EU AI 法第 50 条の施行は 2026 年 8 月から始まる。カリフォルニア州 SB 942 はすでに有効です。主要プラットフォームは今日 AI コンテンツのラベリングを義務付けています。AdCP は、これらの規制が依拠する構造化された機械可読なプロベナンスと開示のメタデータを、それ以前に標準が存在しなかったプログラマティックなサプライチェーンを通じて運びます。プロトコルはデータを動かします。法的義務は依然として、エンドユーザーへの開示を行うデプロイヤーにあります。
プロベナンスオブジェクト
プロベナンスはクリエイティブアセット、クリエイティブマニフェスト、個々の型付きアセット、コンテンツアーティファクトに付与できるオプションのオブジェクトです。プロベナンスレベルでは必須フィールドはない — 各セクションは独立して有用です。 スキーマ: provenance.json最小限の例
ほとんどのプロベナンス宣言は1つの質問に答える: これは AI 生成か、開示ラベルが必要か?digital_source_type はコンテンツがどのように制作されたかを示します。disclosure.required はラベルが必要かどうかを示します。それ以外のすべて — ツールの詳細、C2PA 参照、管轄区域固有のレンダリングガイダンス、検証結果 — は必要なときにサプライチェーン参加者が追加できるオプションのコンテキストです。
AI が関与していないコンテンツの場合、プロベナンスはさらにシンプルだ:
完全な例
デジタルソースタイプ
digital_source_type 列挙型は、IPTC digitalsourcetype 語彙に準拠したコンテンツ制作における AI 関与を分類します。
スキーマ: digital-source-type.json
適切な値の選び方
混合制作のクリエイティブでは、プロベナンスが付与されているレベルでクリエイティブ全体を最もよく説明する値を選ぶ。アセットごとに AI 関与を区別する必要がある場合は、代わりに個々のアセットレベルでプロベナンスを付与する（下記継承を参照）。 一般的なパターン:- AI 画像 + 人間のコピー: 画像アセットに
trained_algorithmic_mediaを付与し、テキストアセットにdigital_creationを付与し、マニフェストレベルにcomposite_with_trained_algorithmic_mediaを付与します - AI 生成ヘッドラインの DCO: マニフェストレベルで
data_driven_media、AI 生成テキストアセットにtrained_algorithmic_media - 人間の写真家 + AI 背景除去: マニフェストレベルで
composite_with_trained_algorithmic_media
ヒューマンオーバーサイト
human_oversight 列挙型は、AI 支援制作プロセスにおける人間の関与レベルを説明します。
このフィールドは
digital_source_type が AI 関与を示す場合に関連します。AI 非関与コンテンツの場合は省略します。
ガバナンスエージェントは、この監査に値するパターンを get_creative_features.audit_observations[] を通じて OVERSIGHT_DISCLOSURE_CARVEOUT_CLAIMED で表面化します。その観測はそれ自体では拒否コードではありません——クリエイティブが通常のレビューを進む間、セラーが監査のために主張を保持またはルーティングできるようにするものです。
継承
プロベナンスはクリエイティブ階層の3つのレベルに付与されます。最も具体的なプロベナンスが優先され、置換はオブジェクト全体 — フィールドレベルのマージは行われない。解決ルール
- 個々のアセットに
provenanceがある場合、それを使用します - そうでなければ、マニフェストに
provenanceがある場合、それを使用します - そうでなければ、クリエイティブアセットに
provenanceがある場合、それを使用します - そうでなければ、そのアセットのプロベナンスは宣言されていません
例: 混合クリエイティブ
画像が AI 生成だがコピーが人間が書いたクリエイティブ。マニフェストレベルのプロベナンスがクリエイティブ全体をカバーします。画像アセットが独自のより具体的なプロベナンスでオーバーライドします。banner_imageは独自のプロベナンスを使用します:trained_algorithmic_mediaと完全な AI ツールの詳細headlineはマニフェストレベルのプロベナンスを継承する:composite_with_trained_algorithmic_mediaclickthrough_urlもマニフェストレベルのプロベナンスを継承します
declared_by があっても、その情報を引き継ぐべき場合は画像アセットが独自のプロベナンスオブジェクトで再宣言しなければなりません。
アーティファクトの継承
コンテンツアーティファクト（パブリッシャーコンテンツ）の場合も同じパターンが適用されます:digital_creation を継承します。イラストは独自の trained_algorithmic_media プロベナンスでオーバーライドします。
トラストモデル
広告において、プロベナンスを宣言する当事者と執行する当事者は競合する動機を持ちます。クリエイティブを提出するバイヤーは、コンテンツが人間制作だと主張する理由がある — AI 生成クリエイティブは特定のインベントリでプレースメント制限、必須開示ラベル、または完全な拒否に直面する可能性があります。そのクリエイティブを受け入れるセラーは逆の動機を持ちます: 適切な開示なしに AI 生成コンテンツを公開すると、広告主ではなくパブリッシャーに規制上の責任が生じる。AdCP はプロベナンスを事実ではなく主張として扱うことでこの緊張を処理します。バイヤーが宣言し、セラーが検証します。検証は各執行ポイントで独立して行われ、AI 検出サービス（get_creative_features 経由）、C2PA マニフェスト検証、または両方を使用します。どの当事者も他の当事者の主張を信頼する必要はない。プロトコルは主張のための構造と検証のための統合ポイントを提供する — サプライチェーンは両者を誠実に保つ敵対的な圧力を提供します。
declared_by フィールドはプロベナンス主張を付与した者を識別します。verification 配列は宣言当事者が透明性のために開示したい検出結果を保持します。しかし、プロベナンス要件を執行する当事者は、バイヤーが付与した結果を信頼するのではなく、既存のガバナンスインフラを通じて独自の検証を実行します。
宣言当事者の役割
バイヤーが付与する検証
プロベナンスオブジェクトのverification 配列は、宣言当事者が透明性のために検出結果を共有できるようにします。複数のサービスが同じコンテンツを独立して評価できる:
get_creative_features を通じて独自の検出を実行します。
検証結果は4つの結果のいずれかを使用します:
例: キャンペーンを通じたプロベナンス
Acme Brands が春のキャンペーンを実施しています。エージェンシーの Meridian Media が AI 画像ジェネレーターを使用してディスプレイバナーセット — AI 生成バックグラウンドのフォトリアリスティックなプロダクトショット — を制作します。Meridian はクリエイティブマニフェストにプロベナンスを付与する:digital_source_type は composite_with_trained_algorithmic_media、ai_tool がジェネレーターを識別し、disclosure.required は true で適用規制として eu_ai_act_article_50 と ca_sb_942 がリストされます。EU 管轄区域では、Meridian は render_guidance.persistence を continuous に設定し positions は overlay を優先する — EU AI 法の継続的なラベリング要件を表現しています。
キャンペーンは AdCP を通じて Pinnacle Publishing に提出されます。Pinnacle の広告運用プラットフォームがプロベナンス主張を確認し、get_creative_features を通じてクリエイティブを検証パイプラインで実行します。AI 検出サービスは 0.94 の信頼度で ai_modified を返す — 宣言されたソースタイプと一致しています。主張が検証されると、Pinnacle は自身の管轄区域ポリシーを適用します——SB 942 の下での対象プラットフォームとして、Meridian の disclosure.required: true を権威あるものとして依拠するのではなく、自身の開示判断を下します——配信管轄区域のレンダリングガイダンスを読み取り、指定された持続性で開示ラベルを適用し、クリエイティブの配信をクリアします。プロベナンスメタデータ、検出結果、レンダリングガイダンス、開示決定がすべて記録され監査可能になります。
Meridian が代わりに digital_capture と宣言していた場合 — AI 関与なしと主張 — Pinnacle の検出サービスが不一致にフラグを立てていました。クリエイティブは配信されずレビューのために保留されていました。
C2PA インテグレーション
c2pa フィールドは、C2PA Content Credentials — Coalition for Content Provenance and Authenticity が開発した暗号プロベナンス標準 — へのソフト参照を提供します。
なぜ URL 参照か
C2PA バインディングは通常、メディアファイル自体に埋め込まれる。しかし、広告技術パイプラインはクリエイティブアセットを日常的にトランスコード、リサイズ、再フォーマットし、その過程でファイルレベルの C2PA バインディングを壊す。元の C2PA マニフェストストアへの URL 参照はこのトランスコーディングを生き残り、サプライチェーンを通じたプロベナンスのチェーンを保持します。 参照はポインターであり、C2PA の置き換えではありません。チェーン内のどの当事者も、メディアファイルがトランスコードされた後でも、URL からマニフェストをフェッチして元のコンテンツ資格情報を検証できます。使用パターン
- クリエイターがコンテンツを生成し、C2PA マニフェストを作成します
- クリエイターがマニフェストストアを安定した URL にアップロードします
- クリエイターが AdCP プロベナンスに
manifest_urlを付与します - 下流の当事者（エージェンシー、プラットフォーム、セラー）はいつでもマニフェストをフェッチして元の資格情報を検証できます
開示要件
disclosure オブジェクトは AI 生成コンテンツの規制上の義務を宣言します。
レンダリングガイダンス
各管轄区域のrender_guidance オブジェクトは、規制の要件に基づいて開示をどのようにレンダリングすべきかについての宣言当事者の意図を表現します。規制によって持続性の要件が異なる:
continuous— 開示はコンテンツ表示の全期間を通じて視覚的または聴覚的に存在し続けなければなりません。ビデオ/オーディオの場合は全再生時間。静的フォーマット（ディスプレイ、DOOH）の場合は全表示スロット。DOOH では「コンテンツ時間」はスクリーンのフルローテーションサイクルではなく、ローテーション内の広告の表示スロットを意味します。initial— 開示は削除される前に最小時間、開始時に表示されなければなりません。min_duration_msと組み合わせて時間を指定する — それなしでは、時間はパブリッシャーの裁量に委ねられます。flexible— 開示の存在で十分。パブリッシャーがタイミングと時間を制御します。
required_disclosures[].persistence とプロベナンス render_guidance.persistence）、最も制限的なモードが適用されます: continuous > initial > flexible。
positions 配列は順序付き優先リストです。配信フォーマットがサポートする最初の位置が使用されるべきです。例えば、["overlay", "subtitle"] は「オーバーレイを優先し、オーバーレイが利用できない場合はサブタイトルにフォールバックする」を意味します。
すべての位置と持続性の組み合わせが意味のあるわけではありません。本質的に持続時間が限定される位置 — end_card、pre_roll — はコンテンツの一部にのみ表示されるため、continuous 持続性を満たすことができません。クリエイティブエージェントはこれらの位置で continuous を要求すべきではなく、フォーマットはそれらの continuous サポートを主張すべきではありません。
オーディオのみの環境（ポッドキャスト、ストリーミングオーディオ、スマートスピーカー）では、audio、pre_roll、companion の位置のみが適用されます。視覚的な位置（overlay、footer、subtitle）はスクリーンなしでは未定義です。オーディオフォーマット用に構築するクリエイティブエージェントは render_guidance.positions をオーディオ互換の値に限定すべきです。
レンダリングガイダンスはクリエイティブとともにサプライチェーンを通じて移動します。配信時に、パブリッシャーはプロベナンスからガイダンスを読み取り、それに応じてレンダリングします。ガバナンスエージェントはパブリッシャーが宣言されたガイダンスに従ったかどうかを監査できます。
マルチアセット集計
DCO で一般的な、同じ管轄区域に対して異なるrender_guidance を持つ複数のアセットからクリエイティブが組み立てられる場合、最も制限的な持続性が組み立てられたクリエイティブ全体に適用されます: いずれかのアセットが continuous を必要とする場合、組み立てられたクリエイティブも continuous を必要とします。これは競合解決と同じ優先順位に従う: continuous > initial > flexible。
執行と自己報告コンプライアンス
パブリッシャーがレンダリングサーフェスを制御するフォーマット（ホスト型ビデオ、ディスプレイバナー、SSAI）では、パブリッシャーはレンダリングガイダンスを直接執行できる — オーバーレイをレンダリングし、その時間を制御し、コンプライアンスを検証します。 不透明な自己レンダリングクリエイティブ（MRAID、JavaScript タグ、VPAID）では、クリエイティブが独自のビューポートを制御します。パブリッシャーはクリエイティブのサンドボックス内に開示レンダリングを注入または執行できません。この場合、開示コンプライアンスはビルド中にクリエイティブエージェントが開示を埋め込むことに依存します。フォーマットのdisclosure_capabilities はこれを反映すべきだ: フォーマットのレンダリング層が検証または執行できる持続性モードのみを主張し、クリエイティブの自己コンプライアンスに依存するモードは主張しません。ガバナンスエージェントは、ヘッドレス環境でクリエイティブをレンダリングして開示の存在を検査することにより、get_creative_features を通じて事後に自己レンダリングされた開示を検証できます。
既知の規制識別子
規制識別子は慣例であり、クローズドな列挙型ではありません。プロトコル変更なしに新しい規制を参照できます。
埋め込みプロベナンスとウォーターマーク
c2pa.manifest_url はサイドカー参照です: 分離された暗号マニフェストへの URL ポインタ。ネットワークを越えて耐久性がありますが、ファイルレベルの C2PA バインディングはアドサーバーのトランスコード、リサイズ、再エンコードを生き延びません。アセットがパブリッシャーに到達する前に中間者を通過するパイプラインでは、トランスコード耐性のある二つのフィールドがアセット自体の内側にプロベナンスの証拠を運びます。
embedded_provenance[]
コンテンツストリーム内に運ばれるプロベナンスメタデータ——ファイルコンテナに埋め込まれたマニフェスト（例: JPEG の JUMBF ボックス、C2PA セクション A.7 に従う平文の C2PATextManifestWrapper）として、またはプロベナンスレコードをエンコードまたは参照するコンテンツ内の不可視マーカーとして。
verify_agent は、受信者が自己検証できないメソッド（例: provenance_markers）では存在すべきです（SHOULD）。受信者がすでに信頼する公開鍵を持つ C2PA テキストマニフェストのような自己検証可能な埋め込みでは省略してもよい（MAY）。
watermarks[]
アセット内に識別子またはフィンガープリントをエンコードするコンテンツウォーターマーク。埋め込みプロベナンスとは異なります: ウォーターマークは識別子（誰が生成したか、誰が所有するか）を運び、埋め込みプロベナンスは構造化されたプロベナンスレコード（完全な管理の連鎖）を運ぶか参照します。単一のアセットは両方を運べます。
verify_agent の形状
verify_agent は、このレイヤーがセラーがすでに受け入れているガバナンスエージェントによって検証できる、というバイヤーの表明です。セラーは記録上の検証者です: 呼び出すエージェントを creative_policy.accepted_verifiers[]（get_products が返す）に公開し、バイヤーの verify_agent.agent_url はそれらのエントリの一つと正規化された一致でなければなりません（MUST）。リスト外の URL は、いかなるアウトバウンド呼び出しの前に PROVENANCE_VERIFIER_NOT_ACCEPTED で拒否されます。
これはバイヤー提供の証拠であって、バイヤー主導のルーティングではありません。セラーは実際にどのエージェントを呼ぶかを選び、バイヤーが指名したのとは異なるオンリストのエージェントを代わりに使ってもよい。許可リスト外のバイヤー主張のエンドポイントは呼びません。
バイヤーは、自己検証可能な埋め込み（例: セラーがすでに信頼する公開鍵を持つ C2PA テキストマニフェスト）については
verify_agent を省略してもよい（MAY）——その場合、セラーは評価時に accepted_verifiers からエージェントを選択します。
継承は親の provenance オブジェクトと同じルールに従います: 最も具体的なものが優先され、置換はオブジェクト全体で、フィールドレベルのマージはありません。
クリエイティブポリシー執行
セラーはcreative-policy でプロベナンス要件を表現します——すべてのプロダクトのフィールドで、get_products を通じて表面化されるため、バイヤーは提出前に要件を把握できます。
provenance_required: true は、クリエイティブが継承チェーンのどこかに何らかのプロベナンスオブジェクトを運ばなければならないことを意味します。provenance_requirements はそれをフィールドレベルの期待で洗練します。accepted_verifiers[] は、セラーが運用または許可リストに登録したガバナンスエージェントを公開します——セラーは記録上の検証者であり、バイヤーの verify_agent の参照はこれらの agent_url の値の一つと正規化された一致でなければなりません（MUST）。フィールドレベルの要件はセラーが強制し、JSON スキーマはそれらを検証しません。
要件を公開するセラーはそれを強制しなければなりません（MUST）。sync_creatives は準拠しない提出を次のいずれかで拒否します:
error.field は、検査された解決済みのプロベナンスのパスを指さなければなりません（MUST）。PROVENANCE_CLAIM_CONTRADICTED の error.details は、監査上安全な許可リスト { agent_url, feature_id, claimed_value, observed_value, confidence } に加えて、セラーがバイヤーの指名したのとは別のオンリストエージェントを呼んだ場合の substituted_for に限定されます——セラーは任意の検証者拡張フィールド、detail_url、またはテナントをまたぐデータや PII を運ぶ可能性のある検証者レスポンス形状を転送してはなりません（MUST NOT）。
これらのコードは訂正可能です: バイヤーのオーケストレーターがそれらを読み、クリエイティブを修正し、再提出します。訂正なしの自動リトライは通りません。
プロベナンスが付与される場所
スキーマリファレンス
関連ドキュメント
- プロベナンス検証 — ガバナンスインフラが AI プロベナンス主張を検証する方法
- クリエイティブガバナンス —
get_creative_featuresを通じた機能ベースのクリエイティブ評価 - コンテンツ標準 — パブリッシャーコンテンツのプライバシー保護ブランド適合性
- 生成クリエイティブ —
build_creativeによる AI 駆動のクリエイティブ生成