本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
draft-hong-ai-agent-communication-00: Agentic AI Communication Protocol (AACP)
【背景と設計目標】
自律的なAIエージェント間の動的な相互作用と、異種プラットフォーム間での意味論的な相互運用性を確保するための共通通信フレームワークの確立。
既存の静的なREST APIやgRPCとは異なり、エージェントの「推論状態」や「タスクの実行権限」を動的に受け渡すプロトコルとして新規設計されています。
【通信シーケンスと動作】
AACPは、Discovery（発見）、Negotiation（交渉）、Execution（実行）、Termination（終了）の4フェーズで構成されます。以下にエージェント間でのタスク委譲シーケンスを示します。
sequenceDiagram
participant "A as Initiator Agent"
participant "B as Target Agent"
participant "R as Semantic Registry"
A ->> R: Discovery (Task Semantic/Capability)
R -->> A: Agent Metadata & Endpoint
A ->> B: Session Initiation (Capability Negotiation)
B -->> A: Capability ACK / Policy Constraints
Note over A,B: Protocol State: NEGOTIATED
A ->> B: Task Delegation (Context + Goal)
loop Reasoning & Execution
B ->> B: Local Inference
B -->> A: Intermediate Status (Progress Update)
end
B ->> A: Result Delivery / Final State
A ->> B: Session Close (Feedback)
【データ構造 / パケットフォーマット】
AACPメッセージは、トランスポート層（TCP/QUIC）上で、JSON-LDまたはCBORを用いた構造化データとして定義されます。以下はメッセージヘッダーと基本フレームの概念図です。
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 (4b) | Message Type (4b) | Reserved (8b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction ID (32b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Agent ID Length (16b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Agent ID (Variable Length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Semantic Payload Length (32b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Semantic Payload (Context, Goals, Constraints) | | (JSON-LD / CBOR encoded) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
【技術的な特徴と比較】
| 特徴項目 | 従来のREST API / gRPC | Agentic AI Comm (AACP) | 備考 |
|---|---|---|---|
| 通信モデル | Request-Response (静的) | Goal-Oriented (動的・自律的) | AACPは目標達成まで状態を維持 |
| セマンティクス | 固定スキーマ (OpenAPI等) | セマンティック記述 (JSON-LD) | 実行時に能力を解釈 |
| 状態管理 | Stateless (基本) | Stateful (推論コンテキスト共有) | 会話履歴や推論過程の同期 |
| 多重化 | HTTP/2 Streams / QUIC | Agent Multi-tenancy | 単一接続で複数エージェントが対話 |
| リアルタイム性 | 高 (固定処理) | 中 (推論レイテンシに依存) | 0-RTT再開による再接続高速化 |
【セキュリティ考慮事項】
Prompt Injection攻撃への耐性: ペイロード内の指示文（Prompt）が受信側エージェントのシステムプロンプトを上書きしないよう、構造化された「指示/データ分離フィールド」の強制。
前方秘匿性 (PFS): QUIC/TLS 1.3をトランスポート層のデフォルトとし、エージェント間の長期的な対話内容を保護。
認可とポリシー制御: OAuth2.1ベースのスコープ定義に加え、エージェントの「推論予算（Token Budget）」を制限する新しい認可フレームワークの導入。
【まとめと実装への影響】
ネットワークエンジニアおよび開発者は、以下の3点に注視する必要があります。
セマンティックルーティングの台頭: IPアドレスやURLではなく、エージェントの「能力（例：Python実行可能）」に基づいた動的なルーティングが必要となり、サービスメッシュ構成が複雑化する。
L7コンテキストの増大: LLMのコンテキストウィンドウの増大に伴い、パケットサイズが従来のHTTPリクエストを大幅に上回る可能性がある。MTU最適化や圧縮アルゴリズムの選定が重要になる。
エージェントIdentityの管理: 人間ではなく「エージェントインスタンス」ごとの証明書管理（mTLS）と、その動的なライフサイクル管理がインフラ側の課題となる。
