AdCP — コンプライアンスカタログ

すべての AdCP エージェントは get_adcp_capabilities で supported_protocols と specialisms を宣言します。各宣言は、クレームを検証するためにストーリーボードランナーが実行する /compliance/{version}/ のコンプライアンスバンドルにマップされます。

supported_protocols は網羅的ではありません。 accounts 表面（sync_accounts、list_accounts、sync_governance）は、すべての media_buy、creative、signals エージェントに暗黙の基盤であり、意図的に supported_protocols 値ではありません。完全なアカウント表面については Accounts tasks を参照してください。

このページはその分類の人間可読なインデックスです。機械可読な同等物は /compliance/{version}/index.json です。

Universal ストーリーボード

すべてのエージェントは、どのプロトコルや専門分野を主張するかにかかわらず /compliance/{version}/universal/ のすべてのストーリーボードを実行します。いくつかは ケイパビリティゲート — 該当ケイパビリティをアドバタイズするときのみ実行される — ですが、ストーリーボードはスコープにおいて依然として universal です: そのケイパビリティを主張する任意のエージェントがそれによってグレードされます。universal ストーリーボードを失敗すると全体のコンプライアンスが失敗します。

Storyboard	目的
`capability-discovery`	`get_adcp_capabilities` 形状、protocol/specialism 宣言、バージョンアドバタイズ
`comply-controller-mode-gate`	共有エンドポイント上で `comply_test_controller` を公開するセラーのサンドボックス/ライブ分離 — ライブモードのプリンシパルはシナリオディスパッチの前に拒否されなければならない
`schema-validation`	リクエストとレスポンスのスキーマ適合性、ISO 8601 タイムスタンプ、時間的不変条件
`schema-validation-signals`	シグナルのレスポンススキーマ適合性 — すべてのシグナルの必須フィールド。`get_signals` にゲートされる
`version-negotiation`	リリース精度の `adcp.supported_versions` アドバタイズとレスポンスエンベロープの `adcp_version` エコー。3.1 では助言的、後のカットで昇格
`v3-envelope-integrity`	v3 プロトコルエンベロープは v2 レガシー `task_status` または `response_status` フィールドを持ってはならない（MUST NOT） — v3 では `status` が唯一の正準ライフサイクルフィールド。
`error-compliance`	構造化エラー形状、公開エラーコード、トランスポートバインディング、テナント間の存在リークなし
`error-compliance-signals`	シグナルプロトコルのエラー処理 — 存在しないシグナル ID、欠けているフィールド、VERSION_UNSUPPORTED、トランスポートバインディング。ディスカバリーフェーズは `get_signals` にゲートされる。アクティベーションフェーズは `signal-marketplace` のようなアクティベーションサポートを主張するエージェントのみ実行
`stale-response-advisory`	`STALE_RESPONSE` ワイヤー配置 — 助言は、トランスポート成功を保持した投入済み成功レスポンス上の `errors[]` に乗る。stale-cache 強制ステップは `force_upstream_unavailable` を伴う `comply_test_controller` にゲートされる
`idempotency`	`idempotency_key` スコーピング、リプレイセマンティクス、`IDEMPOTENCY_CONFLICT`、`replayed: true`、宣言された TTL
`read-tool-idempotency`	読み取り専用タスクラッパーは、厳格なリクエストラッパー拒否なしに 3.1 の全リクエスト `idempotency_key` エンベロープを受け入れる。3.1 の省略キー猶予プローブを含む。
`canonical-format-validate-input`	正準形式 `validate_input` 結果セマンティクス — 必須スロット全体の構造的 pass/fail と、シードされた製品宣言の `unvalidatable_nondeterministic`。`validate_input` をアドバタイズするエージェントにゲートされる。シード製品分岐は `comply_test_controller` シードサポートも要求。
`security`	認証ベースライン — 未認証拒否、静的認証情報強制（Bearer API キーまたは HTTP Basic）、OAuth ディスカバリー + RFC 9728 オーディエンスバインディング。 Authentication を参照。
`webhook-emission`	アウトバウンド webhook 適合性 — リトライ間で安定した `idempotency_key`、RFC 9421 webhook 署名（またはバイヤーがオプトインした場合 HMAC フォールバック）。任意の操作で `push_notification_config` を受け入れる任意のエージェントで実行。
`webhook-receiver-envelope`	バイヤーレシーバーのリプレイ適合性: 完全な MCP webhook エンベロープを受け入れ、素の配信結果ペイロードを拒否し、生ボディバイト上で署名を検証し、`idempotency_key` でリトライを重複排除。
`notification-config-event-scope`	`sync_accounts.accounts[].notification_configs[]` セマンティック検証 — アカウントレベルのサブスクライバーは、共有通知タイプ enum で有効な値であってもメディアバイアンカーの通知タイプ（`scheduled`、`final`、`delayed`、`adjusted`、`impairment`）を拒否。
`notification-config-lifecycle`	`sync_accounts` 上のアカウントレベル `notification_configs[]` ライフサイクル: 一時停止された登録、耐久性のある `list_accounts` エコー、サブスクライバーキーの置換、clear-all セマンティクス。
`notification-config-rejections`	重複する `subscriber_id` 値のためのセマンティック `notification_configs[]` リクエスト拒否パス。
`wholesale-feed-products`	製品ホールセールフィードバージョニング — ブートストラップレスポンスは `wholesale_feed_version`/`cache_scope` を持ち、一致する `if_wholesale_feed_version` プローブは製品行なしで `unchanged` を返す。
`wholesale-feed-signals`	シグナルホールセールフィードバージョニング — ブートストラップレスポンスは `wholesale_feed_version`/`cache_scope` を持ち、一致する `if_wholesale_feed_version` プローブはシグナル行なしで `unchanged` を返す。
`wholesale-feed-product-webhooks`	製品ホールセールフィード webhook イベントをアドバタイズするエージェントのアカウントレベル `notification_configs[]` 登録。
`wholesale-feed-signal-webhooks`	シグナルホールセールフィード webhook イベントをアドバタイズするエージェントのアカウントレベル `notification_configs[]` 登録。
`wholesale-feed-bulk-webhooks`	`wholesale_feed.bulk_change` をアドバタイズするエージェントのアカウントレベル `notification_configs[]` 登録。
`pagination-integrity`	ページ化された `list_creatives` レスポンスを継続ページから終端まで歩くことで検証される `cursor` ↔ `has_more` 不変条件。
`get-products-pagination-integrity`	`get_products` ホールセールページネーションセマンティクス — シードされた製品フィードを継続から終端まで歩き、brief/refine をフィード列挙ではなく上限付きキュレート/リファイン回答として保持。
`get-signals-pagination-integrity`	広範なクエリの下でページ化された `get_signals` レスポンスを歩くことで検証される `cursor` ↔ `has_more` 不変条件 — ページ 1 は任意の非自明なシグナルセットに対して非終端でなければならず、ページ 2 はカーソルをたどる。
`pagination-integrity-list-accounts`	ページ化された `list_accounts` レスポンスを歩くことで検証される `cursor` ↔ `has_more` 不変条件 — ストーリーボードは `sync_accounts` 経由で 3 つのアカウントをブートストラップし、ページ 1 が非終端でページ 2 が古いカーソルなしで終端であることをアサート。
`pagination-integrity-creative-formats`	ページ化された `list_creative_formats` レスポンスを歩くことで検証される `cursor` ↔ `has_more` 不変条件 — ストーリーボードは `seed_creative_format` 経由で 2 つのクリエイティブフォーマットをシードし、ページ 1 が非終端でページ 2 が古いカーソルなしで終端であることをアサート。
`get-media-buys-pagination-integrity`	ページ化された `get_media_buys` レスポンスを歩くことで検証される `cursor` ↔ `has_more` 不変条件 — ストーリーボードは `seed_media_buy` 経由で 3 つのメディアバイをシードし、ページ 1 が非終端でページ 2 が古いカーソルなしで終端であることをアサート。
`content-standards-pagination-integrity`	ページ化された `list_content_standards` レスポンスを歩くことで検証される `cursor` ↔ `has_more` 不変条件 — ストーリーボードは `create_content_standards` 経由で 3 つのコンテンツ標準構成をブートストラップし、ページ 1 が非終端でページ 2 が古いカーソルなしで終端であることをアサート。
`collection-lists-pagination-integrity`	ページ化された `list_collection_lists` レスポンスを歩くことで検証される `cursor` ↔ `has_more` 不変条件 — ストーリーボードは `create_collection_list` 経由で 3 つのコレクションリストをブートストラップし、ページ 1 が非終端でページ 2 が古いカーソルなしで終端であることをアサート。
`property-lists-pagination-integrity`	ページ化された `list_property_lists` レスポンスを歩くことで検証される `cursor` ↔ `has_more` 不変条件 — ストーリーボードは `create_property_list` 経由で 3 つのプロパティリストをブートストラップし、ページ 1 が非終端でページ 2 が古いカーソルなしで終端であることをアサート。
`deterministic-testing`	`comply_test_controller` ステートマシン検証 — `capabilities.compliance_testing.supported: false` ならスキップ。
`signed-requests`	RFC 9421 トランスポート層リクエスト署名検証 — `request_signing.supported: false` ならスキップ。
`billing-gate-dispatch`	`sync_accounts.billing` 拒否ディスパッチ — `BILLING_NOT_SUPPORTED`（ケイパビリティゲート、`error.details.scope` 付き）対 `BILLING_NOT_PERMITTED_FOR_AGENT`（バイヤーエージェントごとの商業関係ゲート、クランプされた `rejected_billing` + `suggested_billing` 形状付き）。セラーが 3 つの `billing` 値すべてをサポートするときケイパビリティフェーズはスキップ。テストキットが `commercial_relationship: passthrough_only` を宣言しないときエージェントごとのフェーズはスキップ。

