> ## 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. # ケイパビリティエクスプローラー > get_adcp_capabilities レスポンススキーマの参照可能なビュー — すべてのトップレベルドメイン、すべてのサブ名前空間を、アンカーと「ここに拡張を提案」リンク付きで示し、新しいフラグが正しいホームに着地するようにする。 # ケイパビリティエクスプローラー このページは、[`get_adcp_capabilities`](/docs/protocol/get_adcp_capabilities) レスポンスの実際のトップレベル形状をレンダリングします。新しいケイパビリティを提案する前に、その正しい場所を見つけられるようにするためです。拡張 RFC がはね返される最も一般的な理由は形状の誤りです: 提案が、類似のフラグがすでに存在する場所と一致しないレベルにフラグを置くことです。まずツリーをたどってください。 RFC を起草しにここに来たなら、ワークフローはこうです: 1. 下から、あなたのフラグに最も近い既存のトップレベルドメインを見つける。 2. そのドメインのサブ名前空間（`features`、`execution` など）に掘り下げる。 3. あなたのフラグが既存のサブ名前空間に適合するなら、そこに提案する。該当ノードの **propose extension here** リンクを使う — issue タイトルにパスが事前入力される。 4. 何も適合しないなら、末尾の **Before proposing a new top-level key** までスクロールし、RFC 本文でゲート質問に答える。 権威あるスキーマは [`static/schemas/source/protocol/get-adcp-capabilities-response.json`](https://github.com/adcontextprotocol/adcp/blob/main/static/schemas/source/protocol/get-adcp-capabilities-response.json) にあります。下のツリーは、リッチなドメインについて 1 レベル深さにキュレーションされています。完全なネスト形状についてはスキーマを読んでください。[設計原則 — Capabilities are commitments, declared under existing buckets](/docs/protocol/design-principles#4-capabilities-are-commitments-declared-under-existing-buckets) も参照。 *** ## トップレベルドメイン 下の 14 のドメインが `get_adcp_capabilities` のトップレベルサーフェス全体です。すべてのケイパビリティフラグは、最終的にこれらの 1 つの下にネストします。新しいトップレベルキーは極めてまれで、最初の一手であるべきではありません — このページ末尾のゲート質問を参照。 ### `adcp` — コアプロトコルアイデンティティ バージョンネゴシエーション、冪等性コントラクト、ビルド識別子。 * **`supported_versions`** — リリース精度の文字列（例: `"3.0"`、`"3.1"`）。バイヤー側のリリースピン留めについて権威的。 * **`major_versions`** — `supported_versions` を優先して非推奨。セラーは 3.x を通じて発し続けなければならない（MUST）。 * **`build_version`** — 完全な semver ビルド識別子。バイヤー側のインシデントトリアージ用の助言的メタデータ。 * **`idempotency`** — リプレイセマンティクスを宣言する判別共用体（`IdempotencySupported` / `IdempotencyUnsupported`）。**ここでの宣言はコミットメント** — `supported: true` を宣言するセラーは適合性ランナーにプローブされる。 [`adcp` への拡張を提案する](https://github.com/adcontextprotocol/adcp/issues/new?title=Extend+adcp+capability:+%3Cflag%3E\&body=Schema+location:+%60.adcp%60%0AExisting+keys:+supported_versions,+major_versions,+build_version,+idempotency%0A%0A%23%23+Proposal%0A%0A...%0A%0A%23%23+Why+this+belongs+under+%60adcp%60+and+not+a+new+top-level+key%0A%0A...\&labels=rfc,capabilities) *** ### `supported_protocols` — このエージェントが実装する AdCP プロトコル プロトコル名の配列。各値はエージェントを (a) それらのツールの実装、かつ (b) `/compliance/{version}/protocols/{protocol}/` のベースラインコンプライアンスストーリーボードの合格にコミットします。 有効な値は `media_buy`、`creative`、`signals`、`governance`、`sponsored_intelligence`、`brand`、`accounts`、`measurement`（開発中）をカバーします。 [`supported_protocols` に追加する新しいプロトコルを提案する](https://github.com/adcontextprotocol/adcp/issues/new?title=Add+protocol+to+supported_protocols:+%3Cname%3E\&body=%23%23+Proposal%0A%0A...%0A%0A%23%23+Compliance+storyboard+plan%0A%0AHow+will+the+baseline+conformance+suite+exercise+this+protocol?+...\&labels=rfc,capabilities,new-protocol) *** ### `account` — アカウント確立と課金 アカウントがどう交渉されるか、プロダクトディスカバリーの前に必要か、どの課金モデルがサポートされるか。 * **`required_for_products`** — boolean。true のとき、`get_products` は確立されたアカウントを必要とする。 * **`authorization_endpoint`** — アカウント交渉用の OAuth/auth URL。 * **`require_operator_auth`** — オペレーターレベルの認証が必要かを宣言する。 * **`supported_billing`** — 課金モデルの配列（例: `prepaid`、`monthly_invoice`）。 * **`account_financials`** — セラーが公開する財務データ（クレジット上限、現在残高など）。 * **`sandbox`** — サンドボックスアカウントのケイパビリティ。 [`account` への拡張を提案する](https://github.com/adcontextprotocol/adcp/issues/new?title=Extend+account+capability:+%3Cflag%3E\&body=Schema+location:+%60.account%60\&labels=rfc,capabilities) *** ### `media_buy` — メディア購入のケイパビリティ 最大のドメイン。サブ名前空間が、ほとんどのメディア購入フラグが属する場所です。 * **`features`** — boolean 機能フラグ（例: `inline_creative_management`、`property_list_filtering`、`catalog_management`、`committed_metrics_supported`）。**新しいメディア購入ケイパビリティフラグのほとんどはここに属する。** * **`execution`** — 技術的実行ケイパビリティ。`trusted_match`（TMP）、`creative_specs`（VAST/MRAID/VPAID/SIMID バージョン）、`targeting`（geo / audience / device / temporal）、`axe_integrations`（非推奨）を含む。`trusted_match` の配置については [設計原則 — Where the surface doesn't yet follow these](/docs/protocol/design-principles#where-the-surface-doesnt-yet-follow-these-principles) のノートを参照。 * **`audience_targeting`** — 宣言されたオーディエンスターゲティングケイパビリティ。 * **`content_standards`** — コンテンツ標準の強制ケイパビリティ。 * **`conversion_tracking`** — コンバージョントラッキングケイパビリティ。 * **`offline_delivery_protocols`** — サポートするオフライン配信プロトコル（放送トラフィッキングなど）。 * **`portfolio`** — ポートフォリオ管理ケイパビリティ。 * **`reporting_delivery_methods`** — レポートがどう配信されるか。 * **`supported_pricing_models`** — 配列（CPM、CPC、CPCV、CPP、fixed など）。 [`media_buy.features` にフラグを提案する](https://github.com/adcontextprotocol/adcp/issues/new?title=Add+media_buy+feature:+%3Cflag%3E\&body=Schema+location:+%60.media_buy.features%60%0A%0A%23%23+Proposal%0A%0A...%0A%0A%23%23+Why+a+feature+flag+and+not+a+new+task%0A%0A...%0A%0A%23%23+Conformance+probe%0A%0AHow+can+a+buyer+verify+this+capability+is+actually+honored?+...\&labels=rfc,capabilities) [`media_buy.execution` への拡張を提案する](https://github.com/adcontextprotocol/adcp/issues/new?title=Extend+media_buy.execution:+%3Cflag%3E\&body=Schema+location:+%60.media_buy.execution%60%0AExisting+sub-keys:+trusted_match,+creative_specs,+targeting\&labels=rfc,capabilities) *** ### `signals` — オーディエンスとコンテキストデータのアクティベーション signals ドメインの認可スコープと機能フラグ。 * **`data_provider_domains`** — このシグナルエージェントが再販を認可されているドメインの配列。バイヤーは検証のため各プロバイダーの `adagents.json` を取得する。 * **`features`** — boolean 機能フラグ。`catalog_signals` は非推奨。構造化 `signal_ref` サポートは Signals プロトコルの一部であり、機能フラグを必要とすべきでない。**追加のシグナルケイパビリティフラグはここに属し**、新しいトップレベルキーには属さない。（例: 直接販売ターゲティング用の `signal_enforcement_on_guaranteed` フラグは、`media_buy.execution.trusted_match` の下ではなく `signals.features` に属する。） [`signals.features` にフラグを提案する](https://github.com/adcontextprotocol/adcp/issues/new?title=Add+signals+feature:+%3Cflag%3E\&body=Schema+location:+%60.signals.features%60%0A%0A%23%23+Proposal%0A%0A...%0A%0A%23%23+Conformance+probe%0A%0A...\&labels=rfc,capabilities,signals) *** ### `governance` — ガバナンスプロトコルのケイパビリティ プロパティとクリエイティブのガバナンスケイパビリティ。 * **`property_features`** — ガバナンスエージェントがプロパティリストで何をするか。 * **`creative_features`** — ガバナンスエージェントがクリエイティブレビューのために何をするか。 * **`aggregation_window_days`** — エージェントがガバナンスイベントを集約する期間。 [`governance` への拡張を提案する](https://github.com/adcontextprotocol/adcp/issues/new?title=Extend+governance+capability:+%3Cflag%3E\&body=Schema+location:+%60.governance%60\&labels=rfc,capabilities,governance) *** ### `sponsored_intelligence` — 会話的なブランド体験 SI セッションを扱うエージェント向け。 * **`endpoint`** — SI エンドポイント URL。 * **`brand_url`** — ブランドアイデンティティ URL。 * **`capabilities`** — SI 固有のケイパビリティ（コマースハンドオフ、音声、UI コンポーネントなど）。 [`sponsored_intelligence` への拡張を提案する](https://github.com/adcontextprotocol/adcp/issues/new?title=Extend+sponsored_intelligence+capability:+%3Cflag%3E\&body=Schema+location:+%60.sponsored_intelligence%60\&labels=rfc,capabilities) *** ### `brand` — ブランドプロトコルのケイパビリティ ブランドエージェント向け。 * **`description`** — エージェントの説明。 * **`available_uses`** — ブランドデータが何にライセンスされているか。 * **`generation_providers`** — サポートする生成プロバイダー。 * **`right_types`** — エージェントが付与する権利タイプ。 * **`rights`** — このエージェントが発行する具体的な権利。 [`brand` への拡張を提案する](https://github.com/adcontextprotocol/adcp/issues/new?title=Extend+brand+capability:+%3Cflag%3E\&body=Schema+location:+%60.brand%60\&labels=rfc,capabilities) *** ### `creative` — クリエイティブプロトコルのケイパビリティ クリエイティブエージェント向け。 * **`has_creative_library`** — エージェントがクリエイティブライブラリを維持するか。 * **`supports_compliance`** — クリエイティブコンプライアンススキャン。 * **`supports_generation`** — 生成クリエイティブケイパビリティ。 * **`supports_transformation`** — クリエイティブ変換ケイパビリティ。 [`creative` への拡張を提案する](https://github.com/adcontextprotocol/adcp/issues/new?title=Extend+creative+capability:+%3Cflag%3E\&body=Schema+location:+%60.creative%60\&labels=rfc,capabilities,creative) *** ### `request_signing` — インバウンドリクエスト用の RFC 9421 HTTP Signatures 3.0 では任意。ケイパビリティとしてアドバタイズされ、当事者が選択的に署名にオプトインできる。 * **`supported`** — boolean。 * **`required_for`** — 署名が必須の操作の配列。 * **`supported_for`** — 署名がサポートされる操作の配列。 * **`warn_for`** — 未署名リクエストが警告を生む操作の配列。 * **`covers_content_digest`** — 署名がリクエストボディのダイジェストをカバーするか。 [`request_signing` への拡張を提案する](https://github.com/adcontextprotocol/adcp/issues/new?title=Extend+request_signing+capability:+%3Cflag%3E\&body=Schema+location:+%60.request_signing%60\&labels=rfc,capabilities,security) *** ### `webhook_signing` — アウトバウンド webhook 用の RFC 9421 署名 `request_signing` のトップレベルの対等物。 * **`supported`** — boolean。 * **`profile`** — 署名プロファイル名。 * **`algorithms`** — サポートする署名アルゴリズム。 * **`legacy_hmac_fallback`** — レガシー受信者に対して HMAC フォールバックがサポートされるか。 [`webhook_signing` への拡張を提案する](https://github.com/adcontextprotocol/adcp/issues/new?title=Extend+webhook_signing+capability:+%3Cflag%3E\&body=Schema+location:+%60.webhook_signing%60\&labels=rfc,capabilities,security) *** ### `identity` — オペレーターアイデンティティ姿勢 鍵スコーピングと侵害対応の制御。3.x では助言的、4.0 で必須。 * **`per_principal_key_isolation`** — 各プリンシパルが分離された鍵を持つか。 * **`key_origins`** — 宣言された鍵管理の由来。 * **`compromise_notification`** — 鍵侵害イベントの通知姿勢。 [`identity` への拡張を提案する](https://github.com/adcontextprotocol/adcp/issues/new?title=Extend+identity+capability:+%3Cflag%3E\&body=Schema+location:+%60.identity%60\&labels=rfc,capabilities,security) *** ### `measurement` — 測定ケイパビリティ（開発中） 広告配信、エクスポージャー、または効果についての定量的メトリクス。 * **`metrics`** — このエージェントが発するメトリクス定義の配列。 ケイパビリティディスカバリーを超えたプロトコルサーフェス（レポート、アトリビューションタスク）は後続のマイナーに着地します。 [`measurement` への拡張を提案する](https://github.com/adcontextprotocol/adcp/issues/new?title=Extend+measurement+capability:+%3Cflag%3E\&body=Schema+location:+%60.measurement%60\&labels=rfc,capabilities,measurement) *** ### `compliance_testing` — 決定的テストシナリオ エージェントが `comply_test_controller` をサポートすること、およびどのシナリオが尊重されるかを宣言します。 * **`scenarios`** — エージェントがサポートするコンプライアンスシナリオ ID の配列。 [`compliance_testing` への拡張を提案する](https://github.com/adcontextprotocol/adcp/issues/new?title=Extend+compliance_testing+capability:+%3Cflag%3E\&body=Schema+location:+%60.compliance_testing%60\&labels=rfc,capabilities,compliance) *** ### `specialisms` — kebab-case の専門分野 ID 任意。専門分野のコンプライアンスクレーム（例: `creative-generative`、`sales-non-guaranteed`）。値はワーキンググループに登録された kebab-case enum ID です。 [新しい専門分野を提案する](https://github.com/adcontextprotocol/adcp/issues/new?title=Add+specialism:+%3Ckebab-case-id%3E\&body=%23%23+Specialism+ID%0A%0A%3Ckebab-case-id%3E%0A%0A%23%23+What+it+claims%0A%0A...%0A%0A%23%23+Conformance+criteria%0A%0AHow+do+we+verify+an+agent+actually+meets+this+claim?+...\&labels=rfc,capabilities,specialism) *** ## ドメインでない「このエージェントがすること」 3 つのトップレベルリストが、単一のプロトコルドメインに適合しないケイパビリティメタデータを運びます。それらのあいだの形状の不一致は未解決リストにあります（[設計原則 — Where the surface doesn't yet follow these](/docs/protocol/design-principles#where-the-surface-doesnt-yet-follow-these-principles)）。 * **`extensions_supported`** — このエージェントが埋める拡張名前空間の配列（`ext.{namespace}`）。 * **`experimental_features`** — このエージェントが実装する実験的サーフェス ID の配列（例: `trusted_match.core`）。 * **`compliance_testing`** — 上でカバー済み。 *** ## 新しいトップレベルキーを提案する前に あなたのフラグが上の 14 のドメインのどれにも本当に適合しないなら、RFC を開いてください — ただし本文でこれらのゲート質問に答えてください。ほとんどのレビュアーはそれらを期待します。それらを無視する RFC ははね返される傾向があります。 1. **最も近い既存のトップレベルドメインはどれか？** それを名指しする。なぜあなたのフラグがそのドメインの `features`、`execution`、その他のサブ名前空間への拡張*でない*かを説明する。 2. **なぜこれが `ext.{vendor}` 拡張でないのか？** ベンダー固有の振る舞いはベンダー名前空間に属する（[プラットフォーム非依存性についての spec-guidelines](/docs/spec-guidelines#platform-agnosticism)）。なぜあなたのフラグがすべての実装者にわたって規範的なのか？ 3. **適合性プローブは何か？** ケイパビリティ宣言はアドバタイズメントではなくコミットメントです。あなたのフラグを宣言するセラーが実際にそれを尊重することを、適合性ランナーはどう検証するか？ 4. **これは何を排除するか？** このトップレベルキーを追加することでどの提案が容易になり — 1 年後にトップレベルをスキャンする人にとって何が難しくなるか？ これらはレビュアーが問う質問と同じです。RFC でそれらに答えることで往復を省けます。 [新しいトップレベルケイパビリティキーを提案する（ゲート質問に答えた後にのみ使用）](https://github.com/adcontextprotocol/adcp/issues/new?title=Propose+new+top-level+capability+key:+%3Cname%3E\&body=%23%23+Proposed+top-level+key%0A%0A%3Cname%3E%0A%0A%23%23+Gate+questions%0A%0A**1.+Which+existing+top-level+domain+is+closest+and+why+isn%27t+this+an+extension+there?**%0A%0A...%0A%0A**2.+Why+isn%27t+this+an+%60ext.%7Bvendor%7D%60+extension?**%0A%0A...%0A%0A**3.+What%27s+the+conformance+probe?**%0A%0A...%0A%0A**4.+What+does+this+rule+out?**%0A%0A...\&labels=rfc,capabilities,new-top-level-key) *** ## 関連 * [設計原則](/docs/protocol/design-principles) — ケイパビリティサーフェス形状の背後にある理由付け。 * [`get_adcp_capabilities` タスクリファレンス](/docs/protocol/get_adcp_capabilities) — フィールドごとに文書化されたレスポンススキーマ。 * [仕様ガイドライン](/docs/spec-guidelines) — 型の命名、enum 設計、ベンダー中立ルール。