{ “version”: “1.0”, “style”: “technical-architect”, “target_audience”: “network-engineers-developers”, “context”: “IETF-Draft-Agentic-AI” }
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
Draft: Agentic AI Communication Framework (draft-peterson-agentic-communications)
【背景と設計目標】
従来のRESTful APIや静的なRPCでは、自律的に思考・行動するAIエージェント間の「動的な意図（Intent）の調整」や「長期的なタスク委任」を効率的に記述できません。本規格案は、非決定的な振る舞いを持つAIエージェント同士が、セマンティックな互換性を維持しつつ、安全かつ構造的に通信するための標準プロトコルスタックの確立を目標としています。
【通信シーケンスと動作】
AIエージェント間の通信は、単純なRequest/Responseではなく、能力の発見（Discovery）から合意形成（Negotiation）、そして非同期の実行状況の報告に至るライフサイクルを持ちます。
sequenceDiagram
participant "A as Originator Agent"
participant D as Directory/Registry
participant "R as Responder Agent"
A ->> D: Agent Discovery (Capability Match)
D -->> A: Candidate List (URI, Model-Spec)
A ->> R: Intent Handshake (Task Proposal)
Note right of R: Policy Check & Resource Allocation
R -->> A: Accept (Contract-ID, Session-Key)
loop Task Execution
R ->> A: Progress Update (Intermediate State)
A ->> R: Feedback / Context Injection
end
R ->> A: Final Result / Objective Attained
A -->> R: Acknowledge & Termination
【データ構造 / パケットフォーマット】
Agentic AI通信では、ペイロードに加えて「推論コンテキスト」や「制約（Constraints）」をヘッダーレベルで管理する必要があります。以下は、カプセル化されたAgentic Messageの概念構造です。
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 (2b) |P(1b)| Reserved (5b) | Message Type (8b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session / Contract ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Capability Hash (SHA-256 Fragment) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Context Length (16b) | Payload Type (16b/CBOR,etc) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Semantic Context (Model Info, Prompt Version) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Agent Task Payload (Intent / Action / Data) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
【技術的な特徴と比較】
既存の通信モデルとAgentic AI通信（提案仕様）の主要な違いを以下に示します。
| 機能特性 | 従来のREST (HTTP/2) | Agentic AI Protocol (Draft) | 備考 |
|---|---|---|---|
| 通信モデル | Request-Response / Stateless | Stateful Intent-based / Async | エージェント間の持続的な対話 |
| 多重化 | ストリーム単位 | タスク/コンテキスト単位 | 1接続内で複数のサブタスクを管理 |
| HOL Blocking | アプリケーション層で発生 | 回避（優先度制御付き非同期転送） | 推論待ち時間による影響を最小化 |
| セマンティック管理 | なし (JSON定義に依存) | プロトコル内でモデル/意図を明示 | モデル間の互換性(LLM spec)を検証可 |
| オーバーヘッド | 低 (バイナリ転送) | 中〜高 (コンテキスト情報を含む) | 意味的整合性のためのメタデータ |
【セキュリティ考慮事項】
意図の改ざん（Intent Injection）: 通信経路でAgentの指示（Prompt）が改ざんされると、予期せぬ行動を誘発します。End-to-Endの署名と、Payload全体の完全性保護が必須です。
リソース枯渇攻撃（Resource Exhaustion）: 無限ループするエージェント間対話による計算リソースの消費を防ぐため、TTL（Time To Live）ならぬ「Total Inference Steps」等の制限フィールドの導入が議論されています。
プライバシーとコンテキスト分離: 送信されるコンテキスト（履歴）に個人情報が含まれるリスクに対し、差分プライバシーを適用したコンテキスト圧縮技術の統合が検討されています。
【まとめと実装への影響】
意味的な相互運用性: 開発者は、単なるエンドポイントのURLだけでなく、エージェントが「理解可能なモデル仕様」と「能力（Capabilities）」を記述したマニフェストファイルを動的に管理する必要があります。
非同期ステートフル管理: 通信が数分〜数時間に及ぶ可能性があるため、ネットワーク機器やプロキシは、HTTPのTimeout概念を超えた「ロングセッション管理」への対応が求められます。
シリアライゼーションの最適化: 巨大なコンテキスト情報を効率的に転送するため、JSONではなくCBORや、セマンティックな差分転送（Context Delta）の実装が推奨されます。
