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

# 仕様

> AdCP シグナルプロトコルの正式仕様。トランスポート要件、get_signals・activate_signal タスクスキーマ、適合基準、エラーハンドリング、アクティベーションキーのセキュリティ、RFC 2119 要件。

**Status**: Request for Comments
**Last Updated**: January 25, 2026

本ドキュメントは Signals Protocol の仕様を定義します。ここで使用する "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、"OPTIONAL" といったキーワードは、[RFC 2119](https://www.rfc-editor.org/rfc/rfc2119) に従って解釈すること。

## Abstract

Signals Protocol は、AI を活用したシグナルの探索・有効化・管理システムの標準インターフェースを定義します。このプロトコルにより、AI アシスタントは自然言語での対話を通じて、マーケターがデータシグナル（オーディエンス、コンテキスト、地理、時間、多次元データ）を発見・有効化・管理できるよう支援します。

## Protocol Overview

Signals Protocol では次のことが可能です。

* マーケティング目的に基づく自然言語でのシグナル探索
* 1 回のリクエストで複数プラットフォームのシグナルを探索
* 特定のプラットフォームやアカウントへのシグナル有効化
* CPM やレベニューシェアモデルによる透明な価格提示
* 個人・デバイス・世帯など単位別のシグナル規模報告

## Transport Requirements

シグナルエージェントは以下のいずれか少なくとも 1 つのトランスポートをサポートしなければなりません。

| Transport | Protocol               | Description                         |
| --------- | ---------------------- | ----------------------------------- |
| MCP       | Model Context Protocol | Tool-based interaction via JSON-RPC |
| A2A       | Agent-to-Agent         | Message-based interaction           |

シグナルエージェントは優先トランスポートとして MCP をサポートすべきです。

シグナルエージェントは `get_adcp_capabilities` で Signals Protocol のサポートを宣言しなければなりません。

```json theme={null}
{
  "$schema": "https://adcontextprotocol.org/schemas/v3/protocol/get-adcp-capabilities-response.json",
  "status": "completed",
  "adcp": {
    "major_versions": [2],
    "idempotency": { "supported": true, "replay_ttl_seconds": 86400 }
  },
  "supported_protocols": ["signals"]
}
```

## Core Concepts

### Request Roles

すべてのシグナルリクエストには 2 つの役割が存在します。

* **Orchestrator**: API リクエストを送るプラットフォーム（例: バイヤーエージェントや AI アシスタント）
* **Account**: リクエストが代行される商業関係。[Accounts Protocol](/docs/accounts/overview) を参照。

### Signal Agent Types

**プライベートシグナルエージェント** — 単一のアカウントが専有し、専用アクセスを持つもの:

* 権限のないアカウントに対しては `REFERENCE_NOT_FOUND` を返さなければなりません — 「エージェントが存在しない」と同じレスポンス。「存在するが未認可」を「存在しない」と区別すると、プライベートエージェントのクロステナント列挙が可能になります。両方のパスで一致しなければならない観測可能なチャネルの完全なセットは [error-handling.mdx](/docs/building/by-layer/L3/error-handling) の統一レスポンス MUST を参照。
* アカウントをまたいでプライベートシグナルを公開してはなりません

**マーケットプレイスシグナルエージェント** — 複数のアカウントにシグナルデータをライセンス提供するもの:

* アカウント登録なしでの公開ホールセールフィードアクセスをサポートしなければなりません
* 登録済みアカウント向けのアカウントパーソナライズされたホールセールフィードビューをサポートすべきです

### Identifiers

* **`signal_agent_segment_id`**: シグナルソースが発行する不透明なシグナルハンドル。Signals Protocol レスポンスは各シグナルに対してこれを返さなければならず、オーケストレーターは `activate_signal` リクエストでこれを使用しなければなりません。セラー提供のメディアバイシグナルターゲティングでは、バイヤーは名前付きシグナル参照として `signal_ref` を使い、選択したプロダクトオプションが別個の実行ハンドルを公開する場合のみ `signal_agent_segment_id` を含めます。

* **`activation_key`**: 外部デプロイメントターゲティングに使うキー。`is_live: true` かつ呼び出し元がデプロイメントへのアクセス権を持つ場合、シグナルエージェントはこれを返さなければなりません。オーケストレーターはプラットフォームまたはデスティネーションのターゲティングに `activation_key` を使用しなければなりません（`signal_agent_segment_id` ではなく）。セールスエージェントのメディアバイで選択されたセラー提供シグナルには、`packages[].targeting_overlay.signal_targeting_groups` を使い、セラーが事前のアクティベーションキーを要求する場合のみ `activation_key` を含めます。