ケイパビリティゲートの行（deterministic-testing、signed-requests）は、エージェントがケイパビリティを false としてアドバタイズするときのみスキップされます。それらを主張して部分的に実装することはできません。supported: true を宣言してストーリーボードを失敗することは非適合です — 部分的な実装を出荷するより false を宣言してください。billing-gate-dispatch と comply-controller-mode-gate の行は、通常のケイパビリティゲート行ではなく前提条件ゲートです: 各フェーズは前提条件が満たされないとき not_applicable をグレードします。エージェントごとの課金ゲートの完全なカバレッジを望むセラーは、エージェントごとのフェーズが実行されるよう commercial_relationship: passthrough_only を宣言したテストキットを出荷すべきです（SHOULD）。

プロトコル

トップレベルのエージェントケイパビリティクレーム。エージェントは supported_protocols にリストすることでプロトコルを主張し、プロトコルのベースラインストーリーボードとすべての universal ストーリーボードを通過しなければなりません。 supported_protocols は snake_case を使います。コンプライアンスパスと専門分野 ID は kebab-case を使います。完全なマッピングについては下の Naming conventions を参照してください。

`supported_protocols` value	Compliance path	目的
`media_buy`	`protocols/media-buy/`	キャンペーン作成、パッケージ管理、配信最適化、コンバージョントラッキング
`creative`	`protocols/creative/`	クリエイティブアセット管理、フォーマットディスカバリー、レンダリング
`signals`	`protocols/signals/`	オーディエンスシグナルディスカバリーとアクティベーション
`governance`	`protocols/governance/`	プロパティガバナンス、ブランド標準、コンプライアンス
`brand`	`protocols/brand/`	ブランドアイデンティティ、権利ディスカバリー、権利取得 — 今日は小さなプロトコルだが、権利ライセンシング作業とともに成長中。`brand-rights` 専門分野を参照。
`sponsored_intelligence`	`protocols/sponsored-intelligence/`	AI 仲介コマースと会話型スポンサードエクスペリエンス
`measurement`	Preview / 安定ベースラインなし	実験的 3.1 メトリックカタログディスカバリー。それを実装するエージェントは `experimental_features` に `measurement.core` をリストしなければならない。

