> ## 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を使用してAI広告ネットワークが複数のAIプラットフォームにまたがってインベントリを集約する方法 — プロダクトモデリング、アカウントチェーン、カタログフォワーディング、ガバナンス、配信レポート、SI Chat Protocolルーティング。 # 広告ネットワーク 広告ネットワークは、複数のAIプラットフォームにまたがるインベントリを単一のセラーインターフェースに集約します。プロトコルはこのトポロジーをネイティブにサポートしており、ネットワークは自身が所有していない複数のパブリッシャープロパティを代理するセラーエージェントとして機能します。 ## ネットワークの見え方 **バイヤーエージェント**から見ると、ネットワークは標準的なセラーエージェントです。バイヤーはネットワークのMCPサーバーに接続し、標準タスクを通じてカタログやデータをプッシュし、買い付けを実行します。**基盤となるAIプラットフォーム**から見ると、ネットワークはオペレーターだ — 各プラットフォームにアカウントを保有し、バイヤーのカタログデータ、ブランドアイデンティティ、コンテンツ基準を転送します。 ## ネットワークのプロダクトモデリング ネットワークのプロダクトは、`publisher_properties`を使用して複数のAIプラットフォームにまたがることができます： ```json theme={null} { "product_id": "sponsored_response_ai_network", "name": "Sponsored responses - AI assistant network", "description": "Sponsored responses across multiple AI assistants. The network routes to the best-matching platform based on user context and brand relevance.", "channels": ["sponsored_intelligence"], "publisher_properties": [ { "publisher_domain": "assistant-alpha.example.com", "selection_type": "all" }, { "publisher_domain": "assistant-beta.example.com", "selection_type": "all" }, { "publisher_domain": "search-gamma.example.com", "selection_type": "all" } ], "format_ids": [ { "agent_url": "https://ads.ai-network.example.com", "id": "sponsored_response" } ], "delivery_type": "non_guaranteed", "pricing_options": [ { "pricing_option_id": "network_cpc", "pricing_model": "cpc", "floor_price": 0.75, "price_guidance": { "p50": 2.50, "p75": 4.00 }, "currency": "USD", "min_spend_per_package": 1000 } ], "metric_optimization": { "supported_metrics": ["clicks", "engagements"], "supported_targets": ["cost_per"] }, "creative_policy": { "co_branding": "none", "landing_page": "any", "templates_available": true }, "catalog_types": ["product", "offering"] } ``` ネットワークは、コンテキスト、関連性、パフォーマンスに基づいてどのプラットフォームが各インプレッションを配信するかを決定します。バイヤーはどのプラットフォームが選ばれたかを知る必要はなく、ネットワークから統合された配信レポートを受け取ります。 ## ネットワークのアカウントモデル ネットワークは通常、暗黙的なアカウント（`require_operator_auth: false`）を使用します。バイヤーエージェントは信頼され、`sync_accounts`を通じてブランドを宣言します。その後ネットワークは、基盤となる各AIプラットフォームとのアカウントを独自に管理します： ``` Buyer agent -> Network (implicit accounts, agent-trusted) Network -> AI Platform A (explicit accounts, operator auth) Network -> AI Platform B (explicit accounts, operator auth) ``` ケイパビリティは以下のように宣言します： ```json theme={null} { "adcp": { "major_versions": [3] }, "supported_protocols": ["media_buy", "creative"], "account": { "require_operator_auth": false, "supported_billing": ["operator", "agent"], "required_for_products": false, "sandbox": true } } ``` ## カタログフォワーディング ネットワークはバイヤーから`sync_catalogs`を通じてカタログを受け取り、関連するAIプラットフォームに転送します。同じタスクが両方の区間で機能し、ネットワークは各プラットフォームにカタログを同期する際にバイヤーとして機能します。これはコアデータパイプです：ブランドのカタログデータがバイヤーからネットワーク、そしてプラットフォームへと流れ、各プラットフォームが広告を生成するための素材を提供します。 ## ガバナンスとコンテンツ基準 ネットワークはプラットフォームへの転送前に、ルーティング層で[ガバナンスポリシー](/docs/governance/overview)を適用できます。バイヤーがコンテンツ基準をプッシュすると、ネットワークはどのプラットフォームとコンテキストが適格かを選択する際にそれを適用し、その後各プラットフォームにもポリシーを転送してクリエイティブ生成時にも適用されるようにします。これにより、ブランドには2層の適合性適用が提供されます：ネットワークのルーティング決定とプラットフォームの生成制約です。 ## 配信レポート ネットワークは基盤となるプラットフォームからの配信データを集約し、`get_media_buy_delivery`を通じてバイヤーに統合されたレポートを提供します。バイヤーはメディアバイごとに単一の配信レポートを受け取り、ネットワークがプラットフォームごとの内訳を内部で処理します。プラットフォームレベルの透明性を提供したいネットワークは、`reporting_dimensions`を使用してプレースメントレベルの内訳を公開できます。 ## Declaring your network in brand.json ネットワークは、`relationship` フィールドを使って [`brand.json`](/docs/brand-protocol/brand-json) でプロパティを宣言します。これは adagents.json の `delegation_type` と同じ語彙を使い、双方向検証チェーン — プログラマティック広告の `sellers.json` の AdCP 版 — を作ります。 ```json theme={null} { "house": { "domain": "ai-network.example.com", "name": "Example AI Network" }, "brands": [{ "id": "ai_network", "properties": [ { "type": "website", "identifier": "ai-network.example.com", "primary": true }, { "type": "website", "identifier": "assistant-alpha.example.com", "relationship": "delegated" }, { "type": "website", "identifier": "assistant-beta.example.com", "relationship": "delegated" }, { "type": "website", "identifier": "search-gamma.example.com", "relationship": "ad_network" } ], "agents": [{ "type": "sales", "url": "https://ads.ai-network.example.com", "id": "network_sales" }] }] } ``` 委任とネットワークのパスについては、`relationship` フィールドは adagents.json の `delegation_type` と同じ値を使います。`owned` はファーストパーティインベントリのための brand.json のみの relationship です。 | Relationship | Meaning | Example | | -------------- | ---------------------------------------------------------- | ------------------------------- | | `owned`（デフォルト） | このプロパティを所有・運営 | 自身のウェブサイト | | `direct` | このプロパティの直接の販売パス | ベンダーのテクノロジーを使うパブリッシャーの社内広告チーム | | `delegated` | このプロパティのマネタイズを管理 — 担当 | フードブログの広告販売を管理する Mediavine | | `ad_network` | このプロパティのインベントリをネットワークまたはエクスチェンジの一部として販売 — 唯一のパスではなく 1 つのパス | nytimes.com の SSP としての PubMatic | `delegated` と `ad_network` の区別は重要です: 委任関係は、オペレーターがプロパティのマネタイズを担当する（排他的またはほぼ排他的なアクセス）ことを意味します。ad\_network 関係は、オペレーターがインベントリへの潜在的に多くのパスの 1 つであることを意味します。 ### Bilateral verification with adagents.json これは双方向の検証チェーンを作ります — プログラマティックの `sellers.json` + `ads.txt` と同じパターンです。 | File | Who publishes it | What it declares | Programmatic equivalent | | ------------------------ | ---------------- | ---------------------------------- | ----------------------- | | `brand.json`（オペレーター） | ネットワーク/SSP | 「私はこれらのパブリッシャーのために販売する、これがその方法」 | `sellers.json` | | `adagents.json`（パブリッシャー） | 各パブリッシャー | 「このオペレーターのエージェントは認可されている、これが委任タイプ」 | `ads.txt` | 両側が合意しなければなりません。ネットワークは `brand.json` で関係を宣言し、各パブリッシャーは自身の `adagents.json` で一致する `delegation_type` によってネットワークのエージェントを認可することで確認します。片側のみが宣言する場合、関係は不完全です — ネットワークヘルスダッシュボードは、これを認可の欠如（オペレーターは宣言したがパブリッシャーが認可していない）または孤立した認可（パブリッシャーは認可したがオペレーターが宣言していない）としてフラグを立てます。 ## ネットワークのadagents.json ネットワークの[`adagents.json`](/docs/governance/property/adagents)には、自身が所有していないパブリッシャープロパティも含めて、代理するパブリッシャープロパティが列挙されます： ```json theme={null} { "version": "1.0", "properties": [ { "domain": "assistant-alpha.example.com", "agents": [{ "agent_url": "https://ads.ai-network.example.com", "relationship": "direct", "supported_protocols": ["media_buy", "creative"] }] }, { "domain": "assistant-beta.example.com", "agents": [{ "agent_url": "https://ads.ai-network.example.com", "relationship": "direct", "supported_protocols": ["media_buy", "creative"] }] } ] } ``` 基盤となる各AIプラットフォームは、自身の`adagents.json`でネットワークを認可します。バイヤーエージェントは、プラットフォームの認可チェーンを通じてネットワークを発見します。 ## ネットワーク経由のSI Chat Protocol 広告ネットワークがブランドを代理して[SI Chat Protocol](/docs/sponsored-intelligence/si-chat-protocol)セッションを販売する場合、セッションフローの仲介者として機能します。ブランドは`type: "offering"`を指定しました`sync_catalogs`でオファリングをネットワークに同期し、ネットワークがそれを基盤となるプラットフォームに転送します。プラットフォームがセッションをトリガーすると、ネットワークはそれを正しいブランドエージェントにルーティングします。 ``` AI Platform -> Network -> Brand Agent 1. Platform calls si_initiate_session with the network's media_buy_id 2. Network maps media_buy_id to the brand's offering_id 3. Network forwards to the brand agent's SI endpoint 4. Brand agent responds; network relays back to the platform ``` 各区間の主要フィールド： | フィールド | プラットフォームからネットワーク | ネットワークからブランド | | -------------- | --------------------- | ---------------- | | `media_buy_id` | ネットワークのメディアバイID | 異なる場合や省略される場合もある | | `offering_id` | 未設定（プラットフォームは知らない） | ブランド固有のオファリング | | `context` | 会話からのユーザーインテント | そのまま転送 | | `identity` | ユーザーアイデンティティ（同意済みの場合） | そのまま転送 | ネットワークは2区間にまたがるアトリビューション相関を処理します。どのプラットフォームがセッションをトリガーしたか（`placement`）、どのメディアバイが資金提供したか（`media_buy_id`）、どのブランドが応答したか（`offering_id`）を把握しています。これにより、ネットワークは`get_media_buy_delivery`を通じてバイヤーに統合された配信レポートを提供でき、一方で各ブランドエージェントは自身のセッションのみを確認します。 ネットワークは`identity`と`supported_capabilities`を変更せずに転送すべきだ — ブランドエージェントはモダリティを交渉するために正確なホストケイパビリティを必要とし、ユーザーの同意はネットワークではなくブランドに対して付与されているためです。 SI Chat Protocolのセッションライフサイクルとケイパビリティネゴシエーションの詳細については、[SI Chat Protocol](/docs/sponsored-intelligence/si-chat-protocol)と[SIホストの実装](/docs/sponsored-intelligence/implementing-si-hosts)を参照。