Abstract
Signals Protocol は、AI を活用したシグナルの探索・有効化・管理システムの標準インターフェースを定義します。このプロトコルにより、AI アシスタントは自然言語での対話を通じて、マーケターがデータシグナル（オーディエンス、コンテキスト、地理、時間、多次元データ）を発見・有効化・管理できるよう支援します。Protocol Overview
Signals Protocol では次のことが可能です。- マーケティング目的に基づく自然言語でのシグナル探索
- 1 回のリクエストで複数プラットフォームのシグナルを探索
- 特定のプラットフォームやアカウントへのシグナル有効化
- CPM やレベニューシェアモデルによる透明な価格提示
- 個人・デバイス・世帯など単位別のシグナル規模報告
Transport Requirements
シグナルエージェントは以下のいずれか少なくとも 1 つのトランスポートをサポートしなければなりません。
シグナルエージェントは優先トランスポートとして MCP をサポートすべきです。
シグナルエージェントは
get_adcp_capabilities で Signals Protocol のサポートを宣言しなければなりません。
Core Concepts
Request Roles
すべてのシグナルリクエストには 2 つの役割が存在します。- Orchestrator: API リクエストを送るプラットフォーム（例: バイヤーエージェントや AI アシスタント）
- Account: リクエストが代行される商業関係。Accounts Protocol を参照。
Signal Agent Types
プライベートシグナルエージェント — 単一のアカウントが専有し、専用アクセスを持つもの:- 権限のないアカウントに対しては
REFERENCE_NOT_FOUNDを返さなければなりません — 「エージェントが存在しない」と同じレスポンス。「存在するが未認可」を「存在しない」と区別すると、プライベートエージェントのクロステナント列挙が可能になります。両方のパスで一致しなければならない観測可能なチャネルの完全なセットは error-handling.mdx の統一レスポンス 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と照合して機密データの使用にフラグを立てます。
エンリッチメントとプログレッシブディスクロージャー
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 / get-signals-response.json
Reference: get_signals task
キャンペーン条件に合致するシグナルを探索します。
要件:
- オーケストレーターは
signal_spec、signal_refs、または非推奨のsignal_idsを含めなければなりません - シグナルエージェントはレスポンススキーマに定義された必須フィールドをすべて返さなければなりません
is_live: trueかつ呼び出し元がデプロイメントにアクセスできる場合、シグナルエージェントはactivation_keyを含めなければなりません
activate_signal
Schema:activate-signal-request.json / activate-signal-response.json
Reference: activate_signal task
意思決定プラットフォームで使用するためにシグナルを有効化します。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 エラースキーマ に従ってエラーを返さなければなりません。 シグナルエージェントは エラーハンドリングリファレンス で定義された 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 エージェントは次を満たさなければなりません。- 指定されたトランスポート（MCP または A2A）のうち少なくとも 1 つをサポートします
- スキーマに沿って
get_signalsを実装します - レスポンススキーマで定義された必須フィールドを返す
- 規定のエラーコードを使用します
- プライベートシグナルの、そしてアクティベーションがサポートされる場合はアクティベーションキーのアクセス制御を適用します
activate_signal も実装しなければなりません。ディスカバリー専用の自社シグナルエージェントは、activate_signal を実装せずに Signals Protocol ベースラインに準拠してもよい（MAY）。
Orchestrator Conformance
準拠した Signals Protocol オーケストレーターは次を満たさなければなりません。- シグナルエージェントと認証を行います
- リクエストスキーマで定義された必須フィールドを含めます
activate_signalを使うときは非同期の有効化レスポンスを処理します- アクティベーションがスコープ内のとき外部デプロイメントターゲティングに
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）— シグナル条件ごとに 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 アイデンティティで、共有タクソノミーレジストリなしでエージェント間マッチを構造的に可能にするものです。