データプロバイダーガイド

このガイドでは、データプロバイダーが adagents.json でシグナルカタログを公開する方法を説明します。AI エージェントがシグナルを探索し、認可を確認し、広告キャンペーン向けにシグナルを活性化できるようにします。

問題

データプロバイダー（Pinnacle Data、Meridian Analytics、Apex Segments など）は価値のあるオーディエンスとコンテキストデータを持っていますが、急成長する AI 駆動の広告エージェントエコシステムとの統合にはチャレンジがあります: 探索が分散しています。 各シグナルエージェント（Luminary Data、Nova DSP など）は、提供するシグナルを知るためにカスタム統合を必要とします。AI エージェントが「Pinnacle Data はどんな自動車購買意向シグナルを持っているか?」と問い合わせる標準的な方法がありません。 認可が不透明です。 バイヤーがシグナルエージェントからシグナルを受け取った場合、エージェントが実際にそれを再販する認可を持っているか確認できません。仲介者を信頼するしかありません。 シグナルのセマンティクスが一貫していません。 標準化された定義がなければ、AI エージェントは「auto_intenders」がバイナリセグメントなのか、傾向スコアなのか、多値カテゴリなのかを知ることができません。適切なターゲティング式を構築することが難しくなります。 スケールには N×M の統合が必要です。 すべてのデータプロバイダーはすべてのシグナルエージェントとカスタム統合を必要とします。これはスケールしません。

解決策

シグナルカタログはデータプロバイダーがよく知られた URL に機械可読なシグナルカタログを公開できるようにすることでこれらの問題を解決します:

探索: AI エージェントは自然言語（「自動車購買意向シグナルを探す」）または構造化ルックアップでシグナルを見つけられます
認可確認: バイヤーはデータプロバイダーのドメインを直接確認することで認可を確認できます
型付きターゲティング: シグナル定義は値タイプ（バイナリ、カテゴリ、数値）を含むのでエージェントが正しいターゲティング式を構築できます
スケーラブルなパートナーシップ: カタログで一度エージェントを認可します; シグナルを追加すると、認可されたエージェントは自動的にアクセスできます

概要

データプロバイダーはオーディエンスとコンテキストデータ（購買意向、人口統計、行動セグメント）を所有します。シグナルカタログ機能により以下を可能にする標準化されたフォーマットでシグナルを公開できます:

自然言語クエリによる探索の有効化
エージェントの認可確認の提供
シグナルの特性（バイナリ、カテゴリ、数値）の説明
効率的な認可のためのタグベースのグループ化のサポート

これはパブリッシャーがプロパティを宣言するのと同じパターンに従います — 「どんな広告プレースメントがあるか」ではなく、「どんなシグナルがあるか」を宣言します。

パラレルパターン

パブリッシャー	データプロバイダー
プロパティ（ウェブサイト、アプリ）を宣言する	シグナル（オーディエンス、セグメント）を宣言する
エージェントがインベントリを売ることを認可する	エージェントがシグナルを再販することを認可する
`property_ids` / `property_tags` を使用する	`signal_ids` / `signal_tags` を使用する
バイヤーは `publisher_domain` で確認する	バイヤーは `data_provider_domain` で確認する

どちらも公開メカニズムとして /.well-known/adagents.json を使用します。

ファイルの場所

データプロバイダーはシグナルカタログを以下でホストします:

https://your-domain.com/.well-known/adagents.json

RFC 8615 の well-known URI 規則に従います。

基本構造

{
  "$schema": "https://adcontextprotocol.org/schemas/v3/adagents.json",
  "contact": {
    "name": "Pinnacle Auto Data",
    "email": "partnerships@pinnacle-auto-data.com",
    "domain": "pinnacle-auto-data.com"
  },
  "signals": [
    {
      "id": "likely_ev_buyers",
      "name": "Likely EV Buyers",
      "description": "Consumers modeled as likely to purchase an electric vehicle in the next 12 months",
      "value_type": "binary",
      "tags": ["automotive", "green"]
    }
  ],
  "signal_tags": {
    "automotive": {
      "name": "Automotive Signals",
      "description": "Vehicle-related audience segments"
    },
    "green": {
      "name": "Green/Sustainability",
      "description": "Environmentally-conscious consumer segments"
    }
  },
  "authorized_agents": [
    {
      "url": "https://signals-agent.example.com",
      "authorized_for": "All automotive signals",
      "authorization_type": "signal_tags",
      "signal_tags": ["automotive"]
    }
  ],
  "last_updated": "2025-01-15T10:00:00Z"
}

シグナル定義

signals 配列の各シグナルはターゲット可能なセグメントを説明します:

必須フィールド

フィールド	型	説明
`id`	string	カタログ内の一意識別子。パターン: `^[a-zA-Z0-9_-]+$`
`name`	string	人間が読めるシグナル名
`value_type`	enum	データタイプ: `binary`、`categorical`、または `numeric`

オプションフィールド

フィールド	型	説明
`description`	string	このシグナルが何を表すかの詳細な説明
`tags`	array	グループ化のためのタグ（小文字、英数字: `^[a-z0-9_-]+$`）
`allowed_values`	array	カテゴリシグナルの場合: 有効な値
`range`	object	数値シグナルの場合: `{ min, max, unit }`
`restricted_attributes`	array	このシグナルが触れる制限された属性カテゴリ（例: `["health_data"]`）。構造的ガバナンスマッチングを有効にします。
`policy_categories`	array	このシグナルが敏感なポリシーカテゴリ（例: `["children_directed"]`）。構造的ガバナンスマッチングを有効にします。

シグナル値タイプ

バイナリシグナル

ユーザーがマッチするかしないか。最も一般的なタイプです。

{
  "id": "likely_ev_buyers",
  "name": "Likely EV Buyers",
  "value_type": "binary",
  "tags": ["automotive", "purchase_intent"]
}

ターゲティング: このシグナルにマッチするユーザーを含めるか除外します。

カテゴリシグナル

ユーザーがいくつかの可能な値のいずれかを持ちます。

{
  "id": "vehicle_ownership",
  "name": "Current Vehicle Ownership",
  "value_type": "categorical",
  "allowed_values": ["luxury_ev", "luxury_non_ev", "mid_range", "economy", "none"]
}

ターゲティング: 特定の値を持つユーザーをターゲットにします（例: 「高級 EV または高級非 EV を所有するユーザー」）。

数値シグナル

ユーザーが範囲内のスコアまたは測定値を持ちます。

{
  "id": "purchase_propensity",
  "name": "Auto Purchase Propensity",
  "value_type": "numeric",
  "range": {
    "min": 0,
    "max": 1,
    "unit": "score"
  }
}

ターゲティング: 値の範囲内のユーザーをターゲットにします（例: 「傾向スコア > 0.7」）。

認可パターン

パターン1: シグナル ID（直接参照）

ID で特定のシグナルを認可します:

{
  "authorized_agents": [
    {
      "url": "https://premium-agent.example.com",
      "authorized_for": "Premium automotive signals only",
      "authorization_type": "signal_ids",
      "signal_ids": ["likely_ev_buyers", "luxury_auto_intenders"]
    }
  ]
}

最適な用途: 特定の限られたシグナルセット。きめ細かい制御。

パターン2: シグナルタグ（効率的なグループ化）

特定のタグを持つすべてのシグナルを認可します:

{
  "authorized_agents": [
    {
      "url": "https://full-catalog-agent.example.com",
      "authorized_for": "All automotive signals",
      "authorization_type": "signal_tags",
      "signal_tags": ["automotive"]
    }
  ]
}

最適な用途: 大型カタログ。タグ付きシグナルを追加すると、エージェントは自動的にアクセスできます。

シグナルタグ

signal_tags オブジェクトはシグナルで使用されるタグのメタデータを提供します:

