AdCP — brand.json Specification

brand.json ファイルは、ブランドがアイデンティティを主張し、発見可能なブランド情報を確立するための標準的な手段を提供します。異なる公開モデルに対応するために 5 つのバリアントをサポートします。

brand.json はブランドアイデンティティデータの正準ソースです。ここで定義されるブランドオブジェクト（logos、colors、tone、tagline）は、AdCP 全体で使われる単一のブランド定義です。タスクはドメインと brand_id でブランドを参照します — システムは brand.json またはレジストリから完全なアイデンティティを解決します。

Motivation

ホールドコのブランドアイデンティティは、親が所有する1 つの brand.json に存在しうる — すべての子の変更が親のファイルの編集を必要とします。Converse がロゴを更新したいなら、誰かが Nike, Inc. のファイルを編集します。ホールドコが 100 の子会社ブランドを運営するなら、100 のすべてのチームが同じモノリシックなドキュメントに集約します。ブランドチームは自分のアイデンティティを所有しますが、モノリシックな形状はコーポレート親に単一の運用チョークポイントを強制します。それはまた独立ブランドがそもそも公開することをブロックします — 他人のポートフォリオにリストされたブランドは、ドメイン管理がそれを証明できる場合でも、自身の正準データを主張するプロトコルレベルのパスを持ちません。仕様は、ハウスが家族に誰がいるかの権威であり続けながら、子ブランドが自身の正準ドキュメントを公開できるようにすることでこれを解決します。インライン brands[] は一級のオプションのままです（親がデータを所有）。brand_refs[] は、正準ドキュメントが別の場所に存在するポインター子を追加します（子がデータを所有）。ハウスは自由に混合します。階層は 1 レベルの深さです — ハウスのみが所有権を宣言し、ブランド自体は子を持てません。

File location

ブランドは brand.json ファイルを次の場所にホストします。

https://example.com/.well-known/brand.json

RFC 8615 の well-known URI 慣例に従います。

Variants

brand.json ファイルは 5 つのバリアントをサポートします。

#	Variant	Use when
1	Authoritative Location Redirect	正準ドキュメントが別の URL にホストされている
2	House Redirect	ブランドドメインがより大きなハウスにロールアップする
3	Brand Agent	MCP エージェントが権威あるブランドアイデンティティを提供する
4	House Portfolio	ハウスがブランドを公開する（インライン、ポインター、または両方）
5	Brand Canonical Document	ブランドが自身のアイデンティティを自己公開する（任意の `house_domain` ポインター付き）

バリアント 1〜3 は互いに、およびバリアント 4〜5 と相互排他的です。バリアント 4 と 5 は合成します: House Portfolio（4）は brand_refs[] を通じて Brand Canonical Document（5）を参照でき、Brand Canonical Document は house_domain を通じてハウスを指し返せます。2 つの半分がどう解決するかについては Mutual-assertion trust model を参照。

1. Authoritative Location Redirect

別の URL にホストされた brand.json を指します。

{
  "$schema": "https://adcontextprotocol.org/schemas/v3/brand.json",
  "authoritative_location": "https://adcontextprotocol.org/brand/abc123/brand.json"
}

次の場合に使います。

brand.json が中央でホストされている（例: サービスプロバイダーによって）
CDN 配信が必要
マネージドブランドサービス

任意フィールド（House Redirect と共有 — Redirect ergonomics を参照）:

redirect_reason: キャッシュ処理のための構造化シグナル（acquisition、rebrand、regional、legacy、consolidation、other）
redirect_effective_at: リダイレクトが有効になった ISO タイムスタンプ
note: 自由テキストの根拠

2. House Redirect

完全なブランドポートフォリオを含むハウスドメインを指します。

{
  "$schema": "https://adcontextprotocol.org/schemas/v3/brand.json",
  "house": "nikeinc.com",
  "note": "Regional site - see house for brand portfolio"
}

任意フィールド:

region: ISO 3166-1 alpha-2 国コード（例: “CN”）
redirect_reason: キャッシュ処理のための構造化シグナル（Redirect ergonomics を参照）
redirect_effective_at: リダイレクトが有効になった ISO タイムスタンプ
note: 自由テキストの根拠

次の場合に使います。

ブランドドメインがより大きなハウスに所有されている
地域/ローカライズドメインがメインハウスを指す
レガシードメインが正準にリダイレクトする

Redirect ergonomics

両方のリダイレクトバリアントは、コンシューマーが古いキャッシュ状態に留まることなくリダイレクト遷移を処理できるよう、任意の redirect_reason と redirect_effective_at を受け入れます。 redirect_reason は enum です。

Value	Meaning	Caching guidance
`acquisition`	所有エンティティが買収された（例: 1 つのホールドコが別のホールドコを購入）	安定するまでキャッシュ TTL を短縮。多くのフィールドが移動する可能性
`divestiture`	所有エンティティがスピンアウトまたは売却された	安定するまでキャッシュ TTL を短縮。新しい所有チェーン
`rebrand`	ブランドまたはハウスが改名/再ポジショニング	安定するまでキャッシュ TTL を短縮
`consolidation`	サブブランドがターゲットに統合された	安定するまでキャッシュ TTL を短縮
`regional`	地域/ローカライズドメインがメインハウスを指す	安定。標準キャッシュ
`legacy`	正準にリダイレクトする古いドメイン	安定。標準キャッシュ
`other`	上記でカバーされない理由	自由テキストの根拠は `note` に属する

redirect_effective_at（ISO 8601 タイムスタンプ）はハードなキャッシュ不変条件です: キャッシュは、このタイムスタンプより前にキャッシュされた任意のエントリを古いものとして扱い、リダイレクトを通じて再取得しなければなりません（MUST）。上記の TTL 短縮ガイダンスは SHOULD です。このタイムスタンプは MUST であり、M&A や他の遷移中のキャッシュポイズニングに対する負荷を担う修正です。これは、IAB Tech Lab の ads.txt（OWNERDOMAIN）と sellers.json（seller_type）の移行パターンに対する brand.json の類似物です。それらは歴史的に帯域外の調整に依存していました — 機械可読な遷移シグナルはありませんでした。redirect_reason + redirect_effective_at が brand.json についてそのギャップを閉じます。例 — 買収リダイレクト:

{
  "$schema": "https://adcontextprotocol.org/schemas/v3/brand.json",
  "house": "wpp.com",
  "redirect_reason": "acquisition",
  "redirect_effective_at": "2026-04-15T00:00:00Z",
  "note": "Acquired by WPP April 2026"
}

3. Brand Agent

ブランド情報を提供する MCP エージェントを指定します。

{
  "$schema": "https://adcontextprotocol.org/schemas/v3/brand.json",
  "version": "1.0",
  "brand_agent": {
    "url": "https://agent.acme.com/mcp",
    "id": "acme_brand_agent"
  }
}

任意フィールド:

contact: 連絡先情報

ブランドがエージェントを持つ場合、エージェントがブランドアイデンティティデータの権威あるソースです。

4. House Portfolio

ハウスがブランドを公開します。ハウスは、インラインの子定義、自己公開するブランドへのポインター参照、または両方を運べます。

brands[] — インラインの子定義。親がデータを所有。 独自のドメインを持たないサブブランド（Nike SB、内部プロダクトライン）や、ホールドコが中央で管理したいサブブランドに最適。
brand_refs[] — ポインターエントリ。子が自身の正準ドキュメント（バリアント 5）でデータを所有。 自己公開権限を望む独自ドメインを持つサブブランド（Converse、Jordan）に最適。

特定の子は 2 つの配列の正確に 1 つに現れます。brands[] または brand_refs[] の少なくとも 1 つが存在しなければなりません。 シンプルなハウス（インラインのみ）:

{
  "$schema": "https://adcontextprotocol.org/schemas/v3/brand.json",
  "version": "1.0",
  "house": {
    "domain": "nikeinc.com",
    "name": "Nike, Inc.",
    "architecture": "hybrid"
  },
  "brands": [
    {
      "id": "nike",
      "names": [{"en": "Nike"}],
      "keller_type": "master",
      "properties": [
        {"type": "website", "identifier": "nike.com", "primary": true}
      ]
    }
  ]
}

混合ハイブリッド（インライン + ポインター）:

{
  "$schema": "https://adcontextprotocol.org/schemas/v3/brand.json",
  "version": "1.0",
  "house": {
    "domain": "nikeinc.com",
    "name": "Nike, Inc.",
    "architecture": "hybrid"
  },
  "brands": [
    {
      "id": "nike_sb",
      "names": [{"en_US": "Nike SB"}],
      "keller_type": "sub_brand"
    }
  ],
  "brand_refs": [
    { "domain": "converse.com", "brand_id": "converse" },
    { "domain": "jordan.com",   "brand_id": "jordan" }
  ]
}

brand_refs[] エントリの形状:

