Skip to main content
クリエイティブがプロベナンスクレームと共に届いた場合、受け取った側はそれを信頼するかどうかを判断する必要があります。このページでは AdCP がその判断をどのように処理するかを説明します: プロベナンスクレームはバイヤーからセラーへクリエイティブと共に伝達され、各強制ポイント — パブリッシャー、SSP、検証ベンダー — が独自の独立したチェックを実行します。いかなる当事者の証明も額面通りには受け取られない。宣言と検証の間のこの分離こそが、関与する当事者が競合するインセンティブを持つ場合でもシステムが機能する理由です。

3つのモーメントライフサイクル

AI プロベナンスは3つの明確なモーメントを経由し、それぞれが既存の AdCP タスクで処理されます。 各モーメントは独立しています。バイヤーは検証が行われる前にプロベナンスを宣言できます。セラーは宣言を要求せずに検証できます。強制は両方なしでも起きる。

バイヤーが宣言できるもの

プロベナンスは3系統の証拠を運びます。それぞれ異なるサプライチェーン操作を生き延びます。 embedded_provenance は構造化されたプロベナンス記録(管理の連鎖)を運びます。watermarks は識別子(誰が生成したか、誰が所有するか)をエンコードします。単一のアセットが両方を運ぶ場合があります。実際に添付したものに合ったフィールドを選んでください。

検証者コントラクト: セラーが公開し、バイヤーが表明し、セラーが確認する

この作業の初期ドラフトは、バイヤーが一方的に検証エンドポイントを指名することを想定していました。そのパターンは SSRF リスク、ベンダーの乱立、そして根本的に誤った信頼モデルを出荷していました。セラーは自らが公開するものについて規制上の責任を負うため、記録上の検証者です。プロトコルは現在それを反映しています。 コントラクトは3ステップで、それぞれに明確なアクターがいます。
  1. セラーが公開する — 受け入れるガバナンスエージェントを creative_policy.accepted_verifiers[]get_products で返される)に公開します。各エントリは agent_url、任意の feature_id(セラーがそのエージェントに対して要求する機能)、任意の providers[](そのエージェントがカバーする provider ラベル)を運びます。セラーはこれらのエンドポイントをすでに審査済みで、それらへの呼び出しはセラーの許可リスト内にあります。
  2. バイヤーが表明する — 各 embedded_provenance[] または watermarks[] エントリに verify_agent: { agent_url, feature_id? } ポインターを添付して、それらのエージェントのどれを使ったかを表明します。バイヤーの agent_url は、セラーが公開した accepted_verifiers[].agent_url のいずれかと(正規化して)一致しなければなりません(MUST)。これはバイヤーが提供する証拠であり、バイヤー主導のルーティングではありません。
  3. セラーが確認する — バイヤーの verify_agent.agent_url を公開リストと突き合わせ(リスト外の URL はいかなるアウトバウンド呼び出しの前に PROVENANCE_VERIFIER_NOT_ACCEPTED で拒否)、次に一致するリスト内エージェントに対して get_creative_features を呼び出し、結果をバイヤーのクレームと照合します。セラーはバイヤーが指名したのと異なるリスト内エージェントを使ってもかまいません(MAY)。セラーが記録上の検証者だからです。置き換える場合、バイヤーが監査できるよう error.details が呼び出したエージェントと substituted_for の両方を運びます。
セラーは accepted_verifiers にない URL を呼び出してはなりません(MUST NOT)— これがバイヤー制御の URL による信頼ギャップを閉じます。verify_agent を省略するバイヤー(例: セラーがすでに信頼する公開鍵を持つ自己検証可能な C2PA テキストマニフェスト)は、エージェント選択を完全にセラーのディスカバリーに委ねます。

セラーが要求できるもの

セラーは必要なものを creative_policy で表現し、get_products で返すことで、バイヤーが提出前に要件を確認できるようにします。 要件を公開するセラーは sync_creatives でそれを強制しなければなりません(MUST)— これが構造的拒否のコントラクトです。クレームの真正性のコントラクト(バイヤーの digital_source_type は実際にコンテンツと一致するか?)は get_creative_features にあり、PROVENANCE_CLAIM_CONTRADICTED として表面化します。