{
  "signal_tags": {
    "automotive": {
      "name": "Automotive Signals",
      "description": "Vehicle ownership, purchase intent, and service signals"
    },
    "premium": {
      "name": "Premium Signals",
      "description": "High-value segments with enhanced pricing"
    }
  }
}

タグを定義する理由:

カタログを探索するバイヤーへの人間が読めるコンテキスト
効率的な認可の有効化（「すべてのプレミアムシグナル」）
簡単な探索のための関連シグナルのグループ化

バイヤーによるカタログの使用方法

1. 探索

バイヤーはシグナルエージェントで get_signals を呼び出します。エージェントはカタログを以下に使用することがあります:

自然言語マッチング（「自動車購買意向シグナルを探す」）
signal_id による構造化ルックアップ

2. 認可確認

バイヤーがシグナルを受け取ったら、認可を確認できます:

{
  "signal_id": {
    "data_provider_domain": "pinnacle-auto-data.com",
    "id": "likely_ev_buyers"
  }
}

バイヤーは https://pinnacle-auto-data.com/.well-known/adagents.json を取得して確認します:

シグナルは signals 配列に存在するか?
シグナルエージェントは authorized_agents にあるか?
認可はこのシグナルをカバーしているか（ID またはタグで）?

3. ターゲティング

value_type に基づいて、バイヤーはターゲティング式を構築します:

// Binary targeting
{
  "signal_id": { "source": "catalog", "data_provider_domain": "pinnacle-auto-data.com", "id": "likely_ev_buyers" },
  "value_type": "binary",
  "value": true
}

// Categorical targeting
{
  "signal_id": { "source": "catalog", "data_provider_domain": "pinnacle-auto-data.com", "id": "vehicle_ownership" },
  "value_type": "categorical",
  "values": ["luxury_ev", "luxury_non_ev"]
}

// Numeric targeting
{
  "signal_id": { "source": "catalog", "data_provider_domain": "pinnacle-auto-data.com", "id": "purchase_propensity" },
  "value_type": "numeric",
  "min_value": 0.7
}

エージェントネイティブシグナル

すべてのシグナルがデータプロバイダーカタログから来るわけではありません。シグナルエージェントはエージェントネイティブシグナル — 独自に作成したカスタムシグナル（プロプライエタリモデル、ファーストパーティデータなど）— も提供することがあります。

シグナル ID 構造

シグナル ID は source を識別子として使用します:

ソース	フィールド	検証
`catalog`	`data_provider_domain` + `id`	データプロバイダーの adagents.json で検証可能
`agent`	`agent_url` + `id`	信頼ベース — バイヤーがエージェントを信頼する

例: エージェントネイティブシグナル

{
  "signal_id": {
    "source": "agent",
    "agent_url": "https://luminary-data.com/.well-known/adcp/signals",
    "id": "custom_auto_intenders"
  },
  "value_type": "binary",
  "value": true
}

いつどちらを使うか

source: "catalog" を使う場合:

シグナルが外部データプロバイダー（Pinnacle Data、Meridian Analytics など）から来ます
認可確認が重要
正規のシグナル定義を参照したい

source: "agent" を使う場合:

シグナルがシグナルエージェント独自のもの
照合する外部データプロバイダーがない
エージェントがカスタムモデルやファーストパーティセグメントを作成しています

完全な例

自動車データプロバイダーの完全なシグナルカタログ:

{
  "$schema": "https://adcontextprotocol.org/schemas/v3/adagents.json",
  "contact": {
    "name": "Pinnacle Auto Data",
    "email": "partnerships@pinnacle-auto-data.com",
    "domain": "pinnacle-auto-data.com"
  },
  "signals": [
    {
      "id": "likely_ev_buyers",
      "name": "Likely EV Buyers",
      "description": "Consumers modeled as likely to purchase an electric vehicle in the next 12 months based on vehicle registration, financial, and behavioral data",
      "value_type": "binary",
      "tags": ["automotive", "premium"]
    },
    {
      "id": "vehicle_ownership",
      "name": "Current Vehicle Ownership",
      "description": "Current vehicle category owned by the consumer",
      "value_type": "categorical",
      "allowed_values": ["luxury_ev", "luxury_non_ev", "mid_range", "economy", "none"],
      "tags": ["automotive"]
    },
    {
      "id": "purchase_propensity",
      "name": "Auto Purchase Propensity",
      "description": "Likelihood score of purchasing any new vehicle in the next 6 months",
      "value_type": "numeric",
      "range": { "min": 0, "max": 1, "unit": "score" },
      "tags": ["automotive"]
    }
  ],
  "signal_tags": {
    "automotive": {
      "name": "Automotive Signals",
      "description": "Vehicle-related audience segments"
    },
    "premium": {
      "name": "Premium Signals",
      "description": "High-value premium audience segments with enhanced pricing"
    }
  },
  "authorized_agents": [
    {
      "url": "https://luminary-data.com/.well-known/adcp/signals",
      "authorized_for": "All Pinnacle automotive signals via Luminary Data",
      "authorization_type": "signal_tags",
      "signal_tags": ["automotive"]
    },
    {
      "url": "https://nova-dsp.com/.well-known/adcp/signals",
      "authorized_for": "Pinnacle premium signals only",
      "authorization_type": "signal_ids",
      "signal_ids": ["likely_ev_buyers"]
    }
  ],
  "last_updated": "2025-01-15T10:00:00Z"
}

位置情報データプロバイダーの例

ジオ/モビリティプロバイダーのシグナルカタログは同じ構造を使用しますが、位置情報固有のシグナルがあります。フットトラフィックとモビリティデータを公開するプロバイダーの signals 配列の例:

{
  "signals": [
    {
      "id": "store_visitors",
      "name": "Store Visitors",
      "description": "Consumers who visited a specified retail location in the past 30 days based on opted-in mobile device data",
      "value_type": "binary",
      "tags": ["geo", "foot_traffic"]
    },
    {
      "id": "visit_frequency",
      "name": "Location Visit Frequency",
      "description": "Monthly visit count to a specified location category",
      "value_type": "numeric",
      "range": { "min": 0, "max": 30, "unit": "visits_per_month" },
      "tags": ["geo", "frequency"]
    },
    {
      "id": "commute_pattern",
      "name": "Commute Pattern",
      "description": "Categorized daily commute behavior based on observed travel patterns",
      "value_type": "categorical",
      "allowed_values": ["urban_transit", "suburban_driver", "remote_worker", "hybrid"],
      "tags": ["geo", "behavioral"]
    }
  ]
}

3つの値タイプが異なるジオコンセプトにマップされることに注目してください: 店舗訪問の有無には binary、意味のある範囲を持つ訪問頻度には numeric、分類されたモビリティ行動には categorical。

アイデンティティ/デモグラフィックプロバイダーの例

アイデンティティ会社のシグナルカタログは金融記録、調査、公開データから得られる消費者セグメントを公開します。注意: これらは生データではなくターゲティングセグメントです。クレジット由来のシグナルは規制上の義務（FCRA）を伴う場合があります — 公開前にコンプライアンスチームに相談してください。

{
  "signals": [
    {
      "id": "household_income",
      "name": "Household Income Tier",
      "description": "Modeled household income bracket based on financial and demographic indicators",
      "value_type": "categorical",
      "allowed_values": ["under_50k", "50k_75k", "75k_100k", "100k_150k", "150k_250k", "over_250k"],
      "tags": ["demographic", "income"]
    },
    {
      "id": "life_stage",
      "name": "Life Stage",
      "description": "Life stage classification derived from demographic and behavioral indicators",
      "value_type": "categorical",
      "allowed_values": ["young_adult", "early_career", "established_family", "empty_nester", "retired"],
      "tags": ["demographic", "life_stage"]
    },
    {
      "id": "credit_active",
      "name": "Active Credit Seeker",
      "description": "Consumer has actively applied for new credit products in the past 90 days",
      "value_type": "binary",
      "tags": ["financial", "in_market", "credit"]
    }
  ]
}

