止められたことは証明できても『なぜ』は誰も答えられない——AIエージェントの監査証跡設計

「止められたことは証明できても、『なぜ』は誰も答えられなかった」というギャップ

Gravitee社が実施した「State of AI Agent Security 2026」調査では、エグゼクティブ・実務家919名を対象に、過去12ヶ月にAIエージェントのセキュリティインシデントを経験した企業が88%に上ると報告されています。ところが同じ調査で、エージェントの実行時の挙動を可視化できている企業はわずか21%にとどまりました。9割近い企業が何らかの事故を経験しているにもかかわらず、その大半は「何が起きたか」をリアルタイムで把握できていない計算になります。

私たちの現場経験に引きつけて言えば、これは「事故が起きたことは分かるが、事故の中身は分からない」という状態です。監視ツールのアラートは鳴った。再起動もした。しかし、そのとき何が実行されようとしていたのか、誰の承認のもとで動いていたのかは、ログを漁っても出てこない。正直に言えば、私たちが最初にこの調査結果を見たとき、数字の低さよりも「事故の経験率」と「可視性」の差の大きさに驚きました。事故は起きているのに、説明する材料がないという状態が、すでに標準になりつつあるということです。

「ログを取っている」と「説明責任を果たせる」は別のことだ

多くの企業が「うちはログを取っている」と答えます。ですが、ここで言うログの多くは、実行結果だけを記録した出力ログです。処理が成功したか失敗したか、何件のレコードが更新されたか——これはこれで必要な情報ですが、説明責任を果たすための材料としては足りません。

CSA(Cloud Security Alliance)とRSA Conferenceが共同で実施した2026年の調査では、900名超のセキュリティ責任者・実務者を対象に、組織の68%が「人間の操作なのか、AIエージェントの操作なのか」を事後に区別できないと回答しています。誰が、あるいは何がその操作をしたのかすら分からない状態です。なぜその操作をしたのかまで説明するのは、当然ながら不可能です。

私たちが監査証跡という言葉を使うとき、それは単なる実行ログを指していません。判断に至った文脈、適用されたポリシー、最終的な実行内容。この三つを一本のチェーンとしてつなげた記録を指しています。出力だけを残す設計から、判断の過程まで残す設計へ。この転換が、今回のテーマの出発点です。

正直に言えば、私たちも最初からこの違いを明確に区別できていたわけではありません。「ログを取っているので大丈夫です」という顧客の言葉を鵜呑みにし、実際に中身を確認してみたら成功・失敗のステータスしか残っていなかった、という経験が何度かあります。ここで意見が分かれるところですが、私たちは「取れているログの量」よりも「説明できる範囲」を基準にすべきだと考えています。量だけを追いかけると、何十万行のログがあっても、肝心の「なぜ」が一行も含まれていないという事態になりかねません。

私たちがこれまでお伝えしてきた「AGENTフレームワーク」、最後のピース

前々回、鍵を守っても『誰が使ったか』は分からないでお伝えしたのは、エージェントごとに固有の身元を持たせる設計でした。前回、最小権限を絞っても、被害はゼロにならないでお伝えしたのは、被害範囲そのものを構造で区切る設計でした。海外の「AGENTフレームワーク」の5原則のうち、今回お伝えするのは、すべての操作を最終的に責任を持つ人間まで遡れる形で記録するという原則です。

身元が明確になり、被害範囲が区切られていても、実際に何が起きたかを誰も再現できなければ、事故対応も規制対応も机上の空論に終わります。私たちの理解では、身元(誰が)・被害範囲(どこまで)・監査証跡(なぜ・何を)の三つが揃って初めて、AIエージェントを安心して本番環境に置ける状態になります。どれか一つだけを整えても、残り二つの抜け穴から事故は起こり得るというのが、このシリーズを通じての私たちの結論です。

余談ですが、この3本の記事を書きながら社内で議論していたとき、あるメンバーから「結局、全部やらないといけないなら大変ではないか」という声が上がりました。私たちの答えは、順番をつければ大変ではないというものです。まず身元を明確にする。次に被害範囲を区切る。そして監査証跡を整える。この順番で着手すれば、それぞれの工程は既存のクラウド環境の設定変更や、ログ出力の見直しといった、決して大がかりではない作業の積み重ねで済みます。

