AI Agentガバナンスを「承認」から「不変な実行・トレース・監視」へ──外界に作用するAIのためのImmutable Agent Execution

🎥 YouTubeでも公開しています

AI Agentを企業業務へ安全につなぐ ― Chinoba Decision Runtime Edge（CDR Edge）とは

Books: Runtime AI Governance 実践ガイド: Knowledge Flow・Trust Engine・Decision Traceによる動的AIガバナンス設計

AI Agentは、文章を生成するだけの存在ではなくなりつつある。

社内文書を検索し、データベースを参照し、メールを送信し、業務システムを更新し、外部APIを呼び出し、他のAgentへ仕事を委任する。AIが外界に作用できるようになるほど、問うべきことは「どれほど賢いか」だけではなくなる。

誰の権限で、どの根拠により、何を実行したのか。
その実行は後から検証でき、異常なら止められるのか。

従来のAIガバナンスは、しばしば事前承認に寄りがちだった。しかし、すべてのAgent行動を人が承認するなら、AIの自律性と速度は失われる。逆に、AIへ広い権限を与え、事後確認だけに任せれば、誤操作や権限逸脱を見逃す。

本稿では、この二者択一を超えるために、Immutable Agent Execution、Decision Trace、継続監視、監視マルチエージェントを組み合わせる考え方を整理する。

承認中心のガバナンスが抱える限界

高リスクの操作に人の承認を求めることは必要である。送金、契約締結、対外公表、権限変更、医療・安全に関わる操作まで、AIが単独で実行してよいわけではない。

しかし、すべての操作を承認対象にすると、問題が起きる。

• 反復的で低リスクな作業まで待ち時間が発生する
• 人は大量の承認依頼を十分に吟味できなくなる
• AIは人の操作を代行するだけの仕組みになる
• 事前に想定できない例外が、実行を止める
• 実行後に何が起きたかを学ぶ仕組みが弱くなる

AI Agentには、完全な自由でも、完全な事前統制でもない運用モデルが必要である。

境界の内側では自律的に実行する。
ただし、全てを追跡し、継続的に監視し、逸脱すれば介入する。

この考え方では、人の役割は個々の操作を承認することから、境界、例外、介入条件、責任分担を設計することへ移る。

Immutable Agent Executionとは何か

「immutableなコード生成」という言葉から、AIが生成したソースコードを一度作ったら変更できなくすることを想像するかもしれない。しかし、外界へ作用するAI Agentで不変にすべき対象は、通常のアプリケーションコードそのものではない。

不変にすべきなのは、AIが外部のToolやAPIを使って作用する直前に確定する、実行パッケージである。

この実行パッケージは、次のような情報を持つ。

AIは、実行前まで提案を修正できる。しかし、実行パッケージがPolicyによって検査され、署名とハッシュによって固定された後は、AIが宛先、引数、権限、利用Toolを勝手にすり替えられない。

これは、AIを縛るための仕組みではない。AIの自律的な提案と、外界に対する実行責任を分離するための仕組みである。

提案は可変でよい。
しかし、外界に作用する実行は固定され、検証可能でなければならない。

実行の流れ──Permit、Trace、Monitorを分離する

Immutable Agent Executionは、以下の流れで実装できる。

flowchart TD
  A["AI Agent: Plan / Proposal"] --> B["Execution Contract"]
  B --> C["Boundary & Policy Gate"]
  C -->|"Permit"| D["Sign & Hash"]
  D --> E["Isolated Tool Execution"]
  E --> F["External API / System"]
  B --> G["Decision Trace"]
  C --> G
  E --> G
  G --> H["Runtime Monitoring MAS"]
  H -->|"Normal"| I["Continue"]
  H -->|"Anomaly"| J["Throttle / Isolate / Stop"]
  J --> K["Human Escalation"]

ここで重要なのは、Permit、Trace、Monitorを一つのAgentへ集めないことである。

• Permit：事前に定義された境界とPolicyを評価し、実行可能な範囲を決める
• Trace：入力、根拠、判断、実行、結果を記録する
• Monitor：Traceを継続観測し、通常からの逸脱や危険兆候を検知する

実行Agentは、業務上必要な限定権限を持つ。監視Agentは原則として読取専用でTraceを観測する。停止や隔離を行うCoordinatorも、外部業務データを自由に変更する強い権限を持つべきではない。

この職務分離により、実行Agentが自分の行動を自分で正当化する構造を避けられる。

Decision Traceは、監査ログより広い

単なる監査ログは、「誰がいつ何をしたか」を残す。Decision Traceは、それに加えて「なぜその行動が選ばれたのか」を残す。

AI Agentの外部実行では、少なくとも次を記録する必要がある。

