プロトコルアーキテクチャ
AdCP は複数の層で動作し、ビジネスロール、オーケストレーション、技術的実行のあいだにクリーンな分離を提供します。Protocol domain map
Identity layer
3 つのプロトコルドメインが、いかなる取引が起こる前にも当事者が誰であるかを確立します。 Brand Protocol は、/.well-known/brand.json にホストされる brand.json ファイルを通じて組織アイデンティティを定義します。バイヤーはそれを広告主アイデンティティと認可されたオペレーターに使い、セラーはオペレーターアイデンティティ、セールスエージェントディスカバリー、署名鍵ディスカバリー、プロパティ関係宣言に使います。任意のドメインは正準なブランドアイデンティティに解決できます。Brand Protocol を参照。
Registry は、エンティティ解決とエージェントディスカバリーのためのパブリックな REST API を提供します。ブランドドメインを解決し、どのエージェントがパブリッシャーのインベントリを販売する認可を受けているかを見つけ、またはケイパビリティでエージェントを発見します。Registry API を参照。
Accounts は、バイヤーとセラーのあいだの商業的関係を確立します。すべての AdCP 取引は、課金条件、オペレーター認可、使用量レポートを定義するアカウント内で起こります。アカウントは Brand Protocol のブランドアイデンティティに根ざしています。Accounts Protocol を参照。
Transaction domains
4 つのプロトコルドメインがコアの広告操作を扱います。Trusted Match Protocol（TMP） は実行層として機能し、4 フェーズのライフサイクルを通じて計画時の決定をリアルタイムのアクティベーションに接続します:- Planning —
get_productsとcreate_media_buyがパッケージ、予算、ターゲティング基準を確立する。 - Execution — TMP Context Match がコンテンツ適合を判定し、TMP Identity Match がユーザー適格性をチェックする。両操作は構造的プライバシー分離のもとで配信時に実行される。
- Engagement — Sponsored Intelligence セッションが会話的なブランド体験を提供する。
- Reporting —
get_media_buy_deliveryがセラーをまたいで配信データを集約する。
get_products）、キャンペーン作成（create_media_buy）、配信レポート（get_media_buy_delivery）をカバーします。パブリッシャーは、価格、ターゲティングオプション、配信予測を含む構造化されたメディアプロダクトを返します。バイヤーはプロポーザル — パブリッシャーの専門知識をエンコードした構造化メディアプラン — をリクエストできます。Media Buy を参照。
Creative は、フォーマットディスカバリー（list_creative_formats）、AI 駆動のクリエイティブ生成（build_creative）、カタログ同期（sync_catalogs）、クリエイティブ配信トラッキングを扱います。クリエイティブエージェントは Brand Protocol からブランドアイデンティティを解決し、オンブランドのアセットを生成します。Creative を参照。
Signals は、オーディエンスとターゲティングデータのディスカバリー（get_signals）とアクティベーション（activate_signal）を可能にします。データプロバイダーはシグナル定義を公開し、バイヤーは自然言語クエリでそれを発見し、決定プラットフォーム上でアクティベートできます。Signals を参照。
Sponsored Intelligence は、AI アシスタントにおける会話的なブランド体験を定義します。ユーザーがブランドへの関心を表明すると、ホストは同意優先のセッションを開始し、そこでブランドのエージェントがテキスト、音声、UI コンポーネント、またはコマースハンドオフで会話的に関与します。Sponsored Intelligence を参照。
Governance (cross-cutting)
Governance はすべての取引ドメインを横断して動作します。ガバナンスエージェントは、プロパティリスト（ターゲティングや除外のためのプロパティのキュレーションされた集合）、コンテンツ標準（ブランド適合性ポリシー）、クリエイティブガバナンス（セキュリティスキャン、コンテンツ分類）を管理します。ガバナンスデータは、メディアバイの決定、クリエイティブ検証、シグナルアクティベーションに流れ込みます。Governance Protocol を参照。 Human-in-the-loop は 2 つのメカニズムを通じてプロトコルに入ります: 任意の変更はタスクライフサイクルを通じて人間のレビューのために非同期にでき、キャンペーンガバナンスはsync_plans と check_governance を通じて宣言的なバイヤー側のレビューチャネルを提供します。How human-in-the-loop enters the protocol を参照。これはリアルタイムプロトコルではありません: 人間の承認が必要なとき、操作は数分から数日かかることがあります。
Privacy posture across domains
AdCP のプライバシー姿勢は一様ではありません。TMP は、プライバシーを構造的に強制する唯一のドメインです — 分離されたコードパス、アイデンティティとコンテキストの結合に対するスキーマレベルの禁止、独立に検証可能な相関除去を通じて。他のすべてのドメインは契約的機密性またはセッションごとの同意に依存します — データを交換する当事者は、プロトコルレベルの分離ではなく、アカウントの条件やユーザーの同意に拘束されます。ガバナンスゲーティング（キャンペーンガバナンス経由）は直交します: それは予算、ポリシー、ブランドセーフティの根拠で人間の承認を要求できますが、基底のドメインのプライバシーメカニズムを変えません。
「構造的」とは、オペレーターのポリシーではなくプロトコルが、機微データの結合を防ぐことを意味します。TMP の外でそのプロパティが必要なら、自分で構築するか TMP と合成してください。
Ecosystem layers
上のプロトコルドメインマップは、AdCP タスクが互いにどう関係するかを示します。下の図は、これらが現実世界のロールとシステムにどうマップするかを示します。
Business parties
Buy side — 特定のユースケース向けにインベントリとデータをパッケージングする広告主、代理店、リテールメディアネットワーク、キュレーター。 Media seller — パブリッシャー、セールスハウス、レップファーム、SSP、アドネットワーク。 これらの当事者は、オーケストレーション層を通じてインプレッションとお金を交換します。Orchestration layer
Media orchestration platform — セラーとオーディエンスを評価し、購買戦略を実行する。MCP 経由で専門エージェントと通信する。 Signals agent — オーディエンスとターゲティングデータのディスカバリーとアクティベーションを公開する MCP サーバー。 Sales agent — メディアプロダクトディスカバリーとキャンペーン実行を公開する MCP サーバー。 Creative agent — フォーマットディスカバリーと AI 駆動のクリエイティブ生成を公開する MCP サーバー。Technical execution
Trusted Match Protocol（TMP） — 特定のインプレッションに対してどの事前交渉済みパッケージがアクティベートすべきかを判定するリアルタイム実行層。2 つの構造的に分離された操作 — Context Match（コンテンツ適合）と Identity Match（ユーザー適格性） — が、計画時のメディアバイを、web、モバイル、CTV、AI アシスタント、リテールメディアをまたぐ配信時の決定に接続する。TMP ドキュメント を参照。 Agentic eXecution Engine（AXE） — TMP の非推奨の前身。AXE ドキュメント を参照。 Decisioning platform — 直接キャンペーンまたはプログラマティック（RTB）を通じて、どの広告を配信するかを選択するインフラ。例には DSP、SSP、アドサーバーが含まれる。Governance and human oversight
Governance agents は、すべての層にわたってコンプライアンスと品質管理を提供します: プロパティリスト、ブランド適合性スコアリング、品質測定（MFA スコア、広告密度）、プライバシーコンプライアンス（COPPA、TCF、GDPR）。これらはセットアップ時、リアルタイム、ポストビッドで動作します。 Human-in-the-loop — 決定ポイントでの手動承認。How human-in-the-loop enters the protocol を参照。State persistence and horizontal scaling
AdCP はマルチインスタンスプロトコルです。エージェントとの単一バイヤーのワークフローは、複数のバックエンドレプリカにまたがってルーティングされることがあります —create_media_buy が 1 つのレプリカに着地し、後続の get_media_buy が別のレプリカに着地する — そして両方の呼び出しは同じ状態を見なければなりません（MUST）。
Normative requirements
(brand, account) タプルでキー付けされた状態は、エージェントプロセスインスタンスをまたいで生き残らなければなりません（MUST）。これには、アカウント、カタログ、クリエイティブ、オーディエンス、イベントソース、ガバナンス設定、アクティブキャンペーン、プロポーザル、インサーションオーダー承認レコード、シグナルアクティベーション、sponsored-intelligence セッション、非同期タスクレコード、冪等性キーキャッシュエントリが含まれますが、これらに限りません。実装は、後続の呼び出しが読み戻せる任意の (brand, account) スコープの状態のプライマリストアとして、プロセス内メモリを使ってはなりません（MUST NOT）。プロセス内ストレージはこの要件を満たしません。状態ドメインの正準な（網羅的でない）カタログについては Account state を参照。
許容されるストレージ: Postgres、Redis、DynamoDB、またはプロセス再起動をまたいで永続化し、すべてのレプリカから到達可能な任意の共有ストア。許容されないもの: モジュールレベル変数、プロセスごとの Map や dict、単一ノードのファイルストレージ、または共有状態の欠如を隠すスティッキーセッションルーティング。
単一の (brand, account) コンテキスト内で、実装はレプリカをまたいだ read-your-writes をサポートしなければなりません（MUST）: 成功した非同期でないレスポンスの後、任意のレプリカにルーティングされた後続リクエストは、その書き込みを観測しなければなりません（MUST）。非同期/保留中のタスク状態（ステータス遷移、context_id、プッシュ通知サブスクリプション）自体もこのルールの対象です — タスクレコードが作成されたら、任意のレプリカから読み取り可能でなければなりません（MUST）。結果整合性は、古さのウィンドウが有界かつ開示されているとき許容されます — 実装が文書化した非同期ポーリング間隔に上限が設けられるか、get_adcp_capabilities で明示的に宣言されるかのいずれか。
サンドボックス免除。 サンドボックスアカウントは、プロセス再起動をまたいで永続化しない一時的な状態を運ぶことが許されます（サンドボックスモード を参照）。単一のサンドボックスセッション内では、レプリカをまたいだ read-your-writes は依然として適用されます。
実装は、この不変条件をアーキテクチャ（マネージドサーバーレス + 共有データストア）、マルチインスタンス適合性テスト、または独自の検証によって証明してもかまいません。プロトコルは方法論ではなく不変条件を気にします。Validate your agent — Verifying cross-instance state を参照。