AdCP — Property Governance Specification

AdCP 3.0 提案 - この仕様は AdCP 3.0 向けに開発中です。フィードバックは GitHub Discussions へどうぞ。

Status: Request for Comments Last Updated: January 2026 本文書における「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「MAY」「OPTIONAL」は RFC 2119 の定義に従って解釈します。

Abstract

Property プロトコルは、プロパティの識別・認可・データ提供・選定のための標準 MCP/A2A インターフェースを定義します。これにより、パブリッシャーはプロパティと認可エージェントを宣言し、データプロバイダーはプロパティインテリジェンスを提供し、バイヤーは準拠したプロパティ集合を選択できます。

概要

The Property Protocol addresses four distinct concerns:

Concern	Question	Owner	Mechanism
Property Identity	どのプロパティが存在するか	Publishers	`adagents.json` の properties 配列
Sales Authorization	誰がこのプロパティを販売できるか	Publishers	`adagents.json` の authorized_agents
Property Data	このプロパティについて何がわかるか	Data providers	`get_adcp_capabilities` 経由のガバナンスエージェント
Property Selection	要件を満たすプロパティはどれか	Buyers	フィルター付きプロパティリスト

最初の 2 つは adagents.json による パブリッシャー側の宣言、後ろの 2 つはガバナンスエージェントのデータを用いる バイヤー側の処理 です。

プロパティデータと選定

プロパティデータと選定は ステートフル モデルです:

Feature discovery: Agents advertise what they can evaluate via get_adcp_capabilities
Property list management: CRUD operations for managed property lists with filters
Brand references: Let agents automatically apply rules based on brand identity
Webhook notifications: Real-time updates when resolved lists change
Marketplace architecture: Multiple specialized agents as subscription services

すべての評価（スコアリング、フィルタリング、ディスカバリ）は get_property_list でリストが解決されるときに暗黙的に行われます。

コア概念

リクエストの役割と関係

Every governance request involves two key roles:

Orchestrator (Buyer Agent)

ガバナンスエージェントへ API リクエストを送るプラットフォーム/システム。メディアバイ文脈ではしばしば「buyer agent」と呼びます。

Examples: DSP、トレーディングデスク、キャンペーン管理ツール
Responsibilities: API 呼び出し、認証、技術的なやり取りを管理
Account: ガバナンスエージェントへの技術的な資格情報と API アクセスを持ちます

Principal

リクエストを代理している主体:

Examples: 広告主（Nike）、代理店（Omnicom）、ブランドチーム
Responsibilities: キャンペーン目標やポリシー要件の所有者
Policies: 独自の閾値、ブロックリスト、コンプライアンス要件を持つ場合があります

プロパティ識別

Properties are identified using the standard AdCP property model:

{
  "property_type": "website",
  "name": "Example News",
  "identifiers": [
    { "type": "domain", "value": "example.com" }
  ],
  "supported_channels": ["display", "olv"]
}

プロパティタイプ: website, mobile_app, ctv_app, dooh, podcast, radio, streaming_audio。プロパティは supported_channels を宣言して在庫が対応する広告チャネルを示してもよい。

プロパティリスト参照

For large property sets, use property list references instead of embedding properties:

{
  "property_list_ref": {
    "agent_url": "https://lists.example.com",
    "list_id": "premium_news_sites",
    "auth_token": "eyJhbGciOiJIUzI1NiIs..."
  }
}

受信側エージェントがリストを取得・キャッシュすることで実現:

スケール: ペイロード肥大化なしに 50,000 件以上のプロパティを扱える
更新: リクエストを変えずにリストを進化させられます
認可: トークンでリストへのアクセスを制御

ガバナンスエージェントの種類

Compliance Agents

プロパティのコンプライアンスインテリジェンスを提供するベンダー:

Examples: データ整合性スコア、同意品質の測定
Business Model: サブスクリプションまたは従量課金
Methodology: 透明性のための公開ルーブリック

Brand Safety Agents

コンテンツ分類とリスク評価:

Examples: コンテンツカテゴライズ、ブランドセーフティスコアリング
Coverage: チャンネルや地域に特化する場合があります

Quality Agents

パフォーマンスと不正計測:

Examples: Viewability 予測、IVT 検知
Integration: キャンペーン成果と相関させる場合があります

スコアリングとデータプライバシー

スコアは内部のみ

重要な設計原則: 生のスコアはバイヤーや下流クライアントに共有しません。データ漏洩を防ぎます。ガバナンスエージェントは内部スコアモデルを保持しますが、プロトコルはスコアを露出させず リスト管理 を中心に設計されています:

Buyers specify thresholds via feature_requirements (e.g., "min_value": 85)
Agents return pass/fail lists of properties that meet the thresholds
Raw scores never leave the governance agent

この設計により以下を防ぎます:

スコア逆算のための列挙攻撃（閾値を変えたリスト要求など）
競合インテリジェンスの漏洩
スコアデータの転売によるアービトラージ

バイヤーが受け取るもの

When calling get_property_list, buyers receive a compact list of identifiers (not full property objects) for efficiency:

{
  "list_id": "pl_abc123",
  "identifiers": [
    { "type": "domain", "value": "bbc.co.uk" },
    { "type": "domain", "value": "theguardian.com" },
    { "type": "domain", "value": "ft.com" }
  ],
  "total_count": 847
}

閾値を通過したプロパティのみが含まれ、落ちたプロパティは除外されます。スコアやメタデータは返さず、入札時参照に必要な識別子のみを返します。

メソドロジーの開示

The get_adcp_capabilities task returns information about what features an agent evaluates and their methodology, but NOT the underlying scores:

{
  "features": [
    {
      "feature_id": "mfa_score",
      "name": "Made For Advertising Score",
      "type": "quantitative",
      "range": { "min": 0, "max": 100 },
      "methodology": "mfa_detection",
      "methodology_version": "v2.1",
      "methodology_url": "https://quality.example.com/methodology"
    }
  ]
}

これによりバイヤーは:

エージェントが何を測っているか把握
エージェント間でメソドロジーを比較
適切な閾値を設定

ただし個々のプロパティの実スコアを取得することはできません。

タスク

ディスカバリ

get_adcp_capabilities

ガバナンスエージェントが評価できる機能を発見します。 ユースケース:

機能ディスカバリ: 何を評価できるか把握
マーケットプレイス閲覧: エージェント間で機能比較
統合計画: リスト作成前に利用可能なフィルターを把握

プロパティリスト管理

create_property_list

フィルターと任意の Brand Manifest を伴うプロパティリストを新規作成します。 必須パラメータ:

countries_all に少なくとも 1 つの国（ISO 3166-1 alpha-2）
channels_any に少なくとも 1 つのチャネル（display, video, audio など）

Base Properties: 評価対象となるプロパティソースの配列。各要素は selection_type を識別子とする判別可能ユニオンです:

publisher_tags: { "selection_type": "publisher_tags", "publisher_domain": "...", "tags": [...] } - パブリッシャー内のタグ
publisher_ids: { "selection_type": "publisher_ids", "publisher_domain": "...", "property_ids": [...] } - パブリッシャー内の property_id
identifiers: { "selection_type": "identifiers", "identifiers": [...] } - パブリッシャーコンテキスト不要
Omitted: エージェントのプロパティ DB 全体を参照

base-property-source schema で完全な仕様を確認してください。 フィルタロジック（フィールド名に明示）:

countries_all: 指定されたすべての国のフィーチャーデータが必要（AND）
channels_any: 指定されたチャネルのいずれかをサポートしていれば可（OR）
feature_requirements: すべての要件を満たす（AND）

ユースケース:

フィルター（国、チャネル、フィーチャー閾値）で準拠リストを定義
Brand Manifest を渡してルールを自動適用
変更通知用の Webhook を登録

update_property_list

既存のプロパティリストを更新します。 ユースケース:

ベースリストにプロパティを追加/削除
キャンペーン要件に応じてフィルター調整
Webhook URL の更新

get_property_list

解決済みプロパティリストを取得します。 ユースケース:

フィルター適用後の準拠リストを取得
入札時利用のためリストをキャッシュ
Webhook 通知後に更新版を取得

list_property_lists

認証済みプリンシパルがアクセスできるプロパティリストを列挙します。

delete_property_list

プロパティリストを削除します。

Validation

validate_property_delivery

配信記録をプロパティリストに照らして準拠性を判定し、「意図」と「結果」を突き合わせます。独立した 2 つの検証を行います:

プロパティ準拠: 識別子が解決済みリストに含まれるか
サプライパス認可: セールスエージェントがそのプロパティを販売する権限を持つか（任意、sales_agent_url が必要）

ユースケース:

ポストキャンペーン検証: インプレッションが準拠プロパティに配信されたか確認
サプライパス検証: セールスエージェントがパブリッシャーに認可されているか確認
リアルタイム監視: 実行中キャンペーンの準拠率を確認
監査証跡: 規制/ブランドセーフティ審査向けにレポート生成

プロパティ検証ステータス:

compliant: 識別子が解決済みリストに含まれます
non_compliant: 識別子が解決済みリストに含まれない
not_covered: 識別子は認識したが当該プロパティのデータがない（新規など）
unidentified: このエージェントでは解決できない識別子（検出失敗・非対応）

認可検証ステータス（sales_agent_url を提供した場合）:

authorized: セールスエージェントが adagents.json に記載されています
unauthorized: authorized_agents に記載されていません
unknown: adagents.json を取得/解析できません

検証不能レコード: not_covered と unidentified は準拠率計算から除外すべきです。データカバレッジの不足と識別子解決の問題を区別できます。 レスポンス形式: 準拠/非準拠/not_covered/unidentified の生カウントを返します。必要に応じてクライアントサイドで率を計算します。オプションで aggregate フィールドに算出指標（スコア、グレード、ラベルなど）を含めることもできます（フォーマットはエージェント依存）。

Typical Flows

Property List Flow

Property lists enable buyers to define and manage compliant property sets:

Create property list: Buyer defines list on governance agent with filters
Resolve and iterate: Buyer calls get_property_list to see resolved properties
Share list reference: Buyer provides list_id to orchestrator/seller
Cache locally: Orchestrator/seller fetches and caches resolved properties
Use at bid time: Orchestrator/seller uses local cache (no governance agent calls)
Refresh periodically: Re-fetch based on cache_valid_until (typically 1-24 hours)

Important: Governance agents are NOT in the real-time bid path. All bid-time decisions use locally cached property sets.

Webhook and Caching Pattern

Webhooks provide notification that a property list has changed. The webhook payload contains a summary of changes, but you must call get_property_list to retrieve the actual updated properties.

┌─────────────────────────────────────────────────────────────────┐
│                     Webhook Flow                                │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  1. Governance agent re-evaluates properties (background)       │
│  2. Webhook fires with change summary (added/removed counts)    │
│  3. Recipient calls get_property_list to fetch updated list     │
│  4. Recipient updates local cache                               │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Best Practices for Downstream Consumers: Consumers of property lists (orchestrators, sellers, buyer agents) should implement at least one of these patterns:

Webhook-driven updates (recommended): Register a webhook URL when creating the property list. Re-fetch via get_property_list when notified of changes.
Polling with cache hints: Use cache_valid_until from get_property_list responses to schedule periodic re-fetches. Typical validity periods are 1-24 hours.
Hybrid approach: Use webhooks for immediate updates, with polling as a fallback safety net.

Cache Expiry Guidance: Every get_property_list response includes:

resolved_at: When the list was evaluated
cache_valid_until: When consumers should consider the cache stale

{
  "resolved_at": "2026-01-04T10:00:00Z",
  "cache_valid_until": "2026-01-04T22:00:00Z"
}

Consumers MUST NOT use cached data beyond cache_valid_until without re-fetching.

