> ## 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 3.0 の明示的な非目標と延期項目 — プロトコルが何をしないか。実装者とレビュアーがそれに応じて計画できるように。

プロトコルが何を*しない*かを知ることは、それを評価することの一部です。このページは、AdCP 3.0 の明示的な非目標と延期項目を統合します — プロトコルが意図的に扱わないもの、このサイクルでスコープ外にされたもの、メカニズムとして存在するがプロトコル層で強制されないもの。

下記の各制限は、仕様の可視な端か、追跡されたフォローアップのいずれかです。どれも隠されていません。

3.x で出荷されたがまだ凍結されていないサーフェスは別途リストされます — [実験的ステータス](/docs/reference/experimental-status) を参照。

## セキュリティとプライバシー

* **エンドユーザー認証なし。** AdCP はエージェントを認証し、それらが代わりに動作する人間を認証しません。ユーザーレベルのアイデンティティ、同意取得、データ主体の権利は、バイヤーのスタックで上流で扱われ、プロトコルのスコープ外です。
* **プロトコルレベルの侵害通知 SLA なし。** AdCP は「セラーは鍵侵害の疑いから N 時間以内にバイヤーに通知しなければならない」を仕様化しません。通知コミットメントは当事者間の DPA に存在します。将来のメジャーバージョンがこれを厳格化するかもしれません。
* **プロトコルに組み込まれた協調的脆弱性開示なし。** 個々のエージェントオペレーターは `/.well-known/security.txt` を公開すべきです。まだ規範的な AdCP 要件はありません。
* **プロトコルレベルの PII トランスポートなし。** `sync_audiences` の `hashed_email` と `hashed_phone` フィールドは、バイヤー側での SHA-256 ハッシュ化を要求します — スキーマはそれらのフィールドに平文を受け入れません。非 PII 空間のために他の識別子タイプが存在します。ワイヤー上に平文 PII が必要なら、AdCP は正しいキャリアではありません。
* **ハッシュ化識別子は仮名であり匿名ではない。** email と phone の SHA-256 ハッシュは GDPR と CPRA の下で仮名識別子のままで、基底の PII の規制的扱いを継承します。AdCP は非識別化を主張しません。
* **プロトコルレベルのデータレジデンシーメカニズムなし。** レジデンシーは個々のエージェントの設定と契約のプロパティです。プロトコルは規範的なレジデンシータグを運びません。
* **LLM プロンプトインジェクション防御についてのプロトコル保証なし。** それはループ内のすべての LLM 駆動エージェントのオペレーターの関心事です。[Security Model — エージェンティック広告に固有の脅威](/docs/building/concepts/security-model#threats-specific-to-agentic-advertising) を参照。
* **構造的プライバシーは TMP にのみ適用される。** Trusted Match Protocol はプライバシーを構造的に強制します（分離されたコードパス、スキーマ上の禁止）。他のすべてのドメインは契約的機密性またはセッションごとの同意に依存します。[ドメインをまたぐプライバシー姿勢](/docs/protocol/architecture#privacy-posture-across-domains) を参照。
* **ワイヤー上の管轄区域認識の同意シグナルなし。** AdCP は規範的な同意タグ（例: ケベックの Law 25、日本の APPI、ブラジルの LGPD のような制度への準拠を表現するのに使われる IAB TCF、GPP、同等物）を運びません。合法的根拠の判断、同意取得、管轄ルーティングは、それぞれのスタックでコントローラーまたはプロセッサーとして動作する各当事者の責任のままで、それらの間の DPA によって統治されます。構造化されたクロスエージェント同意シグナルは将来の作業の候補です。
* **プロトコル境界をまたいだ同意スコープの伝播なし。** ある同意スコープの下でアクティベートされたシグナル（例: ファーストパーティ広告同意を持つ CRM からの `sync_audiences`）は、スコープ整合を強制するプロトコルレベルのメカニズムなしに下流で参照 — 再ターゲット、別のキャンペーンに添付、または他のシグナルと合成 — できます。各当事者は DPA と運用制御を通じてオフプロトコルでスコープ互換性を検証します。3.1 に向けて [#2540](https://github.com/adcontextprotocol/adcp/issues/2540) で追跡。
* **プロトコルレベルの越境転送メカニズムなし。** AdCP は SCC、IDTA、または十分性決定のメタデータを運びません。国際転送の合法性は当事者の契約と設定のプロパティです。
* **バージョン管理されたコンテンツ来歴チェーンなし。** AdCP は権利利用アサーションと `ai_generated_image` フラグを運びます — 後者は boolean マーカーであり、署名された来歴アサーションではありません。プロトコルは、クリエイティブが生成、編集、適応ステップを通過するにつれアサーションを蓄積する暗号学的に署名された来歴グラフを仕様化しません。新興のコンテンツ真正性標準（CAI/C2PA）との相互運用は将来の作業として追跡されます。
* **保持または削除 SLA なし。** プロトコルは、当事者が `sync_audiences` 入力、`report_usage` レコード、タスク履歴をどのくらい保持するかを仕様化しません。保持ウィンドウとデータ主体リクエストの履行は当事者間の DPA に存在します。
* **汎用の同期 RPC レスポンス署名は定義されていない（指定タスクのペイロードエンベロープを除く） — 省略ではなく設計による。** AdCP はアプリケーション層で 5 つのものに署名します: インバウンドリクエスト（RFC 9421、`adcp_use: "request-signing"`）、ブランド権利、AAO Verified コンプライアンス、セールスインテリジェンスリレー、双方向の否認防止領収書などすべての専門分野スコープの永続的アーティファクトを含むアウトバウンド webhook（RFC 9421、`adcp_use: "request-signing"`。非推奨の `webhook-signing` キーは互換性ウィンドウ中受け入れられたまま）、ガバナンスアテステーション（JWS、`adcp_use: "governance-signing"`）、指定タスクのレスポンスペイロード — 現在は `verify_brand_claim` ファミリーのみ（JWS ペイロードエンベロープ、`adcp_use: "response-signing"`）、Trusted Match Protocol エンベロープ（TMP 独自の Ed25519 プロファイル）。`tools/call`（または同等の A2A 非ストリーミング応答 / ストリーミング `artifactUpdate` フレーム）が返す同期レスポンスボディは、指定タスクリスト外のタスクについては署名され **ません**: 即時応答の完全性はリクエストを運んだ認証済みセッション内の TLS によって配信され、永続的アーティファクトの静止時完全性は署名付き webhook の仕事です。分割は意図的です — webhook のみのアテステーションは、「このアーティファクトは永続的完全性を必要とする」をすべての応答へのフリーライダーではなく明示的なモデリング決定にする強制関数であり、webhook のものと重なる汎用のレスポンス署名サーフェスの運用コスト（追加の検証者パス、適合性グレーダー、失効エントリ）を避けます。**RFC 9421 §2.2.9 トランスポートレスポンス署名は 3.x のどのタスクにも定義されていません。** バイヤーは指定タスクリスト外のレスポンス署名に依存してはなりません（MUST NOT）。静止時アテステーションを必要とするアーティファクトは署名付き webhook 経由で配信されなければなりません（MUST）。同期的に返されるアーティファクトがアテステーション可能である必要がある場合、仕様がサポートするパスは、タスクを指定リストに追加する（規範的決定）か、正準バージョンで署名付き webhook を発するようツールを再構築することです。[#3737](https://github.com/adcontextprotocol/adcp/issues/3737) で追跡、意図された 3.x 設計として解決、脅威モデルが進化すれば 4.0 で再検討可能。

## コマースと決済

* **プロトコル内の支払いまたは決済なし。** `report_usage` は請求に供給される消費データを提供しますが、請求と決済はバイヤー/セラーの商業的関係を通じて帯域外で起こります。
* **クロス通貨メディアバイなし。** 各メディアバイは単一の ISO 4217 通貨を使います（`core/price.json` を参照）。バイヤーの予算通貨がセラーの価格通貨と異なる場合、バイは一致する通貨を使うか拒否されます。FX レートのピン留め、リスク帰属、クロス通貨レポートは将来のバージョンに延期されます。
* **プロトコルレベルの配信紛争フローなし。** バイヤーとセラーの配信数が不一致のとき、再照合は商業的関係を通じて帯域外で起こります（両側の監査証跡によって裏付けられる）。構造化された紛争タスクは将来の作業の候補です。

## 測定とアトリビューション

* **アトリビューションプロトコルではない。** AdCP はエクスポージャーレコード、許可される場合は識別子、アトリビューションに供給される成果シグナルを運びますが、アトリビューションモデルを仕様化しません。メディアミックスモデリング、マルチタッチアトリビューション、インクリメンタリティテストはバイヤーの測定スタックに存在します — プロトコルによって計算されるのではなく AdCP データ（[`report_usage`](/docs/accounts/tasks/report_usage) とタスクレベルの出力）によって供給されます。

## 認証とアイデンティティ

* **OAuth 2.1 + resource-indicators の規範的要件なし。** AdCP は mTLS、事前プロビジョニングされた API キー、RFC 9421 署名付き HTTP リクエスト（最後は 3.1 で規範的）を使ってエージェントを認証します。これらは、委譲された人間ユーザー認可ではなく、自律エージェント間の相互認証のために意図的に選ばれています。resource indicators を持つ OAuth 2.1 は、オペレーターのインフラがすでにそれに標準化している場合に許容されるトランスポートですが、プロトコル要件ではなく、上記の 3 つのメカニズムの代替にはなりません。
* **変更呼び出しの署名付きリクエストは 3.1 で規範的、3.0 ではない。** AdCP 3.0 は変更呼び出しで bearer トークン認証を許します。3.1 は RFC 9421 署名または JWS 署名ボディを要求します。[#2307](https://github.com/adcontextprotocol/adcp/issues/2307) で追跡。
* **レジストリでの鍵透明性アンカリングなし。** [AgenticAdvertising.org レジストリ](/docs/registry/index) はブランドアイデンティティ、プロパティ認可、エージェントディスカバリーを解決し、パブリッシャーの [`adagents.json`](/docs/governance/property/adagents#signing_keys) で宣言された `signing_keys[]` をキャッシュできます。まだしないことは、鍵透明性ログとして動作することです: ドメインをルート検証鍵にバインドする登録儀式、追記専用のローテーションレコード、すべての検証者が同じ鍵履歴を見る暗号学的コミットメントはありません。したがって 3.x では、RFC 9421 バイヤー鍵、ガバナンス JWS 鍵、エージェント署名鍵、ポインターファイルは依然として究極的には当事者自身のインフラに根ざしています — 当事者の CDN、DNS、`/.well-known` パスを制御する攻撃者は攻撃者制御の鍵を提供でき、証明書が侵害されたホスト名に対して有効なので TLS はこれを閉じません。3.x は継続性を伴う trust-on-first-use を配信します（マルチソースクロスチェック、公開遅延ウィンドウ、帯域外ローテーションシグナリング、ローテーション有効性の規律） — 検出可能にハードルを上げますが、暗号学的にギャップを閉じません。完全な閉鎖は、追記専用ローテーションログと JWKS ワイヤー互換性を持つ、既存レジストリの上の鍵透明性層で、4.0 の成果物として追跡されます。

## ガバナンス

* **規制カテゴリーの人間レビューは、3 つの名指しされたカテゴリーについてスキーマレベルで、それ以外すべてについてガバナンスエージェントレベルで強制される。** 3.0 は、`fair_housing`、`fair_lending`、`fair_employment` を宣言するキャンペーンで `authority_level: agent_full` をスキーマレベルで拒否します（[#2310](https://github.com/adcontextprotocol/adcp/issues/2310) 経由で出荷、2026-04-18 マージ）。その他の規制カテゴリー — 政治、製薬、ギャンブル、アルコール、タバコ、金融、暗号、大麻/CBD、銃器、栄養補助食品の健康クレーム、子供向け — は、スキーマ不変条件ではなくガバナンスエージェント実装に依存します。
* **`sync_catalogs` または `sync_creatives` でプロトコルが義務付ける HITL なし。** ユニバーサルタスクライフサイクルメカニズムが利用可能です。人間のゲートを要求する規範的ルールはありません。`acquire_rights` は、バイヤーのプランがそれ用に設定されているとき、キャンペーンガバナンスパス（[購入フェーズ](/docs/governance/campaign/specification#governance-phases)）経由で統治されます。2 つのチャネルについては [How human-in-the-loop enters the protocol](/docs/governance/embedded-human-judgment#how-human-in-the-loop-enters-the-protocol) を、`check_governance`、`TERMS_REJECTED`、ライフサイクルタスクの規範的ルールについては EHJ レジスターを参照。
* **`fair_housing`、`fair_lending`、`fair_employment` を超えた規制カテゴリーはファーストクラスの扱いを持たない。** 政治広告、製薬、ギャンブル、アルコール、タバコ、金融プロモーション（暗号とデジタル資産を含む）、大麻/CBD、銃器、栄養補助食品の健康クレーム、子供向け広告は、カテゴリー固有のスキーマルールではなく一般的な [キャンペーンガバナンス](/docs/governance/campaign/specification) メカニズム（HITL ゲート、ガバナンスタスク）に依存します。地域固有の開示要件（例: 英国 FCA s.21、EU MiCA、政治広告レジストリ、COPPA、英国 Children's Code、GDPR 第 8 条）は、プロトコルではなくセラーの配信スタックとバイヤーのコンプライアンス姿勢に存在します。

## 適合性とテスト

* **リファレンステストベクターは部分的。** [適合性](/docs/building/conformance) はストーリーボードスイートによって定義され、スイートは今日リクエスト署名と正準化のベクターを公開します — しかしより広いリファレンステストベクターのコーパスは [#2383](https://github.com/adcontextprotocol/adcp/issues/2383) で追跡されます。
* **AdCP Verified は 3.0 で自己証明。正式なプログラムは 3.1 でローンチ。** 今日、エージェントは自身の署名付き `runner-output.json` を公開します — 任意の検証当事者によって再現可能・再実行可能ですが、AAO 監査されていません。トレーニングエージェントと公式 SDK は、3.0 → 3.1 ウィンドウにわたって 4〜6 週間のケイデンスで完全なストーリーボードコンプライアンスに引き上げられています（トレーニングエージェントは今日 32/55 クリーン）。それらがクリーンに合格し曖昧なストーリーボード作業が完了したら、AAO は提出されたエージェントを正準ストーリーボードスイートに対して実行し、Verified エージェントの公開レジストリを維持します。コンプライアンスランナーとストーリーボード自体が 3.0 のソフトウェアです — ストーリーボードのバグ、カバレッジギャップ、エンコードされた仕様意図の曖昧さは、実装バグと並んで正当な GitHub issue です。
* **プロパティ名をスキャンする `check:platform-agnostic` リントを超えたプラットフォーム非依存性の自動強制なし。** スキーマセマンティクスをカバーするより豊かなチェックは将来の作業です。
* **レイテンシーまたはレスポンスタイム SLA なし。** プロトコルは、エージェントがどのくらい速く応答しなければならないかについて規範的な期待を持ちません（OpenRTB のオークションごとの `tmax` とは異なり）。バイヤーとセラーは、商業的関係を通じて、またはタスク固有の [アカウンタビリティ条件](/docs/media-buy/advanced-topics/accountability) を通じてタイミングを交渉します。構造化された SLA 宣言は延期されます。
* **ワイヤー上のランタイムスキーマディスカバリーツールなし。** AdCP は、ライブエージェント上の名前付きタスクのリクエストとレスポンスの形状を返す `get_schema`（または同等）ケイパビリティツールを出荷しません。コーディングエージェントは、仕様とパッケージされた [SKILL.md ファイル](https://github.com/adcontextprotocol/adcp/tree/main/skills) 経由で形状を発見します。SDK ビルダーはビルド時に `/schemas/v3/bundled/` から JSON Schema を読みます。したがって正準スキーマソースはワイヤー上ではなく帯域外です。ランタイムツールは [#3057](https://github.com/adcontextprotocol/adcp/issues/3057) で検討され延期されました — SKILL.md パスがコーディングエージェントの発見性をカバーし、スキーマバンドル URL が SDK ビルダーをカバーし、唯一のランタイム固有のケース（特定エージェントのプライベートツール拡張）は 3.x で規範的なツールサーフェスを正当化するほど一般的でないからです。決定は MCP `tools/list` が `inputSchema` を運び続けることに依存します — MCP と A2A 間の SDK 検証対称性（[adcp-client#909](https://github.com/adcontextprotocol/adcp-client/issues/909) で追跡）は、A2A `AgentCard` をスキルごとの `schemaRef` で拡張するか、検証の非対称性を受け入れて A2A でバンドルスキーマにフォールバックすることで解決されるべきです。MCP `tools/list` から `inputSchema` を剥がすことによって*ではありません*。それを剥がすと、`get_schema` が閉じるはずだったまさにそのワイヤーサーフェスのギャップが生まれ、その解決は #3057 を再開すべきです。スキルローダーを持たない非 Anthropic LLM が主要なコンシューマーになる場合、プライベートツール拡張が一般的になる場合、静的ケイパビリティ記述子をまったく持たないトランスポートが現れる場合、または SDK 検証対称性の修正が MCP ディスカバリーから `inputSchema` を削除することで着地する場合、再検討してください。
* **ランナー側のケイパビリティスロット `not_applicable` 強制はまだ着地中。** `definePlatform` などの SDK ヘルパーによって投影されるケイパビリティスロットは、提案ではなくコミットメントです。望まれるランナー動作はこうです: ストーリーボード/ベクターが宣言されていないスロットをターゲットにする場合、そのパスを `not_applicable` とグレードする。スロットが宣言されている場合、ディスパッチし実装エラーで通常どおり失敗する。`adcp-client#2244` が着地するまで、プレリリース/カスタムランナーはエージェントの宣言されたスロットスコープ外のベクターに明示的なスキップゲートが必要かもしれません。実装者は、サポートされないスロットをプレースホルダー動作で宣言するのではなく欠如させるべきです。

## プロトコルの外にあるもの

AdCP はワイヤーを仕様化します。次のいずれも仕様化せず — また代替もできません:

* **シークレットストレージ。** KMS、Vault、Secrets Manager、または同等物を使う。
* **エンドポイント堅牢化。** WAF、レート制限、DDoS 保護、TLS 設定、OS パッチ、依存関係スキャン。
* **監視とインシデント対応。** プロトコルは監視する価値のあるシグナル（冪等性衝突、ガバナンス失敗、SSRF 拒否）を発します。それらを検出し対応するのはオペレーターの仕事です。
* **人間の制御。** 承認しきい値、支出上限、一時停止権限 — これらはプロトコルではなく、オペレーターのエージェントやガバナンスプラットフォーム内のポリシー設定です。
* **物理的および人的セキュリティ。** 誰が本番に触れられるか、誰がブレークグラス認証情報を保持するか、誰が main にプッシュできるかについての通常の制御。
* **課金グレードのメトリクス会計。** AdCP はセラーの広告配信システムからエンドツーエンドで配信と使用量のデータを運び、[`report_usage`](/docs/accounts/tasks/report_usage) が請求に供給します。基底の配信プラットフォーム — またはバイヤー指定の測定ベンダー — が、測定方法論のカウント、監査、MRC 認定の記録システムです。AdCP 自体は MRC 認定されておらず、認定を求めません。認定は下流に位置する測定システムに付随します。AdCP はワイヤーと契約であり、台帳ではありません。
* **無効トラフィックのフィルタリングとビューアビリティ測定。** バイヤーとセラーは、[アカウンタビリティ条件](/docs/media-buy/advanced-topics/accountability) を通じて検証ベンダー、しきい値、修復に合意します。GIVT/SIVT フィルタリング（MRC 準拠）、ビューアビリティ測定（MRC Viewable Ad Impression 標準準拠）、ブランドセーフティ検証は、配信スタックまたは選ばれたベンダー層（例: DoubleVerify、IAS、HUMAN）で実行されます。
* **配信されるクリエイティブのアクセシビリティ適合性。** レンダリングされた広告の WCAG、ADA、EN 301 549 適合性は、クリエイティブサプライヤー、配信スタック、パブリッシャーのレンダリングコンテキストにあります。AdCP はアクセシビリティ適合性アサーションを規範的フィールドとして運びません。

AdCP をドアの錠を仕様化するものと考えてください。オペレーターは依然として建物を所有します。

## 関連

* [Security Model](/docs/building/concepts/security-model) — 脅威モデルと多層防御
* [プライバシー考慮事項](/docs/reference/privacy-considerations) — クロスプロトコルのプライバシー入口
* [実験的ステータス](/docs/reference/experimental-status) — 3.x で出荷されたがまだ凍結されていないサーフェス
* [バージョニングとガバナンス](/docs/reference/versioning) — ケイデンス、サポートウィンドウ、制限がフォローアップになる方法
* [ロードマップ](/docs/reference/roadmap) — 次に来るもの