AdCP 3.0 プロポーザル - このプロトコルは AdCP 3.0 向けに開発中です。GitHub Discussions でフィードバックを歓迎します。
概要
クリエイティブガバナンスエージェントはクリエイティブを評価して機能値を返します。異なるエージェントが異なる機能を評価する:
プロトコルは固定された機能タクソノミーを定義しません。ベンダーは
get_adcp_capabilities で評価するものを宣言し、カバレッジで競争します。
仕組み
1. エージェントが機能を宣言します
クリエイティブガバナンスエージェントはプロパティガバナンスと同じ機能定義パターンを使ってケイパビリティをアドバタイズする:get_adcp_capabilities でこれらの宣言を読む。必要な機能がエージェントの宣言にない場合、オーケストレーターは評価の途中で発見する代わりに、即座にギャップを表面化させる。
2. オーケストレーターがクリエイティブを評価します
オーケストレーターはクリエイティブマニフェストでget_creative_features を呼び出す:
3. エージェントが機能値を返す
エージェントはクリエイティブを評価して機能値を返します。レスポンスの形状はエージェントタイプに関わらず同じだ:4. オーケストレーターが要件を適用します
オーケストレーターはバイヤー定義の要件に対して機能値を評価する — プロパティリストの機能要件と同じパターン:- セキュリティ:
auto_redirectがtrueなら拒否 - 品質:
brand_consistencyが 80 未満なら拒否 - 分類:
iab_casinos_gamblingがtrueでキャンペーンがギャンブルを除外しているなら拒否
設計原則
機能 ID はスキーマの厳格さではなく厳密さを強制します。 IAB コンテンツタクソノミー 3.1 ID 181 を使ってiab_casinos_gambling を宣言する分類エージェントは、どんなカスタムスキーマと同じくらい厳密だ — 規律はエージェントの方法論に存在し、ワイヤーフォーマットではありません。iab_casinos_gambling: false を要求するオーケストレーターは、エージェントがコンテンツをどのように検出したかに関わらず、バイナリの合否回答を得ます。機能 ID がコントラクトです。プロトコルがスキーマに依存しないことで、新しい IAB カテゴリやスキャン技術を追加してもプロトコル変更が不要です。
信頼度はオプション、必須ではありません。 機能結果の confidence フィールドはオプションです。セキュリティスキャナーは通常省略する — クリエイティブには資格情報収集パターンが含まれているかいないかです。分類エージェントはコンテンツ検出が確率的だから含める: クリエイティブには 94% の確率でギャンブルコンテンツが含まれているかもしれない。エージェントが何を開示するかを決定します。曖昧さを許容できないオーケストレーターは value: false を要求して信頼度を完全に無視する; 確率的な結果を閾値で扱いたいオーケストレーターはそれを使用します。これはプロパティガバナンスの property-feature-value に存在するのと同じフィールドです。
オーケストレーターが強制する一貫性。 分類エージェントに iab_casinos_gambling を要求するオーケストレーターは、クリエイティブが評価される前のケイパビリティチェック時に、エージェントがその機能をサポートするかどうかを発見します。サポートしない場合、オーケストレーターは早期に失敗してギャップを表面化させる。これはプロパティガバナンスの動作方法を反映する: IAS と DoubleVerify は異なるプロパティ機能を評価し、オーケストレーターはどの機能が必要かを決定して対応するようにルーティングします。プロトコルスキーマで固定された機能セットを義務付けると、すべての新しい IAB カテゴリやカスタムブランド要件がプロトコルの改訂を必要とします。プロトコルは執行メカニズムを定義し、オーケストレーターは要件を定義します。
不透明な詳細インテリジェンス。 ワイヤー上の機能値は合否（バイナリ）またはスコア（定量的）だ。検出方法論、脅威インテリジェンス、詳細なスコアリングブレークダウンはベンダーのアクセス制御された detail_url と methodology_url の背後に留まる。
マルチエージェントコラボレーション
クリエイティブガバナンスの評価は通常、複数の専門エージェントが並行して動作する — プロパティガバナンスがサステナビリティ、品質、スーツアビリティエージェントに使うのと同じパターン。
各エージェントは同じ
get_creative_features タスクを使用します。オーケストレーターはそれらを並行して呼び出し、独立した結果セットを収集し、すべてに対して要件を適用します。どのエージェントも他のエージェントについて知る必要はない。
これにより、バイヤーは以下が可能になる:
- 既存のエージェントや評価プロトコルを変更せずに新しい専門エージェントを追加します
- エージェントタイプごとに異なる信頼度閾値を適用します
- 他のエージェントの評価ロジックを変更せずに1つのベンダーを別のベンダーに置き換える
価格
評価に課金するクリエイティブガバナンスエージェントは、他の AdCP ベンダーサービスと同じベンダー価格パターンを使います。バイヤーがget_creative_features リクエストで account を提供する場合、レスポンスには pricing_option_id、vendor_cost、currency、任意で consumption の詳細（例: LLM ベースのスキャンにおける tokens）が含まれます。
バイヤーは、課金の照合のために standards_id と pricing_option_id を伴う report_usage で利用をレポートします。これは クリエイティブエージェント、シグナルエージェント、コンテンツ標準が使うのと同じ「発見・実行・レポート」ループです。
課金するガバナンスエージェントは Accounts プロトコル を実装しなければなりません（MUST）。
非同期評価
評価に時間がかかる場合（例: マルウェアスキャンのためのサンドボックス実行）、エージェントはstatus: "working" を返し、標準の Webhook メカニズムで結果を配信します。カスタムステータス値や Webhook イベントは不要 — 既存の非同期タスクパターンがこれを処理します。