AI Trust Review
関係者限定プレビューです。
パスワードを入力してください。
記事カオスマップフレームワーク規制・法令 無料相談
トップ / 記事一覧 / MCP / Agentic AI
MCP / Agentic AI

A2A時代のエージェント間Trust設計—エージェントが他エージェントを呼ぶときに崩れる4つの前提

2026.05.29 | AITB編集部

2025 年後半から 2026 年にかけて、AI エージェント実装は「人間 → エージェント → ツール」という 1 段モデルから、「人間 → A → B → C → ツール」という**多段委譲モデル**に急速に移行している。Google の A2A プロトコル、Anthropic の Sub-agents、各社のオーケストレーション層の標準化が同時並行で進み、エージェント同士が互いを「ツール」として呼び出すアーキテクチャが現実になった。だが、ここで前回扱った MCP の JIT 権限付与だけでは解けない **4 つの新しい問題**が立ち上がる。本記事では A2A 通信で崩れる前提を整理し、OAuth on-behalf-of の応用パターン、監査連鎖の設計、暴走遮断のサーキットブレーカーまで、実装視点で踏み込む。

1. A2A 通信が一般化する背景

エージェント実装は、2024 年までは「単一エージェントが MCP を経由して外部ツールを叩く」モデルが主流だった。2025 年後半以降、これが次のように変質した：

結果として、「ある業務リクエストを処理するためのコールチェーン」が 3 段・4 段に伸びる実装が日常になった。問題はここからだ。

2. 多段委譲で崩れる 4 つの前提

MCP のスコープクリープ議論（前回記事）では、1 段の「エージェント → ツール」の関係でも RBAC が破綻することを示した。A2A では、これに加えて以下 4 つの前提が崩れる。

前提① 身元証明：呼ばれたエージェントは「誰の依頼か」を本当に知れるか

下流エージェント B から見ると、自分を呼んだのは上流エージェント A だ。しかし、本当に責任を負うべきは A の背後にいる人間ユーザー（Alice）である。

Alice → Agent A → Agent B → CRM
                 ↑
                 ここでBが見えるのは「Aの認証情報」だけ
                 Aliceの存在は構造化されていない

「Alice の依頼」であることを B が 暗号学的に検証可能な形で知らない限り、B は誤った権限判定をする。これは OAuth における Confused Deputy 問題の AI 版だ。

前提② 権限委譲：上流の権限はどこまで継承される（されない）べきか

Alice → A → B → C のチェーンで、各段は次のいずれかを取りうる：

パターン 内容 リスク
完全継承 A の権限をそのまま B に渡す スコープ過剰、横展開で爆発
縮退委譲 A は B に「必要な分」だけ渡す 実装が複雑、忘却で機能不全
再認可 B が改めて Alice に同意を取る UX 破壊
専用権限 B 自体が独自の権限を持つ A 経由の意図と分離してしまう

RBAC は「主体ごとに静的」を前提とするため、この 4 択を動的に切り替える表現力を持たない。

前提③ 監査連鎖：チェーン全体を 1 つのトレースとして残せるか

問題発生時にトレースしたいのは「Alice の発話 → A の解釈 → B への依頼 → C への依頼 → CRM へのアクセス」の 一本のストーリーだ。

しかし実装上は、各エージェントが独立にログを吐く。trace_id が伝播していなければ、事後の調査でチェーンを復元できない。これは AI-SPM や SIEM の側で監査する場合の致命傷になる。

前提④ 暴走遮断：チェーンの途中で異常を検知して遮断できるか

A2A は再帰呼び出しを構造的に許す。プロンプトインジェクションが 1 箇所で成功すると、

これらをチェーンの途中で止める仕組みが要る。エンドポイントの WAF では遅すぎる。

3. 設計パターン：OAuth on-behalf-of の A2A 応用

幸い、この問題はゼロから設計し直す必要はない。OAuth 2.0 の Token Exchange（RFC 8693） と act クレーム、そして on-behalf-of フローを素直に拡張すれば実装できる。

基本構造：actor token のチェーン化

各段で発行されるトークンに、**直接の actor（呼び出し元エージェント）と究極の主体（人間ユーザー）**を分離して埋め込む。

{
  "iss": "ai-secure-gateway.example.com",
  "sub": "user:alice@example.com",
  "act": {
    "sub": "agent:contract-reviewer-v2",
    "act": {
      "sub": "agent:legal-orchestrator-v1"
    }
  },
  "intent": {
    "action": "fetch_contract",
    "contract_id": "K-2026-0571"
  },
  "scope": ["read:contract:K-2026-0571"],
  "trace_id": "trc-2026-05-29-9f3a",
  "parent_request_id": "req-2026-05-29-7b21",
  "depth": 3,
  "max_depth": 5,
  "iat": 1780012800,
  "exp": 1780012830
}

ポイント：

Token Exchange の実フロー（3 段の例）

