AIエージェントのすべての操作に監査ログが必要な理由と、そこに何を記録すべきか

エージェントの操作とは実際に何なのか

人が「課題を完了」をクリックすれば、それは一人による一つの操作です。エージェントが課題を完了させる場合は連鎖になります。人（またはスケジュール）がエージェント実行を開始し、その実行がツールを呼び出し、ツールがスコープを確認し、スコープはトークンに、トークンは人に紐づき、そこでようやく課題の状態が変わります。このどの環でも問題が起き得ます。

だからこそ「エージェントがやった」は答えになりません。監査ログが答えるべき問いは、どの実行が、誰のトークンで、どのツールを、どのレコードに対して呼び出し、結果はどうだったか、です。この五つのどれかが欠けていれば、そのログは安心材料であって統制ではありません。

通常のアプリケーションログでは足りない理由

ほとんどの製品はすでに何かを記録しています。Webサーバーはリクエストを、データベースは変更を記録し、チャットツールは履歴を残します。「エージェントの操作もどこかに入っている」と言いたくなりますが、実務では三つの点で破綻します。

• 境界で帰属が失われる。 エージェントからのリクエストは通常、連携用ユーザーか、エージェントが持つトークンの持ち主からのリクエストとして届きます。アプリケーションログには「Moeidが課題412を完了した」と残りますが、Moeidが昼食中で、夜間スケジュールが開始した実行がそれをやったことは残りません。
• 読み取りが見えない。 アプリケーションログは書き込みを記録します。すべての商談の金額を読み取り、チャットに要約を投稿したエージェントは、読み取りの痕跡を残しません。漏えいはデータベースではなく要約の中にあります。
• ログがレビューできない。 エージェントの操作が一万行のリクエストノイズに混ざったログを、創業者が金曜日に開いて今週エージェントが何をしたか確認することはありません。誰も読まないなら、それは監督ではありません。

Anthropicのエージェント構築ガイダンスは明快です。エージェントの計画ステップを明示して透明性を優先し、チェックポイントで人のフィードバックのために停止し、最大反復回数のような停止条件を設けること。監査ログは、実行が終わりチャット画面を閉じた後も、その透明性を残すための手段です。

標準が求めていること

知っておくべき文書が三つあります。「十分」とは何かを定義しており、顧客の調達部門から引用されるからです。

• OWASP Top 10 for Agentic Applications（2026年版）。 OWASP GenAI Security Projectが2025年12月9日に公開、100人以上が寄稿しています。不十分なロギングは、過剰なエージェンシー、ツールの誤用、メモリ汚染と並ぶ十のリスクの一つです。二次的な解説記事はカテゴリの番号付けで食い違っているため、IDではなく名称で引用してください。
• EU AI法 第12条。 「高リスクAIシステムは、システムの存続期間にわたり、イベント（ログ）の自動記録を技術的に可能にしなければならない。」ロギングは「意図された目的に適した」トレーサビリティを可能にする必要があります。リスクを生じ得る状況の特定、市販後監視、運用の監視の三点です。附属書IIIのシステムには2027年12月2日から、附属書Iのシステムには2028年8月2日から適用されます。小さなチームの課題管理ツールは高リスクシステムではありませんが、この文言はログの目的の良い定義です。
• Anthropic「Building effective agents」（2024年12月）。 標準ではありませんが、最も引用される実務者向けガイダンスです。計画ステップの透明性、人によるチェックポイント、ガードレール付きのサンドボックスでのテスト。今日のツールの多くが存在する前に書かれ、今も正しい内容です。

共通するのは、ログは自動（事後の手書き報告ではない）、継続的（サンプルではなく全操作）、目的に適合（何が起きたか再構成できる量であり、すべてのコピーではない）であるべきだという点です。

五つのフィールドと、除外すべき唯一のもの

これはエージェントが行うすべての呼び出しについて私たちが保持している記録で、どのチームにとっても最低限だと考えています。