Field	Required	Meaning
`domain`	yes	子の正準 brand.json が存在する場所。`brand_refs[]` 内で一意でなければなりません。
`brand_id`	yes	ハウスのポートフォリオ内でのこのブランドの安定した識別子。`brand_refs[]` 内で一意で、`brands[]` にも現れてはなりません（MUST NOT）。
`managed_by`	no	このブランドを運用的に管理するエンティティのドメイン（例: ホールドコ内のエージェンシーネットワーク）。ハウスが宣言。コンシューマーは信頼や認可の決定に使ってはなりません（MUST NOT）。ハウス横断の集計（「BBH が管理するすべてを表示」）が意図された用途です — これは信頼フィールドではなくディレクトリフィールドです。
`effective_at`	no	ハウスがこの所有権クレームを確立した ISO 8601 タイムスタンプ。コンシューマーはこの日付から相互アサーションのエッジをエイジングします。省略すると、コンシューマーは自身の最初の観察からエイジングします。

このエントリと子の house_domain クレームの関係についての信頼セマンティクスは、下記 Mutual-assertion trust model で定義されます。 委任を伴うハウス（WPP）: ホールドコはブランド管理をエージェンシーネットワークに委任します。WPP plc はブランドを所有しますが、Ogilvy や BBH が実際に日々運営します。brand_refs[] エントリの managed_by は、これを所有ハウスによる一方的な宣言として捕捉します。リーフブランドはマネージャーを参照しません。UI はエージェンシービューのために BBH Sport を BBH の下でレンダリングします。信頼検証は BBH Sport → WPP のみをたどります。

{
  "$schema": "https://adcontextprotocol.org/schemas/v3/brand.json",
  "version": "1.0",
  "house": {
    "domain": "wpp.com",
    "name": "WPP plc"
  },
  "brand_refs": [
    { "domain": "bbh-sport.com",     "brand_id": "bbh_sport",     "managed_by": "bbh.com" },
    { "domain": "ogilvy-toyota.com", "brand_id": "ogilvy_toyota", "managed_by": "ogilvy.com" },
    { "domain": "wpp-direct.com",    "brand_id": "wpp_direct" }
  ]
}

managed_by はディレクトリフィールドであり、信頼フィールドではありません。 コンシューマーが実際に日々運営する主体でブランドをグループ化できるように存在します — エージェンシーネットワーク横断でインベントリをショッピングするときにバイヤー側 DSP が望む正準ビューです。コンシューマーは信頼や認可の決定に使ってはなりません（MUST NOT）。その線は依然としてリーフとハウス間の相互アサーションを通じて流れます。Conformance を参照。

5. Brand Canonical Document

ブランドが自身のアイデンティティ属性を所有する、ブランドごとの自己公開ドキュメント。ブランド自身の /.well-known/brand.json（または authoritative location redirect 経由）にホストされます。ブランドは house_domain を通じてハウスを宣言するか、単独で立つ（親ハウスなし — Patagonia、Liquid Death — フィールドを省略）ことができます。house_domain 関係の信頼セマンティクスは、下記 Mutual-assertion trust model で定義されます。 ハウス付き — Nike 傘下の Converse:

{
  "$schema": "https://adcontextprotocol.org/schemas/v3/brand.json",
  "version": "1.0",
  "id": "converse",
  "names": [{"en_US": "Converse"}],
  "keller_type": "sub_brand",
  "house_domain": "nikeinc.com",
  "logos": [
    {"url": "https://converse.com/logo.svg", "variant": "primary"}
  ],
  "tagline": "Sneaker for the streets"
}

スタンドアロン — Patagonia:

{
  "$schema": "https://adcontextprotocol.org/schemas/v3/brand.json",
  "version": "1.0",
  "id": "patagonia",
  "names": [{"en_US": "Patagonia"}],
  "keller_type": "independent",
  "logos": [
    {"url": "https://patagonia.com/logo.svg", "variant": "primary"}
  ],
  "tagline": "We're in business to save our home planet."
}

ブランドが独自のドメインを持ち、そのアイデンティティ（logos、colors、tone、taglines）の自己公開権限を望む場合に使います。ブランドは brands[] のインラインエントリと同じアイデンティティフィールドを運びます。 このバリアント固有のトップレベルフィールド:

Field	Type	Required	Description
`id`	string	Yes	ブランド識別子（アンダースコア付きの小文字英数字）
`names`	array	Yes	ローカライズされた名前
`house_domain`	string (domain)	No	このブランドが属するコーポレートハウスへのポインター。省略されるとブランドはスタンドアロンとして扱われます。シングルホップ — ブランド自体は `brand_refs[]` を宣言できません。
`$schema`、`version`、`last_updated`	string	No	ドキュメントメタデータ

他のすべてのブランドアイデンティティフィールドが適用されます（logos、colors、fonts、tone、tagline、visual_guidelines、keller_type、parent_brand、properties[]、industries[]、target_audience、description、agents[]、contact、trademarks[]、data_subject_contestation など — 完全なフィールドリストは Brand definition を参照）。ドキュメントは、ハウス専用フィールド（house、brands、brand_refs、authorized_operators）やリダイレクトフィールド（authoritative_location、文字列としての house、region、note、redirect_reason、redirect_effective_at）を運んではなりません（MUST NOT）。

Mutual-assertion trust model

信頼は 2 つの層で解決します — ブランドアイデンティティ（logos、colors、tone、tagline など）とブランド関係（このブランドを誰が所有するか、誰がそれを代弁できるか）。2 つの層はきれいに分離します。アイデンティティは単一の TLS 提供ドキュメントから検証可能です。関係は両側が相互に応答することを必要とします。

Edge	Identity trust	Relationship trust	Notes
`brands[]` のインライン子	Trusted（親の TLS がデータをカバー）	Trusted（ハウスがエントリを作成）	古典的な形状。親がデータを所有。
相互アサーション: リーフが `house_domain: A` と言い、A の `brand_refs[]` がリーフを含む	Trusted（リーフの TLS）	Trusted（両側が相互応答）	完全な信頼。ガバナンス伝播、メンバー機能継承、課金可能な包含がすべて流れる。
リーフのみ: リーフが `house_domain: A` と言い、A の `brand_refs[]` がリーフを含まない	Trusted（リーフの TLS）	未検証	アイデンティティは本物 — ブランドは自身のドメインを管理。親クレームは未検証。ガバナンスと課金可能な包含は相互応答待ちでブロックされる。Self-healing through notification を参照。
ハウスのみ: A の `brand_refs[]` がリーフを含み、リーフが `house_domain` を持たない	Trusted（リーフの TLS — スタンドアロンドキュメントとして）	逆方向で未検証	リーフは A を主張していない。リーフをスタンドアロンとして扱う。A のクレームは補助メタデータ。
スタンドアロン（`house_domain` なし）	Trusted（リーフの TLS）	n/a — 主張された関係なし	Patagonia、Liquid Death。ブランドはそれ自体のもの。

主要な非対称性。 自身のドメインで検証済み TLS を持つリーフは、その親クレームが相互応答されているかどうかに関係なく、自身のアイデンティティ属性について権威を持ちます。相互アサーションがゲートするのは関係層です。素朴な「主張されたが未検証 ⇒ リーフを完全に無視」という読みは誤りです — リーフの logos/colors/tone は依然として本物です。 スタンドアロンは第三者クレームに勝る。 house_domain のない Brand Canonical Document はスタンドアロンです。他のハウスの brand_refs[] がそれをリストしていても、リーフの沈黙が決定的です: スタンドアロンとして扱い、第三者クレームは未検証メタデータのみです。規範的な記述については Conformance を参照。検証はランタイムチェックです（クローラーが両方のドキュメントを取得して比較）。JSON スキーマはフィールドを独立して受け入れます。

Self-healing through notification

リーフのみのエッジケースは実際に一般的です — サブブランドチームが、親のポートフォリオチームが相互エントリを追加する時間を持つ前に、自身の正準ドキュメントを立ち上げます。今日これはブランドを行き詰まらせます: アイデンティティは良好ですが、メディアバイとガバナンス決定はブロックされます。仕様は自己修復ループを定義します。ブランドエージェントなしのハウスの場合:

ハウスがその brand.json のトップレベルで到達可能な contact.email を公開します。
コンシューマーがリーフのみのエッジ — リーフが house_domain: A を主張し、A の brand_refs[] がリーフを含まない — に遭遇したとき、コンシューマーは、リーフが相互応答を主張し検証待ちでブロックされていることを A の contact.email に通知すべきです（SHOULD）。
ハウスチームがエントリを brand_refs[] に追加します。次のクロール/再検証で、エッジは相互にアップグレードします。

verify_brand_claim をアドバタイズするブランドエージェントありのハウスの場合、コンシューマーは代わりにエージェントに直接尋ねます — 下記 Agent-augmented verification を参照。エージェントパスは、メールループが表現できるよりリッチな状態（pending_review、transferring、disputed、licensed_in）を表面化し、ハウスとリーフの両方がエージェントを公開する場合、静的ファイルのクロールなしに 2 つの署名付きエージェント呼び出しを通じて相互アサーションが完了します。

Agent-augmented verification

ブランドがブランドエージェント（variant 3、またはバリアント 4/5 の agents[] の type: "brand" エントリ）を公開する場合、エージェントに verify_brand_claim を通じて検証の質問ができます — claim_type（subsidiary / parent / property / trademark）を取り、ブランドの権威ある回答を返す単一のツールです。ブランドエージェントは、サーバーの背後に隠された brand.json です: 静的ファイルが運ぶのと同じデータに加え、静的ファイルが捕捉できないよりリッチな状態（pending_review、transferring、disputed、licensed_in、licensed_out）です。 信頼モデルは方向によって非対称です。 この非対称性がなければ、悪意ある、または誤ったハウスが所有していない子会社を主張し、署名だけの強さでコンシューマーに信頼を拡張させることができます。

Direction	Trust rule
拒否 — エージェントが `disputed` または `not_ours` に署名	一方的に権威を持つ。ブランドは他の当事者が何を公開しようと関連を拒否する立場を持つ。任意の相互応答クレームをオーバーライドする。
アサーション — エージェントが `owned` / `pending_review` / `transferring` / `licensed_*` に署名	情報提供的だが単独では信頼を拡張しない。相互側が（自身のブランドエージェントの `parent` クレームタイプを通じて、または静的クロールを通じて）依然として確認しなければ、関係信頼は拡張しない。

ハウスとリーフの両方がブランドエージェントを公開する場合、相互アサーションはエージェント層で完了できます: パートナーがハウスに claim_type: "subsidiary" で、リーフに claim_type: "parent" で verify_brand_claim を呼び出します。両方が owned → 相互アサーション、リアルタイム、両当事者による署名、クロール不要。これが信頼拡張の最もクリーンなパスです。 相互アサーションは 2 当事者間の一貫性を証明し、立場を証明しません。 攻撃者が制御するドメインの相互アサーションを行う 2 つのエージェントは、一致する owned レスポンスに署名できます。相互アサーションは、彼らが同意することのみを確認し、いずれかが基礎となるブランドに対して正当な権限を持つことは確認しません。最終的な信頼ゲートは依然としてドメイン管理 + TLS です — コンシューマー側で、コンシューマーがドメインを所有すると期待する法的/運用エンティティに対して検証されます。エージェント層での相互アサーションは下限です。コンシューマー側の立場チェック（ドメイン登録、実世界のアイデンティティ）は、高信頼の決定については依然として呼び出し元の責任です。エージェントレスポンスはブランドの adcp_use: "response-signing" JWK の下で署名されます。完全なリクエスト/レスポンス形状とクレームタイプごとの詳細については、タスクリファレンスを参照。

Field resolution

継承/オーバーライドブロックはありません。各コンシューマー側の質問には単一の回答があります。

Question	Resolution
ブランドアイデンティティ（logos、colors、tone、tagline、voice）	ブランド自身の正準ドキュメントから読む。インライン子については、親の `brands[]` エントリから読む。
ブランド連絡先、properties、industries	ブランド自身の正準ドキュメントから読む。
Trademarks、authorized_operators、コーポレート連絡先	ハウスの brand.json から読む。
`data_subject_contestation`、コンプライアンスポリシー、規制カテゴリフラグ	ハウスレベルとブランドレベルの最も厳格なもの。下記参照。
相互アサーション検証	ブランドとハウスの両方を取得し、`house_domain` ↔ `brand_refs[]` を比較。

アイデンティティフィールド（name、names、logos、colors、fonts、tone、voice、tagline、visual_guidelines、avatar）: ブランドレベルの値が権威を持ちます。ハウスの値は参照されません。ブランドチームがブランドアイデンティティを所有します。

Authorized Operator Resolution

authorized_operators[] エントリは、ブランド、国、アクティビティ、時間でスコープできます。オペレーター関係を評価するコンシューマーは、現在時刻が valid_from より前、または valid_until 以降のとき、エントリを無視しなければなりません（MUST）。省略された有効性フィールドは、ハウスが機械可読な開始または終了境界を公開していないことを意味します。 scopes が省略された場合、コンシューマーはエントリを、リストされたブランドと国に対する後方互換の広範な認可として扱うべきです。scopes が存在する場合、オペレーターはリストされたアクティビティのみ、または明示的に all を含む場合はすべてのアクティビティについて認可されます。 authorized_operators[] はパブリッシャー側のインベントリ認可を置き換えません。委任またはネットワークインベントリについては、バイヤーは依然としてパブリッシャーの一致する adagents.json 認可を必要とします。ブランドファイルは誰がブランドまたはハウスを代表できるかを確立し、adagents.json は誰がパブリッシャーのインベントリを販売できるかを確立します。 コンプライアンスとガバナンスのフィールド: 解決される値はハウスレベルとブランドレベルの値の最も厳格なものです。ブランドはハウスのガバナンスアサーションを弱められません。より厳しい制約を追加できるだけです。次に適用されます。

data_subject_contestation — 両方の連絡先がデータ主体に提示されるべきです（SHOULD。コンシューマーはいずれかを使ってもよい。ブランドレベルはハウスレベルを置き換えない）
compliance_policies、オーディエンス除外、規制カテゴリフラグ — 和集合として解決（より多くの制限が勝つ）

これが、ホールドコがコーポレートレベルのガバナンスを公開する負荷を担う理由です: ブランドチームが自己公開によってコンプライアンスを緩められるべきではありません。アイデンティティはブランドチームが所有するものなのでブランドが勝ち、ガバナンスは法務/コンプライアンスレジームが実際に機能する方法なので最も厳格なものです。スキーマはこのルールをエンコードしません。これは解決層のセマンティクスです。完全なクローラー手順については、下記 Resolution algorithm を参照。

Acquisitions and reorganizations

既存のリダイレクトバリアントは M&A をネイティブに処理します。

ディール前: dentsu.com/.well-known/brand.json は House Portfolio です。Dentsu ブランドの正準ドキュメントは house_domain: "dentsu.com" と言います。
ディール成立: Dentsu の brand.json が House Redirect → { "house": "wpp.com" } に置き換えられます。WPP は買収したブランドを、運用継続のための managed_by: "dentsu.com" とディール成立日に設定された effective_at とともに brand_refs[] に追加します。
ディール後: 依然として house_domain: "dentsu.com" を指すリーフは、リダイレクトを通じて WPP に解決します。相互アサーション検証はリダイレクトチェーンをたどり（Conformance を参照）、保持されます。緊急のリーフ移行は不要です。

Adopting brand_refs[] for an existing portfolio

既存の House Portfolio パブリッシャー（今日インライン brands[] 上）は移行する必要はありません。brand_refs[] は追加的でプルベースです — ブランドは、そのチームが自己公開を決定したときにのみ brands[] から移動します。単一ブランドの移行パス:

子ブランドが自身のドメインで /.well-known/brand.json を Brand Canonical Document として立ち上げ、house_domain: "<house>" を宣言します。
ハウスチームが子のエントリを brands[] から削除し、{ domain, brand_id, effective_at } を brand_refs[] に追加します。brand_id は子が使う値に一致しなければなりません（MUST）。そうでなければ、クロス配列の一意性不変条件が将来の読者を助けません。
クローラーが次のリフレッシュで相互アサーションを取得します。

ステップ 1 と 2 の間、リーフのみのエッジは関係層で未検証ですが、リーフのアイデンティティは依然として TLS で信頼されます（Self-healing through notification を参照）。コンシューマーは、ステップ 2 を促すためにハウスの contact.email にメールすべきです（SHOULD）。 AAO レジストリは今日両方の形状を消費し、brands[] から brand_refs[] に移動するブランドを再分類しません — brand_id が移行を通じた安定した識別子です。

Out of scope

単一ハウス、シングルホップの信頼モデルは、意図的に 4 つの形状をカバーしません。

2 つの親を持つジョイントベンチャー（Disney 以前の Hulu、ファーマの JV、自動車パートナーシップ）。リーフは最大 1 つの house_domain を持ちます。JV 構造は 1 つの正準親を選ぶか、持株エンティティを使わなければなりません。プロトコルは 2 親所有をモデル化しません。
不透明性を望む PE ロールアップとホワイトラベル取り決め。 相互アサーションは所有権を well-known URL で公開します。公開開示なしにブランドを運営したいホールドコは、既存のモノリシックな brands[] 形状（リーフドメインのクローラーに親を公開しない）を使えますが、相互アサーションは使えません。相互アサーションは不透明性を検証可能性と引き換えにします — それが設計です。
管轄ガバナンスの乖離（例: データ主体の争議ルールが米国親と異なるドイツの Marriott フランチャイジー）。最も厳格な解決は、ブランドレベルのパブリッシャーが制約を追加できるだけであることを意味します。規制の緩い管轄のブランドは、それに適用されないハウスレベルのルールを落とせません。回避策: ハウスが最も厳格な適用可能な地域ごとのルールを公開します。
静的な brand.json サーフェスとしての標準的なライセンス関係。 claim_type: "trademark" を伴う verify_brand_claim は、基礎となる関係が本物であるため licensed_in / licensed_out を返せます — Marriott フランチャイジーはライセンスの下で MARRIOTT マークを使い、音楽カタログは領域ごとにライセンスアウトされ、管轄ライセンス分割（「CN でライセンス、他では自己管理」）は一般的です。ブランドエージェントは内部記録からこれらについて語れます。しかし brand.json 自体は、所有権のための brand_refs[] と並行する、標準的なライセンス関係の公開サーフェスをまだ持ちません。 既存の権利プロトコル（rights_agent、acquire_rights）は、標準的な宣言ではなくトランザクショナルなライセンス — ディールの交渉 — を処理します。このギャップは本物で、フォローアップとして追跡されています。verify サーフェスは、パートナーがそれらを消費する必要があるため状態を公開しますが、それらを支える静的ファイル基盤は権利プロトコルチームとともに別個の設計です。