Step 1: Alice → Gateway
  Alice が Orchestrator(A) を呼び出すための初期トークンを発行
  sub=alice, act=null, scope=最大スコープ

Step 2: A → Gateway → B
  A は B を呼ぶ前に Token Exchange でトークンを再発行
  sub=alice, act={sub: agent:A}, scope=Bに渡す最小スコープ, intent=B用に再宣言

Step 3: B → Gateway → C(MCP/CRM)
  B も同様に再発行
  sub=alice, act={sub: agent:B, act: {sub: agent:A}}, scope=さらに絞る, intent=C用に再宣言

各段で Gateway を必ず経由する点が肝。直接 A から B にトークンをパススルーさせると、scope の縮退と intent の再宣言が忘れられがちになる。

4. A2A 監査ログの設計

A2A の監査では「3 点セット」を必ず残す：

フィールド 役割
trace_id チェーン全体で共通。Alice の 1 リクエストに対応
parent_agent_id 直接の呼び出し元。チェーン構造の復元に必須
intent（各段独立） 各段で何のために呼んだか。意図のドリフト検出に使う

チェーン可視化のサンプル

trace_id: trc-2026-05-29-9f3a
└─ [depth=0] user:alice  intent={request:"今期の契約更新可否を整理して"}
   └─ [depth=1] agent:legal-orchestrator  intent={action:"fan_out_review"}
      ├─ [depth=2] agent:contract-reviewer  intent={action:"review", contract_id:K-2026-0571}
      │  └─ [depth=3] mcp:crm  intent={action:"fetch_contract", contract_id:K-2026-0571}
      └─ [depth=2] agent:risk-checker  intent={action:"assess_risk", contract_id:K-2026-0571}
         └─ [depth=3] mcp:risk-db  intent={action:"lookup", entity:"counterparty-X"}

この粒度でログが残っていれば、事後に「Alice の発話に対して、結局どのデータが触られたか」を 1 本のストーリーで再現できる。AI-SPM 側（AI-SPM アーキテクチャ記事）でこの形のログを集約する前提で設計する。

検出したい逸脱パターン

5. 暴走遮断：サーキットブレーカーの設計

A2A の遮断は、ネットワーク機器の WAF ではなく Gateway 層の論理ブレーカーとして実装する。最低限、次の 4 つを持つ：

  1. 深さブレーカー：depth > max_depth で即遮断（デフォルト 5）
  2. 回数ブレーカー：同一 trace_id 内の総 API 呼び出し回数に上限（デフォルト 50）
  3. コストブレーカー：同一 trace_id 内の累積トークン消費に上限（金額換算で運用）
  4. スコープ拡大率ブレーカー：チェーンを下って scope が広がる呼び出しは原則拒否

これらは「正常系を妨げない」よう、最初はアラートのみ・後段で自動遮断、という二段運用が現実的だ。

6. 実装チェックリスト

A2A 通信を導入する設計レビューで確認する項目：

7. 3 軸評価との接続

AITB の 3 軸評価フレームワーク の文脈で、A2A 案件は次のように整理できる：

軸 A2A で問うこと
Technology チェーンが安定して完走するか／レイテンシ・コストが許容範囲か／障害が局所化されるか
Business Value マルチエージェント化で本当に価値が増えているか（単一エージェントで足りない明確な理由があるか）
Trust 上記 4 前提（身元・委譲・監査・遮断）が設計レベルで解かれているか

特に Trust 軸では、A2A は「単一エージェントよりリスクが連鎖的に拡大する」という構造的な不利を持つ。本当に多段化が必要か、まず単一エージェントで実装し、必要になった時点で A2A 化するという順序を推奨したい。

8. 始めかた

すべてを一気にやる必要はない。次の順序が現実的：

  1. 既存の A2A 呼び出しを棚卸し（意図せず多段化している箇所がないか）
  2. trace_id と parent_agent_id をログに残す（最小投資で監査連鎖が立ち上がる）
  3. depth / max_depth の導入（暴走遮断の最小実装）
  4. Gateway 経由化と Token Exchange の段階導入（高リスク経路から順に）
  5. スコープ縮退の自動化と監査ダッシュボード化

DataSign の AI MONBAN は、JIT 権限付与（前回記事）と A2A チェーン監査をひとつの Gateway 上で統合して扱う設計を取っており、上記 1〜5 を段階的に載せていける。とはいえ製品選定の前に、まず trace_id を残すことから始めれば、自社にとって何が足りていないかが見えるはずだ。

関連：MCP サーバーのスコープクリープ問題 は本記事の前提となる 1 段モデルの議論。AI-SPM 実装アーキテクチャ では A2A のチェーンログを集約する基盤側の設計を扱っている。AITB の 3 軸評価フレームワーク では、Trust 軸の中で本記事のチェック観点を必須項目として運用する。A2A を含むエージェント案件のレビュー希望は 無料相談 よりお問い合わせください。