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 の強みは、テキスト・データ・ファイルを組み合わせたマルチパートメッセージです:スキル呼び出し方法
自然言語(柔軟)
明示的スキル(決定的)
ハイブリッド(推奨)
A2A レスポンス形式
AdCP 1.6.0 の新機能: すべてのレスポンスに統一ステータスフィールドが含まれます。標準レスポンス構造
A2A 上の AdCP レスポンスは、タスクレスポンスを含む DataPart(data フィールドを運ぶ Part)を少なくとも 1 つ含める 必要があります。人間向けメッセージの TextPart(text フィールドを運ぶ Part)は 推奨 ですが任意です。
kind 判別子を運びません — Part のコンテンツタイプはどのフィールドが設定されているか(text、data、url、raw)で暗黙的に決まります。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 固有)
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 テンプレート(バイヤー側のサーバールーティングのみ):
SSE ストリーミング(A2A 固有)
A2A の強みは Server-Sent Events によるリアルタイム更新です: A2A 上でもアプリケーション層のタスクライフサイクルは依然として AdCP が所有します。A2ATask、taskId、SSE、プッシュ通知フレームはトランスポート配信の仕組みです。耐久性のあるビジネスオペレーションは AdCP task_id でキーされる AdCP ペイロードのままです。完了した A2A タスクでも、ペイロードが status: 'submitted' と言う AdCP レスポンスを運ぶことがあります。
タスク監視
リアルタイム更新の例
A2A Webhook ペイロード例
例 1: 完了オペレーションのTask ペイロード
タスク完了時、サーバーは A2A 1.0 の StreamResponse エンベロープでラップされた完全な Task オブジェクトを送信します。タスク結果は .artifacts に存在します:
completed、failed、rejected ステータスでは、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": { … } } としてラップします:
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:- Task type supports async (e.g.,
create_media_buy,sync_creatives,get_products) pushNotificationConfigis provided in the request- Task runs asynchronously — initial response is
workingorsubmitted
completed, failed, rejected)なら Webhook は送信されません。結果はその場で得られます。
Webhook を送るステータス変化:
working→ 進捗更新(処理中)input-required→ 人による入力が必要auth-required(1.0) → 実行中の再認証チャレンジcompleted→ 最終結果failed→ エラー詳細rejected(1.0) →adcp_error付きのポリシー/検証拒否canceled→ キャンセル確定
データスキーマのバリデーション
A2A Webhook の DataPartdata フィールドはステータス別スキーマを使用します:
スキーマ参照:
async-response-data.json
Webhook ハンドラーの例
コンテキスト管理(A2A 固有)
主要な利点: A2A はコンテキストを自動管理するため、context_id を手動で扱う必要はありません。
自動コンテキスト
明示的コンテキスト(任意)
マルチモーダルメッセージ(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
エージェントカード
A2A エージェントは.well-known/agent.json の Agent Card で機能を公開します。
Agent Card の取得
Agent Card 構造の例(A2A 1.0)
1.0 では、v0.3 のトップレベルurl と protocolVersion フィールドが supportedInterfaces 配列に置き換えられます。各エントリは 1 つのトランスポートバインディングとプロトコルバージョンを宣伝します。supportsAuthenticatedExtendedCard は capabilities.extendedAgentCard に移動しました。
v0.3 互換のためのデュアル宣伝
v0.3 から移行するサーバーは両方のインターフェースを宣伝します。クライアントは理解できるバージョンを選びます: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 固有の設定(下記スキーマ参照)
adcp-extension.json スキーマが使われていましたが、v3 で廃止されました。v3 以降のエージェントでは get_adcp_capabilities タスクで実行時に機能を発見してください。上記の params オブジェクトは典型的な構造です。
:::note
エージェントカードメタデータの adcp_version フィールドは v2 の慣習であり、v3 スペックの一部ではありません。v3 のバージョンネゴシエーションでは、バイヤーがすべてのリクエストでリリース精度の adcp_version(例: "3.1")を送り、セラーが get_adcp_capabilities の adcp.supported_versions でサポートするリリースを宣伝し、すべてのレスポンスでエンベロープルートに adcp_version をエコーします。レガシーの整数のみの adcp_major_version フィールドも後方互換性のため依然受け入れられます。完全な契約は versioning.mdx § Version negotiation を参照してください。
:::
メリット:
- テストコールなしで AdCP 対応状況を発見できます
- 実装しているプロトコルドメイン(media_buy, creative, signals)を宣言できます
- バージョンに基づく互換性チェックが可能
統合の例
A2A 固有の考慮点
エラーハンドリング
失敗したタスクは、アーティファクトのDataPart の adcp_error キーに構造化された AdCP エラーを格納します。完全な抽出ロジックと復旧動作は Transport Error Mapping を参照してください。
クリエイティブアップロードのエラーハンドリング
For uploading creative assets and handling validation errors, use thesync_creatives task. See sync_creatives Task Reference for complete testable examples.
@adcp/sdk ライブラリは A2A アーティファクトの抽出を自動で処理するため、レスポンス構造を手動で解析する必要はありません。
ベストプラクティス
- ハイブリッドメッセージ(テキスト + データ + 必要に応じてファイル)を活用
- アーティファクト処理前に status フィールド を確認
- 長時間処理には SSE ストリーミング でリアルタイム更新
- ステータス処理パターンは Core Concepts を参照
- 利用可能なスキルと例は エージェントカード で確認
次のステップ
- Core Concepts: ステータス処理とワークフローは Task Lifecycle を参照
- Task Reference: Media Buy Tasks と Signals
- Protocol Comparison: MCP integration と比較
- Examples: 完全なワークフロー例は Core Concepts に掲載