> ## 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.
# アカウントプロトコル
> AdCP アカウントプロトコルは広告取引の商取引レイヤーを定義します — 請求、オペレーター認可、バイヤー・ブランド・ベンダーエージェント間の利用報告。
アカウントプロトコルは、すべての AdCP ベンダープロトコルの基盤となる商取引レイヤーを定義します。メディアバイ、データシグナル、コンテンツ標準チェックなど、あらゆる取引は商取引関係を持つ当事者間で行われます。アカウントプロトコルはその関係を確立し、ベンダーがサービスの利用状況を追跡できるよう消費報告を提供します。
## 商取引モデル
すべての AdCP 取引には7つの根本的な問いがあります。
| 問い | 回答主体 | 仕組み |
| ---------------- | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 広告主は誰か？ | ブランドレジストリ | `brand.domain` が `brand.json` に解決される |
| ブランドの代理で誰が動くか？ | ブランドレジストリ | `brand.json` の `authorized_operators` がブランド代理購入者を宣言 |
| オペレーターはどう認証するか？ | セラーケイパビリティ | `require_operator_auth` が誰が認証しなければならないか、どのアカウント参照形状が期待されるかを決定。 |
| このアカウントで何をしてよいか？ | 呼び出し元スコープ | [`sync_accounts`](/docs/accounts/tasks/sync_accounts) と [`list_accounts`](/docs/accounts/tasks/list_accounts) のレスポンスの各アカウントごとエントリの `authorization` オブジェクトが、呼び出しエージェントの `allowed_tasks`、`field_scopes`、`scope_name`、`read_only` を記述。下記の [Caller authorization](#caller-authorization) を参照。 |
| 誰が請求を受けるか？ | バイヤー宣言 | バイヤーが `sync_accounts` で `billing` を渡す — `operator`、`agent`、`advertiser`。セラーが承認または拒否。 |
| 何が消費されたか？ | 利用報告 | `report_usage` がベンダーエージェントに配信後のサービス利用状況を通知 |
セラーは [`get_adcp_capabilities`](/docs/protocol/get_adcp_capabilities) の `require_operator_auth` でアカウントモデルを宣言します。そのフィールドは誰が認証しなければならないかを宣言します。それ自体は OAuth が使われるか、`list_accounts` が公開されるか、どの `sync_accounts` モードがサポートされるかを宣言しません。
`require_operator_auth` が `true`（**アカウント ID 名前空間**）の場合、オペレーターは独立して認証し、セラーまたは上流プラットフォームが正準のアカウント名前空間を所有するため、バイヤーはセラー割り当ての `account_id` 値を渡します。クレデンシャルが複数のアカウントにアクセスし得る場合、セラーは [`list_accounts`](/docs/accounts/tasks/list_accounts) を公開しなければならず（MUST）、バイヤーは最初のアカウントスコープリクエストの前に明示的な `account_id` を解決しなければなりません（MUST）。クレデンシャルが正確に 1 つのアカウントに束縛される場合、セラーはそのシングルトンを返す `list_accounts` を公開すべきで（SHOULD）、同じ明示的な `account_id` が別の宣言されたパスまたはアウトオブバンドのオンボーディングを通じて供給される場合のみ省略してもよい（MAY）。
`require_operator_auth` が `false`（**バイヤー宣言アカウント**）の場合、エージェントは信頼され、バイヤーは [`sync_accounts`](/docs/accounts/tasks/sync_accounts) でブランド/オペレーターのペアを宣言してアカウントをプロビジョニングします。
**広告ネットワーク**は両方のモデルを同時に利用できます — バイヤー向けにはバイヤー宣言アカウント（ネットワークはエージェント信頼）、各基盤プラットフォームとはアカウント ID 名前空間（ネットワークはオペレーターとして認証）。完全なアカウントチェーン（`バイヤーエージェント → ネットワーク（バイヤー宣言）→ AI プラットフォーム（アカウント ID 名前空間）`）については [Sponsored Intelligence ガイド — ネットワークのアカウントモデル](/docs/sponsored-intelligence/networks#account-model-for-networks) を参照してください。
配信後、オーケストレーターは [`report_usage`](/docs/accounts/tasks/report_usage) を呼び出し、ベンダーエージェント（シグナル、ガバナンス、クリエイティブ）にサービスの消費状況を通知します。これは精算ではなく、ベンダーが獲得収益を追跡し請求を検証するための消費報告です。
## スコープ
アカウントプロトコルはすべてのベンダープロトコルに適用されます。オーケストレーターはブランド/オペレーターのペアごとにベンダーエージェントとのアカウントを一度確立し、そのエージェントとのすべてのやり取りで同じアカウント参照を再利用します。
| ベンダープロトコル | アカウント参照の用途 |
| --------- | ---------------------------- |
| メディアバイ | レートカード、請求書、キャンペーン帰属 |
| シグナル | アカウント別料金オプション、アクティベーション、利用報告 |
| ガバナンス | コンテンツ標準の請求 |
| クリエイティブ | クリエイティブサービスの請求 |
アカウント参照はセラーが割り当てた `account_id`（セラー所有の名前空間、通常 `require_operator_auth: true`）または自然キー — `brand` + `operator`（バイヤー宣言アカウント、`require_operator_auth: false`）のいずれかになります。バイヤー宣言アカウントでは、セラーが内部 `account_id` もエコーしても、自然キーの `AccountRef` は後続の呼び出しで有効なままでなければなりません（MUST）。サンドボックスの場合、アカウント ID 名前空間は `list_accounts` で探索するかアウトオブバンドで供給される既存のテストアカウントを使い、バイヤー宣言アカウントは `sandbox: true` を付けた `sync_accounts` でサンドボックスを宣言します。詳細は [アカウント参照](/docs/building/by-layer/L2/accounts-and-agents#account-references) を参照してください。
## アカウントステータスライフサイクル
アカウントは定義された状態のセットを進みます。終端状態（`rejected`、`closed`）はそれ以上の遷移を許しません。
```
sync_accounts ──▶ pending_approval ──▶ active
│ │
│ (seller declines) ├── (credit limit / funds depleted)
▼ │ ▼
rejected (terminal) │ payment_required
│ │ (buyer resolves billing)
│ ▼
│ active
│
├── (seller suspends) ──▶ suspended
│ │
│ (seller reactivates) ◀─┤
│ │
│ └──▶ closed (terminal)
│
└── (seller or buyer closes) ──▶ closed (terminal)
```
**遷移ルール:**
* `pending_approval` → `active`: セラーが与信/契約/アイデンティティレビュー後に承認
* `pending_approval` → `rejected`: セラーが拒否。終端 — バイヤーは新しいアカウントリクエストを提出しなければならない。
* `active` → `payment_required`: 与信限度に達したか資金が枯渇したとき自動
* `payment_required` → `active`: バイヤーが未払い残高を解決したとき。セラーは自動遷移してもよい（MAY）し、手動再アクティベーションを要求してもよい（MAY）。
* `active` → `suspended`: セラー起因（ポリシー違反、請求紛争、不正レビュー）。セラーは Webhook でオーケストレーターに通知しなければならない（MUST）。
* `suspended` → `active`: セラー起因の再アクティベーション
* `suspended` → `closed`: セラー起因の恒久クローズ
* `active` → `closed`: セラーまたはバイヤー起因の恒久クローズ。終端。
* セラーは終端状態のアカウントへのオペレーションを `ACCOUNT_NOT_FOUND` または適切なエラーで拒否しなければならない（MUST）
### アカウントステータス別のオペレーション
アカウントステータスは、どのタスクが許可されるかのゲートとして機能します。読み取り専用オペレーションは常に利用可能。変更オペレーションはステータスに基づいて制限されます。
| Task | `active` | `pending_approval` | `payment_required` | `suspended` | `rejected` / `closed` |
| ------------------------ | -------- | ------------------ | ------------------ | ----------- | --------------------- |
| `list_accounts` | Yes | Yes | Yes | Yes | Yes |
| `get_account_financials` | Yes | Yes | Yes | Yes | No |
| `get_products` | Yes | No | Yes | No | No |
| `create_media_buy` | Yes | No | No | No | No |
| `update_media_buy` | Yes | No | Yes | No | No |
| `get_media_buys` | Yes | No | Yes | Yes | No |
| `sync_creatives` | Yes | No | Yes | No | No |
| `sync_catalogs` | Yes | No | Yes | No | No |
| `sync_event_sources` | Yes | No | Yes | No | No |
| `report_usage` | Yes | No | Yes | Yes | No |
* `payment_required` は新規支出（`create_media_buy`）をブロックするが、既存バイの管理とセットアップの解決を許可。パッケージ追加は機能的に新規支出と同等なので、セラーはアカウントが `payment_required` のとき `update_media_buy` 内の `new_packages` も拒否すべき（SHOULD）。
* `suspended` は既存データへの読み取り専用アクセスを許可するが、すべての変更をブロック
* セラーは、停止アカウントのブロックされたオペレーションには `ACCOUNT_SUSPENDED` を、payment-required アカウントのブロックされたオペレーションには `ACCOUNT_PAYMENT_REQUIRED` を返さなければならない（MUST）
## Caller authorization
アカウントにアクセスできるすべての呼び出し元が同じ付与を持つわけではありません。ベンダーエージェントは、ある呼び出しエージェントに完全なスコープを、別のエージェントに狭い読み取り+更新スコープを発行できます。認証は呼び出し元が主張どおりの者であることを確認します。認可は「この呼び出し元はこのアカウントで何をしてよいか？」に答えます。
**すべてのベンダープロトコルに適用。** ここで説明する認可メカニズムは共有 Accounts Protocol の一部です — `sync_accounts` / `list_accounts` を実装するすべてのエージェント（media-buy sales agent、signals agent、governance agent、creative agent、brand agent）に適用されます。signals エージェントはアクティベーション vs カタログアクセスをスコープし、governance エージェントは監査読み取り vs プラン管理をスコープし、creative エージェントはライブラリ読み取り vs アップロードをスコープします。標準の名前付きスコープ `attestation_verifier` のみが Media Buy Protocol 固有です（**AAO Verified (Live)** 修飾子にバインド）。残りの仕組み — `allowed_tasks`、`field_scopes`、`read_only`、`custom:` プレフィックスのスコープ — はプロトコル中立です。
**スキーマ**: [`/schemas/v3/core/account-authorization.json`](https://adcontextprotocol.org/schemas/v3/core/account-authorization.json)
スコープイントロスペクションをサポートするベンダーエージェントは、[`sync_accounts`](/docs/accounts/tasks/sync_accounts) と [`list_accounts`](/docs/accounts/tasks/list_accounts) のレスポンスの各アカウントごとエントリに `authorization` オブジェクトを付加します:
```json theme={null}
{
"account_id": "acc_acme_compliance",
"name": "Acme c/o AAO Compliance",
"status": "active",
"billing": "operator",
"authorization": {
"allowed_tasks": [
"get_adcp_capabilities",
"get_products",
"get_media_buys",
"get_media_buy_delivery",
"list_creatives",
"update_media_buy"
],
"field_scopes": {
"update_media_buy": ["reporting_webhook"]
},
"scope_name": "attestation_verifier",
"read_only": false
}
}
```
### フィールド
| Field | Description |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `allowed_tasks` | 呼び出し元がこのアカウントに対して呼び出してよい正準の snake\_case タスク名。タスクの不在は「不許可」と読まなければならない（MUST）— 不在のタスクを呼び出すと `SCOPE_INSUFFICIENT` を返す。 |
| `field_scopes` | 呼び出し元が設定してよいリクエストフィールドのタスクごとのオプション許可リスト。キーはタスク名、値はフィールドパス。タスクがここに現れるとき、許可リスト外の任意のフィールドは `FIELD_NOT_PERMITTED` を返す。暗黙的なフレーミングフィールド — 型付きエンティティ参照（`account`、`media_buy_id`、`package_id`、`creative_id`、`signal_id`、`format_id`、`proposal_id`、`plan_id`、`session_id`）、並行性/冪等性（`revision`、`idempotency_key`）、バイヤー側相関（`buyer_ref`、`po_number`）、モードフラグ（`dry_run`）、ページネーション（`pagination`、`cursor`、`max_results`）、エンベロープフィールド（`context`、`ext`、`adcp_major_version`、`push_notification_config`）— は常に許可され、許可リストに現れる必要はない。リストは非網羅的: 読み取りタスクの他の任意の型付きエンティティ ID パラメーターやクエリ形成フィールドはフレーミングとして扱うべき（SHOULD）。 |
| `scope_name` | オプションの名前付きスコープ識別子。`attestation_verifier` のみが標準化（media-buy 固有、**AAO Verified (Live)** 修飾子にバインド）。エージェント定義の名前は `custom:` プレフィックスを使わなければならず（MUST）、標準値のタイポがスルーせずスキーマ検証に失敗するように。 |
| `read_only` | 便宜フラグ。true のとき、タスクが `allowed_tasks` にあるかに関わらず変更は `READ_ONLY_SCOPE` を返す。省略は `false` と等価。呼び出し元は `allowed_tasks` だけから read-only を推論してはならない（MUST NOT）。 |
### 存在と不在のセマンティクス
* **存在**: ベンダーエージェントは、形状がこの瞬間のこのアカウントに対するこの呼び出し元への強制を反映すると表明します。数秒古いのは問題ないが、体系的に発散するのは非コンフォーマント。
* **単一アカウントで不在**: ベンダーエージェントはそのアカウントについて呼び出し元にスコープを伝えていません。呼び出し元はエラー駆動ディスカバリー（タスクを試し、RBAC エラーコードを処理）にフォールバックします。
* **すべてのアカウントで不在**: ベンダーエージェントはスコープイントロスペクションを実装していません。呼び出し元は不在からアクセスを推論してはならない（MUST NOT）— ベンダーエージェントは依然ローカルでスコープを強制し、任意のタスク呼び出しで `SCOPE_INSUFFICIENT` / `READ_ONLY_SCOPE` / `FIELD_NOT_PERMITTED` を返し得ます。
* **`authorization` は 3.x でオプション**。破壊的変更を避けたいベンダーエージェントは設定を延期できます。設定は厳密に追加的です — 呼び出し元が試行で発見するはずのエラーを先取りできるようにします。
`attestation_verifier` 標準スコープ（Media Buy Protocol 固有）を主張するベンダーエージェントは `authorization` を設定しなければなりません（**MUST**）— **AAO Verified (Live)** 証明フローは、宣伝されたスコープが強制に一致することの検証に依存します。
### アイデンティティバインディング、リフレッシュケイデンス、一貫性
`authorization` オブジェクトは読み取り時に **`(呼び出し元アイデンティティ, account_id)` タプルに暗黙的にスコープ**されます。異なる認証済み呼び出し元に返される同じアカウントは異なる `authorization` オブジェクトを返してもよい（MAY）— それが RBAC モデルの要点です。ベンダーエージェントは呼び出し元アイデンティティを認証済みリクエストから解決しなければならず（MUST、クライアント供給フィールドからではない）、返す `authorization` をその解決されたアイデンティティにバインドしなければなりません（MUST）。
**リフレッシュケイデンス。**
* 呼び出し元は、アカウントに対する能動的使用の少なくとも **300 秒**ごとに、`sync_accounts` または `list_accounts`（保持する `account` でフィルタ）を介して `authorization` を再読み取りすべき（SHOULD）。
* ベンダーエージェントは、オペレーター起因のスコープ変更を、変更がなされてから **300 秒以内**に `sync_accounts` / `list_accounts` レスポンスに反映しなければならない（MUST）。300 秒ごとにポーリングするコンフォーマントな呼び出し元は、最大 1 リフレッシュサイクル以内にオペレーター変更を見ます。
* ベンダーエージェントは `authorization` オブジェクトを短期間キャッシュしてもよい（MAY）が、再検証なしに 300 秒を超えてキャッシュしてはならない（MUST NOT）。
* 300 秒の数字はターゲットではなくフロアです — スコープがより頻繁に変わるベンダーエージェントはより速く表面化すべきで（SHOULD）、**AAO Verified (Live)** 証明を実行する呼び出し元は check-7 ケイデンス（ローリングウィンドウごとに少なくとも 1 回、加えて観測されたすべてのスコープ変更時）で探るべき（SHOULD）。
**一貫性。**
ある `(呼び出し元アイデンティティ, account_id)` タプルについて、リフレッシュウィンドウ内の逐次読み取りは、オペレーター起因のスコープ変更を除き、同一の `authorization` オブジェクトを返さなければならない（MUST）。ロードバランスされたまたは結果整合性のバックエンドからのちらつき — 異なるレプリカにヒットして 10 秒離れた 2 つの読み取りが異なる `allowed_tasks` を返す — は非コンフォーマント。コンプライアンスエンジンとコーディングエージェントは状態追跡にスコープの安定性に依存します。それを保証できないベンダーエージェントは、一貫性なく設定するのではなく `authorization` を省略しなければなりません（MUST）。
これは上記の存在セマンティクスの「体系的に発散するのは非コンフォーマント」保証の具体形です — 検証可能です: コンフォーマンスチェックはリフレッシュウィンドウ内で同じアイデンティティから同じアカウントを 2 回読み、結果を diff できます。
### リフレッシュウィンドウ内での SCOPE\_INSUFFICIENT へのバイヤー応答
単一の `SCOPE_INSUFFICIENT` レスポンスは、2 つの原因間で観測的に区別不能です: 有効な付与をまだ伝播していないセラーレプリカ（一時的インフラアーティファクト — 解決する）と、オペレーターによる正当なスコープ削減（永続的 — 表面化しなければならない）。エラーをオペレーター介入が必要な確定的な `correctable` シグナルとして分類する前に、バイヤーは 2 つを区別するため小さな制限されたリトライバジェットを使い果たしてもよい（MAY）:
* **リトライバジェット:** 3 回以下、各回 1〜5 秒のジッター付きバックオフで分離。これは曖昧性解消ロジック — `correctable` 分類を信頼する前にスコープが本当に不十分かを確立 — であり、correctable エラーの復旧アクションではありません。
* **300 秒ウィンドウではない:** リトライバジェットはセラーの伝播 SLA ではありません。バイヤーはすべての偽陰性で 300 秒ウィンドウ全体を待つべきではありません（SHOULD NOT）。累積 15 秒までのバックオフ遅延が典型的なレプリカラグを吸収するのに十分です。
* **リトライ尽きた後:** バイヤーはエラーを表面化しなければなりません（MUST）。「表面化」とは: 呼び出し層に構造化エラー（アカウント ID、失敗したタスク、試行回数を持つ `error.details.retry_count` を含む）を返す AND 失敗をオペレーターがアクセス可能なチャネル — 構造化ログ、ダッシュボードアラート、通知 — で可視にすることを意味します。エスカレーションメカニズムは実装依存。要件はエラーが黙って飲み込まれないことです。
`READ_ONLY_SCOPE` は、バイヤーが付与伝播ラグ（書き込み付与更新に遅れているレプリカ）を疑うとき、同じ制限リトライロジックに従います。注意: 書き込みアクセスが最近*失効*した場合、古いレプリカは、失効したスコープが拒否すべきだった変更を受け入れるかもしれません。制限リトライが成功した場合、バイヤーは結果を信頼できるとして扱う前に `authorization` を再読み取りしなければならず（MUST）、再読み取りで書き込みアクセスが失効したことが確認された場合、バイヤーは変更を潜在的に未認可としてフラグするアラートをオペレーターに表面化しなければならず（MUST）、正しいものとして黙って受け入れてはなりません（MUST NOT）。
`FIELD_NOT_PERMITTED` はこのパターンに従いません。エージェント自律の復旧パス — 許可されないフィールドを削除して再送 — がリトライの考慮に優先します。バイヤーは `FIELD_NOT_PERMITTED` について同一の失敗リクエストをリトライしてはならず（MUST NOT）、即座に修正して再送すべき（SHOULD）。
これらのコードの規範的なリトライ例外条項は [Authorization (RBAC)](/docs/building/by-layer/L3/error-handling#authorization-rbac) を参照。
### 標準の名前付きスコープ: `attestation_verifier`
**AAO Verified (Live)** 準備（[#2965](https://github.com/adcontextprotocol/adcp/issues/2965) で追跡）を宣伝する media-buy sales agent は、次の最小形状で `scope_name: "attestation_verifier"` で識別される名前付きスコープをサポートしなければなりません（MUST）:
* `allowed_tasks`（最小限 — ベンダーエージェントは追加の読み取り専用タスクを含めてもよい）:
* `get_adcp_capabilities`
* `get_products`
* `get_media_buys`
* `get_media_buy_delivery`
* `list_creatives`
* `update_media_buy`
* `field_scopes.update_media_buy`: `["reporting_webhook"]`
* `read_only`: `false`
このスコープは `create_media_buy`、`sync_creatives`、`update_media_buy` のすべての支出コミットまたはターゲティング変更フィールドを意図的に省略します。継続的な可観測性検証のために狭く設計されています — コンプライアンスエンジンはライブキャンペーンを発見し、インベントリとクリエイティブの状態を読み、検証レポート Webhook を接続し、デリバリーを読めますが、インベントリを予約したり、予算を変更したり、フライト日を変えたり、クリエイティブをアップロードしたり、何かをキャンセルしたりはできません。
`get_products` と `list_creatives` が含まれるのは、**AAO Verified (Live)** の可観測性が、セラーの宣言されたインベントリとアクティブなバイのクリエイティブパイプライン状態のサニティ読み取りを必要とするためです。
`attestation_verifier` は Media Buy Protocol 固有です — **AAO Verified (Live)** 修飾子にバインドし、それはメディアバイフロー（ライブ観測は実際の広告配信を必要とする）です。signals、governance、creative、brand エージェント向けの同等の可観測性スコープはまだ標準化されていません。標準化されるまで、それらのエージェントは `custom:` スコープを使います。
**レポートのみ — ライフサイクル実行は将来のスコープ。** `attestation_verifier` は (Live) の*レポート*半分です: エンジンはセラーがトラフィックしたキャンペーンを観測し、デリバリーを読み、検証 Webhook を接続します。意図的にキャンペーンを作成したり、クリエイティブを接続したり、予算を変更したりはできません。補完的な*ライフサイクル実行*の役割 — エンジンが正準の PSA をセラーのライブエージェントを通じてエンドツーエンドでトラフィックする、[#3046](https://github.com/adcontextprotocol/adcp/issues/3046) で検討される AAO 運用の正準キャンペーンランナー向け — はより広い書き込みスコープ（`attestation_runner`、[#3561](https://github.com/adcontextprotocol/adcp/issues/3561) で追跡）を必要とします。今日のブラウンフィールド登録（Path B）は `attestation_verifier` のみを必要とします。ランナー側のスコープは正準キャンペーンランナー自体とともに点灯します。
### 他のベンダープロトコル向けのカスタムスコープ
任意のベンダーエージェントは `custom:` プレフィックスを使ってカスタムスコープを定義してもよい（MAY）。バイヤーは custom-prefixed スコープ名からいかなるセマンティクスも仮定してはなりません（MUST NOT）— 名前はエージェント定義で、帯域外（ドキュメント、オンボーディング）で学ばれます。
例示的な例（標準化されていない — 各エージェントが独自に命名）:
* **Signals agent**: `custom:activation_only` — `allowed_tasks: [get_signals, activate_signal, get_adcp_capabilities]`、カタログ管理なし、クロスアカウントメタデータなし。
* **Governance agent**: `custom:audit_viewer` — `allowed_tasks: [get_plan_audit_logs, get_adcp_capabilities]`、`read_only: true`。ガバナンストレイルへの読み取りアクセスを付与された規制当局や外部監査人に有用。
* **Creative agent**: `custom:library_reader` — `allowed_tasks: [list_creatives, list_creative_formats]`、`read_only: true`。アップロードしないバイヤー（例: 測定パートナー）が変更せずにライブラリの中身を発見できる。
* **Brand agent（権利）**: `custom:rights_viewer` — `allowed_tasks: [get_rights, get_brand_identity]`、`read_only: true`。クリアランス権限なしのディスカバリー。
上記の存在/不在セマンティクス、アイデンティティバインディング、リフレッシュケイデンス、一貫性要件は、すべてのベンダープロトコルにわたって一律に適用されます — `custom:activation_only` を設定する signals エージェントは、`attestation_verifier` を設定する media-buy セラーと同じ 300 秒リフレッシュ義務を負います。
### 先行技術
イントロスペクションモデル — 「呼び出し元が認可を強制する当事者に付与が何かを尋ねる」— は、AdCP のタスク・フィールド認可モデルに特化した [RFC 7662 OAuth 2.0 Token Introspection](https://www.rfc-editor.org/rfc/rfc7662) と構造的に類似しています。レスポンスを別個のタスクに分割するのではなく sync/list に埋め込むことは、アカウントディスカバリーとスコープイントロスペクションが同じ自然な問い（「私のアカウントは何で、それで何ができるか？」）であることを反映します — 2 つは一緒に返されます。
## トランザクションライフサイクル
```
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. アカウント参照を確立
アカウント ID 名前空間 (require_operator_auth: true):
list_accounts() → このブランド/オペレーターの既存 account_id を検索（上流管理）
または 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種類のプリンシパルで動作します。請求階層、信頼モデル、認可オペレーターの詳細は [アカウントとエージェント](/docs/building/by-layer/L2/accounts-and-agents) を参照してください。
| プリンシパル | 役割 | 識別子 |
| ---------- | ---------------- | ----------------------------------------------------- |
| ブランド | 誰の製品を広告するか | `brand.domain` + brand.json 経由のオプション `brand.brand_id` |
| オペレーター | 誰が購入を行うか | ドメイン (例: `pinnacle-media.com`) |
| エージェント | どのソフトウェアが購入するか | 認証済みセッション |
| ベンダーエージェント | セラーの AdCP エージェント | `agent_url` |
## タスク
| タスク | 目的 |
| ----------------------------------------------------------------------- | -------------------------------------------------------------------------------- |
| [`sync_accounts`](/docs/accounts/tasks/sync_accounts) | ブランド/オペレーターのペアと請求を宣言してアカウントをプロビジョニング（バイヤー宣言アカウント、`require_operator_auth: false`） |
| [`list_accounts`](/docs/accounts/tasks/list_accounts) | 既存アカウントを探索（アカウント ID 名前空間、`require_operator_auth: true`）; 保留中アカウントのステータスをポーリング |
| [`sync_governance`](/docs/accounts/tasks/sync_governance) | セラー側検証のためガバナンスエージェントエンドポイントをアカウントに同期 |
| [`get_account_financials`](/docs/accounts/tasks/get_account_financials) | オペレーター請求アカウントの支出、クレジット、請求書ステータスを照会 |
| [`report_usage`](/docs/accounts/tasks/report_usage) | 配信後にベンダーエージェントへサービス消費状況を通知 |
## ブランドレジストリとの接続
アカウント参照の `brand.domain` は任意の識別子ではありません — ブランドのドメインであり、ブランドの正規アイデンティティ、サブブランド、認可オペレーター、プロパティを宣言する `brand.json` ファイルに解決可能です。
ベンダーエージェントはブランドレジストリに対してバイヤーの主張を検証できます: オーケストレーターが `acme-corp.com` を代表すると主張した場合、ベンダーは `acme-corp.com/.well-known/brand.json` を取得して認可オペレーターとブランド階層を確認できます。これによりアカウントプロトコルは改ざん耐性を持ちます — アカウント関係は公開検証可能なブランドアイデンティティに基づきます。
ブランドアイデンティティの解決方法については [ブランドプロトコル](/docs/brand-protocol/index) を参照してください。
## 取引相手の検証
広告のすべての商取引関係は、実際に取引している相手が誰であるかを知ることに依存します。アカウントプロトコルはブランドレジストリを通じてプロトコルレベルでこれに対応します。
オーケストレーターがアカウントを参照する際、`brand.domain` が広告主を識別します。ベンダーエージェントは `brand.domain/.well-known/brand.json` を取得して以下を検証できます。
* **ブランドアイデンティティ**: このブランドは主張通りか？
* **オペレーター認可**: リクエストのオペレーターはこのブランドの代理購入が許可されているか？
* **ブランド階層**: このハウスポートフォリオにはどのサブブランドが含まれるか？
この検証は公開アクセス可能な DNS ホスト型アイデンティティに基づきます — バイヤーエージェントが主張する内容ではなく、ブランド自身が宣言した内容によります。
`pending_approval` アカウント状態では人間によるレビューが行われます: 与信審査、法的合意、本人確認。これらのステップが必要なベンダーエージェントは人間がプロセスを完了するための `setup.url` を返します。アカウントがアクティブになる前に完了が必要です。
### ブランドレジストリとコントリビュートバックパターン
[AgenticAdvertising.org ブランドレジストリ](https://agenticadvertising.org) は、独自の `brand.json` を公開していないブランドに対してコミュニティが維持するブランドアイデンティティレイヤーを提供します。アカウント設定前にブランドを解決するバイヤーエージェントは、通常のワークフローの副産物としてレジストリにデータをコントリビュートできます — 追加作業なしにエコシステムのアイデンティティカバレッジを向上させます。
バイヤーエージェントに推奨されるパターンは3つのビルディングブロックを使用します（[#1166](https://github.com/adcontextprotocol/adcp/issues/1166) 参照）。
| ツール | 目的 |
| ---------------- | ------------------------------------------------ |
| `resolve_brand` | レジストリを確認し brand.json を取得 — 利用可能な場合は正規アイデンティティを返す |
| `research_brand` | Brandfetch 経由でエンリッチし `enriched` としてレジストリに自動保存 |
| `save_brand` | ブランドを `community` としてレジストリに手動コントリビュート |
```javascript theme={null}
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`](/docs/registry/index#activity-history) で照会できます。
#### プロパティコントリビュートバック
同じパターンがパブリッシャープロパティにも適用されます。バイヤーエージェントがセールスエージェントとのやり取りを通じて新しいパブリッシャーを発見した場合、`POST /api/properties/save` 経由でそのプロパティをレジストリにコントリビュートできます。これはブランドコントリビュートバックがブランドカバレッジを向上させるのと同様に、プロパティカバレッジを向上させます。詳細は [レジストリ API — プロパティを保存](/docs/registry/index#save-property) を参照してください。
## 利用報告
ベンダーエージェント（シグナル、ガバナンス、クリエイティブ）はキャンペーン実行の直接参加者ではなく、オーケストレーターがメディアバイへの入力としてサービスを使用します。配信後、`report_usage` はこれらのベンダーに消費状況を伝え、獲得収益を追跡し請求を検証できるようにします。
`report_usage` はバイヤー報告です: オーケストレーターが消費を計算して報告します。各レコードは独自の `account`、`operator_id`、`kind`（`"signal"`、`"content_standards"`、`"creative"`）を持ちます。ベンダーエージェントは報告された `pricing_option_id` を使用して正しいレートが適用されたことを検証します。
部分的な受け入れは有効です — 単一のリクエストが複数のアカウント、オペレーター、キャンペーンにまたがることができます。レスポンスは受け入れられたレコード数と（もしあれば）失敗したレコードを確認します。