障害モード能力スコープ
このドキュメントは、各 AdCP 障害モードシナリオを、それが属する認定モジュールにマップし、ティアごとの深さターゲットを指定し、評価アプローチを定義します。これはスコープアーティファクトです — 各モジュールの実際のコンテンツの作成は、モジュールごとのフォローアップ issue で追跡されます。 以下で使われる深さレベル:FM-1 — 冪等性リプレイ / コンフリクト / 期限切れ
ステータス: 部分的にカバー。#2346 と #2367 がトレーニングエージェントに冪等性を確立しました。このエントリーは評価スコープを統合します。
作成前に閉じるギャップ: S1 ラボ演習 7（「ライフサイクル管理」）が
NOT_CANCELLABLE だけでなく 3 つのエラー状態すべてをサンドボックスでステージングすることを確認。そうでない場合、演習 7 を IDEMPOTENCY_CONFLICT と IDEMPOTENCY_EXPIRED をカバーするよう拡張。
FM-2 — ローンチ後のクリエイティブコンプライアンス障害
ステータス: まだどのモジュールにもない。前提読書は S2 と S4 に存在するが、ローンチ後の発見パスをウォークするラボ演習はない。
作成前に閉じるギャップ:
validate_content_delivery を使ってローンチ後コンプライアンス障害を明示的にステージングする番号付きラボ演習を S2 に追加。前提読書カードは存在する; 演習は存在しない。ステージングされたシナリオなしでは、評価は完全に会話に依存し、IACET Element 7（実証可能な能力証拠）を満たせない。作成 issue は、読書カードがラボ演習として提出されるのを防ぐため 3 つのことを指定しなければならない: (a) サンドボックスエージェントは、シミュレートされたフライト開始イベント後に特定のクリエイティブ ID で validate_content_delivery 違反を返すよう構成されなければならない; (b) 学習者は同じセッション内で get_media_buy_artifacts を呼び、監査アーティファクトを違反に相関させなければならない; (c) これは安定した基準 ID（例: s2_postlaunch_sc0）を持つ必須デモンストレーションを構成する — 再認定機構は ID が存在するときのみ発火する。
FM-3 — 支払い / 決済の照合差異
ステータス: まだどのモジュールにもない。スキーマは#2391（billing reconciliation、AdCP 3.1）で最終化中。現在の配信とアカウンタビリティ条件の表面に対して今スコープ; #2391 が着地したとき深さが拡大する。
作成のためのフラグ: 作成時に安定した基準 ID（例:
s1_recon_sc0）を割り当てる。#2391 が照合スキーマを出荷したとき、現在の基準の下で発行された S1 クレデンシャルはターゲットを絞った再認定のためフラグされなければならない — インストラクショナルデザインフレームワークの再認定機構は基準 ID が存在するときのみ発火する。これを暗黙のままにしないこと。
#2391 保留の深さ TBD: billing reconciliation スキーマが着地したら、新しい決済フィールドをカバーする 2 番目の基準（s1_recon_sc1）を追加。その追加前に発行されたクレデンシャルは、プロトコルトリガー再認定ポリシーに従い再認定の候補。
FM-4 — ガバナンストークン不一致 / ライフサイクル途中の認可失効
ステータス: 部分的にカバー。S4 はGOVERNANCE_DENIED 回復、15 ステップの JWS 検証、governance_context 相関モデルをカバー。ライフサイクル途中の失効はチェック時の拒否とは別で、まだシナリオとして名指されていない。
作成前に閉じるギャップ: S4 の「あなたがデモンストレーションすること」セクションは 15 ステップの JWS 検証と
governance_context 相関モデルをカバーするが、ライフサイクル途中の失効を個別のシナリオとして名指していない。それをデモンストレーション項目として追加し、ラボ演習 7（「GOVERNANCE_DENIED 回復」）を実行中失効バリアントで拡張。
FM-5 — ライフサイクル状態がスタック（メディアバイ、クリエイティブ、アカウント、SI セッション、カタログ）
ステータス: 明示的な障害モードシナリオとしてまだどのモジュールにもない。S1 ラボ演習 6 はpending_start からの強制拒否をカバーするが、レスポンスなしのタイムアウトはカバーしない。S5 は通常の SI セッション管理をカバーするが、スタックまたは期限切れセッションはカバーしない。
作成前に閉じるギャップ:
- S5 の現在の「あなたがデモンストレーションすること」は通常のセッション管理のみをカバー。セッション期限切れとスタックセッション回復を明示的なデモンストレーション項目として追加。
- S1 ラボ演習 6 は、既にステージングされた強制拒否とは別に、レスポンスなしのタイムアウトケースのために拡張（またはバリアント追加）されるべき。
FM-6 — Webhook 配信障害 / リトライ
ステータス: 障害シナリオとしてまだどのモジュールにもない。D3 の前提読書はエラー処理を参照するが、webhook 障害をカバーするラボ演習や評価次元はない。
作成前に閉じるギャップ: webhook 配信障害をエンドツーエンドでウォークするシナリオを D3 のエラー処理議論内に追加（必ずしも完全な新演習でなくてよい）。D3 は現在エラー処理ドキュメントを前提読書としてリストするが、運用回復をテストするラボ演習や評価項目がない。
FM-7 — 署名付きリクエスト検証障害
ステータス: 障害シナリオとしてまだどのモジュールにもない。S1 はバイヤーアイデンティティ解決チェーン（署名 → JWKS → エージェントエントリー → brand.json）を概念的にカバーするが、fail-closed 実装をテストするモジュールはない。
基準 ID に関する注記: RFC 9421 リクエスト署名への将来の変更が両モジュールで独立して再認定をトリガーするよう、作成時に D2（
d2_sig_sc0）と S1（s1_sig_sc0）に別々の基準 ID を割り当てる。
関連（下の FM-C）: エージェントディスカバリー時の adagents.json / brand.json 認可障害は、別途スコープされる密接に関連したオンボーディング障害モード。
FM-8 — TMP プロバイダー統合障害
ステータス: 「TMP 証明障害」から再分類。TMP 暗号証明は AdCP 3.0 で SHOULD（MUST ではない）で、仕様で「将来の拡張」とマークされている — 現在の適合性モデルは HTTPS 上のadagents.json 経由のパブリッシャー証明。メカニズムが安定する前に暗号証明障害を認定トピックとして教えることは、現在のプロトコル動作ではなく将来のフィーチャーの知識をクレデンシャル化することになる。今日の運用上の実際の障害モードは: (1) adagents.json バインディング障害 — プロバイダーがリストされていない、seller_agent URL 不一致、または bypass モード誤構成; (2) TMP Router プロバイダー構成障害; (3) 統合誤構成による Identity Match が結果を返さず、フリークエンシーキャップロジックが no-cap 動作にフォールバックする。ホームは S3 ではなく S1 — TMP はメディアバイ実行メカニズムで、シグナル / オーディエンストピックではない。
延期: 暗号証明障害シナリオは、TMP が実験的ステータスから移行したときに追加される。
作成前に閉じるギャップ: S1 ラボ演習 9 に障害バリアントを追加 — 同じクロスパブリッシャー抑制シナリオだが、Identity Match が
adagents.json 誤構成のため結果を返さない。これは既存演習の拡張で、新しいものではない。
FM-9 — クロスプロトコルポリシー衝突
ステータス: まだどのモジュールにもない。S4 はガバナンスドメイン（campaign、property、collection、content standards、creative）の合成をカバーするが、複数ドメインからのルールが衝突し裁定されなければならないシナリオを含まない。
S4 の根拠（新しいクロスドメインセクションではなく）: S4 は既に、campaign、property、collection、content standards、creative にわたる相互作用を含むガバナンスドメインの合成をカバー。クロスプロトコルシナリオは既存の S4 スコープの拡張で、S4 + S3 前提知識で評価可能。新しいモジュールセクションは、この issue が明示的に延期する作成スコープを要求する。
#2391 のためのフラグ: billing reconciliation が支払い認可にガバナンス次元を導入する場合（例: 支出を制約するプランが billing reconciliation ルールに対して検証しなければならない）、#2391 が閉じたときその相互作用のための 2 番目の基準 ID を S4 に追加。
FM-A — アカウント支払い要求がアクティブバイをブロック
ステータス: 元の候補リストにない。カリキュラムレビュー中に実際の高頻度運用障害として識別。アカウントステートマシンはアカウントがpayment_required に遷移することを許可し、それは新しい支出をブロックするが飛行中のキャンペーンを終了しない。すべての認可障害を一時的として扱うバイヤーエージェントは過剰リトライする; それらを致命的として扱うエージェントは依然として変更可能なキャンペーンの管理を止める。どちらの動作も正しくない。
FM-B — report_usage 価格不一致
ステータス: 元の候補リストにない。課金紛争トリガーとして識別: バイヤーがreport_usage でバイ時に交渉されたレートに一致しない pricing_option_id をレポートし、セラーエージェントがそれを拒否する。これは、価格オプション ID がバイとレポート呼び出しの間で変わる CPA とパフォーマンス価格キャンペーンで運用上苦痛。
スコープ注記:
#2391 が正式な billing reconciliation メカニズムを導入する場合、この障害モードは FM-3 と統合された決済モジュールにマージするかもしれない。#2391 が閉じたときレビューのためフラグ。
FM-C — ディスカバリー時の adagents.json / brand.json 認可障害
ステータス: 元の候補リストにない。新規統合の最も一般的なオンボーディング障害として識別: バイヤーエージェントがget_adcp_capabilities 経由で販売エージェントを発見し、OAuth 認証を試み、バイヤーの adagents.json が正しい authorized_agents[] 関係を宣言しない — または brand.json エントリーが署名付きリクエストで提示されたエージェントアイデンティティに一致しない — ため、セラーがトークンを拒否する。