アイデンティティ会社はクロスデバイスのアイデンティティグラフも提供することが多いですが、サービスとしてのアイデンティティ解決（デバイス A を人物 B にマッチング）はまだ AdCP プロトコルの一部ではありません。この境界の詳細はシグナルエコシステムガイドを参照してください。

リテールメディアプロバイダーの例

リテーラーはファーストパーティの購買データを持ち、それが高価値なターゲティングシグナルになります。リテールメディアネットワークは同じ adagents.json 内でプロパティと並べてシグナルを公開できます:

{
  "signals": [
    {
      "id": "category_buyer",
      "name": "Category Buyer",
      "description": "Purchased in the specified product category within the past 90 days",
      "value_type": "categorical",
      "allowed_values": ["electronics", "home", "beauty", "grocery", "fashion"],
      "tags": ["retail", "purchase"]
    },
    {
      "id": "purchase_frequency",
      "name": "Monthly Purchase Frequency",
      "description": "Number of purchases in a product category over the trailing 90 days",
      "value_type": "numeric",
      "range": { "min": 0, "max": 50, "unit": "purchases" },
      "tags": ["retail", "frequency"]
    },
    {
      "id": "new_to_brand",
      "name": "New to Brand",
      "description": "Consumer has no prior purchase history with the specified brand in the trailing 12 months",
      "value_type": "binary",
      "tags": ["retail", "conquest"]
    }
  ]
}

リテールシグナルはモデル化された行動ではなく実際の購買に基づく決定論的なデータのため特に価値が高いです。デュアルロールパターン（パブリッシャー + データプロバイダー）についてはシグナルエコシステムガイドを参照してください。

バリデーション

AdAgents.json Builder を使ってシグナルカタログを検証するか、プログラム的に検証します:

curl -X POST https://adcontextprotocol.org/api/adagents/validate \
  -H "Content-Type: application/json" \
  -d '{"domain": "your-domain.com"}' | jq '.data.validation'

バリデーターは以下をチェックします:

必須フィールド（各シグナルの id、name、value_type）
ID パターン（アンダースコア/ハイフン付き英数字）
タグの一貫性（シグナルで使用されるタグは signal_tags で定義されるべきです）
認可参照（signal_ids/signal_tags は既存のシグナル/タグを参照すべきです）

ベストプラクティス

1. 説明的な ID を使用します

// Good
{ "id": "likely_ev_buyers" }
{ "id": "household_income_150k_plus" }

// Avoid
{ "id": "seg_12345" }
{ "id": "a1b2c3" }

2. 完全なメタデータを提供します

description を含めてバイヤーが各シグナルが何を表すか理解できるようにします。

3. スケーラビリティのためにタグを使用します

カタログが成長するにつれて、タグは各シグナル ID をリストアップせずに効率的な認可を可能にします。

4. 値タイプを明確に文書化します

カテゴリシグナルには常に allowed_values を含めます。数値シグナルには unit を含む range を含めます。

5. ファイルを最新の状態に保つ

シグナルが変更されたときは last_updated タイムスタンプを更新します。バイヤーはこれらのファイルをキャッシュします — 古いデータは認可の失敗を引き起こします。

ガバナンスメタデータの宣言

シグナル定義は2つのオプションフィールドをサポートします。restricted_attributes と policy_categories は構造的ガバナンスマッチングを有効にします。宣言されると、ガバナンスエージェントはシグナル名からの意味的推論に頼る代わりに、キャンペーンプランの制限に対して決定論的にシグナルをマッチできます。

restricted_attributes

シグナルが触れる GDPR 第9条の個人データの特別カテゴリを宣言します。値: racial_ethnic_origin、political_opinions、religious_beliefs、trade_union_membership、health_data、sex_life_sexual_orientation、genetic_data、biometric_data。

{
  "id": "chronic_condition_hh",
  "name": "Chronic Condition Households",
  "description": "Households with modeled indicators of chronic health conditions",
  "value_type": "binary",
  "tags": ["health", "demographic"],
  "restricted_attributes": ["health_data"]
}

キャンペーンプランが restricted_attributes: ["health_data"] を宣言すると、ガバナンスエージェントは説明を解釈することなくこのシグナルをブロックします。

policy_categories

シグナルが敏感なポリシーカテゴリを宣言します。ポリシーカテゴリは関連する規制レジームをグループ化します — children_directed は COPPA、英国 AADC、GDPR 第8条をカバーします。値はレジストリ定義のカテゴリ ID です。

{
  "id": "kids_cartoon_fans",
  "name": "Kids Cartoon Fans",
  "description": "Children aged 6-12 who watch animated content",
  "value_type": "binary",
  "tags": ["entertainment", "children"],
  "policy_categories": ["children_directed"]
}

両フィールドの組み合わせ

シグナルが制限された個人データに触れ、特定の規制レジームに関連する場合、両方を宣言できます:

{
  "id": "fertility_intent",
  "name": "Fertility Intent",
  "description": "Consumers researching fertility treatments",
  "value_type": "binary",
  "tags": ["health", "life_stage"],
  "restricted_attributes": ["health_data"],
  "policy_categories": ["pharmaceutical_advertising"]
}

ガバナンスメタデータがない場合、ガバナンスエージェントはシグナル名から感度を推論しなければなりません — これは脆弱で偽陽性を生みます。宣言された属性により決定論的なマッチングが可能になります。

get_adcp_capabilities との統合

シグナルエージェントは get_adcp_capabilities で利用可能なデータプロバイダーをアドバタイズします:

{
  "signals": {
    "data_provider_domains": ["pinnacle-auto-data.com", "meridian-analytics.com", "apex-segments.com"]
  }
}

これにより、エージェントがアクセスできるデータプロバイダーのカタログをバイヤーに伝えます。

次のステップ

adagents.json を作成する: シグナルカタログと共に
ドメインの /.well-known/adagents.json でホストする
AdAgents.json Builder を使ってバリデートする
データを再販するシグナルエージェントとパートナーシップを締結する
パートナーシップが確立されたら authorized_agents にエージェントを追加する

Getting Started

Building with AdCP

Governance Protocol

Signals Protocol

Curation Protocol

Sponsored Intelligence Protocol

Media Buy Protocol

Creative

Reference

Community

​データプロバイダーガイド

​問題

​解決策

​概要

​パラレルパターン

​ファイルの場所

​基本構造

​シグナル定義

​必須フィールド

​オプションフィールド

​シグナル値タイプ

​バイナリシグナル

​カテゴリシグナル

​数値シグナル

​認可パターン

​パターン1: シグナル ID（直接参照）

​パターン2: シグナルタグ（効率的なグループ化）

​シグナルタグ

​バイヤーによるカタログの使用方法

​1. 探索

​2. 認可確認

​3. ターゲティング

​エージェントネイティブシグナル

​シグナル ID 構造

​例: エージェントネイティブシグナル

​いつどちらを使うか

​完全な例

​位置情報データプロバイダーの例

​アイデンティティ/デモグラフィックプロバイダーの例

​リテールメディアプロバイダーの例

​バリデーション

​ベストプラクティス

​1. 説明的な ID を使用します

​2. 完全なメタデータを提供します

​3. スケーラビリティのためにタグを使用します

​4. 値タイプを明確に文書化します

​5. ファイルを最新の状態に保つ

​ガバナンスメタデータの宣言

​restricted_attributes

​policy_categories

​両フィールドの組み合わせ

​get_adcp_capabilities との統合

​次のステップ

​関連ドキュメント