そして除外すべきもの、それは内容です。商談の金額も、課題の本文も、メッセージの文面も入れません。理由は二つ。第一に、ログはログの閲覧を許された人なら誰にでも見せられなければなりません。内容を含むと、記録したすべての権限を引き継いでしまい、最も必要とする人に見せられなくなります。第二に、内容はすでにレコードの中にあります。対象のIDがそこを指し、レコード自身のバージョン履歴が何が変わったかを示します。

ツール、実行者、対象、結果、時刻を持つログは、この記事のすべての問いに答えられます。さらに内容まで持つログは、アクセス制御の弱いデータベースの二つ目のコピーです。

読み取りは書き込みと同じくらい重要

反射的に書き込みだけを記録しがちです。壊すのは書き込みだからです。しかしエージェントはこの計算を変えます。CRMの読み取り権限を持つエージェントは、エージェントにアクセスできる誰からでも、チャット画面で全商談と金額の一覧を求められ得ます。CRMの権限システムは、商談金額の閲覧には特定の権限が必要という前提で作られています。エージェントのトークンがその権限を持ち、尋ねた人が持っていなければ、その読み取りのログだけが漏えいの証拠になります。

私たちのルールは、読み取りも書き込みと同じ粒度で記録し、結果フィールドを正直に保つこと。拒否された読み取り（「refused: crm.value.view」）は、千件の成功した読み取りよりレビュー担当者に役立ちます。権限層が機能していること、誰が探りを入れていたかが分かるからです。

レート制限も監査の一部

ログは何が起きたかを教えます。制限は、誰かがログを読む前に間違ったことが一万回起きるのを止めます。両者は一組です。トークンごとの呼び出し制限と、より厳しい書き込み制限があれば、ループしたエージェントや盗まれたトークンの被害は有限になり、ログには人が見て分かる429の山が現れます。

Atrixでは、各MCPトークンは毎分120回の呼び出しと30回の書き込みに制限されています。意図的に低い値です。人の一日の仕事を手伝うエージェントは近づきもせず、ループは十秒以内に到達します。

Atrixがエージェントの操作を記録する方法

Atrix AIは、OAuth 2.1の背後にある85ツールのMCPサーバーを通じてワークスペースをエージェントに公開しています。すべての呼び出しは、上記の五つのフィールドそのもの、つまりツール、結果、対象の種類とID、そして背後のトークンと人で監査されます。内容が監査ログに書かれることはありません。/developersに文書化されているREST API経由の呼び出しも同様です。

三つの設計判断が大半の仕事をしています。

1. スコープは狭く、決して広がらない。 トークンには特定のスコープが付与されます（2026年10月時点で付与可能なものは49）。書き込みスコープはその読み取りを含意しますが、それ以外は含意されません。九つのスコープはさらに本人のアカウントに対応する権限を要求するため、トークンは作成した人以上の範囲に決して届かず、権限は呼び出しごとに確認されます。ある人のアクセスを取り消せば、その人が作ったすべてのトークンはその瞬間に届く範囲を失います。
2. 人に通知する書き込みはゲートされる。 フィードへの更新投稿は独立した名前付きスコープで、一般的な書き込みスコープから含意されることはありません。全員の携帯電話に通知が飛ぶからです。エージェントが偶然これを引き継ぐことはできません。
3. ログはエージェントではなく人のもの。 監査エントリはトークンとそれを作った人を名指しします。「エージェントがやった」は名前のあるチームメイトに解決され、その人がエージェントに許したことに責任を持ちます。

限界も率直に述べます。これはMCPとAPI経由の呼び出しの監査です。Atrixはコードをスキャンせず、静的解析も行わず、エージェントの「要件監査」は凍結したベースラインに対するカバレッジ確認であってセキュリティツールではありません。監査ログはワークスペースで誰が何をしたかに答えますが、エージェントの推論が妥当だったかは評価しません。

小さなチームで監督体制を整える

セキュリティチームは要りません。必要なのは五つのフィールド、週一回の習慣、そして誰がエージェントを接続できるかのルールです。

