3 つではなく 2 つの言葉
AdCP 適合性には 2 つの荷重を担う用語があります。3 つ目（実世界で耳にするもの）は罠です。- Conformant（適合） — エージェントが規範的ルールを満たす。この文書がインデックスするストーリーボードで定義される。
- Verified — AAO がエージェントを最近テストし署名付き証明を発行した。アクティブなメンバーシップとライブなハートビートにゲートされる。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 の判定 については AAO Verified を参照してください。このページの残りは両方の修飾子を裏付けるストーリーボードをインデックスします。
テスト表面とストーリーボードループ
すべてのセラーは テスト表面 を公開します — ストーリーボードランナーが実世界の副作用を引き起こすことなくセラーのツールを決定的に行使できるようにするメカニズム。テスト表面は (Spec) がグレードされる対象です。セラーがその表面をどう立ち上げるかは、状態の記録がどこに存在するかに依存します。実装は異なり、目標は異なりません:
両方のパスが
(Spec) を獲得します — 両方ともセラーのワイヤー形式がストーリーボードに一致することを証明します。ブリッジはテスト表面パターンの 1 つの実装 であり、別のセラーカテゴリーではありません。配線されたシードのない状態ローカルセラーと、配線されたブリッジのないアップストリームプロキシセラーは同じ立場にあります: ストーリーボードはそれらに対してエンドツーエンドで実行できません。どちらのカテゴリーも (Sandbox) が証明するものではありません。(Sandbox) は、セラーの本番スタックが実世界の副作用なしに account.sandbox: true を尊重するかどうかをカバーする別の軸です。
フィクスチャマージ済みとアップストリーム由来のレスポンスを区別する
レスポンスが SDK のTestControllerBridge を通過するとき、SDK はレスポンスに _bridge: { callback, tool, merged_count } マーカーをスタンプします。ステップ上のマーカーの存在は、レスポンス内容がセラーのハンドラーが返した後にシードされたフィクスチャからマージされたことを意味します。マーカーの不在は、レスポンスがセラーのアダプターからエンドツーエンドで来た（またはランナーが直接シードしたローカル DB から来た）ことを意味します。マーカーはランナーと下流リーダーボード用の助言的メタデータであり、ワイヤーコントラクトの一部では ありません。セラーはそれを発行してはならず（MUST NOT）、適合性チェックはそれを無視します。先頭のアンダースコアはフィールドをテストツール用に予約された SDK/ランナースタンプメタデータとしてマークします。同じプレフィックスを持つ将来のフィールドは同じルールに従います。
マーカー設計: adcp-client#1775。出荷済み: adcp-client#1786。マーカーを消費するリーダーボードポリシー: adcp-client#1782。
3 つのシグナル — 混同しないこと
採用者はしばしばこれら 3 つの制御を同じものとして読みます。それらは異なる質問に答えます:
これらは個々のストーリーボードステップ上の ランタイム制御 です — ストーリーボードの通過が時間をかけて何を 証明する かを記述する
(Spec) と (Sandbox) の検証修飾子とは別。ストーリーボードの通過は 3 つのシグナルの任意の組み合わせを持ちうる。
ストーリーボードが真実
すべての MUST を散文で再述する — それは避けがたく実行可能なスイートからドリフトする — のではなく、ストーリーボードが適合性仕様そのものです。 この文書はそれらへのナビゲーショナルインデックスで、ストーリーボードの実行を義務付ける宣言でグループ化されています。 スイート内のすべての規範的ルールはちょうど 1 つの居場所を持ちます:/compliance/latest/ のストーリーボード YAML。「適合」が何を意味するかの変更はそこで、バージョン管理されたリリースで、実エージェントに対してテストされて起こります。ルールがストーリーボードにないなら、それは適合性の一部ではありません。
これは意図的です。ストーリーボードルールを再述する別の散文仕様は 2 つの真実の源泉を作ります。2 つの真実の源泉はドリフトします。私たちは 1 つを選びます: スイート。
@adcp/sdk パッケージは、ストーリーボード駆動の comply() に先行する testing/scenarios/ 下の TypeScript ファイルも出荷します。それらは適合性仕様では ありません — どちらがどれかについては Storyboards 対 scenarios を参照してください。Conformance is layered
すべてのエージェントは universal 層を満たします。各supported_protocols クレームはプロトコルベースラインを追加します。各 specialisms クレームは専門分野ベースラインを追加します。
エージェントは、そのストーリーボードを通過しないケイパビリティを宣言してはなりません（MUST NOT）。完全な分類については コンプライアンスカタログ を、スイートをローカルで実行する方法については エージェントを検証する を参照してください。
Universal 適合性
すべてのエージェントは以下のすべてのストーリーボードを通過しなければなりません（MUST）。capabilities.compliance_testing.supported: true を宣言するエージェントは、完全な テストコントローラー を実装しなければなりません（MUST）。部分的なコントローラーは非適合なので、出荷するより false を宣言してください。
request_signing.supported: true を宣言するエージェントは、リクエスト署名プロファイル に従って完全な RFC 9421 検証者を実装しなければなりません（MUST）。部分的な検証者は非適合なので、出荷するより false を宣言してください。
Protocol 適合性
supported_protocols クレームはプロトコルのベースラインストーリーボードを義務付けます。
Specialism 適合性
specialisms クレームは、親プロトコルベースラインに加えて専門分野のストーリーボードを義務付けます。カタログは /compliance/latest/index.json に存在します。人間可読なインデックスは コンプライアンスカタログ です。
専門分野は 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 データがリージョン内に保たれるかどうかとその方法は、通常エージェントのケイパビリティまたはコントラクトで宣言されます。ワイヤーは宣言を記録し、基盤インフラは記録しません。
適合性 対 外部保証
適合性はワイヤーレベルの正しさです。SOC 2、ISO 27001、NIST CSF は運用保証です。それらは異なる質問に答え、どちらも他方の代替にはなりません。
2 つの実践的帰結:
- ストーリーボード通過証拠は特定の外部制御目標をサポートしてもよい（MAY）。監査の代替にはなりません。
- 外部認証は AdCP 適合性を含意しません。SOC 2 Type II は
create_media_buyレスポンスが検証されるかどうかについて何も言いません。
適合性を主張する方法
get_adcp_capabilitiesでsupported_protocolsとspecialismsを宣言する。- 宣言が義務付けるすべてのストーリーボード — universal + protocol ベースライン + specialism ベースライン — を特定の AdCP メジャーバージョンで通過する。
- 宣言と動作を同期に保つ。スイートがたまたまテストする未宣言のケイパビリティは、失敗する宣言済みケイパビリティとは別です。両方とも非適合です。
この文書がしないこと
- 個々の MUST を定義する。 ストーリーボードがします。ルールがストーリーボードにないなら、それは適合性の一部ではありません。
- 認定を付与または取り消す。 AgenticAdvertising.org 認定プログラム がこの上に走ります。適合性は必要ですが十分ではありません。
- 既にスイートにあるもの以外のリファレンステストベクターを公開する。 リファレンステストベクターインデックス は今日出荷されるベクターセットをカタログ化します。より広範なタスクレベルコーパスは 3.0 GA と 3.1 の間で漸増的に到達し、#2383 でスコープされます。
ストーリーボードが失敗するとき
失敗が仕様、モック、SDK 間の不一致を表面化するとき、以下のセクションはトリアージ順を与えます。症状から原因への検索については、このセクション末尾のリンクを参照してください。Mock-server authority and failure triage
adcp mock-server は安定表面のリファレンスワイヤー実装です。ストーリーボードの失敗がモックまたは SDK を巻き込むとき、このトリアージ順を使ってください:
トリアージ順: spec → mock → SDK。 ストーリーボード（とそれらが参照するスキーマ）は正準です。モックはストーリーボードを解釈します。SDK はモックを通じてプロトコルを消費します。
スコープ。 このトリアージ順は安定表面のみに適用されます。実験的表面（実験的ステータス を参照）は活発な改訂中です。そこでのモック動作はまだ権威的ではありません。
仕様の曖昧性 対 仕様の沈黙。 仕様テキストが存在するが曖昧なとき、モックの動作が権威的解釈をピン留めします — そのピン留めは散文がまだ引き締められていなくても規範的です。仕様がある点について完全に沈黙しモックがそれに対する動作を持たないとき、チェーンは切れます。モックを権威的として扱うのではなく known-ambiguities issue を開いてください。
- ストーリーボードのトラブルシューティング — 最も一般的なストーリーボード失敗のエラーパターン → 根本原因 → 修正
- 既知の仕様曖昧性 — 回避策と issue リンク付きのオープンな仕様ギャップ。基盤 issue がクローズすると項目は削除される
さらに読む
- AAO Verified — セラーのライブ広告サーバー統合の継続的可観測性検証
- コンプライアンスカタログ — ストーリーボード ID 付きプロトコルと専門分野の完全な分類
- エージェントを検証する — スイートを実行する方法
- セキュリティモデル — セキュリティストーリーボードが強制する 5 つの防御層の戦略的フレーミング
- Security（実装リファレンス） — ストーリーボードが引用する規範的ルール
- バージョニング — メジャーバージョンサポートウィンドウ
- 既知の制限 — 仕様の可視な縁