これらのケースは brand.json ではなくガバナンス / コーポレート構造の仕様に属します。brand.json はブランドアイデンティティのサーフェスです。コーポレート法務構造とライセンス関係の公開は、それぞれ独自の関心事です。

House definition

house オブジェクトはコーポレートエンティティを表します。

Field	Type	Required	Description
`domain`	string	Yes	ハウスの主要ドメイン
`name`	string	Yes	表示名
`names`	array	No	ローカライズされた名前
`architecture`	enum	No	`branded_house`、`house_of_brands`、または `hybrid`

Brand definition

brands 配列内の各ブランド:

Field	Type	Required	Description
`id`	string	Yes	ブランド識別子（アンダースコア付きの小文字英数字）
`names`	array	Yes	ローカライズされた名前（下記参照）
`keller_type`	enum	No	`master`、`sub_brand`、`endorsed`、`independent`
`parent_brand`	string	No	親ブランドの id
`properties`	array	No	このブランドに関連付けられたデジタルプロパティ
`brand_agent`	object	No	ブランドアイデンティティデータを提供するエージェント `{ url, id }`
`rights_agent`	object	No	権利ライセンスエージェント `{ url, id, available_uses, right_types, countries }`
`logos`	array	No	ブランドロゴアセット
`colors`	object	No	ブランドカラーパレット
`fonts`	object	No	ブランドタイポグラフィ
`tone`	object	No	ブランドのボイスとメッセージングガイドライン（`voice`、`attributes`、`dos`、`donts`）
`tagline`	string	No	ブランドタグラインまたはスローガン
`visual_guidelines`	object	No	生成クリエイティブシステム向けの構造化ビジュアルルール
`trademarks`	array	No	このブランドが所有またはライセンスする登録商標（`registry`、`number`、`mark`、任意の `status`、`license_type`、`countries`）。Trademarks を参照。

Names Array

名前は言語コードでローカライズされます。

{
  "names": [
    {"en": "Nike"},
    {"en": "The Swoosh"},
    {"zh": "耐克"},
    {"ja": "ナイキ"}
  ]
}

言語ごとに複数のエントリが許可されます（エイリアス用）。

Keller Types

マーケティング理論からのブランドアーキテクチャ分類:

Type	Description	Example
`master`	ハウスの主要ブランド	Nike, Inc. の Nike
`sub_brand`	親ブランド名を運ぶ	Nike SB
`endorsed`	独立したアイデンティティ、親によって推奨	Air Jordan “by Nike”
`independent`	ハウスとは別に運営	Converse

Extended color roles

colors オブジェクトは 5 つの標準ロール（primary、secondary、accent、background、text）を持ちますが、ブランドはより細かい粒度のために追加のロールを提供でき、また提供すべきです。スキーマは additionalProperties を通じて任意の追加カラーロールを受け入れます。

{
  "colors": {
    "primary": "#FF6600",
    "secondary": "#0066CC",
    "background": "#FFFFFF",
    "text": "#1A1A1A",
    "heading": "#FF6600",
    "body": "#333333",
    "label": "#666666",
    "border": "#E5E5E5",
    "divider": "#F0F0F0",
    "surface_1": "#F9F9F9",
    "surface_2": "#F0F0F0"
  }
}

Role	Purpose
`heading`	見出しテキストの色（本文テキストと異なる場合）
`body`	本文テキストの色
`label`	ラベル/キャプションテキストの色
`border`	ボーダー/アウトラインの色
`divider`	ディバイダー/セパレーターの色
`surface_1`	主要サーフェス/カード背景
`surface_2`	副次サーフェス背景

これらの拡張ロールは、クリエイティブエージェントが推測せずにテキスト階層とサーフェスレベルを区別するのに役立ちます。

Visual guidelines

visual_guidelines オブジェクトは、生成クリエイティブシステムがオンブランドのアセットを一貫して生成するために使える構造化ルールを提供します。これらはブランド定数です — キャンペーンごとに変わりません。

ビジュアルガイドラインは基本的なアイデンティティフィールド（colors、fonts、logos）を補完します。colors はブランドパレットが何かを定義し、visual guidelines はそれをどう使うかを定義します。fonts はフォントファミリーを定義し、visual guidelines はタイプスケールを定義します。

Photography

ブランド写真が選択または生成されるときにどう見えるべきかを制御します。

{
  "photography": {
    "realism": "natural",
    "lighting": "soft daylight",
    "color_temperature": "warm",
    "contrast": "medium",
    "depth_of_field": "medium",
    "subject": {
      "people": {
        "age_range": "25-45",
        "diversity": "mixed",
        "mood": ["confident", "relaxed"]
      },
      "product_focus": "in-use",
      "setting": "outdoor"
    },
    "framing": {
      "subject_position": "center-left",
      "crop_style": "waist-up",
      "perspective": "eye-level"
    }
  }
}

Field	Type	Description
`realism`	enum	`natural`、`stylized`、`hyperreal`、`abstract`
`lighting`	string	ライティングスタイルの説明
`color_temperature`	enum	`warm`、`neutral`、`cool`
`contrast`	enum	`low`、`medium`、`high`
`depth_of_field`	enum	`shallow`、`medium`、`deep`
`subject`	object	被写体ガイドライン（people、product focus、setting）
`framing`	object	カメラフレーミングルール（position、crop、perspective）
`preferred_aspect_ratios`	array	優先アスペクト比（例: `["16:9", "4:5", "1:1"]`）
`tags`	array	追加のスタイル記述子

Graphic style

ブランドグラフィックとイラストのビジュアル言語を定義します。

{
  "graphic_style": {
    "style_type": "flat_illustration",
    "stroke_style": "rounded",
    "stroke_weight": "2px",
    "corner_radius": "12px"
  }
}

スタイルタイプ: flat_illustration、geometric、gradient_mesh、editorial_collage、hand_drawn、minimal_line_art、3d_render、isometric、photographic_composite。

Field	Type	Description
`style_type`	enum	`flat_illustration`、`geometric`、`gradient_mesh`、`editorial_collage`、`hand_drawn`、`minimal_line_art`、`3d_render`、`isometric`、`photographic_composite`
`stroke_style`	enum	`rounded`、`square`、`mixed`、`none`
`stroke_weight`	string	ストローク太さ（例: `2px`）
`corner_radius`	string	グラフィック/イラスト要素のコーナー半径（例: `12px`）。UI コンポーネントには `border_radius` を参照。
`tags`	array	追加のスタイル記述子

Shapes

ビジュアルアイデンティティの一部として使われるブランドシェイプ:

{
  "shapes": {
    "primary_shape": "circle",
    "secondary_shapes": ["rounded_rectangle", "diagonal_wave"],
    "usage": {
      "max_per_layout": 2,
      "overlap_allowed": true
    }
  }
}

Field	Type	Description
`primary_shape`	string	主要ブランドシェイプ（例: `circle`、`rounded_rectangle`、`hexagon`）
`secondary_shapes`	array	ブランド語彙の副次シェイプ
`usage.max_per_layout`	integer	レイアウトごとの最大の異なるシェイプ数
`usage.overlap_allowed`	boolean	シェイプが重なってよいか

Iconography

アイコンスタイルシステムと使用ルール:

{
  "iconography": {
    "style": "outline",
    "stroke_weight": "2px",
    "corner_style": "rounded",
    "usage": {
      "max_per_frame": 3,
      "size_ratio": "1:8"
    }
  }
}

Field	Type	Description
`style`	enum	`outline`、`filled`、`duotone`、`flat`、`glyph`、`hand_drawn`
`stroke_weight`	string	アイコンのストローク太さ（例: `2px`）
`corner_style`	enum	`rounded`、`square`、`mixed`
`usage.max_per_frame`	integer	クリエイティブフレームごとの最大アイコン数
`usage.size_ratio`	string	アイコン対レイアウトのサイズ比（例: `1:8`）

Composition

オーバーレイ、テクスチャ、背景のレイアウトルール:

{
  "composition": {
    "overlays": {
      "gradient_style": "linear",
      "gradient_direction": "45deg",
      "opacity": "70%"
    },
    "texture": {
      "style": "subtle_grain",
      "intensity": "low"
    },
    "backgrounds": {
      "types_allowed": ["solid_color", "gradient", "image"]
    }
  }
}

テクスチャスタイル: none、subtle_grain、noise、paper、fabric、concrete。強度: low、medium、high。背景タイプ: solid_color、gradient、blurred_photo、image、video、pattern、transparent。

Border radius

UI コンポーネントとレイアウト要素の名前付きボーダー半径プリセット。ボーダー半径は最も目立つブランド差別化要因の 1 つです — 大きな半径は温かく親しみやすく感じられ、小さいまたはゼロの半径は精密で編集的に感じられます。

{
  "border_radius": {
    "none": "0",
    "default": "12px",
    "small": "4px",
    "large": "20px",
    "pill": "999px"
  }
}

Field	Type	Description
`none`	string	明示的にシャープなコーナー（`0`）
`default`	string	UI コンポーネントのデフォルトボーダー半径（例: `8px`、`12px`）
`small`	string	コンパクト要素用の小さい半径（例: `4px`）
`large`	string	カードとコンテナ用の大きい半径（例: `16px`、`24px`）
`pill`	string	完全に丸い / ピル形状（例: `999px`）