こうしたTraceがあれば、インシデント後に「AIが失敗した」と抽象的に言うのではなく、根拠データが古かったのか、権限が広すぎたのか、Policyが不足していたのか、Toolの制約が甘かったのかを分析できる。

Decision Traceは、説明責任のためだけにあるのではない。異常検知、ロールバック、再発防止、ルール改善を可能にする運用データである。

監視の中心は、承認ではなく自律性の調整である

監視中心のガバナンスでは、毎回「実行してよいか」を人が判定しない。Agentが与えられた境界の内側で行動することを許可し、その行動の自由度を観測結果に応じて変える。

Coordinatorが扱うべき状態は、次のように整理できる。

ここでの目的は、Agentに単純な許可／不許可を与えることではない。リスクと観測結果に応じて自律性の水準を動的に制御することである。

監視マルチエージェントという設計

単一の監視AIに全てを見させると、そのAI自体がブラックボックスの統制者になる。そこで監視を役割ごとに分け、複数のAgentが同じTraceを異なる観点から観測する構成が有効になる。

すべてをLLMに判断させる必要はない。むしろ、役割に応じて使い分けるべきである。

• 明確な上限、期限、権限は決定論的ルールで検査する
• 頻度、失敗率、対象の広がりは統計的な異常検知で観測する
• 文書の意味的矛盾や不自然な目的はLLMで補助評価する
• 高リスクの介入とルール変更は人が確認する

監視マルチエージェントのCoordinatorは、「何が正しいか」を最終決定するAIではない。複数の観測結果を統合し、Normal、Observe、Ask、Throttle、Isolate、Stopという運用状態を遷移させる制御面に徹するべきである。

不変性とデータ保持──全データをブロックチェーンに置かない

Traceを改ざんしにくくするために、ハッシュ連鎖、電子署名、追記型ログ、WORMストレージ、外部タイムスタンプ、ブロックチェーンを利用できる。

しかし、「不変だから」といって、プロンプト全文、個人情報、顧客情報、機密データをブロックチェーンや永久保管領域へそのまま置くべきではない。これは保存期間、削除、プライバシー、機密管理と衝突する。

現実的な構成は、データ本体と検証用証跡を分けることである。

削除が必要な場合は、データ本体を削除または暗号鍵を破棄し、Traceには「いつ、どのルールにより削除されたか」という最小限の証跡だけを残す。

ブロックチェーンが特に有効なのは、企業、委託先、監査法人、規制機関など、複数組織が同一の実行証跡を検証する場合である。単一企業内の用途であれば、署名付き追記ログとWORM保管で十分なことも多い。

この方式で防げること、防げないこと

Immutable Agent ExecutionとTrace監視は強力だが、AIの判断が常に正しくなるわけではない。

したがって、これは「AIを正しくする」技術ではない。

AIが何を根拠に、どの権限で、どの外部作用を行ったかを、後から隠せず、観測し、必要なら止められるようにする技術である。

導入の優先順位

最初からブロックチェーンや複雑な監視マルチエージェントを導入する必要はない。外界への作用の強さに応じて、段階的に進めるべきである。

1. Tool権限を最小化する：Agentが使えるAPI、データ、対象、頻度を限定する。
2. Decision Traceを設計する：入力、根拠、判断、実行、結果、版情報を残す。
3. Act／Ask／Stopを定義する：判断・実行の境界と、人へ渡す条件を明確にする。
4. 不変な実行パッケージを導入する：高リスク操作から署名、ハッシュ、期限、制約を付ける。
5. 監視と介入を自動化する：異常行動に対するThrottle、Isolate、Stopを実装する。
6. 監視マルチエージェントへ拡張する：Policy、行動、データ、セキュリティ、結果を役割分担で監視する。
7. 組織横断の証跡共有を検討する：必要な場合にのみ、許可型台帳やブロックチェーンを使う。

おわりに──AIの自律性を止めるのではなく、観測可能にする

AI Agentが外界へ作用する時代に必要なのは、すべての行動を人が承認する仕組みではない。

必要なのは、AIの提案を柔軟に保ちながら、実行を不変な単位として固定し、根拠・権限・結果をTraceし、監視マルチエージェントが逸脱を検知し、必要に応じて自律性を縮小・隔離・停止できる仕組みである。

Permit within Boundary → Trace Everything → Monitor Continuously → Intervene on Anomaly → Learn from Outcome

これは、AIを単に止めるためのガバナンスではない。AIが社会や業務へ安全に参加し、失敗から学びながら、より大きな責任を持てるようにするためのRuntime OSである。

参考資料

• NIST AI Risk Management Framework
• NISTIR 8202: Blockchain Technology Overview
• OWASP: Prompt Injection

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance