> ## 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.
# プロベナンス検証
> AI プロベナンスクレームが AdCP でクリエイティブと共に伝達され、配信チェーンの各強制ポイントで独立して検証される仕組み。
クリエイティブがプロベナンスクレームと共に届いた場合、受け取った側はそれを信頼するかどうかを判断する必要があります。このページでは AdCP がその判断をどのように処理するかを説明します: プロベナンスクレームはバイヤーからセラーへクリエイティブと共に伝達され、各強制ポイント — パブリッシャー、SSP、検証ベンダー — が独自の独立したチェックを実行します。いかなる当事者の証明も額面通りには受け取られない。宣言と検証の間のこの分離こそが、関与する当事者が競合するインセンティブを持つ場合でもシステムが機能する理由です。
## 3つのモーメントライフサイクル
AI プロベナンスは3つの明確なモーメントを経由し、それぞれが既存の AdCP タスクで処理されます。
```mermaid theme={null}
flowchart LR
subgraph declare["1. 宣言"]
direction TB
D1["sync_creatives / build_creative"]
D2["バイヤーがクリエイティブマニフェストまたは
アセットにプロベナンスを添付する"]
D1 --> D2
end
subgraph verify["2. 検証"]
direction TB
V1["get_creative_features /
calibrate_content"]
V2["ガバナンスエージェントが
コンテンツを独立して評価する"]
V1 --> V2
end
subgraph enforce["3. 強制"]
direction TB
E1["creative_policy /
validate_content_delivery"]
E2["セラー/パブリッシャーがルールを適用して
受け入れまたは拒否する"]
E1 --> E2
end
declare --> verify --> enforce
```
| モーメント | タイミング | 担当 | タスク |
| ------ | ---------------------- | -------------------------- | --------------------------------------------- |
| **宣言** | クリエイティブ提出時 | バイヤー、エージェンシー、またはクリエイティブツール | `sync_creatives`、`build_creative` |
| **検証** | トラフィッキング前またはキャリブレーション中 | セラーのガバナンスエージェント | `get_creative_features`、`calibrate_content` |
| **強制** | 受け入れ決定または配信後監査 | セラーエージェント、バイヤーエージェント | `creative_policy`、`validate_content_delivery` |
各モーメントは独立しています。バイヤーは検証が行われる前にプロベナンスを宣言できます。セラーは宣言を要求せずに検証できます。強制は両方なしでも起きる。
## バイヤーが宣言できるもの
プロベナンスは3系統の証拠を運びます。それぞれ異なるサプライチェーン操作を生き延びます。
| Field | What it carries | Survives transcoding? |
| ----------------------- | ----------------------------------------------------- | --------------------------------------------------- |
| `c2pa.manifest_url` | 分離された暗号マニフェストへのサイドカー参照 | No — ファイルレベルのバインディングはアドサーバーのトランスコード、リサイズ、再エンコードで壊れる |
| `embedded_provenance[]` | コンテンツストリーム*内*に埋め込まれたプロベナンスメタデータ（マニフェストラッパーまたは不可視マーカー） | Yes — CMS 取り込み、コピーペースト、再フォーマット、CDN 再エンコードを通じて残るよう設計 |
| `watermarks[]` | コンテンツにエンコードされた識別子またはフィンガープリント（音声、画像、動画、テキストの透かし） | Yes — 知覚的コンテンツを保持する変換を生き延びる |
`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` の両方を運びます。
```json theme={null}
// 1. Seller publishes — returned by get_products on each Product
{
"creative_policy": {
"accepted_verifiers": [
{
"agent_url": "https://governance.encypher.seller.example",
"feature_id": "encypher.markers_present_v2",
"providers": ["Encypher"]
},
{
"agent_url": "https://governance.imatag.seller.example",
"feature_id": "imatag.watermark_detected",
"providers": ["Imatag"]
}
]
}
}
// 2. Buyer represents — attached to creative on sync_creatives
{
"embedded_provenance": [
{
"method": "provenance_markers",
"provider": "Encypher",
"verify_agent": {
"agent_url": "https://governance.encypher.seller.example",
"feature_id": "encypher.markers_present_v2"
}
}
]
}
// 3. Seller confirms — cross-check, then call, then reconcile.
// Off-list URL → PROVENANCE_VERIFIER_NOT_ACCEPTED, no outbound call.
// On-list URL with contradicting verifier result → PROVENANCE_CLAIM_CONTRADICTED.
```
セラーは `accepted_verifiers` にない URL を呼び出してはなりません（MUST NOT）— これがバイヤー制御の URL による信頼ギャップを閉じます。`verify_agent` を省略するバイヤー（例: セラーがすでに信頼する公開鍵を持つ自己検証可能な C2PA テキストマニフェスト）は、エージェント選択を完全にセラーのディスカバリーに委ねます。
## セラーが要求できるもの
セラーは必要なものを `creative_policy` で表現し、`get_products` で返すことで、バイヤーが提出前に要件を確認できるようにします。
| Field | Effect |
| ----------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- |
| `provenance_required: true` | クリエイティブは継承チェーンのどこかに*何らかの*プロベナンスオブジェクトを運ばなければなりません（MUST）。プロベナンスなしの提出は `PROVENANCE_REQUIRED` で拒否されます。 |
| `provenance_requirements.{require_digital_source_type, require_disclosure_metadata, require_embedded_provenance}` | フィールドレベルの要件。名前付きフィールドを欠く提出は、対応する `PROVENANCE_*_MISSING` コードで拒否されます。フィールドレベルの要件はセラーが強制します — JSON スキーマ検証はこれらをチェックしません。 |
| `accepted_verifiers[]` | セラーがプロベナンスクレームを検証するために呼び出すガバナンスエージェント。バイヤーの `verify_agent` 参照は、これらの `agent_url` 値のいずれかと正規化して一致しなければなりません（MUST）。 |
要件を公開するセラーは `sync_creatives` でそれを強制しなければなりません（MUST）— これが構造的拒否のコントラクトです。クレームの真正性のコントラクト（バイヤーの `digital_source_type` は実際にコンテンツと一致するか？）は `get_creative_features` にあり、`PROVENANCE_CLAIM_CONTRADICTED` として表面化します。
### 拒否エラーコード
`sync_creatives` がプロベナンス上の理由でクリエイティブを拒否する場合、クリエイティブごとの結果は次のいずれかを持つ構造化エラーを運びます。
| Code | Meaning | `error.field` points at |
| ---------------------------------------- | ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `PROVENANCE_REQUIRED` | クリエイティブのどこにもプロベナンスオブジェクトがないが `provenance_required: true` | プロベナンスが期待されたマニフェストパス |
| `PROVENANCE_DIGITAL_SOURCE_TYPE_MISSING` | 解決されたプロベナンスに `digital_source_type` がない | 解決された `provenance.digital_source_type` パス |
| `PROVENANCE_DISCLOSURE_MISSING` | 解決されたプロベナンスに `disclosure.required` がない（または jurisdictions なしで true） | 解決された `provenance.disclosure` パス |
| `PROVENANCE_EMBEDDED_MISSING` | 解決されたプロベナンスに `embedded_provenance` エントリがない | 解決された `provenance.embedded_provenance` パス |
| `PROVENANCE_VERIFIER_NOT_ACCEPTED` | `verify_agent.agent_url` がセラーの `accepted_verifiers` リストにない | 問題の `verify_agent.agent_url` パス |
| `PROVENANCE_CLAIM_CONTRADICTED` | 検証者（`accepted_verifiers` から呼び出された）がバイヤーのクレームを積極的に反証 | クレームが反証されたプロベナンスフィールド。`error.details` は `{ agent_url, feature_id, claimed_value, observed_value, confidence }` に加え、セラーがバイヤーの指名と異なるリスト内エージェントを使った場合の `substituted_for` に限定 |
これらのコードを受け取るバイヤーは、セラーと交渉することなく自己修正できます — 失敗は機械可読です。修正なしの自動リトライは通りません。
### 拒否ではなく監査観察
一部のプロベナンスクレームは、検証者が反証していなくても監査ルーティングに値します。正典的なケースは、`provenance.disclosure.required` が `false` である一方で `provenance.human_oversight` が `edited` または `directed` に設定されている場合です。この組み合わせは、宣言当事者が編集責任の適用除外を援用する場合には正当かもしれませんが、検証者はスキーマフィールドだけから法的前提条件を判断できません。
ガバナンスエージェントは、そのクレームの組み合わせを、成功した `get_creative_features` レスポンスで `OVERSIGHT_DISCLOSURE_CARVEOUT_CLAIMED` として表面化すべきです（SHOULD）。この観察はクレーム駆動です。`observed_value` や `confidence` のような検証者の観察は、利用可能な場合は有用な監査コンテキストですが、観察が発火するために必須ではありません。`field` は複数フィールドの組み合わせのうちリスクのあるクレーム側を指すため、正典的なパスは `creative_manifest.provenance.disclosure.required` です。
```json theme={null}
{
"audit_observations": [
{
"code": "OVERSIGHT_DISCLOSURE_CARVEOUT_CLAIMED",
"severity": "audit-worthy",
"recovery": "informational",
"field": "creative_manifest.provenance.disclosure.required",
"message": "Creative claims human-directed AI output does not require disclosure; retain for audit review.",
"details": {
"agent_url": "https://governance.encypher.seller.example",
"feature_id": "ai_generated",
"claimed_value": {
"human_oversight": "directed",
"disclosure_required": false
},
"observed_value": true,
"confidence": 0.94
}
}
]
}
```
この観察は `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_required` は `creative_manifest.provenance.disclosure.required` のフラット化されたエイリアスです。セラーは、任意の検証者拡張フィールド、`detail_url`、またはクロステナントのレポートデータを自身のバイヤー向けレスポンスにコピーしてはなりません（MUST NOT）。
## get\_creative\_features による AI 検出
AI 検出はクリエイティブガバナンス機能であり、`get_creative_features` を通じて専門エージェントが評価する — セキュリティスキャン、クリエイティブ品質、コンテンツ分類に使われるのと同じタスクです。AI 検出に別のプロトコルやワークフローは不要です。
### エージェントが AI 検出ケイパビリティを宣言します
AI 検出エージェントは `get_adcp_capabilities` で機能をアドバタイズする:
```json theme={null}
{
"governance": {
"creative_features": [
{
"feature_id": "ai_generated",
"type": "binary",
"description": "Whether the creative contains AI-generated content",
"methodology_url": "https://detector.example.com/methodology"
},
{
"feature_id": "ai_modified",
"type": "binary",
"description": "Whether the creative contains AI-modified elements",
"methodology_url": "https://detector.example.com/methodology"
},
{
"feature_id": "ai_confidence",
"type": "quantitative",
"range": { "min": 0, "max": 1 },
"description": "Confidence score for AI detection result",
"methodology_url": "https://detector.example.com/methodology"
}
]
}
}
```
### セラーがクリエイティブを評価します
セラーはクリエイティブマニフェストを AI 検出エージェントに送信します:
```json theme={null}
{
"creative_manifest": {
"format_id": {
"agent_url": "https://creative.adcontextprotocol.org",
"id": "display_300x250"
},
"assets": {
"banner_image": {
"url": "https://cdn.novabrands.example.com/hero.jpg",
"width": 300,
"height": 250
},
"headline": {
"content": "Nutrition dogs love"
}
}
},
"feature_ids": ["ai_generated", "ai_modified", "ai_confidence"]
}
```
### エージェントが検出結果を返す
```json theme={null}
{
"results": [
{ "feature_id": "ai_generated", "value": true, "confidence": 0.94 },
{ "feature_id": "ai_modified", "value": false },
{ "feature_id": "ai_confidence", "value": 0.94 }
],
"detail_url": "https://detector.example.com/reports/ctx_xyz789"
}
```
### セラーが強制ロジックを適用します
セラーは検出結果をバイヤーのプロベナンスクレームと比較する:
```javascript theme={null}
const provenance = creative.manifest.provenance;
const detection = await detectionAgent.getCreativeFeatures({
creative_manifest: creative.manifest,
feature_ids: ['ai_generated']
});
if (detection.errors) {
// Detection failed - handle based on policy
return;
}
const aiDetected = detection.results.find(
f => f.feature_id === 'ai_generated'
);
// Case 1: Provenance claims non-AI, detection says AI
if (
provenance?.digital_source_type === 'digital_capture' &&
aiDetected?.value === true &&
aiDetected?.confidence > 0.9
) {
// Reject - provenance claim contradicts detection
return;
}
// Case 2: AI content in jurisdiction requiring disclosure
if (
aiDetected?.value === true &&
!provenance?.disclosure?.required
) {
// Reject - AI content without required disclosure metadata
return;
}
```
### マルチエージェント評価
AI 検出はマルチエージェントクリエイティブガバナンスパターンに自然に適合します。クリエイティブを評価するセラーは複数の専門エージェントを並行して呼び出せる:
| エージェント | 機能 | プロベナンスとの関連 |
| ----------- | ---------------------------- | --------------- |
| セキュリティスキャナー | `auto_redirect`、`cloaking` | なし — 独立した問題 |
| AI 検出 | `ai_generated`、`ai_modified` | プロベナンスクレームを検証する |
| コンテンツ分類器 | `iab_casinos_gambling` | なし — 独立した問題 |
| クリエイティブ品質 | `brand_consistency` | なし — 独立した問題 |
オーケストレーターはすべてのエージェントを `get_creative_features` で呼び出し、結果を集計し、すべてに対して要件を適用します。AI 検出は評価マトリクスの1列であり、別のワークフローではありません。
## コンテンツ標準との統合
パブリッシャーコンテンツ（アーティファクト）の場合、プロベナンス検証はコンテンツ標準インフラを使います: アライメントのための `calibrate_content` と監査のための `validate_content_delivery`。
### アーティファクトのプロベナンス
パブリッシャーはバイヤーがクリエイティブにプロベナンスを宣言するのと同じ方法で、アーティファクトにプロベナンスを宣言する:
```json theme={null}
{
"property_id": { "type": "domain", "value": "newssite.example.com" },
"artifact_id": "article_trends_2026",
"provenance": {
"digital_source_type": "digital_creation",
"declared_by": { "role": "platform" }
},
"assets": [
{
"type": "text",
"role": "title",
"content": "Industry trends to watch in 2026"
},
{
"type": "image",
"url": "https://cdn.newssite.example.com/ai-illustration.jpg",
"alt_text": "Conceptual illustration",
"provenance": {
"digital_source_type": "trained_algorithmic_media",
"ai_tool": { "name": "Midjourney", "version": "v7" },
"declared_by": { "role": "platform" }
}
}
]
}
```
### AI プロベナンスのキャリブレーション
`calibrate_content` の実行中、検証エージェントはアーティファクトのプロベナンスクレームが正確かどうかを評価できます。これはブランドスータビリティと同じキャリブレーションダイアログを使う — 検証エージェントは説明付きのバーディクトを返します:
```json theme={null}
{
"verdict": "fail",
"explanation": "The article's hero image shows strong indicators of AI generation (GAN artifacts, inconsistent lighting) but is marked as digital_creation. The provenance claim does not match detection results.",
"features": [
{
"feature_id": "provenance_accuracy",
"status": "failed",
"explanation": "Image asset provenance claims digital_creation but AI detection confidence is 0.92."
},
{
"feature_id": "brand_safety",
"status": "passed",
"explanation": "No safety concerns with the content itself."
}
]
}
```
### 配信後の検証
バイヤーは `validate_content_delivery` を通じて配信済みコンテンツの AI プロベナンスを監査できる — ブランドスータビリティ監査と同じタスクだ:
```json theme={null}
{
"standards_id": "acme_ai_disclosure_policy",
"records": [
{
"record_id": "imp_54321",
"media_buy_id": "mb_acme_q1",
"artifact": {
"property_id": { "type": "domain", "value": "newssite.example.com" },
"artifact_id": "article_trends_2026",
"provenance": {
"digital_source_type": "digital_creation",
"declared_by": { "role": "platform" }
},
"assets": [
{
"type": "image",
"url": "https://cdn.newssite.example.com/ai-illustration.jpg"
}
]
}
}
]
}
```
## コンプライアンスプロファイル
規制環境によってプロベナンス強制のレベルが異なります。以下は設定例です。
```json EU（厳格） theme={null}
{
"profile": "eu_strict",
"creative_policy": {
"provenance_required": true
},
"enforcement_rules": {
"ai_detection_required": true,
"ai_detection_confidence_threshold": 0.85,
"disclosure_required_for": [
"trained_algorithmic_media",
"composite_with_trained_algorithmic_media",
"human_edits"
],
"reject_on_mismatch": true,
"jurisdictions": [
{
"country": "DE",
"regulation": "eu_ai_act_article_50",
"label_text": "KI-generiert"
},
{
"country": "FR",
"regulation": "eu_ai_act_article_50",
"label_text": "Contenu généré par l'IA"
}
]
}
}
```
```json 米国/カリフォルニア（中程度） theme={null}
{
"profile": "us_california",
"creative_policy": {
"provenance_required": true
},
"enforcement_rules": {
"ai_detection_required": true,
"ai_detection_confidence_threshold": 0.90,
"disclosure_required_for": [
"trained_algorithmic_media",
"composite_with_trained_algorithmic_media"
],
"reject_on_mismatch": true,
"jurisdictions": [
{
"country": "US",
"region": "CA",
"regulation": "ca_sb_942",
"label_text": "Created with AI"
}
]
}
}
```
```json 緩和 theme={null}
{
"profile": "permissive",
"creative_policy": {
"provenance_required": false
},
"enforcement_rules": {
"ai_detection_required": false,
"log_provenance_if_present": true,
"reject_on_mismatch": false
}
}
```
これらのプロファイルは説明用の設定例であり、スキーマ定義オブジェクトではありません。各セラーは自社の規制要件に適した強制ロジックを実装します。AdCP スキーマはデータモデルを提供し、強制ルールは実装上の判断です。
## 規制当局向け
AdCP はプログラマティック広告における AI 開示のための、機械可読でプロトコルレベルのメカニズムを提供します。サプライチェーン内のすべてのクリエイティブとコンテンツアーティファクトは、デジタルソースタイプ、使用された AI ツール、人間の監督レベル、管轄ごとの適用可能な開示要件（`eu_ai_act_article_50`、`ca_sb_942`、`cn_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_media`、`composite_with_trained_algorithmic_media`）に基づいてクリエイティブをフィルタリングまたはフラグ付けできます。
**カリフォルニア州 SB 942**: コンテンツが AI によって生成または実質的に変更された場合の開示を要求します。`digital_source_type` と `human_oversight` フィールドを合わせることで、クリエイティブが開示閾値を満たすかどうかを判断するために必要な情報が提供されます。`disclosure.required` フラグは強制のための直接的なシグナルを提供します。
**プラットフォームの要件（Meta、Google、TikTok）**: 主要プラットフォームはすでに IPTC に準拠したメタデータを使った AI コンテンツラベリングを要求しています。AdCP のプロベナンス構造は同じ基盤となる語彙を使用するため、これらの要件と直接互換性があります。
AdCP は特定のクリエイティブにどの規制が適用されるかを決定しません。各強制ポイントが自身の管轄ルールを適用できるよう、構造化されたメタデータを提供します。プロトコルはデータを運び、強制する当事者がコンプライアンスの決定を行います。
### 検証フロー
```mermaid theme={null}
flowchart TB
subgraph creative["広告クリエイティブ"]
C1["バイヤーがクリエイティブマニフェストに
プロベナンスを宣言する"]
C2["セラーが creative_policy で
プロベナンスを要求する"]
C3["AI 検出エージェントが
get_creative_features で評価する"]
C4["セラーがクレームと検出を比較して
受け入れまたは拒否する"]
C1 --> C2 --> C3 --> C4
end
subgraph content["パブリッシャーコンテンツ"]
P1["パブリッシャーがアーティファクトと
アセットにプロベナンスを宣言する"]
P2["検証エージェントが
calibrate_content でキャリブレーションする"]
P3["バイヤーが validate_content_delivery で
配信を監査する"]
P1 --> P2 --> P3
end
```
## 実装チェックリスト
### バイヤー（ブランドとエージェンシー）
| 要件 | 説明 |
| ------------------- | -------------------------------------------------------------------------------------- |
| クリエイティブにプロベナンスを添付する | `sync_creatives` で提出する際に `creative-asset` または `creative-manifest` に `provenance` を設定する |
| AI 関与を分類する | 各クリエイティブとアセットに正しい `digital_source_type` を使用する |
| AI ツールを宣言する | AI システムが制作に使用された場合に `ai_tool` を入力する |
| 人間の監督レベルを設定する | AI が関与する場合に `human_oversight` を示す |
| 開示義務を宣言する | 適用される各規制の `disclosure.jurisdictions` を入力する |
| C2PA 参照を保持する | コンテンツクレデンシャルが存在する場合に `c2pa.manifest_url` を含める |
| 提出前検出を実行する | オプションで独自の検出サービスからの `verification` 結果を添付する |
### セラー（パブリッシャーとプラットフォーム）
| 要件 | 説明 |
| -------------------- | ------------------------------------------------------------------- |
| クリエイティブポリシーを設定する | プロベナンスが必要な場合は `creative-policy` に `provenance_required: true` を追加する |
| AI 検出を実行する | AI 検出エージェントで `get_creative_features` を呼び出してプロベナンスクレームを検証する |
| クレームと検出を比較する | `digital_source_type` を `ai_generated` 機能の結果と比較するロジックを実装する |
| 開示を強制する | AI コンテンツがターゲット管轄に適切な `disclosure` メタデータを含んでいることを確認する |
| 不一致を拒否する | プロベナンスクレームが検出結果と矛盾するクリエイティブを拒否する |
| アーティファクトのプロベナンスを宣言する | コンテンツ標準で提出するコンテンツアーティファクトに `provenance` を添付する |
### クリエイティブエージェント
| 要件 | 説明 |
| -------------------------------- | -------------------------------------------------------------------------------------------------- |
| 生成コンテンツにプロベナンスを添付する | `build_creative` が AI コンテンツを生成する際、`digital_source_type`、`ai_tool`、`human_oversight` を含むプロベナンスを添付する |
| `declared_by` のロールを `tool` に設定する | プロベナンスを添付するクリエイティブエージェントはロール `tool` で自身を識別すべきだ |
| C2PA を引き継ぐ | ソースアセットに C2PA マニフェストがある場合、生成されたマニフェストに参照を引き継ぐ |
### ガバナンスエージェント（AI 検出）
| 要件 | 説明 |
| ----------------------------- | ------------------------------------------------------- |
| 検出機能を宣言する | `get_adcp_capabilities` で `ai_generated` と関連機能をアドバタイズする |
| `get_creative_features` を実装する | クリエイティブマニフェストを受け入れて検出結果を返す |
| 信頼スコアを返す | 確率的な評価には検出結果に `confidence` を含める |
| 詳細 URL を提供する | 監査証跡のために `detail_url` で完全なレポートにリンクする |
## 関連
* [AI プロベナンスと開示](/docs/creative/provenance) — プロベナンススキーマリファレンス、デジタルソースタイプ enum、継承モデル
* [クリエイティブガバナンス](/docs/governance/creative/index) — `get_creative_features` による機能ベースのクリエイティブ評価
* [`get_creative_features`](/docs/governance/creative/get_creative_features) — クリエイティブ機能評価のタスクリファレンス
* [コンテンツ標準](/docs/governance/content-standards/index) — パブリッシャーコンテンツのプライバシー保護ブランドスータビリティ
* [`calibrate_content`](/docs/governance/content-standards/tasks/calibrate_content) — コンテンツ標準アライメントのキャリブレーションタスク
* [`validate_content_delivery`](/docs/governance/content-standards/tasks/validate_content_delivery) — 配信後コンテンツ検証