5 つの標準レベルを超えて追加の名前付きプリセットを追加できます。

graphic_style.corner_radius はグラフィック/イラスト要素のデフォルト半径を定義します。border_radius は UI コンポーネントとレイアウト — ボタン、カード、入力、モーダル — の名前付きスケールを定義します。

Elevation

要素がサーフェスから浮き上がって見える方法を定義する名前付きシャドウレベル。ブランドはエレベーションをアイデンティティとして使います — ドラマチックな多層シャドウを好むものもあれば、単一の拡散シャドウを使うものもあります。

{
  "elevation": {
    "none": "none",
    "subtle": "0 1px 3px rgba(0,0,0,0.08)",
    "card": "0 4px 8px -1px rgba(0,0,0,0.1), 0 2px 4px -2px rgba(0,0,0,0.06)",
    "modal": "0 20px 25px -5px rgba(0,0,0,0.1), 0 8px 10px -6px rgba(0,0,0,0.06)"
  }
}

値は CSS box-shadow 構文を使います。生成システムはこれらを直接適用できます。

Field	Type	Description
`none`	string	シャドウなし（`none`）
`subtle`	string	インタラクティブ要素の軽い浮き上がり
`card`	string	カードレベルのエレベーション
`modal`	string	モーダル/オーバーレイのエレベーション

追加の名前付きレベル（例: dropdown、tooltip）を追加できます。

Spacing

一貫したレイアウトリズムのためのスペーシングシステム。ベースユニットと名前付きスケールにより、クリエイティブエージェントは推測せずに正しくスペースされたレイアウトを生成できます。

{
  "spacing": {
    "unit": "8px",
    "scale": {
      "xs": "4px",
      "sm": "8px",
      "md": "16px",
      "lg": "24px",
      "xl": "32px",
      "2xl": "48px"
    }
  }
}

Field	Type	Description
`unit`	string	このスケールが設計されたベースグリッドユニット（例: `8px`）。情報提供 — エージェントは名前付きスケール値を直接使うべき。
`scale`	object	名前付きスペーシングスケール（`xs` から `2xl`）

scale オブジェクトは標準サイズ（xs、sm、md、lg、xl、2xl）をサポートし、追加の名前付き値（例: 3xl、section）を含められます。

Graphic elements

ブランドアイデンティティの一部である再利用可能な装飾的または構造的なビジュアル要素 — 破れた紙の端、ウォーターマーク、ディバイダー、背景パターン:

{
  "graphic_elements": [
    {
      "name": "Paper Tear",
      "type": "frame",
      "description": "Torn paper edge used as section dividers and photo frames. Use primarily vertical orientation.",
      "orientation": "vertical",
      "colors": ["#a75230", "#f6f1f1", "#fba007"],
      "max_per_layout": 2
    },
    {
      "name": "Location Sketch Watermark",
      "type": "watermark",
      "description": "Light hand-drawn building sketch behind content, visible through the logo area",
      "colors": ["#a75230"]
    }
  ]
}

Field	Type	Required	Description
`name`	string	Yes	要素名
`type`	enum	No	`border`、`divider`、`frame`、`watermark`、`pattern`、`texture_overlay`、`decorative`
`description`	string	No	要素がレイアウトでどう使われるか
`orientation`	enum	No	`horizontal`、`vertical`、`any`
`colors`	array	No	この要素が現れてよい色
`max_per_layout`	integer	No	レイアウトごとの最大インスタンス数

Motion

動画、アニメーションディスプレイ、インタラクティブフォーマットのモーションとアニメーションルール:

{
  "motion": {
    "transition_style": "dissolve",
    "animation_speed": "moderate",
    "easing": "ease-in-out",
    "text_entrance": "fade",
    "pacing": "lingering",
    "kinetic_typography": false
  }
}

Field	Type	Description
`transition_style`	enum	`cut`、`dissolve`、`slide`、`wipe`、`zoom`、`fade`
`animation_speed`	enum	`slow`、`moderate`、`fast`
`easing`	string	デフォルトのイージング関数（例: `ease-in-out`、`spring`、`linear`）
`text_entrance`	enum	`fade`、`typewriter`、`slide_up`、`slide_left`、`scale`、`none`
`pacing`	enum	`lingering`、`moderate`、`fast_cuts`
`kinetic_typography`	boolean	アニメーション/キネティックタイポグラフィが許可されるか
`tags`	array	追加のモーションスタイル記述子

Logo placement

自動化されたクリエイティブ制作のためのロゴ配置とクリアスペースルール:

{
  "logo_placement": {
    "preferred_position": "bottom-left",
    "min_clear_space": "0.5x",
    "min_height": "40px",
    "background_contrast": "any"
  }
}

Field	Type	Description
`preferred_position`	enum	`top-left`、`top-center`、`top-right`、`bottom-left`、`bottom-center`、`bottom-right`、`center`
`min_clear_space`	string	ロゴ高さの倍数（例: `0.5x`、`1x`）または固定値（例: `16px`）としての最小クリアスペース
`min_height`	string	可読性のための最小ロゴ高さ（例: `40px`）
`background_contrast`	enum	`light_only`、`dark_only`、`any`

Logo selection slots

ライトロゴカード、ダークロゴカード、プロファイルマーク、CTV エンドカード、コブランドロックアップ、マーケットプレイスリスティングなどの特定のサーフェスに対して、レンダラーが正しいロゴバリアントを選ぶ必要がある場合に logos[].slots[] を使います。logos[].id は、可変のアセット URL に依存しない安定したターゲットをダウンストリームルールに与えます。

{
  "logos": [
    {
      "id": "primary_horizontal",
      "url": "https://assets.example.com/logos/primary.svg",
      "orientation": "horizontal",
      "background": "light-bg",
      "variant": "primary",
      "slots": ["logo_card_light", "nav_header", "marketplace_listing"]
    },
    {
      "id": "knockout_horizontal",
      "url": "https://assets.example.com/logos/knockout.svg",
      "orientation": "horizontal",
      "background": "dark-bg",
      "variant": "secondary",
      "slots": ["logo_card_dark", "ad_end_card"]
    }
  ]
}

正準クリエイティブフォーマットは、マニフェストアセットグループに依然として asset_group_id: "logo" を使います。プロダクトがそのスロットを format_options[].params.slots[].logo_slots[] で狭める場合、ビルダーは logos[].slots[] が要求されたスロットと交差する brand.json の logos[] から選択すべきです。フォーマットが required_logo_slots[] も宣言する場合、カバレッジの欠如は、黙って文章にフォールバックするのではなく、検証警告または承認マッピングとして表面化すべきです。 visual_guidelines.logo_usage_rules[] は、安定した logo_id に配置制約を適用できます。

{
  "visual_guidelines": {
    "logo_usage_rules": [
      {
        "logo_id": "primary_horizontal",
        "slots": ["logo_card_light", "marketplace_listing"],
        "minimum_size": { "height": "18px" },
        "clear_space": "1x cap height",
        "forbidden_contexts": ["photography_without_knockout"],
        "severity": "must"
      }
    ]
  }
}

Color constraints

アクセント専用の色、禁止された背景の組み合わせ、決して一緒に現れるべきでない色などの機械可読なカラー使用とペアリングルールのために visual_guidelines.color_constraints[] を使います。

{
  "visual_guidelines": {
    "color_constraints": [
      {
        "color": { "kind": "name", "name": "market_yellow" },
        "applies_to": ["accent"],
        "forbidden_on": [
          { "kind": "surface", "surface": "background" },
          { "kind": "surface", "surface": "text" }
        ],
        "never_pair_with": [{ "kind": "name", "name": "linen" }],
        "contexts": ["digital", "print", "ctv_end_card"],
        "severity": "must",
        "description": "Market yellow is accent only."
      }
    ]
  }
}

各 color_ref は明示的な kind 識別子を使います: kind: "name" は colors{} のキーをルックアップし、kind: "value" はリテラルの hex カラーを運び、kind: "surface" は background、text、logo_background などのレイアウトサーフェスを識別します。

Mark lockups

コブランド、パートナー、スポンサー、プログラム、または副次マークのレイアウトルールのために visual_guidelines.mark_lockups[] を使います。これらのフィールドは、順序、スペーシング、セパレーター、サイズ比のガイダンスをクエリ可能にしながら、光学的バランシングをレイアウト/レンダーレビューに残します。

{
  "visual_guidelines": {
    "mark_lockups": [
      {
        "lockup_type": "co_brand",
        "ordering": "brand_first",
        "brand_logo_id": "primary_horizontal",
        "contexts": ["partner_campaign", "sponsored_content"],
        "separator": {
          "type": "keyline",
          "color": { "kind": "name", "name": "text" },
          "width": "1px"
        },
        "min_gap": "1x clear space",
        "brand_min_optical_weight_ratio": 1,
        "partner_max_optical_weight_ratio": 1,
        "severity": "must"
      }
    ]
  }
}

Tooling notes: ingesting brand books

ブランドガイド PDF からドラフト brand.json を作成するツールは、アセット抽出とガイドライン解釈を分離すべきです。決定的な抽出を使って候補アセット ID を生成します。

