Skip to main content

​
S7: ブランドアイデンティティと検証

メンバー限定 — Practitioner 資格が必要。Addie と約 60 分。ハンズオンラボとアダプティブ試験を組み合わせます。
このスペシャリストモジュールは、Brand Protocol のアイデンティティと検証レイヤーの習熟をテストします。サンドボックスエージェントと協働してブランドの brand.json を解決し、brand.json と adagents.json にまたがる双方向トラストチェーンをウォークし、verify_brand_claim を呼んでその署名レスポンスをトラストのために解釈し、複数の法域にわたって商標を曖昧性解消します。Addie はあなたのハンズオン作業とプロトコルのトラストモデルについて推論する能力の両方を評価します。 合格すると AdCP specialist — Brand 資格を獲得します。
これはブランド資格で、暗号の資格ではありません。 それはブランドドメインの 判断 を証明します — アイデンティティの解決、組織階層の読み取り、誰がブランドのために行動できるか知ること、トラストモデルの適用、検証結果が何を 意味する か決めること。ハイパー技術的ではありません: 署名レスポンスが現れる場所では、ゲートは「有効 / 期限切れ / 偽造された署名が何を教えるか、そしてそれについて何をするか」であり — 暗号を実装することではありません。署名メカニクス（キー解決、正規化、署名チェック）は S6: セキュリティ のセキュリティスペシャリストスキルで、関連する場所で相互参照されます。
このドメインは 2 速で、このモジュールもそうです。 アイデンティティと検証の表面 — brand.json 解決、分散セルフパブリッシング、verify_brand_claim 署名レスポンス、adagents.json 確認 — は成熟しており、この資格が ゲートする ものです。権利ライフサイクル（get_rights / acquire_rights / update_rights）は brand.rights_lifecycle フィーチャークラスターに属し、実験的ステータス で 実験的 とマークされています。あなたはそれをウォークすることを学びますが、その習熟は 教えられ、評価されません — それに依存するゲートされた基準はありません。

​
このトラックが検証を準備する専門分野

以下の specialisms は brand ドメインに該当します。それぞれ独自のコンプライアンスストーリーボードを持ちます — 完全な分類については コンプライアンスカタログ を参照。 brand-rights 専門分野ストーリーボードは stable ですが、実験的 とマークされた brand.rights_lifecycle フィーチャークラスター（get_rights、acquire_rights、update_rights）を実行します — 部分的権利、サブライセンス、失効、紛争解決は進化することが予想されます。このモジュールはドメインのアイデンティティと検証の半分をゲートします; 権利ライフサイクルは実験的として教えます。

​
組織階層: 属性だけではない

ブランドアイデンティティは 組織が誰であり誰がそれのために行動できるか を、2 つの異なる軸に沿ってエンコードします — そしてこのモジュールは属性（色、トーン、ロゴ）だけでなく両方をゲートします:
  • 軸 1 — ブランド対ブランド（ハウス階層）。 どのブランドがハウスに属するか: house_of_brands 対 branded_house アーキテクチャ、keller_type（master / endorsed / independent）、brand_refs[] ↔ house_domain 相互性。
  • 軸 2 — ブランド対オペレーター（誰がブランドの ために 行動するか）。 ハウスはその brand.json で authorized_operators[] を宣言します — そのブランドを代表することを許可されたエージェンシー、プラットフォーム、インハウスチームで、それぞれ domain、brands[]（または * ワイルドカード）、countries、scopes[]（media_buying、creative_generation、rights_clearance、governance、measurement、agent_operations）でスコープされます。
3 つの関係タイプを区別しておきます — 混同しやすいです: ランタイムでオペレーター軸は Accounts Protocol で表面化します: すべてのアクションは自然キーが {brand, operator} である account を運びます（operator はアカウントを運用するエンティティのドメインで; ブランドが直接運用するときはブランド自身のドメインに等しい）。セラーの require_operator_auth ケイパビリティが参照形状を選択します — true ⇒ 独立したオペレーター認証を持つセラー割り当ての account_id 名前空間; false ⇒ sync_accounts 経由のバイヤー宣言 {brand, operator} ペア。get_brand_identity の authorized ティアは、まさにアイデンティティのオペレーター（リンクされたアカウント）ビューです。

​
あなたが知れること — そして知れないこと

この資格の知的中核は トラストフレームワーク です: ブランドアイデンティティの認識論。ここでの暗号は 誰かが何かを言った ことを証明し、それが真実かどうか ではありません。トラストはクリーンに分離する 2 つのレイヤーで解決します:
  • アイデンティティ属性（ロゴ、色、トーン、タグライン） — 単一の TLS でサーブされる brand.json から信頼されます。自身のドメインを制御するブランドは、自身の属性について権威的です、以上 — 親関係が相互化されていなくても。（「主張されたが未検証 ⇒ リーフを完全に無視」は 間違い です: リーフのアイデンティティは依然として本物です。）
  • 関係（誰がブランドを所有するか、誰がそれのために話せるか） — 両方の 側が相互化するときのみ信頼されます。
次に 各シグナルが実際に何を証明するか のはしごを登ります: プロトコルがあなたのために確立できないもの — そしてあなたが代わりにどこへ行かなければならないか:
  • 現実世界の法的地位 → あなたが期待する法的エンティティに対する消費者側ドメイン制御 + TLS; 高信頼決定のための帯域外アイデンティティ。（これは 検証済みアイデンティティ証明 が存在する場所です — 別の、実験的 フィーチャーで、この資格の範囲外。）
  • 商標の実際の登録 → 公開 レジストリ レコードをクロスチェック（エージェントは matched_registration を主張するだけ）。
  • プロパティクレーム → DNS/TLS をクロスチェック。
  • licensed_in → 名指されたライセンサーが licensed_out を相互化するまで未検証。
  • 保留された内部状態（キュー位置、チケット状態、チームルーティング） → 決して露出されない; それを推論しない。
  • exp を過ぎた鮮度 → 期限切れのエンベロープは監査証拠で、新鮮な認可シグナルではない。
避けるべき 2 つの罠: managed_by は ディレクトリ フィールドで、決してトラスト / 認可シグナルではない; そしてスタンドアロンリーフの沈黙は、それを主張する任意のサードパーティハウスに 勝る。

​
ブランドアイデンティティがクリエイティブ生成をどう駆動するか

ブランドアイデンティティは装飾ではありません — それはオンブランド生成への 入力 で、それが authorized ティアが存在する 理由 です。クリエイティブエージェントは brand.json をフェッチ（または get_brand_identity authorized を呼び）、次にワードマークを引き出し、正確なパレットとタイプスケールを適用し、トーンオブボイスを採用し、制限に従います — visual_guidelines が食品画像の上のテキストを禁止するので、見出しを画像の 下 に置いたフードフォワードなコンポジションを生成します。推測なし、修正なし。2 つのロールを分離します:
  • ジェネレーターが消費する 入力: logos、colors、fonts、tone.voice、voice_synthesis（provider / voice_id / settings）。
  • それが生成してよいものを束縛する 制約: tone.dos / tone.donts、visual_guidelines.restrictions（例: 「アスリートの上に決してテキストを置かない」）、content_restrictions。
入力品質が出力品質を駆動します — よりリッチな brand.json はより少ない修正でより良い生成を生みます。これらはまさに get_brand_identity が認可の背後にゲートするフィールドです、ブランドが生成入力を保護するから。 2 番目の、実験的 パスは、ライセンスされたタレントの肖像や声で生成するとき（brand.rights_lifecycle）に適用されます: acquire_rights が、特定のプロバイダー（肖像には Midjourney、声には ElevenLabs）が 生成時に 検証する スコープされた generation_credentials を発行します — 権利エージェントが許可を設定し、プロバイダーがそれを強制します — rights_constraint（用途 / 国 / インプレッション上限）、必須の開示テキスト、生成されたアセットをレビューのためにブランドエージェントに戻す creative_approval ループとともに。インプレッション上限に達すると生成が停止します。
範囲境界。 このモジュールはハンドオフのブランド 側 をカバーします — 入力 / 制約としてのアイデンティティ、そして権利 / 承認インターフェース。クリエイティブ自体の生成（build_creative マニフェスト / コードモード、フォーマット選択、プレビュー、同期）は S2: クリエイティブ と S5: Sponsored Intelligence / 生成広告 に属します — 相互参照され、ここで再教育されません。権利ゲートされた半分は教えられ、ゲートされません（それは実験的な権利ライフサイクルに乗ります）。

​
このモジュールでの stable 対 experimental

​
あなたがデモンストレーションすること

  • ブランドのアイデンティティを、静的な brand.json と get_brand_identity エージェントタスクの両方から解決; available_fields を読んで未認可の呼び出し元が何を欠いているか検出し、次に authorized=true を再リクエストしてゲートされた colors / fonts / tone / voice / rights セクションを取得
  • ブランド階層関係が本物であることを 両方の 方向をチェックして確立 — 親ハウスの brand_refs[] とサブブランドの house_domain バックポインター — し、なぜ片側のアサーションがトラストを拡張しないか説明
  • ハウスの authorized_operators[] を解決し、与えられたオペレーター（エージェンシー、プラットフォーム、インハウスチーム）が特定のブランドのために行動できるか判定 — domain、brands[]（* ワイルドカード含む）、countries、scopes[] をチェック — し、このバイサイドオペレーター軸をハウスメンバーシップとセルサイドエージェント委任から区別; require_operator_auth が {brand, operator} 対 account_id 参照形状をどう選択するか推論
  • 委任された販売エージェントを双方向に確認: パブリッシャーの adagents.json がそれを認可 かつ エージェントが自身の brand.json で自己宣言（どちらも単独では不十分）; なぜエージェントの署名キーをピンするパブリッシャーがエージェントの署名レスポンスのトラスト権威になるか（侵害されたエージェントが自身のキーにスワップできないように）理解し、パブリッシャーがリストしないエージェントを拒否 （署名チェックのメカニクスは S6 セキュリティ）
  • 署名された verify_brand_claim レスポンスをトラストのために 解釈 — 有効な署名はブランドが回答を 作成した ことを証明（真実であること、否認防止ではない）、期限切れのものは監査のみ、検証に失敗するか署名された内容が一致しないレスポンスは拒否されなければならず、未署名 / 未検証の回答や verification_status フィールド単独は決してトラストを拡張しない （署名がどう検証されるかは S6 セキュリティスキル — ここでは各結果が何を意味するか推論）
  • 方向非対称トラストルール を適用: 単一の owned / pending_review / licensed_in アサーションを、他の側が相互化するまで有益だがトラストを拡張しないものとして扱い、not_ours / disputed を単一の署名レスポンスについて権威的として扱う
  • レジストリと Nice クラスにわたって商標クレームを曖昧性解消: あるレジストリで owned だが別で disputed または licensed_in であるマークを解決し、AMBIGUOUS_MATCH を絞り、間違った登録に対してクリエイティブをクリアすることを回避
  • ブランドの解決されたアイデンティティを クリエイティブ生成 にマップ: どのフィールド（logos、colors、fonts、tone.voice、voice_synthesis）がジェネレーターが消費する 入力 か、どれ（tone.donts、visual_guidelines.restrictions、content_restrictions）がハードな 制約 か; なぜこれらが認可ゲートされたフィールドか説明し、ブランド / プロダクション境界（build_creative と実験的な権利ゲートされた generation_credentials + creative_approval ループが引き継ぐ場所）を特定
  • トラストフレームワークの知り得性境界 について推論: アイデンティティレイヤー（TLS 検証可能）を関係レイヤー（相互アサーションゲート）から分離; なぜ署名が 真実ではなく作成 を証明し相互アサーションが 地位ではなく一貫性 を証明するか説明; そしてブランドについての任意の事実について、プロトコルが確立できるもの、できないもの、ギャップを閉じる外部クロスチェック（レジストリ、DNS/TLS、ライセンサー相互化、消費者側地位）を名指す
  • 実験的な権利ライフサイクル（get_rights → acquire_rights → update_rights）をウォークし、権利支出ガバナンスについて推論 — 表面をまだ安定していないと正しくフラグしながら

