> ## 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. # 3.0 から 3.1 への移行 > AdCP 3.0 統合を 3.1 安定リリースに移行するための焦点を絞ったアップグレードガイド。 # 3.0 から 3.1 への移行 **3.1 はリリース済みです。** 新しい 3.1 統合は、エージェントが `supported_versions` でそれをアドバタイズすることを確認した後に `"3.1"` をピン留めすべきです。既存の 3.0 統合は移行中 `"3.0"` にピン留めしたままでかまいません。 3.1 は 3.0 に対するマイナーリリースです。プロトコル変更は加算的です: 既存の 3.0 準拠エージェントは、リクエストやレスポンスの形状を変えずに `"3.0"` に留まれます。SDK、バイヤー、セラー、クリエイティブエージェント、シグナルエージェント、ブランドエージェント、またはコンプライアンスワークフローが 3.1 を主張または消費する準備をするとき、このガイドを使ってください。 機能の物語については [What's New in AdCP 3.1](/docs/reference/whats-new-in-3-1) から始めてください。完全なリリース記録については [リリースノート](/docs/reference/release-notes#version-3-1-0) を参照。 ## アップグレードチェックリスト | Step | Who | Action | | ---- | --------------- | ------------------------------------------------------------------------------------------------ | | 1 | 全員 | この統合が当面 `"3.0"` に留まるか `"3.1"` に移るかを決める。 | | 2 | SDK と手書きクライアント | すべてのリクエストに `adcp_version` リリースピンを追加する。`"3.1"` はそれをアドバタイズするエージェントにのみ送る。 | | 3 | セラーとエージェント | `get_adcp_capabilities.adcp.supported_versions` で受け入れるすべてのリリースをアドバタイズし、エンベロープルートで提供したリリースをエコーする。 | | 4 | バイヤー | `VERSION_UNSUPPORTED` をデコードし、セラーがアドバタイズしたバージョンに対してのみリトライする。 | | 5 | 手書きバイヤー | 3.1 動作を主張する前に、変更タスクと同様に読み取りタスクにも `idempotency_key` を追加する。 | | 6 | MCP と A2A アダプター | 未知のルートメンバーを拒否せずにエンベロープフィールドとトランスポートラッパーを受け入れる。 | | 7 | エラーハンドラー | `error.code` をオープン文字列として扱い、存在するとき `error.recovery` でディスパッチする。 | | 8 | コンプライアンスオペレーター | 3.1 ストーリーボードバンドルを実行し、3.1 バッジが発行されるまで 3.0 互換性ラインをグリーンに保つ。 | ## バージョンピン留め 3.0 統合はメジャーバージョンのみで交渉しました。3.1 はリリース精度ネゴシエーションを追加します: * 安定 3.0 トラフィックには `"3.0"` を使う。 * エージェントがアドバタイズした後、安定 3.1 トラフィックには `"3.1"` を使う。 * `"3.0.19"` のようなパッチ値や `"3.1.0-rc.15"` のような完全な semver プレリリースをワイヤー上で送らない。 セラーはサポートされないピンを `VERSION_UNSUPPORTED` で拒否し、`error.data.supported_versions` にサポートリリースリストを含めるべきです。バイヤーはマイナーリリースをまたいで黙ってダウンシフトすべきではありません。不一致をサーフェスするか、セラーが明示的にアドバタイズしたバージョンに対してリトライしてください。 ## 監査すべきランタイム変更 ### すべてのタスクの冪等性 3.0 は変更リクエストに `idempotency_key` を要求しました。3.1 は信頼性モデルをすべてのタスクに拡張し、リトライ、リプレイ、下流の再照合が一様に動作するようにします。SDK ユーザーはこの動作を SDK リリースから拾います。手書きバイヤーは、書き込みと同様に読み取りタスクにも UUID v4 冪等性キーを生成すべきです。 レスポンスが `replayed: true` とマークされたとき、それを元の操作の歴史的な結果として扱ってください。行動する前に新しい状態が必要な場合、リプレイされたレスポンスを処理した後に該当リソースを再読み取りしてください。 ### エンベロープ許容 3.1 は、トランスポートアダプターが AdCP エンベロープルートを許容することに依存します。MCP と A2A クライアントは、まずトランスポート固有のラッパーをアンラップし、次に `status`、`result`、`errors`、`adcp_version`、`replayed`、`context` などの AdCP フィールドを読むべきです。未知のエンベロープメンバーは拒否を引き起こしてはなりません。 ### エラーデコード 標準エラーカタログは 3.1 で拡張されましたが、`error.code` はオープン文字列のままです。クライアントは次をすべきです: * 未知のエラーコードを受け入れる。 * 存在するとき `error.recovery` を優先する。 * `error.recovery` が欠けているとき、未知のレガシーエラーに有界の transient フォールバックを適用する。 * `AUTH_MISSING` と `AUTH_INVALID` のあいだの auth 分割を扱う。 * `CREDENTIAL_IN_ARGS` を terminal として扱い、リトライ前に認証情報を適切なトランスポートチャネルに移す。 ### プロポーザルとアクションディスカバリーのクリーンアップ 3.1 は `proposal_status` をプロポーザルの真実の源泉にし、プロダクトとバイで構造化されたアクションディスカバリーを使います。セラーは GA 前の `requires_proposal` アクションモードを発すべきではありません。キャッシュされたプレリリースアクションメタデータを持つバイヤーは、それを無効化し、プロダクト、プロポーザル、バイのサーフェスを再読み取りすべきです。 ### ブランド検証署名 `verify_brand_claim` または `verify_brand_claims` を実装するブランドエージェントは、署名されたレスポンス証拠を返さなければなりません。ブランドごとのレスポンス署名鍵を公開し、署名をタスク、解決されたブランドテナント、応答エージェント URL、呼び出し元/リクエストハッシュ、有効期間にバインドしてください。 ### シグナルターゲティング シグナルアイデンティティは `SignalRef` に向かって移動し、プロダクトスコープの `included_signals`、`signal_targeting_options`、バイ時の `signal_targeting_groups` を伴います。所有シグナルディスカバリーとマーケットプレイスアクティベーションは別個のケイパビリティです。バイヤーは、エージェントがマーケットプレイスまたはアクティベーションサポートを宣言するときのみ `activate_signal` を呼ぶべきです。 ### クリエイティブフォーマットとトランスフォーマー クリエイティブエージェントは正準な `format_kind` 値を公開し、`list_transformers` を通じてビルドユニットを発見すべきです。フォーマット添付の入力/出力/価格宣言は、トランスフォーマースコープの設定と価格を優先して非推奨です。ホストされた音声/動画スロットは、固定 duration には `duration_ms_exact` を、有界または片側範囲には `duration_ms_range` を使うべきです。 ### レポートと課金 3.1 は配信と使用量の確定マーカー、リーチウィンドウセマンティクス、`viewability.viewed_seconds`、AdCP 外のクリエイティブ課金のための `BILLING_OUT_OF_BAND` エラーを追加します。バイヤーは、該当する確定フィールドが確定と言うまで配信数を確定として扱うのを避けるべきです。 ## ロールベースの移行 | Role | 3.1 を主張する前の最小限の準備 | | -------------- | ----------------------------------------------------------------------------------------------------------------------- | | SDK バイヤー | `adcp_version` を発し、セラーがサポートするとき `"3.1"` をピンし、冪等性キーを一貫して追加し、オープンエラーコードを受け入れる SDK にアップグレードする。 | | 手書きバイヤー | リリースピン、読み取りタスクの冪等性キー、エンベロープ許容、前方互換のエラーデコード、リプレイ処理を追加する。 | | セラー | `supported_versions` をアドバタイズし、提供したリリースをエコーし、エンベロープフィールドを許容し、サポートされないピンを `VERSION_UNSUPPORTED` で拒否し、冪等性/リプレイ/エラー動作を監査する。 | | クリエイティブエージェント | ディスカバリーを `list_transformers` に移し、正準フォーマットを公開し、レガシーフォーマット参照は互換性エイリアスとしてのみ保つ。 | | シグナルエージェント | 所有シグナルディスカバリーをマーケットプレイスアクティベーションから分離する。プロダクトスコープのターゲティングオプションは、バイヤーが選択できる場所でのみ公開する。 | | ブランドエージェント | レスポンス署名鍵を公開し、ブランド検証タスクに署名された証拠を返す。 | | コンプライアンスオペレーター | 3.1 ストーリーボードを実行し、3.0 互換性証拠を保持し、実際にテストされたリリースについてのみバージョンスコープのバッジを発行する。 | ## プレリリースアーティファクト 3.1 プレリリースアーティファクトは、検証中にそれらをピン留めした採用者のために利用可能なままですが、新しい統合は安定した `"3.1"` ワイヤー値を使うべきです。プレリリースに対して構築した場合、`requires_proposal` のようなプレリリースのみのフィールドを無効化し、現在のプロダクト/プロポーザル/アクションメタデータを再読み取りし、安定リリースを主張する前に 3.1 ストーリーボードバンドルを再実行してください。 ## 関連 * [What's New in AdCP 3.1](/docs/reference/whats-new-in-3-1) * [リリースノート](/docs/reference/release-notes#version-3-1-0) * [バージョンと互換性](/docs/reference/versions) * [バージョニングとガバナンス](/docs/reference/versioning) * [バージョン適応](/docs/building/cross-cutting/version-adaptation)