AIエージェントの監査ログ設計｜「誰が、何を、なぜ実行したか」を後から復元する【2026】

AIエージェントで問題が起きたとき、「モデルが何かをした」だけでは復旧も説明もできません。誰の依頼から始まり、どのエージェントと設定が、どのtoolを、どの入力で呼び、誰が承認し、外部システムで何が完了したかを、一つの実行としてたどれる必要があります。

監査ログの目的は、会話をすべて保存することではありません。事故調査、権限レビュー、誤実行の取消しで必要な最小限の証跡を残しながら、プロンプトや応答に含まれ得る個人情報・営業秘密を不要に増やさないことです。OpenAI Agents SDKは、LLM生成、tool call、handoff、guardrail、独自イベントを実行トレースとして収集できます。ここから、AIの出力だけでなく処理経路を記録する実装が現実的になっています。

まず、一つの実行を貫くIDを作る

利用者の画面操作、エージェントの実行、モデル呼出し、tool、承認、外部更新に共通のrun_idを渡します。画面側の操作IDだけ、モデル提供者のrequest IDだけ、と断片化すると、障害時に別々のログを人手で突き合わせることになります。

最低限、次を構造化して残します。

実行主体: 利用者、サービスアカウント、テナント
実行条件: run_id、エージェント名・版、ポリシー版、開始・終了時刻
判断経路: モデル、tool名、許可・拒否、エラー、再試行の有無
外部効果: 更新先、送信先の種別、処理結果、取消し可否
人の関与: 承認要求ID、承認者、判断、期限、承認対象の版

ここで重要なのは、監査ログをモデルの説明文で代用しないことです。「この理由で送信した」という文章は証拠の一部にはなっても、実際にどの宛先・本文・添付・設定で送ったかを示しません。外部操作は、AIエージェントの承認ゲート設計のように対象を固定し、その対象の版と実行結果を関連付けます。

本文保存を既定にしない

LLMの入力・出力には、顧客情報、個人情報、社内文書、認証情報が入り得ます。OpenTelemetryのGenAI仕様は、instructions、入力、出力を機微かつ大容量になり得るデータとして扱い、instrumentationが既定で記録しないことを推奨しています。調査しやすいからと全文を永続保存すれば、ログ基盤が新しい機密データ保管庫になります。

通常は、モデル名、時刻、所要時間、token使用量、status、tool名、分類済みの結果、相関IDなどのメタデータを残します。本文が必要なのは、明確な調査目的、限定された閲覧者、保持期限、削除方法を決めた例外です。Cloudflare AI Gatewayでも、本文保存を止めながらtoken数、model、provider、status、cost、durationなどのメタデータは記録できます。

ただし、本文を保存しないと、誤答やprompt injectionの調査に足りない場合があります。そのため「常に全文を残す」か「一切残さない」かではなく、検証環境、明示同意のある評価データ、インシデント時の限定採取など、用途ごとの方針を決めます。OpenAI Agents SDKも機微データを含めるトレースを設定で制御できる一方、設定前に既にバッファされたデータまでは自動で消えないと案内しています。採取開始だけでなく、停止・保持・削除を運用に含めます。

監査ログと設定変更ログを分ける

実行ログだけでは、なぜ昨日まで許されたtoolが今日ブロックされたのかを説明できません。エージェントのtool許可、model、ガードレール、保持設定を誰がいつ変更したかも別に記録します。Cloudflare AI Gatewayはgatewayの作成、削除、更新を監査ログの対象として示しています。これはアプリの業務ログの代わりにはなりませんが、設定変更の追跡という別の層が必要なことを示します。

OWASPはAgentic AIの論点としてlogging and non-repudiationを掲げています。とはいえログの存在だけで安全になるわけではありません。認可が広すぎる、危険なtoolを許す、承認後に対象が変わる、といった事故は、ログを見てからでは防げません。MCPサーバーのOAuth認可設計や承認ゲートで実行前の境界を狭め、監査ログでは実際に何が起きたかを復元する、と役割を分けます。

事故時に答えるべき問いを、先にテストする

導入前に、次を一つのrun_idで答えられるかを確認します。「誰が開始したか」「どの版のエージェントか」「どのtoolが何を対象に実行したか」「承認は誰がどの版に対してしたか」「外部更新は成功したか、再試行されたか」「機微な本文を誰が閲覧できるか」。答えられない項目があれば、ログ量を増やす前にID、イベント形式、閲覧権限を整えます。

TechWorkerでは、内製AIツールについて、権限・承認・tool実行・保持期間を業務フローに沿って整理し、説明できる監査証跡の設計を支援します。情シス審査に備えるだけでなく、日常の誤操作から安全に復旧できる状態を作ります。

限界と確認範囲

監査ログは検知・説明・復旧を支えますが、prompt injection、誤認可、情報漏えい、誤送信を単独で防ぐものではありません。また、完全な入力・出力を残さない設計では、調査できない事実も残ります。データ最小化と調査可能性のトレードオフを、対象業務、保存先、閲覧者、保持期限ごとに明文化してください。製品仕様と保持条件は変更されるため、導入前に公式資料の最新版を再確認します。

一次情報と確認範囲

確認日：2026年9月10日。製品仕様・制度は更新されるため、導入時はリンク先の最新版を再確認してください。海外の制度・職業規範は日本へ直接適用せず、相違点と限界を本文に明記しています。