写真、モックアップ、ラスターアイコン、例のための埋め込み PDF 画像
ベクターロゴ、マーク、カラースウォッチ、埋め込み画像ファイルでないロゴサンプルのためのレンダーページクロップ

次にマルチモーダルモデルを使って、それらの候補 ID を提案された logos[]、assets[]、colors、visual_guidelines ルールに分類します。モデルは既知の候補 ID にマップし戻すべきです。オリジナルのアセットバイトのソースとして扱うべきではありません。ドラフト取り込み記録は、提案されたロゴエントリから証拠を指せます。

{
  "asset_id": "candidate_logo_0007",
  "source_page": 15,
  "extraction_method": "rendered_page_crop",
  "proposed_logo": {
    "id": "primary_wordmark_dark_card",
    "variant": "wordmark",
    "background": "dark-bg",
    "slots": ["logo_card_dark", "marketplace_listing"]
  },
  "review_status": "needs_review"
}

レビュアーがクロップを確認し、正しいスロット/背景を割り当て、候補ファイルを耐久性のある HTTPS ロゴアセット URL に置き換えるまで、これらの候補を正準 logos[] として直接公開しないでください。ソース PDF がホストされたアセット、オペレーター認可、または商標証拠を欠く場合、それはスキーマギャップではなく取り込み警告です。

Public hosted asset promotion

AAO ホストのブランドアセットは、レビュアーまたは検証済み所有者がパブリックな brand.json 使用のためにプライベートアップロードを承認したケース用です。抽出のみでバイトが公開されることは決してありません。プライベート分析アーティファクトはパブリックアセット行とは別のままで、brand.json は承認後にのみパブリック URL を受け取ります。推奨フロー:

アップロードまたは抽出されたファイルを分析のためにプライベートに保存します。
正確な提案された brand.json diff とともに候補をオペレーターに提示します。
プロモーション前に明示的な承認を要求します。
承認されたバイトを安定したパブリック HTTPS URL にプロモートします。
そのパブリック URL を logos[] に書き込みます。

AAO ホストの URL はこの形状を使います。

https://agenticadvertising.org/assets/brands/{domain}/{assetId}.{ext}

例:

{
  "logos": [
    {
      "id": "primary_wordmark",
      "url": "https://agenticadvertising.org/assets/brands/acme.example/{assetId}.png",
      "variant": "wordmark",
      "slots": ["logo_card_light"],
      "width": 512,
      "height": 128
    }
  ]
}

パブリックロゴプロモーションは、公開された brand.json の外部で来歴メタデータを保持しなければなりません: オリジナルのファイル名、既知の場合のアップローダーユーザーと組織、ソースフロー、作成時刻、コンテンツタイプ、寸法、ハッシュ、パスが所有者証明・委任・コミュニティ提出のいずれか。モデレーションと所有者承認の状態は運用メタデータです。コンシューマーがそれらをパブリック URL からパースする必要はないはずです。初期のプロモーション制限は意図的に保守的です: ロゴに必要な画像 MIME タイプのみを受け入れ（image/png、image/jpeg、image/webp、image/gif、およびサニタイズされた image/svg+xml）、アップロードを 5 MB に制限し、公開前にラスター寸法を検出し、SVG を積極的にサニタイズするか、サニタイザーがサーフェスで有効になるまで拒否します。プライベート署名付き URL、ファイルビューアーリンク、分析専用のオブジェクトパスは、公開された brand.json に現れてはなりません。削除は URL を無関係なバイトに再利用するのではなく、パブリックアセット行をトゥームストーンすべきです。置換は新しいアセット URL を作成し、brand.json をそれを指すよう更新すべきです。以前に公開された URL は、キャッシュ安定性のために古い承認済みバイトを提供し続けるか、1 対 1 の後継がある場合は置換にリダイレクトするか、法的/セキュリティのテイクダウン後に 404 を返してもよいですが、同じ ID の下で異なるアセットを黙って提供してはなりません。

Colorways

色がどう連携するかを定義する名前付きカラーペアリング。クリエイティブブリーフが、すべての色を指定せずに「私の primary カラーウェイを使う」と参照できるようにします。

{
  "colorways": [
    {
      "name": "primary",
      "foreground": "#FFFFFF",
      "background": "#FF6600",
      "accent": "#0066CC",
      "cta_foreground": "#FFFFFF",
      "cta_background": "#0066CC"
    },
    {
      "name": "inverted",
      "foreground": "#FF6600",
      "background": "#FFFFFF",
      "accent": "#0066CC",
      "border": "#FF6600"
    }
  ]
}

Field	Type	Required	Description
`name`	string	Yes	カラーウェイ名（例: `"primary"`、`"inverted"`、`"dark"`）
`foreground`	hex color	Yes	テキスト/前景色
`background`	hex color	Yes	背景色
`accent`	hex color	No	アクセント色
`cta_foreground`	hex color	No	CTA テキスト色
`cta_background`	hex color	No	CTA ボタン色
`border`	hex color	No	ボーダー色
`channels`	array	No	このカラーウェイが適用されるチャネル（例: `["online"]`、`["print", "pos"]`）。ユニバーサルなカラーウェイでは省略。

Type scale

異なるテキストロールのサイズとウェイトを定義するタイポグラフィスケール:

{
  "type_scale": {
    "base_width": "1080px",
    "heading": {
      "font": "primary",
      "size": "48px",
      "weight": "700",
      "line_height": "1.1"
    },
    "subheading": {
      "font": "primary",
      "size": "24px",
      "weight": "600",
      "line_height": "1.3"
    },
    "body": {
      "font": "secondary",
      "size": "16px",
      "weight": "400",
      "line_height": "1.5"
    },
    "caption": {
      "font": "secondary",
      "size": "12px",
      "weight": "400",
      "line_height": "1.4"
    },
    "cta": {
      "font": "primary",
      "size": "18px",
      "weight": "700",
      "text_transform": "uppercase",
      "letter_spacing": "0.05em"
    }
  }
}

font フィールドは、ブランドの fonts オブジェクトで定義されたフォントロール（"primary"、"secondary"）を参照するか、フォントファミリー名を直接指定できます。サイズがピクセルの場合、これらのサイズが設計された参照キャンバスを示すために base_width を使います。生成システムは他のキャンバスサイズについて比例的にスケールすべきです — 1080px 幅用に設計された 48px の見出しは、320px のモバイルリーダーボードで 14px にスケールします。

Asset libraries

管理されたアセットライブラリ（アイコンセット、イラストシステム、画像コレクション）への参照。URL は人間のアクセス用です — 人がブラウザで開けるブランドポータル、プレスキット、または DAM ランディングページ。

{
  "asset_libraries": [
    {
      "name": "Brand Illustrations v2",
      "type": "illustration_system",
      "url": "https://brand.example.com/illustrations",
      "description": "Flat illustration system with defined color guide",
      "color_guide": {
        "roles": ["base", "shadow_1", "shadow_2", "highlight_1", "highlight_2", "stroke"],
        "palettes": [
          {
            "name": "orange",
            "colors": {
              "base": "#FF6600",
              "shadow_1": "#CC5200",
              "shadow_2": "#993D00",
              "highlight_1": "#FF8533",
              "highlight_2": "#FFB380",
              "stroke": "#662900"
            }
          }
        ]
      }
    }
  ]
}

Field	Type	Required	Description
`name`	string	Yes	アセットライブラリの表示名
`type`	enum	Recommended	`icon_set`、`illustration_system`、`image_library`、`video_library`、`template_library`
`url`	string (URI)	Yes	アセットライブラリへの URL（人間のアクセス用）
`description`	string	No	ライブラリの内容と使用の説明
`color_guide`	object	No	ライブラリで使われるカラーロールとパレット

color_guide は、ライブラリで使われるカラーパレットを生成システムに提供します — ライブラリ自体にアクセスせずにオンブランドのイラストやアイコンを生成するのに有用です。

Restrictions

ビジュアルの禁止事項とガードレール — tone.donts のビジュアル版。生成システムに何を避けるべきかを伝えます。

{
  "restrictions": [
    "Never place text over the product",
    "Do not use black backgrounds",
    "No stock photography of people on phones",
    "No split-screen layouts"
  ]
}

Trademarks

登録商標は、ハウスレベル（コーポレートマーク — 例: Nike, Inc. が所有する NIKE）またはブランドレベル（ブランド固有のマーク — 例: Converse が所有する CONVERSE）に現れます。両方の配列が有効なクレームです。それらの間の解決は和集合です。

ライセンスイン / ライセンスアウト関係（MARRIOTT マークを使う Marriott フランチャイジー、領域ごとにライセンスされる音楽カタログなど）は、claim_type: "trademark" を伴う verify_brand_claim を通じて今日ブランドエージェント経由でクエリ可能です。標準的なライセンス関係のための静的な brand.json 公開サーフェス（所有権のための brand_refs[] と並行する）は、権利プロトコルチームとともに将来の RFC です。下記の静的 trademarks[] 配列は所有権のみをカバーします。ライセンスの姿勢はエージェントから来ます。

{
  "trademarks": [
    {
      "registry": "USPTO",
      "number": "12345678",
      "mark": "CONVERSE",
      "status": "active",
      "license_type": "owned",
      "countries": ["US"]
    }
  ]
}

