アカウントプロトコル

​

商取引モデル

​

スコープ

​

アカウントステータスライフサイクル

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）

​

アカウントステータス別のオペレーション

• payment_required は新規支出（create_media_buy）をブロックするが、既存バイの管理とセットアップの解決を許可。パッケージ追加は機能的に新規支出と同等なので、セラーはアカウントが payment_required のとき update_media_buy 内の new_packages も拒否すべき（SHOULD）。
• suspended は既存データへの読み取り専用アクセスを許可するが、すべての変更をブロック
• セラーは、停止アカウントのブロックされたオペレーションには ACCOUNT_SUSPENDED を、payment-required アカウントのブロックされたオペレーションには ACCOUNT_PAYMENT_REQUIRED を返さなければならない（MUST）

​

Caller authorization

{
  "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
  }
}

​

フィールド

​

存在と不在のセマンティクス

• 存在: ベンダーエージェントは、形状がこの瞬間のこのアカウントに対するこの呼び出し元への強制を反映すると表明します。数秒古いのは問題ないが、体系的に発散するのは非コンフォーマント。
• 単一アカウントで不在: ベンダーエージェントはそのアカウントについて呼び出し元にスコープを伝えていません。呼び出し元はエラー駆動ディスカバリー（タスクを試し、RBAC エラーコードを処理）にフォールバックします。
• すべてのアカウントで不在: ベンダーエージェントはスコープイントロスペクションを実装していません。呼び出し元は不在からアクセスを推論してはならない（MUST NOT）— ベンダーエージェントは依然ローカルでスコープを強制し、任意のタスク呼び出しで SCOPE_INSUFFICIENT / READ_ONLY_SCOPE / FIELD_NOT_PERMITTED を返し得ます。
• authorization は 3.x でオプション。破壊的変更を避けたいベンダーエージェントは設定を延期できます。設定は厳密に追加的です — 呼び出し元が試行で発見するはずのエラーを先取りできるようにします。

​

アイデンティティバインディング、リフレッシュケイデンス、一貫性

• 呼び出し元は、アカウントに対する能動的使用の少なくとも 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）。

​

リフレッシュウィンドウ内での SCOPE_INSUFFICIENT へのバイヤー応答

• リトライバジェット: 3 回以下、各回 1〜5 秒のジッター付きバックオフで分離。これは曖昧性解消ロジック — correctable 分類を信頼する前にスコープが本当に不十分かを確立 — であり、correctable エラーの復旧アクションではありません。
• 300 秒ウィンドウではない: リトライバジェットはセラーの伝播 SLA ではありません。バイヤーはすべての偽陰性で 300 秒ウィンドウ全体を待つべきではありません（SHOULD NOT）。累積 15 秒までのバックオフ遅延が典型的なレプリカラグを吸収するのに十分です。
• リトライ尽きた後: バイヤーはエラーを表面化しなければなりません（MUST）。「表面化」とは: 呼び出し層に構造化エラー（アカウント ID、失敗したタスク、試行回数を持つ error.details.retry_count を含む）を返す AND 失敗をオペレーターがアクセス可能なチャネル — 構造化ログ、ダッシュボードアラート、通知 — で可視にすることを意味します。エスカレーションメカニズムは実装依存。要件はエラーが黙って飲み込まれないことです。

​

標準の名前付きスコープ: attestation_verifier

• 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

​

他のベンダープロトコル向けのカスタムスコープ

• 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。クリアランス権限なしのディスカバリー。

​

先行技術

​

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

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, ... }])
   配信後にベンダーエージェントへサービス消費状況を通知

​

プリンシパル

​

タスク

​

ブランドレジストリとの接続

​

取引相手の検証

• ブランドアイデンティティ: このブランドは主張通りか？
• オペレーター認可: リクエストのオペレーターはこのブランドの代理購入が許可されているか？
• ブランド階層: このハウスポートフォリオにはどのサブブランドが含まれるか？

​

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

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);
}

​

ソース権威

​

プロパティコントリビュートバック

​

利用報告