{ “target_audience”: “network_engineers, ai_system_architects, protocol_developers”, “technical_level”: “advanced”, “status”: “internet_draft_review”, “version”: “0.1”, “tags”: [“IETF”, “Agentic_AI”, “Agent-to-Agent”, “Autonomous_Networking”, “Intent-based”] }

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

IETF Internet-Draft: draft-hong-agent-protocol (Agent-to-Agent Communication Protocol)

【背景と設計目標】

従来のREST/JSONベースのHTTP通信は、静的なAPIエンドポイントを前提としており、自律的に思考・行動するAIエージェント間の「インテント（意図）」や「実行コンテキスト」の動的な同期には不十分です。本プロトコルは、マルチエージェント・システム（MAS）における自律的な交渉、タスクの委譲、および推論プロセスの追跡を可能にする、ステートフルかつセマンティックな通信基盤を新規に定義することを目標としています。

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

エージェント間の「能力発見（Discovery）」から「タスク合意（Negotiation）」までの標準的なシーケンスを以下に示します。

sequenceDiagram
    participant "A as Orchestrator Agent"
    participant "B as Specialist Agent"
    participant "K as Knowledge Base"

    A ->> B: Agent Hello / Capability Query
    B -->> A: Capability Manifest (Manifest-ID)
    Note over A,B: 意図(Intent)の確立
    A ->> B: Task Proposal (Intent-ID, Context-Token)
    B ->> K: Context Verification
    K -->> B: Knowledge Verified
    B -->> A: Proposal Acceptance / Counter-Offer
    Note over A,B: タスク実行とストリーミング同期
    A ->> B: Execute (Stream Enabled)
    B -->> A: Intermediate Reasoning State (Chunked)
    B -->> A: Final Result / Reward Signal

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

本プロトコルは、シリアライズ効率と柔軟性を両立するため、メタデータ部にCBOR（Concise Binary Object Representation）を採用しています。

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) | Type (4b)     | Flags (8b)    | Message ID (16b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Agent ID (32-bit UUID or Hash)                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Destination Agent ID (32-bit UUID or Hash)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Context Token Length (16b)  |     Reserved (16b)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Context Token (Variable Length, e.g., LLM Context State ID) ...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Type (8b) | Payload Length (24b)                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CBOR Encoded Payload (Intent, Reasoning, Task Data)           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

【技術的な特徴と比較】

既存の通信モデルとAgentic AI通信（本提案）の比較です。

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

1. Model Attestation (モデル検証): 通信相手のエージェントが、特定の信頼された基盤モデル（LLM）や重み設定で動作しているかを証明するためのリモートアテステーション機構。

2. Provenance (情報の起源): エージェントが生成した出力の出所を追跡し、ハルシネーションや不正なプロンプト注入（Prompt Injection）の伝播を防ぐためのデジタル署名チェーン。

3. Context Isolation: エージェント間で共有されるコンテキスト・ウィンドウの暗号化。PFS（前方秘匿性）を確保し、過去の推論プロセスが漏洩しても将来のセッションを保護。

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

ネットワークエンジニアおよび開発者が注目すべき点は以下の3点です。

• インテント・ルーティングの台頭: 従来のIPアドレス/ポートベースのルーティングから、エージェントの「能力（Capability）」や「コスト/報酬」に基づいたセマンティック・ルーティングへのシフトが必要になる。

• Long-lived Sessionの再定義: AIの推論には時間がかかるため、TCP/QUICのタイムアウト設計を見直し、長時間存続するセッション（Reasoning Session）の管理がクリティカルになる。

• 監視指標の変換: スループットや遅延に加え、「推論成功率（Reasoning Success Rate）」や「トークン効率」といった新しいQoS指標をネットワーク層で可視化する準備が求められる。