Skip to main content
Agent-to-Agent Protocol を使って AdCP を統合するためのトランスポート別ガイドです。タスク処理、ステータス管理、ワークフローパターンは Task Lifecycle を参照してください。

A2A プロトコルバージョン

AdCP は Linux Foundation ガバナンス下の A2A 仕様を追跡します。1.0 ワイヤーフォーマットがターゲットです。v0.3 は依然広くデプロイされており、互換期間中サポートされます。

1.0 で変わったこと

AdCP 自身の統合トップレベル status フィールド(@adcp/sdk が返す)は、引き続き小文字の短縮形("completed""working"、…)を使用します — これは生の A2A status.state に対する AdCP の抽象化であり、A2A ワイヤー値ではありません。

デュアルバージョン互換性

v0.3 と 1.0 の両方のクライアントに提供する必要のあるサーバーは、エージェントカードで両方のインターフェースを宣伝し、トランスポート層で明示的な互換性を有効にします(例: Python SDK の enable_v0_3_compat=True)。後方互換性はデフォルトでは有効になりません 1.0 を話すクライアントは、SDK が下位変換を提供する場合に v0.3 サーバーと通信できます。逆(v0.3 クライアント → 1.0 専用サーバー)はサーバーが互換を有効にする必要があります。

本ガイドの例

以下の例は 1.0 ワイヤーフォーマットkind フィールドなし、ProtoJSON enum)を使用します。v0.3 サーバーの場合、同じ Part は { kind: "text", text: "…" } になり、状態は小文字になります。AdCP 抽出クライアント(A2A レスポンス抽出を参照)は互換期間中に両方の形状を受け入れます。

A2A クライアントのセットアップ

1. A2A クライアントを初期化

2. エージェントカードを確認

3. 最初のタスクを送る

メッセージ構造(A2A 固有)

マルチパートメッセージ

A2A の強みは、テキスト・データ・ファイルを組み合わせたマルチパートメッセージです:

スキル呼び出し方法

自然言語(柔軟)

明示的スキル(決定的)

ハイブリッド(推奨)

ステータス処理: 完全なパターンは Task Lifecycle を参照してください。

A2A レスポンス形式

AdCP 1.6.0 の新機能: すべてのレスポンスに統一ステータスフィールドが含まれます。

標準レスポンス構造

A2A 上の AdCP レスポンスは、タスクレスポンスを含む DataPart(data フィールドを運ぶ Part)を少なくとも 1 つ含める 必要があります。人間向けメッセージの TextPart(text フィールドを運ぶ Part)は 推奨 ですが任意です。
A2A 1.0 ワイヤーフォーマットは kind 判別子を運びません — Part のコンテンツタイプはどのフィールドが設定されているか(textdataurlraw)で暗黙的に決まります。v0.3 のサーバー/クライアントでは、同等の Part に "kind": "text" / "kind": "data" / "kind": "file" が含まれます。 完全な標準仕様は A2A Response Format を参照してください。

A2A 固有フィールド

  • taskId: ストリーミング更新のための A2A タスク ID
  • contextId: A2A プロトコルが自動管理
  • artifacts: テキスト・データを含むマルチパート成果物
  • status: A2A の status.state からマップされる AdCP の統合小文字短縮形(A2A レスポンス抽出を参照)

アーティファクトの処理

DataPart が複数ある場合(ストリーミングなど)は 最後の DataPart を正とします:
レスポンス構造の要件、エラーハンドリング、実装パターンの詳細は A2A Response Format を参照してください。

プッシュ通知(A2A 固有)

A2A では PushNotificationConfig によりプッシュ通知が標準で定義されています。Webhook URL を設定すると、ポーリング不要でサーバーがタスク更新を直接 POST します。

相関: URL ではなくペイロードフィールド

受信する通知は、ペイロードボディの operation_id(および task_type)を使って相関します — pushNotificationConfig.url を解析することは決してしません。URL はサーバーにとって不透明で、相関のワイヤーレベルの真実の源はペイロードフィールドです。完全な規範的ワイヤー契約は Webhooks — Operation IDs and URL templates を参照してください(MCP と A2A の両方に適用されます — アドテックのすべての比較可能な非同期通知プロトコルは URL を発火エンティティにとって不透明にします)。 バイヤーは自身の HTTP サーバーのルーティング補助として operation_id を URL パスやクエリにエンコードしてもよい(MAY)— 多くの Web フレームワークはボディを解析する前にパスセグメントでディスパッチします — が、それはバイヤー側のサーバー設計の選択であり、ワイヤー契約の一部ではありません。バイヤーのサーバールーティングテンプレートはセラーには見えません。セラーはバイヤーが供給した pushNotificationConfig.operation_id フィールドからのみ operation_id を読み、ペイロードでそのままエコーします。 URL テンプレート(バイヤー側のサーバールーティングのみ):
設定例:
Webhook のペイロード形式、プロトコル比較、詳細な処理例は Webhooks を参照してください。

