本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
IETF Draft: draft-zhao-agentic-ai-coordination-00 – Agentic AI Communicationsにおけるエージェント間調整プロトコル（ACP）仕様
【背景と設計目標】
自律型AIエージェント間の意思決定、タスク分散、状況認識共有を、既存のHTTP/RESTやWebSocketを超えて最適化する自律協調通信プロトコルの策定。
本プロトコル（Agent Communication Protocol: ACP）は、HTTP/2やHTTP/3などの汎用アプリケーション層プロトコルの上位（L7セマンティック階層）に位置する、新しい協調動作フレームワークです。従来の密結合なクライアント・サーバ型RPC（gRPCなど）や、静的なPub/Sub（MQTT）とは異なり、LLM（大規模言語モデル）をバックエンドに持つエージェント同士が、動的にタスクを交渉・分散・合意（Negotiation & Consensus）し、ステートフルなコンテキスト共有を行うために新規設計されました。
【通信シーケンスと動作】
ACPにおけるエージェントの発見、ケイパビリティ交渉、タスク合意、およびコンテキスト同期の一連の通信フローを以下に示します。
sequenceDiagram
autonumber
participant "A1 as Initiator Agent (Agent-A)"
participant "Registry as Agent Registry (DNS-SD/CoAP)"
participant "A2 as Target Agent (Agent-B)"
A1 ->> Registry: 1. Discover Capable Agents (Query: Capability="Reasoning")
Registry -->> A1: 2. Resolve Agent-B Endpoint (TLS/ALPN: acp-proto)
A1 ->> A2: 3. Protocol Handshake (Client Hello + Cap-Negotiation)
A2 -->> A1: 4. Handshake Response (Agree on Semantics & Security Policy)
A1 ->> A2: 5. Task Proposal (Agentic-AI Message: Frame ID: 0x01)
Note over A1, A2: Multi-turn State Evaluation & LLM-based Negotiation
A2 ->> A1: 6. Proposal Acceptance & Sub-task Status Update
A1 ->> A2: 7. Commitment (State Sync & Session Close)
通信シーケンスの補足
発見フェーズ:
Agent-AはDNS-SDまたはサービスレジストリを介し、「Reasoning（推論）」や「Code Execution（コード実行）」といった特定のメタデータ属性（ケイパビリティ）を持つエージェントを検出します。ネゴシエーション: ALPN（Application-Layer Protocol Negotiation）識別子
acp-protoを用いて、エージェント間で暗号スイートおよび使用するオントロジー（セマンティック・スキーマ）の合意形成を行います。コミットメント: LLMのマルチターン対話（推論合意）が発生した後に、トランザクションの確証（State Sync）を行い、整合性を保ちます。
【データ構造 / パケットフォーマット】
ACPメッセージの制御ヘッダおよびペイロードカプセル化構造は以下の通りです。
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 | Sequence Number | Offset: 0:32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | Offset: 4:32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Context Session ID | Offset: 8:32 | | Offset: 12:32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Semantic Encoding | Payload Length | Offset: 16:32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload (JSON-LD / CBOR / Protobuf) | Offset: 20:Variable | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HMAC-SHA256 (Integrity & Auth) | Offset: Variable:256 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
各フィールドの定義
Version (8bit): ACPのプロトコルバージョン（例:
0x01）。Message Type (8bit): フレーム種別を定義。
0x01: Discover (発見要求)0x02: Propose (タスク提案)0x03: Counter-Propose (対抗提案/交渉)0x04: Accept/Commit (合意/ステート同期)0x05: Reject/Teardown (拒否/セッション切断)
Sequence Number (16bit): 同一セッション内でのメッセージ順序管理用。TCP/IPとは独立したL7順序保証。
Message ID (32bit): 各トランザクションを一意に識別するためのランダムな値。
Context Session ID (64bit): LLMのコンテキスト（チャット履歴、共有メモリ、DAG型タスクグラフ）を識別するためのセッションID。
Semantic Encoding (16bit): ペイロードの構造化スキーマを指定（例:
0x0001= JSON-LD,0x0002= CBOR-LD,0x0003= Protocol Buffers）。Payload Length (16bit): 可変長ペイロードのサイズ。
【技術的な特徴と比較】
| 評価項目 | ACP (Agent Communication Protocol) | HTTP/3 (gRPC over HTTP/3) | MQTT v5.0 |
|---|---|---|---|
| 主なユースケース | 自律エージェント間の推論・交渉・協調 | マイクロサービス間の高速RPC | IoTデバイスのメッセージング |
| トランスポート層 | QUIC (UDP) / TCP | QUIC (UDP) | TCP (WebSockets) |
| HOL Blocking | 回避（QUICストリーム多重化に依存） | 回避（QUICストリーム多重化） | 発生あり |
| セマンティック統合 | ネイティブ統合 (JSON-LD/Ontology) | なし（未構造のバイナリ/JSON） | なし（バイナリ透過） |
| 状態同期の性質 | ステートフル (LLMコンテキスト連動型) | ステートレス (アプリケーション実装依存) | セッション状態保持のみ |
| 0-RTT/セッション再開 | 対応（QUIC連携 & 以前の推論状態維持） | 対応（TLS 1.3/QUIC 0-RTT） | 限定的（Session Presentのみ） |
| ヘッダ効率 | 非常に高い (可変長セマンティック圧縮) | 中 (HPACK/QPACKによる固定辞書) | 極めて高い (固定ヘッダは数バイト) |
【セキュリティ考慮事項】
1. リプレイ攻撃の防止
自律エージェントの合意形成は、金銭的取引や重要システムのインフラ操作を伴うため、リプレイ攻撃は重大なインシデントに直結します。ACPでは、すべてのハンドシェイクおよびメッセージ内に Epochベースのタイムスタンプ（ミリ秒精度） と、メッセージ送信ごとにインクリメントされる 暗号論的 nonce（使い捨ての乱数） を内包させ、HMAC-SHA256 で署名します。受信側エージェントはスライディングウィンドウを用いて既知の nonce を破棄し、古いパケットの再注入を完全に遮断します。
2. ダウングレード攻撃への耐性
トランスポート層における TLS 1.3 の使用、および ALPN での acp-proto 指定を厳格な要件として定めています。ネゴシエーション時に暗号化されていない平文または TLS 1.2 以前での接続試行、あるいは脆弱な暗号スイート（Null暗号やRC4等）が検知された場合、エージェントは 0x05 (Reject/Teardown) メッセージを送信し、ソケットを即時クローズします。
3. 前方秘匿性（PFS）の確保
鍵交換には、静的な秘密鍵による暗号化を禁止し、ECDHE（楕円曲線ディフィー・ヘルマン一時鍵共有） を強制します。これにより、万が一、将来的に特定の自律エージェントの永続秘密鍵が漏洩した場合でも、過去に遡ってセッション間の通信ログが解読されるリスク（前方秘匿性の喪失）を防止します。
【まとめと実装への影響】
自律型AIエージェントのインフラ構築・統合に携わるネットワークエンジニアおよびシステム開発者は、以下の3つのポイントに留意する必要があります。
L7での「セマンティックパース」によるCPU/メモリ負荷の上昇 ACPはJSON-LDなどのグラフ構造のメタデータを高頻度でパースします。LLMとのコンテキスト統合に伴い、パケット受信時のパース処理（特にCBORデコードとオントロジーのマッピング）がボトルネックとなるため、RustやC++などを用いた低レイヤーでのシリアライズエンジンの採用が必須です。
ステートフルなコンテキスト同期とメモリ管理 エージェント間の交渉は長時間の対話（Long-Running Session）になる傾向があります。セッション維持に伴うLLMのコンテキスト（履歴）保持が必要となるため、ネットワークレイヤーのタイムアウト値（Keep-Alive）を物理接続とは切り離し、仮想的なセッション（Context Session ID）として管理するアーキテクチャ設計が要求されます。
認可トークンの自動更新とガバナンス エージェント間の協調には、OAuth DPoP (Demonstrating Proof-of-Possession) 等を用いた自律的なトークン要求と検証が必要になります。ネットワーク上のエージェントが「本物のエージェント（改ざんされていないコードベース）」であるかを検証するための「リモートアテステーション（Remote Attestation）」の仕組みを、ハンドシェイク時に統合することが将来的な実装フェーズでの鍵となります。
