draft-hong-ai-agent-communication-00: Agentic AI Communication Protocol (AACP)

Tech

[Protocol: Agentic AI Communication Protocol (Candidate Draft)] [Status: Individual Submission / IETF 120 Discussion Base] [Draft-Ref: draft-hong-ai-agent-communication-00] [Layer: L7 (Application Layer)] [Keywords: AI Agent, Interoperability, Semantic Discovery, State Synchronization]

本記事は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再開による再接続高速化

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

  1. Prompt Injection攻撃への耐性: ペイロード内の指示文（Prompt）が受信側エージェントのシステムプロンプトを上書きしないよう、構造化された「指示/データ分離フィールド」の強制。

  2. 前方秘匿性 (PFS): QUIC/TLS 1.3をトランスポート層のデフォルトとし、エージェント間の長期的な対話内容を保護。

  3. 認可とポリシー制御: OAuth2.1ベースのスコープ定義に加え、エージェントの「推論予算（Token Budget）」を制限する新しい認可フレームワークの導入。

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

ネットワークエンジニアおよび開発者は、以下の3点に注視する必要があります。

  1. セマンティックルーティングの台頭: IPアドレスやURLではなく、エージェントの「能力（例：Python実行可能）」に基づいた動的なルーティングが必要となり、サービスメッシュ構成が複雑化する。

  2. L7コンテキストの増大: LLMのコンテキストウィンドウの増大に伴い、パケットサイズが従来のHTTPリクエストを大幅に上回る可能性がある。MTU最適化や圧縮アルゴリズムの選定が重要になる。

  3. エージェントIdentityの管理: 人間ではなく「エージェントインスタンス」ごとの証明書管理（mTLS）と、その動的なライフサイクル管理がインフラ側の課題となる。

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました