[Draft] draft-hong-t2trg-ai-agent-coordination-01 : Agentic AI Communications (Agentic Communication Protocol – ACP)

Tech

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

[Draft] draft-hong-t2trg-ai-agent-coordination-01 : Agentic AI Communications (Agentic Communication Protocol – ACP)

【背景と設計目標】

複数のAIエージェントが協調して複雑なタスクを分散処理する際、従来のREST APIやgRPCでは「状態遷移の同期不全」や「セマンティック（意味論的）なミスマッチ」が発生します。本プロトコルは、動的な「意図（Intent）の合意」と「コンテキスト（文脈）の同期」を自律的に行うためのL7アプリケーションプロトコルとして新規設計されました。既存のHTTP/3（QUIC）やCoAPをトランスポート層として再利用しつつ、エージェント間の協調オーバーヘッドを最小化することを目標とします。

【通信シーケンスと動作】

ACP（Agentic Communication Protocol）は、単一の静的リクエスト/レスポンスではなく、協調タスクの完了まで継続する「マルチエージェント・セッション」を確立します。以下に、エージェントA（イニシエータ）がエージェントB（サービスプロバイダ）を発見し、セマンティック合意からタスク実行、状態同期に至るシーケンスを示します。

sequenceDiagram
    autonumber
    participant "AgentA as Agent A (Initiator)"
    participant "AgentB as Agent B (Executor)"

    Note over AgentA, AgentB: Phase 1: Semantic Negotiation & Capability Handshake
    AgentA ->> AgentB: ACP_INIT (Session ID, Semantic Vector Schema)
    AgentB -->> AgentA: ACP_ACK (Supported Intents, Semantic Alignment Matrix)

    Note over AgentA, AgentB: Phase 2: Intent Allocation & Execution
    AgentA ->> AgentB: ACP_INTENT_REQ (Task Intent, Constraints, Context ID)
    AgentB ->> AgentB: Parse & Planning (Local Model Inference)
    AgentB -->> AgentA: ACP_PLAN_PROPOSAL (Task Breakdown, Resource Costs)
    AgentA ->> AgentB: ACP_PLAN_ACCEPT (Execution Token, Session PFS Key)

    Note over AgentA, AgentB: Phase 3: Synchronous Execution & Context Sync
    rect rgb(240, 240, 255)
        AgentB ->> AgentA: ACP_CONTEXT_UPDATE (Intermediate State, Token Metrics)
        AgentA -->> AgentB: ACP_CONTEXT_ACK (Corrective Intent / Keep-Alive)
    end

    Note over AgentA, AgentB: Phase 4: Teardown & Finalization
    AgentB ->> AgentA: ACP_FIN (Execution Result, Context Summary, Signature)
    AgentA -->> AgentB: ACP_CLOSE (Session Destroyed)

動作解説

  1. フェーズ1（メタデータ合意）: ACP_INITにより、相互のLLM（大規模言語モデル）やスモールモデルが理解可能なセマンティック・ベクトル・スキーマ（埋め込み表現の次元数や空間空間情報）をネゴシエーションします。

  2. フェーズ2（意図の合意）: タスクの意図（Intent）と制約（トークン上限、応答時間、セキュリティ境界）を提案。エージェントBはローカルでプランニングを行い、実行計画を提示して合意を形成します。

  3. フェーズ3（継続的状態同期）: タスク実行中、中間コンテキストを「コンテキスト・フレーム」として双方向に高頻度で同期（差分同期）し、ハルシネーションや不整合を動的に補正します。

【データ構造 / パケットフォーマット】

ACPメッセージは、既存のバイナリシリアライゼーション（例：CBORやProtobuf）の上に配置される共通のACPヘッダ（Agentic Communication Header: ACH）を持ちます。以下に、ACHの基本フォーマットを示します。

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Version    |  Message Type |             Flags             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Sequence Number                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                         Session ID (64-bit)                   +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                         Context ID (64-bit)                   +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Semantic Space Type      |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                  Semantic Vector/Schema URI                   +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Payload (CBOR / Protobuf)             ...

フィールド定義

  • Version (8-bit): ACPのプロトコルバージョン。初期ドラフトは 0x01。

  • Message Type (8-bit):

    • 0x01: ACP_INIT (セッション初期化)

    • 0x02: ACP_INTENT_REQ (意図要求)

    • 0x03: ACP_PLAN_PROPOSAL (計画提案)

    • 0x04: ACP_CONTEXT_UPDATE (コンテキスト同期)

    • 0x05: ACP_FIN (正常終了)

  • Flags (16-bit): コントロールフラグ（例: 動的計画変更フラグ、緊急遮断フラグ等）。

  • Sequence Number (32-bit): セッション内のフレーム番号（パケットの再整列、損失検出用）。

  • Session ID (64-bit): 同一のタスクライフサイクルを追跡するためのグローバル一意識別子。

  • Context ID (64-bit): コンテキスト分岐（サブスレッド）を識別するための識別子。

  • Semantic Space Type (16-bit): 使用する埋め込みベクトル空間（例: OpenAI ada-002, Cohere, 自社内製モデル空間等）を定義。

  • Semantic Vector/Schema URI: データのスキーマやセマンティック解釈を記述したメタデータリポジトリへのURI。