拒否エラーコード

sync_creatives がプロベナンス上の理由でクリエイティブを拒否する場合、クリエイティブごとの結果は次のいずれかを持つ構造化エラーを運びます。 これらのコードを受け取るバイヤーは、セラーと交渉することなく自己修正できます — 失敗は機械可読です。修正なしの自動リトライは通りません。

拒否ではなく監査観察

一部のプロベナンスクレームは、検証者が反証していなくても監査ルーティングに値します。正典的なケースは、provenance.disclosure.requiredfalse である一方で provenance.human_oversightedited または directed に設定されている場合です。この組み合わせは、宣言当事者が編集責任の適用除外を援用する場合には正当かもしれませんが、検証者はスキーマフィールドだけから法的前提条件を判断できません。 ガバナンスエージェントは、そのクレームの組み合わせを、成功した get_creative_features レスポンスで OVERSIGHT_DISCLOSURE_CARVEOUT_CLAIMED として表面化すべきです(SHOULD)。この観察はクレーム駆動です。observed_valueconfidence のような検証者の観察は、利用可能な場合は有用な監査コンテキストですが、観察が発火するために必須ではありません。field は複数フィールドの組み合わせのうちリスクのあるクレーム側を指すため、正典的なパスは creative_manifest.provenance.disclosure.required です。
この観察は PROVENANCE_CLAIM_CONTRADICTED ではなく、それ単独で拒否の根拠にはなりません。セラーは、監査のために観察を保持し、人間のレビュアーにルーティングし、または宣言当事者に帯域外で裏付け証拠を求めながら、クリエイティブを受け入れてもかまいません(MAY)。反証エラーと同様に、audit_observations[].details は監査に安全な許可リスト { agent_url, feature_id, claimed_value, observed_value, confidence, substituted_for } に限定されます。OVERSIGHT_DISCLOSURE_CARVEOUT_CLAIMED については、claimed_value{ human_oversight, disclosure_required } で、disclosure_requiredcreative_manifest.provenance.disclosure.required のフラット化されたエイリアスです。セラーは、任意の検証者拡張フィールド、detail_url、またはクロステナントのレポートデータを自身のバイヤー向けレスポンスにコピーしてはなりません(MUST NOT)。

get_creative_features による AI 検出

AI 検出はクリエイティブガバナンス機能であり、get_creative_features を通じて専門エージェントが評価する — セキュリティスキャン、クリエイティブ品質、コンテンツ分類に使われるのと同じタスクです。AI 検出に別のプロトコルやワークフローは不要です。

エージェントが AI 検出ケイパビリティを宣言します

AI 検出エージェントは get_adcp_capabilities で機能をアドバタイズする:

セラーがクリエイティブを評価します

セラーはクリエイティブマニフェストを AI 検出エージェントに送信します:

エージェントが検出結果を返す

セラーが強制ロジックを適用します

セラーは検出結果をバイヤーのプロベナンスクレームと比較する:

マルチエージェント評価

AI 検出はマルチエージェントクリエイティブガバナンスパターンに自然に適合します。クリエイティブを評価するセラーは複数の専門エージェントを並行して呼び出せる: オーケストレーターはすべてのエージェントを get_creative_features で呼び出し、結果を集計し、すべてに対して要件を適用します。AI 検出は評価マトリクスの1列であり、別のワークフローではありません。

コンテンツ標準との統合

パブリッシャーコンテンツ(アーティファクト)の場合、プロベナンス検証はコンテンツ標準インフラを使います: アライメントのための calibrate_content と監査のための validate_content_delivery

アーティファクトのプロベナンス

パブリッシャーはバイヤーがクリエイティブにプロベナンスを宣言するのと同じ方法で、アーティファクトにプロベナンスを宣言する:

AI プロベナンスのキャリブレーション

calibrate_content の実行中、検証エージェントはアーティファクトのプロベナンスクレームが正確かどうかを評価できます。これはブランドスータビリティと同じキャリブレーションダイアログを使う — 検証エージェントは説明付きのバーディクトを返します:

配信後の検証

バイヤーは validate_content_delivery を通じて配信済みコンテンツの AI プロベナンスを監査できる — ブランドスータビリティ監査と同じタスクだ:

コンプライアンスプロファイル

規制環境によってプロベナンス強制のレベルが異なります。以下は設定例です。
これらのプロファイルは説明用の設定例であり、スキーマ定義オブジェクトではありません。各セラーは自社の規制要件に適した強制ロジックを実装します。AdCP スキーマはデータモデルを提供し、強制ルールは実装上の判断です。

規制当局向け

AdCP はプログラマティック広告における AI 開示のための、機械可読でプロトコルレベルのメカニズムを提供します。サプライチェーン内のすべてのクリエイティブとコンテンツアーティファクトは、デジタルソースタイプ、使用された AI ツール、人間の監督レベル、管轄ごとの適用可能な開示要件(eu_ai_act_article_50ca_sb_942cn_deep_synthesis などの特定の規制識別子を含む)を宣言する構造化されたプロベナンスメタデータを保持できます。 このメタデータは IPTC デジタルソースタイプ語彙を使用します。これは AI コンテンツラベリングのために C2PA Content Credentials、Meta、Google が採用したのと同じ分類システムです。AdCP は新しいタクソノミーを発明しません。既存の広く採用された分類を、これまで構造化された形式で利用できなかった広告サプライチェーンに伝達します。

検証は独立していて自己申告ではありません

AdCP のプロベナンスは明示的にクレームであり、認証ではありません。宣言する当事者 — 通常は広告主またはエージェンシー — はクリエイティブを提出する際にプロベナンスを添付します。強制する当事者 — 通常はパブリッシャーまたはサプライサイドプラットフォーム — は AI 検出サービス、C2PA マニフェスト検証、またはその両方を使って独立してそのクレームを検証します。この検証は既存の AdCP ガバナンスメカニズム(クリエイティブには get_creative_features、パブリッシャーコンテンツには calibrate_content)を通じて行われ、新しいインフラを必要としません。 このアーキテクチャは広告コンプライアンスの構造的問題に対処する: クリエイティブを提出する当事者は AI 関与を過小申告する動機がある(プレースメント制限や開示要件を回避するため)一方、クリエイティブを公開する当事者は非開示に対する規制責任を負う。プロベナンスを信頼された主張ではなく検証可能なクレームとして扱うことで、プロトコルはコンプライアンスがいかなる参加者の誠意にも依存しないことを保証します。

規制要件へのマッピング

EU AI 法第50条: AI 生成コンテンツが機械可読な方法でラベル付けされることを要求します。AdCP の digital_source_type フィールドはアセットレベルでこの分類を提供します。disclosure.jurisdictions 配列により、クリエイティブは管轄固有のラベルテキストを保持できます。強制ポイントは AI 生成を示す digital_source_type 値(trained_algorithmic_mediacomposite_with_trained_algorithmic_media)に基づいてクリエイティブをフィルタリングまたはフラグ付けできます。 カリフォルニア州 SB 942: コンテンツが AI によって生成または実質的に変更された場合の開示を要求します。digital_source_typehuman_oversight フィールドを合わせることで、クリエイティブが開示閾値を満たすかどうかを判断するために必要な情報が提供されます。disclosure.required フラグは強制のための直接的なシグナルを提供します。 プラットフォームの要件(Meta、Google、TikTok): 主要プラットフォームはすでに IPTC に準拠したメタデータを使った AI コンテンツラベリングを要求しています。AdCP のプロベナンス構造は同じ基盤となる語彙を使用するため、これらの要件と直接互換性があります。 AdCP は特定のクリエイティブにどの規制が適用されるかを決定しません。各強制ポイントが自身の管轄ルールを適用できるよう、構造化されたメタデータを提供します。プロトコルはデータを運び、強制する当事者がコンプライアンスの決定を行います。

検証フロー

実装チェックリスト

バイヤー(ブランドとエージェンシー)

セラー(パブリッシャーとプラットフォーム)

クリエイティブエージェント

ガバナンスエージェント(AI 検出)

関連