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

# build_creative へのバイヤー添付入力

> バイヤーが build_creative に添付する入力の共有コントラクトと、入力が生成をゲートするか単にステアリングするかを決める 1 つのガバナンス区別。

[`build_creative`](/docs/creative/task-reference/build_creative) は、バイヤーがビルドに添付する入力を受け入れます: 選択されたビルドケイパビリティ、レンダー構成、そして時とともにバイヤーが生成に尊重させたいコンテキストへのポインター。このページは、それらの入力が共有するコントラクトを定義し、各新しいポインターがガバナンスを再議論するのではなくそれを継承するようにします。重要な唯一の区別は、入力が、エージェントが検証しゲートする **強制ケイパビリティ入力** か、生成を情報提供するが AdCP 層でハードブロックしない **助言コンテキストポインター** かです。

境界は意図的で、プロトコルの残りに一致します: ケイパビリティは宣言され、ゲートされず、デフォルトは強制ではなく露出です。入力は、それがエージェントがエンドツーエンドで所有する型付きコントラクト — 有料レンダーを駆動するレンダー構成 — のときのみゲートします。他のすべてはステアリングします。

## バイヤー添付入力の 2 クラス

|                 | 強制ケイパビリティ入力                                  | 助言コンテキストポインター                                                                                                                                                             |
| --------------- | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **例**           | `transformer_id`、`config`                    | `signal_ref`（[#5240](https://github.com/adcontextprotocol/adcp/issues/5240)）、`evaluator`（[#5241](https://github.com/adcontextprotocol/adcp/issues/5241)）、権利 / プロベナンスポインター |
| **ステータス**       | 現在規範的                                        | 権利/プロベナンスは現在助言的。signal/evaluator は実験的                                                                                                                                     |
| **何をするか**       | ビルドを選択しパラメーター化する。エージェントはそれを検証しなければならない（MUST） | 生成をバイヤーコンテキストに向けて情報提供またはステアリング                                                                                                                                            |
| **不正/未知の入力で**   | フィールド帰属エラーで拒否                                | AdCP 層でハードブロックしない                                                                                                                                                         |
| **強制がどこに存在するか** | ビルド時のクリエイティブエージェント                           | 別の場所 — 認証情報層、トラフィッキング互換性チェック、またはセラー自身の検証                                                                                                                                  |

### 強制ケイパビリティ入力 — `transformer_id` + `config`

`transformer_id` は、ビルドを実行するアカウントスコープの transformer（[`list_transformers`](/docs/creative/task-reference/list_transformers) 経由で発見）を選択します。呼び出しごとに 1 transformer。`target_format_id` / `target_format_ids` は transformer の `output_format_ids` のサブセットでなければなりません（MUST）。レンダー構成は `config` に入ります。

`config` は、transformer の `params[]` の各 param の `field` でキーされた型付きバッグです。それはゲートし、正しくゲートします: [`build_creative`](/docs/creative/task-reference/build_creative) に従い、クリエイティブエージェントは、それらを黙って無視するのではなく **未知のキーと範囲外の値をフィールド帰属エラーで拒否しなければなりません（MUST）** — `config` は有料レンダーを駆動します。宣言された param でないベンダー固有のノブは、ここではなく `ext` に入ります。合法なキーは transformer ごとに動的なので、スキーマはオブジェクトをオープンに残します。したがって厳格な検証は規範的なエージェント義務です。

これは AdCP 層でビルドをハードブロックする唯一のバイヤー添付入力で、それは正しいものです: `config` はクリエイティブエージェントが所有し、アカウントごとに価格設定されるコントラクトで、誤キーされた値は誤ったレンダーに課金するでしょう。エージェントはこの表面を露出するため `creative.supports_transformers` を宣言し、`transformer` と `build_variant` は登録された `x-entity` タイプです。

### 助言コンテキストポインター — `signal_ref`、`evaluator`、権利 / プロベナンス

助言ポインターは、生成が尊重すべきバイヤーコンテキスト — オーディエンスシグナル、評価者の好み、権利またはプロベナンス参照 — を運びます。それらは情報提供またはステアリングします。AdCP 層で生成をハードブロックしてはなりません（MUST NOT）。ポインターが名指すもののために強制が存在する場合、それは `build_creative` ではなくそれを所有する層に存在します:

* **権利 / プロベナンス** — バイヤーのポインターではなく認証情報層（合成時の `generation_credentials`、ライブ失効の `rights_constraint.verification_url`）によって強制。
* **シグナル**（[#5240](https://github.com/adcontextprotocol/adcp/issues/5240)） — 強制が存在する場合、トラフィッキング互換性チェックに存在。
* **評価者**（[#5241](https://github.com/adcontextprotocol/adcp/issues/5241)） — 探索 & ランクガイダンス、リーフ上で `recommended` / `rank` として表示。ゲートではない。

これは、プロトコルが助言状態に既に使うレジスターをミラーします: バイヤーは、[`sync_creatives`](/docs/creative/task-reference/sync_creatives) `status` が「UI ヒントとポーリングスケジューリングシグナル — 支出承認ゲートではない」のと同じように、助言値に下流の支出またはパッケージアクティベーションをゲートしてはなりません（MUST NOT）。`keep_mode` はリクエスト側の同じ形状です — 助言のみ、返されるか課金されるものを変えません。

## 共有形状

すべてのバイヤー添付入力 — 強制または助言 — は同じ 3 部形状を継承します。これは今日 transformer に規範的で、将来のポインターが再利用するパターンです:

1. **アカウントスコープディスカバリー。** オプションは推測されず発見されます。`list_transformers` はアカウントスコープ、ブリーフフィルター可能、ページ化され、アカウントの構成されたオプション値（例えばそのアカウントにプロビジョンされたボイス）を列挙する `expand_params` モードを持ちます。別のオプションエンドポイントはありません — 列挙は 1 つのディスカバリータスクのモードです。将来のポインターのカタログは同じ方法で発見されます。

2. **アカウントごとの価格設定。** ケイパビリティは、アカウントごとに解決され、結果でリーフごとにエコーされ、`report_usage` 経由で照合される `pricing_options`（`vendor-pricing-option.json` を再利用）を運びます。どの価格オプションにも一致せずアンスコープデフォルトを持たない出力は `UNPRICEABLE_OUTPUT` を表示します。

3. **安定したリーフアンカーを持つ結果エンベロープ。** [`build_creative`](/docs/creative/task-reference/build_creative) は、各生成されたリーフを自身の `build_variant_id` — `preview_id`（プレビュー）、サーブされた `variant_id`（配信）、呼び出しレベルの `build_creative_id` と異なる名前空間 — とともに返します。リネージ、リファインメント親子関係、build→delivery 学習結合はすべてこのリーフ id でキーされ、各リーフは自身の価格設定レシートを運びます。保持されたリーフがトラフィックされるとき、その `build_variant_id` は通常、耐久性のある `creative_id` になります。[`get_creative_delivery`](/docs/creative/task-reference/get_creative_delivery) は次に `creative_id` を通じて結果を生成されたリーフに結合します。これは、評価者のスコアやシグナルのターゲティングがそれらのポインターが到達したときに添付するアンカーです。レスポンス形状コントラクトとリーフごとのフィールド仕組みは [`build_creative`](/docs/creative/task-reference/build_creative) タスクリファレンスに存在します。

## 権利はポインターで助言的。強制は認証情報

ビルドに添付された権利または [プロベナンス](/docs/creative/provenance) 参照は、助言 / 監査ポインターです。それは AdCP 層でビルドを認可せず、クリエイティブエージェントはそれに対して権利トークンを検証する義務を負いません。transformer の `voice_synthesis_ref[].rights_id` はこれを直接言います:

> これはプロベナンスメタデータのみで、build\_creative 権利トークンではありません。

権利の強制は既に出荷され、認証情報層に存在します — バイヤーのポインターではなく:

* **`generation_credentials`** は合成時にプロバイダー強制されます。権利エージェントはプロバイダーと調整してスコープされた認証情報を発行します。プロバイダーは生成時に `rights_key` を検証し、ゲートキーパーです。認証情報は `acquire_rights` の acquired 分岐で必須です。
* **`rights_constraint.verification_url`** はライブ失効チャネルです: 下流参加者（SSP、検証ベンダー）は、サーブ前に付与がアクティブであることを確認するためそれにヒットします — アクティブなら HTTP 200、失効なら 404。（`approval_status` はマニフェスト時のスナップショットで、ライブ値ではありません。）
* **`creative-manifest` `rights[]`** は情報的メタデータとしてクリエイティブとともに移動します: 「v1 では、権利制約は情報的メタデータです — バイヤー/オーケストレーターがこれらの条件に対してクリエイティブライフサイクルを管理します。」

バイヤー添付プロベナンスは、同じ [seller-publishes / buyer-represents / seller-confirms 分割](/docs/governance/creative/provenance-verification) に従います — バイヤーが宣言し、セラーが検証します。バイヤーの `verify_agent.agent_url` は、セラーの公開された `creative_policy.accepted_verifiers[]` の 1 つの [正準化された一致](/docs/reference/url-canonicalization) でなければなりません（MUST）。リスト外の URL は `PROVENANCE_VERIFIER_NOT_ACCEPTED` で拒否されます。その拒否は、任意のアウトバウンド呼び出しの前にセラーが自身の allowlist を強制することです — バイヤーのポインターがビルドをゲートすることではありません。バイヤーの添付結果は補足的です。検証を要求するセラーは、それらを信頼するのではなく自身の検出を実行します。

<Note>
  **確定した立場対 [#5261](https://github.com/adcontextprotocol/adcp/issues/5261)。** バイヤー添付 `rights_tokens[]` をハードクリエイティブエージェントゲートとして扱う提案は、このページに対して解決されました。バイヤーポインターでのハードゲートは、合成層で既に出荷される `generation_credentials` 強制プラスサーブ層での `verification_url` ライブ失効を再発明します。ポインターは助言的なまま。強制は認証情報層に留まります。唯一の実際のギャップは構造的で、欠けているゲートではありません: `voice_synthesis` は `provider` / `voice_id` / `settings` を運びますが、今日 `rights_id` 逆参照はありません。その逆参照の追加は前方項目です — それは助言/監査証跡を拡張し、ビルド時ゲートを導入しません。
</Note>

## 実験的助言ポインター

以下の助言ポインターはこのコントラクトの 2 番目のクラスに属し、相互運用が固まる間実験的なままです。それらは上の共有形状を継承します: 該当する場合アカウントスコープディスカバリー、該当する場合アカウントごとの価格設定、同じ結果エンベロープ。それらは強制クラスのビルド時ゲートを継承しません — それは `config` のようなクリエイティブエージェントが所有する型付きコントラクトに予約されています。

* **シグナル駆動クリエイティブファンアウト（[#5240](https://github.com/adcontextprotocol/adcp/issues/5240)、RFC）。** バイヤーは `build_creative` の `signal_conditions: SignalTargeting[]` にわたってファンアウトし、条件ごとに 1 クリエイティブグループを生成し、各々がそれが FOR である `signal_condition` でタグ付けされます。AdCP 層で助言的。トラフィッキング互換性（sun クリエイティブは rain ターゲットパッケージにサーブしてはならない、MUST NOT）は `SIGNAL_TARGETING_INCOMPATIBLE` 経由でセールス側で強制されます。#5240 は **既存のシグナルドメイン `SignalTargeting` / `signal-ref.json` を再利用** します — 新しいクリエイティブコンテキスト `signal_ref` は作られません — したがってクリエイティブの条件とセールス側パッケージターゲティングは 1 つの `signal_ref` アイデンティティを共有します。

<Warning>
  2 番目の `x-entity: signal` クリエイティブスキーマを作らないでください。#5240 の解決は、並行シグナル語彙を作るのではなく、クリエイティブ `signal_condition` に既存のシグナルドメイン `signal-ref.json`（`x-entity: signal`、`scope` 判別子）と `signal-targeting.json` を **再利用** することです — その共有アイデンティティが、セールスエージェントがクリエイティブの条件をパッケージターゲティングに対して一致できるようにするものです。シグナルポインターは助言クラスに留まります（ビルド時ゲートなし）。強制はトラフィッキング境界に存在します。
</Warning>

* **`evaluator` / `evaluator_id`（[#5241](https://github.com/adcontextprotocol/adcp/issues/5241)、実験的）。** バイヤーが添付するクリエイティブ評価者/オラクルで、エージェントが `best_of_n` 軸で代替を探索しランク付けでき、リーフに `recommended` / `rank` を表示します。助言的 — 好みシグナルで、セラー強制ゲートではありません。フィーチャー語彙と結果エンベロープのみがオンワイヤーで発見されます: 評価者フィーチャーディスカバリーは `get_adcp_capabilities.governance.creative_features` を再利用し、評価者結果は `get_creative_features` と同じ `creative-feature-result[]` 語彙を使います。実験的表面で使われる `evaluator_id` は、事前プロビジョンされたアカウント手配のハウスプリセットで、creative-feature カタログからの ID でもマーケットプレイス/プロバイダーアイデンティティでもありません。

  信頼境界は他のバイヤー添付ポインターと同じです: ペイロードは評価者を名指しまたは較正します。評価者認証情報や呼び出し元供給の信頼素材を運びません。外部評価者呼び出しは、リクエスト署名/JWKS、mTLS、または事前プロビジョンされた静的認証情報を使って、生成エージェントの評価者へのトランスポート接続で認証します。`evaluator`、`context`、`ext` は API キー、bearer トークン、クライアントシークレット、`Authorization` 値、JWK、JWKS 文書、JWKS URI を含んではなりません（MUST NOT）。認証情報または信頼素材ペイロードフィールドは `CREDENTIAL_IN_ARGS` として拒否されるべきです。

### 評価者ソースモデル

`evaluator` は 3 つの分離可能な層を持ちます:

* **Intent** はバイヤーが判断させたいものです。`feature_requirement[]`、`rank_by`、creative-feature 語彙を通じて表現されます。これらはゲート/ランクセマンティクスを定義し、評価者がどこから来たかではありません。
* **Source** は評価を実行するものです。クリーンなソース解決モデルはエージェント形状の評価者エンドポイントまたはアダプターです。現在の実験的表面では、それは生成エージェントが呼ぶことを許可されたバイヤー供給の `agent_url` として直接、セラーサポートの評価者エージェント/アダプターのアカウント手配 `evaluator_id` エイリアスとして、または予測パフォーマンススタイルフィーチャーを較正するインライン `exemplars` として現れます。
* **Discovery / marketplace** はバイヤーが評価者プロバイダーを見つける方法です。その層は、セラーが実際に解決できるハンドルやアダプターをアドバタイズしていない限り、AdCP コアの外側です。

現在のソース形式は異なるバイヤーパスにマップします:

| Buyer path             | Request form                              | Provisioning model                                                                                                                                                                           |
| ---------------------- | ----------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| プロビジョンされたアカウントハンドル     | `evaluator_id`                            | `list_evaluators` または後継ディスカバリー表面が出荷されるまで、セラーサポートの評価者エージェント/アダプターの双方向エイリアス。                                                                                                                   |
| BYOK API アダプター / 外部評価者 | `agent_url` または `feature_agent.agent_url` | セラー側カタログエントリーゼロだが、URL は依然として `creative_policy.accepted_verifiers[]` に一致しなければならない。リスト外の URL は `EVALUATOR_AGENT_NOT_ACCEPTED` で拒否。認証情報と信頼素材は `build_creative` ではなくトランスポートまたは事前プロビジョンされた接続に留まる。 |
| アーティファクトベースの履歴         | `exemplars`                               | プロビジョニングゼロ。バイヤーはこのリクエストの評価者フィーチャーを較正する良い / 悪いクリエイティブ例または説明を供給。                                                                                                                               |

その分割は、ディスカバリーをマーケットプレイスにせずに現在の動機付けケースをカバーします: 外部ブランド要件 API は `agent_url` / allowlist 検証者パスを使い、汎用 brand.json アライメントは allowlist されたエージェントまたはセラーサポートアカウントエイリアスで表現でき、良い / 悪いアーティファクトからの履歴パフォーマンスは `exemplars` を使います。

これは、並行 id カタログではなくエージェント形状評価者ソースにプロトコル境界を中心化します。将来の `list_evaluators` は、商業マーケットプレイス / プロバイダーディスカバリーではなく、セラーサポートの評価者エージェント/アダプターにスコープされるのが最善です。`evaluator_id` は、具体的な相互運用ケースがそのエージェント形状参照で表現できない場合のみ、耐久性のあるプリミティブとして残る必要があります。

アーティファクト事例ではなく配信履歴から訓練されるコンバージョン結果評価者には、4 番目のソース形式が必要かもしれません。それは `list_evaluators` / 評価者ディスカバリーフォローアップのオープンな設計問題のままで、この明確化はそれを凍結しません。