Property Discovery Flow

Define filters: Specify country, channel, quality thresholds when creating property list
Resolve list: Call get_property_list with resolve=true to get matching properties
Review candidates: Evaluate returned properties for fit
Add to campaign: Include property list reference in media buy

Response Structure

All AdCP Governance responses follow a consistent structure:

Core Response Fields

message: Human-readable summary of the operation result
context_id: Session continuity identifier for follow-up requests
data: Task-specific payload (varies by task)

Protocol Transport

MCP: Returns complete response as flat JSON object
A2A: Returns as structured artifacts with message in text part, data in data part
Data Consistency: Both protocols contain identical AdCP data structures

Error Handling

Error Codes

PROPERTY_NOT_FOUND: Property identifier not recognized
PROPERTY_NOT_MONITORED: Governance agent doesn’t cover this property
POLICY_NOT_FOUND: Referenced policy doesn’t exist
LIST_ACCESS_DENIED: Cannot access property list (auth failed)
LIST_NOT_FOUND: Property list reference invalid
METHODOLOGY_NOT_SUPPORTED: Requested methodology version unavailable
PARTIAL_RESULTS: Some properties couldn’t be evaluated

Partial Success

For bulk operations, the response may include partial results:

{
  "message": "Evaluated 847 of 850 properties. 3 properties not in coverage.",
  "context_id": "ctx-gov-123",
  "scores": [...],
  "errors": [
    {
      "code": "PROPERTY_NOT_MONITORED",
      "property": { "identifiers": [{ "type": "domain", "value": "unknown.com" }] },
      "message": "Property not in monitoring coverage"
    }
  ]
}

Implementation Notes

Caching Architecture

Governance decisions are highly cacheable:

Orchestrator-Side Caching

Score cache: Store scores with TTL from valid_until field
Decision cache: Pre-compute pass/fail for campaigns
List cache: Cache property lists from property_list_ref

Agent-Side Caching

Profile cache: Maintain pre-computed property profiles
Methodology cache: Cache scoring algorithm results

Performance Requirements

Operation	Target Latency
Single property score	< 100ms
Bulk scoring (100 properties)	< 2s
Filter decision (cached)	< 5ms
Property discovery	< 5s

Multi-Agent Strategies

Orchestrators may consult multiple governance agents:

Primary + Validation: Use primary agent, validate with secondary
Specialization: Route by property type to specialist agents
Consensus: Require multiple agents to agree
Competitive: Track agent accuracy, weight by performance

Agent Discovery

There are two complementary discovery mechanisms:

Publisher-Side Discovery via adagents.json

Publishers declare which governance agents have data about their properties using the property_features field in adagents.json:

{
  "property_features": [
    {
      "url": "https://api.scope3.com",
      "name": "Scope3",
      "features": ["carbon_score", "sustainability_grade"],
      "publisher_id": "pub_12345"
    },
    {
      "url": "https://api.onetrust.com",
      "name": "OneTrust",
      "features": ["gdpr_compliant", "tcf_registered", "ccpa_compliant"]
    }
  ]
}

This solves the discovery problem: buyers don’t need to query every possible governance agent. Instead, they read property_features from the publisher’s adagents.json to find which agents have relevant data. See the adagents.json Tech Spec for the complete discovery workflow.

Agent-Side Discovery via agent-card.json

Governance agents expose capabilities via .well-known/agent-card.json:

{
  "name": "Example Compliance Provider",
  "url": "https://compliance.example.com",
  "capabilities": {
    "tasks": [
      "get_adcp_capabilities",
      "create_property_list",
      "get_property_list",
      "update_property_list",
      "delete_property_list",
      "list_property_lists",
      "validate_property_delivery"
    ],
    "protocols": ["MCP", "A2A"],
    "schema_version": "v1"
  },
  "methodology": {
    "documentation_url": "https://compliance.example.com/methodology",
    "scoring_frameworks": ["data_integrity_index", "brand_safety_score"],
    "coverage": {
      "property_types": ["website", "mobile_app", "ctv_app"],
      "jurisdictions": ["GDPR", "CCPA", "COPPA"]
    }
  }
}

