本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
IETF Draft: Agentic AI Communications Protocol (AACP) – 自律エージェント間通信の要件定義
【背景と設計目標】
現在、LLM（大規模言語モデル）をベースとした自律型エージェントの普及により、エージェント間（Agent-to-Agent）の動的な連携が急増しています。しかし、既存のHTTP/RESTやgRPCは、静的なAPI定義に依存しており、エージェントが持つ「意図（Intent）」や「推論の不確実性」を扱うには不十分です。本規格（AACP）は、エージェント間のセマンティックな相互運用性を確保し、ゴール共有、能力交渉、実行の監視を標準化することを目的とした新規設計のフレームワークです。
【通信シーケンスと動作】
AACPは、ステートフルなセッション管理を行い、エージェント間の「合意形成（Negotiation）」フェーズを重視します。
sequenceDiagram
autonumber
participant "OA as Orchestrator Agent"
participant "WA as Worker Agent (Expert)"
Note over OA, WA: Session Establishment (TLS 1.3/QUIC)
OA ->> WA: Capability Discovery (Intent: "Solve Optimization Problem")
WA -->> OA: Capability Manifest (Tools, Model-Ver, Latency, Cost)
rect rgb(240, 240, 240)
Note over OA, WA: Negotiation Phase
OA ->> WA: Proposed Goal & Constraint (Budget, Reliability Threshold)
WA -->> OA: Confirmation & Task Plan (DAG-based)
end
OA ->> WA: Execute (Trigger)
loop Step Execution
WA ->> WA: Local Reasoning / Tool Use
WA -->> OA: Intermediate Status / Token Stream
end
WA -->> OA: Final Result & Verifiable Proof
OA ->> WA: Termination / Feedback
【データ構造 / パケットフォーマット】
AACPパケット（メタデータ部）は、LLMが解釈しやすいセマンティックヘッダーと、バイナリ転送効率を重視したペイロードで構成されます。
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=1| Type(4b) | Flags (8b) | Session ID (16 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Intent Code (16 bits) | Payload Length (16 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Semantic Context Hash (SHA-256 / First 128 bits) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | JSON-LD Payload (Variable Length: Capability/Goal/State) | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HMAC-Tag / Signature (Variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
【技術的な特徴と比較】
| 特徴 | HTTP/2 (Conventional) | AACP (Agentic Communications) |
|---|---|---|
| 主要な交換対象 | 生データ (JSON/Binary) | 意図 (Intent) と 推論コンテキスト |
| 相互運用性 | 事前定義されたAPIスキーマ | 動的な能力宣言 (Capability Manifest) |
| 多重化 | ストリームレベルの多重化 | 推論ブランチ単位のセマンティック多重化 |
| 接続性 | クライアント/サーバモデル | ピアツーピア (Orchestrator-Worker) |
| 不確実性管理 | リトライ/タイムアウト | 確信度(Confidence Score)に基づく再交渉 |
【セキュリティ考慮事項】
Hallucination Injection（ハルシネーション注入）: 悪意のあるエージェントが偽の推論結果を返し、オーケストレーターの意思決定を歪める攻撃への耐性。解決策として、実行証明（Proof of Execution）の添付が検討されています。
Resource Exhaustion (Recursive Loop): エージェント同士が無限にタスクを委譲し合い、計算リソースやトークンを枯渇させる攻撃。これを防ぐため、パケットヘッダーに
TTL (Time to Live)ならぬMax-Reasoning-Depthを導入します。PFS (Perfect Forward Secrecy): TLS 1.3をベースとし、セッションキーの漏洩が過去の推論コンテキストに影響しない設計を継承します。
【まとめと実装への影響】
ネットワークエンジニアや開発者が留意すべき3つのポイント：
APIからインテントへ: 従来の「どのURLを叩くか」ではなく、「どの意図を伝えるか」を抽象化するライブラリ実装が必要になります。
L7以上の可視化: AACPはセマンティックハッシュを用いるため、従来のIDS/IPSでは「正常な推論」と「異常な推論」の区別が困難です。エージェントゲートウェイでの深層検疫が必須となります。
トークン消費の予測可能性: 通信量よりも「推論コスト（トークン数）」が課金やQoSの指標となるため、ネットワーク管理に「AIコンピュート・コスト」の概念が統合される可能性があります。
