オーケストレーターの役割
オーケストレーターは複数の AdCP エージェントに接続し、それら全体でクリエイティブワークフローを調整するバイヤーサイドのシステムです。クリエイティブプロトコル自体を実装するのではなく、それを消費します。典型的なオーケストレーターにはエージェンシープラットフォーム（ホールディングカンパニーの内部ツールチェーンを想像します）、ブランドサイドのクリエイティブハブ、マルチパブリッシャーキャンペーン管理システムが含まれます。 オーケストレーターの責任:- 接続されている各エージェントが何をできるかを発見する
- クリエイティブリクエストを最も適したエージェントにルーティングする
- 完成したクリエイティブを必要なすべてのセラーに配布する
- エージェント全体の配信データを単一のレポートビューに集計する
ケイパビリティ発見
リクエストをルーティングする前に、オーケストレーターは各エージェントがサポートしているもののマップが必要です。接続されているすべてのエージェントでget_adcp_capabilities を呼び出し、各レスポンスの creative セクションをインデックス化します。
このマップをキャッシュして定期的に更新する — ケイパビリティレスポンスの
last_updated フィールドはエージェントのケイパビリティが最後に変更された時刻を示します。
エージェント全体のフォーマット発見
各エージェントでlist_creative_formats を並行して呼び出す。各エージェントは formats 配列を返し、各フォーマットにはそのフォーマット定義を所有するエージェントを識別する agent_url を持つ format_id が含まれます。
format_id の agent_url がそれらを区別します。ルーティング時には、リクエストに最もよく一致するケイパビリティを持つエージェントを優先する（ブリーフには生成エージェント、タグ取得にはライブラリエージェント）。
一部のエージェントは、オーケストレーターがクエリできる追加エージェントを指す creative_agents 配列も返します。これらの参照をたどって、接続リストにまだないエージェントからフォーマットを発見するが、無限ループを避けるために訪問済みの URL を追跡します。
クリエイティブリクエストのルーティング
ケイパビリティマップとフォーマットカタログを使用して、各リクエストを適切なエージェントにルーティングします。 既存のクリエイティブがないブリーフ — ブランドチームがクリエイティブの方向性を提供するがアセットがない。supports_generation: true のエージェントにルーティングします。エージェントは build_creative を通じて自然言語ブリーフを受け取り、生成されたアセットを含むマニフェストを返します。
既存のクリエイティブのリサイズが必要 — バイヤーがあるフォーマットのマニフェストを持ち、別のフォーマットに適応する必要があります。supports_transformation: true のエージェントにルーティングします。既存の creative_manifest と希望する出力の target_format_id を渡します。
広告サーバーからタグを取得 — クリエイティブがすでにプラットフォームライブラリに存在します。それをホストする has_creative_library: true のエージェントにルーティングします。creative_id と target_format_id を build_creative に渡して配信タグを取得します。
ターゲットフォーマットがエージェントを決定する — リクエストが特定のフォーマット（CTV、DOOH、パブリッシャー独自のユニット）をターゲットにする場合、format_id.agent_url が一致するエージェントにルーティングします。そのエージェントがそのフォーマットの権威であり、最も信頼性の高い出力を生成します。
複数のエージェントが条件を満たす場合、ケイパビリティを組み合わせたエージェントを優先します。supports_generation: true と has_creative_library: true を持つセールスエージェントは、クリエイティブを生成してワンステップで保存できるため、別の同期が不要になります。
一度ビルドして多くに配布します
コアとなるマルチエージェントワークフロー: クリエイティブを一度生成またはビルドして、必要なすべてのセラーに配布します。ステップ 1: クリエイティブをビルドします
クリエイティブエージェントでbuild_creative を呼び出してマニフェストを作成する:
creative_id を割り当てる — この ID はクリエイティブをどこに送っても一貫しています。
ステップ 2: 各セラーに同期します
各セールスエージェントで同じcreative_id と concept_id を使用して sync_creatives を呼び出す:
creative_id（acme_holiday_300x250）と concept_id（concept_holiday_2026）を使用します。これらは後でクロスエージェント相関のキーになります。
ステップ 3: 承認状態を追跡します
各セラーはクリエイティブを独立してレビューします。各エージェントでlist_creatives をポーリングしてステータスを確認します:
status フィールドは現在の位置を示します: processing、pending_review、approved、rejected、archived。統合されたビューを構築する:
クリエイティブはあるセラーには承認され、別のセラーには拒否される場合がある — 各セラーは独自のポリシーを適用します。ステータス遷移の仕組みについてはクリエイティブレビューを参照。
クロスエージェント配信集計
クリエイティブがライブになったら、各エージェントでget_creative_delivery を呼び出してパフォーマンスデータを収集します。レスポンスにはバリアントレベルのブレークダウンを含む creatives 配列が含まれます:
エージェント間の相関
creative_id は主な相関キーです。各セラーに同期する際に同じ creative_id を割り当てたため、エージェント間の配信レコードを直接マッチできます。
concept_id は関連するクリエイティブをグループ化します。すべてのサイズとセラー間で “Holiday 2026” キャンペーンの集計メトリクスが必要な場合、各エージェントの list_creatives で concept_ids でフィルタリングして creative_id 値のセットを取得し、すべての配信データをプルします。
variant_id は単一のエージェントとクリエイティブにスコープされます。2つのエージェントが独立して同じ variant_id 文字列を割り当てる場合があります。エージェント間でバリアントを集計する際は、エージェント URL をプレフィックスとして付けてグローバルに一意なキーを作成する: https://sales.pinnaclemedia-example.com/var_a1b2c3。
タイムゾーンの正規化
各エージェントはreporting_period.timezone を通じて独自のタイムゾーンでレポートします。エージェント間でメトリクスを合計する前に、すべてのタイムスタンプを共通のタイムゾーンに変換します。timezone フィールドは IANA 識別子（America/New_York、Europe/London、UTC）を使用するため、標準のタイムゾーンライブラリが変換を処理します。
相関キーとしての concept_id
コンセプトはバイヤーが割り当てたグループ化 — プロトコルはそれらを強制しません。オーケストレーターがコンセプトを構成するものを決定し、関連するクリエイティブを異なるエージェントに同期する際に concept_id を一貫して割り当てる。
典型的なマッピング: キャンペーンアイデアごとに1つのコンセプト、コンセプトごとに複数のクリエイティブ（異なるサイズ、フォーマット、またはバリエーション）。
sync_creatives の各クリエイティブの concept_id フィールドを通じて同期時に concept_id を割り当てる。使用方法:
concept_idsでlist_creativesをフィルタリングして特定のエージェントのコンセプト内のすべてのクリエイティブを確認します- ロールアップレポートのためにコンセプトで
get_creative_delivery結果をグループ化します - 同じキャンペーンアイデアのサイズとセラー全体の承認状態を追跡します
エージェント全体のエラー処理
マルチエージェント操作は部分的な失敗を生む。あるセラーがクリエイティブを受け入れ、別が拒否する場合や、エージェントが一時的に到達不能になる場合があります。最初からこれに対応して設計します。部分的な同期失敗
sync_creatives はクリエイティブごとの結果を返します。レスポンスの各アイテムの action フィールドを確認します:
creatives の代わりにトップレベルの errors がある場合、操作全体が失敗した（認証、ネットワーク、無効なリクエスト）。呼び出し全体を再試行します。
成功した操作内で個々のクリエイティブが失敗した場合、個別に処理する — 問題を修正して、creative_ids フィルターを使用して失敗したクリエイティブのみを再同期する:
エージェントの到達不能
エージェントが到達不能な場合、オーケストレーターは以下を行うべきだ:- どの同期またはクエリが失敗したか、どのエージェントで失敗したかを記録します
- 他のエージェントの処理を続行する — ワークフロー全体をブロックしません
- 失敗したエージェントを指数バックオフで再試行します
- 再試行が安全であるよう
sync_creativesでidempotency_keyを使用します
一致しない承認状態
あるセラーで承認され別のセラーで拒否されたクリエイティブはエラーではなく正常です。オーケストレーターはこれを失敗として処理するのではなく、キャンペーンチームに明確にサーフェスするべきです。拒否が修正可能な問題（間違いなアスペクト比、クリック URL の欠如）によるものであれば、クリエイティブを更新して拒否したセラーのみに再同期します。レート制限と並行処理
多数のエージェントを並行して呼び出す場合（クロスセラー同期と配信集計で一般的）、エージェントがリクエストをレート制限する可能性があることを想定します。標準的な HTTP パターンでこれを処理します:429 Too Many RequestsレスポンスとRetry-Afterヘッダーを尊重します- ジッターを含む指数バックオフを再試行に使用します
- エージェントごとに合理的な並行処理制限を設定する（エージェントあたり 5 つの並行リクエストから始め、観察された動作に基づいて調整します）
- どのエージェントが低い並行処理が必要かを特定するために、エージェントごとのレート制限イベントをログに記録します
Retry-After ヘッダー付きの 429 を返す場合があります。その他は明示的なシグナルなしにレスポンスを遅らせる場合があります。オーケストレーターは両方のパターンを処理するように構築します。
特化フォーマットのオーケストレーション
このページのパターンはすべてのクリエイティブフォーマットに適用される — ディスプレイ、ビデオ、CTV、会話型、オーディオ、DOOH。プロトコルレベルの操作（list_creative_formats、sync_creatives、get_creative_delivery）はフォーマットタイプに関わらず同一に機能します。フォーマット固有の違いはアセット要件とプレビュー動作にある:
- CTV フォーマットはマルチレンダープレビュー（プライマリビデオ + コンパニオン）を生成します。CTV とコネクテッド TV を参照。
- 会話型フォーマットはサンドボックステスト用にプレビューで
interactive_urlを返し、バリアントマニフェストには会話トランスクリプトが含まれます。会話型フォーマットを参照。 - フィードネイティブ/ソーシャルフォーマットは、レンダリング時にバイヤーアセットをラップするプラットフォーム所有のクロームを持ちます。パターン 4 を参照。
format_id.agent_url とケイパビリティマップがそれを処理します。フォーマット固有の知識は、キャンペーンチームに表示するためにプレビューと配信データを解釈する際にのみ重要です。
次のステップ
- オーケストレーター設計パターン — マルチエージェントシステムのステートマシン、永続性、リトライパターン
- クリエイティブライブラリとコンセプト — 単一エージェントのライブラリでのクリエイティブ管理
- セールスエージェントのクリエイティブ機能 — セラーがメディアとクリエイティブの両方を管理する場合
- 生成クリエイティブ — AI 駆動のクリエイティブ生成ワークフロー
- 仕様 — 完全なクリエイティブプロトコル仕様とインタラクションモデル