【技術的な特徴と比較】

評価項目 gRPC over HTTP/2 REST over HTTP/3 Agentic Communication Protocol (ACP)
トランスポート TCP / TLS QUIC / TLS QUIC (UDP) / TLS 1.3
HOL Blocking (頭部ブロッキング) 発生する (TCPストリーム間) 回避 (QUICストリーム) 回避 (マルチストリームとセマンティック境界の分離)
0-RTTセッション再開 非対応 対応 対応 (過去のセマンティック・コンテキスト状態をキャッシュ再生)
多重化単位 HTTP/2 ストリーム QUIC ストリーム サブタスク / コンテキスト分岐単位
ルーティングパラダイム URI / Path ベース URI / Path ベース セマンティックルーティング (Intent/Vector類似度)
セッションの自律性 静的クライアント・サーバ 静的クライアント・サーバ 自律的ネゴシエーション（P2P協調）

技術的キーワード解説

  • セマンティックルーティング: 物理アドレスや固定URLではなく、「何を実行したいか（意図：Intent）」を表す高次元ベクトルに基づいて、パケットの宛先（最適なAIエージェント）を動的に決定する方式。

  • 0-RTTコンテキスト再生: 一度セッションを切断したエージェント間において、過去の「文脈（コンテキスト・ステート）」をメモリキャッシュから迅速に復元し、再ハンドシェイクの往復遅延を削減する技術。

【セキュリティ考慮事項】

1. 敵対的プロンプト・インジェクションの連鎖（Adversarial Injection Propagation）

エージェントAから受信した「コンテキスト」や「実行結果」に悪意ある命令が埋め込まれていた場合、エージェントBがそれを「命令」として認識・実行してしまう脅威があります。

  • 対策: ACPパーサはセマンティックペイロードを完全に「データプレーン」として隔離し、実行エンジン（LLM等）に入力する前にセマンティックフィルタリング（ガードレール）を強制適用する仕様としています。

2. コンテキスト改ざんとリプレイ攻撃（Context Poisoning / Replay）

中間者が過去のコンテキストフレーム（同期パケット）を傍受し、再送することで、エージェントに同一の重いタスク（例: トークン消費攻撃）を繰り返し実行させるリスク。

  • 対策: Sequence Number と Session ID の組み合わせに対し、TLS 1.3由来の共通鍵を用いたAEAD（Authenticated Encryption with Associated Data）による署名を全フレームに義務付け、前方秘匿性（PFS）を維持した一時セッション鍵をフェーズ2で交換します。

3. ダウングレード攻撃（Downgrade Attacks）

高度な暗号化や強固なセマンティック監査をサポートしていない古いバージョン（ACP v0.1等）に強制的にフォールバックさせ、脆弱性を突く攻撃。

  • 対策: ACP_INITハンドシェイクにおいて、サポートする最低セキュリティポリシーを明記。要件を満たさないセッション要求はトランスポート層で即座にリセット（RST）します。

【まとめと実装への影響】

ネットワークエンジニアおよびシステム開発者が、本ドラフト（ACP）の実装において留意すべきポイントは以下の3点です。

  1. セマンティックゲートウェイの構築設計 従来のL4/L7ロードバランサ（物理IPやURIベース）では、AIエージェントの動的なインテントを判別できません。ベクトルの類似度（コサイン類似度など）を低遅延で判定する「セマンティック・リバースプロキシ（ゲートウェイ）」の配置設計がインフラ側に求められます。

  2. ステートフル・マルチストリーミングの負荷 コンテキストの同期は大量の差分データ（ベクトルやトークン差分）を伴うため、QUICコネクション上でのマルチストリーム制御が極めて重要です。エージェント数に比例してセッション並行数が増大するため、ルータ/ホスト側でのメモリ圧迫に対するレートリミット（Flow Control）設計が不可欠です。

  3. トークン消費（経済的DoS）の防止設計 悪意ある、あるいはバグを抱えたエージェントによる、無限ループ状の「協調プラン交渉」は、急激なAPI利用コストの暴騰（経済的DoS）を招きます。ACPヘッダの「Flags」内に定義される『最大許容トークン/コスト（Max Cost Constraint）』をインフラレベルで常時監視し、閾値超過時に強制切断（ACP_CLOSE）するサーキットブレーカーの実装が必須となります。

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました