Skip to main content
アカウントプロトコルは、すべての AdCP ベンダープロトコルの基盤となる商取引レイヤーを定義します。メディアバイ、データシグナル、コンテンツ標準チェックなど、あらゆる取引は商取引関係を持つ当事者間で行われます。アカウントプロトコルはその関係を確立し、ベンダーがサービスの利用状況を追跡できるよう消費報告を提供します。

商取引モデル

すべての AdCP 取引には6つの根本的な問いがあります。
問い回答主体仕組み
広告主は誰か?ブランドレジストリbrand.domainbrand.json に解決される
ブランドの代理で誰が動くか?ブランドレジストリbrand.jsonauthorized_operators がブランド代理購入者を宣言
オペレーターはどう認証するか?セラーケイパビリティrequire_operator_auth がアカウントモデルを決定: true = 明示的アカウント(オペレーター資格情報必須、list_accounts 経由で探索)、false = 暗黙的アカウント(エージェント信頼、sync_accounts 経由で宣言)
誰が請求を受けるか?バイヤー宣言バイヤーが sync_accountsbilling を渡す — operator または agent。セラーが承認または拒否。
何が消費されたか?利用報告report_usage がベンダーエージェントに配信後のサービス利用状況を通知
セラーは get_adcp_capabilitiesrequire_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 でサンドボックスを宣言します。詳細は アカウント参照 を参照してください。

トランザクションライフサイクル

1. セラーケイパビリティを探索
   get_adcp_capabilities → require_operator_auth, supported_billing

2. ブランドアイデンティティを解決
   brand.domain/.well-known/brand.json を取得 → 正規ブランド (domain, brand_id)

3. オペレーターアイデンティティを検証
   brand.json の authorized_operators を確認 → このブランドのオペレーターが許可されているか確認

4. 認証(必要な場合)
   require_operator_auth が true の場合 → authorization_endpoint またはアウトオブバンドでオペレーター資格情報を取得

5. アカウント参照を確立
   明示的 (require_operator_auth: true):
     list_accounts() → このブランド/オペレーターの既存 account_id を検索
   暗黙的 (require_operator_auth: false):
     sync_accounts({ accounts: [{ brand, operator, billing }] }) → status, billing terms

6. 実行
   プロトコルタスクがアカウント参照を使用して正しいレートと条件を適用
   例: get_products(account: {...}), create_media_buy(account: {...})

7. 利用を報告
   report_usage(usage: [{ account: {...}, operator_id, kind, vendor_cost, ... }])
   配信後にベンダーエージェントへサービス消費状況を通知

プリンシパル

アカウントプロトコルは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 を取得して以下を検証できます。
  • ブランドアイデンティティ: このブランドは主張通りか?
  • オペレーター認可: リクエストのオペレーターはこのブランドの代理購入が許可されているか?
  • ブランド階層: このハウスポートフォリオにはどのサブブランドが含まれるか?
この検証は公開アクセス可能な DNS ホスト型アイデンティティに基づきます — バイヤーエージェントが主張する内容ではなく、ブランド自身が宣言した内容によります。 pending_approval アカウント状態では人間によるレビューが行われます: 与信審査、法的合意、本人確認。これらのステップが必要なベンダーエージェントは人間がプロセスを完了するための setup.url を返します。アカウントがアクティブになる前に完了が必要です。

ブランドレジストリとコントリビュートバックパターン

AgenticAdvertising.org ブランドレジストリ は、独自の brand.json を公開していないブランドに対してコミュニティが維持するブランドアイデンティティレイヤーを提供します。アカウント設定前にブランドを解決するバイヤーエージェントは、通常のワークフローの副産物としてレジストリにデータをコントリビュートできます — 追加作業なしにエコシステムのアイデンティティカバレッジを向上させます。 バイヤーエージェントに推奨されるパターンは3つのビルディングブロックを使用します(#1166 参照)。
ツール目的
resolve_brandレジストリを確認し brand.json を取得 — 利用可能な場合は正規アイデンティティを返す
research_brandBrandfetch 経由でエンリッチし enriched としてレジストリに自動保存
save_brandブランドを community としてレジストリに手動コントリビュート
async function ensureBrand(domain) {
  // 1. レジストリを確認(brand.json または以前に解決済み)
  const resolved = await resolveBrand(domain);

  if (resolved.errors) {
    // 解決失敗 — ブランド不明、エンリッチへ進む
  } else if (resolved.source === 'brand_json' || resolved.source === 'enriched') {
    // 権威ある、またはエンリッチされたデータが利用可能 — ユーザーに確認してから使用
    return await confirmWithUser(resolved);
  }
  // source === 'community': レジストリにプレースホルダーあり、より豊富なデータのためエンリッチ

  // 2. Brandfetch 経由でエンリッチ — 'enriched' としてレジストリに自動保存
  const enriched = await researchBrand(domain);
  if (enriched.errors) {
    // エンリッチメント利用不可 — コミュニティエントリにフォールバック、またはユーザーに修正を促す
    return resolved ? await confirmWithUser(resolved) : null;
  }

  // 3. エンリッチデータを使用する前にユーザーに確認
  // エンリッチメントはサードパーティ — ユーザー確認でエラーを検知し、レジストリの品質を向上
  return await confirmWithUser(enriched);
}
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 はバイヤー報告です: オーケストレーターが消費を計算して報告します。各レコードは独自の accountoperator_idkind"signal""content_standards""creative")を持ちます。ベンダーエージェントは報告された pricing_option_id を使用して正しいレートが適用されたことを検証します。 部分的な受け入れは有効です — 単一のリクエストが複数のアカウント、オペレーター、キャンペーンにまたがることができます。レスポンスは受け入れられたレコード数と(もしあれば)失敗したレコードを確認します。