コンプライアンステストコントローラーのサポートは、supported_protocols ではなく get_adcp_capabilities の capabilities.compliance_testing ブロックで宣言されます。コンプライアンステストはテストハーネス用の RPC 表面であり、機能的プロトコルではありません。

エージェントは複数のプロトコルを主張できます — フルスタックのメディアバイプラットフォームは media_buy、creative、signals をリストするかもしれません。ランナーはすべての一致するベースラインを実行します。

専門分野

具体的なケイパビリティクレーム。各専門分野はちょうど 1 つのプロトコルの下に存在します。専門分野を主張するエージェントは、親プロトコルのベースラインに加えて専門分野のストーリーボードを通過しなければなりません — 例えば sales-guaranteed を主張するには supported_protocols に media_buy が必要です。専門分野は status を持ちます:

stable — 完全に仕様化されたストーリーボード。コンプライアンスランナーはすべてのフェーズを実行する。AAO Verified はエージェントが実証可能に通過したことを意味する。
preview — ID とスコープは予約済み。基盤プロトコル表面が安定するまでストーリーボードはプレースホルダー。エージェントはこれらを主張してもよい。ランナーは検証済み pass/fail の代わりに { status: "preview", passed: null, reason: "storyboard not yet defined" } の結果を発行する。AAO バッジは preview 専門分野を明確なインジケーターでレンダリングする。
deprecated — 後方互換性のため保持されるが、将来のメジャーで削除予定。ランナーは { status: "deprecated", passed: <boolean>, reason: "..." } を発行する — 存在すれば依然としてストーリーボードを実行するが、クレームを移行すべきと警告する。