SSE ストリーミング(A2A 固有)

A2A の強みは Server-Sent Events によるリアルタイム更新です: A2A 上でもアプリケーション層のタスクライフサイクルは依然として AdCP が所有します。A2A TasktaskId、SSE、プッシュ通知フレームはトランスポート配信の仕組みです。耐久性のあるビジネスオペレーションは AdCP task_id でキーされる AdCP ペイロードのままです。完了した A2A タスクでも、ペイロードが status: 'submitted' と言う AdCP レスポンスを運ぶことがあります。

タスク監視

リアルタイム更新の例

A2A Webhook ペイロード例

例 1: 完了オペレーションの Task ペイロード タスク完了時、サーバーは A2A 1.0 の StreamResponse エンベロープでラップされた完全な Task オブジェクトを送信します。タスク結果は .artifacts に存在します:
重要: completedfailedrejected ステータスでは、AdCP タスク結果は .artifacts[0].parts[] に必ず入れる必要があります。サーバーがフリーテキストの致命的メッセージのみ(構造化ペイロードなし)を持つ場合、status.message.parts[] にフォールバックしてもよい(MAY)— クライアントは両方を扱います。 A2A 1.0 の StreamResponse oneof は、すべての SSE フレームとプッシュ通知ペイロードを、{ task }{ statusUpdate }{ artifactUpdate }{ message } のちょうど 1 つでラップします(A2A 1.0 §3.2.3、§4.3.3)。tasks/get と v0.3 サーバーからの非ストリーミングレスポンスは素のオブジェクトを配信します。クライアントはフィールドを読む前にアンラップします。 例 2: 進捗更新用 TaskStatusUpdateEvent 実行中の中間ステータス更新では、status.message.parts[] に任意データを含められます。SSE/プッシュフレームはイベントを { "statusUpdate": { … } } としてラップします:
すべてのステータスペイロードは AdCP スキーマを使用します: 最終ステータス(completed/failed)も中間ステータス(working, input-required, submitted)も async-response-data.json に参照がある対応スキーマを持ちます。中間ステータスのスキーマは策定中で将来変更される可能性があるため、実装者は緩めに扱う選択も可能です。

A2A Webhook のペイロード種別

