> ## 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 適合」が何を意味するか、それを検証するストーリーボードで定義される。適合性は仕様が要求するもの、verified はスイートが証明するもの。 **ステータス**: Request for Comments **最終更新**: April 19, 2026 ## 3 つではなく 2 つの言葉 AdCP 適合性には 2 つの荷重を担う用語があります。3 つ目（実世界で耳にするもの）は罠です。 * **Conformant（適合）** — エージェントが規範的ルールを満たす。この文書がインデックスするストーリーボードで定義される。 * **Verified** — AAO がエージェントを最近テストし署名付き証明を発行した。アクティブなメンバーシップとライブなハートビートにゲートされる。[AAO Verified バッジ](/docs/building/verification/aao-verified) は 2 つの修飾子のいずれかを持ちます: テストデプロイまたは開発エンドポイントに対するストーリーボード適合性の **(Spec)**、`account.sandbox: true` フラグの下でセラーの実本番エンドポイントに対するストーリーボード適合性の **(Sandbox)**。エージェントはどちらか、または両方を獲得できます。 * **"Compliant"** — 自己証明、未検証、外部チェックなし。それを主張しない。それに向けて設計しない。この文書は *conformant* と *verified* を排他的に使います。 言い換えれば: * 適合性はエージェントのワイヤー動作の性質です。 * 検証は時間で区切られた第三者証明です。**(Spec)** は任意の登録エンドポイントに対するワイヤー形式適合性を証明します。**(Sandbox)** は同じストーリーボードスイートがサンドボックスフラグ付きトラフィックの下でセラーの実本番エンドポイントに対して通過することを証明します。同じストーリーボード、異なる証明表面。 * 2 つの軸は独立しています: 別のテストデプロイを持たないセラーは本番上で直接 **(Sandbox)** を獲得できます。実インプレッションを決してサーブできないテストエージェントは完全なクレームとして **(Spec)** を獲得します。 ## ストーリーボード適合性 対 AAO Verified このページは **ストーリーボード適合性** をインデックスします — シードされたテストデータに対して実行されるストーリーボードで検証される、エージェントのワイヤー動作が仕様に一致するときに持つ性質。ストーリーボードの通過は、ランナーがどこをターゲットしたかに応じて、エージェントのバッジ上で **AAO Verified (Spec)** または **AAO Verified (Sandbox)** の修飾子（または両方）を獲得します。 2 つ目の軸 — **AAO Verified (Sandbox)** — は、セラーの実本番エンドポイントが `account.sandbox: true` フラグの下で完全なストーリーボードスイートを正しく処理することを検証します。(Sandbox) はより強いクレームです: セラーはテストデプロイで (Spec) を通過しながら、本番スタックには壊れたサンドボックスゲート（フラグ付きトラフィックの下での実世界の副作用、欠けているアカウントモード検証など）があるかもしれません — (Sandbox) はそのギャップを閉じます。 2 つの修飾子は 1 つのブランドマーク — **AAO Verified** — を共有し、エージェントはどちらか、または両方を獲得できます。**(Spec) と (Sandbox) は独立しています**: それぞれが異なる証拠を通じて独立に適合性を実証します。(Spec) は任意の登録エンドポイントに対するワイヤー形式適合性を証明します。(Sandbox) は本番コードパスがサンドボックスフラグ付きトラフィックを正しく許容することを証明します。修飾子モデルと [Sandbox framing の判定](https://github.com/adcontextprotocol/adcp/issues/4379) については [AAO Verified](/docs/building/verification/aao-verified) を参照してください。このページの残りは両方の修飾子を裏付けるストーリーボードをインデックスします。 ## テスト表面とストーリーボードループ すべてのセラーは *テスト表面* を公開します — ストーリーボードランナーが実世界の副作用を引き起こすことなくセラーのツールを決定的に行使できるようにするメカニズム。テスト表面は (Spec) がグレードされる対象です。セラーがその表面をどう立ち上げるかは、状態の記録がどこに存在するかに依存します。実装は異なり、目標は異なりません: | 状態の記録がどこに存在するか | テストループがどう閉じるか | | ------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | ローカル DB のみ（典型的には SSP、クリエイティブエージェント） | ストーリーボードランナーは `comply_test_controller.seed_*` 経由でフィクスチャを書き込む。セラーの読み取りハンドラーは同じストアを消費する。seed → read ループが自然に閉じる。 | | セラーが制御しないアップストリームシステム（プラットフォームにプロキシする DSP、リテーラーカタログを読むリテールメディアネットワーク、シグナルブローカー） | シードされた書き込みは読み取りハンドラーにとって無効。TypeScript SDK は、まず実アダプター呼び出しを実行し（壊れたアップストリーム呼び出しは依然としてゲートを失敗させる）、次にシードされたフィクスチャをレスポンスにマージする `TestControllerBridge` を出荷する。 | | 混合（一部のツールはローカル、一部はアップストリーム） | ツールごとに両方。 | 両方のパスが `(Spec)` を獲得します — 両方ともセラーのワイヤー形式がストーリーボードに一致することを証明します。ブリッジはテスト表面パターンの **1 つの実装** であり、別のセラーカテゴリーではありません。配線されたシードのない状態ローカルセラーと、配線されたブリッジのないアップストリームプロキシセラーは同じ立場にあります: ストーリーボードはそれらに対してエンドツーエンドで実行できません。どちらのカテゴリーも `(Sandbox)` が証明するものではありません。`(Sandbox)` は、セラーの本番スタックが実世界の副作用なしに `account.sandbox: true` を尊重するかどうかをカバーする別の軸です。 ### フィクスチャマージ済みとアップストリーム由来のレスポンスを区別する レスポンスが SDK の `TestControllerBridge` を通過するとき、SDK はレスポンスに `_bridge: { callback, tool, merged_count }` マーカーをスタンプします。ステップ上のマーカーの存在は、レスポンス内容がセラーのハンドラーが返した後にシードされたフィクスチャからマージされたことを意味します。マーカーの不在は、レスポンスがセラーのアダプターからエンドツーエンドで来た（またはランナーが直接シードしたローカル DB から来た）ことを意味します。マーカーはランナーと下流リーダーボード用の助言的メタデータであり、ワイヤーコントラクトの一部では **ありません**。セラーはそれを発行してはならず（MUST NOT）、適合性チェックはそれを無視します。先頭のアンダースコアはフィールドをテストツール用に予約された SDK/ランナースタンプメタデータとしてマークします。同じプレフィックスを持つ将来のフィールドは同じルールに従います。 マーカー設計: [`adcp-client#1775`](https://github.com/adcontextprotocol/adcp-client/issues/1775)。出荷済み: [`adcp-client#1786`](https://github.com/adcontextprotocol/adcp-client/pull/1786)。マーカーを消費するリーダーボードポリシー: [`adcp-client#1782`](https://github.com/adcontextprotocol/adcp-client/issues/1782)。 ### 3 つのシグナル — 混同しないこと 採用者はしばしばこれら 3 つの制御を同じものとして読みます。それらは異なる質問に答えます: | Signal | 答える質問 | | --------------------------------------------------------- | -------------------------------------------------------- | | テストコントローラーの利用可能性（`tools/list` の `comply_test_controller`） | 「セラーは決定的モードの force を公開したか?」 | | サンドボックスフラグ（リクエスト上の `account.sandbox`） | 「ターゲットされたアカウントはサンドボックスアカウントで、実世界の副作用がないか?」 | | ブリッジ参加（レスポンス上の `_bridge` マーカー） | 「このレスポンスはアダプターのアップストリーム呼び出しから来たか、SDK がマージしたフィクスチャから来たか?」 | これらは個々のストーリーボードステップ上の **ランタイム制御** です — ストーリーボードの通過が時間をかけて何を *証明する* かを記述する `(Spec)` と `(Sandbox)` の検証修飾子とは別。ストーリーボードの通過は 3 つのシグナルの任意の組み合わせを持ちうる。 ## ストーリーボードが真実 すべての MUST を散文で再述する — それは避けがたく実行可能なスイートからドリフトする — のではなく、**ストーリーボードが適合性仕様そのものです。** この文書はそれらへのナビゲーショナルインデックスで、ストーリーボードの実行を義務付ける宣言でグループ化されています。 スイート内のすべての規範的ルールはちょうど 1 つの居場所を持ちます: [`/compliance/latest/`](https://adcontextprotocol.org/compliance/latest/) のストーリーボード YAML。「適合」が何を意味するかの変更はそこで、バージョン管理されたリリースで、実エージェントに対してテストされて起こります。ルールがストーリーボードにないなら、それは適合性の一部ではありません。 これは意図的です。ストーリーボードルールを再述する別の散文仕様は 2 つの真実の源泉を作ります。2 つの真実の源泉はドリフトします。私たちは 1 つを選びます: スイート。 `@adcp/sdk` パッケージは、ストーリーボード駆動の `comply()` に先行する `testing/scenarios/` 下の TypeScript ファイルも出荷します。それらは適合性仕様では **ありません** — どちらがどれかについては [Storyboards 対 scenarios](/docs/building/verification/storyboards-vs-scenarios) を参照してください。 以下で参照されるストーリーボードと散文セクションのキーワード「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「MAY」「OPTIONAL」は [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119) で説明される通りに解釈されます。 ## Conformance is layered すべてのエージェントは universal 層を満たします。各 `supported_protocols` クレームはプロトコルベースラインを追加します。各 `specialisms` クレームは専門分野ベースラインを追加します。 | Layer | Obligation | Path | | -------------- | ---------------------------------- | -------------------------------------------------------------------------------------------------------- | | **Universal** | すべての AdCP エージェント | [`/compliance/latest/universal/`](https://adcontextprotocol.org/compliance/latest/universal/) | | **Protocol** | `supported_protocols` 値を主張するエージェント | [`/compliance/latest/protocols/{protocol}/`](https://adcontextprotocol.org/compliance/latest/protocols/) | | **Specialism** | `specialisms` 値を主張するエージェント | [`/compliance/latest/specialisms/{id}/`](https://adcontextprotocol.org/compliance/latest/specialisms/) | エージェントは、そのストーリーボードを通過しないケイパビリティを宣言してはなりません（MUST NOT）。完全な分類については [コンプライアンスカタログ](/docs/building/verification/compliance-catalog) を、スイートをローカルで実行する方法については [エージェントを検証する](/docs/building/verification/validate-your-agent) を参照してください。 ## Universal 適合性 すべてのエージェントは以下のすべてのストーリーボードを通過しなければなりません（MUST）。 | Storyboard | 検証するもの | | -------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [`capability_discovery`](https://adcontextprotocol.org/compliance/latest/universal/capability-discovery) | `get_adcp_capabilities` 形状、protocol/specialism 宣言、バージョンアドバタイズ | | [`comply_controller_mode_gate`](https://adcontextprotocol.org/compliance/latest/universal/comply-controller-mode-gate) | 共有エンドポイント上で `comply_test_controller` を公開するセラーのサンドボックス/ライブ分離 — ライブモードのプリンシパルはシナリオディスパッチの前に拒否されなければならない | | [`schema_validation`](https://adcontextprotocol.org/compliance/latest/universal/schema-validation) | リクエストとレスポンスのスキーマ適合性、ISO 8601 タイムスタンプ、時間的不変条件 | | [`schema_validation_signals`](https://adcontextprotocol.org/compliance/latest/universal/schema-validation-signals) | シグナルのレスポンススキーマ適合性 — すべてのシグナルの必須フィールド。`get_signals` にゲートされる | | [`version_negotiation`](https://adcontextprotocol.org/compliance/latest/universal/version-negotiation) | リリース精度の `adcp.supported_versions` アドバタイズとレスポンスエンベロープの `adcp_version` エコー。3.1 では助言的、後のカットで昇格 | | [`v3_envelope_integrity`](https://adcontextprotocol.org/compliance/latest/universal/v3-envelope-integrity) | v3 プロトコルエンベロープは v2 レガシー `task_status` または `response_status` フィールドを持ってはならない（MUST NOT） — v3 では `status` が唯一の正準ライフサイクルフィールド | | [`error_compliance`](https://adcontextprotocol.org/compliance/latest/universal/error-compliance) | 構造化エラー形状、公開エラーコード、トランスポートバインディング、テナント間の存在リークなし | | [`error_compliance_signals`](https://adcontextprotocol.org/compliance/latest/universal/error-compliance-signals) | シグナルプロトコルのエラー処理 — 存在しないシグナル ID、欠けているフィールド、VERSION\_UNSUPPORTED、トランスポートバインディング。ディスカバリーフェーズは `get_signals` にゲートされる。アクティベーションフェーズは `signal-marketplace` のようなアクティベーションサポートを主張するエージェントのみ実行 | | [`stale_response_advisory`](https://adcontextprotocol.org/compliance/latest/universal/stale-response-advisory) | `STALE_RESPONSE` ワイヤー配置 — 助言は、トランスポート成功を保持した投入済み成功レスポンス上の `errors[]` に乗る。stale-cache 強制ステップは `force_upstream_unavailable` を伴う `comply_test_controller` にゲートされる | | [`idempotency`](https://adcontextprotocol.org/compliance/latest/universal/idempotency) | `idempotency_key` スコーピング、リプレイセマンティクス、`IDEMPOTENCY_CONFLICT`、`replayed: true`、宣言された TTL | | [`read_tool_idempotency`](https://adcontextprotocol.org/compliance/latest/universal/read-tool-idempotency) | 読み取り専用タスクラッパーは、厳格なリクエストラッパー拒否なしに 3.1 の全リクエスト `idempotency_key` エンベロープを受け入れる。3.1 の省略キー猶予プローブを含む | | [`canonical_format_validate_input`](https://adcontextprotocol.org/compliance/latest/universal/canonical-format-validate-input) | 正準形式 `validate_input` 結果セマンティクス: 必須スロット全体の構造的 pass/fail と、シードされた製品宣言の `unvalidatable_nondeterministic`。`validate_input` をアドバタイズするエージェントにゲートされる。シード製品分岐は `comply_test_controller` シードサポートも要求 | | [`security_baseline`](https://adcontextprotocol.org/compliance/latest/universal/security) | 未認証拒否、静的認証情報強制（Bearer API キーまたは HTTP Basic）、OAuth ディスカバリー + RFC 9728 オーディエンスバインディング | | [`webhook_emission`](https://adcontextprotocol.org/compliance/latest/universal/webhook-emission) | アウトバウンド webhook 適合性 — リトライ間で安定した `idempotency_key`、すべての配信での RFC 9421 webhook 署名（またはオプトイン HMAC フォールバック）。`push_notification_config` を受け入れる任意のエージェントで実行 | | [`webhook_receiver_envelope`](https://adcontextprotocol.org/compliance/latest/universal/webhook-receiver-envelope) | バイヤーレシーバーのリプレイ適合性: 完全な MCP webhook エンベロープを受け入れ、素の配信結果ペイロードを拒否し、生ボディバイト上で署名を検証し、`idempotency_key` でリトライを重複排除 | | [`notification_config_event_scope`](https://adcontextprotocol.org/compliance/latest/universal/notification-config-event-scope) | `sync_accounts.accounts[].notification_configs[]` セマンティック検証 — アカウントレベルのサブスクライバーは、それらの値が共有 enum で有効であってもメディアバイアンカーの通知タイプを拒否 | | [`notification_config_lifecycle`](https://adcontextprotocol.org/compliance/latest/universal/notification-config-lifecycle) | `sync_accounts` 上のアカウントレベル `notification_configs[]` ライフサイクル: 一時停止された登録、耐久性のある `list_accounts` エコー、サブスクライバーキーの置換、clear-all セマンティクス | | [`notification_config_rejections`](https://adcontextprotocol.org/compliance/latest/universal/notification-config-rejections) | 重複する `subscriber_id` 値のためのセマンティック `notification_configs[]` リクエスト拒否パス | | [`wholesale_feed_products`](https://adcontextprotocol.org/compliance/latest/universal/wholesale-feed-products) | 製品ホールセールフィードバージョニング: ブートストラップレスポンスは `wholesale_feed_version`/`cache_scope` を持ち、一致する `if_wholesale_feed_version` プローブは製品行なしで `unchanged` を返す | | [`wholesale_feed_signals`](https://adcontextprotocol.org/compliance/latest/universal/wholesale-feed-signals) | シグナルホールセールフィードバージョニング: ブートストラップレスポンスは `wholesale_feed_version`/`cache_scope` を持ち、一致する `if_wholesale_feed_version` プローブはシグナル行なしで `unchanged` を返す | | [`wholesale_feed_product_webhooks`](https://adcontextprotocol.org/compliance/latest/universal/wholesale-feed-product-webhooks) | 製品ホールセールフィード webhook イベントをアドバタイズするエージェントのアカウントレベル `notification_configs[]` 登録 | | [`wholesale_feed_signal_webhooks`](https://adcontextprotocol.org/compliance/latest/universal/wholesale-feed-signal-webhooks) | シグナルホールセールフィード webhook イベントをアドバタイズするエージェントのアカウントレベル `notification_configs[]` 登録 | | [`wholesale_feed_bulk_webhooks`](https://adcontextprotocol.org/compliance/latest/universal/wholesale-feed-bulk-webhooks) | `wholesale_feed.bulk_change` をアドバタイズするエージェントのアカウントレベル `notification_configs[]` 登録 | | [`pagination_integrity`](https://adcontextprotocol.org/compliance/latest/universal/pagination-integrity) | ページ化された `list_creatives` レスポンス上の `cursor` ↔ `has_more` 不変条件、継続ページから終端ページまで歩く | | [`get_products_pagination_integrity`](https://adcontextprotocol.org/compliance/latest/universal/get-products-pagination-integrity) | `get_products` ホールセールページネーションセマンティクス: シードされた製品フィードを継続から終端まで歩き、brief/refine をフィード列挙ではなく上限付きキュレート/リファイン回答として保持 | | [`get_signals_pagination_integrity`](https://adcontextprotocol.org/compliance/latest/universal/get-signals-pagination-integrity) | 広範なクエリの下でページ化された `get_signals` レスポンス上の `cursor` ↔ `has_more` 不変条件、任意の非自明なシグナルセットに対する最初のページ非終端アサーション付き | | [`pagination_integrity_list_accounts`](https://adcontextprotocol.org/compliance/latest/universal/pagination-integrity-list-accounts) | `list_accounts` レスポンス上の継続側ページネーション整合性。ストーリーボードは `sync_accounts` 経由で 3 つのサンドボックスアカウントをブートストラップし、最初のページで使用可能なカーソルを伴う `has_more=true` を要求し、そのカーソルを一度たどる | | [`pagination_integrity_creative_formats`](https://adcontextprotocol.org/compliance/latest/universal/pagination-integrity-creative-formats) | ページ化された `list_creative_formats` レスポンス上の `cursor` ↔ `has_more` 不変条件。ストーリーボードは `seed_creative_format` 経由で 2 つのクリエイティブフォーマットをシードし継続ページから終端ページまで歩く | | [`get_media_buys_pagination_integrity`](https://adcontextprotocol.org/compliance/latest/universal/get-media-buys-pagination-integrity) | ページ化された `get_media_buys` レスポンス上の `cursor` ↔ `has_more` 不変条件。ストーリーボードは `seed_media_buy` 経由で 3 つのメディアバイをシードし継続ページから終端ページまで歩く | | [`pagination_integrity_content_standards`](https://adcontextprotocol.org/compliance/latest/universal/content-standards-pagination-integrity) | ページ化された `list_content_standards` レスポンス上の `cursor` ↔ `has_more` 不変条件。ストーリーボードは `create_content_standards` 経由で 3 つのコンテンツ標準構成をブートストラップし継続ページから終端ページまで歩く | | [`pagination_integrity_collection_lists`](https://adcontextprotocol.org/compliance/latest/universal/collection-lists-pagination-integrity) | ページ化された `list_collection_lists` レスポンス上の `cursor` ↔ `has_more` 不変条件。ストーリーボードは `create_collection_list` 経由で 3 つのコレクションリストをブートストラップし継続ページから終端ページまで歩く | | [`pagination_integrity_property_lists`](https://adcontextprotocol.org/compliance/latest/universal/property-lists-pagination-integrity) | ページ化された `list_property_lists` レスポンス上の `cursor` ↔ `has_more` 不変条件。ストーリーボードは `create_property_list` 経由で 3 つのプロパティリストをブートストラップし継続ページから終端ページまで歩く | | [`deterministic_testing`](https://adcontextprotocol.org/compliance/latest/universal/deterministic-testing) | `comply_test_controller` ステートマシン — `capabilities.compliance_testing.supported: false` ならスキップ | | [`signed_requests`](https://adcontextprotocol.org/compliance/latest/universal/signed-requests) | RFC 9421 トランスポート層リクエスト署名検証 — `request_signing.supported: false` ならスキップ | | [`billing_gate_dispatch`](https://adcontextprotocol.org/compliance/latest/universal/billing-gate-dispatch) | `sync_accounts.billing` 拒否時の 2 ゲートディスパッチ: セラー全体のケイパビリティゲート（`error.details.scope` 付き `BILLING_NOT_SUPPORTED`）対 バイヤーエージェントごとの商業関係ゲート（クランプされた `rejected_billing` + オプションの `suggested_billing` 形状付き `BILLING_NOT_PERMITTED_FOR_AGENT`）。セラーが 3 つの `billing` 値すべてをサポートするときケイパビリティフェーズはスキップ。テストキットが `commercial_relationship: passthrough_only` を宣言しないときエージェントごとのフェーズはスキップ | `capabilities.compliance_testing.supported: true` を宣言するエージェントは、完全な [テストコントローラー](/docs/building/by-layer/L3/comply-test-controller) を実装しなければなりません（MUST）。部分的なコントローラーは非適合なので、出荷するより `false` を宣言してください。 `request_signing.supported: true` を宣言するエージェントは、[リクエスト署名プロファイル](/docs/building/by-layer/L1/security#署名付きリクエストトランスポート層) に従って完全な RFC 9421 検証者を実装しなければなりません（MUST）。部分的な検証者は非適合なので、出荷するより `false` を宣言してください。 ## Protocol 適合性 `supported_protocols` クレームはプロトコルのベースラインストーリーボードを義務付けます。 | `supported_protocols` | Storyboard | | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `media_buy` | [`media_buy_seller`](https://adcontextprotocol.org/compliance/latest/protocols/media-buy/) + [`media_buy_state_machine`](https://adcontextprotocol.org/compliance/latest/protocols/media-buy/state-machine) | | `creative` | [`creative_lifecycle`](https://adcontextprotocol.org/compliance/latest/protocols/creative/) | | `signals` | [`signals_baseline`](https://adcontextprotocol.org/compliance/latest/protocols/signals/) | | `governance` | [`media_buy_governance_escalation`](https://adcontextprotocol.org/compliance/latest/protocols/governance/) | | `brand` | [`brand_baseline`](https://adcontextprotocol.org/compliance/latest/protocols/brand/) | | `sponsored_intelligence` | [`si_baseline`](https://adcontextprotocol.org/compliance/latest/protocols/sponsored-intelligence/) | ## Specialism 適合性 `specialisms` クレームは、親プロトコルベースラインに加えて専門分野のストーリーボードを義務付けます。カタログは [`/compliance/latest/index.json`](https://adcontextprotocol.org/compliance/latest/index.json) に存在します。人間可読なインデックスは [コンプライアンスカタログ](/docs/building/verification/compliance-catalog) です。 専門分野は `status` を持ちます — `stable`（検証済み pass/fail）、`preview`（ストーリーボード未定義。ランナーは `passed: null` を発行）、`deprecated`（削除予定）。エージェントは preview 専門分野を主張してもよい（MAY）が、preview クレームは pass/fail 判定を生みません。 ## ワイヤーの外側 一部の要件はストーリーボードで検証できません。なぜならワイヤーレベルではなくオペレーターレベルだからです。それらは適合エージェントを運用することの一部のままですが、スイートはそれらを証明できません。オペレーターはこれらに対して自己評価しなければなりません（MUST）。第三者フレームワーク（SOC 2、ISO 27001）が通常の証明パスです。 * **シークレットストレージ** — 認証情報は KMS または同等物に存在すべきです（SHOULD）。ワイヤーは認証が成功するかどうかだけを示し、鍵がどこに保存されたかは示しません。 * **認証情報のローテーションと失効** — オペレーターは、侵害された認証情報を 1 時間未満で失効させる文書化されたパスを持たなければなりません（MUST）。ワイヤーはランブックを観測できません。 * **人員と物理的セキュリティ** — 誰が本番に触れられるか、ブレークグラス管理、従業員のオフボーディング。完全にプロトコルの外側。 * **ガバナンスエージェントのデューデリジェンス** — オペレーターが第三者ガバナンスエージェントに依存するとき、バイヤーはそれをマルチカスタマーの爆発半径を持つプロセッサーとして扱い、その姿勢を評価すべきです（SHOULD）。ストーリーボードはセラーによる正しい JWS 処理を検証しますが、ガバナンスエージェント自体を保証できません。 * **LLM サブプロセッサーの姿勢** — エージェントが LLM プロバイダーを使う場合、そのプロバイダーとの DPA が、プロンプト、ブランドアセット、クリエイティブメタデータが保持されうるかを統制します。プロトコルはアップストリームの DPA 条件を見られません。 * **インシデントレスポンス** — AdCP は監視する価値のあるシグナル（`IDEMPOTENCY_CONFLICT` スパイク、失敗したガバナンス検証、SSRF 拒否）を発行します。検出、アラートルーティング、レスポンスはオペレーターの関心事です。 * **データレジデンシー構成** — EU / UK データがリージョン内に保たれるかどうかとその方法は、通常エージェントのケイパビリティまたはコントラクトで宣言されます。ワイヤーは宣言を記録し、基盤インフラは記録しません。 完全なオペレーターチェックリスト: [セキュリティモデル § 本番稼働前に検証すべきもの](/docs/building/concepts/security-model#what-to-verify-before-going-live)。 ## 適合性 対 外部保証 適合性はワイヤーレベルの正しさです。SOC 2、ISO 27001、NIST CSF は運用保証です。それらは異なる質問に答え、どちらも他方の代替にはなりません。 | 外部制御領域 | ストーリーボード証拠 | 外部保証へのギャップ | | ----------------------------------- | --------------------------------------------------- | -------------------------------- | | アクセス制御（SOC 2 CC6、ISO 27001 A.5.15） | `security_baseline`（アイデンティティ）+ プロトコルストーリーボードの分離チェック | 人員アクセスレビュー、最小権限管理、オフボーディング | | 変更管理（SOC 2 CC8） | `idempotency` はワイヤー上で重複状態変更が防がれることを証明 | デプロイ承認、リリースゲート、ロールバック手順 | | システム監視（SOC 2 CC7、ISO 27001 A.8.16） | エラー分類が監視可能な表面を生成 | 検出エンジニアリング、アラートルーティング、オンコールランブック | | 暗号（ISO 27001 A.8.24） | TLS、RFC 9421 署名、JWS ガバナンストークン | KMS 選択、ローテーション頻度、証明書ライフサイクル | | 監査ログ（SOC 2 CC7） | ガバナンスストーリーボードは署名付きレコード発行を検証 | ログ保持、リーガルホールド、整合性監視 | | データ処理（SOC 2 Privacy、GDPR、ISO 27701） | TMP 2 コール分離、オーディエンスハッシュ、シグナルアクセス制御 | データ主体の権利、DPA 管理、越境転送 | | ベンダーとサブプロセッサーリスク（SOC 2 CC9） | `adagents.json` / brand.json ディスカバリー、JWKS 公開 | 第三者リスク評価、LLM プロバイダーレビュー | | インシデントレスポンス（SOC 2 CC7、NIST CSF RS） | シグナルは観測可能。レスポンスは義務化されない | ランブック、机上演習、侵害通知 | | 事業継続（ISO 27001 A.5.30） | クロスインスタンス状態ストーリーボードチェック | RPO/RTO 目標、DR テスト | 2 つの実践的帰結: 1. ストーリーボード通過証拠は特定の外部制御目標をサポートしてもよい（MAY）。監査の代替にはなりません。 2. 外部認証は AdCP 適合性を含意しません。SOC 2 Type II は `create_media_buy` レスポンスが検証されるかどうかについて何も言いません。 ## 適合性を主張する方法 1. `get_adcp_capabilities` で `supported_protocols` と `specialisms` を宣言する。 2. 宣言が義務付けるすべてのストーリーボード — universal + protocol ベースライン + specialism ベースライン — を特定の AdCP メジャーバージョンで通過する。 3. 宣言と動作を同期に保つ。スイートがたまたまテストする未宣言のケイパビリティは、失敗する宣言済みケイパビリティとは別です。両方とも非適合です。 適合性はバージョンごとです。スイートはバージョンごとです。3.0 適合のエージェントはそれによって 3.1 適合にはなりません。 **第三者証明のために**、AAO に対してハートビートを実行し [AAO Verified バッジ](/docs/building/verification/compliance-catalog) を獲得してください。バッジは、AAO がエージェントを最近テストし通過がまだ保持されているという署名付きクレームです。*verified* でフィルターするバイヤーは *conformant* より小さいセットを得ます — より少ないエージェント、より新鮮な証明、責任を負う名指しされた当事者。 ## この文書がしないこと * **個々の MUST を定義する。** ストーリーボードがします。ルールがストーリーボードにないなら、それは適合性の一部ではありません。 * **認定を付与または取り消す。** [AgenticAdvertising.org 認定プログラム](/docs/learning/overview) がこの上に走ります。適合性は必要ですが十分ではありません。 * **既にスイートにあるもの以外のリファレンステストベクターを公開する。** [リファレンステストベクターインデックス](/docs/reference/test-vectors) は今日出荷されるベクターセットをカタログ化します。より広範なタスクレベルコーパスは 3.0 GA と 3.1 の間で漸増的に到達し、[#2383](https://github.com/adcontextprotocol/adcp/issues/2383) でスコープされます。 ## ストーリーボードが失敗するとき 失敗が仕様、モック、SDK 間の不一致を表面化するとき、以下のセクションはトリアージ順を与えます。症状から原因への検索については、このセクション末尾のリンクを参照してください。 ### Mock-server authority and failure triage `adcp mock-server` は安定表面のリファレンスワイヤー実装です。ストーリーボードの失敗がモックまたは SDK を巻き込むとき、このトリアージ順を使ってください: **トリアージ順: spec → mock → SDK。** ストーリーボード（とそれらが参照するスキーマ）は正準です。モックはストーリーボードを解釈します。SDK はモックを通じてプロトコルを消費します。 | Condition | Default verdict | Next step | | ---------------------------------------------- | --------------- | ---------------------------------------------------- | | SDK ワイヤー形状がモックのものと **異なる** | SDK が間違い | SDK に対してバグを提出 | | SDK ワイヤー形状がモックのものと **一致** するが、ストーリーボードが依然として失敗 | モックが間違い | モックを修正するため `adcontextprotocol/adcp` に issue を提出 | | ストーリーボードアサーションが、それ以外は通過するワイヤー形状と衝突 | ストーリーボードが間違い | ストーリーボードを修正するため `adcontextprotocol/adcp` に issue を提出 | | 仕様テキスト（ストーリーボード散文またはスキーマ）がモックと明示的に矛盾 | 仕様が勝つ。モックがバグ | モックを修正するため `adcontextprotocol/adcp` に issue を提出 | **スコープ。** このトリアージ順は安定表面のみに適用されます。実験的表面（[実験的ステータス](/docs/reference/experimental-status) を参照）は活発な改訂中です。そこでのモック動作はまだ権威的ではありません。 **仕様の曖昧性 対 仕様の沈黙。** 仕様テキストが存在するが曖昧なとき、モックの動作が権威的解釈をピン留めします — そのピン留めは散文がまだ引き締められていなくても規範的です。仕様がある点について完全に沈黙しモックがそれに対する動作を持たないとき、チェーンは切れます。モックを権威的として扱うのではなく [known-ambiguities issue](/docs/building/cross-cutting/known-ambiguities) を開いてください。 * **[ストーリーボードのトラブルシューティング](/docs/building/operating/storyboard-troubleshooting)** — 最も一般的なストーリーボード失敗のエラーパターン → 根本原因 → 修正 * **[既知の仕様曖昧性](/docs/building/cross-cutting/known-ambiguities)** — 回避策と issue リンク付きのオープンな仕様ギャップ。基盤 issue がクローズすると項目は削除される ## さらに読む * **[AAO Verified](/docs/building/verification/aao-verified)** — セラーのライブ広告サーバー統合の継続的可観測性検証 * **[コンプライアンスカタログ](/docs/building/verification/compliance-catalog)** — ストーリーボード ID 付きプロトコルと専門分野の完全な分類 * **[エージェントを検証する](/docs/building/verification/validate-your-agent)** — スイートを実行する方法 * **[セキュリティモデル](/docs/building/concepts/security-model)** — セキュリティストーリーボードが強制する 5 つの防御層の戦略的フレーミング * **[Security（実装リファレンス）](/docs/building/by-layer/L1/security)** — ストーリーボードが引用する規範的ルール * **[バージョニング](/docs/reference/versioning)** — メジャーバージョンサポートウィンドウ * **[既知の制限](/docs/reference/known-limitations)** — 仕様の可視な縁