​
前提読書

Brand Protocol 概要

ブランドドメイン: アイデンティティ、分散パブリッシング、階層、検証、権利。

brand.json

セルフパブリッシュされたアイデンティティドキュメント — ハウスアーキテクチャ、brand_refs[]、エージェント、相互アサーショントラストモデル。

verify_brand_claim

4 つのクレームタイプ、署名レスポンスエンベロープ、方向非対称トラストルール。

相互アサーショントラストモデル

2 つのトラストレイヤー、相互化テーブル、なぜ一貫性が地位でないか — 知り得性フレームワーク。

セラー検証

双方向 adagents.json + brand.json トラストチェーン — Northwind / StreamHaus / Sportshaus Holdings。

Accounts Protocol

ランタイムのオペレーター軸: authorized_operators、{brand, operator} アカウントモデル、require_operator_auth、課金。

ブランドアイデンティティ → クリエイティブ

クリエイティブエージェントがどう brand.json アセット、トーン、制限を引き出してオンブランドを生成するか — そして権利ゲートされた generation_credentials パス。

ブランドエージェントの構築

get_brand_identity、verify_brand_claim、レスポンス署名キーの実装。

実験的ステータス

なぜ brand.rights_lifecycle が実験的か、それが採用者にとって何を意味するか。

​
テストエージェントへの接続

ラボ演習は公開テストエージェントのブランドテナントに対して実行します。共有トークンを使います — サインアップ不要:
ディスカバリーとウォークスルーのドキュメントはホストルートでサーブされます:
  • https://test-agent.adcontextprotocol.org/.well-known/brand.json — エージェント自身のアイデンティティドキュメント
  • https://test-agent.adcontextprotocol.org/.well-known/adagents.json — 販売認可
  • https://test-agent.adcontextprotocol.org/.well-known/jwks.json — 署名キー（response-signing キーを含む）
  • …/fixtures/walkthrough/northwind/.well-known/brand.json — 委任されたエージェンシーのアイデンティティ
  • …/fixtures/walkthrough/streamhaus/.well-known/brand.json と …/fixtures/walkthrough/streamhaus/.well-known/adagents.json — サブブランドパブリッシャーのアイデンティティと販売認可（adagents.json フィクスチャをサーブする唯一のロール）
  • …/fixtures/walkthrough/sportshaus-holdings/.well-known/brand.json — 親ハウスのアイデンティティ、brand_refs[] と authorized_operators[] 付き（ポートフォリオ全体のエージェンシーとブランドスコープの US のみのインハウスオペレーター） これらは セラー検証ウォークスルー のマルチティアトラストチェーンフィクスチャです。
最初の呼び出しのウォークスルーについては クイックスタート を参照。