Detailed Capability Discovery

Use get_adcp_capabilities for detailed capability discovery:

{
  "tool": "get_adcp_capabilities",
  "arguments": {}
}

Returns the specific features the agent can evaluate (consent_quality, carbon_score, brand_risk, etc.).

Marketplace Architecture

The Property Protocol enables a marketplace of specialized data agents:

┌─────────────────────────────────────────────────────────────────────────┐
│                         SELLER AGENT (DSP/SSP)                          │
│  "Give me the compliant property list for this campaign"                │
└───────────────────────────────┬─────────────────────────────────────────┘
                                │
                                ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                    BUYER AGENT (implements Property Protocol)           │
│  - Exposes: get_adcp_capabilities, get_property_list, webhooks         │
│  - Source of truth for final compliant list                             │
│  - Intersects results from specialized agents                           │
└───────────────────────────┬─────────────────────────────────────────────┘
                            │
        ┌───────────────────┼───────────────────┐
        ▼                   ▼                   ▼
┌───────────────┐   ┌───────────────┐   ┌───────────────┐
│ Consent Agent │   │ Scope3 Agent  │   │ Brand Safety  │
│ (Compliant)   │   │               │   │    Agent      │
├───────────────┤   ├───────────────┤   ├───────────────┤
│ Features:     │   │ Features:     │   │ Features:     │
│ consent_qual  │   │ carbon_score  │   │ content_cat   │
│ tcf_version   │   │ climate_risk  │   │ brand_risk    │
│ coppa_cert    │   │ green_host    │   │ sentiment     │
├───────────────┤   ├───────────────┤   ├───────────────┤
│ Subscription  │   │ Subscription  │   │ Subscription  │
└───────────────┘   └───────────────┘   └───────────────┘

Key Principles

Buyer agent is source of truth: The buyer agent aggregates data from multiple specialized governance agents
Seller sees one interface: Sellers interact only with the buyer agent using standard Property Protocol
Subscription model: Each specialized agent is a paid service with its own features and coverage
Webhook-driven updates: Specialized agents notify the buyer agent when property evaluations change

Multi-Agent Orchestration

A buyer agent can distribute a master property list to multiple specialized agents:

# Buyer agent creates variants on each specialized agent
consent_list = consent_agent.create_property_list(
    name="Q1 Campaign - Consent",
    base_properties=master_list,
    brand=brand
)
# Configure webhook for updates
consent_agent.update_property_list(
    list_id=consent_list.list_id,
    webhook_url="https://buyer.example.com/webhooks/consent"
)

scope3_list = scope3_agent.create_property_list(
    name="Q1 Campaign - Sustainability",
    base_properties=master_list,
    brand=brand
)
scope3_agent.update_property_list(
    list_id=scope3_list.list_id,
    webhook_url="https://buyer.example.com/webhooks/scope3"
)

# Buyer agent intersects filtered results
def on_list_changed(event):
    consent_props = consent_agent.get_property_list(consent_list.list_id, resolve=True)
    scope3_props = scope3_agent.get_property_list(scope3_list.list_id, resolve=True)

    # Intersection = properties that pass ALL governance agents
    compliant_props = intersect(consent_props, scope3_props)

    # Update buyer agent's exposed list
    update_compliant_list(compliant_props)

Brand

複雑なフィルターを指定する代わりに、バイヤーはブランド参照を提供します:

{
  "brand": {
    "domain": "toybrand.com"
  }
}

各ガバナンスエージェントはブランドのアイデンティティを解決し、専門領域に応じてルールを適用します:

Consent agent: 子ども向けブランドに対して COPPA 要件を適用
Brand safety agent: 適切なコンテンツにフィルタリング、暴力/アダルトを除外
Sustainability agent: グリーンメディア要件を適用

バイヤーは具体的なルールを知る必要がなく、自分が誰かを宣言すれば、エージェントが何を適用するかを判断します。

