ブログ · ガイド · 2026年10月28日
本番環境の AI エージェントのためのトレーサビリティ・チェックリスト：何を記録し、何に署名し、レビュー担当者に何を見せるか
開示: 100monkeys.ai はオープンソースのエージェント・オーケストレーター AEGIS を開発しており、下で引用している awesome-agent-traceability リストもメンテナンスしています。このチェックリストは特定ベンダーに依存しません。どの項目もオープンなツールで満たせ、当社製品は必要ありません。当社の AI エージェントが下書きし、当社がレビューしました。この日本語版は英語の原文の翻訳です。
AI エージェントが実際のシステムに対して行動すれば、いずれ誰かが「何をしたのか、なぜしたのか」と尋ねます。このチェックリストは、その質問が来る前にやっておくべき作業です。各実行で何を記録するか、記録を信頼できるものにするために何に署名するか、そしてレビューする人の前に何を置くか。各項目には、awesome-agent-traceability リストに載っているオープン標準やツールを挙げています。
この枠組みは当社の論文 Red levers: traceable, deterministic agents in production（英語）から来ています。この論文は、エージェントシステムが本番で安全であるとは、人がそのシステムのすべての判断と、その判断の理由を見ることができ、さらに止められることだと定義しています。ログは 1 つ目に、記録された理由は 2 つ目に、レビューの手順は 3 つ目に対応します。
パート 1. 何を記録するか
ステップ 1. すべての実行に ID を与える
実行の開始時に ID を割り当て、すべてのモデル呼び出し、ツール呼び出し、副作用にそれを引き継ぎます。ID がなければ、ログは誰にもまとめられないイベントの山です。生成 AI 向けの OpenTelemetry セマンティック規約 のトレース ID とスパン ID を使いましょう。モデル呼び出し、エージェントのステップ、ツール呼び出しに共通の名前を定めているので、異なるフレームワークのトレースも同じように読めます。エージェントスパン の規約は、エージェントの作成と呼び出しを扱っています。
ステップ 2. 依頼と意図を言葉で記録する
エージェントが何を、誰から、どんな理由で頼まれたかを記録します。そして結果を伴う行為のたびに、なぜそうするのかをエージェント自身が 1 行で述べたものを記録します。行為の時点で書かれた理由は証拠になり、後から再構成した理由はただの物語です。
ステップ 3. モデルとその設定を記録する
モデル呼び出しごとに、プロバイダー、モデル名とバージョン、出力を変えるパラメーター（temperature、最大トークン数、提供したツール）、トークン数を記録します。モデルのバージョンに結びつけられない挙動は、プロバイダーがモデルを更新した後には再現できません。
ステップ 4. すべてのツール呼び出しを入力と出力つきで記録する
ツール名、引数、結果、時刻を記録します。個人データは保存した後ではなく、保存する前にマスクしてください。オープンな選択肢の 1 つに Presidio があります。どこかに書き込んだツール呼び出しは、何を変えたか（diff、レコード ID、メッセージ ID）も記録すべきです。
ステップ 5. ポリシー判断をひとつずつ記録する
ポリシーエンジンが呼び出しを許可または拒否したなら、その判断と、判断を下したルールを記録します。Open Policy Agent はまさにこのための判断ログを残します。拒否は許可と同じくらい残す価値があります。制限が守られたことを示すからです。
ステップ 6. アイデンティティと到達範囲を記録する
実行がどの認証情報やトークンを使い、その認証情報が何に到達できたかを記録します。シークレットの値そのものは記録しません。レビュー担当者の問いは多くの場合「もっと悪いことができたか」であり、その答えは持っていたスコープです。
ステップ 7. 実行を再現できるようにする
作業をもう一度実行できるだけの情報を保存します。入力、各ステップの状態、イベントの順序です。Temporal のような永続実行エンジンはワークフローのイベント履歴を保持し、ワークフローを決定的に再実行（リプレイ）できるようにします。
パート 2. 何に署名するか
ステップ 8. ログを追記専用にし、チェーンでつなぐ
後から書き換えられる記録は何も証明しません。イベントは追記専用のストアに書き込み、各エントリをハッシュで直前のエントリとつなげて、削除や編集があればチェーンが壊れるようにします。IETF の SCITT ワーキンググループは、追記専用の透明性サービスに登録される署名付きステートメントを定義しており、まさにこの用途に使える形です。
ステップ 9. エージェントが生成したものに署名する
実行が成果物（ビルド、レポート、リリースしたファイル）を生み出したら、それがどう作られたかを示す署名付きステートメントを添付します。in-toto Attestation Framework はそうしたステートメントを運び、SLSA はビルドの来歴のレベルを定めています。メディアについては、C2PA 仕様 が、AI が生成または編集したコンテンツも含めて、署名付きの来歴マニフェストを添付します。
ステップ 10. 承認に署名する
人が行為を承認したなら、誰が、いつ、正確に何を見て承認したかを記録します。承認は内容に結びつけてください。承認後に行為が変わったら、その承認はもう有効ではありません。
パート 3. レビュー担当者に何を見せるか
ステップ 11. 要約ではなく行為そのものを見せる
レビュー担当者が見るべきは、実行自身の出力から描画された、送られるメール、diff、実行されるコマンドです。承認を求めている当のモデルが書いた要約は、レビューの対象にはなりません。
ステップ 12. 行為の横に理由を見せる
エージェントが記録した意図を、それが行った変更の横に置きます。「この行はなぜここにあるのか」には、その行が入ったときに書かれた一文が答えるべきです。
ステップ 13. 実行時の制限を見せる
ポリシーと認証情報のスコープを実行の横に表示します。エージェントが 1 つのブランチにしか書き込めなかったと分かっているレビュー担当者は、何にでも手が届いたと想定するしかない人とは違う読み方をします。
ステップ 14. レビュー担当者に停止手段を渡す
どのレビュー画面にも拒否する手段が必要で、その拒否は確実に効かなければなりません。Red levers で引用している EU AI 法第 14 条は、高リスクシステムを監督する人が "intervene in the operation of the high-risk AI system or interrupt the system"（システムの動作に介入し、または中断できる）ことを求めています。ここで引用するのは制御の形を示すためであり、法令への準拠を主張するものではありません。
自分で確かめる
先週の実行を 1 つ選び、記録だけから答えてみてください。誰が依頼したか、エージェントは何を呼び出したか、何を変えたか、どのポリシーのもとか、誰が承認したか、そしてその記録はその後編集されえたか。答えられない質問は、どれも上のいずれかのステップに対応しています。
当社での適用
当社はこのリストの一部を担うツールを作っています。AEGIS by 100monkeys.ai, in beta は、エージェントを隔離され、ポリシーが強制され、永続的な状態を持つランタイムで動かすセルフホスト型のオーケストレーターです。オーケストレーターに承認ステップを持たせる方法ではその承認ゲートを実例として紹介し、こちらのインストールガイド でサーバー上で動かす手順を説明しています。Carbon Forge はコードと文章を 1 つの記録に保ち、blame で変更が入った時点に書かれた意図を表示します。