# AIエージェントの台帳と監査ログが、制度の論点に

著者：Kotaro OKUYAMA / AgentCollusion  
資料確認日：2026年9月7日  
対応する記事：`/news/stop-rogue-ai-agent-inventory-audit`

AIが一時的な作業役を作り、外部サービスへ仕事を委任するようになると、企業は二つの問いに答える必要がある。いま動けるAIはどれか。そして、過去のある操作は、誰のどの許可に基づいて行われたのか。

9月3日、「Stop Rogue AI Act」の提案が報じられた。[Mike Lawler下院議員サイトに転載された報道](https://lawler.house.gov/news/documentsingle.aspx?DocumentID=6424)

本稿の9月7日の資料確認では、法案本文、法案番号、最新の審議履歴を独立に確認できていない。このため、報じられた提案として扱い、成立、施行期限、個々の企業に適用される義務は断定しない。

## NISTの標準化活動は、すでに進んでいる

NISTは2月17日、AI Agent Standards Initiativeを発表している。産業界による標準化、オープンなプロトコル、セキュリティとIDの研究を柱とする活動だ。今回報じられた法案とは、別の取り組みとして区別する必要がある。[NISTの公式発表](https://www.nist.gov/news-events/news/2026/02/announcing-ai-agent-standards-initiative-interoperable-and-secure)

また8月27日のNISTの記事で、Bill FisherとRyan Galluzzoは、エージェント固有のID、運用主体と結び付く認証情報、範囲を絞った権限、共有・長期利用の認証情報に伴う問題を取り上げている。既存のID管理の実践を土台にした議論である。[NISTのIDに関する解説](https://www.nist.gov/blogs/cybersecurity-insights/back-future-why-agentic-ai-needs-strong-identity-foundation)

以下の台帳とログの設計は、この運用上の課題を考えるためのAgentCollusionの提案だ。法案の条文や、NISTが義務付けた項目を列挙するものではない。

## 導入製品の一覧から、稼働中の主体の把握へ

架空の企業が、購買アシスタントを導入したとする。一つの仕事の途中で、調査用の作業役を起動し、社外の見積もりAIを呼び、別の審査役に候補の承認を頼む。

製品名だけを並べた一覧では、注文時点でどの作業役が購買APIにアクセスできたかは分からない。部署ごとの契約一覧があっても、実際の実行主体までは追えない場合がある。

運用に使う台帳には、配置したサービスと、その実行ID、責任を持つ運用者を結び付けたい。モデルやソフトウェアの版、許された操作、認証情報への参照、対象テナント、起動中・終了済みなどの状態も必要になる。ここに置くのは認証情報への参照であり、再利用できる秘密鍵やトークンそのものではない。

一時的に生まれる作業役には、親のタスクと、引き継いだ権限への対応付けが必要だ。終了した作業役にも、過去を調べるための記録は残す。同時に、その認証情報で本当に操作できなくなったかを確かめる。台帳から行を消しただけでは、ダッシュボードから見えなくなった一方で、アクセス手段が生き残るおそれがある。

## 台帳とログでは、答える問いが違う

台帳は、誰がどの状態で存在するかを把握する。行動ログは、その主体が何をしたかを追う。調査で役立てるには、次の記録をつなぐ必要がある。

| 記録 | 答えたい問い |
| --- | --- |
| エージェント台帳 | どの配置・実行IDが関わったか |
| 委任の記録 | 誰が、何を、いつまで許可したか |
| 操作イベント | いつ、どの操作が要求されたか |
| ポリシーの判断 | どのルールで許可・拒否したか |
| 相手側の処理結果 | 実際に何が完了したか |

これらを結べる識別子が必要になる。ただし、タスクIDは記録をまとめるための値であって、知っているだけで閲覧や操作を許す根拠にはしない。判断に使ったポリシーの版も残しておけば、当時と現在で権限が変わっていても調査できる。

AIの依頼、認可サービスの判断、接続先の結果も分けて記録したい。「注文を取り消しました」という生成文と、注文に対応する相手側の取消受付記録では、示す証拠が違う。両方があれば、食い違いを調べられる。

## 改ざんへの強さと、記録の完全さを分ける

ログを改ざんしにくくしても、最初から一つのサービスを記録していなければ、その行動は残らない。誤った主張をそのまま保存することもあるし、介入に使うには到着が遅すぎることもある。

そのため本稿の設計案では、記録範囲、改ざんへの耐性、記録元の確認、保存期間、閲覧権限を、それぞれ評価する。機微な本文は権限を絞った保管場所に置き、監査イベントには、許された調査者がたどれる参照を残す方法も考えられる。

運用訓練では、一時的な作業役を起動し、狭い権限を与え、別のサービスを呼ばせた後に権限を取り消す。次の呼び出しが拒否されることと、過去の経路がたどれることを確認する。途中に通信障害と再試行も入れれば、結果が不明な操作を照合できるかまで調べられる。これは提案する訓練であり、本稿で実施した結果ではない。

## 正当な操作が並んでも、判断全体の検証は残る

架空の購買アシスタントに戻ろう。推薦役と審査役の操作が、どちらも個別の権限確認を通っていたとする。それでも共謀の可能性を調べるには、候補をどう比較したか、審査役に何が見えていたか、当事者にどんな関係があったかが必要になる。

十分なイベント記録は、その調査の出発点になる。記録がそろっていることだけで、結論が決まるわけではない。

この論点は、[共有台帳とマルチエージェントの説明責任を扱った記事](https://agentcollusion.ai/news/blockchain-multi-agent-accountability)ともつながる。どの保存技術を選ぶとしても、具体的な依頼が複数のAIを経由して、どの実行結果に変わったのかを再構成できることが、運用上の価値になる。