> ## 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 コンプライアンスランナーが専門分野宣言を具体的なグレードされたストーリーボードのセットにどう変換するか — そしてケイパビリティフラグがどうそのセットを変えるか。 [適合性仕様](/docs/building/verification/conformance#conformance-is-layered) は 3 つの義務層を定義します: Universal、Protocol、Specialism。このページは Specialism 層の内側で何が起こるかを説明します: 専門分野マニフェストがどうグレードされるシナリオのセットに解決するか、シナリオごとのケイパビリティゲートがどうそのセットを狭めるか広げるか。 ## 宣言からグレードされるシナリオへ エージェントが `get_adcp_capabilities` で専門分野を宣言すると、ランナーは: 1. `/compliance/{version}/specialisms/{id}/` の専門分野マニフェストをフェッチ。 2. マニフェストの `requires_scenarios` リスト — ランナーがグレードしなければならないシナリオ ID の順序付きセット — を読む。 3. 各シナリオについて、シナリオが `requires_capability` ゲートを宣言するかを確認。 4. ゲートが存在する場合、シナリオを実行するかスキップするかを決めるため、`get_adcp_capabilities` レスポンスから名前付きパスを読む。 マニフェストが完全なシナリオリストを駆動します。ケイパビリティゲートはその上にシナリオごとに適用されます。 ## ランナー証拠対検証ポリシー ストーリーボードランナーは、エージェントがバッジを獲得するか特定のバイヤーを満たすかを決めません。証拠を生成します: 実行されたアサーション、失敗、選択されたがスキップされたステップ、選択されなかったステップ、スキップ理由、使われたエンドポイント/実行モード。検証ポリシーがその証拠を消費し、どのギャップが名前付きの結果に許容可能かを決めます。 | Question | Decided by | Evidence used | | ------------------------------------------ | ----------------------------- | ---------------------------------------------------------------- | | 「このステップはストーリーボードに一致したか？」 | ストーリーボードランナー | ステップ検証とレスポンススキーマ | | 「このエージェントは **Verified (Spec)** を獲得するか？」 | AgenticAdvertising.org 検証ポリシー | 登録された spec/test エンドポイントに対するランナー証拠、加えてメンバーシップと宣言チェック | | 「このエージェントは **Verified (Sandbox)** を獲得するか？」 | AgenticAdvertising.org 検証ポリシー | `account.sandbox: true` の下の本番エンドポイントに対するランナー証拠、加えてサンドボックス分離チェック | | 「これは特定のバイヤーに十分か？」 | そのバイヤーの要件プロファイル | Verified モード、宣言されたプロトコル/専門分野、要求する任意ケイパビリティ、AdCP 外の任意のビジネスまたは統合要件 | これがランナー分類が重要な理由です。「これはサンドボックス専用実行なので選択されなかった」はスイート選択の事実で、セラーケイパビリティギャップではありません。「セラーが任意機能を主張しなかったのでスキップ」はバッジに許容可能でも、その機能を要求するバイヤーには許容不可能かもしれません。「宣言された必須ツールが欠けているのでスキップ」はセラー実装問題です。 ## 要件プロファイル 「何を通過する必要があるか？」に答えるには、満たそうとしているプロファイルから始めます: | Target | Minimum question the profile answers | | ---------------------- | ------------------------------------------------------------------------------------------------------------ | | **Verified (Spec)** | 宣言された AdCP サーフェスは、ブロックする欠けたツールや失敗したアサーションなしに、登録された spec/test エンドポイントで必須ストーリーボードを通過するか？ | | **Verified (Sandbox)** | 登録された本番エンドポイントは、サンドボックス分離が強制され Sandbox 許容可能なスキップのみが存在する状態で、`account.sandbox: true` の下でサンドボックス検証プロファイルを通過するか？ | | **特定バイヤー要件** | このバイヤーはどの verified モード、プロトコル、専門分野、任意ケイパビリティ、運用動作、スキップクラスを要求するか？ | バイヤー要件プロファイルは公開バッジより厳格でありえます。例えば、公開 Sandbox プロファイルは `media_buy.supports_proposals: false` のときケイパビリティゲートのプロポーザルストーリーボードがスキップされるのを受け入れられます。プロポーザルワークフローを要求するバイヤーは同じスキップをブロッカーとして扱えます。逆に、`comply_test_controller` を省略する本番エンドポイントは Sandbox バッジに許容可能でも、決定的統合テストをするバイヤーはそれを公開する別の dev/staging エンドポイントを求めるかもしれません。 ストーリーボードランナーはそれらのバイヤー決定をエンコードすべきではありません。検証ポリシーやバイヤープロファイルが一貫して評価できる型付き証拠を発すべきです。 ## 専門分野マニフェスト 各専門分野の `requires_scenarios` フィールドは、ランナーがグレードするシナリオをリストします。例 — `sales-guaranteed` マニフェストは 8 つの必須シナリオを宣言します: ```yaml theme={null} # /compliance/{version}/specialisms/sales-guaranteed/ (source: static/compliance/source/specialisms/sales-guaranteed/index.yaml) id: sales_guaranteed requires_scenarios: - media_buy_seller/refine_products - media_buy_seller/delivery_reporting - media_buy_seller/measurement_terms_rejected - media_buy_seller/pending_creatives_to_start - media_buy_seller/inventory_list_targeting - media_buy_seller/inventory_list_no_match - media_buy_seller/invalid_transitions - media_buy_seller/proposal_finalize # ← capability-gated ``` これらの 7 つは任意の `sales-guaranteed` エージェントに無条件で実行されます。8 つ目 — `proposal_finalize` — はケイパビリティゲートを運びます。 ## ケイパビリティゲート シナリオまたはフェーズは `requires_capability` ブロックを宣言できます。ランナーは `get_adcp_capabilities` レスポンスから名前付きパスを読み、期待される値に対して確認します。チェックが失敗（ケイパビリティが欠如または false）すると、シナリオまたはフェーズはスキップされ — `skip` ブロックが `reason: not_applicable` でランナー出力に現れ — `steps_failed` に寄与しません。 ```yaml theme={null} # /compliance/{version}/protocols/media-buy/scenarios/proposal_finalize/ (source: static/compliance/source/protocols/media-buy/scenarios/proposal_finalize.yaml) id: media_buy_seller/proposal_finalize requires_capability: path: media_buy.supports_proposals equals: true ``` ゲートは、実行時にエージェントのライブ `get_adcp_capabilities` レスポンスに対して評価されます — ランナーが universal `capability_discovery` ストーリーボード中に行うのと同じ呼び出し。 フェーズレベルのゲートは同じ形状を使い、ブロックを宣言するフェーズのみをスコープします。Universal ストーリーボードはこれをプロトコル固有のフェーズファミリーに使います。例えば、決定的テストは、エージェントが `sponsored_intelligence` を宣言しないとき SI セッションフェーズをスキップし、エージェントが宣言するメディアバイまたはクリエイティブフェーズは依然実行します。 ## 実践例 **シナリオ:** Priya の StreamHaus プラットフォームが `sales-guaranteed` を主張し `media_buy.supports_proposals: true` を宣言。 ```json theme={null} { "supported_protocols": ["media_buy"], "specialisms": ["sales-guaranteed"], "media_buy": { "supports_proposals": true } } ``` **ランナー動作:** `proposal_finalize` を含む 8 つすべての `requires_scenarios` が実行される。Priya のプラットフォームは完全なプロポーザルライフサイクル — プロポーザル付きブリーフ、refine、finalize、`create_media_buy` 経由の実行 — でグレードされる。 *** **シナリオ:** StreamHaus Direct はオークションベースの PG プラットフォーム — プロポーザル抽象なし。`sales-guaranteed` を主張し `media_buy.supports_proposals: false` を宣言。 ```json theme={null} { "supported_protocols": ["media_buy"], "specialisms": ["sales-guaranteed"], "media_buy": { "supports_proposals": false } } ``` **ランナー動作:** 7 つのシナリオが実行され、`proposal_finalize` はスキップされる。ランナー出力の `skip` ブロックが権威あるシグナル: ```json theme={null} { "storyboard_id": "media_buy_seller/proposal_finalize", "skip": { "reason": "not_applicable", "detail": "requires_capability check: media_buy.supports_proposals must equal true — agent declared false" } } ``` `skip` ブロックが存在するとき、ステップはグレードされず `steps_failed` にカウントされません。`skip.detail` 文字列が特定の原因（ケイパビリティゲート、欠けている専門分野宣言、欠けているツール）を識別します。 **欠如 = false。** `supports_proposals` フィールドはケイパビリティスキーマで `"default": false` を持ちます。レスポンスから省略することは `false` を宣言するのと等価です — ランナーはケイパビリティゲートのプロポーザルシナリオをスキップします。グレーディングにオプトインするには `true` を明示的に宣言してください。 このフラグはグレーディングゲートのみです。バイヤーエージェントはそれを特定のプロポーザルが実行可能かを決めるのに使うべきではありません。セラーがプロポーザルを返す場合、`proposal_status` が真実の源泉です: `draft` は create の前に finalize を要求、`committed` は `expires_at` の前に実行可能、欠如したステータスはレガシーの ready-to-buy。 ## 一目でのグレーディング判定 | Outcome | Output field | Meaning | | -------- | -------------------------------------------------------------- | --------------------------------------------------------------- | | シナリオ合格 | `skip` なしのステップ結果、`passed: true` | すべての検証が通過 | | シナリオ失敗 | `skip` なしのステップ結果、`passed: false` | 1 つ以上の必須検証が失敗。失敗フィールドと `json_pointer` については `validations[]` を参照 | | シナリオ未選択 | `run_summary.not_selected[].reason`、`steps_not_selected` にカウント | 呼び出し元の選択スイート、実行モード、バージョン、検証プロファイルが実行前にこのシナリオを除外 | | シナリオスキップ | `skip.reason: not_applicable` | シナリオは選択されたが、適用性ゲートが false と評価、例えばセラーが主張しなかった任意ケイパビリティ | | 必須ツール欠如 | `skip.reason: missing_tool` | シナリオは選択されエージェントは専門分野を宣言したが、`required_tools` にリストされたツールを公開しなかった | 実行の全体的なコンプライアンス判定は `steps_failed` によって決定されます。スキップされたステップ（`skip` ブロック存在）と未選択アイテム（`run_summary.not_selected[]` エントリ）はそのカウンターに寄与しませんが、異なることを意味します。`steps_not_selected` は、ランナーがこの実行からそれらのシナリオを意図的に除外したことを言います。`steps_skipped` は、ランナーがそれらのシナリオを選択したが実行できなかったことを言います。任意ケイパビリティ選択を欠けている必須サーフェスから区別するには `skipped_by_reason` と `skip.detail` を使います。 したがってサンドボックス専用実行は、除外された作業のみが選択モード外のとき、こう見えるべきです: ```json theme={null} { "summary": { "steps_passed": 84, "steps_failed": 0, "steps_skipped": 0, "steps_not_selected": 80, "not_selected_by_reason": { "run_mode_excluded": 80 } } } ``` それらの 80 アイテムが代わりに `steps_skipped` の下に現れる場合、それらは選択されてからスキップされた。それは異なるシグナルで `skipped_by_reason` が必要です。 ## 合格対部分カバレッジ ランナーサマリーは **失敗** を **カバレッジ** から区別します: | Run shape | What it means | Seller action | | ---------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ---------------------------------------------------------------- | | `steps_failed > 0` | 実行したステップでストーリーボードアサーションが失敗 | 対応するプロトコルや専門分野を主張する前にエージェントを修正 | | `steps_failed = 0`、カバレッジギャップスキップなし | 宣言されたスコープの完全合格 | 宣言されたプロトコル、専門分野、ケイパビリティフラグがクリーンにグレードされた | | `steps_failed = 0`、`steps_not_selected > 0` のみ | 要求されたスイートまたは実行モードが一部のプローブを意図的に除外、例えばサンドボックス専用実行中の live-only チェック | 実装依頼なし。実行モードを明確にラベル | | `steps_failed = 0`、ケイパビリティゲート `not_applicable` スキップのみ | より狭い宣言スコープ、失敗でない | エージェントが任意ケイパビリティを正直に辞退、例えば `media_buy.supports_proposals: false` | | `steps_failed = 0`、`missing_test_controller` スキップ | 決定的テストサーフェスのカバレッジギャップ | dev/staging の決定的パスを実行するかスキップされたライフサイクルカバレッジを明示的に公開 | | 宣言されたプロトコルや専門分野の任意の `missing_tool`、`requirement_unmet`、`unsatisfied_contract` スキップ | セラーがランナーが完全にテストできないクレームを宣言 | 欠けているサーフェスを修正するか宣言を狭める | この区別は本番パスのサンドボックス実行に重要です。セラーは、サンドボックスフラグ付きトラフィックの下で実際の本番エンドポイントに対してストーリーボードスイートを実行し **ゼロ失敗** を得ながら、本番エンドポイントが正しく `comply_test_controller` を公開しないため依然として `partial` サマリーを見られます。その結果はこう言います: 「バイヤー可視のサンドボックスパスはランナーがグレードできたすべてのアサーションを通過したが、コントローラーシードのライフサイクルシナリオはスキップされた」。それはサンドボックス準備の有用な証拠ですが、完全な決定的専門分野カバレッジと同じではありません。 完全なカバレッジには、コントローラーを公開する dev または staging エンドポイントに対して同じ宣言スコープを実行するか、必要な状態を事前シードしランナーがシードされた状態のカバレッジをアサートするよう設定します。本番のみのセラーには、バイヤーが何がグレードされ何がされなかったかを正確に見られるよう、スキップされたカバレッジリストをゼロ失敗結果と並んで公開します。 ## 各部品がどこに存在するか | Artifact | URL path | Source | | ------------------ | -------------------------------------------------------------- | --------------------------------------------------------------------- | | 専門分野マニフェスト | `/compliance/{version}/specialisms/{id}/` | `static/compliance/source/specialisms/{id}/index.yaml` | | シナリオ YAML | `/compliance/{version}/protocols/{protocol}/scenarios/{name}/` | `static/compliance/source/protocols/{protocol}/scenarios/{name}.yaml` | | Universal ストーリーボード | `/compliance/{version}/universal/` | `static/compliance/source/universal/` | | ケイパビリティスキーマ | `/schemas/v3/protocol/get-adcp-capabilities-response.json` | `static/schemas/source/protocol/get-adcp-capabilities-response.json` | 完全な専門分野からシナリオへのインデックスは [Compliance Catalog](/docs/building/verification/compliance-catalog) にあります。すべてのスキップ理由と判定形状を定義するランナー出力コントラクトは `static/compliance/source/universal/runner-output-contract.yaml` にあります。 ## 関連 * [適合性仕様](/docs/building/verification/conformance) — 3 層義務モデルと規範的ストーリーボードインデックス * [Compliance Catalog](/docs/building/verification/compliance-catalog) — プロトコル、専門分野、universal ストーリーボードの完全タクソノミー * [エージェントを検証する](/docs/building/verification/validate-your-agent) — `@adcp/sdk` でスイートをローカルで実行