ステータスは YAML フロントマターで専門分野ごとに宣言され、/compliance/{version}/index.json に表示されます。専門分野は下で親プロトコルごとにグループ化されています。

3.0 での変更点。 sponsored_intelligence は専門分野からフルプロトコルに昇格しました（specialisms ではなく supported_protocols で宣言）。audience-sync はそのツールファミリーに合わせて governance から media-buy に移動しました。broadcast-platform は sales-broadcast-tv に、social-platform は sales-social にリネームされました。property-governance と collection-governance は兄弟の property-lists と collection-lists 専門分野に分割されました。

media-buy

Specialism	Status	目的
`sales-guaranteed`	stable	人間 IO 承認を伴う保証メディアバイ
`sales-non-guaranteed`	stable	非保証オークションベースメディアバイ
`sales-proposal-mode`	deprecated	3.1 で非推奨。このクレームを落とし `sales-guaranteed` + `media_buy.supports_proposals: true` で置き換えてください。#3823 を参照。
`sales-catalog-driven`	stable	コンバージョントラッキングを伴うカタログ駆動コマース
`sales-broadcast-tv`	stable	保証在庫と FCC キャンセルルールを伴う放送リニア TV
`sales-social`	stable	セルフサービスフローを伴うソーシャルメディア広告プラットフォーム
`governance-aware-seller`	stable	ベースライン登録後にバイヤーのキャンペーンガバナンスエージェントと合成するセラー — `check_governance` を呼び、承認、条件、拒否を変えずに伝播する。完全なガバナンスチェックループのオプションクレーム。
`audience-sync`	stable	バイヤー提供のオーディエンスセグメントをアクティベーションのためプラットフォームに同期（`sync_audiences`、`list_accounts` を使う）

3.1 で登場。 sales-streaming-tv（CTV / ストリーミング）、sales-exchange（プログラマティック SSP / エクスチェンジ）、sales-retail-media（リテールメディアネットワーク）は 3.1 に予定されています。それらのカテゴリーのセラーは 3.0 GA では sales-guaranteed または sales-non-guaranteed を主張すべきです。

audience-sync はそのツールファミリーに合わせて governance プロトコルから media-buy に移動しました。エージェントが audience-sync を主張するが supported_protocols に governance のみ宣言する場合、supported_protocols に media_buy を追加してください — ランナーは今や audience-sync ストーリーボードと並んでメディアバイベースラインが実行されることを期待します。

creative

Specialism	Status	目的
`creative-ad-server`	stable	タグベース配信を伴うクリエイティブ広告サーバー
`creative-generative`	stable	オンデマンドでアセットを生成する生成クリエイティブエージェント
`creative-template`	stable	クリエイティブテンプレートと変換エージェント

signals

Specialism	Status	目的
`signal-owned`	stable	`get_signals` を通じてファーストパーティセグメントを公開する所有シグナルエージェント。このクレームにアクティベーションは不要
`signal-marketplace`	stable	サードパーティデータを再販するマーケットプレイスシグナルエージェント。`get_signals` と `activate_signal` が必要

governance

Specialism	Status	目的
`content-standards`	stable	コンテンツ標準強制（ブランドセーフティ、ポリシーコンプライアンス）
`property-lists`	stable	プロパティリストガバナンス — ターゲティングと配信コンプライアンスのためのキュレートされた包含/除外リスト
`collection-lists`	stable	コレクションリストガバナンス — プログラムレベルのブランドセーフティのためのコンテンツプログラム（番組、シリーズ、ポッドキャスト）のキュレートされた包含/除外リスト
`governance-delivery-monitor`	stable	ドリフト検出を伴うキャンペーン配信監視
`governance-spend-authority`	stable	条件付き支出承認と human-in-the-loop ガバナンス

3.1 で実験的。 メジャメントメトリックカタログディスカバリーは実験的 measurement ケイパビリティブロックと measurement.core 実験的機能を通じて利用可能です。安定した measurement-verification 専門分野とベースラインストーリーボードは、メジャメントタスク表面が凍結されるまで延期されます。

brand

Specialism	Status	目的
`brand-rights`	stable	ブランドアイデンティティと権利ライセンシング（タレント、音楽、ストックメディア）

Choosing a sales specialism

sales-* 専門分野は相互排他的ではありません — 保証ダイレクトデスクとオークションフロアの両方を持つハイブリッドプラットフォームは sales-guaranteed と sales-non-guaranteed の両方を主張すべきです。クレームを解決するには下のステップに従ってください。

sales-proposal-mode は 3.1 で非推奨です。 新しいエージェントでそれを主張しないでください。それを宣言する既存のエージェントはそれを完全に落とし、get_adcp_capabilities で sales-guaranteed + media_buy.supports_proposals: true で置き換えなければなりません。#3823 を参照。

あなたの在庫はチャネル固有か?

3 つの専門分野は特定の配信チャネルに適用され、独自のストーリーボードを持ちます。これらのチャネルタイプの 1 つだけを販売する場合、一致する専門分野のみを主張してください。これらのチャネル外の一般的なディスプレイやビデオ在庫も販売する場合、ステップ 2 に進んでください。

運用するもの…	Claim
FCC キャンセルルールを伴う放送リニア TV	`sales-broadcast-tv`
カタログ駆動ダイナミック広告（製品リスティング、レストランメニュー、ホテルリスティング、ローカルコマース）	`sales-catalog-driven`
プラットフォーム管理クリエイティブを伴うソーシャルプラットフォーム	`sales-social`

どの購入モデルをサポートするか?

販売するもの…	Claim
保証メディア（IO 承認、固定価格）	`sales-guaranteed` → ステップ 3 を参照
オークション / PMP 非保証	`sales-non-guaranteed`
保証と非保証の両方	`sales-guaranteed` + `sales-non-guaranteed`

media_buy.supports_proposals を設定（sales-guaranteed のみ）

media_buy.supports_proposals は get_adcp_capabilities レスポンスの media_buy ケイパビリティブロックのブール値です。proposal_finalize コンプライアンスシナリオが実行されるかをゲートします。これは適合性宣言であり、バイヤーのプロポーザルごとのルーティングシグナルではありません: バイヤーは proposal_status から返されたプロポーザルが購入できるかを決定します。

もし…	Set
RFP を受け入れ、プロポーザルを生成し、作成前にドラフトプロポーザルをコミット済みステータスにファイナライズする	`media_buy.supports_proposals: true`
ダイレクトバイ保証のみを販売（オークション PG、リテール SKU、見積レート — RFP フローなし）	`media_buy.supports_proposals: false`（または省略 — デフォルトは `false`）

// フルサービス保証セラー — プロポーザルライフサイクルがグレードされる
{
  "supported_protocols": ["media_buy"],
  "specialisms": ["sales-guaranteed"],
  "media_buy": {
    "supports_proposals": true
  }
}

