> ## 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.

# セラーセットアップ

> パブリッシャー、セールスエージェント、ネットワーク、SSP がセラーアイデンティティ、署名鍵ディスカバリー、サプライパス検証のため brand.json と adagents.json をどう一緒に使うか。

`brand.json` はアドバタイザーだけのものではありません。売り手側では、AdCP セールスパスを運用する組織の公開企業レコードです: 名前、ロゴ、ドメイン、セールスエージェント、署名鍵ディスカバリー。`adagents.json` はパブリッシャーの認可レコードです: どのプロパティが存在しどのエージェントがそれらを販売できるか。

バイヤーエージェントは両方のビューを必要とします。`brand.json` は「このセラーまたはプラットフォームは誰で、何を主張しているか?」に答えます。`adagents.json` は「パブリッシャーはこのエージェントにこの在庫を販売する認可を与えているか?」に答えます。

## 要件境界

実践的なルールは:

* **AdCP エージェントを運用する場合**、そのエージェントはオペレーターアイデンティティと署名鍵ディスカバリーを必要とします。運用組織の `brand.json` エントリーを公開し、エージェントを `agents[]` にリストし、`agents[].jwks_uri` またはデフォルト `/.well-known/jwks.json` を通じて公開鍵を露出します。
* **在庫を公開する場合**、パブリッシャー認可レコードが必要です。バイヤーがどのエージェントがどのプロパティを販売できるか検証できるよう、パブリッシャードメインで `adagents.json` を公開します。
* **在庫を公開しかつセールスエージェントを運用する両方の場合**、同じ組織/ドメインで両方を行います。
* **販売を別のオペレーターに委譲する場合**、あなたの `adagents.json` が認可のヒンジです。パブリッシャーアイデンティティ、ポートフォリオコンテキスト、ガバナンスのため自身の `brand.json` は依然として推奨されますが、委譲されたオペレーターの `brand.json` がバイヤーがインタラクトするセールスエージェントアイデンティティを運びます。

プロトコル要件は検証可能性です: 公開鍵は発見可能でなければならず、署名付きリクエストまたは webhook はそれらの鍵に対して検証されなければなりません。本番エージェントは秘密署名鍵を KMS/HSM またはマネージドシークレットシステムで保護すべきですが、AdCP は特定のベンダーやホスティングパターンを義務付けません。このページはディスカバリーと検証レコードをカバーします。鍵ストレージと署名の実装詳細は [リクエスト署名](/docs/building/by-layer/L1/request-signing) に存在します。

## 誰が何を公開するか

| Organization      | Publish `brand.json`? | Publish `adagents.json`? | Why                                                                                                                                                      |
| ----------------- | --------------------- | ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 直接販売するパブリッシャー     | Yes                   | Yes                      | パブリッシャーは在庫所有者と販売オペレーターの両方。バイヤーは同じ組織からアイデンティティ、販売エンドポイント、鍵、プロパティ認可を検証。                                                                                    |
| 販売を委譲するパブリッシャー    | 推奨                    | Yes                      | パブリッシャーの `adagents.json` が外部セールスエージェントを認可。その `brand.json` はバイヤーにパブリッシャー自身のアイデンティティとハウス/ポートフォリオコンテキストを与えるが、外部オペレーターの `brand.json` がセールスエージェントアイデンティティを運ぶ。 |
| ネットワーク、SSP、セールスレプ | Yes                   | 通常 no、プロパティも所有する場合を除く    | オペレーターの `brand.json` がそのセールスエージェント、署名鍵、代表されるプロパティを宣言。パブリッシャーが自身の `adagents.json` で関係を確認。                                                                 |

パブリッシャーと販売オペレーターが同じ会社の場合、両ファイルは同じドメインに存在できます。サードパーティプラットフォームがパブリッシャーのため販売する場合、オペレーターの `brand.json` はオペレータードメインに、パブリッシャーの `adagents.json` はパブリッシャードメインに存在します。

## 検証の仕組み

売り手側チェーンは双方向です:

1. セラーの `brand.json` が `agents[]` でセールスエージェントを宣言。
2. セラーの `brand.json` が `properties[]` で所有、直接販売、管理、または代表するプロパティを宣言。
3. パブリッシャーの `adagents.json` が `authorized_agents[]` で同じセールスエージェントを宣言。
4. 委譲またはネットワークパスには、`brand.json` の `relationship` 値がパブリッシャーの `adagents.json` の `delegation_type` に一致。ファーストパーティ在庫には、`relationship: "owned"` はインライン所有権で `delegation_type` カウンターパートを持たない。
5. エージェントが使う署名鍵はセラーの `brand.json` `agents[].jwks_uri` から発見可能。変更するセラー認可には、パブリッシャーも `adagents.json` `authorized_agents[].signing_keys[]` で許可された鍵をピン留め。