監査証跡に残すべき5つの要素

海外の実務では、監査証跡に残すべき要素として、おおむね次の5つが挙げられています。誰が(エージェントの固有ID)、いつ(タイムスタンプ)、何を(呼び出したツール・APIとそのパラメータ)、どの権限で(適用されたポリシーと許可・拒否の判定)、そしてなぜ(判断に至った文脈や根拠)です。

私たちの現場経験では、最初の4つは比較的取り組みやすい項目です。ログの出力形式を決め、必須フィールドとして強制すれば済みます。「誰が」はエージェントの固有IDとバージョンを紐づけるだけで済みますし、「いつ」もタイムスタンプを自動付与すれば足ります。「何を」は呼び出したツール名とパラメータをそのまま記録すればよく、「どの権限で」も適用したポリシーのIDと許可・拒否の結果を残すだけです。

難しいのは最後の「なぜ」です。AIエージェントは人間のように「こう考えたからこう判断した」という説明を自然に残しません。判断の根拠を残すには、エージェントに判断理由を明示的に出力させる設計を、あらかじめ組み込んでおく必要があります。私たちが顧客の現場で提案しているのは、エージェントに行動を実行させる直前に「なぜこの操作を選んだか」を1〜2文で出力させ、それをログの必須フィールドとして保存する方法です。完璧な説明である必要はありません。あとから人間が読んで文脈を追える程度で十分機能します。ここを後回しにすると、後から「なぜ」だけが永久に欠落したログが積み上がっていきます。

証跡があるとき、事故対応はどれほど変わるか

抽象的な話が続いたので、ここで具体的な場面を想像してみます。ある企業のAIエージェントが、深夜に想定外の外部APIを呼び出し、顧客データの一部を第三者のサービスに送信していたことが翌朝発覚したとします。

証跡がない場合、対応チームがまず取り組むのは「何が起きたか」の推測です。アプリケーションログを漁り、担当エンジニアの記憶を頼りに設定変更の履歴を洗い直し、原因の特定だけで数日を要することも珍しくありません。その間、顧客への説明も規制当局への報告も、正確な情報がないまま「調査中です」を繰り返すことになります。

監査証跡が整っていれば、話はまったく違います。どのエージェントが、いつ、どのポリシー判定のもとで、なぜその外部APIを呼び出したのかが、記録から数分で再現できます。原因の切り分けが終われば、顧客への説明も「調査中です」ではなく、「何が起き、どこまでの範囲に影響したか」という具体的な報告に変わります。私たちの現場経験では、この「数分で再現できるか、数日かかるか」の差が、事故対応のコストだけでなく、顧客や規制当局からの信頼にも直結します。

これは想像の話ではありません。私たちが顧客の現場に伴走する中でも、似たような場面に何度も遭遇してきました。原因調査に時間がかかればかかるほど、担当者は「何か隠しているのではないか」という不信の目にさらされます。逆に、初動から正確な事実を提示できれば、事故そのものは残念な出来事であっても、その後の関係が壊れることはめったにありません。同じ事故を起こしても、迅速かつ正確に説明できる企業と、できない企業とでは、その後の関係修復にかかる時間がまるで違うというのが実感です。

規制の締切は、もうすでに到来している

EU AI Actは2026年8月2日に完全施行の段階に入り、AIによる意思決定について照会可能な記録を残すことが義務付けられています。加えて、インシデントが発生した場合の報告期限は72時間以内とされています。規制当局から「このエージェントは何をしたのか」と問われたとき、検証可能なタイムラインを3日以内に提示できなければ、対応そのものが規制違反になりかねません。

私たちが強調したいのは、これがEU域内の企業だけの話ではないという点です。EU圏の顧客・取引先を持つ日本企業や、グローバル企業のサプライチェーンに組み込まれている製造業にとっても、無関係ではいられません。仮に直接の適用対象でなくても、取引先の監査要件として同水準の証跡を求められる場面は、今後増えていくというのが私たちの見立てです。ログファイルを後から人力でかき集める運用では、この期限には到底間に合いません。