// ダイレクトバイ保証セラー — プロポーザルシナリオは capability_unsupported としてスキップ
{
  "supported_protocols": ["media_buy"],
  "specialisms": ["sales-guaranteed"],
  "media_buy": {
    "supports_proposals": false
  }
}

creative

Specialism	Status	目的
`creative-ad-server`	stable	タグベース配信を伴うクリエイティブ広告サーバー
`creative-generative`	stable	オンデマンドでアセットを生成する生成クリエイティブエージェント
`creative-template`	stable	クリエイティブテンプレートと変換エージェント

signals

Specialism	Status	目的
`signal-owned`	stable	`get_signals` を通じてファーストパーティセグメントを公開する所有シグナルエージェント。このクレームにアクティベーションは不要
`signal-marketplace`	stable	サードパーティデータを再販するマーケットプレイスシグナルエージェント。`get_signals` と `activate_signal` が必要

governance

Specialism	Status	目的
`content-standards`	stable	コンテンツ標準強制（ブランドセーフティ、ポリシーコンプライアンス）
`property-lists`	stable	プロパティリストガバナンス — ターゲティングと配信コンプライアンスのためのキュレートされた包含/除外リスト
`collection-lists`	stable	コレクションリストガバナンス — プログラムレベルのブランドセーフティのためのコンテンツプログラム（番組、シリーズ、ポッドキャスト）のキュレートされた包含/除外リスト
`governance-delivery-monitor`	stable	ドリフト検出を伴うキャンペーン配信監視
`governance-spend-authority`	stable	条件付き支出承認と human-in-the-loop ガバナンス

brand

Specialism	Status	目的
`brand-rights`	stable	ブランドアイデンティティと権利ライセンシング（タレント、音楽、ストックメディア）

Specialism	Status	目的
`sponsored-intelligence`	preview	専門分野 ID でディスパッチする SDK 用のエージェントクレーム。グレードされるストーリーボードは `sponsored-intelligence` プロトコルベースライン。この専門分野はワイヤー ID を予約し、SI ツールが `x-status: experimental` から卒業したとき `stable` に昇格する。

クロスリソース不変条件

ステップごとの検証に加えて、専門分野はランナーが完全なストーリーボード実行全体で観測するクロスステップとクロスリソースの 不変条件 を宣言します。これらは単一のレスポンス形状では表面化しない状態不整合を捕捉します。

Invariant	Scope	Specialisms
`status.monotonic`	単一リソース — 仕様ライフサイクルグラフ上にないステップ間で観測されたステータス遷移を拒否。	ステートフルなリソースライフサイクルを持つすべての専門分野。
`impairment.coherence`	クロスリソース — `media_buy.impairments[]` が参照されるリソースと同期を保つことを検証。前方: すべてのエントリーが現在オフラインのリソースを参照する。逆: 非終端バイが参照する任意のオフラインリソースが `impairments[]` に現れる。Health-iff: 非終端バイ上で、`impairments[]` が非空のとき、かつそのときに限り `health == "impaired"`（厳格な iff — 古いドリフトは失敗）。スコープ外: 3 つのルールすべてが終端ステータスバイで緩和される（セラーは終端遷移で保持されていた状態のまま `impairments[]` と `health` を残してもよい（MAY））。マテリアリティは `package_ids: minItems: 1` 経由でスキーマ強制される。	`audience-sync`、`creative-ad-server`、`creative-template`、`creative-generative`、`sales-catalog-driven`。`media_buy_seller/dependency_impairment` シナリオ（`force_creative_status` 経由の creative-track）で駆動される。audience-track と catalog-track は、コンプライアンステストコントローラーが `force_audience_status` / `force_catalog_item_status` を追加すると続く。リソース遷移とメディアバイスナップショット読み取りの両方を観測しないストーリーボードでは `not_applicable` をグレード。

不変条件は専門分野 YAML の invariants: 配列で宣言され、それらが強制するルールとともにインラインで文書化されます。完全な impairment.coherence コントラクトについては media-buy lifecycle § Compliance を参照してください。

主張する方法

get_adcp_capabilities でプロトコルと専門分野を宣言します:

{
  "supported_protocols": ["media_buy", "creative"],
  "specialisms": ["sales-guaranteed", "creative-template"]
}

ストーリーボードランナーは:

/compliance/{version}/universal/ のすべてのストーリーボードを実行
supported_protocols の各プロトコルについて、/compliance/{version}/protocols/{protocol}/ のベースラインを実行（snake_case → kebab-case）
各主張された専門分野のストーリーボードを /compliance/{version}/specialisms/{id}/ で実行
preview 専門分野については、pass/fail 判定の代わりに警告を発行 — AAO Verified バッジは preview 専門分野を明確なインジケーターでレンダリング

ツールを実装し、かつ専門分野を主張してください。 専門分野の必須ツールをすべて配線するが capabilities.specialisms[] から kebab-case ID を省略するエージェントは、ランナーによって “No applicable tracks found” としてグレードされます — tracks_passed = 0, tracks_failed = 0, tracks_skipped = 1。これはステップレベルでの黙った通過であり、トラックレベルでの黙った失敗です。修正は get_adcp_capabilities レスポンスに専門分野 ID（例: "creative-generative"）を追加することです。

任意の stable ストーリーボードが失敗すると、あなたのエージェントはそのクレームに対して非適合です。スイートをローカルで実行する方法についてはエージェントを検証するを参照してください。ランナーが専門分野マニフェストをどうグレードされるシナリオに解決するか — media_buy.supports_proposals のようなケイパビリティフラグがどう個々のシナリオをゲートするかを含む — の詳細なウォークスルーについてはグレーディングの仕組みを参照してください。

Naming conventions

分類には 4 つのケーシングが共存します。どれが適用されるかは、識別子がどこで読まれるかに依存します:

Casing	Layer	Example	現れる場所
`snake_case`	ワイヤー enum（`supported_protocols`、`delivery_type`、チャネル ID、`signal_type`）	`media_buy`、`non_guaranteed`、`ctv`、`custom`	`get_adcp_capabilities` レスポンス、JSON ペイロード、生成されたスキーマ
`kebab-case`	専門分野 ID とコンプライアンス URL	`sales-broadcast-tv`、`property-lists`、`audience-sync`	`get_adcp_capabilities.specialisms`、`/compliance/.../specialisms/{id}/` パス
`snake_case`	ストーリーボード `id:` と `category:` フィールド	`sales_broadcast_tv`、`audience_sync`	コンプライアンス YAML フロントマター、ランナー出力、テストレポート
散文 / ハイフン付き	タイトルとナラティブ	”Streaming TV”、“non-guaranteed”	カタログページ、ナラティブコピー

ワイヤー専門分野 ID とストーリーボードカテゴリー間の kebab↔snake スワップは機械的アイデンティティです — ハイフンがアンダースコアになるだけ。専門分野内のバリアントシナリオは {category}/{variant} パス形式を使います。

Specialism ID (wire)	Channel / tool family	Storyboard category	Variant scenarios
`sales-broadcast-tv`	`channels: ['linear_tv']`	`sales_broadcast_tv`	—
`sales-social`	`channels: ['social']`	`sales_social`	—
`audience-sync`	`sync_audiences` tool	`audience_sync`	—
`property-lists`	`property_list` tools	`property_lists`	—
`collection-lists`	`collection_list` tools	`collection_lists`	—
`governance-spend-authority`	`check_governance`, `sync_plans`	`governance_spend_authority`	`governance_spend_authority/denied`
`creative-generative`	`build_creative`	`creative_generative`	`creative_generative/seller`
`brand-rights`	`get_brand_identity`, `acquire_rights`	`brand_rights`	`brand_rights/governance_denied`

ケース分割は意図的です: supported_protocols は既に本番エージェントに出荷された既存の 3.0 フィールドである一方、専門分野 ID は新しく URL ファーストです（それぞれが /compliance/.../specialisms/{id}/ 下のディレクトリ名）。ランナーはマッピングを透過的に処理します。

専門分野 ↔ ツールファミリーマッピング

エージェントが主張するプロトコルは、専門分野が使うツールファミリー名と常に一致するわけではありません:

audience-sync は media-buy プロトコルの下に存在します。なぜなら sync_audiences はメディアバイツールだからです。
property-lists（専門分野 ID、kebab-case）は property_list ツールファミリー（create_property_list、validate_property_delivery）とストーリーボードカテゴリー property_lists にマップされます。
sales-broadcast-tv は channels: ['linear_tv'] を宣言します — “Broadcast TV” は散文名。linear_tv はワイヤー値です。