1. 各エージェント接続に一人の責任者を置く。 共有の連携ユーザーは使わない。トークンを作るなら、名前のある人が自分のアカウントで作る。そうすればトークンが持つ権限は本人のものになり、ログはその人を名指しします。
2. まず読み取りだけを付与する。 一週間、読み取りスコープのみでエージェントを接続する。ログを読む。それからエージェントが本当に必要とする書き込みスコープを一つだけ足す。
3. 毎週ログを読む。書き込みと拒否で絞り込んで。 金曜日に二十分。見るのは二点、想定外の書き込みと、誰かが本来以上を求めたことを示す拒否です。
4. 通知を伴う書き込みは人のトリガーのもとに置く。 チーム全体への投稿、顧客へのメール送信、金銭の移動は、人が明示的に付与し、別途レビューするスコープにします。
5. レート制限は人が手作業でできる量より低く設定する。 人が一分に30件の変更をできないなら、エージェントにも許すべきではありません。
6. 必要になる前に保持期間を決める。 90日分の監査エントリがあれば「先月何があったか」のほぼすべてに答えられます。ログに内容が含まれないならもっと長くても構いません。内容を入れないもう一つの理由です。

エージェントのロギング手法の比較

チャット記録には注記が必要です。エージェント自身の要約（「商談を三件、成約に移しました」）を記録として扱いたくなります。しかしそれは調べられる側の供述です。監査ログこそが独立した記録です。

よくある質問

AIエージェントの監査ログには何を含めるべきですか？

最低限、呼び出されたツール、トークンとその所有者、対象の種類とID、結果（ok、拒否、エラー）、時刻です。内容は除外します。対象のIDがレコードを指し、レコード自身の履歴が変更を保持します。

エージェントの読み取りも記録すべきですか、書き込みだけですか？

両方です。エージェントは読み取った内容をチャットで要約することでデータを漏らすことがあり、その読み取りが唯一の証拠になります。読み取りも書き込みと同じ粒度で記録し、特に拒否された読み取りに注意してください。

AIエージェントの監査ログは法律で義務付けられていますか？

ほとんどの小さなチームには義務はありません。EU AI法第12条は高リスクAIシステムにイベントの自動記録を求めており、附属書IIIのシステムには2027年12月2日から適用されます。課題管理やCRMのエージェントは高リスクではありません。OWASP Top 10 for Agentic Applications（2026年版）は不十分なロギングを名指しのリスクとして挙げていますが、これはガイダンスであって法律ではありません。ただし調達のアンケートで引用されるのはこれです。

監査ログはエージェントのチャット履歴とどう違うのですか？

チャット履歴はエージェントが書いた、自分が何をしたかの説明です。監査ログはエージェントが操作した側のシステムが、操作の瞬間に、トークンと人を名指しして書くものです。両者が食い違えば、正しいのは監査ログです。

Atrixはエージェントが読み書きした内容を記録しますか？

いいえ。AtrixはすべてのMCPとAPIの呼び出しについて、ツール、結果、対象の種類とID、背後のトークンと人を記録します。内容が監査ログに書かれることはありません。レコードへの変更は、そのレコード自身のバージョン履歴で確認できます。

エージェントの監査エントリはどのくらい保持すべきですか？

90日あれば実務上のほぼすべての問いに答えられます。適切に設計されたエントリは内容を含まないため、長く保持してもリスクは小さいです。より重要なのは、誰かが毎週それを読むことです。

次のステップ

初めてエージェントを仕事に接続するなら、読み取りスコープ、名前のある一人の責任者、週一回のログ確認から始めてください。Atrix AIエージェントも同じ制限の中で動作し、MCPドキュメントにはすべてのスコープとその含意が記載されているので、付与する前に何を付与するか決められます。

出典

2026年10月に確認：OWASP Top 10 for Agentic Applications for 2026、EU AI法 第12条：記録保持、Anthropic, Building effective agents。