Integration with Media Buy Protocol

Property Lists in Media Buys

The Media Buy Protocol accepts property list references:

{
  "task": "create_media_buy",
  "arguments": {
    "packages": [{
      "property_list_ref": {
        "agent_url": "https://governance.example.com",
        "list_id": "approved_q1_campaign",
        "auth_token": "..."
      }
    }]
  }
}

Policy Compliance

Media buys can reference governance policies via property list references:

{
  "compliance_requirements": {
    "property_list_ref": {
      "agent_url": "https://compliance.example.com",
      "list_id": "pl_q1_compliant",
      "auth_token": "eyJhbGciOiJIUzI1NiIs..."
    }
  }
}

Best Practices

Cache aggressively: Property scores change slowly; cache for hours/days
Bulk where possible: Use batch operations for planning, not per-property calls
Pre-compute decisions: Build pass/fail lookups before bid-time
Monitor coverage: Track which properties agents don’t cover
Log methodology versions: For audit trails, record which scoring version was used
Handle partial results: Not all properties will be scorable; plan for gaps

Next Steps

See the adagents.json Tech Spec for property declaration and authorization
See the get_adcp_capabilities task reference for capability discovery
See the Property List Management for CRUD operations and webhooks
See the validate_property_delivery task reference for post-campaign compliance validation

​Abstract

​概要

​プロパティデータと選定

​コア概念

​リクエストの役割と関係

​Orchestrator (Buyer Agent)

​Principal

​プロパティ識別

​プロパティリスト参照

​ガバナンスエージェントの種類

​Compliance Agents

​Brand Safety Agents

​Quality Agents

​スコアリングとデータプライバシー

​スコアは内部のみ

​バイヤーが受け取るもの

​メソドロジーの開示

​タスク

​ディスカバリ

​get_adcp_capabilities

​プロパティリスト管理

​create_property_list

​update_property_list

​get_property_list

​list_property_lists

​delete_property_list

​Validation

​validate_property_delivery

​Typical Flows

​Property List Flow

​Webhook and Caching Pattern

​Property Discovery Flow

​Response Structure

​Core Response Fields

​Protocol Transport

​Error Handling

​Error Codes

​Partial Success

​Implementation Notes

​Caching Architecture

​Orchestrator-Side Caching

​Agent-Side Caching

​Performance Requirements

​Multi-Agent Strategies

​Agent Discovery

​Publisher-Side Discovery via adagents.json

​Agent-Side Discovery via agent-card.json

​Detailed Capability Discovery

​Marketplace Architecture

​Key Principles

​Multi-Agent Orchestration

​Brand

​Integration with Media Buy Protocol

​Property Lists in Media Buys

​Policy Compliance

​Best Practices

​Next Steps

Abstract

概要

プロパティデータと選定

コア概念

リクエストの役割と関係

Orchestrator (Buyer Agent)

Principal

プロパティ識別

プロパティリスト参照

ガバナンスエージェントの種類

Compliance Agents

Brand Safety Agents

Quality Agents

スコアリングとデータプライバシー

スコアは内部のみ

バイヤーが受け取るもの

メソドロジーの開示

タスク

ディスカバリ

get_adcp_capabilities

プロパティリスト管理

create_property_list

update_property_list

get_property_list

list_property_lists

delete_property_list

Validation

validate_property_delivery

Typical Flows

Property List Flow

Webhook and Caching Pattern

Property Discovery Flow

Response Structure

Core Response Fields

Protocol Transport

Error Handling

Error Codes

Partial Success

Implementation Notes

Caching Architecture

Orchestrator-Side Caching

Agent-Side Caching

Performance Requirements

Multi-Agent Strategies

Agent Discovery

Publisher-Side Discovery via adagents.json

Agent-Side Discovery via agent-card.json

Detailed Capability Discovery

Marketplace Architecture

Key Principles

Multi-Agent Orchestration

Brand

Integration with Media Buy Protocol

Property Lists in Media Buys

Policy Compliance

Best Practices

Next Steps