ケイパビリティエクスプローラー
このページは、get_adcp_capabilities レスポンスの実際のトップレベル形状をレンダリングします。新しいケイパビリティを提案する前に、その正しい場所を見つけられるようにするためです。拡張 RFC がはね返される最も一般的な理由は形状の誤りです: 提案が、類似のフラグがすでに存在する場所と一致しないレベルにフラグを置くことです。まずツリーをたどってください。
RFC を起草しにここに来たなら、ワークフローはこうです:
- 下から、あなたのフラグに最も近い既存のトップレベルドメインを見つける。
- そのドメインのサブ名前空間（
features、executionなど）に掘り下げる。 - あなたのフラグが既存のサブ名前空間に適合するなら、そこに提案する。該当ノードの propose extension here リンクを使う — issue タイトルにパスが事前入力される。
- 何も適合しないなら、末尾の Before proposing a new top-level key までスクロールし、RFC 本文でゲート質問に答える。
static/schemas/source/protocol/get-adcp-capabilities-response.json にあります。下のツリーは、リッチなドメインについて 1 レベル深さにキュレーションされています。完全なネスト形状についてはスキーマを読んでください。設計原則 — 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 への拡張を提案する
supported_protocols — このエージェントが実装する AdCP プロトコル
プロトコル名の配列。各値はエージェントを (a) それらのツールの実装、かつ (b) /compliance/{version}/protocols/{protocol}/ のベースラインコンプライアンスストーリーボードの合格にコミットします。
有効な値は media_buy、creative、signals、governance、sponsored_intelligence、brand、accounts、measurement（開発中）をカバーします。
supported_protocols に追加する新しいプロトコルを提案する
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 への拡張を提案する
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 のノートを参照。audience_targeting— 宣言されたオーディエンスターゲティングケイパビリティ。content_standards— コンテンツ標準の強制ケイパビリティ。conversion_tracking— コンバージョントラッキングケイパビリティ。offline_delivery_protocols— サポートするオフライン配信プロトコル（放送トラフィッキングなど）。portfolio— ポートフォリオ管理ケイパビリティ。reporting_delivery_methods— レポートがどう配信されるか。supported_pricing_models— 配列（CPM、CPC、CPCV、CPP、fixed など）。
media_buy.features にフラグを提案する
media_buy.execution への拡張を提案する
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 にフラグを提案する
governance — ガバナンスプロトコルのケイパビリティ
プロパティとクリエイティブのガバナンスケイパビリティ。
property_features— ガバナンスエージェントがプロパティリストで何をするか。creative_features— ガバナンスエージェントがクリエイティブレビューのために何をするか。aggregation_window_days— エージェントがガバナンスイベントを集約する期間。
governance への拡張を提案する
sponsored_intelligence — 会話的なブランド体験
SI セッションを扱うエージェント向け。
endpoint— SI エンドポイント URL。brand_url— ブランドアイデンティティ URL。capabilities— SI 固有のケイパビリティ（コマースハンドオフ、音声、UI コンポーネントなど）。
sponsored_intelligence への拡張を提案する
brand — ブランドプロトコルのケイパビリティ
ブランドエージェント向け。
description— エージェントの説明。available_uses— ブランドデータが何にライセンスされているか。generation_providers— サポートする生成プロバイダー。right_types— エージェントが付与する権利タイプ。rights— このエージェントが発行する具体的な権利。
brand への拡張を提案する
creative — クリエイティブプロトコルのケイパビリティ
クリエイティブエージェント向け。
has_creative_library— エージェントがクリエイティブライブラリを維持するか。supports_compliance— クリエイティブコンプライアンススキャン。supports_generation— 生成クリエイティブケイパビリティ。supports_transformation— クリエイティブ変換ケイパビリティ。
creative への拡張を提案する
request_signing — インバウンドリクエスト用の RFC 9421 HTTP Signatures
3.0 では任意。ケイパビリティとしてアドバタイズされ、当事者が選択的に署名にオプトインできる。
supported— boolean。required_for— 署名が必須の操作の配列。supported_for— 署名がサポートされる操作の配列。warn_for— 未署名リクエストが警告を生む操作の配列。covers_content_digest— 署名がリクエストボディのダイジェストをカバーするか。
request_signing への拡張を提案する
webhook_signing — アウトバウンド webhook 用の RFC 9421 署名
request_signing のトップレベルの対等物。
supported— boolean。profile— 署名プロファイル名。algorithms— サポートする署名アルゴリズム。legacy_hmac_fallback— レガシー受信者に対して HMAC フォールバックがサポートされるか。
webhook_signing への拡張を提案する
identity — オペレーターアイデンティティ姿勢
鍵スコーピングと侵害対応の制御。3.x では助言的、4.0 で必須。
per_principal_key_isolation— 各プリンシパルが分離された鍵を持つか。key_origins— 宣言された鍵管理の由来。compromise_notification— 鍵侵害イベントの通知姿勢。
identity への拡張を提案する
measurement — 測定ケイパビリティ（開発中）
広告配信、エクスポージャー、または効果についての定量的メトリクス。
metrics— このエージェントが発するメトリクス定義の配列。
measurement への拡張を提案する
compliance_testing — 決定的テストシナリオ
エージェントが comply_test_controller をサポートすること、およびどのシナリオが尊重されるかを宣言します。
scenarios— エージェントがサポートするコンプライアンスシナリオ ID の配列。
compliance_testing への拡張を提案する
specialisms — kebab-case の専門分野 ID
任意。専門分野のコンプライアンスクレーム（例: creative-generative、sales-non-guaranteed）。値はワーキンググループに登録された kebab-case enum ID です。
新しい専門分野を提案する
ドメインでない「このエージェントがすること」
3 つのトップレベルリストが、単一のプロトコルドメインに適合しないケイパビリティメタデータを運びます。それらのあいだの形状の不一致は未解決リストにあります（設計原則 — Where the surface doesn’t yet follow these）。extensions_supported— このエージェントが埋める拡張名前空間の配列（ext.{namespace}）。experimental_features— このエージェントが実装する実験的サーフェス ID の配列（例:trusted_match.core）。compliance_testing— 上でカバー済み。
新しいトップレベルキーを提案する前に
あなたのフラグが上の 14 のドメインのどれにも本当に適合しないなら、RFC を開いてください — ただし本文でこれらのゲート質問に答えてください。ほとんどのレビュアーはそれらを期待します。それらを無視する RFC ははね返される傾向があります。- 最も近い既存のトップレベルドメインはどれか？ それを名指しする。なぜあなたのフラグがそのドメインの
features、execution、その他のサブ名前空間への拡張でないかを説明する。 - なぜこれが
ext.{vendor}拡張でないのか？ ベンダー固有の振る舞いはベンダー名前空間に属する（プラットフォーム非依存性についての spec-guidelines）。なぜあなたのフラグがすべての実装者にわたって規範的なのか？ - 適合性プローブは何か？ ケイパビリティ宣言はアドバタイズメントではなくコミットメントです。あなたのフラグを宣言するセラーが実際にそれを尊重することを、適合性ランナーはどう検証するか？
- これは何を排除するか？ このトップレベルキーを追加することでどの提案が容易になり — 1 年後にトップレベルをスキャンする人にとって何が難しくなるか？
関連
- 設計原則 — ケイパビリティサーフェス形状の背後にある理由付け。
get_adcp_capabilitiesタスクリファレンス — フィールドごとに文書化されたレスポンススキーマ。- 仕様ガイドライン — 型の命名、enum 設計、ベンダー中立ルール。