​
ラボ演習

  1. ブランドアイデンティティの解決 — 認可なしでサンドボックスブランドの get_brand_identity を呼び、available_fields を読んでどのセクションがゲートされているか見る。authorized=true で再度呼び、colors、fonts、tone、rights セクションが現れることを確認。なぜブランドがこれらのフィールドをリンクされたアカウントの背後にゲートするか説明。
  2. アイデンティティ → クリエイティブ生成 — タレントブランド（例: daan_janssen）で、authorized=true で get_brand_identity を呼び、colors、fonts、tone（dos / donts）、voice_synthesis、visual_guidelines.restrictions を読む。各フィールドをクリエイティブエージェントが消費する生成 入力 か出力を束縛するハードな 制約 かに分類し、ジェネレーターが従うオンブランドブリーフを書く。なぜこれらがまさに認可ゲートされたフィールドか説明し、build_creative（S2/S5）と実験的な権利ゲートされた generation_credentials + creative_approval ループが引き継ぐ場所を指す。
  3. 分散パブリッシング相互性 — Sportshaus Holdings の brand.json をフェッチしその brand_refs[] を読む。StreamHaus の brand.json をフェッチしその house_domain を読む。関係が 両方の 方向でアサートされることを確認。1 つの方向だけがチェックされた場合に悪意あるハウスが何を主張できるか説明。
  4. オペレーター認可 — Sportshaus Holdings の brand.json で authorized_operators[] を読む。meridian-agency.example が streamhaus のために購入できること（brands: ["*"] を持つ）、courtside-inhouse.example が できない こと（brands: ["courtsidehq"]、countries: ["US"] にスコープされている）を確認。このバイサイドオペレーター軸がハウスメンバーシップ（brand_refs[]）とセルサイドエージェント委任（adagents.json）とどう異なるか、require_operator_auth が {brand, operator} 自然キーとセラー割り当ての account_id のどちらを渡すか決めるかを説明。
  5. 双方向 adagents.json 確認 — StreamHaus の adagents.json をフェッチし Northwind Media を認可するエントリーを見つける; delegation_type: "delegated" を確認。Northwind の brand.json をフェッチし同じ販売エージェントを宣言することを確認 — パブリッシャーがそれを認可 かつ エージェントが自己宣言、どちらも単独では不十分。なぜエージェントの署名キーをピンするパブリッシャーがそのエージェントの署名レスポンスのトラスト権威になるか（侵害されたエージェントが自身のキーにスワップできないように）、なぜパブリッシャーがリストしないエージェントが失敗するか説明。（署名チェックのメカニクスは S6 セキュリティ。）
  6. verify_brand_claim — 署名された回答を解釈 — streamhaus.example について claim_type: "subsidiary" で verify_brand_claim を呼び、回答を 解釈: それはブランドによって署名されているので、有効な署名はブランドが それを作成した ことを証明 — 真実であることではない; 期限切れの署名は監査のみ; 検証に失敗するか署名された内容が一致しないレスポンスは拒否されなければならない; verification_status フィールド単独を決して信頼しない。（暗号検証の実行は S6 セキュリティスキル — ここでは各結果がトラストにとって何を意味するか推論。） 次に claim_type: "parent" でリーフ側のミラーを検証し、相互アサーションがエージェントレイヤーで完了することを確認。
  7. 方向非対称トラスト — 無関係なプロパティについて verify_brand_claim を呼び not_ours を観測。なぜこの拒否が単一の署名レスポンスについて権威的で、owned または licensed_in の回答がそうでないか — そして licensed_in がどの相互化ステップを要求するか説明。
  8. 商標曖昧性解消 — 同じマークについて 2 つの異なるレジストリの下で claim_type: "trademark" で verify_brand_claim を呼び、異なるステータス（owned 対 licensed_in）を観測。レジストリなしで一度呼び AMBIGUOUS_MATCH を観測。registry、countries、nice_classes がどう曖昧性を解決するか、なぜこれがクリエイティブクリアランスにとって重要か説明。
  9. トラスト境界 — 知れないこと — エージェントが courtsidehq サブシディアリークレームに owned で署名し、Sportshaus Holdings が brand_refs[] に courtsidehq をリスト — しかし courtsidehq ドキュメントが相互化しない。なぜ署名された owned が 真実ではなく作成 を証明するか、なぜこのハウスのみのエッジが courtsidehq のアイデンティティ（それが 1 つを公開したなら）が依然として本物であっても関係レイヤーで 未検証 か説明。次に sportshaus-holdings.example があなたが思う 本物の 組織であると信頼するためにあなたがまだ必要とするもの — そしてなぜ署名も相互アサーションもそれを与えられないか述べる。
  10. 権利ライフサイクル（実験的） — get_rights を使ってタレントオファリングを発見し、acquire_rights → update_rights ライフサイクル、スコープされた generation_credentials と creative_approval ループ、権利支出ガバナンスについて推論。この表面を実験的（brand.rights_lifecycle）として識別し、それが本番採用にとって何を意味するか説明。資格ゲートとして評価されない。

​
評価

合格しきい値: 70%。