> ## 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. # AI エージェントへのインベントリ提供 > AdCP セラー統合ガイド。パブリッシャー、SSP、広告プラットフォームが標準化されたプロダクト発見とメディアバイタスクを通じて AI バイヤーエージェントにインベントリを公開する方法。 AI エージェントがメディアを購入し始めています。エージェンシーの AI アシスタントが複数のプラットフォームにわたって広告インベントリを評価するとき、何を販売しているかを発見し、価格設定とターゲティングオプションを理解し、購入を実行する方法が必要だ — すべて標準インターフェースを通じて。 AdCP（Ad Context Protocol）はそのインターフェースを提供します。パブリッシャー、SSP、または広告プラットフォームであれば、AdCP を実装することで、各バイヤーエージェントのカスタム統合を必要とせずに、任意の準拠バイヤーエージェントがインベントリにアクセスできるようになります。 ## なぜ重要か今日、すべてのプラットフォームはバイヤーが独自の API を学ぶことを必要とします。人間が購入を行う場合はそれで機能します。しかし AI エージェントは多くのプラットフォームを同時に横断して動作し、一般的な操作のための共通言語が必要です。 AdCP を実装したプラットフォームは、バイヤーエージェントによって即座に発見可能です。実装していないプラットフォームは各バイヤーがカスタム統合を構築する必要があり、インベントリにアクセスできるエージェントのプールが制限されます。 ## 実装する必要があるもの AdCP セルサイド統合には3つのパートがある: ### パブリッシャー認可を公開します各パブリッシャードメインに `adagents.json` ファイルを公開します。このファイルはパブリッシャーのプロパティと、そのインベントリの販売またはエンリッチを認可されたエージェントを宣言する — サプライチェーンの透明性において `ads.txt` が機能する方法に似ています。 ```json theme={null} { "$schema": "https://adcontextprotocol.org/schemas/v3/adagents.json", "contact": { "name": "Example Publisher", "email": "adops@publisher.example.com", "domain": "publisher.example.com" }, "properties": [ { "property_id": "publisher_home", "property_type": "website", "name": "Example Publisher", "publisher_domain": "publisher.example.com", "identifiers": [{ "type": "domain", "value": "publisher.example.com" }] } ], "authorized_agents": [ { "authorization_type": "property_ids", "url": "https://ads.publisher.example.com/mcp", "authorized_for": "Example Publisher direct inventory", "property_ids": ["publisher_home"], "signing_keys": [ { "kid": "publisher-sales-prod-2026", "kty": "OKP", "alg": "EdDSA", "crv": "Ed25519", "x": "w8zcY1LZqV4n1oKbfyq3n2q3sL2uV3z7kEw1m9Qjv4A", "use": "sig" } ] } ] } ``` バイヤーエージェントは `adagents.json` を確認してパブリッシャー認可を検証し、変更系のセラー認可についてはパブリッシャーがピン留めした署名鍵を検証します。エージェントのプロトコルカバレッジは `adagents.json` からではなく `get_adcp_capabilities` から発見します。 ### オペレーターアイデンティティを公開しますセールスエージェントを運用する組織のために、`https://{your-domain}/.well-known/brand.json` に `brand.json` を公開します。`adagents.json` はどのパブリッシャーがセールスエージェントを認可するかをバイヤーに伝えます。`brand.json` はどのオペレーターが販売パスを主張しているか、どのプロパティを代表するか、署名鍵をどこで見つけるかをバイヤーに伝えます。パブリッシャー所有のセールスチームの場合、所有または直接のプロパティをリストします。ネットワークや SSP の場合、`relationship: "delegated"` または `relationship: "ad_network"` で代表するプロパティをリストし、その値がパブリッシャーの `adagents.json` の `authorized_agents[].delegation_type` と一致することを確認します。2 つのファイルは双方向の検証チェーンを形成します。オペレーターは「私はこのプロパティを販売する」と宣言し、パブリッシャーは「このオペレーターはそれを販売する認可を持つ」と確認します。販売を委任するパブリッシャーも `adagents.json` を公開すべきです。自身の `brand.json` はパブリッシャーアイデンティティとポートフォリオコンテキストのために推奨されますが、委任されたオペレーターの `brand.json` が、バイヤーが呼び出すエージェントの必須のアイデンティティレコードです。直販パブリッシャーと委任ネットワークの例を含む完全なセルサイドセットアップパターンは、[seller setup](/docs/brand-protocol/seller-setup) を参照してください。 ```json theme={null} { "$schema": "https://adcontextprotocol.org/schemas/v3/brand.json", "version": "1.0", "id": "example_publisher", "url": "https://publisher.example.com", "names": [{ "en_US": "Example Publisher" }], "properties": [ { "type": "website", "identifier": "publisher.example.com", "relationship": "owned" } ], "agents": [ { "type": "sales", "url": "https://ads.publisher.example.com", "id": "publisher_sales", "jwks_uri": "https://ads.publisher.example.com/.well-known/jwks.json" } ] } ``` `agents[].jwks_uri` によりバイヤーはあなたの公開署名鍵を解決できます。プロトコルは検証可能な署名と発見可能な公開鍵を要求します。特定の KMS ベンダーは要求しません。本番エージェントは秘密署名鍵を KMS/HSM またはマネージドシークレットシステムでバックアップすべきです。AdCP Webhook を送るセラーは、バイヤーがアウトバウンド Webhook 署名を検証できるよう、その JWKS に `adcp_use: "request-signing"` JWK を公開すべきです。非推奨の `adcp_use: "webhook-signing"` 鍵は後方互換性のため Webhook パスで受け入れられ続けます。鍵公開と Webhook 署名プロファイルは [request signing](/docs/building/by-layer/L1/request-signing) を参照してください。 ### インベントリを公開します `get_products` を実装して販売内容を記述します。各プロダクトは購入可能なユニットを表す — ディスプレイプレースメント、ビデオスロット、スポンサードリスティング、ニュースレタースポンサーシップなど。バイヤーエージェントは `buying_mode` とオプションの `brief` でこれを呼び出す: ```json theme={null} { "buying_mode": "brief", "brief": "Premium display placements for consumer electronics brand" } ``` レスポンスには価格、フォーマット、デリバリータイプを含む構造化されたプロダクトオブジェクトが含まれます: ```json theme={null} { "products": [ { "product_id": "homepage_leaderboard", "name": "Homepage leaderboard", "channels": ["display"], "format_ids": [ { "agent_url": "https://ads.publisher.example.com", "id": "display_728x90" } ], "pricing_options": [ { "pricing_option_id": "cpm_standard", "pricing_model": "cpm", "floor_price": 8.00, "currency": "USD" } ] } ] } ``` プロダクトメタデータが充実しているほど、バイヤーエージェントはキャンペーン要件にインベントリをより適切にマッチさせることができます。ポッドキャスト、CTV、ライブイベントなどのコンテンツ中心のインベントリでは、プロダクトはショーを参照し、独占性を提供できる: ```json theme={null} { "products": [ { "product_id": "signal_noise_sponsorship", "name": "Signal & Noise — Category Sponsorship", "description": "Category-exclusive sponsorship of the Signal & Noise podcast, including pre-roll and mid-roll host read placements.", "shows": [{ "publisher_domain": "crestnetwork.example.com", "show_ids": ["signal_noise"] }], "publisher_properties": ["crestnetwork_podcast"], "channels": ["podcast"], "placements": [ { "placement_id": "pre_roll", "name": "Pre-roll (30s)" }, { "placement_id": "host_read", "name": "Mid-roll host read (60s)" } ], "delivery_type": "guaranteed", "exclusivity": "category", "format_ids": [ { "agent_url": "https://ads.publisher.example.com", "id": "audio_30s" } ], "pricing_options": [ { "pricing_option_id": "flat_monthly", "pricing_model": "flat_rate", "fixed_price": 15000, "currency": "USD" } ] } ] } ``` 完全なコンテンツモデルについては[ショーとエピソード](/docs/media-buy/product-discovery/collections-and-installments)を、独占性パターンについては[メディアプロダクト](/docs/media-buy/product-discovery/media-products#exclusivity)を参照。 ### バイを受け入れて実行します `create_media_buy` を実装してバイヤーエージェントからのキャンペーン指示を受け入れる。メディアバイにはプロダクト、予算、スケジュール、ターゲティングパラメーターが含まれます。 ```json theme={null} { "account": { "account_id": "acct-56789" }, "brand": { "brand_id": "nova-electronics" }, "proposal_id": "prop-homepage-leaderboard", "total_budget": { "amount": 10000, "currency": "USD" }, "start_time": "2026-04-01T00:00:00Z", "end_time": "2026-04-30T23:59:59Z" } ``` プラットフォームは通常のワークフローに従ってバイを処理する — 即時活性化、内部レビュー、または承認キューのいずれであっても。AdCP の非同期ステータスシステム（`completed`、`working`、`submitted`、`input-required`）により、あらゆるワークフローをモデル化できます。 ## 業種別ガイダンス上記のコア統合ステップはすべてのセラーに適用されます。**複数のプラットフォームにわたって集約する広告ネットワーク**の場合は、プロダクトモデリング、アカウントチェーン、カタログフォワーディング、ネットワーク向け `adagents.json` について[広告ネットワークの詳細ガイド](/docs/sponsored-intelligence/networks)を参照。垂直固有のプロダクトモデリング、価格設定パターン、測定については: * **AI プラットフォームと AI 広告ネットワーク**: スポンサードレスポンス、AI 検索プロダクト、カタログからの生成クリエイティブ、SI チャットプロトコルハンドオフについては[スポンサードインテリジェンスガイド](/docs/sponsored-intelligence/overview)を参照。 * **リテールメディアネットワーク**: スポンサードプロダクトリスティング、クローズドループアトリビューション、店内測定については[コマースメディアガイド](/docs/media-buy/commerce-media)を参照。 ## アカウントとサンドボックス本番セールスエージェントはアカウントプロトコルを実装すべきです。[`sync_accounts`](/docs/accounts/tasks/sync_accounts) と [`list_accounts`](/docs/accounts/tasks/list_accounts) により、バイヤーが請求関係を確立し、広告主ごとの支出を追跡し、単一エージェントを通じて異なるブランドのために購入する複数のオペレーターを管理できます。アカウントモデルはプラットフォームによって異なる: * **ウォールドガーデン**（ソーシャルプラットフォーム、AI プラットフォーム、リテールメディアネットワーク）は通常、明示的なアカウントを使用する — 各オペレーターが独立して認証するように [`get_adcp_capabilities`](/docs/protocol/get_adcp_capabilities) で `require_operator_auth: true` を設定します。 * **オープンプラットフォーム**（パブリッシャー、SSP）は暗黙的なアカウントを使用できる — エージェントが信頼され、`sync_accounts` を通じてアカウントを宣言します。完全なワークフローについては[アカウントとエージェント](/docs/building/by-layer/L2/accounts-and-agents)を参照。 **サンドボックスサポートを強く推奨します。** 実際の支出を確定する前に、バイヤーがテストアカウントをプロビジョニングして完全な統合を検証できるよう、ケイパビリティで `account.sandbox: true` を宣言する — プロダクト発見、メディアバイ作成、デリバリーレポート。サンドボックスなしでは、バイヤーはライブインベントリに対してテストする必要があり、採用が遅くなりオンボーディングの摩擦が増加します。実装の詳細については[サンドボックスモード](/docs/media-buy/advanced-topics/sandbox)を参照。 ## オプション: デリバリーレポート `get_media_buy_delivery` を実装して、バイヤーエージェントが標準化された形式でパフォーマンスデータ — インプレッション、クリック、支出、コンバージョン — を取得できるようにします。これはエージェントが各ダッシュボードに個別にログインすることなく複数のプラットフォームにわたってキャンペーンを監視する方法です。 ## プロダクトデザインパターンインベントリタイプによって異なる AdCP 機能を使用します: | インベントリタイプ | 主要機能 | | ---------------- | ------------------------------------------------------------------------- | | 標準ディスプレイ/ビデオ | `format_ids`、`delivery_type: "non_guaranteed"`、オークション価格設定 | | ポッドキャストスポンサーシップ | `shows`、`placements`（ホストリード）、`delivery_type: "guaranteed"`、flat\_rate | | CTV シリーズスポンサーシップ | `shows`、`exclusivity`、`delivery_type: "guaranteed"` | | ライブイベント | `shows`（cadence: event）、`episodes`（flexible\_end、tentative）、`exclusivity` | | リテールメディア | `catalog_types`、`catalog_match`、メトリクス最適化 | コンテンツ中心のインベントリについては[ショーとエピソード](/docs/media-buy/product-discovery/collections-and-installments)を参照。独占性とスポンサーシップパターンについては[メディアプロダクト](/docs/media-buy/product-discovery/media-products#exclusivity)を参照。 ## ガバナンス適用バイヤーエージェントはますます支出を確定する前にガバナンスコンプライアンスを要求するようになっています。ガバナンスを実装することで、インベントリがブランドセーフキャンペーンの対象となり、キャンペーン後の紛争が減り、プラットフォームがブランドの適合性を真剣に考えていることをバイヤーエージェントに示せる。セラーに関連する3つのガバナンスドメインがあります。 ### adagents.json によるプロパティガバナンス `adagents.json` ファイルはプロパティガバナンスの基盤です。販売するプロパティ、販売を認可されたエージェント、インベントリに関するデータを持つガバナンスエージェントを宣言します。バイヤーエージェントはこれを使用してサプライパスの認可を検証し、プロパティインテリジェンスを発見する — `adagents.json` が欠如または不完全な場合、バイヤーエージェントは主張するものを販売する権限があるかを検証できません。バイヤーが品質、持続可能性、またはブランドセーフティのためにプロパティをスコアするガバナンスエージェントを発見できるよう、`property_features` エントリを宣言します。完全なスキーマについては[プロパティガバナンス仕様](/docs/governance/property/specification)を、パブリッシャーサイドのセットアップについては[adagents.json テクスペック](/docs/governance/property/adagents)を参照。 ### コンテンツスタンダードの適用バイヤーが `get_products` または `create_media_buy` リクエストに `content_standards_ref` を含める場合、デリバリー中にブランド適合性ルールを適用するよう依頼しています。責任: 参照されたガバナンスエージェントからスタンダードを取得し、適用できるかどうかを評価し、できない場合はバイを拒否し、`calibrate_content` を通じてガバナンスエージェントに対してローカル評価モデルをキャリブレーションします。デリバリー後、バイヤーがコンプライアンスを独立して検証できるようにコンテンツアーティファクトをバイヤーに返します。バイヤーのコンテンツスタンダードを意味のある形で適用できない場合は、受け入れてサイレントに失敗するのではなく、バイを拒否します。完全なセールスエージェントワークフローについては[コンテンツスタンダード実装ガイド](/docs/governance/content-standards/implementation-guide)を参照。 ### 実行チェックバイヤーのアカウントにガバナンスエージェントが設定されている場合（[`sync_governance`](/docs/accounts/tasks/sync_governance) 経由）、セラーはメディアバイを確定する前に、`media_buy_id` と `planned_delivery` を付けて [`check_governance`](/docs/governance/campaign/tasks/check_governance) を呼び出さなければなりません（MUST）。これは拘束力のある検証です — ガバナンスエージェントがセラーの計画されたデリバリーをバイヤーのキャンペーンプランに照らして検証します。 ```javascript theme={null} // create_media_buy を確定する前に const check = await governanceAgent.checkGovernance({ plan_id: mediaBuy.plan_id, // from the create_media_buy request caller: "https://seller.example.com", governance_context: mediaBuy.governance_context, // opaque — pass through, do not parse media_buy_id: mediaBuy.media_buy_id, phase: "purchase", planned_delivery: { geo: { countries: ["US"] }, channels: ["olv"], start_time: mediaBuy.start_time, end_time: mediaBuy.end_time, total_budget: mediaBuy.total_budget.amount, currency: mediaBuy.total_budget.currency } }); if (check.status === "denied") { // Committed checks are always binding — do not confirm the media buy return { error: "GOVERNANCE_DENIED", detail: check.explanation }; } if (check.status === "conditions" && retries < 3) { // Conditions restrict what the seller can deliver — e.g., narrower geo, // blocked channels, reduced frequency. The seller adjusts their own // delivery parameters (not the buyer's budget) and re-calls check_governance. // If the seller cannot satisfy the conditions, reject the media buy. const adjusted = applyConditions(plannedDelivery, check.conditions); if (!adjusted) { return { error: "GOVERNANCE_CONDITIONS_UNSATISFIABLE", detail: check.conditions }; } // Re-check with adjusted delivery (governance agents SHOULD deny after 3 re-calls) return await checkGovernanceWithRetry(request, adjusted, retries + 1); } if (check.status === "conditions") { return { error: "GOVERNANCE_CONDITIONS_RETRY_LIMIT", detail: check.conditions }; } // check.status === "approved" — proceed with confirmation ``` 実行チェックはメディアバイライフサイクルの 3 つのフェーズをカバーします: | フェーズ | いつ呼ぶか | 何が検証されるか | | -------------- | ---------------------------------------------------------------------------- | ----------------------- | | `purchase` | `create_media_buy` を確定する前 | 予算、地域、チャネル、フライト日、ポリシー | | `modification` | [`update_media_buy`](/docs/media-buy/task-reference/update_media_buy) を確定する前 | 変更の大きさ、再配分、新しいパラメーター | | `delivery` | デリバリー中に定期的に | ペーシング、支出率、地域ドリフト、チャネル分布 | セラーは実行チェックを段階的に導入できます — purchase のみ（`create_media_buy` ごとに 1 回の呼び出し）から始め、その後 modification と delivery チェックを追加します。完全な仕様は [`check_governance`](/docs/governance/campaign/tasks/check_governance) を参照してください。 ### キャンペーンガバナンスコンテキストバイヤーが `create_media_buy` リクエストのプロトコルエンベロープに `governance_context` を含める場合、メディアバイと一緒に保存します。これは不透明な値だ — 解釈せず、ただ永続化して転送します。そのメディアバイのすべてのライフサイクルイベントでバイヤーのガバナンスエージェントに `governance_context` を渡す: | ライフサイクルイベント | governance\_context の流れ | | --------------- | ------------------------------------------------------------------------------------ | | **作成** | `create_media_buy` エンベロープで受信します。保存します。`check_governance` を呼び出す場合は含めます。 | | **活性化** | セラーの `planned_delivery` で `check_governance` を呼び出す際に保存した `governance_context` を含めます。 | | **更新** | 変更に対する `check_governance` に含めます。ガバナンスエージェントはそれを使用して累積的な変更を追跡します。 | | **一時停止 / 再開** | `check_governance` を呼び出す場合に含めます。ガバナンスエージェントはペーシング状態を更新します。 | | **キャンセル / 完了** | ガバナンスエージェントが予算追跡を終了して最終監査を生成できるよう含めます。 | | **デリバリーウェブフック** | ガバナンスエージェントがデリバリーデータと関連付けられるようウェブフックペイロードに含めます。 | ガバナンスエージェントは `governance_context` を使用して各イベントを元のプラン、キャンペーン、予算状態に再接続します。これなしに、ガバナンスエージェントはライフサイクルを通じてメディアバイを追跡する方法がない。元のリクエストに `governance_context` が存在しない場合は、ガバナンス呼び出しをスキップする — バイヤーはこのメディアバイにキャンペーンガバナンスを使用していません。 ### クリエイティブガバナンスバイヤーエージェントはデリバリー前にクリエイティブ評価を要求することがある — セキュリティスキャン、コンテンツ分類、品質スコアリング。セラーとして、`get_creative_features` を通じてガバナンスエージェントにクリエイティブマニフェストを送信し、バイヤーが設定した機能要件を尊重する（例: `auto_redirect` や `credential_harvest` にフラグされたクリエイティブのブロック）。評価を自分で実装する必要はない。専門のガバナンスエージェントがそれを処理します。フィーチャーベースの評価モデルとマルチエージェント協調パターンについては[クリエイティブガバナンスの概要](/docs/governance/creative/index)を参照。 ### スポンサードインテリジェンスセラー向け: 生成時の適用従来のセラーはガバナンスをポストデリバリーフィルターとして適用する — コンテンツを分類し、失敗したものをブロックします。スポンサードインテリジェンスプラットフォームはサーブ時にクリエイティブを生成するため、ガバナンスルールを事後ではなく生成中に適用できます。バイヤーがコンテンツスタンダードをプッシュする際は、それらを生成パイプラインの制約として適用することで、不適切なコンテンツが生成されないようにします。これによりブランドは根本的に強力な保証を得る: 適合性はチェックとして後付けされるのではなく、出力に組み込まれる。コンテンツスタンダードがカタログ駆動のクリエイティブ生成とどのように統合されるかについては[スポンサードインテリジェンスガイド](/docs/sponsored-intelligence/overview)を参照。 ## 既存スタックとの接続 AdCP は既存の API やダッシュボードと並列して動作します。セルフサービスプラットフォームや内部のキャンペーン管理システムを置き換えるものではありません。AI エージェントが使用できる標準インターフェースを追加します。 | 既存システム | AdCP との関係 | | ---------------- | ------------------------------------------------- | | セルフサービスダッシュボード | AdCP は異なるオーディエンス（AI エージェント、人間ではない）に対応 | | 管理 API | AdCP は標準的なサブセットを提供し、API は完全な機能セットを提供 | | 広告サーバー（GAM、カスタム） | AdCP はキャンペーン指示を送信し、広告サーバーはデリバリーを処理 | | OpenRTB 統合 | AdCP はキャンペーン設定を処理し、OpenRTB はインプレッションレベルのオークションを処理 | ## はじめるインタラクティブビルダーを使って adagents.json ファイルを作成・検証します。セルサイドタスク実装の完全なリファレンス: プロダクト、メディアバイ、デリバリーレポート。実装ガイド、SDK、統合パターン。プラットフォーム向けの AdCP 実装について質問する — コードは不要。 AI プラットフォームと広告ネットワーク向けのプロダクトモデリングとワークフロー。リテールメディアネットワーク向けのプロダクトモデリングとワークフロー。