> ## Documentation Index
> Fetch the complete documentation index at: https://adcp-docs-ja.pier1.co.jp/llms.txt
> Use this file to discover all available pages before exploring further.
# プロトコルアーキテクチャ
> AdCP プロトコルアーキテクチャ: アイデンティティ層（brand、registry、accounts）、取引ドメイン（media buy、creative、signals、sponsored intelligence）、および横断的なガバナンス。
# プロトコルアーキテクチャ
AdCP は複数の層で動作し、ビジネスロール、オーケストレーション、技術的実行のあいだにクリーンな分離を提供します。
## Protocol domain map
### Identity layer
3 つのプロトコルドメインが、いかなる取引が起こる前にも当事者が誰であるかを確立します。
**Brand Protocol** は、`/.well-known/brand.json` にホストされる `brand.json` ファイルを通じて組織アイデンティティを定義します。バイヤーはそれを広告主アイデンティティと認可されたオペレーターに使い、セラーはオペレーターアイデンティティ、セールスエージェントディスカバリー、署名鍵ディスカバリー、プロパティ関係宣言に使います。任意のドメインは正準なブランドアイデンティティに解決できます。[Brand Protocol](/docs/brand-protocol) を参照。
**Registry** は、エンティティ解決とエージェントディスカバリーのためのパブリックな REST API を提供します。ブランドドメインを解決し、どのエージェントがパブリッシャーのインベントリを販売する認可を受けているかを見つけ、またはケイパビリティでエージェントを発見します。[Registry API](/docs/registry) を参照。
**Accounts** は、バイヤーとセラーのあいだの商業的関係を確立します。すべての AdCP 取引は、課金条件、オペレーター認可、使用量レポートを定義するアカウント内で起こります。アカウントは Brand Protocol のブランドアイデンティティに根ざしています。[Accounts Protocol](/docs/accounts/overview) を参照。
### Transaction domains
4 つのプロトコルドメインがコアの広告操作を扱います。[Trusted Match Protocol（TMP）](/docs/trusted-match) は実行層として機能し、4 フェーズのライフサイクルを通じて計画時の決定をリアルタイムのアクティベーションに接続します:
1. **Planning** — `get_products` と `create_media_buy` がパッケージ、予算、ターゲティング基準を確立する。
2. **Execution** — TMP Context Match がコンテンツ適合を判定し、TMP Identity Match がユーザー適格性をチェックする。両操作は構造的プライバシー分離のもとで配信時に実行される。
3. **Engagement** — Sponsored Intelligence セッションが会話的なブランド体験を提供する。
4. **Reporting** — `get_media_buy_delivery` がセラーをまたいで配信データを集約する。
**Media Buy** は、インベントリディスカバリー（`get_products`）、キャンペーン作成（`create_media_buy`）、配信レポート（`get_media_buy_delivery`）をカバーします。パブリッシャーは、価格、ターゲティングオプション、配信予測を含む構造化されたメディアプロダクトを返します。バイヤーはプロポーザル — パブリッシャーの専門知識をエンコードした構造化メディアプラン — をリクエストできます。[Media Buy](/docs/media-buy) を参照。
**Creative** は、フォーマットディスカバリー（`list_creative_formats`）、AI 駆動のクリエイティブ生成（`build_creative`）、カタログ同期（`sync_catalogs`）、クリエイティブ配信トラッキングを扱います。クリエイティブエージェントは Brand Protocol からブランドアイデンティティを解決し、オンブランドのアセットを生成します。[Creative](/docs/creative) を参照。
**Signals** は、オーディエンスとターゲティングデータのディスカバリー（`get_signals`）とアクティベーション（`activate_signal`）を可能にします。データプロバイダーはシグナル定義を公開し、バイヤーは自然言語クエリでそれを発見し、決定プラットフォーム上でアクティベートできます。[Signals](/docs/signals/overview) を参照。
**Sponsored Intelligence** は、AI アシスタントにおける会話的なブランド体験を定義します。ユーザーがブランドへの関心を表明すると、ホストは同意優先のセッションを開始し、そこでブランドのエージェントがテキスト、音声、UI コンポーネント、またはコマースハンドオフで会話的に関与します。[Sponsored Intelligence](/docs/sponsored-intelligence/overview) を参照。
### Governance (cross-cutting)
**Governance** はすべての取引ドメインを横断して動作します。ガバナンスエージェントは、プロパティリスト（ターゲティングや除外のためのプロパティのキュレーションされた集合）、コンテンツ標準（ブランド適合性ポリシー）、クリエイティブガバナンス（セキュリティスキャン、コンテンツ分類）を管理します。ガバナンスデータは、メディアバイの決定、クリエイティブ検証、シグナルアクティベーションに流れ込みます。[Governance Protocol](/docs/governance/overview) を参照。
Human-in-the-loop は 2 つのメカニズムを通じてプロトコルに入ります: 任意の変更はタスクライフサイクルを通じて人間のレビューのために非同期にでき、キャンペーンガバナンスは `sync_plans` と `check_governance` を通じて宣言的なバイヤー側のレビューチャネルを提供します。[How human-in-the-loop enters the protocol](/docs/governance/embedded-human-judgment#how-human-in-the-loop-enters-the-protocol) を参照。これはリアルタイムプロトコルではありません: 人間の承認が必要なとき、操作は数分から数日かかることがあります。
### Privacy posture across domains
AdCP のプライバシー姿勢は一様ではありません。TMP は、プライバシーを**構造的に**強制する唯一のドメインです — 分離されたコードパス、アイデンティティとコンテキストの結合に対するスキーマレベルの禁止、独立に検証可能な相関除去を通じて。他のすべてのドメインは**契約的機密性またはセッションごとの同意**に依存します — データを交換する当事者は、プロトコルレベルの分離ではなく、アカウントの条件やユーザーの同意に拘束されます。ガバナンスゲーティング（キャンペーンガバナンス経由）は直交します: それは予算、ポリシー、ブランドセーフティの根拠で人間の承認を要求できますが、基底のドメインのプライバシーメカニズムを変えません。
| Domain | Privacy mechanism | Notes |
| --------------------------- | ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Trusted Match Protocol | **構造的分離** | Context Match と Identity Match は分離されたコードパスで動作し、スキーマがクロスオーバーを禁止する。[TMP privacy architecture](/docs/trusted-match/privacy-architecture) を参照。 |
| Media Buy | 契約的 | バイヤーとセラーはアカウント条件のもとで完全なプラン文脈を交換する。 |
| Creative | 契約的 | クリエイティブアセットとターゲティングシグナルは、アカウント条件のもとでクリエイティブエージェントを通過する。 |
| Signals | 契約的 | オーディエンスとシグナルデータは、アカウント条件とシグナルプロバイダー契約のもとで交換される。 |
| Brand / Registry / Accounts | 公開または契約的 | ブランドアイデンティティは公開（`brand.json`）、商業条件はアカウントスコープ。 |
| Sponsored Intelligence | 同意優先 | ユーザーはセッションごとに同意する。ブランドエージェントは会話内容を見、アイデンティティはユーザーが共有したときのみ見る。セッションをルーティングするネットワークはルーティングメタデータを見ることがある — [Networks](/docs/sponsored-intelligence/networks) を参照。 |
| Governance | 契約的 | ガバナンスエージェントは、アカウント条件のもとでポリシーを評価するのに必要な文脈を受け取る。 |
「構造的」とは、オペレーターのポリシーではなくプロトコルが、機微データの結合を防ぐことを意味します。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 ドキュメント](/docs/trusted-match) を参照。
**Agentic eXecution Engine（AXE）** — TMP の非推奨の前身。[AXE ドキュメント](/docs/media-buy/advanced-topics/agentic-execution-engine) を参照。
**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](/docs/governance/embedded-human-judgment#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](/docs/building/by-layer/L2/account-state) を参照。
**許容されるストレージ:** Postgres、Redis、DynamoDB、またはプロセス再起動をまたいで永続化し、すべてのレプリカから到達可能な任意の共有ストア。**許容されないもの:** モジュールレベル変数、プロセスごとの Map や dict、単一ノードのファイルストレージ、または共有状態の欠如を隠すスティッキーセッションルーティング。
単一の `(brand, account)` コンテキスト内で、実装はレプリカをまたいだ read-your-writes をサポートしなければなりません（MUST）: 成功した非同期でないレスポンスの後、任意のレプリカにルーティングされた後続リクエストは、その書き込みを観測しなければなりません（MUST）。非同期/保留中のタスク状態（ステータス遷移、`context_id`、プッシュ通知サブスクリプション）自体もこのルールの対象です — タスクレコードが作成されたら、任意のレプリカから読み取り可能でなければなりません（MUST）。結果整合性は、古さのウィンドウが有界かつ開示されているとき許容されます — 実装が文書化した非同期ポーリング間隔に上限が設けられるか、`get_adcp_capabilities` で明示的に宣言されるかのいずれか。
**サンドボックス免除。** サンドボックスアカウントは、プロセス再起動をまたいで永続化しない一時的な状態を運ぶことが許されます（[サンドボックスモード](/docs/media-buy/advanced-topics/sandbox) を参照）。単一のサンドボックスセッション内では、レプリカをまたいだ read-your-writes は依然として適用されます。
実装は、この不変条件をアーキテクチャ（マネージドサーバーレス + 共有データストア）、マルチインスタンス適合性テスト、または独自の検証によって証明してもかまいません。プロトコルは方法論ではなく不変条件を気にします。[Validate your agent — Verifying cross-instance state](/docs/building/validate-your-agent#verifying-cross-instance-state) を参照。