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

# Targeting

> AdCP のターゲティング — 自然言語ブリーフがどのようにタクソノミーベースのオーディエンス選択を置き換えるか、地理的オーバーレイとインプレッション時のリアルタイム判断とともに解説します。

AdCP のターゲティング思想は **ブリーフベースのターゲティング** を中心に据えています。ターゲティング要件は自然言語のブリーフで伝え、パブリッシャーが必要なターゲティング機能をすべて含むプロダクトを返します。

## コア原則: ブリーフによるターゲティング

AdCP でターゲティングを指定する主な方法はキャンペーンブリーフです。複雑なターゲティングパラメータを設定する代わりに、バイヤーはオーディエンス要件を平易な言葉で記述します:

```json theme={null}
{
  "brief": "We want to reach millennial parents (ages 25-40) in major US metro areas who are interested in sustainable products. Focus on mobile and desktop during evening hours when families are planning purchases."
}
```

すると、パブリッシャーはこのオーディエンスにリーチするためのターゲティング機能を含むプロダクトを返します。ターゲティングのコストはメディアの価格に組み込まれています。

バイヤーが、セラーが提供する特定の選択可能なシグナルをパッケージレベルで制御したい場合は、パッケージ上で `targeting_overlay.signal_targeting_groups` を使います。バイ時の適格性は、選択したプロダクトのシグナルターゲティング契約に由来します: `signal_targeting_allowed`、存在する場合はインラインの `Product.signal_targeting_options`、インラインオプションを省略するホールセールプロダクトについてはセラーの `get_signals` フィード、そして `signal_targeting_rules` です。シグナルは名前付きのターゲティング可能な次元であり、`signal_ref` で参照します: プロダクトローカルなシグナルオプションには `scope: "product"`、データプロバイダーが公開する adagents.json の `signals[]` で定義されたシグナルには `data_provider_domain` を伴う `scope: "data_provider"`、adagents.json の `signals[]` で公開されていないソースネイティブなシグナルには `signal_source_url` を伴う `scope: "signal_source"` です。`signal_ref.scope` はバイ時の解決パスであってプロヴェナンス（出所）ではなく、権威ある拡充情報はセラー、データプロバイダー、またはソースのシグナル定義に存在します。この目的のために `audience_include` や `audience_exclude` を流用しないでください。それらのフィールドは `sync_audiences` を通じて登録されたファーストパーティオーディエンス専用です。

プロダクトは、すでにプロダクトに束ねられている、または束ねる予定のシグナルを `included_signals` で公開することもできます。それらのシグナルは記述的なプロダクトメタデータであってパッケージレベルのターゲティング制御ではなく、バイヤーは `signal_targeting_groups` でそれらをエコーしません。

## なぜブリーフベースなのか

### ターゲティング衝突を排除

* **単一のソース**: すべてのターゲティングはパブリッシャーのプロダクト定義に由来します
* **レイヤリングの衝突なし**: 複数のターゲティングシステムが競合することを避けます
* **価格の一貫性**: ターゲティングのコストは透明であり、メディア価格に含まれます

### 実装を簡素化

* **自然言語**: バイヤーは馴染みのある言葉でニーズを記述します
* **パブリッシャーの専門知識**: パブリッシャーは自身のインベントリとオーディエンス機能を最もよく知っています
* **複雑さの低減**: プラットフォーム固有のターゲティング構文を学ぶ必要がありません

### 正確な価格付けを実現

* **すべて込みの価格**: すべてのターゲティングコストがプロダクト価格に組み込まれています
* **サプライズなし**: バイヤーは完全なコストを事前に把握できます
* **市場主導**: 価格はターゲティングされたインベントリの真の市場価値を反映します

## TMP を用いたリアルタイム判断

インプレッション時に行わなければならないターゲティングの判断には、AdCP は **[トラステッドマッチプロトコル（TMP）](/docs/trusted-match)** を使います。TMP は、あらゆるサーフェスにわたって配信時に事前交渉されたパッケージを評価する、リアルタイムの実行レイヤーです。

TMP は、構造的に分離された二つの操作——コンテキストマッチ（コンテンツの関連性）とアイデンティティマッチ（ユーザーの適格性）——を通じて、各適格インプレッションに対するリアルタイムの視点をバイヤーに与えます。ユーザーのアイデンティティとページのコンテキストをバイヤーに同時に露出させることはありません。

**主な機能:**

* **パブリッシャー横断のフリークエンシーキャップ**: アイデンティティマッチのパスを通じて、複数のパブリッシャーにまたがるユーザーの露出を管理します
* **動的なオーディエンスターゲティング**: PII を共有せずに、インプレッション時にオーディエンスのメンバーシップを評価します
* **ブランド適合性の強制**: コンテキストマッチのパスを通じたリアルタイムのコンテンツ評価
* **ファーストパーティデータの活性化**: 顧客データをパブリッシャーに露出させずに使用します

**TMP を使う場面:**

* パブリッシャー横断のフリークエンシーキャップ
* サプレッションリスト（既存顧客、過去のコンバージョン者）
* ブリーフで表現できないオーディエンスセグメント
* 静的なルールを超えるリアルタイムのブランド適合性
* ウェブ、モバイル、CTV、AI アシスタント、リテールメディアにまたがる任意のインプレッション時の判断

完全な仕様とサーフェス固有の統合ガイドについては、[TMP のドキュメント](/docs/trusted-match)を参照してください。

## パブリッシャーはこうターゲティングを含めます

パブリッシャーはターゲティング機能を直接プロダクト定義に組み込みます:

### 地理的ターゲティング

プロダクトは地理的なカバレッジを指定します:

```
"Chicago metro premium display package" 
"US national mobile video inventory"
"California lifestyle sites network"
```

### デモグラフィックターゲティング

オーディエンスの特性がプロダクトに組み込まれます:

```
"Millennial-focused social media placements"
"Premium business professional network"
"Family-oriented content sites"
```

### コンテキストターゲティング

コンテンツとの整合がプロダクト記述に内在します:

```
"Sports content premium video inventory"
"Financial news site network"
"Entertainment property display package"
```

### デバイス・プラットフォームターゲティング

技術仕様がプロダクトフォーマットに含まれます:

```
"Mobile-optimized video formats"
"Connected TV premium inventory"
"Desktop display network"
```

## 代表的なターゲティング要件のブリーフ例

### 地理的ターゲティング

```json theme={null}
{
  "brief": "Target users in New York, Los Angeles, and Chicago metro areas with premium display advertising for our luxury retail brand."
}
```

### デモグラフィックターゲティング

```json theme={null}
{
  "brief": "Reach parents with children under 10 who are interested in educational content, focusing on weekend and evening viewing times."
}
```

### コンテキストターゲティング

```json theme={null}
{
  "brief": "Place financial services ads adjacent to business and investment content, targeting affluent professionals during business hours."
}
```

### 行動ターゲティング

```json theme={null}
{
  "brief": "Target users who have shown interest in sustainable products and eco-friendly brands, particularly those researching major purchases."
}
```

## プロダクト応答に含まれるターゲティング情報

パブリッシャーはプロダクトを返す際、バイヤーが必要とするターゲティング情報を含めます:

```json theme={null}
{
  "$schema": "/schemas/media-buy/get-products-response.json",
  "status": "completed",
  "cache_scope": "public",
  "products": [
    {
      "product_id": "premium_millennial_mobile",
      "name": "Premium Millennial Mobile Package",
      "description": "Mobile display inventory reaching adults 25-40 across lifestyle and entertainment apps in the top 25 US metro areas.",
      "publisher_properties": [
        {
          "publisher_domain": "pinnacle-media.example",
          "selection_type": "by_tag",
          "property_tags": ["lifestyle", "entertainment", "mobile_app"]
        }
      ],
      "channels": ["display"],
      "delivery_type": "guaranteed",
      "format_ids": [
        {
          "agent_url": "https://creative.adcontextprotocol.org",
          "id": "display_300x250_image"
        }
      ],
      "pricing_options": [
        {
          "pricing_option_id": "premium_mobile_cpm",
          "pricing_model": "cpm",
          "currency": "USD",
          "fixed_price": 8.50
        }
      ],
      "forecast": {
        "forecast_range_unit": "availability",
        "method": "modeled",
        "currency": "USD",
        "reach_unit": "individuals",
        "points": [
          {
            "metrics": {
              "audience_size": { "mid": 2500000 },
              "impressions": { "mid": 12000000 }
            }
          }
        ]
      },
      "included_signals": [
        {
          "signal_ref": {
            "scope": "product",
            "signal_id": "lifestyle_entertainment_interest"
          },
          "name": "Lifestyle and entertainment interest",
          "value_type": "binary",
          "description": "Seller-modeled users with recent lifestyle or entertainment content engagement."
        }
      ],
      "reporting_capabilities": {
        "available_reporting_frequencies": ["daily"],
        "expected_delay_minutes": 240,
        "timezone": "America/New_York",
        "supports_webhooks": false,
        "available_metrics": ["impressions", "clicks", "spend", "ctr"],
        "date_range_support": "date_range"
      },
      "brief_relevance": "Matches the requested millennial audience, mobile app environment, lifestyle/entertainment context, and major US metro coverage."
    }
  ]
}
```

## プロダクトフィルター vs ターゲティングオーバーレイ

一部のターゲティング次元は、`get_products` のフィルターと `create_media_buy` のターゲティングオーバーレイの両方に現れます。これらは異なる段階で異なる目的を果たします:

| フィルター（`get_products`） | オーバーレイ（`create_media_buy`）              | フィルター: 何をするか              | オーバーレイ: 何をするか     |
| --------------------- | --------------------------------------- | ------------------------- | ----------------- |
| `countries`           | `geo_countries` / `_exclude`            | これらの国に配信するプロダクトを表示        | これらの国でのみ配信        |
| `regions`             | `geo_regions` / `_exclude`              | これらの地域に配信するプロダクトを表示       | これらの地域でのみ配信       |
| `metros`              | `geo_metros` / `_exclude`               | これらのメトロに配信するプロダクトを表示      | これらのメトロでのみ配信      |
| `postal_areas`        | `geo_postal_areas` / `_exclude`         | これらの郵便番号に配信するプロダクトを表示     | これらの郵便番号でのみ配信     |
| `geo_proximity`       | `geo_proximity`                         | この地点の近くにインベントリを持つプロダクトを表示 | この地点の近くのユーザーにのみ配信 |
| `keywords`            | `keyword_targets` / `negative_keywords` | これらの検索語をサポートするプロダクトを表示    | これらの特定の語に入札       |

**フィルター**は、セルサイドエージェントにバイヤーにとって何が重要かを伝え、関連するプロダクトをキュレーションできるようにします。プロキシミティのフィルターがなければ、セラーは geo\_proximity をサポートしないプロダクトを推奨するかもしれず、バイヤーは `create_media_buy` までそのギャップに気づきません。

**オーバーレイ**は、実行時に正確な機能的制約を適用します。オーバーレイはセラーのアドサーバーが強制するものです。

値フィルター（`countries`、`regions`、`metros`、`postal_areas`、`geo_proximity`、`keywords`）はカバレッジエリアで絞り込みます——「これらの場所のインベントリを見せてほしい」。ケイパビリティフィルター（`required_geo_targeting`、`required_features`）はセラーが何を強制できるかで絞り込みます——「郵便番号レベルのターゲティングをサポートするセラーのみ」。これらは組み合わせられます: 特定のエリアのインベントリを、その粒度でターゲティングできるセラーから必要とする場合は両方を使います。

バイヤーへ: 発見時にフィルターを渡し、それからバイ時に同じ値（または洗練させた版）をオーバーレイとして適用します。オーバーレイのスキーマはより厳格である点に注意してください——例えば、`keyword_targets` は `match_type` を必須としますが、`keywords` フィルターはデフォルトで `broad` になります。

### 例: 発見からバイまで

```json theme={null}
// Step 1: get_products — signal intent with filters
{
  "brief": "Coffee shop promotion in downtown Seattle",
  "filters": {
    "geo_proximity": [{
      "lat": 47.6062,
      "lng": -122.3321,
      "label": "Downtown Seattle",
      "radius": { "value": 5, "unit": "mi" }
    }],
    "keywords": [{ "keyword": "coffee" }]
  }
}
```

```json theme={null}
// Step 2: create_media_buy — apply precise constraints as overlays
{
  "targeting": {
    "geo_proximity": [{
      "lat": 47.6062,
      "lng": -122.3321,
      "label": "Downtown Seattle",
      "radius": { "value": 5, "unit": "mi" }
    }],
    "keyword_targets": [{ "keyword": "coffee", "match_type": "broad" }]
  }
}
```

`keywords`（フィルター）が `keyword_targets`（オーバーレイ）になり、`match_type` が必須になる点に注意してください。

## ターゲティングオーバーレイを使う場面

`create_media_buy` と `update_media_buy` のターゲティングオーバーレイは**まれ**であり、以下の場合にのみ使うべきです:

### 地理的な制限

geo フィールドは**次の場合のみ**使います:

* **RCT テスト**: 特定の地理的分割を必要とするランダム化比較試験
* **規制コンプライアンス**: 地理的制限に関する法的要件
* **プロダクトの絞り込み**: プロダクトが複数の地域にまたがり、そのサブセットに制限する必要がある場合

**包含フィールド**（これらの場所に配信を制限）:

* `geo_countries`: ISO 3166-1 alpha-2 の国コード（例: `["US", "GB"]`）
* `geo_regions`: ISO 3166-2 の細分区分コード（例: `["US-CA", "GB-SCT"]`）
* `geo_metros`: 明示的なシステム（例: `nielsen_dma`、`uk_itl2`）を伴う構造化されたメトロエリア——すべてのパブリッシャーがメトロレベルのターゲティングをサポートするわけではありません
* `geo_postal_areas`: 明示的な国とシステム（例: `US` / `zip`、`GB` / `outward`、`ZA` / `postal_code`）を伴う構造化された郵便エリア——すべてのパブリッシャーが郵便レベルのターゲティングをサポートするわけではありません

**除外フィールド**（これらの場所を配信から除外）:

* `geo_countries_exclude`: `geo_countries` と同じ形式
* `geo_regions_exclude`: `geo_regions` と同じ形式
* `geo_metros_exclude`: `geo_metros` と同じ形式
* `geo_postal_areas_exclude`: `geo_postal_areas` と同じ形式

**注**: 包含と除外は組み合わせられます。メトロと郵便のターゲティングは分類システムの指定を必要とし、これにより国際的なサポートが可能になります。すべての地理的粒度がすべてのパブリッシャーでサポートされるわけではありません。国と地域が最も広くサポートされています。

### 年齢制限（コンプライアンス）

**法的コンプライアンス**の要件のために使います:

* **アルコール広告**: 米国で検証済みの 21 歳以上を要求
* **ギャンブル/ゲーミング**: 管轄区域に応じて検証済みの 18 歳以上または 21 歳以上を要求
* **カンナビス**: 現地の規制に応じて検証済みの年齢を要求