結果は検証可能なサプライパスです。オペレーターは公に「私はこのプロパティを販売する」と言う。パブリッシャーは公に「このオペレーターはそれを販売する認可を受けている」と言う。

## 直接パブリッシャー例

自身のセールスエージェントを持つパブリッシャーは `https://streamhaus.example/.well-known/brand.json` で `brand.json` を公開します:

```json theme={null}
{
  "$schema": "https://adcontextprotocol.org/schemas/v3/brand.json",
  "version": "1.0",
  "id": "streamhaus",
  "url": "https://streamhaus.example",
  "names": [{ "en_US": "StreamHaus" }],
  "industries": ["media"],
  "properties": [
    {
      "type": "ctv_app",
      "identifier": "com.streamhaus.ctv",
      "relationship": "owned"
    }
  ],
  "agents": [
    {
      "type": "sales",
      "id": "streamhaus_sales",
      "url": "https://ads.streamhaus.example/mcp",
      "jwks_uri": "https://ads.streamhaus.example/.well-known/jwks.json"
    }
  ]
}
```

同じパブリッシャーが `https://streamhaus.example/.well-known/adagents.json` で `adagents.json` を公開します:

```json theme={null}
{
  "$schema": "https://adcontextprotocol.org/schemas/v3/adagents.json",
  "contact": {
    "name": "StreamHaus",
    "email": "adops@streamhaus.example",
    "domain": "streamhaus.example"
  },
  "properties": [
    {
      "property_id": "streamhaus_ctv",
      "property_type": "ctv_app",
      "name": "StreamHaus CTV App",
      "publisher_domain": "streamhaus.example",
      "identifiers": [{ "type": "bundle_id", "value": "com.streamhaus.ctv" }]
    }
  ],
  "authorized_agents": [
    {
      "authorization_type": "property_ids",
      "url": "https://ads.streamhaus.example/mcp",
      "authorized_for": "StreamHaus direct CTV inventory",
      "property_ids": ["streamhaus_ctv"],
      "signing_keys": [
        {
          "kid": "streamhaus-sales-prod-2026",
          "kty": "OKP",
          "alg": "EdDSA",
          "crv": "Ed25519",
          "x": "w8zcY1LZqV4n1oKbfyq3n2q3sL2uV3z7kEw1m9Qjv4A",
          "use": "sig"
        }
      ]
    }
  ]
}
```

バイヤーは、`brand.json` の `agents[].url` が `adagents.json` の `authorized_agents[].url` に一致すること、StreamHaus が主張するプロパティを所有すること、署名付き変更レスポンスが `signing_keys[]` で StreamHaus がピン留めした鍵を使うことを検証します。

## 委譲セラー例

ネットワークが別のパブリッシャーの在庫を販売するとき、ネットワークは自身の `brand.json` を公開します:

```json theme={null}
{
  "$schema": "https://adcontextprotocol.org/schemas/v3/brand.json",
  "version": "1.0",
  "id": "northwind_media",
  "url": "https://northwind.example",
  "names": [{ "en_US": "Northwind Media" }],
  "industries": ["advertising"],
  "properties": [
    {
      "type": "website",
      "identifier": "streamhaus.example",
      "relationship": "delegated"
    }
  ],
  "agents": [
    {
      "type": "sales",
      "id": "northwind_sales",
      "url": "https://northwind.example/mcp",
      "jwks_uri": "https://northwind.example/.well-known/jwks.json"
    }
  ]
}
```

StreamHaus は `https://streamhaus.example/.well-known/adagents.json` で関係を確認します:

```json theme={null}
{
  "$schema": "https://adcontextprotocol.org/schemas/v3/adagents.json",
  "contact": {
    "name": "StreamHaus",
    "email": "adops@streamhaus.example",
    "domain": "streamhaus.example"
  },
  "properties": [
    {
      "property_id": "streamhaus_web",
      "property_type": "website",
      "name": "StreamHaus",
      "publisher_domain": "streamhaus.example",
      "identifiers": [{ "type": "domain", "value": "streamhaus.example" }]
    }
  ],
  "authorized_agents": [
    {
      "authorization_type": "property_ids",
      "url": "https://northwind.example/mcp",
      "authorized_for": "StreamHaus inventory via delegated sales agreement",
      "property_ids": ["streamhaus_web"],
      "delegation_type": "delegated",
      "signing_keys": [
        {
          "kid": "northwind-sales-prod-2026",
          "kty": "OKP",
          "alg": "EdDSA",
          "crv": "Ed25519",
          "x": "Xe2lAKRJR_zr3FQRdSNwp3zsrv_IXnVCWJXDcWXwkLI",
          "use": "sig"
        }
      ]
    }
  ]
}
```

Northwind の `brand.json` だけでは認可ではありません。任意のオペレーターがプロパティを主張できます。パブリッシャーの一致する `adagents.json` エントリーが、主張を認可されたサプライパスに変えるものです。

### マルチテナントセールスエージェント

多くのパブリッシャーテナントのため 1 つのセールスエージェントデプロイをホストするオペレーターは、すべてのエントリーが `type: "sales"` でも、テナントまたはプロパティスコープエンドポイントごとに 1 つの `agents[]` エントリーを公開してもよい（MAY）。各エントリーは `type` ではなく具体的な `url` で選択されるので、パスルーテッドデプロイはテナントごとの JWKS シャードを公開できます。テナントまたはプロパティスコープは、`/mcp/{tenant}` のような認証される具体的なエージェント URL によって運ばれます。署名付きリクエストボディ内のテナント識別子から選択されません。エージェント URL は `agents[]` 配列内で一意でなければなりません（MUST）。

```json theme={null}
{
  "$schema": "https://adcontextprotocol.org/schemas/v3/brand.json",
  "version": "1.0",
  "agents": [
    {
      "type": "sales",
      "id": "sales_streamhaus",
      "url": "https://northwind.example/mcp/streamhaus",
      "jwks_uri": "https://northwind.example/.well-known/jwks/streamhaus.json"
    },
    {
      "type": "sales",
      "id": "sales_pinnacle_news",
      "url": "https://northwind.example/mcp/pinnacle_news",
      "jwks_uri": "https://northwind.example/.well-known/jwks/pinnacle_news.json"
    }
  ]
}
```

署名検証者は、リクエスト署名ディスカバリーアルゴリズムを使って認証されるエージェント URL から鍵を解決しなければなりません（MUST）: ちょうど 1 つの `brand.json` `agents[].url` エントリーに一致、そのエントリーの `jwks_uri` またはエージェント URL のオリジンのデフォルト `/.well-known/jwks.json` を使い、次に `keyid` を解決。重複する一致エントリーを曖昧として拒否しなければならず（MUST）、エージェント `type` だけで JWKS を選んではならず（MUST NOT）、どの鍵セットを信頼するか決めるためリクエストペイロード内で供給されたテナント識別子に依存してはなりません（MUST NOT）。

## セットアップチェックリスト

1. AdCP セールスエージェントを運用する各組織の `brand.json` を `https://{seller-domain}/.well-known/brand.json` で公開。
2. 組織が運用する各 AdCP セールスエンドポイントのため `agents[]` に `sales` エントリーを追加。
3. エンドポイントの JWKS を `agents[].jwks_uri` を通じて公開、またはエージェントオリジンのデフォルト `/.well-known/jwks.json` に依存。
4. 所有、直接、委譲、またはネットワーク代表のすべてのプロパティを正しい `relationship` で `properties[]` に追加。ファーストパーティ在庫には `owned` を使う。
5. 在庫を所有する各パブリッシャードメインで `adagents.json` を公開。
6. `authorized_agents[]` に、セラーのエージェント URL、認可スコープ、委譲またはネットワークパスの一致する `delegation_type`、任意の変更セラー認可の `signing_keys[]` をリスト。
7. 販売関係、エンドポイント、署名鍵が開始、変更、終了するとき両ファイルを揃えたまま保つ。

## 次に行く場所

* [brand.json リファレンス](/docs/brand-protocol/brand-json) — `agents[]`、`properties[]`、プロパティ関係のフィールドレベル詳細
* [adagents.json リファレンス](/docs/governance/property/adagents) — パブリッシャー側認可と `delegation_type`
* [セラー検証](/docs/verification/overview) — 完全な検証チェーンのバイヤー側ウォークスルー
* [セラー統合ガイド](/docs/building/operating/seller-integration) — 完全な AdCP セールスエージェント実装パス