/compliance/{version}/index.json は各専門分野の required_tools を表示するため、エージェントは完全なストーリーボード YAML を読まずにツールファミリーを発見できます。

ワイヤー enum 対散文

ワイヤー enum 値は常に snake_case（non_guaranteed、pmax_platform、ctv）です。散文は同じ概念をハイフンやスペースでレンダリングします（“non-guaranteed auction inventory”、“Connected TV”）。ペイロードを投入するときは常にワイヤー形式を使ってください — ハイフン付きまたはスペース付きの綴りは編集上のものだけで、スキーマ検証に失敗します。

`signal_type` 値

シグナルレスポンスの signal_type enum は 3 つの値を持ちます:

marketplace — シグナルエージェントはサードパーティデータプロバイダー（Experian、Peer39 など）が公開するセグメントを再販している。バイヤーはプロバイダーの /.well-known/adagents.json 経由で認可を検証できる。
owned — シグナルエージェントは直接所有するデータ（リテーラー購入データ、パブリッシャー行動データ、通信位置データ）から派生した自身のファーストパーティセグメントを公開する。
custom — シグナルソースはモデル、コンポジット、またはバイヤー提供の入力からオンデマンドでセグメントを構築する。adagents.json 認可チェーンが適用されないときこれを使う — セグメントはソースネイティブで、常設アップストリームプロバイダーに帰属しない。

真実の源泉

機械インデックスはスキーマと並んで公開されます:

Path	Contents
`/compliance/{version}/index.json`	列挙されたプロトコル + 専門分野 + universal ストーリーボード + 専門分野ごとの `status`
`/schemas/{version}/enums/specialism.json`	`get_adcp_capabilities.specialisms` が使う専門分野 enum
`/schemas/{version}/enums/adcp-protocol.json`	`tasks-list-request` と webhook ペイロードが参照するタスク分類 enum。`supported_protocols` と同じ軸（ここでは kebab-case、ワイヤー上では snake_case）。

ビルドパイプラインは専門分野ファイルシステム ↔ enum パリティと、すべての専門分野の親プロトコルがコンプライアンスツリーに存在することを検証します。ドリフトはビルドを失敗させます。

このページのカタログは人間のコンテキストを与えるため手動で保守されています。権威的な列挙は常に /compliance/{version}/index.json です。

アップストリームプラットフォームをラップするエージェントを構築していますか? このカタログのストーリーボードは AdCP ワイヤーコントラクトをグレードします。アップストリームと統合せずに形状有効なレスポンスを返すアダプターは検出できません。補完的なプレステージングゲートについては モックアップストリームフィクスチャでアダプターエージェントを検証する を参照してください。

はじめに

AdCP で構築する

プロトコル

FAQ

トラストとセキュリティ

リファレンス

AAO

認定

コンプライアンスカタログ

Universal ストーリーボード

プロトコル

専門分野

media-buy

creative

signals

governance

brand

Choosing a sales specialism

creative

signals

governance

brand

sponsored-intelligence

クロスリソース不変条件

主張する方法

Naming conventions

専門分野 ↔ ツールファミリーマッピング

ワイヤー enum 対散文

`signal_type` 値

真実の源泉

​Universal ストーリーボード

​プロトコル

​専門分野

​media-buy

​creative

​signals

​governance

​brand

​Choosing a sales specialism

​creative

​signals

​governance

​brand

​sponsored-intelligence

​クロスリソース不変条件

​主張する方法

​Naming conventions

​専門分野 ↔ ツールファミリーマッピング

​ワイヤー enum 対 散文

​signal_type 値

​真実の源泉

Universal ストーリーボード

プロトコル

専門分野

media-buy

creative

signals

governance

brand

Choosing a sales specialism

creative

signals

governance

brand

sponsored-intelligence

クロスリソース不変条件

主張する方法

Naming conventions

専門分野 ↔ ツールファミリーマッピング

ワイヤー enum 対散文

`signal_type` 値

真実の源泉