同様の動きは他の地域でも進んでいます。シンガポールのIMDA(情報通信メディア開発庁)は2026年1月、自律型AIエージェントに特化したガバナンスの枠組みを公表しました。エージェントごとに検証可能なデジタルIDを持たせること。そして、誰の権限のもとで動いたかを示す監査証跡を持たせること。この2点を求めています。米国でもNIST(米国立標準技術研究所)のAIリスクマネジメントフレームワークが2026年3月に改訂され、実務での参照基準になりつつあります。私たちの見立てでは、法域ごとに細部は違っても、「AIエージェントの判断は、あとから第三者が検証できる形で残す」という方向性そのものは、今後も世界的に強まっていくと考えています。

私たちが自社で実践していること——ISMSでの証跡蓄積

私たちAI-Path自身も、社内のISMS(情報セキュリティマネジメントシステム)をこの1年で本番移行のフェーズまで進めてきました。社内アプリに文書承認フロー・ロール別の閲覧制限・証跡の蓄積を実装し、財務経理・人事系まで含めて機能単位でアクセス権を分離しています。誤解のないように言えば、これは完璧な仕組みを最初から作れたわけではありません。むしろ、自社の運用で実際に踏み抜いた穴を一つずつ塞ぎながら、ここまで来たというのが実感に近いです。

具体的には、認証機関との打合せを重ねながらe-learningを受講レベル1〜6まで全面刷新し、社内ISMSアプリで文書の承認フロー・ロール別の閲覧制限・証跡の蓄積を実装しました。顧客の自社環境へ移行する前にはレッドチームアタック(攻撃者の視点で自社システムを試す訓練)を実施し、本番環境にはIP制限を入れています。単体テスト(Vitest)とシナリオテスト(Playwright)を自動化する一方、AIが苦手とするUXの観点はユーザー受け入れテストで人が最終確認する、という役割分担も崩していません。

私たちがこの経験から得た教訓は、証跡の仕組みは「あとから足す」のが最も高くつくということです。すでに動いているエージェントに証跡の仕組みを後付けしようとすると、ログの粒度がエージェントごとにばらばらになり、結局は横断的な分析ができません。新しいエージェントを立ち上げる段階から、証跡のフォーマットを標準化しておくことを、私たちは顧客の現場でも徹底しています。

AI-Pathの見解——記録の目的は「監視」ではなく「学びの蓄積」

私たちは社内の会議をすべて記録し、AIに読み込ませて横断的に振り返るという運用を徹底しています。この記録の目的は、誰かを取り締まることではありません。難度の高い判断ほど、あとから振り返る価値のある学びとして貯まっていく、という考え方に基づいています。監査証跡も、私たちは同じ発想で捉えています。

前回の記事で、ログを「事後調査用」だけでなく「進行中の検知用」としても使うべきだとお伝えしました。監査証跡はさらにその先で、「事後の説明責任」と「組織としての学び」の両方に使える資産になります。あるエージェントがなぜその判断をしたのかが記録に残っていれば、事故対応の場面では説明責任の材料になり、平時にはプロンプトやガードレールを見直すための教材になります。規制対応のためだけに証跡を残すという発想では、現場は「義務だからやる」という受け身の姿勢に留まってしまいます。学びとして活用できる設計にして初めて、証跡を残す作業そのものに現場が前向きになる、というのが私たちの実感です。

私たちが月次で振り返っているのは、事故になりかけた「ヒヤリハット」の証跡です。実際に被害が出た事故だけを分析していては、学びの母数が少なすぎます。未遂に終わった判断のログにこそ、次の設計改善のヒントが詰まっているというのが、私たちがこれまでの現場で得てきた実感です。

自己診断: 自社のAIエージェントは「なぜ」を説明できるか

ここまでの内容を、自社に当てはめてチェックしてみてください。

1. AIエージェントの操作ログに、実行結果だけでなく「なぜその操作を選んだか」の根拠が残っているか。
2. ある操作が、人間の手によるものかAIエージェントによるものか、ログから明確に区別できるか。
3. 規制当局や取引先から「このエージェントは何をしたか」と問われたとき、72時間以内に検証可能なタイムラインを提示できるか。
4. 新しいエージェントを立ち上げる際、証跡のフォーマットがあらかじめ標準化されているか。
5. 蓄積した証跡を、事故対応だけでなく、プロンプトやガードレールの改善にも活用できているか。