### Governance metadata

シグナル定義には `restricted_attributes` および `policy_categories` フィールドを含めてもよい。これらは構造的なガバナンスマッチングを可能にします。データプロバイダーはこれらを宣言すべきであり、それによりガバナンスエージェントはシグナル名から感度を推測するのではなく、コンプライアンスを確定的に評価できます。

* **`restricted_attributes`**: このシグナルが関係する GDPR 第 9 条の特別カテゴリー値の配列。ガバナンスエージェントはセマンティック推論より宣言された属性を優先すべきです。
* **`policy_categories`**: このシグナルが対象となるポリシーカテゴリー ID の配列。ガバナンスエージェントはこれをプランの `policy_categories` と照合して機密データの使用にフラグを立てます。

実装の詳細は [ガバナンスメタデータの宣言](/docs/signals/data-providers#declaring-governance-metadata) を参照してください。

### エンリッチメントとプログレッシブディスクロージャー

`taxonomy.values[]`、`taxonomy.value_mappings[]`、`segmentation_criteria`、`onboarder`、`modeling.disclosure.jurisdictions[]` のようなリッチな定義フィールドは、権威的なシグナル定義を記述します。それらをすべてのディスカバリーリスティングで繰り返す必要はありません。

シグナルエージェントは `get_signals` をディスカバリーと利用可能性の面として扱うべきです（SHOULD）。広範な検索結果とホールセールフィードページでは、エージェントは安定したアイデンティティ、表示メタデータ、価格、デプロイメントステータス、利用可能な場合はキャッシュバリデーターまたはディスクロージャーポインターを持つコンパクトなリスティングを返すべきです（SHOULD）。プロバイダーが公開する公開シグナルでは、`signal_ref` が定義ポインターです: オーケストレーターはプロバイダーの `/.well-known/adagents.json` をフェッチし（存在する場合 `authoritative_location` に従う）、一致する `signals[].id` を選択します。大きなタクソノミー、長いセグメンテーション基準、管轄区域固有のディスクロージャーテキストは、その権威的なシグナル定義または `taxonomy.ref`、`criteria_url`、`modeling.disclosure.jurisdictions[].disclosure_url` のような宣言された URL からフェッチすべきです（SHOULD）。

プロバイダーファイルが既存の `adagents.json` の `catalog_etag` を含むか、HTTP レスポンスが `ETag` または `Last-Modified` を含む場合、オーケストレーターは解決された権威的 URL とそのバリデーターでフェッチした `adagents.json` ドキュメントをキャッシュし、キャッシュされたドキュメント内で `signal_ref.signal_id` を解決すべきです（SHOULD）。クライアントはシグナル定義キャッシュをバリデーターのみでキーしてはなりません（MUST NOT）。独自のフレッシュネスバリデーターを持つタクソノミードキュメントには `taxonomy.etag` を使います。エージェントはレビュー、ランキング、参照ルックアップのフロー向けにインライン抜粋を含めてもよい（MAY）が、大きな `get_signals` レスポンスのすべてのアイテムで完全な外部リソースを複製することは避けるべきです（SHOULD）。

インラインでよりリッチなメタデータを必要とするオーケストレーターは、`get_products.fields` と同じレスポンス射影パターンを使い、`get_signals` に `fields` を設定して、`taxonomy`、`data_sources`、`methodology`、`modeling`、`countries`、`consent_basis`、`data_subject_rights` のような特定のリスティングまたは定義フィールドを要求してもよい（MAY）。エージェントは、正確なルックアップ、リファインメント、小さなカスタムシグナル結果セット、公開 `adagents.json` 定義を持たないプライベート/ソースネイティブなシグナルについて、要求されたフィールドを尊重すべきです（SHOULD）。`fields` は射影リクエストであり資格付与ではありません。エージェントは、呼び出し元が基盤の系譜、方法論、権利ルーティングメタデータに認可されていない限り、要求された定義フィールドを秘匿してもよい（MAY）。セラーまたはフェデレーティングエージェントが別のプロバイダーの `consent_basis` や `art9_basis` を `get_signals` 行に射影するとき、その値はプロバイダー宣言のシグナル定義の姿勢のままです。セラーはそれを自身の処理根拠に書き換えてはなりません（MUST NOT）。広範なディスカバリーとホールセールページでは、エージェントは大きな定義リソースをインライン化する代わりにコンパクトなポインターを返してもよい（MAY）。

### 定義エンリッチメントフィールド

シグナル定義は、透明性、ガバナンス、レビューのための追加フィールドを運んでもよい（MAY）:

* **タクソノミーメタデータ**: `taxonomy.ref`、`taxonomy.values[]`、`taxonomy.value_mappings[]`、`taxonomy.parent_match_behavior` は、シグナルが外部またはプロバイダー所有のタクソノミーにどうマップするかを記述します。これらのフィールドはパッケージのターゲティング文法を変えません。
* **ソースと方法論のディスクロージャー**: `data_sources`、`methodology`、`segmentation_criteria`、`criteria_url`、`refresh_cadence`、`lookback_window`、`onboarder` は、セグメントがどうコンパイルされたかを記述します。オフラインと公的記録のソースカテゴリーは `onboarder` を必要とします。
* **モデリングディスクロージャー**: `methodology` が `modeled` または `audience_expansion` が `true` のとき `modeling` が必須です。必須のモデリングディスクロージャーは、ディスクロージャーが適用される管轄区域を名指ししなければなりません。
* **管轄区域とプライバシーメタデータ**: `countries`、GDPR スコープの `consent_basis`、`restricted_attributes`、`policy_categories`、`art9_basis` により、ガバナンスエージェントは使用制約を構造的に評価できます。ピアのシグナルを表面化するフェデレーティングエージェントは、ピアの `countries[]` を上限として扱い、バイヤーの意図するデプロイメント国に対して再チェックし、より狭いローカルポリシーのみを適用しなければなりません（MUST）。
* **データ主体の権利ルーティング**: `data_subject_rights.channels[]` は、このシグナルについてアクセス、消去、異議、ポータビリティ、訂正のリクエストがどこにルーティングされるかを宣言します。少なくとも 1 つのチャネルがアクセス、消去、異議の 1 つ以上をサポートしなければなりません。`response_sla_days` はシグナルスコープです。カスタム/プライベートシグナルと上流固有のルートは公開のプロバイダー全体のポリシー面を共有しないかもしれないからです。Global Privacy Control サポートはシグナル定義で宣言されず、コンシューマーは `data_subject_rights` から GPC の扱いを推論してはなりません（MUST NOT）。

### ランタイム検証ノート

シグナル定義スキーマは、多くの SDK ジェネレーターが保持しない制約に JSON Schema draft-07 の `if`/`then` と `contains` を使います。コンシューマーと SDK はこれらのケースにランタイムガードを実装すべきです（SHOULD）:

* `taxonomy` を持つ `value_type: "categorical"` は `taxonomy.value_mappings` を必要とします。
* `audience_scope: "single_domain"` は `originating_domain` を必要とします。
* `methodology: "modeled"` または `audience_expansion: true` は `modeling` を必要とします。
* オフラインまたは公的記録の `data_sources[]` は `onboarder` を必要とします。
* `data_subject_rights.channels[]` は、アクセス、消去、異議の 1 つ以上をサポートする少なくとも 1 つのチャネルを含まなければなりません。

`art9_basis` は、第 9 条の適用可能性が管轄区域と使用に依存するため、スキーマ必須ではなくポリシー必須です。ガバナンスエージェントはランタイムチェックを実行すべきです（SHOULD）: `restricted_attributes[]` が非空で計画された使用が第 9 条の管轄区域に触れるとき、`art9_basis` を要求するか、有効化前にレビューイシューを提起します。

## Tasks

Signals Protocol は 2 つのタスクスキーマを定義します。すべてのコンフォーマントな Signals Protocol エージェントはディスカバリー用に `get_signals` を実装します。マーケットプレイスアクティベーション専門分野を主張するか、アクティベーション/デアクティベーションを宣伝するか、バイヤー管理のアクティベーションを必要とするシグナルを返すエージェントは、アクティベーションライフサイクル面として `activate_signal` を実装します。

### get\_signals

**Schema**: [`get-signals-request.json`](https://adcontextprotocol.org/schemas/v3/signals/get-signals-request.json) / [`get-signals-response.json`](https://adcontextprotocol.org/schemas/v3/signals/get-signals-response.json)

**Reference**: [`get_signals` task](/docs/signals/tasks/get_signals)

キャンペーン条件に合致するシグナルを探索します。

**要件:**

* オーケストレーターは `signal_spec`、`signal_refs`、または非推奨の `signal_ids` を含めなければなりません
* シグナルエージェントはレスポンススキーマに定義された必須フィールドをすべて返さなければなりません
* `is_live: true` かつ呼び出し元がデプロイメントにアクセスできる場合、シグナルエージェントは `activation_key` を含めなければなりません

### activate\_signal

**Schema**: [`activate-signal-request.json`](https://adcontextprotocol.org/schemas/v3/signals/activate-signal-request.json) / [`activate-signal-response.json`](https://adcontextprotocol.org/schemas/v3/signals/activate-signal-response.json)

**Reference**: [`activate_signal` task](/docs/signals/tasks/activate_signal)

意思決定プラットフォームで使用するためにシグナルを有効化します。`activate_signal` は、`signal_marketplace` を主張するか、アクティベーション/デアクティベーションを宣伝するか、バイヤー管理のアクティベーションを必要とするシグナルを返すエージェントに必須です。ディスカバリー専用の自社シグナルエージェントは公開する必要はありません。

**要件:**

* オーケストレーターは `signal_agent_segment_id` と `destinations` を含めなければなりません
* ガバナンス対象のアカウントでは、オーケストレーターは `check_governance` からの有効な `governance_context` を渡さなければなりません。シグナルエージェントは、それを省略または捏造したガバナンス対象の有効化を拒否しなければなりません
* 成功時、シグナルエージェントは各デプロイメントの `is_live` を含む `deployments` 配列を返さなければなりません
* `is_live: true` かつ呼び出し元がデプロイメントにアクセスできる場合、シグナルエージェントは `activation_key` を返さなければなりません
* 失敗時、シグナルエージェントは `errors` 配列を返さなければならず（`deployments` 配列は含めない）

## Error Handling

シグナルエージェントは [標準の AdCP エラースキーマ](/docs/building/by-layer/L3/error-handling) に従ってエラーを返さなければなりません。

シグナルエージェントは [エラーハンドリングリファレンス](/docs/building/by-layer/L3/error-handling) で定義された Signals Protocol のエラーコードを使用しなければなりません。

## Security Considerations

### Transport Security

Signals Protocol の通信はすべて TLS 1.2 以上の HTTPS を使用しなければなりません。

### Authentication

* オーケストレーターは有効な認証情報を用いてシグナルエージェントに認証しなければなりません
* シグナルエージェントはリクエストを処理する前に認証情報を検証しなければなりません
* シグナルエージェントはアカウントのコンテキストを利用してカタログのアクセスレベルを判断すべきです

### Activation Key Security

* シグナルエージェントは認証済みでデプロイメントにアクセスできる呼び出し元にのみ `activation_key` を返さなければなりません
* 呼び出し元がアクセスできないデプロイメントに対するアクティベーションキーを返してはなりません

### Data Minimization

* シグナルエージェントは認証済みエージェントまたはアカウントがアクセスを許可されていないシグナルを返してはなりません

## Conformance

### Signal Agent Conformance

準拠したベースラインの Signals Protocol エージェントは次を満たさなければなりません。

1. 指定されたトランスポート（MCP または A2A）のうち少なくとも 1 つをサポートします
2. スキーマに沿って `get_signals` を実装します
3. レスポンススキーマで定義された必須フィールドを返す
4. 規定のエラーコードを使用します
5. プライベートシグナルの、そしてアクティベーションがサポートされる場合はアクティベーションキーのアクセス制御を適用します

マーケットプレイスアクティベーション専門分野を主張するか、その他アクティベーションサポートを宣伝するエージェントは、スキーマに従い `activate_signal` も実装しなければなりません。ディスカバリー専用の自社シグナルエージェントは、`activate_signal` を実装せずに Signals Protocol ベースラインに準拠してもよい（MAY）。

### Orchestrator Conformance

準拠した Signals Protocol オーケストレーターは次を満たさなければなりません。

1. シグナルエージェントと認証を行います
2. リクエストスキーマで定義された必須フィールドを含めます
3. `activate_signal` を使うときは非同期の有効化レスポンスを処理します
4. アクティベーションがスコープ内のとき外部デプロイメントターゲティングに `activation_key` を使い、セールスエージェントのメディアバイでのセラー提供シグナル選択にはパッケージレベルの `signal_targeting_groups` を使う

セラー提供のシグナルをセールスエージェントのバイの特定パッケージにのみ適用すべき場合、オーケストレーターはその選択を `create_media_buy.packages[].targeting_overlay.signal_targeting_groups` に運ぶべきです（SHOULD）。必要な場合は選択したシグナルの `pricing_option_id`、選択した `signal_ref` を含めます。`get_signals` はより広範なディスカバリー面で、選択したプロダクトのインライン `signal_targeting_options`（存在する場合）と `signal_targeting_rules` がバイ時の適格性と価格を規定します。ホールセールプロダクトはインラインオプションを省略し、候補ディスカバリーに `get_signals` に依存できます。`included_signals` は記述的なだけです: プロダクトにすでにバンドルまたは計画されたシグナルを識別しますが、それらを選択可能にはしません。プロダクトオプションまたは `get_signals` 結果がセラーの要求する別個の `signal_agent_segment_id` を公開する場合、バイヤーはそれを実行ハンドルとしてエコーします。そうでなければ `signal_ref` で十分です。これはパッケージレベルのバインディングです。`audience_include` と `audience_exclude` は `sync_audiences` からのバイヤー管理オーディエンスにスコープされたままです。

## Implementation Notes

### Multi-Platform Discovery

オーケストレーターは 1 回の `get_signals` 呼び出しで複数プラットフォームにわたるシグナルを要求してもよい。

シグナルエージェントは要求されたすべてのプラットフォームについてデプロイ情報を返すことが推奨されます。

### Activation Timing

シグナルの有効化は通常非同期です。

* シンプルな有効化: 1〜2 時間
* 複雑なデプロイ: 最大 24〜48 時間

オーケストレーターは有効化リクエスト直後に利用可能になると仮定してはなりません。

### デスティネーションタイプの選択

`activate_signal` リクエストは 2 つのデスティネーションタイプをサポートします。選択はバイヤーの実行パスによります:

* セールスエージェント経由で購入するオーケストレーターは、SA の URL を持つ `type: "agent"` デスティネーションを使うべきです（SHOULD）。SA がダウンストリームのプラットフォーム連携を処理します — どの DSP を使うかは実装の詳細です。
* DSP で直接購入するオーケストレーターは `type: "platform"` デスティネーションを使うべきです（SHOULD）。オーケストレーターは、有効化プラットフォームがキャンペーンが実行される場所と一致することを保証する責任があります。
* シグナルマーケットプレイスエージェントは、デスティネーションスキーマに従い両方のデスティネーションタイプをサポートしなければなりません（MUST）。

### クリエイティブシグナルのファンアウトとトラフィッキング互換性

`build_creative` は `signal_conditions` にわたってファンアウトしてもよい（[#5240](https://github.com/adcontextprotocol/adcp/issues/5240)）— シグナル条件ごとに 1 つの別個のクリエイティブグループを生成する keep-all の制作軸です（例: 雨のクリエイティブ AND 晴れのクリエイティブ）。生成された各グループは、それが対象とする `signal_condition`（`SignalTargeting`）でタグ付けされます。

**トラフィッキング互換性の不変条件（規範的）。** ある信号条件のために構築されたクリエイティブは、互換性のない条件をターゲティングするパッケージに配信されてはなりません（MUST NOT）。セールスエージェントは `create_media_buy` / `sync_creatives` でこの**トラフィッキング時拒否**を強制します: `signal_condition` がパッケージのシグナルターゲティングと互換性のないクリエイティブを割り当てると `SIGNAL_TARGETING_INCOMPATIBLE` で拒否されます。これは `build_creative` では強制されません — ビルド層ではシグナルポインターは助言的（バイヤー添付入力契約）で、強制はトラフィッキング境界に存在します。

**マッチング。** 互換性は共有される `signal_ref` アイデンティティで一致されます — 名前空間付きの `signal_agent_segment_id` / データプロバイダースコープの `signal_ref` が主要パス、カテゴリカルな `{signal_id, value}` がフォールバック。`value_type: numeric` では比較は範囲オーバーラップ（WG 未決: 範囲オーバーラップ vs 完全一致）。これは `create_media_buy` の `packages[].targeting_overlay.signal_targeting_groups` が使う**同じ** `signal_ref` アイデンティティで、共有タクソノミーレジストリなしでエージェント間マッチを構造的に可能にするものです。

## Schema Reference

| Schema                                                                                                                    | Description               |
| ------------------------------------------------------------------------------------------------------------------------- | ------------------------- |
| [`signals/get-signals-request.json`](https://adcontextprotocol.org/schemas/v3/signals/get-signals-request.json)           | get\_signals request      |
| [`signals/get-signals-response.json`](https://adcontextprotocol.org/schemas/v3/signals/get-signals-response.json)         | get\_signals response     |
| [`signals/activate-signal-request.json`](https://adcontextprotocol.org/schemas/v3/signals/activate-signal-request.json)   | activate\_signal request  |
| [`signals/activate-signal-response.json`](https://adcontextprotocol.org/schemas/v3/signals/activate-signal-response.json) | activate\_signal response |
| [`core/deployment.json`](https://adcontextprotocol.org/schemas/v3/core/deployment.json)                                   | Deployment target         |
| [`core/activation-key.json`](https://adcontextprotocol.org/schemas/v3/core/activation-key.json)                           | Activation key            |