Field	Type	Required	Description
`registry`	string	Yes	商標レジストリ（例: `USPTO`、`EUIPO`、`JPO`、`CNIPA`）
`number`	string	Yes	レジストリが発行した登録番号
`mark`	string	Yes	公開された登録マーク
`status`	enum	No	`active`、`pending`、`abandoned`、`cancelled`、`expired`。ステータス追跡が維持されていない場合、アクティブマークでは省略。
`license_type`	enum	No	`owned`（デフォルト）、`licensed_in`、`licensed_out`
`countries`	array	No	この登録が適用される ISO 3166-1 alpha-2 国コード。グローバル、またはレジストリの管轄が暗黙的な場合は省略。

クロス管轄の競合を持つホールドコ（異なる所有者の USPTO CONVERSE 対 EUIPO CONVERSE）は、各登録を別個のエントリとして公開し、countries を使ってマークが適用される場所をスコープすべきです。

Property definition

プロパティはブランドに関連付けられたデジタルタッチポイントです。

Field	Type	Required	Description
`type`	enum	Yes	プロパティタイプ（下記参照）
`identifier`	string	Yes	ドメインまたはアプリ ID
`store`	enum	No	アプリストア（`apple`、`google` など）
`region`	string	No	ISO 国コードまたは `global`
`primary`	boolean	No	これが主要プロパティか？
`relationship`	enum	No	このブランドがプロパティにどう関係するか: `owned`（デフォルト）、`direct`、`delegated`、`ad_network`。委任/ネットワークの値は、双方向検証のために adagents.json の `delegation_type` に一致します。`owned` は brand.json のみの所有権クレームです。アドネットワークを参照。

Property types

AdCP の property-type enum に一致します。

website
mobile_app
ctv_app
desktop_app
dooh
podcast
radio
streaming_audio

Property relationships

プロパティはデフォルトで owned です — ブランドがプロパティを直接運営します。所有していないインベントリを販売するネットワークと SSP について、relationship フィールドは商業的取り決めを宣言します。

Value	Meaning	Example
`owned`	ブランドがこのプロパティを所有・運営（デフォルト）	自身のウェブサイト
`direct`	第三者がテクノロジーを運営していても、ブランドが直接の販売パス	ベンダーのプラットフォームを使うパブリッシャーの社内広告チーム
`delegated`	ブランドがマネタイズを管理 — 広告販売を担当	フードブログを管理する Mediavine
`ad_network`	ブランドがネットワーク/エクスチェンジの一部として販売 — 唯一のパスではなく 1 つのパス	SSP としての PubMatic

これは sellers.json の AdCP 版です — オペレーターがどのパブリッシャーと連携するかの公開宣言です。委任またはネットワークパスについては、パブリッシャーが自身の adagents.json でエージェントの認可に一致する delegation_type を設定することで確認します。ファーストパーティインベントリについては、relationship: "owned" はオペレーターのインライン所有権宣言です。セルサイド実装は、オペレーターの brand.json クレームと、インベントリがパブリッシャー認可または委任の場合はパブリッシャーの一致する adagents.json 認可を必要とします。ステップバイステップのセルサイドパターンについてはセラーセットアップを、ネットワーク固有のガイダンスについてはアドネットワークを参照。

Resolution algorithm

ドメインを正準ブランドに解決するには:

https://{domain}/.well-known/brand.json を取得します。
バリアントを確認します:
- authoritative_location: その URL から取得し、ステップ 2 から続行します。
- house（文字列）: ハウスドメインから取得し、ステップ 2 から続行します。
- brand_agent: エージェント URL を返します — エージェントが権威を持ちます。
- House Portfolio（house オブジェクト + brands[] および/または brand_refs[]）: インライン子については、properties[] または id がクエリに一致するブランドを見つけます。ポインター子については、brand_refs[].domain をたどって一度解決します — たどったドキュメントは Brand Canonical Document でなければならず、決して別の House Portfolio であってはなりません（MUST）。
- Brand Canonical Document（トップレベルの id + names）: ドキュメントがブランドです。house_domain が存在する場合、ハウスの brand.json を取得して、その brand_refs[] での相互応答を検証します（相互アサーション）。ハウス側自体が House Redirect の場合、比較する前にハウス側のリダイレクトチェーンをたどります。ブランドに存在しない場合、コーポレートレベルのフィールド（例: data_subject_contestation）をハウスから読みます。コンプライアンスフィールドについては、ハウスとブランドの最も厳格なものを解決します（Mutual-assertion trust model を参照）。
正準ブランド情報を返します。

最大リダイレクト深さ: 3 ホップ。ブランド → ハウスのルックアップはシングルホップです（再帰的な親ウォークなし）。信頼セマンティクスについては Mutual-assertion trust model を参照。

Complete examples

Small Business

{
  "$schema": "https://adcontextprotocol.org/schemas/v3/brand.json",
  "version": "1.0",
  "house": {
    "domain": "bobsburgers.com",
    "name": "Bob's Burgers LLC"
  },
  "brands": [
    {
      "id": "bobs_burgers",
      "names": [{"en": "Bob's Burgers"}],
      "keller_type": "master",
      "properties": [
        {"type": "website", "identifier": "bobsburgers.com", "primary": true}
      ],
      "logos": [
        { "url": "https://bobsburgers.com/logo.svg", "tags": ["icon"] }
      ],
      "colors": { "primary": "#FF6B35" }
    }
  ]
}

Enterprise with Agent

{
  "$schema": "https://adcontextprotocol.org/schemas/v3/brand.json",
  "version": "1.0",
  "brand_agent": {
    "url": "https://brand-agent.enterprise.com/mcp",
    "id": "enterprise_brand_agent"
  },
  "contact": {
    "name": "Enterprise Brand Team",
    "email": "brand@enterprise.com"
  }
}

Multi-Brand Portfolio

{
  "$schema": "https://adcontextprotocol.org/schemas/v3/brand.json",
  "version": "1.0",
  "house": {
    "domain": "nikeinc.com",
    "name": "Nike, Inc.",
    "architecture": "hybrid"
  },
  "brands": [
    {
      "id": "nike",
      "names": [{"en": "Nike"}, {"zh": "耐克"}, {"ja": "ナイキ"}],
      "keller_type": "master",
      "properties": [
        {"type": "website", "identifier": "nike.com", "primary": true},
        {"type": "website", "identifier": "nike.cn", "region": "CN"},
        {"type": "mobile_app", "store": "apple", "identifier": "com.nike.omega"}
      ]
    },
    {
      "id": "air_jordan",
      "names": [{"en": "Air Jordan"}, {"en": "Jordan"}, {"en": "Jumpman"}],
      "keller_type": "endorsed",
      "parent_brand": "nike",
      "properties": [
        {"type": "website", "identifier": "jordan.com", "primary": true},
        {"type": "website", "identifier": "jumpman23.com"},
        {"type": "mobile_app", "store": "apple", "identifier": "com.nike.snkrs"}
      ]
    },
    {
      "id": "converse",
      "names": [{"en": "Converse"}],
      "keller_type": "independent",
      "properties": [
        {"type": "website", "identifier": "converse.com", "primary": true}
      ]
    }
  ],
  "contact": {
    "name": "Nike Brand Team",
    "email": "brand@nike.com"
  }
}

Talent Agency with Rights

ライセンス可能な権利を持つアスリートブランドを管理するタレントエージェンシー:

{
  "$schema": "https://adcontextprotocol.org/schemas/v3/brand.json",
  "version": "1.0",
  "house": {
    "domain": "lotientertainment.com",
    "name": "Loti Entertainment",
    "architecture": "house_of_brands"
  },
  "brands": [
    {
      "id": "daan_janssen",
      "names": [{"en": "Daan Janssen"}],
      "description": "Dutch Olympic speed skater, 2x gold medalist",
      "industries": ["sports"],
      "logos": [
        {
          "url": "https://cdn.lotientertainment.com/janssen/headshot.jpg",
          "variant": "primary"
        }
      ],
      "brand_agent": {
        "url": "https://rights.lotientertainment.com/mcp",
        "id": "loti_entertainment"
      },
      "rights_agent": {
        "url": "https://rights.lotientertainment.com/mcp",
        "id": "loti_entertainment",
        "available_uses": ["likeness", "voice", "endorsement"],
        "right_types": ["talent"],
        "countries": ["NL", "BE", "DE"]
      }
    }
  ]
}

rights_agent フィールドは、MCP 呼び出しなしにクローラーに何がライセンス可能かを伝えます — 利用可能な用途、権利タイプ、国。バイヤーエージェントは「音声ライセンスに利用可能なオランダのアスリート」をレジストリで検索し、インデックスされた brand.json データからマッチを見つけられます。

Regional Domain Redirect

nike.cn/.well-known/brand.json 上:

{
  "$schema": "https://adcontextprotocol.org/schemas/v3/brand.json",
  "house": "nikeinc.com",
  "region": "CN"
}

Caching

推奨キャッシュ TTL:

正準ファイル: 24 時間
リダイレクトファイル: 24 時間
失敗したルックアップ: 1 時間

Conformance

これらの不変条件は、バリデーターとクローラーによって強制されなければなりません（MUST）。JSON スキーマはそれらを直接表現できません。 ポートフォリオ不変条件