```json theme={null}
{
  "$schema": "/schemas/core/targeting.json",
  "age_restriction": {
    "min": 21,
    "verification_required": true,
    "accepted_methods": ["facial_age_estimation", "id_document", "world_id"]
  }
}
```

**検証方法**（[`age-verification-method.json`](https://adcontextprotocol.org/schemas/v3/enums/age-verification-method.json) で定義、ISO/IEC 27566-1 の年齢保証標準に基づく）:

* `facial_age_estimation` - AI ベースの年齢推定（Yoti など）
* `id_document` - 政府発行 ID のスキャン
* `digital_id` - 検証済みのデジタルアイデンティティクレデンシャル
* `credit_card` - 決済カードによる年齢ゲート
* `world_id` - World ID オーブ検証

**注**: 「推定」年齢（行動/プロフィールからの推測）は規制コンプライアンスには**受け入れられません**。プラットフォームはサポートする検証方法を `get_adcp_capabilities` で宣言します。

### デバイスプラットフォーム（技術的互換性）

**技術要件**のために使います:

* **アプリインストールキャンペーン**: iOS 専用アプリは `device_platform: ["ios"]` を要求
* **CTV キャンペーン**: 特定の TV オペレーティングシステムをターゲット

```json theme={null}
{
  "$schema": "/schemas/core/targeting.json",
  "device_platform": ["ios", "android"]
}
```

**利用可能なプラットフォーム**（[`device-platform.json`](https://adcontextprotocol.org/schemas/v3/enums/device-platform.json) で定義、CTV 向けに拡張された Sec-CH-UA-Platform 標準に基づく）:

* ブラウザ: `ios`、`android`、`windows`、`macos`、`linux`、`chromeos`
* CTV: `tvos`、`tizen`、`webos`、`fire_os`、`roku_os`
* その他: `unknown`

### デバイスタイプ（フォームファクター）

OS ではなくハードウェアのカテゴリで**パフォーマンス最適化**のためにターゲティングする場合に使います:

* **モバイルキャンペーン**: OS を問わずすべてのモバイルデバイスをターゲット
* **CTV キャンペーン**: すべてのプラットフォームにわたるコネクテッド TV をターゲット
* **フォームファクターの除外**: アプリインストールキャンペーンで CTV をスキップ

```json theme={null}
{
  "$schema": "/schemas/core/targeting.json",
  "device_type": ["mobile", "tablet"]
}
```

**除外** — 特定のフォームファクターを除外するには `device_type_exclude` を使います:

```json theme={null}
{
  "$schema": "/schemas/core/targeting.json",
  "device_type_exclude": ["dooh"]
}
```

**利用可能なタイプ**（[`device-type.json`](https://adcontextprotocol.org/schemas/v3/enums/device-type.json) で定義）:

* `desktop`、`mobile`、`tablet`、`ctv`、`dooh`、`unknown`

**デバイスタイプ vs デバイスプラットフォーム**: `device_type` はフォームファクター（モバイル、デスクトップ、CTV）をターゲットします。`device_platform` はオペレーティングシステム（iOS、Android、tvOS）をターゲットします。パフォーマンス最適化には `device_type` を、技術的互換性には `device_platform` を使います。

### 言語（ローカライゼーション）

**ローカライゼーション要件**のために使います:

* クリエイティブが特定の言語である
* キャンペーンが特定の言語話者をターゲットする

```json theme={null}
{
  "$schema": "/schemas/core/targeting.json",
  "language": ["es", "en"]
}
```

**形式**: ISO 639-1 の 2 文字言語コード（例: `en`、`es`、`fr`、`de`、`zh`）。

### フリークエンシーキャップ

二つのフリークエンシー制御は、独立して、または一緒に使えます:

**露出間のクールダウン** — `suppress` は連続した配信を防ぎます:

```json theme={null}
{
  "$schema": "/schemas/core/targeting.json",
  "frequency_cap": {
    "suppress": { "interval": 60, "unit": "minutes" }
  }
}
```

**エンティティごと・ウィンドウごとのインプレッションキャップ** — `max_impressions` + `per` + `window` が総露出を制限します:

```json theme={null}
{
  "$schema": "/schemas/core/targeting.json",
  "frequency_cap": {
    "max_impressions": 5,
    "per": "households",
    "window": { "interval": 7, "unit": "days" }
  }
}
```

両方を組み合わせられます。`per` フィールドは、リーチ最適化ゴールの `reach_unit` と同じエンティティタイプを使います——リーチキャンペーンの上にハードキャップを重ねる場合は、一致する値を使ってください。

### 地理的オーバーレイの例（RCT テスト）

RCT テストでは、包含ターゲティングよりも除外ターゲティングの方がしばしば単純です。含める何百もの DMA を列挙する代わりに、全国キャンペーンからホールドアウト市場を除外します。包含と除外を組み合わせた場合、除外フィールドは包含された集合から差し引かれます（例: 「米国からこれら 3 つの DMA を引いたもの」）:

```json theme={null}
{
  "packages": [
    {
      "product_id": "national_video",
      "targeting_overlay": {
        "geo_countries": ["US"],
        "geo_metros_exclude": [
          { "system": "nielsen_dma", "values": ["501", "803", "602"] }
        ]
      }
    },
    {
      "product_id": "national_video",
      "targeting_overlay": {
        "geo_metros": [
          { "system": "nielsen_dma", "values": ["501", "803", "602"] }
        ]
      }
    }
  ]
}
```

正確な市場を指定したい場合には、包含ターゲティングも同じように機能します:

```json theme={null}
{
  "packages": [
    {
      "product_id": "national_video",
      "targeting_overlay": {
        "geo_metros": [
          { "system": "nielsen_dma", "values": ["501", "602", "803"] }
        ]
      }
    },
    {
      "product_id": "national_video",
      "targeting_overlay": {
        "geo_metros": [
          { "system": "nielsen_dma", "values": ["504", "505", "506"] }
        ]
      }
    }
  ]
}
```

## ターゲティングオーバーレイを使うべきでないもの

**代わりにブリーフで表現してください:**

* **デモグラフィックの好み**（年齢、性別、収入）- ブリーフのテキストで「ミレニアルをターゲット」や「高収入世帯」
* **デバイスの好み** - ブリーフのテキストで「モバイルユーザー」や「CTV 視聴者」（`device_platform` オーバーレイは技術的互換性のためだけに使用）
* **コンテンツカテゴリ** - ブリーフのテキストで「スポーツコンテンツ」や「ニュースサイト」
* **一般的なオーディエンスの好み** - ブリーフのテキストで「自動車購入意向者」や「ラグジュアリー購入者」。バイヤーがこのパッケージに特定の名前付きシグナルを適用したい場合は、`signal_targeting_groups` を使います。
* **デイパートの好み** - ブリーフのテキストで「朝の通勤時間」や「プライムタイムの夜」

**オーバーレイ vs ブリーフ:**

| ユースケース                                  | オーバーレイ                                    | ブリーフ                               |
| --------------------------------------- | ----------------------------------------- | ---------------------------------- |
| コンプライアンスのための年齢（アルコール、ギャンブル）             | ✅ `age_restriction`                       |                                    |
| オーディエンスターゲティングのための年齢                    |                                           | ✅ "Target millennials"             |
| アプリ互換性のためのデバイス                          | ✅ `device_platform`                       |                                    |
| オーディエンスの好みのためのデバイス                      |                                           | ✅ "Mobile users"                   |
| クリエイティブのローカライズのための言語                    | ✅ `language`                              |                                    |
| オーディエンスの好みのための言語                        |                                           | ✅ "Spanish-speaking audiences"     |
| ファーストパーティ CRM オーディエンス（リターゲティング、サプレッション） | ✅ `audience_include` / `audience_exclude` |                                    |
| オーディエンスの好み（インタレストターゲティング）               |                                           | ✅ ブリーフで "Auto intenders"           |
| セラーが提供する特定の名前付きシグナル                     | ✅ `signal_targeting_groups`               |                                    |
| 検索/リテールメディアのキーワードターゲティング                | ✅ `keyword_targets` / `negative_keywords` |                                    |
| 広範なテーマ的意図（「靴を探している人」）                   |                                           | ✅ "Reach in-market shoe shoppers"  |
| 特定座標への近接（都市から車で 2 時間以内）                 | ✅ `geo_proximity`                         |                                    |
| 近隣のオーディエンス（「コーヒーショップの近くの人」）             |                                           | ✅ "Reach people near coffee shops" |

**なぜ好みにはブリーフの方が良いのか:**

* 自然言語は意図をより明確に捉えます
* パブリッシャーは自身のインベントリを知っており、効果的にターゲティングできます
* チャネル固有の複雑さを避けられます（DOOH にブラウザはありません）
* エッジケースの少ない、よりシンプルな API

## 利用可能なターゲティングオーバーレイパラメータ

地理的ターゲティングは、すべての geo 次元について包含（〜に制限）と除外（〜から除外）の両方をサポートします。包含フィールドと除外フィールドは組み合わせられます——例えば、ある国を含めつつ、その中の特定のメトロを除外できます。

### 除外のセマンティクス

**包含なしの除外。** 除外フィールドが対応する包含フィールドなしに存在する場合、除外はプロダクトの完全な地理的カバレッジに適用されます。例えば、プロダクトが米国全体をカバーし、バイヤーが `geo_metros_exclude` のみを指定した場合、除外されたメトロがプロダクトの全国的なフットプリントから取り除かれます。

**レベル横断の解決。** 地理的レベルは階層を成します: 国 > 地域 > メトロ > 郵便。セラーは、より高いレベルでの除外がより具体的なレベルでの包含より優先されるように、階層的な衝突を解決すべきです（SHOULD）。例えば、`geo_countries_exclude: ["US"]` と `geo_regions: ["US-CA"]` の組み合わせは、米国への配信なしという結果になるべきです——国レベルの除外が優先されます。

**同一値の重複。** セラーは、同じ値が同じレベルの包含フィールドと除外フィールドの両方に現れるリクエスト（例: `geo_countries: ["US"]` と `geo_countries_exclude: ["US"]`）を拒否し、説明的なエラーを返すべきです（SHOULD）。

**ケイパビリティ。** `get_adcp_capabilities` で地理的ターゲティングのサポートを宣言するセラーは、そのレベルで包含と除外の両方をサポートすべきです（SHOULD）。セラーが一方向のみをサポートする場合、サポートしないフィールドを黙って無視するのではなく、バリデーションエラーを返さなければなりません（MUST）。

### geo\_countries

* **説明**: 特定の国に配信を制限する
* **形式**: ISO 3166-1 alpha-2 の国コード
* **例**: `["US", "CA"]`、`["GB", "FR", "DE"]`
* **ユースケース**: 規制コンプライアンス、国別キャンペーン

### geo\_countries\_exclude

* **説明**: 特定の国を配信から除外する
* **形式**: ISO 3166-1 alpha-2 の国コード
* **例**: `["RU", "CN"]`
* **ユースケース**: 規制コンプライアンス、制裁

### geo\_regions

* **説明**: 特定の地域/州に配信を制限する
* **形式**: ISO 3166-2 の細分区分コード
* **例**: `["US-CA", "US-NY"]`、`["GB-SCT", "GB-ENG"]`
* **ユースケース**: 州レベルのコンプライアンス、地域テスト

### geo\_regions\_exclude

* **説明**: 特定の地域/州を配信から除外する
* **形式**: ISO 3166-2 の細分区分コード
* **例**: `["US-CA"]`、`["CA-QC"]`
* **ユースケース**: 規制コンプライアンス（例: 州ごとのカンナビス規制）、RCT ホールドアウト地域、プロダクトが利用できない地域

### geo\_metros

* **説明**: 特定のメトロエリアに配信を制限する
* **形式**: それぞれ `system` と `values` を持つオブジェクトの配列
* **システム**: `nielsen_dma`（米国）、`uk_itl1` / `uk_itl2`（英国）、`eurostat_nuts2`（EU）、`custom`
* **例**: `[{ "system": "nielsen_dma", "values": ["501", "803"] }]`
* **ユースケース**: ローカルキャンペーン、メトロレベルの RCT テスト
* **注**: セラーはサポートするシステムを `get_adcp_capabilities` で宣言しなければなりません

### geo\_metros\_exclude

* **説明**: 特定のメトロエリアを配信から除外する
* **形式**: それぞれ `system` と `values` を持つオブジェクトの配列
* **例**: `[{ "system": "nielsen_dma", "values": ["602"] }]`
* **ユースケース**: RCT ホールドアウト市場、競合除外ゾーン、プロダクトが利用できない市場
* **注**: セラーはサポートするシステムを `get_adcp_capabilities` で宣言しなければなりません

### geo\_postal\_areas

* **説明**: 特定の郵便エリアに配信を制限する
* **形式**: それぞれ `country`、`system`、`values` を持つオブジェクトの配列
* **システム**: `zip`、`zip_plus_four`、`outward`、`full`、`fsa`、`plz`、`code_postal`、`postcode`、`pin`、`postal_code` などの国ローカルな値
* **例**: `[{ "country": "US", "system": "zip", "values": ["10001", "10002"] }]`
* **ユースケース**: ハイパーローカルキャンペーン、郵便レベルの制限
* **注**: セラーはサポートするシステムを `get_adcp_capabilities` で宣言しなければなりません。3.x への移行期間中は、`us_zip` のような非推奨の国融合システムが互換性と SDK のバックフィルのために引き続き受け入れられます。

### geo\_postal\_areas\_exclude

* **説明**: 特定の郵便エリアを配信から除外する
* **形式**: それぞれ `country`、`system`、`values` を持つオブジェクトの配列
* **例**: `[{ "country": "US", "system": "zip", "values": ["90210"] }]`
* **ユースケース**: RCT ホールドアウトの郵便番号、配信制限エリア
* **注**: セラーはサポートするシステムを `get_adcp_capabilities` で宣言しなければなりません。非推奨のレガシー形式は 3.x への移行期間中は引き続き受け入れられます。

### axe\_include\_segment

* **説明**: 包含ターゲティング用のセグメント ID（レガシーの AXE フィールド）
* **形式**: 文字列のセグメント識別子
* **例**: `"seg_auto_intenders_q1"`、`"audience_lapsed_buyers_30d"`
* **ユースケース**: 動的なオーディエンスターゲティング、ファーストパーティデータの活性化
* **注**: このフィールドはレガシーの AXE 統合に由来します。新しい実装では [TMP](/docs/trusted-match) を使うべきです。そこではオーディエンスターゲティングはアイデンティティマッチのパスを通じて扱われます。

### axe\_exclude\_segment

* **説明**: 除外ターゲティング用のセグメント ID（レガシーの AXE フィールド）
* **形式**: 文字列のセグメント識別子
* **例**: `"seg_existing_customers"`、`"audience_past_converters"`
* **ユースケース**: 顧客サプレッション、フリークエンシー管理
* **注**: このフィールドはレガシーの AXE 統合に由来します。新しい実装では [TMP](/docs/trusted-match) を使うべきです。そこではサプレッションはアイデンティティマッチのパスを通じて扱われます。

### audience\_include

* **説明**: これらのファーストパーティ CRM オーディエンスのメンバーであるユーザーに配信を制限します。アップロードされたリスト上の人だけが広告を見る資格を持ちます。
* **形式**: [`sync_audiences`](/docs/media-buy/task-reference/sync_audiences) からの `audience_id` 文字列の配列
* **例**: `["lapsed_subscribers", "high_value_prospects"]`
* **ユースケース**: 既知ユーザーへのリターゲティング、既存メンバーをターゲットするロイヤルティキャンペーン、クローズドプラットフォーム（LinkedIn、Meta、TikTok、Google Ads）での CRM ベースの包含
* **類似/拡張のためではない**: あるオーディエンスに*似た*新しいユーザーを見つけるには、キャンペーンブリーフでその意図を記述します（「既存顧客のような人にリーチ」）——セラーが拡張戦略を扱います
* **前提条件**: オーディエンスは使用前に `sync_audiences` を通じて登録され `ready` になっていなければなりません
* **注**: セラーは `get_adcp_capabilities` でサポートを宣言しなければなりません

### audience\_exclude

* **説明**: これらのファーストパーティ CRM オーディエンスのメンバーであるユーザーへの配信を抑制します。マッチしたユーザーは他のターゲティングに関わらず除外されます。
* **形式**: [`sync_audiences`](/docs/media-buy/task-reference/sync_audiences) からの `audience_id` 文字列の配列
* **例**: `["existing_customers", "recent_purchasers"]`
* **ユースケース**: 獲得キャンペーンでの顧客サプレッション、最近のコンバージョン者の除外、オプトアウトしたユーザーの抑制
* **前提条件**: オーディエンスは使用前に `sync_audiences` を通じて登録され `ready` になっていなければなりません
* **注**: セラーは `get_adcp_capabilities` でサポートを宣言しなければなりません

### signal\_targeting\_groups

* **説明**: セラーが提供するデータシグナルの基本的なブール型のグルーピング。単純な包含のみのシグナルターゲティングと、`(A OR B) AND NOT (C OR D)` のようなグループ化された包含/除外の表現の両方に使います。
* **ディスカバリー**: ホールセールプロダクトは `signal_targeting_allowed: true` を設定してインラインの `signal_targeting_options` を省略でき、バイヤーはその場合 `get_signals` を選択可能なシグナルフィードとして使います。プロダクトは、プロダクト固有の価格、活性化ハンドル、デフォルト、グルーピングのヒント、またはブリーフ/refine 応答向けの関連サブセットが必要な場合に、インラインの `signal_targeting_options` を返します。
* **形式**: 必須のトップレベル `operator: "all"` と `groups` 配列を持つオブジェクト。v1 では `all` のみをサポートしますが、トップレベルのオペレーターは常に存在します。
* **子グループ**: 各子グループは `operator: "any"` または `operator: "none"` と、パッケージシグナルターゲティングオブジェクトの `signals` 配列を持ちます。各シグナルは `signal_ref`、`value_type`、値フィールド、加えて任意のコマーシャルおよび活性化ハンドルを持ちます。
* **レガシーのフラットターゲティング**: `targeting_overlay.signal_targeting` は、古いクライアント向けに SignalRef の移行ウィンドウ中はスキーマ的に有効なままですが、非推奨です。新しいパッケージレベルのシグナル選択は `signal_targeting_groups` を使い、セラーが包含/除外グループ、プロダクトルール、シグナルごとの価格を一貫して適用できるようにします。
* **セマンティクス**: `any` はユーザーがそのグループ内の少なくとも一つのシグナルにマッチしなければならないことを意味します。`none` はユーザーがそのグループ内のどのシグナルにもマッチしてはならないことを意味します。トップレベルの `all` により、すべての子グループが通過しなければなりません。単純な包含のみのターゲティングには、`operator: "any"` の子グループを一つ送ります。
* **解決モデル**: `signal_targeting_rules.resolution_model` は、セラーが選択されたシグナルをインベントリにどう適用するかをバイヤーに伝えます。`direct_targeting` は、選択されたシグナルがパッケージのターゲティング述語のように振る舞うことを意味します。`seller_planned` は、選択されたシグナルが、プロダクト固有のインベントリ、タイミング、可用性、リーチ、ペーシングの制約に対するセラー管理のプランニングへの入力であることを意味します。バイヤーは、選択されたオーディエンスをより低レベルのインベントリやスケジュールの決定に分解しようとすべきではありません。
* **選択グループ**: プロダクトが `signal_targeting_rules.selection_group_rules` を宣言する場合、各子グループはちょうど一つの `selection_group` と一つのターゲティングモードのシグナルを含まなければならず（MUST）、バイヤーは各 `(selection_group, targeting_mode)` ペアにつき最大一つの子グループを送らなければなりません（MUST）。セラーは、異なる選択グループのルールを同じ `any` または `none` グループに組み合わせる、重複した、混在した、または折りたたまれた子グループを拒否しなければなりません（MUST）。`selection_group` はプロダクトが定義する合成可能性のバケットであって、バックエンドのアイデンティティタイプではありません: 例えば、GAM ベースのセラーは、オーディエンスセグメントとキーバリューの両方を通常の `signal_ref` オプションとして公開し、それらが自由に OR 結合できるときは一つの `selection_group` を、別々の AND 節としてトラフィックしなければならないときは別々の `selection_group` を使うことができます。
* **価格**: 選択したプロダクトの `signal_targeting_options` エントリが `pricing_options` を持つ場合は `pricing_option_id` を含めます。シグナルがプロダクト価格に束ねられているか、追加コストがない場合にのみ省略します。`signal_targeting_options` のプロダクトスコープの価格は、そのプロダクトについて権威があります。プロダクトオプションにプロダクト固有の価格がない場合、セラーは `get_signals` で公開されるデフォルトの価格を使ってもかまいません（MAY）。
* **シグナル参照**: プロダクトローカルなシグナルオプションには `signal_ref: { "scope": "product", "signal_id": "..." }` を使います。データプロバイダーが公開する adagents.json の `signals[]` で定義されたシグナルには `signal_ref: { "scope": "data_provider", "data_provider_domain": "...", "signal_id": "..." }` を使います。`signal_ref` はシグナル定義を識別します。`signal_agent_segment_id` は、プロダクトオプションが公開する場合に、解決済みのセグメントまたは実行ハンドルを識別します。公開された `signal_agent_segment_id` はパッケージエントリでそのままエコーし、カテゴリ値からアイデンティティを再構築するよりもそれを優先してください。プロバイダーは、リアルタイムの雨と予報の高降水量のような定義を区別するために、ハンドルを名前空間で分けられるからです。プロダクトオプションが `activation_status: "requires_activation"` を持つ場合、それは `signal_agent_segment_id` を含まなければなりません（MUST）。まずシグナルを活性化し、それからセラーが要求する場合は `activation_key` を含めます。
* **プロバイダー公開シグナル**: プロバイダー公開シグナルについては、`signal_ref.data_provider_domain` が上流のデータプロバイダーを識別し、`signal_ref.signal_id` が公開シグナル定義を識別します。バイヤーは、プロバイダーの `adagents.json` の `authorized_agents` エントリにセラーがあるかを確認することで、セラーがそのシグナルを提供する権利を検証できます。
* **プロダクトゲーティング**: セラーは次の場合にシグナルエントリを拒否すべきです（SHOULD）: プロダクトがそのシグナルをインラインまたは `get_signals` を通じて公開していない、パッケージレベルの選択について `signal_targeting_allowed` が false、シグナルがプロダクトの `signal_targeting_rules` に違反している、シグナルの `allowed_targeting_modes` が要求された子グループのオペレーターを許可しない、シグナルがアカウントに対してアクティブでない、または要求された値がシグナル定義の範囲外である。`allowed_targeting_modes: ["include"]` は `any` グループに、`["exclude"]` は `none` グループにマップされます。バイナリのパッケージシグナルエントリは `value: true` を使います。除外には `value: false` ではなく親の `none` グループを使います。シグナルターゲティングの制限はプロダクトスコープであり、セラー全体の `get_adcp_capabilities` では宣言されません。プロダクトは異なるアドサーバーやプラットフォームに支えられている可能性があるからです。`selection_mode` が `fixed` の場合、バイヤーは `signal_targeting_groups` への編集を省略すべきです（SHOULD）。セラーは固定/デフォルトの選択を適用し、結果のパッケージ状態でそれらをエコーしなければなりません（MUST）。
* **更新**: `targeting_overlay` は `create_media_buy` と `update_media_buy` で共有されるため、選択されたシグナル、グループ表現、または `pricing_option_id` が価格付けされたエンベロープを変更する場合、セラーはフライト途中のシグナルグループの変更を `REQUOTE_REQUIRED` で拒否してもかまいません（MAY）。
* **ファーストパーティオーディエンスのためではない**: `sync_audiences` からのバイヤーがアップロードしたオーディエンスには `audience_include` / `audience_exclude` を使います。

バックエンドのターゲティングプリミティブは意図的に `signal_ref` の背後に隠されています。バイヤーは「オーディエンスセグメント」と「キーバリュー」のために別々のアイデンティティシステムを必要とすべきではありません。選択したプロダクトの `signal_targeting_rules` が、それらのオプションを一緒に合成できるかどうかを記述します。プロダクトが `gam_audience_segments` グループと `gam_key_values` グループの両方を `targeting_mode: "include"` で公開する場合、バイヤーはトップレベルの `all` の下に二つの `any` 子グループを合成するのであって、一つの折りたたまれた混在グループにはしません。

線形放送スケジュールのような、インベントリとオーディエンスのプランニングが不可分なプロダクトについては、セラーは `resolution_model: "seller_planned"` を使います。必須のオーディエンス選択は依然として `selection_mode: "required"` または必須の `selection_group_rules` エントリに存在します。プロダクト横断のオーディエンスの一貫性は、セラーがデータプロバイダーでもある場合でさえ、共有された `scope: "data_provider"` のシグナル定義から得られます。

```json theme={null}
{
  "packages": [
    {
      "product_id": "retail_video_premium",
      "pricing_option_id": "media_cpm_usd",
      "budget": 25000,
      "targeting_overlay": {
        "signal_targeting_groups": {
          "operator": "all",
          "groups": [
            {
              "operator": "any",
              "signals": [
                {
                  "signal_ref": { "scope": "product", "signal_id": "high_intent_shoppers" },
                  "value_type": "binary",
                  "value": true
                },
                {
                  "signal_ref": { "scope": "product", "signal_id": "loyalty_members" },
                  "value_type": "binary",
                  "value": true
                }
              ]
            },
            {
              "operator": "none",
              "signals": [
                {
                  "signal_ref": { "scope": "product", "signal_id": "recent_purchasers" },
                  "value_type": "binary",
                  "value": true
                }
              ]
            }
          ]
        }
      }
    }
  ]
}
```

### frequency\_cap

* **説明**: エンティティごとに広告の露出頻度を制限します。二つの任意の制御を独立して、または一緒に使えます。
* **クールダウン制御**: `suppress` — 同じエンティティへの連続した露出の間の最小時間。後方互換性のために `suppress_minutes`（数値）も受け入れられます。
* **インプレッションキャップ**: `max_impressions` + `per` + `window` — エンティティごと・時間ウィンドウごとの総インプレッション上限。三つのフィールドはすべて一緒に必須です。
* **ユースケース**: ユーザー体験の管理、広告疲労の防止、ハードな上限でリーチ最適化ゴールを補完
* **例**: `{"suppress": {"interval": 60, "unit": "minutes"}}`、`{"max_impressions": 5, "per": "households", "window": {"interval": 7, "unit": "days"}}`

### age\_restriction

* **説明**: コンプライアンスのために最低年齢を要求します
* **形式**: `min`（必須）、`verification_required`、`accepted_methods` を持つオブジェクト
* **例**: `{"min": 21, "verification_required": true}`、`{"min": 18, "accepted_methods": ["world_id"]}`
* **ユースケース**: アルコール（21+）、ギャンブル（18+）、カンナビス規制
* **注**: プラットフォームはサポートする検証方法を `get_adcp_capabilities` で宣言します

### device\_platform

* **説明**: 特定のオペレーティングシステムプラットフォームに制限します
* **形式**: Sec-CH-UA-Platform 標準のプラットフォーム識別子の配列
* **例**: `["ios"]`、`["ios", "android"]`、`["tvos", "fire_os"]`
* **ユースケース**: アプリインストールキャンペーン（iOS 専用アプリ）、CTV 固有のキャンペーン
* **値**: `ios`、`android`、`windows`、`macos`、`linux`、`chromeos`、`tvos`、`tizen`、`webos`、`fire_os`、`roku_os`

### device\_type

* **説明**: 特定のデバイスのフォームファクターに制限します
* **形式**: デバイスタイプ識別子の配列
* **例**: `["mobile"]`、`["mobile", "tablet"]`、`["ctv"]`
* **ユースケース**: モバイル専用プロモーション、すべての TV プラットフォームをターゲットする CTV キャンペーン、特定のキャンペーンから DOOH を除外
* **値**: `desktop`、`mobile`、`tablet`、`ctv`、`dooh`、`unknown`
* **注**: セラーは `get_adcp_capabilities` のターゲティングで `device_type: true` を宣言しなければなりません

### device\_type\_exclude

* **説明**: 特定のデバイスのフォームファクターを配信から除外します
* **形式**: デバイスタイプ識別子の配列
* **例**: `["dooh"]`、`["ctv", "dooh"]`
* **ユースケース**: アプリインストールキャンペーンで CTV を除外、ダイレクトレスポンスキャンペーンで DOOH を除外
* **注**: セラーが `get_adcp_capabilities` で `device_type: true` を宣言する場合にサポートされます

### language

* **説明**: 特定の言語設定を持つユーザーに制限します
* **形式**: ISO 639-1 の 2 文字言語コードの配列
* **例**: `["en"]`、`["es", "en"]`、`["zh", "ja", "ko"]`
* **ユースケース**: ローカライズされたクリエイティブ、言語固有のキャンペーン

### keyword\_targets

* **説明**: 検索およびリテールメディアプラットフォーム向けに特定のキーワードをターゲットします。指定されたキーワードにマッチするクエリに配信を制限します。
* **形式**: `keyword`、`match_type`（`broad`、`phrase`、または `exact`）、および任意の `bid_price` を持つオブジェクトの配列
* **アイデンティティ**: 各キーワードはタプル `(keyword, match_type)` で識別されます。異なるマッチタイプを持つ同じキーワード文字列は別個のターゲットです。単一リクエスト内の重複ペアはセラーによって拒否されるべきです（SHOULD）。
* **マッチタイプ**:
  * `broad` — 関連クエリと同義語クエリにマッチ
  * `phrase` — キーワードフレーズを順序どおりに含むクエリにマッチ
  * `exact` — キーワードクエリのみにマッチ
* **キーワードごとの入札**: 任意の `bid_price` は、そのキーワードについてパッケージレベルの `bid_price` を上書きします。価格オプションから `max_bid` の解釈を継承します: `max_bid` が true のときはこれがキーワードの入札上限、false のときはこれが正確な入札です。省略した場合はパッケージの `bid_price` が適用されます。
* **ユースケース**: 検索キャンペーン、リテールメディアのスポンサープロダクト、キーワードベースの意図ターゲティング
* **注**: セラーは `get_adcp_capabilities` で `execution.targeting.keyword_targets` を、受け入れる `supported_match_types` とともに宣言しなければなりません。セラーが宣言するマッチタイプのみを使ってください——セラーはサポートしないマッチタイプを拒否しなければなりません。ローンチ後にキーワードを段階的に追加または更新するには、`update_media_buy` で `keyword_targets_add` と `keyword_targets_remove` を使います。キーワードレベルの配信データ（レポートの `by_keyword`）は、プロダクトに `reporting_capabilities.supports_keyword_breakdown: true` を必要とします——これらは独立したケイパビリティです。`by_keyword` はキーワード粒度（keyword+match\_type ペアごとに 1 行）であって、検索語粒度ではありません。

```json theme={null}
{
  "$schema": "/schemas/core/targeting.json",
  "keyword_targets": [
    { "keyword": "running shoes", "match_type": "broad", "bid_price": 0.45 },
    { "keyword": "trail running shoes womens", "match_type": "phrase", "bid_price": 0.85 },
    { "keyword": "acme cloudrunner 5", "match_type": "exact", "bid_price": 1.20 }
  ]
}
```

### negative\_keywords

* **説明**: 特定のキーワードを配信から除外します。これらのキーワードにマッチするクエリは広告をトリガーしません。
* **形式**: `keyword` と `match_type`（`broad`、`phrase`、または `exact`）を持つオブジェクトの配列
* **ユースケース**: 無関係なクエリへの無駄な支出を防ぐ、競合のブランド語を除外
* **注**: セラーは `get_adcp_capabilities` で `execution.targeting.negative_keywords` を、受け入れる `supported_match_types` とともに宣言しなければなりません。ローンチ後にネガティブを段階的に追加/削除するには、`update_media_buy` で `negative_keywords_add` と `negative_keywords_remove` を使います。

```json theme={null}
{
  "$schema": "/schemas/core/targeting.json",
  "negative_keywords": [
    { "keyword": "free", "match_type": "broad" },
    { "keyword": "used running shoes", "match_type": "phrase" }
  ]
}
```

### store\_catchments

* **説明**: 同期された店舗カタログの店舗商圏内のユーザーをターゲットします
* **形式**: `sync_catalogs` を通じて同期された store 型カタログをそれぞれ参照するオブジェクトの配列
* **必須フィールド**: `catalog_id`
* **任意フィールド**: `store_ids`（特定の店舗に絞り込む）、`catchment_ids`（`"walk"` や `"drive"` のような特定のゾーンに絞り込む）
* **ユースケース**: 来店促進キャンペーン、ローカルインベントリ広告、近接ターゲティング

```json theme={null}
{
  "targeting_overlay": {
    "store_catchments": [
      {
        "catalog_id": "retail-locations",
        "store_ids": ["store_nyc_001", "store_nyc_002"],
        "catchment_ids": ["drive"]
      }
    ]
  }
}
```

`store_ids` を省略した場合、カタログ内のすべての店舗がターゲットされます。`catchment_ids` を省略した場合、すべての商圏ゾーンがターゲットされます。セラーは店舗商圏ターゲティングのサポートを `get_adcp_capabilities` で宣言しなければなりません。

### geo\_proximity

* **説明**: 任意の地理的地点の周囲の、移動時間、距離、またはカスタム境界内のユーザーをターゲットします
* **形式**: それぞれちょうど一つの方法を持つオブジェクトの配列: `travel_time` + `transport_mode`、`radius`、または `geometry`
* **必須フィールド**: `lat` + `lng`（travel\_time と radius の方法の場合）、または `geometry`（事前計算された境界の場合）
* **任意フィールド**: `label`（エントリの人が読める名前）
* **ユースケース**: 観光キャンペーン（都市から車で 2 時間以内）、イベントターゲティング（会場の近く）、空港の商圏エリア
* **セマンティクス**: 複数のエントリは OR を使います——列挙された任意の地点の範囲内のユーザーが適格です。他の geo ターゲティングフィールドと交差します（例: `geo_countries` と組み合わせると近接をそれらの国に制限します）

移動時間（アイソクロン）の例:

```json theme={null}
{
  "targeting_overlay": {
    "geo_proximity": [
      {
        "lat": 51.2277,
        "lng": 6.7735,
        "label": "Düsseldorf",
        "travel_time": { "value": 2, "unit": "hr" },
        "transport_mode": "driving"
      }
    ]
  }
}
```

半径ベースの例:

```json theme={null}
{
  "targeting_overlay": {
    "geo_proximity": [
      {
        "lat": 51.4700,
        "lng": -0.4543,
        "label": "Heathrow Airport",
        "radius": { "value": 30, "unit": "km" }
      }
    ]
  }
}
```

事前計算されたジオメトリの例（バイヤーがポリゴンを提供）:

```json theme={null}
{
  "targeting_overlay": {
    "geo_proximity": [
      {
        "label": "2hr drive from Düsseldorf",
        "geometry": {
          "type": "Polygon",
          "coordinates": [[[5.87, 50.35], [8.23, 50.35], [8.23, 52.10], [5.87, 52.10], [5.87, 50.35]]]
        }
      }
    ]
  }
}
```

移動時間のエントリについては、プラットフォームが実際の交通ネットワークに基づいてアイソクロンを地理的境界に解決します。移動手段: `driving`、`walking`、`cycling`、`public_transport`。`geometry` の方法は、（TravelTime、Mapbox などで）すでにアイソクロンを計算したバイヤーがポリゴンを直接渡すことを可能にします——これはルーティングエンジンを持たないセラーの参加も可能にします。

10 か所以上をターゲットするキャンペーンには、代わりにロケーションカタログを持つ `store_catchments` の使用を検討してください。継続的な管理とロケーションごとのレポートをサポートします。`geo_proximity` には除外バリアントがありません——これは設計上の意図であり、「ある地点の近くの全員」を除外することが意味のあるターゲティング制約になることはめったにないためです。

セラーは、自身のプライバシーポリシーと適用される規制に合致した最小エリアのしきい値を強制すべきです（SHOULD）。セラーは `get_adcp_capabilities` で `geo_proximity` のサポートを、どの方法（`radius`、`travel_time`、`geometry`）と移動手段がサポートされるかを指定して宣言しなければなりません。

検証済みの例:

```json theme={null}
{
  "$schema": "/schemas/core/targeting.json",
  "geo_proximity": [
    {
      "lat": 51.2277,
      "lng": 6.7735,
      "label": "Düsseldorf",
      "travel_time": { "value": 2, "unit": "hr" },
      "transport_mode": "driving"
    }
  ]
}
```

```json theme={null}
{
  "$schema": "/schemas/core/targeting.json",
  "geo_proximity": [
    {
      "lat": 51.4700,
      "lng": -0.4543,
      "label": "Heathrow Airport",
      "radius": { "value": 30, "unit": "km" }
    }
  ]
}
```

```json theme={null}
{
  "$schema": "/schemas/core/targeting.json",
  "geo_proximity": [
    {
      "label": "2hr drive from Düsseldorf",
      "geometry": {
        "type": "Polygon",
        "coordinates": [[[5.87, 50.35], [8.23, 50.35], [8.23, 52.10], [5.87, 52.10], [5.87, 50.35]]]
      }
    }
  ]
}
```

## ステークホルダー別の利点

### バイヤー向け

* **シンプルなプランニング**: オーディエンスのニーズを自然に記述
* **透明な価格**: すべてのコストが事前に込み
* **複雑さの低減**: ターゲティングの設定が不要
* **より良い成果**: パブリッシャーの専門知識が配信を最適化

### パブリッシャー向け

* **価格の制御**: ターゲティングをプロダクト価格に束ねる
* **専門知識の活用**: インベントリとオーディエンスの知識を適用
* **統合の簡素化**: 技術的なターゲティングパラメータが少ない
* **市場でのポジショニング**: ターゲティング機能で差別化

### プラットフォーム向け

* **衝突の低減**: 単一のターゲティングソースがレイヤリングの問題を排除
* **クリーンな実装**: より複雑でないターゲティングロジック
* **より良いパフォーマンス**: パブリッシャーのインベントリ特性に最適化

## リアルタイムターゲティングシグナル

オーケストレーターは、静的なオーバーレイで表現できるものを超えた動的で高カーディナリティなターゲティングのために、パブリッシャーに**リアルタイムターゲティングシグナル**を提供できます。これらのシグナルは次を可能にします:

* **ブランドセーフティ** - リアルタイムのコンテンツフィルタリングと隣接制御
* **ブランド適合性** - ブランド価値とのコンテキスト的整合
* **オーディエンスターゲティング** - リアルタイムで更新される動的なオーディエンスセグメント
* **コンテキストターゲティング** - ページレベルまたはモーメントレベルのターゲティング判断

リアルタイムシグナルは [AdCP シグナルプロトコル](/docs/signals/overview) を通じて提供され、オーケストレーターがインプレッション時にターゲティングデータを供給できるようにします。

### シグナル vs オーバーレイの違い

* シグナルはキャンペーンのセットアップ時ではなく、**インプレッション時に評価**されます
* シグナルは**より高いカーディナリティ**をサポートします（数十ではなく数千の値）
* シグナルはメディアバイを変更せずに**継続的に更新**できます
* シグナルは、ブリーフでは表現できない**高度なコンテキストターゲティング**を可能にします

### リアルタイムシグナルを使う場面

✅ **リアルタイムシグナルを使う場合:**

* ブランドセーフティのフィルタリング（安全でないコンテンツをブロック）
* ブランド適合性のスコアリング（適した文脈を優先）
* 動的なオーディエンスターゲティング（リアルタイムのセグメントメンバーシップ）
* コンテキストターゲティング（ページレベルまたはモーメントレベルの判断）
* 高カーディナリティなターゲティング（数千の値）
* キャンペーンのフライト中に変化するターゲティング

## ローンチ後のキーワード管理

キーワードターゲットとネガティブキーワードはどちらも `update_media_buy` で段階的な操作をサポートし、`targeting_overlay` 全体を置き換える必要をなくします:

* **`keyword_targets_add`** — `(keyword, match_type)` のアイデンティティでアップサートします。新しいキーワードを追加するか、既存のものの `bid_price` を更新します。
* **`keyword_targets_remove`** — マッチする `(keyword, match_type)` ペアを削除します。
* **`negative_keywords_add`** — ネガティブを追加します。重複は no-op です。
* **`negative_keywords_remove`** — マッチするペアを削除します。存在しないエントリは no-op です。

```json theme={null}
{
  "packages": [
    {
      "package_id": "pkg_sponsored_search_001",
      "keyword_targets_add": [
        { "keyword": "trail running shoes", "match_type": "phrase", "bid_price": 0.95 }
      ],
      "keyword_targets_remove": [
        { "keyword": "running shoes", "match_type": "broad" }
      ],
      "negative_keywords_add": [
        { "keyword": "diy", "match_type": "broad" },
        { "keyword": "how to make running shoes", "match_type": "phrase" }
      ]
    }
  ]
}
```

セラーは、同じリクエストに `targeting_overlay.keyword_targets` が `keyword_targets_add` または `keyword_targets_remove` とともに存在する場合、バリデーションエラーを返すべきです（SHOULD）（ネガティブキーワードについても同様）。段階的な操作と完全なオーバーレイの置き換えは、単一の更新内では相互排他的です。

他のオーバーレイフィールドを保ちつつキーワードターゲティングをすべて削除するには、`keyword_targets` フィールドなしで完全な `targeting_overlay` を送ります。

## 実装要件

### パブリッシャーが必ず満たすこと:

1. **地理的ターゲティングのサポート**: プラットフォームがサポートする範囲で、地理的な包含と除外のパラメータ（`geo_countries`、`geo_countries_exclude`、`geo_regions`、`geo_regions_exclude`、`geo_metros`、`geo_metros_exclude`、`geo_postal_areas`、`geo_postal_areas_exclude`）を扱います。サポートするメトロと郵便のシステムを `get_adcp_capabilities` で宣言します
2. **ブリーフの解釈**: ブリーフを使って適切なオーディエンスとコンテンツのターゲティングを決定します
3. **ターゲティングの検証**: サポートできないターゲティングを持つメディアバイを拒否します
4. **制限の文書化**: 地理的ターゲティングの制限をプロダクト記述で明確に伝えます

### バイヤーが推奨されること:

1. **まずブリーフを使う**: ほとんどのターゲティングニーズを自然言語ブリーフで表現します
2. **オーバーレイを最小化**: 技術的なターゲティングは地理的制限または RCT テストにのみ使います
3. **パブリッシャーを信頼**: パブリッシャーにブリーフの解釈へインベントリの知識を適用させます
4. **早期に検証**: 技術的なターゲティングを適用する前にプロダクトのケイパビリティを確認します

## ベストプラクティス

1. **ブリーフをデフォルトに** - 自然言語の記述から始めます
2. **明確なブリーフを書く**: オーディエンスとコンテキストの要件を具体的にします
3. **パブリッシャーの専門知識を信頼**: パブリッシャーは自身のインベントリ機能を最もよく知っています
4. **動的なターゲティングにはシグナルを使う** - リアルタイムシグナルは、複雑で高カーディナリティなターゲティングをオーバーレイより上手く扱います
5. **技術的オーバーレイを最小化**: 地理的制限またはコンプライアンスにのみ使います
6. **オーディエンスの適合を検証**: プロダクト記述がキャンペーンゴールと一致することを確認します
7. **すべて込みの価格** - ターゲティングコストがプロダクトレートに組み込まれていることを期待します

## 将来の進化

* **強化されたブリーフ処理**: より高度な自然言語理解
* **オーディエンスの発見**: 利用可能なオーディエンスを探索するためのより良いツール
* **より深いシグナル統合**: より高度なリアルタイムターゲティング機能
* **パフォーマンス最適化**: キャンペーン結果に基づく AI 主導のオーディエンス絞り込み

## 関連ドキュメント

* **[トラステッドマッチプロトコル（TMP）](/docs/trusted-match)** - インプレッション時のターゲティング、フリークエンシーキャップ、ブランド適合性のためのリアルタイム実行レイヤー
* **[シグナルプロトコル](/docs/signals/overview)** - ブランド適合性とコンテキストターゲティングのためのリアルタイムターゲティングシグナル
* **[プロダクトディスカバリー](/docs/media-buy/product-discovery/)** - ブリーフがどのようにターゲティングされたプロダクト推奨へつながるか
* **[ブリーフ例](/docs/media-buy/product-discovery/example-briefs)** - 効果的なターゲティングブリーフの実例
* **[ポリシーコンプライアンス](/docs/media-buy/media-buys/policy-compliance)** - 自動化されたコンプライアンスチェックと強制