> ## 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 が検証可能性と監督のため決定をどう構造化するか — プロトコルが提供する継ぎ目と、デプロイヤーが責任を負うもの。 AdCP はビルディングブロックで、コンプライアンスの近道ではありません。プロトコルは、デプロイヤーが義務を果たせる構造化フィールドを公開します — それ自体は適合性評価を実行したり、ポリシーを強制したり、結果を保証したりしません。AdCP がしないことの明示的なリストについては [既知の制限](/docs/reference/known-limitations) を参照してください。 AdCP のトラスト姿勢は単一の構造原則に基づきます: **単一のエージェントが一方的に行動できず、すべての決定はチェックしたい任意の当事者によって暗号的に再検証可能。** ガバナンスエージェントは資金が動く前にプランを検証します。JWS 署名付き `governance_context` がすべてのバイとともに移動し、セラーがバイヤーの言葉を信頼せずに独立に認可を確認できます。コンプライアンスランナーは `runner-output.json` からストーリーボード出力を数か月後に再実行し、規制当局が見るのと同じ pass/fail 行を生成できます。 AdCP がしないことはデプロイヤーポリシーを強制することです。継ぎ目はフックです — デプロイヤーがそれらを自身のガバナンスプラットフォーム、ポリシーレジストリ、人間レビューワークフローに配線します。キャンペーンを承認する権限は人間定義のルールに留まります。プロトコルはそれを運び、署名し、監査可能にします。 このページは、AdCP デプロイを評価する CISO、コンプライアンスレビュアー、調達チームのため 7 つのトラスト表面をマップします。各表面について: AdCP が何を提供するか、明示的に何を提供しないか、正準詳細をどこで見つけるか。7 つすべての表面にわたるライブ作業は [Trust, Identity, and Governance マスター issue (#3925)](https://github.com/adcontextprotocol/adcp/issues/3925) の下で追跡されます。 *** ## Governance **AdCP が提供するもの。** 資金を使うエージェントが決して支出を承認するエージェントでない三者構造。オーケストレーターは [`sync_plans`](/docs/governance/campaign/specification) 経由でプランを提案します。独立に運用されるガバナンスエージェントが、オーケストレーターが進む前に [`check_governance`](/docs/governance/campaign/specification) 経由でデプロイヤー構成のポリシーに対して各プランを検証します。すべてのガバナンス決定が [`get_plan_audit_logs`](/docs/governance/campaign/tasks/get_plan_audit_logs) エントリーを生成します — 不変、タイムスタンプ付き、再現可能。 **AdCP が提供しないもの。** `check_governance` は継ぎ目で、強制者ではありません。ガバナンスエージェントを構成していないセラー、または誤構成されたセラーは `check_governance` をまったく呼びません — プロトコルは非適合セラーがトランザクションするのを防ぎません。規制されたバーティカル（クレジット、保険、雇用、住宅）は、AdCP 3.0 で名指しされた 3 つのカテゴリー（`fair_housing`、`fair_lending`、`fair_employment`）にスキーマレベルの強制を得ますが、他のすべての規制されたカテゴリー — 政治、製薬、ギャンブル、金融プロモーション — はガバナンスエージェント実装に依存します。[既知の制限 — Governance](/docs/reference/known-limitations#governance) セクションを参照。 → [ガバナンス概要](/docs/governance/overview) · [埋め込まれた人間の判断](/docs/governance/embedded-human-judgment) · [ポリシーレジストリ](/docs/governance/policy-registry) · [Annex III と Art 22 の義務](/docs/governance/annex-iii-obligations) *** ## 規制 **AdCP が提供するもの。** デプロイヤーが EU AI Act Annex III と GDPR Article 22 の義務を果たせる構造化フィールド: 人間の監督（Art. 14）の `plan.human_review_required`、入力データ統制（Art. 10）の `policy_categories` と `restricted_attributes`、自動ログ（Art. 12）の `get_plan_audit_logs`、発見可能な異議申立連絡先（Art. 22(3)）としての `brand.data_subject_contestation`。 **AdCP が提供しないもの。** AdCP は適合性評価、DPIA、異議処理を実行しません。それらはデプロイヤーの責任のままです。[Annex III と Art 22 の義務](/docs/governance/annex-iii-obligations) の上部の Warning ブロックが権威的フレーミングです。 → [Annex III と Art 22 の義務](/docs/governance/annex-iii-obligations) *** ## プライバシー **AdCP が提供するもの。** スキーマレベルの PII 制御: `sync_audiences` の `hashed_email` と `hashed_phone` フィールドが平文を拒否。Trusted Match Protocol の構造的プライバシー — TMP でクロス当事者データリークを防ぐ分離されたコードパスとスキーマ禁止。仕様の他の場所にプロトコルレベルの PII トランスポートなし。 **AdCP が提供しないもの。** 構造的プライバシーは TMP にのみ適用されます。他のドメインは契約上の機密性またはセッションごとの同意に依存します。AdCP は規範的同意シグナル（IAB TCF、GPP、または同等物）を運びません。越境転送の合法性は当事者の契約と構成の性質です。[既知の制限 — Security and Privacy](/docs/reference/known-limitations#security-and-privacy) を参照。 → [プライバシー考慮事項](/docs/reference/privacy-considerations) · [Trusted Match Protocol](/docs/trusted-match/index) *** ## アイデンティティ **AdCP が提供するもの。** エージェントがトランザクションするすべての当事者の発見可能なアイデンティティ。 ハウスは `/.well-known/brand.json` で [`brand.json`](/docs/brand-protocol/brand-json) を公開し、企業ドメイン、Keller 型関係（`master` / `sub_brand` / `endorsed` / `independent`）を持つブランドポートフォリオ、デジタルプロパティ、認可されたオペレーター（ドメインによるエージェンシーとパートナー）、ハウスレベルの商標クレーム、検証可能な署名鍵のためのエージェントごとの JWKS URI を宣言します。パブリッシャーは [`adagents.json`](/docs/governance/property/adagents) を公開し、どのセールスエージェントがどのプロパティを販売またはどの公開されたシグナル定義を再販する認可を受けているかを、エージェントごとのパブリッシャー証明の `signing_keys` とともに宣言します。 双方向検証チェーンが 2 つを結びつけます: 委譲とネットワークパスは、セラーの `brand.json` `properties[].relationship` がパブリッシャーの `adagents.json` `delegation_type` に一致することを要求します。ファーストパーティ在庫はインライン所有権として解決します。ブランドプロトコルの相互主張モデル（RFC [#3533](https://github.com/adcontextprotocol/adcp/issues/3533)） — 子ブランドが `parent_house` を宣言、親ハウスが `brand_refs[]` 経由で相互にする — は、下流消費者が直接行動できる 5 状態トラストシグナル（`inline` / `mutual_assertion` / `one_sided_brand` / `one_sided_house` / `standalone`）を生成します。 `(Spec)` と `(Live)` 修飾子を持つ [AAO Verified](/docs/building/verification/aao-verified) マークは、セラーの実広告サーバー統合に対して実行される正準テストキャンペーンを通じて動作適合性を継続的に証明します。 **AdCP が提供しないもの — 知るべき 3 つのギャップ。** 第一: **集約された公開レジストリアイデンティティクレームなし。** brand.json はハウスレベルの商標クレームと自己主張のブランド関係を運びます。それは、関連する事実を既に検証する公開レジストリに対するクレームを集約する一般化された `identifiers[]` ブロック — 法人には LEI / GLEIF、商標登録には USPTO / EUIPO / WIPO Madrid、CA 証明の商標→ドメインバインディングには Verified Mark Certificates、公開アイデンティティには Wikidata Q-ID、公開企業アイデンティティには SEC EDGAR CIK — を運びません。アイデンティティクレームはスプーフとルックアライクドメインに対して防御します。それらは正当な brand.json のホスティングインフラの侵害に対して防御しません — その脅威は Security 表面で対処されます。この層の集約 RFC はトラストマスター issue の下で追跡されます。 第二: **`adagents.json` に対称なバイヤー側認可プリミティブなし。** ブランドは、どのバイヤーエージェントが自身に代わってトランザクションする認可を受けているかを単一の発見可能な場所で宣言できません。最も近い既存プリミティブは `brand.json` の `authorized_operators[]` で、オペレータードメインでスコープします — エージェントエンドポイントではなく、特定のバイヤーエージェント JWKS へのブランドからの署名付きバインディングなし。認可されたオペレーターのドメインの侵害されたエージェントは、そのオペレーターをリストするすべてのブランドで一方的にトランザクションできます。RFC [#2307](https://github.com/adcontextprotocol/adcp/issues/2307) はリクエスト署名のためのバイヤー側 agents.json を提案します。より広範な認可層ギャップはそれと並んで追跡されます。 第三: **プロトコルにオペレーター/人間 KYC プリミティブなし。** プロトコルは、人間または組織オペレーターが KYC プロバイダー（Persona、Stripe Identity、Onfido）によってアイデンティティ検証された、または権威的 IdP にルートされたという証明を運びません。KYC はメンバーシップとアカウント層に委ねられます。プロトコル側では、暗号的事実（どの鍵がどのメッセージに署名したか）のみが規範的です。[既知の制限 — Authentication and Identity](/docs/reference/known-limitations#authentication-and-identity) を参照。 **在庫と製品クレーム。** バイヤーが [`get_products`](/docs/media-buy/task-reference/get_products) レスポンスを評価するとき、上のチェーンは *誰が問題の在庫を販売する認可を受けているか* を確立します: セラーオペレーターの `brand.json` がエージェントと代表されるプロパティを宣言、プロパティ所有者の `adagents.json` がそのエージェントを認可、レスポンス自体がオペレーターの JWKS から解決された鍵またはパブリッシャーの `adagents.json` でピン留めされた鍵で RFC 9421 署名されます。チェーンが確立しないのは、特定の製品ライン — 可用性ウィンドウ、価格、在庫ボリューム — が配信時に現実を反映するかです。カタログの正確性はプロトコル証明されません: パブリッシャーは個別の製品エントリーに署名せず、製品ごとの証明は在庫が本番でどう運用されるかに一致しません。配信時の真実は測定レポートと課金照合フロー（[#2391](https://github.com/adcontextprotocol/adcp/issues/2391)）に存在します。誤動作する認可されたセラーは、プロトコル内クレームチェックではなく、パブリッシャーが `adagents.json` エントリーを取り消すことで修復されます。これは在庫に適用された C2PA の「クレーム非認証」姿勢です: AdCP は認可クレームを運びそれを検証可能にします。主張された在庫が存在することを認証しません。 → [brand.json](/docs/brand-protocol/brand-json) · [adagents.json とエージェントアイデンティティ](/docs/governance/property/adagents) · [AAO Verified](/docs/building/verification/aao-verified) *** ## セキュリティ **AdCP が提供するもの。** 変更する呼び出しの署名付きリクエスト（3.1 で規範的。3.0 で許可 — 下記参照）とアウトバウンド webhook 配信（それを要求するレシーバーのオプトイン HMAC フォールバック付き）のベースラインメカニズムとしての RFC 9421 HTTP メッセージ署名。リプレイ攻撃を防ぐすべての状態変更操作の冪等性キー。盗まれたトークンの爆発半径を制限する `(agent, account)` ごとの認証情報スコーピング。すべてのメディアバイとともに移動しセラーがバイヤーを信頼せず独立に検証可能な JWS 署名付きガバナンスコンテキスト。 **AdCP が提供しないもの — 知るべき 2 つの制限。** 第一: **署名付きリクエストは 3.1 で規範的、3.0 ではない。** AdCP 3.0 は変更する呼び出しに bearer トークン認証を許可します。すべての変更する呼び出しに RFC 9421 署名を要求することは 3.1 に向けて [#2307](https://github.com/adcontextprotocol/adcp/issues/2307) で追跡されます。今日署名を要求するデプロイは、それをプラットフォーム層で強制し、プログラムが 3.1 で立ち上がるとき AdCP Verified にオプトインすべきです。 第二: **署名鍵はまだ鍵透明性ログにアンカーされていない。** 3.x では、RFC 9421 バイヤー鍵、ガバナンス JWS 鍵、エージェント署名鍵は最終的に各相手方自身のインフラにルートされます — 相手方の CDN、DNS、`/.well-known` パスを制御する攻撃者は攻撃者制御の鍵をサーブできます。TLS はこのギャップを閉じません。AdCP 3.x は継続性を伴う trust-on-first-use（マルチソースクロスチェック、公開遅延ウィンドウ、帯域外ローテーションシグナリング）を配信します — バーを検出可能に上げますが、暗号的に閉じません。鍵透明性層は 4.0 の成果物です。完全な記述については [既知の制限 — Authentication and Identity](/docs/reference/known-limitations#authentication-and-identity) を参照。 → [セキュリティモデル](/docs/building/concepts/security-model) · [セキュリティ実装リファレンス](/docs/building/by-layer/L1/security) *** ## プロベナンス **AdCP が提供するもの。** クリエイティブペイロードの正しい使用主張、AI 生成画像の `ai_generated_image` ブールフラグ、各メディアバイをそれを認可したガバナンス決定に遡らせる `governance_context` JWS。 **AdCP が提供しないもの。** `ai_generated_image` フラグはブールマーカーで、署名付きプロベナンス主張ではありません。クリエイティブが生成、編集、適応を通過するにつれ主張を蓄積する暗号署名付きプロベナンスグラフはありません。CAI/C2PA との相互運用は将来の作業として追跡されます。 → [クリエイティブプロベナンス検証](/docs/governance/creative/provenance-verification) · [adagents.json とエージェントアイデンティティ](/docs/governance/property/adagents) *** ## 開示 **AdCP が提供するもの。** [/docs/ai-disclosure](/docs/ai-disclosure) の AI 開示ページは、AgenticAdvertising.org が AI を使うすべての表面、その背後のモデル、人間レビューをリクエストする方法を名指します。`sync_plans` と `create_media_buy` はオーケストレーションエージェントのアイデンティティを運び、各決定の AI 起源を発見可能にします。 **AdCP が提供しないもの。** 配信されるクリエイティブの AI 生成広告コンテンツの規範的開示要件なし。サーブされる広告の開示義務は、適用される法（例: FTC ガイダンス、EU AI Act Art. 50、DSA Art. 26）の下でデプロイヤーの責任です。 → [AI 開示](/docs/ai-disclosure) *** ## コンプライアンスレビュアー向け これらはデプロイヤーが実装するワイヤーレベルフックです。それらは継ぎ目で、保証ではありません — 非適合デプロイヤーはそれらをバイパスできます。 | Control | Wire hook | AdCP role | | -------------- | ------------------------------------------------------------------------------------------ | ----------------------------------------- | | 人間監督ゲート | `plan.human_review_required: true` + `APPROVED` を返す `check_governance` | ゲートを提供。デプロイヤーがしきい値を構成 | | 監査証跡 | [`get_plan_audit_logs`](/docs/governance/campaign/tasks/get_plan_audit_logs) | 不変、タイムスタンプ付き。デプロイヤーが保持に責任 | | 異議申立連絡先 | `brand.data_subject_contestation` | 発見可能なエンドポイント。デプロイヤーがプロセスを運用 | | リクエスト署名 | RFC 9421 `Signature` / `Signature-Input` ヘッダー | 3.1 で規範的。3.0 で許可 | | ガバナンス証明 | `create_media_buy` の JWS 署名付き `governance_context` | セラーが独立に検証可能 | | 規制カテゴリーブロック | `fair_housing`、`fair_lending`、`fair_employment` の `authority_level: agent_full` のスキーマレベル拒否 | 3 カテゴリーのみ。他はガバナンスエージェント実装が必要 | | ブランドアイデンティティ宣言 | `brand.json` `house`、`brands[]`、`authorized_operators[]`、ハウスレベル `trademarks[]` | 発見可能。デプロイヤー / エコシステムが公開レジストリに対して解決 | | 相互主張トラスト状態 | `brand.json` `parent_house` ↔ `brand_refs[]`（RFC #3533） | 5 状態シグナル。デプロイヤーポリシーが何が必要か決定 | | エージェントアイデンティティ | `brand.json` `agents[].jwks_uri`、`adagents.json` `signing_keys` | 検証可能な署名鍵。鍵透明性層は 4.0 | | 動作検証 | 正準テストキャンペーン経由の AAO Verified `(Live)` 継続証明 | AAO が発行し取り消す。デプロイヤーは AdCP ランタイムではなくマークを信頼 | **AdCP が明示的にしないことについては [既知の制限](/docs/reference/known-limitations) を参照** — そのページは、このページがあなたが取ったと仮定する敵対的な読みです。