A2A 1.0 仕様に従い、サーバーは StreamResponse oneof でラップした異なるペイロードタイプを送信します: AdCP では主に次の 2 つが多くなります:
  • { task }: 最終結果(completed, failed, rejected
  • { statusUpdate }: 進捗更新(working, input-required, auth-required
クライアントはフィールドを読む前に単一キーのエンベロープをアンラップします。非ストリーミングレスポンス(例: tasks/get)は素のペイロードを配信します — そこでは単一キーエンベロープのアンラップは no-op です。 エンベロープのセマンティクス:
  • { artifactUpdate } フレームは、ブール値フラグ append(名前付きアーティファクトにパートを連結)と lastChunk(最終チャンクを示す)付きの増分アーティファクトチャンクを運びます。ストリームを消費する AdCP クライアントは、これらをターゲットアーティファクトに蓄積し、終端状態の { task } フレームが到着したときに抽出アルゴリズムを適用すべきです(SHOULD)。プッシュ通知を消費するクライアントは通常、すでにマージされた Task オブジェクトを受け取り、個々の artifactUpdate フレームを無視できます。A2A 1.0 §7.3 を参照。
  • { message } フレームは、タスクステータス遷移に紐づかない帯域外のエージェントメッセージです。AdCP はタスク指向です — タスク向けクライアントは素の message エンベロープをログして無視すべきです(SHOULD)。

Webhook が送信される条件

Webhooks are sent when all of these conditions are met:
  1. Task type supports async (e.g., create_media_buy, sync_creatives, get_products)
  2. pushNotificationConfig is provided in the request
  3. Task runs asynchronously — initial response is working or submitted
初回レスポンスがすでに終端(completed, failed, rejected)なら Webhook は送信されません。結果はその場で得られます。 Webhook を送るステータス変化:
  • working → 進捗更新(処理中)
  • input-required → 人による入力が必要
  • auth-required(1.0) → 実行中の再認証チャレンジ
  • completed → 最終結果
  • failed → エラー詳細
  • rejected(1.0) → adcp_error 付きのポリシー/検証拒否
  • canceled → キャンセル確定

データスキーマのバリデーション

A2A Webhook の DataPart data フィールドはステータス別スキーマを使用します: スキーマ参照: async-response-data.json

Webhook ハンドラーの例

コンテキスト管理(A2A 固有)

主要な利点: A2A はコンテキストを自動管理するため、context_id を手動で扱う必要はありません。

自動コンテキスト

明示的コンテキスト(任意)

MCP との違い: MCP の手動 context_id 管理と異なり、A2A はプロトコルレベルでセッション継続を扱います。

マルチモーダルメッセージ(A2A 固有)

A2A の特徴は、1 つのメッセージ内にテキスト・データ・ファイルを組み合わせられることです:

コンテキスト付きクリエイティブアップロード

キャンペーンブリーフ + アセット

利用可能なスキル

すべての AdCP タスクは A2A スキルとして利用できます。確実な実行には明示的な呼び出しを使用してください: タスク管理: 全ドメインにわたる非同期追跡、ポーリングパターン、Webhook 連携の詳細は Webhooks を参照。

スキルの構造

利用可能なスキル

  • Protocol: get_adcp_capabilities (start here to discover agent capabilities)
  • Media Buy: get_products, list_creative_formats, create_media_buy, update_media_buy, sync_creatives, get_media_buy_delivery, provide_performance_feedback
  • Signals: get_signals, activate_signal
タスクパラメータ: 詳細なパラメータ仕様は Media BuySignals を参照してください。

エージェントカード

A2A エージェントは .well-known/agent.json の Agent Card で機能を公開します。

Agent Card の取得

Agent Card 構造の例(A2A 1.0)

1.0 では、v0.3 のトップレベル urlprotocolVersion フィールドが supportedInterfaces 配列に置き換えられます。各エントリは 1 つのトランスポートバインディングとプロトコルバージョンを宣伝します。supportsAuthenticatedExtendedCardcapabilities.extendedAgentCard に移動しました。

v0.3 互換のためのデュアル宣伝

v0.3 から移行するサーバーは両方のインターフェースを宣伝します。クライアントは理解できるバージョンを選びます:
Python SDK サーバーはルート構築時に enable_v0_3_compat=True も渡す必要があります — 後方互換性はデフォルトでは有効になりません。A2A Python SDK 1.0 migration guide を参照してください。

AdCP 拡張

推奨: 実行時の機能発見には get_adcp_capabilities を使用してください。エージェントカードの拡張は、レジストリやディスカバリーサービス向けの静的メタデータを提供します。
extensions 配列に AdCP 拡張を含めることで、プログラム的に AdCP 対応を宣言できます。 A2A プロトコルでは extensions 配列に以下を持つ拡張を列挙します:
  • uri: 拡張の識別子(https://adcontextprotocol.org/extensions/adcp を使用)
  • description: AdCP をどう使うかの説明
  • required: クライアントがこの拡張を必須とするか(AdCP は通常 false
  • params: AdCP 固有の設定(下記スキーマ参照)
Extension Params: v2 では adcp-extension.json スキーマが使われていましたが、v3 で廃止されました。v3 以降のエージェントでは get_adcp_capabilities タスクで実行時に機能を発見してください。上記の params オブジェクトは典型的な構造です。 :::note エージェントカードメタデータの adcp_version フィールドは v2 の慣習であり、v3 スペックの一部ではありません。v3 のバージョンネゴシエーションでは、バイヤーがすべてのリクエストでリリース精度の adcp_version(例: "3.1")を送り、セラーが get_adcp_capabilitiesadcp.supported_versions でサポートするリリースを宣伝し、すべてのレスポンスでエンベロープルートに adcp_version をエコーします。レガシーの整数のみの adcp_major_version フィールドも後方互換性のため依然受け入れられます。完全な契約は versioning.mdx § Version negotiation を参照してください。 ::: メリット:
  • テストコールなしで AdCP 対応状況を発見できます
  • 実装しているプロトコルドメイン(media_buy, creative, signals)を宣言できます
  • バージョンに基づく互換性チェックが可能

統合の例

A2A 固有の考慮点

エラーハンドリング

失敗したタスクは、アーティファクトの DataPartadcp_error キーに構造化された AdCP エラーを格納します。完全な抽出ロジックと復旧動作は Transport Error Mapping を参照してください。

クリエイティブアップロードのエラーハンドリング

For uploading creative assets and handling validation errors, use the sync_creatives task. See sync_creatives Task Reference for complete testable examples. @adcp/sdk ライブラリは A2A アーティファクトの抽出を自動で処理するため、レスポンス構造を手動で解析する必要はありません。

ベストプラクティス

  1. ハイブリッドメッセージ(テキスト + データ + 必要に応じてファイル)を活用
  2. アーティファクト処理前に status フィールド を確認
  3. 長時間処理には SSE ストリーミング でリアルタイム更新
  4. ステータス処理パターンは Core Concepts を参照
  5. 利用可能なスキルと例は エージェントカード で確認

次のステップ

ステータス処理、非同期オペレーション、確認フローについては Task Lifecycle を参照してください。このガイドは A2A トランスポート固有の内容に絞っています。