brand_id のクロス配列一意性。 特定の brand_id は、同じハウスの brands[] と brand_refs[] の両方に現れてはなりません（MUST NOT）。パブリッシャーは 1 つを選ばなければなりません。
brand_id の配列内一意性。 特定の brand_id は、同じハウスの brands[] 内で一意で、brand_refs[] 内で一意でなければなりません（MUST）。
domain の配列内一意性。 各 brand_refs[].domain は配列内で一意でなければなりません（MUST）。異なる brand_id 値で同じドメインを指す 2 つのエントリは未定義です — ハウスごと、ドメインごとに 1 つの正準ポインターしか存在できません。
house_domain の配置。 house_domain は brands[] 内のエントリに現れてはなりません（MUST NOT）。それは Brand Canonical Document のトップレベルフィールドです。インライン子は自身の親ポインターを運べません。

信頼不変条件

相互アサーションが関係信頼のエッジです。 コンシューマーは、一方的なクレームを通じて関係信頼（自動プロビジョニング、メンバー機能継承、課金可能なシート包含）を拡張してはなりません（MUST NOT）。相互アサーション（子の house_domain が名付けられたハウスの brand_refs[] エントリに一致）が正準の信頼エッジです。
アイデンティティは TLS のみ。 リーフブランド自身のアイデンティティ属性（logos、colors、tone、tagline、visual_guidelines）は、相互アサーション状態に関係なく、リーフの TLS 提供ドキュメントのみに基づいて権威を持ちます。リーフのみの関係クレームはリーフのアイデンティティを無効にしません。
ハウス側の House Redirect はたどらなければなりません（MUST）。 相互アサーションを検証するとき、名付けられたハウスの brand.json が House Redirect の場合、コンシューマーは brand_refs[] メンバーシップを比較する前にリダイレクトチェーン（3 ホップ制限まで）をたどらなければなりません（MUST）。そうでなければ、買収後のリーフが黙って信頼を失います。
スタンドアロンは第三者クレームに勝る。 house_domain のない Brand Canonical Document は、それについての任意の第三者ハウスの brand_refs[] クレームに関係なく、スタンドアロンです。リーフの沈黙が決定的です。（ここで一度述べられます。他の場所の記述的な文章はこの句に従います。）
managed_by はディレクトリフィールドであり、信頼フィールドではありません。 コンシューマーは信頼や認可の決定に managed_by を使ってはなりません（MUST NOT）。managed_by による集計（「BBH が管理するすべてを表示」）が意図された用途です — これは信頼アサーションではなく、ハウス横断の運用ディレクトリです。

解決不変条件

コンプライアンスフィールドは最も厳格なもの。 ガバナンスフィールド — data_subject_contestation、compliance_policies、policy_categories、オーディエンス除外、規制カテゴリフラグ、およびハウスも公開するブランドレベルの disclaimers[] を含む — について、解決される値はハウスレベルとブランドレベルの和集合/最も厳格なものです。ブランドレベルのパブリッシャーは、ハウスレベルのアサーションを弱めることに依存してはなりません（MUST NOT）。これは関係信頼とは異なります — 最も厳格なものは信頼ゲートではなく解決ルールです。
エッジエイジング。 相互アサーションのエッジはエイジングされるべきです（SHOULD）: コンシューマーは、パブリッシャー宣言の brand_refs[].effective_at（または、ない場合はコンシューマーの最初の観察）と最後の成功した再検証の間のギャップがコンシューマーの選んだ TTL を超えるとき、エッジを一方的として扱うべきです（SHOULD）。AAO の参照クローラーは 180 日でエイジングします。コンシューマーは異なる選択をしてもかまいません（MAY）。

自己修復

リーフのみのエッジは通知をトリガーすべきです（SHOULD）。 コンシューマーが X 上の相互エントリなしに house_domain: X を主張するリーフに遭遇したとき、コンシューマーは、ハウスチームが相互応答を完了できるよう X の contact.email に通知すべきです（SHOULD）。通知する当事者は、フラッディングを避けるために {leaf, house} ペアごとにレート制限しなければなりません（MUST）。
エージェント強化検証。 名付けられたハウスが supported_tasks で関連する claim_type（subsidiary / parent / property / trademark）とともに verify_brand_claim をアドバタイズするブランドエージェントを公開する場合、コンシューマーは、クロールベースの相互アサーション推論を実行することに加えてエージェントを呼び出すべきです（SHOULD）。信頼モデルは方向によって非対称です: 署名付き disputed / not_ours は任意の相互応答クレームをオーバーライドします（拒否は一方的）。署名付き owned / pending_review / transferring / licensed_* は相互アサーション検証を置き換えません — 相互側が関係信頼を拡張する前に依然として確認しなければなりません。両側がブランドエージェントを持つ場合、相互アサーションは 2 つの署名付きエージェント呼び出し（ハウスの subsidiary + リーフの parent）を通じて完了します。クロールパスは、エージェントが到達不能または unknown を返す場合のフォールバックです。メール通知の SHOULD は、ブランドエージェントのないハウスについて引き続き適用されます。完全な信頼表については Agent-augmented verification を参照。

Prior art

相互アサーションの信頼プリミティブは、IAB Tech Lab の ads.txt と sellers.json の相互公開モデル — およびパターンがウェブバンドルからモバイルアプリにきれいに移行することを証明した app-ads.txt 拡張 — を反映しています。バイヤーは、両側が well-known URL で関係を公開する場合にのみ、セラーのリセラーとして信頼されます。同じ信頼形状、同じ非暗号的な「誰が誰について何を主張するか」の検証、部分的な公開に対する同じ一方的/未検証へのフォールバック。デプロイされた耐久性のある業界パターンです。 well-known URL に加えた構造化 JSON リソースディスカバリーの形状は ads.txt より前からあります — IETF の類似物については WebFinger（RFC 7033）と host-meta（RFC 6415）を参照。brand.json は RFC 8615 を通じてこの慣例を借用します。 AdCP 内では、プロベナンス検証者コントラクト（セラー公開 / バイヤー表明 / セラー確認）が、異なるフィールドファミリーに対して同じ構築ファミリーを使います。

Best practices

シンプルに始める: 最小限の brand.json から始め、必要に応じて複雑さを追加する
子会社にはリダイレクトを使う: ブランドドメインをハウスドメインに指す
すべてのプロパティをリストする: 地域ドメイン、アプリ、レガシードメインを含める
名前を最新に保つ: ローカライズされた名前と一般的なエイリアスを含める
ビジュアルガイドラインは任意: 生成システムにオンブランドのアセットを一貫して生成させる必要があるときに追加する。カラーウェイと restrictions から始める — それらが最も高い即時のインパクトを持つ。
ポートフォリオをリーンに保つ: 多くのブランドを持つハウスポートフォリオでは、必要なブランドにのみビジュアルガイドラインを含める。大きなポートフォリオのすべてのブランドに完全なビジュアルガイドラインを付けると、ファイルサイズが大幅に増加する。

​Motivation

​File location

​Variants

​1. Authoritative Location Redirect

​2. House Redirect

​Redirect ergonomics

​3. Brand Agent

​4. House Portfolio

​5. Brand Canonical Document

​Mutual-assertion trust model

​Self-healing through notification

​Agent-augmented verification

​Field resolution

​Authorized Operator Resolution

​Acquisitions and reorganizations

​Adopting brand_refs[] for an existing portfolio

​Out of scope

​House definition

​Brand definition

​Names Array

​Keller Types

​Extended color roles

​Visual guidelines

​Photography

​Graphic style

​Shapes

​Iconography

​Composition

​Border radius

​Elevation

​Spacing

​Graphic elements

​Motion

​Logo placement

​Logo selection slots

​Color constraints

​Mark lockups

​Tooling notes: ingesting brand books

​Public hosted asset promotion

​Colorways

​Type scale

​Asset libraries

​Restrictions

​Trademarks

​Property definition

​Property types

​Property relationships

​Resolution algorithm

​Complete examples

​Small Business

​Enterprise with Agent

​Multi-Brand Portfolio

​Talent Agency with Rights

​Regional Domain Redirect

​Caching

​Conformance

​Prior art

​Best practices

Motivation

File location

Variants

1. Authoritative Location Redirect

2. House Redirect

Redirect ergonomics

3. Brand Agent

4. House Portfolio

5. Brand Canonical Document

Mutual-assertion trust model

Self-healing through notification

Agent-augmented verification

Field resolution

Authorized Operator Resolution

Acquisitions and reorganizations

Adopting brand_refs[] for an existing portfolio

Out of scope

House definition

Brand definition

Names Array

Keller Types

Extended color roles

Visual guidelines

Photography

Graphic style

Shapes

Iconography

Composition

Border radius

Elevation

Spacing

Graphic elements

Motion

Logo placement

Logo selection slots

Color constraints

Mark lockups

Tooling notes: ingesting brand books

Public hosted asset promotion

Colorways

Type scale

Asset libraries

Restrictions

Trademarks

Property definition

Property types

Property relationships

Resolution algorithm

Complete examples

Small Business

Enterprise with Agent

Multi-Brand Portfolio

Talent Agency with Rights

Regional Domain Redirect

Caching

Conformance

Prior art

Best practices