> ## 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 プロトコルと専門分野の完全なインデックス — それぞれが何を意味するか、どのコンプライアンスストーリーボードが実行されるか、ソース YAML をどこで見つけるか。

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

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

このページはその分類の人間可読なインデックスです。機械可読な同等物は `/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](/docs/building/by-layer/L2/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](/docs/building/verification/validate-your-agent#storyboard-taxonomy) ストーリーボードを通過しなければなりません。

`supported_protocols` は snake\_case を使います。コンプライアンスパスと専門分野 ID は kebab-case を使います。完全なマッピングについては下の [Naming conventions](#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` をリストしなければならない。 |

<Note>
  [コンプライアンステストコントローラー](/docs/building/by-layer/L3/comply-test-controller) のサポートは、`supported_protocols` ではなく `get_adcp_capabilities` の `capabilities.compliance_testing` ブロックで宣言されます。コンプライアンステストはテストハーネス用の RPC 表面であり、機能的プロトコルではありません。
</Note>

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

## 専門分野

具体的なケイパビリティクレーム。各専門分野はちょうど 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` に表示されます。

専門分野は下で親プロトコルごとにグループ化されています。

<Note>
  **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` 専門分野に分割されました。
</Note>

### 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](https://github.com/adcontextprotocol/adcp/issues/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` を使う）                                                                                 |

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

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

### 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 ガバナンス                                                   |

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

### brand

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

## Choosing a sales specialism

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

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

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

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

  <Step title="どの購入モデルをサポートするか?">
    | 販売するもの…            | Claim                                       |
    | ------------------ | ------------------------------------------- |
    | 保証メディア（IO 承認、固定価格） | `sales-guaranteed` → ステップ 3 を参照             |
    | オークション / PMP 非保証   | `sales-non-guaranteed`                      |
    | 保証と非保証の両方          | `sales-guaranteed` + `sales-non-guaranteed` |
  </Step>

  <Step title="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`） |

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

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

### 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 ガバナンス                                                   |

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

### brand

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

### sponsored-intelligence

| 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](/docs/media-buy/media-buys/lifecycle#compliance) を参照してください。

## 主張する方法

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

```json theme={null}
{
  "supported_protocols": ["media_buy", "creative"],
  "specialisms": ["sales-guaranteed", "creative-template"]
}
```

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

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

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

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

## 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 パリティと、すべての専門分野の親プロトコルがコンプライアンスツリーに存在することを検証します。ドリフトはビルドを失敗させます。

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

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