私たちの現場経験では、5つのうち3つ以上に「いいえ」がつく企業ほど、いざというときに説明責任を果たせず、規制対応にも社内の信頼回復にも時間がかかる傾向にあります。逆に言えば、5つすべてに「はい」と答えられる企業は、まだそう多くありません。完璧を目指す試験ではなく、次に何から着手するかを決める地図として使っていただければと思います。

よくある質問

Q1. 監査証跡と、これまでお伝えしてきたログ監視は何が違うのですか。 ログ監視は「異常が起きていないか」をリアルタイムで検知するための仕組みです。監査証跡は、実際に何が起きたかをあとから第三者に説明できる形で記録する仕組みで、目的が異なります。私たちは両方が必要だと考えています。

Q2. 「なぜ」の部分は、具体的にどう記録すればよいですか。 私たちが勧めているのは、エージェントに判断理由を短いテキストで出力させ、それをログの必須フィールドとして保存する方法です。完璧な説明である必要はなく、あとから人間が読んで文脈を追える程度で十分機能します。

Q3. 小規模なチームでも、ここまでの証跡設計は必要ですか。 必要です。私たちの経験では、エージェントの数が少ないうちのほうが、証跡のフォーマットを標準化する手間ははるかに小さく済みます。前回・前々回の記事でも同じことをお伝えしましたが、後回しにするほど手戻りは大きくなります。専任のセキュリティ担当者がいない企業ほど、最初の1つを決めておくだけで、後から加わるエージェントすべてに同じ型を使い回せるという利点もあります。

Q4. 監査証跡を残すこと自体が、AIエージェントの処理速度を落としませんか。 判断理由の出力とログ保存を非同期の処理に分ければ、体感できるほどの遅延にはなりません。私たちが自社で運用している範囲では、処理速度への影響よりも、証跡が残ることで得られる安心感のほうがはるかに大きいというのが実感です。ログの保存先も、本番のデータベースとは別のストレージに分けておくと、証跡そのものが本番処理の負荷要因になる事態を避けられます。

Q5. EU AI Actは、日本国内だけで事業をしている企業には関係ないのでしょうか。 直接の適用対象でなくても、無関係とは言い切れません。取引先や親会社がEU圏に関わりを持つ場合、同水準の証跡を求められる場面が今後増えていくというのが私たちの見立てです。

Q6. 監査証跡の設計は、前回・前々回の記事とどう関係しますか。 前々回でお伝えした身元の設計、前回でお伝えした被害範囲の設計、そして今回の監査証跡は、いずれも同じ「AGENTフレームワーク」の異なる側面です。三つが揃って初めて、事故発生時に迅速な原因特定と説明責任の両立ができるようになります。

まず試すなら

• AIエージェントのログに、実行結果だけでなく判断理由が残っているかを確認してみること。
• ある操作が人間によるものかAIエージェントによるものか、既存のログから区別できるかを試してみること。
• 新しいエージェントを立ち上げる前に、証跡のフォーマットを1つ決めて標準化しておくこと。
• 直近の小さな事故やヒヤリハットを1件選び、72時間以内に説明できる情報がログに残っているか検証してみること。
• 蓄積したログを、事故対応だけでなくプロンプト改善の材料として月に一度振り返る機会を作ること。

身元を明らかにし、被害範囲を区切り、そして何が起きたかを説明できる。この三つが揃って初めて、AIエージェントは安心して本番環境に置ける存在になります。AI-Pathでは、無償の業務プロセス診断(BPR)を実施しています。自社のAIエージェントが「なぜ」を説明できる状態か、一緒に点検してみませんか。

参考リンク

• 88% Had AI Agent Incidents. Few Have an Audit Trail (Gravitee "State of AI Agent Security 2026"調査の紹介)

• Your AI Agents Are Changing State. There's No Audit Trail.

• AI Agent Audit Trails Explained: The Missing Layer of Enterprise AI Governance