商取引モデル
すべての AdCP 取引には6つの根本的な問いがあります。| 問い | 回答主体 | 仕組み |
|---|---|---|
| 広告主は誰か? | ブランドレジストリ | brand.domain が brand.json に解決される |
| ブランドの代理で誰が動くか? | ブランドレジストリ | brand.json の authorized_operators がブランド代理購入者を宣言 |
| オペレーターはどう認証するか? | セラーケイパビリティ | require_operator_auth がアカウントモデルを決定: true = 明示的アカウント(オペレーター資格情報必須、list_accounts 経由で探索)、false = 暗黙的アカウント(エージェント信頼、sync_accounts 経由で宣言) |
| 誰が請求を受けるか? | バイヤー宣言 | バイヤーが sync_accounts で billing を渡す — operator または agent。セラーが承認または拒否。 |
| 何が消費されたか? | 利用報告 | report_usage がベンダーエージェントに配信後のサービス利用状況を通知 |
get_adcp_capabilities の require_operator_auth でアカウントモデルを宣言します。true(明示的アカウント)の場合、オペレーターは独立して認証し、バイヤーは list_accounts でアカウントを探索します。false(暗黙的アカウント)の場合、エージェントは信頼され、バイヤーは sync_accounts でブランド/オペレーターのペアを宣言してアカウントをプロビジョニングします。
広告ネットワークは両方のモデルを同時に利用できます — バイヤー向けには暗黙的アカウント(ネットワークはエージェント信頼)、各基盤プラットフォームとは明示的アカウント(ネットワークはオペレーターとして認証)。完全なアカウントチェーン(バイヤーエージェント → ネットワーク(暗黙)→ AI プラットフォーム(明示))については Sponsored Intelligence ガイド — ネットワークのアカウントモデル を参照してください。
配信後、オーケストレーターは report_usage を呼び出し、ベンダーエージェント(シグナル、ガバナンス、クリエイティブ)にサービスの消費状況を通知します。これは精算ではなく、ベンダーが獲得収益を追跡し請求を検証するための消費報告です。
スコープ
アカウントプロトコルはすべてのベンダープロトコルに適用されます。オーケストレーターはブランド/オペレーターのペアごとにベンダーエージェントとのアカウントを一度確立し、そのエージェントとのすべてのやり取りで同じアカウント参照を再利用します。| ベンダープロトコル | アカウント参照の用途 |
|---|---|
| メディアバイ | レートカード、請求書、キャンペーン帰属 |
| シグナル | アカウント別料金オプション、アクティベーション、利用報告 |
| ガバナンス | コンテンツ標準の請求 |
| クリエイティブ | クリエイティブサービスの請求 |
account_id(明示的アカウント、require_operator_auth: true)または自然キー — brand + operator(暗黙的アカウント、require_operator_auth: false)のいずれかになります。サンドボックスの場合、経路はアカウントモデルに依存します: 明示的アカウントは list_accounts で既存のテストアカウントを探索し、暗黙的アカウントは sandbox: true を付けた sync_accounts でサンドボックスを宣言します。詳細は アカウント参照 を参照してください。
トランザクションライフサイクル
プリンシパル
アカウントプロトコルは4種類のプリンシパルで動作します。請求階層、信頼モデル、認可オペレーターの詳細は アカウントとエージェント を参照してください。| プリンシパル | 役割 | 識別子 |
|---|---|---|
| ブランド | 誰の製品を広告するか | brand.domain + brand.json 経由のオプション brand.brand_id |
| オペレーター | 誰が購入を行うか | ドメイン (例: pinnacle-media.com) |
| エージェント | どのソフトウェアが購入するか | 認証済みセッション |
| ベンダーエージェント | セラーの AdCP エージェント | agent_url |
タスク
| タスク | 目的 |
|---|---|
sync_accounts | ブランド/オペレーターのペアと請求を宣言してアカウントをプロビジョニング(暗黙的アカウント、require_operator_auth: false) |
list_accounts | 既存アカウントを探索(明示的アカウント、require_operator_auth: true); 保留中アカウントのステータスをポーリング |
get_account_financials | オペレーター請求アカウントの支出、クレジット、請求書ステータスを照会 |
report_usage | 配信後にベンダーエージェントへサービス消費状況を通知 |
ブランドレジストリとの接続
アカウント参照のbrand.domain は任意の識別子ではありません — ブランドのドメインであり、ブランドの正規アイデンティティ、サブブランド、認可オペレーター、プロパティを宣言する brand.json ファイルに解決可能です。
ベンダーエージェントはブランドレジストリに対してバイヤーの主張を検証できます: オーケストレーターが acme-corp.com を代表すると主張した場合、ベンダーは acme-corp.com/.well-known/brand.json を取得して認可オペレーターとブランド階層を確認できます。これによりアカウントプロトコルは改ざん耐性を持ちます — アカウント関係は公開検証可能なブランドアイデンティティに基づきます。
ブランドアイデンティティの解決方法については ブランドプロトコル を参照してください。
取引相手の検証
広告のすべての商取引関係は、実際に取引している相手が誰であるかを知ることに依存します。アカウントプロトコルはブランドレジストリを通じてプロトコルレベルでこれに対応します。 オーケストレーターがアカウントを参照する際、brand.domain が広告主を識別します。ベンダーエージェントは brand.domain/.well-known/brand.json を取得して以下を検証できます。
- ブランドアイデンティティ: このブランドは主張通りか?
- オペレーター認可: リクエストのオペレーターはこのブランドの代理購入が許可されているか?
- ブランド階層: このハウスポートフォリオにはどのサブブランドが含まれるか?
pending_approval アカウント状態では人間によるレビューが行われます: 与信審査、法的合意、本人確認。これらのステップが必要なベンダーエージェントは人間がプロセスを完了するための setup.url を返します。アカウントがアクティブになる前に完了が必要です。
ブランドレジストリとコントリビュートバックパターン
AgenticAdvertising.org ブランドレジストリ は、独自のbrand.json を公開していないブランドに対してコミュニティが維持するブランドアイデンティティレイヤーを提供します。アカウント設定前にブランドを解決するバイヤーエージェントは、通常のワークフローの副産物としてレジストリにデータをコントリビュートできます — 追加作業なしにエコシステムのアイデンティティカバレッジを向上させます。
バイヤーエージェントに推奨されるパターンは3つのビルディングブロックを使用します(#1166 参照)。
| ツール | 目的 |
|---|---|
resolve_brand | レジストリを確認し brand.json を取得 — 利用可能な場合は正規アイデンティティを返す |
research_brand | Brandfetch 経由でエンリッチし enriched としてレジストリに自動保存 |
save_brand | ブランドを community としてレジストリに手動コントリビュート |
confirmWithUser はUXに合った確認メカニズムのプレースホルダーです — 明示的なプロンプト、ワークフローUIのレビューステップ、または人間のレビューをトリガーする低信頼フラグ。確認ステップが改善ループを機能させます: エンリッチメントデータはサードパーティから来るため正確さは保証されません。本番キャンペーンで使用される前のユーザー検証がレジストリの精度を保ちます。
ソース権威
レジストリはブランドデータがどこから来たかを追跡します。権威の降順でソースを示します。| ソース | 意味 | 上書き可能? |
|---|---|---|
brand_json | ブランドが /.well-known/brand.json 経由で自己宣言 | 不可 — 409 を返す |
enriched | サードパーティエンリッチメント(Brandfetch) | より高い権威のみ |
community | レジストリメンバーが手動コントリビュート | 可 |
save_brand または research_brand を呼び出すと、レジストリはマージロジックを適用します: より高い権威ソースの既存フィールドは保持され、欠落フィールドのみが補完されます。ブランドが宣言した内容を尊重しながらギャップを埋めます。
research_brand は最近の enriched データがドメインのレジストリに既に存在する場合、再エンリッチをスキップして冗長な API 呼び出しを避けます。
ブランドの完全な編集履歴(誰が、いつ、どのような概要でコントリビュートしたか)は GET /api/brands/history で照会できます。
プロパティコントリビュートバック
同じパターンがパブリッシャープロパティにも適用されます。バイヤーエージェントがセールスエージェントとのやり取りを通じて新しいパブリッシャーを発見した場合、POST /api/properties/save 経由でそのプロパティをレジストリにコントリビュートできます。これはブランドコントリビュートバックがブランドカバレッジを向上させるのと同様に、プロパティカバレッジを向上させます。詳細は レジストリ API — プロパティを保存 を参照してください。
利用報告
ベンダーエージェント(シグナル、ガバナンス、クリエイティブ)はキャンペーン実行の直接参加者ではなく、オーケストレーターがメディアバイへの入力としてサービスを使用します。配信後、report_usage はこれらのベンダーに消費状況を伝え、獲得収益を追跡し請求を検証できるようにします。
report_usage はバイヤー報告です: オーケストレーターが消費を計算して報告します。各レコードは独自の account、operator_id、kind("signal"、"content_standards"、"creative")を持ちます。ベンダーエージェントは報告された pricing_option_id を使用して正しいレートが適用されたことを検証します。
部分的な受け入れは有効です — 単一のリクエストが複数のアカウント、オペレーター、キャンペーンにまたがることができます。レスポンスは受け入れられたレコード数と(もしあれば)失敗したレコードを確認します。