> ## 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. # 認証 > AdCP 認証ガイド: 公開操作と認証必須操作の使い分け、静的クレデンシャルの実装、バイヤーおよびセラーエージェント向けの認証情報管理。 AdCP では、公開操作と認証必須の操作を使い分ける段階的な認証モデルを採用しています。 ## 認証が必要な場面 ### 公開操作（認証不要） 探索や評価のため、以下は認証なしで利用できます: * **`get_adcp_capabilities`** - エージェントの機能、ポートフォリオ、対応機能の取得 * **`list_creative_formats`** - 利用可能なクリエイティブ形式の閲覧 * **`get_products`** - 在庫の探索（認証なしでは結果が限定） **理由**: パブリッシャーは、ビジネス関係を結ぶ前に購入者に自社の提供内容を知ってもらいたいため。 **重要**: 未認証の `get_products` は以下のように制限される場合があります: * 一部のカタログ（標準商品）のみ * 価格情報や CPM の非表示 * カスタム商品なし * 汎用的なフォーマット対応のみ ### 認証が必要な操作 以下の操作には有効な認証情報が必要です: * **`get_products`** (full access) - Complete catalog with pricing and custom products * **`create_media_buy`** - Create advertising campaigns * **`update_media_buy`** - Modify existing campaigns * **`sync_creatives`** - Upload creative assets * **`list_creatives`** - View your creative library * **`get_media_buy_delivery`** - Monitor campaign performance and metrics * **`provide_performance_feedback`** - Submit optimization signals **理由**: 金銭が絡む取引、機密データへのアクセス、稼働中キャンペーンの変更が含まれるため。 ## 認証方式 AdCP は認証必須操作向けに 3 つの認証メカニズムをサポートします。選択は操作のリスククラスと使用する AdCP バージョンによります: | メカニズム | 3.0（現行） | 3.1+ | 備考 | | ---------------------------------------------- | ----------------------- | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | **RFC 9421 リクエスト署名** | すべての認証必須操作で RECOMMENDED | 変更系 / 金融操作で **REQUIRED** | 非対称、ボディ束縛、リプレイ耐性。[RFC 9421 リクエスト署名](/docs/building/by-layer/L1/security#request-signing)を参照。 | | **相互 TLS（mTLS）** | 任意の操作で許可 | 9421 の代替として許可 | トランスポート層のアイデンティティ。デプロイがすでにエッジで mTLS を終端している場合に推奨。 | | **静的 Authorization クレデンシャル（Bearer または Basic）** | 許可。3.0 の実効的なベースライン | 変更系 / 金融操作で **PROHIBITED**、読み取り / ディスカバリーのみ許可 | 共有シークレットのトランスポート。Bearer が正規の例。HTTP Basic も TLS 上で送信され保護された各リクエストで検証される場合は許容される。変更系操作については廃止予定が文書化されている — [既知の制限](/docs/reference/known-limitations)を参照。 | **3.0 の変更系操作の下限。** 3.1 が到着するまで、TLS 上の静的 Authorization ヘッダークレデンシャルが変更系操作の実効的な下限です。支出コミットメントを扱う運用者は、強制的な切り替えを避けるため、3.1 の廃止日より前に RFC 9421 リクエスト署名を出荷すべきです（SHOULD）。 ### 静的 Authorization クレデンシャル（3.0 ベースライン） ``` Authorization: Bearer Authorization: Basic ``` Bearer トークンの種類: * **Opaque tokens**: サーバーで検証されるエージェント紐づけ文字列 * **JWT tokens**: クレームを埋め込んだ自己完結型トークン HTTP Basic クレデンシャルも静的な共有シークレットメカニズムです。TLS 上で `Authorization` ヘッダーに載せて送信しなければならず（MUST）、サーバーは保護された各リクエストでクレデンシャルを検証しなければなりません（MUST）。Basic クレデンシャルは Bearer トークンより強力ではありません。両者ともトランスポート上に事前プロビジョニングされた共有シークレットを載せるため、同じコンフォーマンスクラスとして受け入れられます。 実装はすべての静的クレデンシャル認証エンドポイントで TLS 1.2+ を強制しなければなりません（MUST）。トランスポート要件は[実装セキュリティリファレンス](/docs/building/by-layer/L1/security)を参照してください。 クレデンシャルは `Authorization` リクエストヘッダーで運ばなければなりません（MUST）。セラーは非正規のエイリアス（例: 一部の初期 MCP 専用デプロイに現れた `x-adcp-auth`）を要求してはならず（MUST NOT）、エージェントカード・機能レスポンス・ドキュメントでサポート対象ヘッダーとして宣伝してもなりません（MUST NOT）。セラーは既存アダプターの統合を段階的に廃止する間、そのようなエイリアスを移行的な入力として受け入れてもよい（MAY）が、同じエンドポイントで `Authorization: Bearer` または `Authorization: Basic` も受け入れなければなりません（MUST）。バイヤーエージェントと SDK は、セラーが明示的に Basic クレデンシャルをプロビジョニングしない限り `Authorization: Bearer` を発行すべきです（SHOULD）。SDK の例やドキュメント文字列で、エイリアスヘッダーを正規の形として示してはなりません（MUST NOT）。 ### RFC 9421 リクエスト署名（推奨。3.1+ の変更系操作で必須） 署名付きリクエストは、`@method`、`@target-uri`、`@authority`、`content-type`、`content-digest` を、±60 秒のタイムスタンプウィンドウと 128 ビット以上のノンス付きで `Ed25519`、`ecdsa-p256-sha256`、または `rsa-pss-sha512` 署名の下に束縛します。完全な検証器チェックリスト、鍵ディスカバリールール（`brand.json` → `agents[]` → `jwks_uri`）、ローテーションセマンティクスは[実装セキュリティリファレンス](/docs/building/by-layer/L1/security#request-signing)で定義されています。`get_adcp_capabilities.request_signing.supported` による機能ディスカバリーにより、クライアントは変更系呼び出しを送信する前にセラーが署名を強制するかどうかを検出できます。 ### mTLS エッジで mTLS を終端する運用者は、AdCP 操作の主要なアイデンティティメカニズムとしてピア証明書を使用してもよい（MAY）。mTLS を使用する場合、運用者はいかなるヘッダーフィールドでもなく証明書のサブジェクト / SAN にアイデンティティをピン留めしなければなりません（MUST）。 ### JWT のクレーム When using JWT tokens, include these standard claims: ```json theme={null} { "sub": "agent_123", "exp": 1706745600, "iat": 1706742000 } ``` 認可のために追加クレームを求める sales agent もあります。 ## エージェントとアカウント AdCP は **エージェント**（リクエストを実行する主体）と **アカウント**（課金対象）を区別します: * **エージェント**: API 呼び出しを行う認証済みエンティティ（トークンで識別） * **アカウント**: 料率と請求を決定する課金関係 エージェントは複数のアカウントにアクセスできる場合があります（例: 複数クライアントを管理する代理店）。アカウントの選択と課金の帰属については [Accounts and Agents](/docs/building/by-layer/L2/accounts-and-agents) を参照してください。 スキーマ定義は [`account.json`](https://adcontextprotocol.org/schemas/v3/core/account.json) を参照してください。 ## テナント解決 AdCP はテナントをリクエストペイロードからではなく、認証済みプリンシパルから解決します。セラーエージェントは、認証済みアイデンティティ（bearer トークン、Basic クレデンシャル、mTLS クライアント証明書、または RFC 9421 鍵）を、自身の認可コンテキストを介して発信元バイヤーのアカウントにマッピングします。タスクペイロードが認証の代替としてテナントアイデンティティを運ぶことは決してありません。スキーマが `account` エンベロープではなくグローバルに一意なリソース ID（`plan_id`、`rights_id`、`standards_id`、`event_source_id`、`list_id`）を要求する場合、セラーは同じ認可コンテキストを介して ID → テナントを解決します。認証済みプリンシパルは参照されたリソースへのアクセス権を持たなければならず、リソース自体はそれがプロビジョニングされたブランドを保持します。それらの呼び出しでのエンベロープアイデンティティは冗長であり、認証済みプリンシパルと食い違えばスプーフィングのベクトルになります。 トレーニングエージェントのコンプライアンスストーリーボードは、これらの呼び出しにサンドボックスのルーティング規約としてエンベロープアイデンティティを注入します。トレーニングエージェントは自身の認証済みプリンシパル層を持たないためです — [ストーリーボード作成](/docs/contributing/storyboard-authoring)を参照してください。本番のセラーはそれを必要としません。 ## クレデンシャルの配置 **バイヤープリンシパル**を認証するクレデンシャルは、トランスポートの認証チャネルに到着しなければならず（MUST）、タスクペイロード — トップレベル、`context` 内、`ext` 内、その他あらゆるネストされた場所 — に置いてはなりません（MUST NOT）。トランスポートチャネルは次のとおりです: * **HTTP 上の静的クレデンシャル** — [RFC 6750 §2](https://www.rfc-editor.org/rfc/rfc6750#section-2) に従う `Authorization: Bearer `、またはセラーが HTTP Basic クレデンシャルをプロビジョニングする場合は `Authorization: Basic `。 * **RFC 9421 署名付きリクエスト** — [RFC 9421 §2](https://www.rfc-editor.org/rfc/rfc9421#section-2) に従う `Signature` および `Signature-Input` ヘッダー。署名自体がクレデンシャルであり、ペイロード内には署名者を認証するものは何もありません。 * **MCP および A2A の認証フレーミング** — トランスポートの認証記述子（例: MCP の `authInfo`、A2A の `authentication.schemes`）。認証要件のディスカバリーは、該当する場合 [RFC 9728 §3](https://www.rfc-editor.org/rfc/rfc9728#section-3) の保護リソースメタデータに従います。 * **相互 TLS** — 上表の mTLS 行に従うピア証明書。 このルールはトランスポート非依存です。セラーがどのメカニズムを受け入れるかに関わらず適用されます。バイヤープリンシパルがペイロードフィールドを介して認証する AdCP バージョン・機能・セラーポリシーは存在しません。同じ配置ルールは、リクエストがダウンストリームの評価器呼び出しのために渡そうとするクレデンシャルや呼び出し元提供の信頼素材にも適用されます。それらはエージェント間 - 評価器間トランスポート、またはアカウントプロビジョニングに属し、タスクペイロードには属しません。ペイロード内でクレデンシャルまたは信頼素材のキー（例: 任意のネスト深度の `_access_token`、`api_key`、`client_secret`、`bearer`、`authorization`、`jwk`、`jwks`、`jwks_uri`）を検出したセラーは、AdCP 3.1 の下でリクエストを [`CREDENTIAL_IN_ARGS`](/docs/building/by-layer/L3/error-handling#authentication-and-access) で拒否すべきです（SHOULD）。この要件は 3.1 公開日の 90 日後に MUST に格上げされます。このコードのリカバリー分類は `terminal` です。エージェントは自動リトライしてはなりません（MUST NOT）。自動リトライは試行ごとにクレデンシャルを再ログし、それ自体がこのルールが塞ぐプロンプトインジェクションの流出面だからです（[エージェント広告に固有の脅威](/docs/building/concepts/security-model#threats-specific-to-agentic-advertising)を参照）。 ### カーブアウト 以下のクレデンシャル面は**バイヤープリンシパル**のクレデンシャルでは**なく**、上記のルールは適用されません: * **`push_notification_config.authentication.credentials`**（[スキーマ](https://adcontextprotocol.org/schemas/v3/core/push-notification-config.json)）。これは、**セラー**がバイヤーの Webhook エンドポイントに**折り返し**呼び出す際に使用するレガシー Bearer / HMAC-SHA256 クレデンシャルです。セラーを呼び出し元として、バイヤーを受信側として認証します — インバウンドの AdCP リクエストを認証するバイヤープリンシパルのクレデンシャルとは直交します。デフォルトの 9421 Webhook プロファイルは `brand.json` で発見された鍵を使用し、共有シークレットを一切交換しません。レガシーブロックは AdCP 4.0 で削除される非推奨の互換スキームです。 * **帯域外で交換されるオンボーディング時のシークレット** — 初回トークン発行、OAuth 動的登録レスポンス、ダッシュボード発行の API キー。これらは AdCP タスクペイロードとしてではなく、AAO 認可サーバーまたはセラーのオンボーディングフローを通過します。 ### リレーエージェント 代理店 / A2A リレートポロジー（ブランド → リレー → セラー）は、**リレー自身のプリンシパルの下で**認証します。リレーはブランドエージェントの RFC 9421 署名をそのまま保持する（パススルーモデル）か、自身の鍵の下で再署名する（再署名モデル）かのいずれかです — どちらのオプションも [#2324](https://github.com/adcontextprotocol/adcp/issues/2324) で説明されています。いずれのモデルも、ブランドのトランスポートクレデンシャルをリレー側のペイロードフィールドとして転送することを許可しません。リレーが記録上のプリンシパルである場合のブランドエージェントのアイデンティティは、リクエストボディにアイデンティティコンテキスト（例: `adagents.json` / `authorized_operator[]` に対してセラーが検証可能なバイヤー側のアイデンティティアサーション）として運ばなければならず（MUST）、転送されたトランスポートクレデンシャルとしては決して運びません。リレーは、アウトバウンドのセラー宛てリクエストの任意の args フィールドでバイヤークレデンシャルをエコーまたは再添付してはなりません（MUST NOT）。 ## プロトコル設定 ほとんどの MCP および A2A 統合は、認証ヘッダーとして `Authorization: Bearer `（[RFC 6750 §2](https://www.rfc-editor.org/rfc/rfc6750#section-2)）を使用します。クライアントを次のように設定します: ```json theme={null} { "auth": { "type": "bearer", "token": "" } } ``` クライアントライブラリが `Authorization: Bearer ` ヘッダーの付与を処理します。 セラーが明示的に HTTP Basic クレデンシャルをプロビジョニングする場合、同じトランスポートルールが適用されます。HTTPS 上の認証必須な各リクエストで `Authorization: Basic ` を送信します。 **レッグごとのヘッダーエイリアスポリシー。** 2 つのプロトコルレッグは、標準の `Authorization` ヘッダーを超えてどのエイリアスを受け入れるかが異なります: * **A2A** — `Authorization` のみ。Bearer クレデンシャルの場合、`Authorization: Bearer ` を送信し、セラーのエージェントカードで `bearerAuth` `HTTPAuthSecurityScheme` を宣言します（[A2A ガイド — エージェントカード](/docs/building/by-layer/L0/a2a-guide#agent-cards)を参照）。Basic クレデンシャルの場合、`Authorization: Basic ` を送信し、HTTP Basic を宣言します。`x-adcp-auth` カスタムヘッダーは A2A 面では認識されません。 * **MCP** — `Authorization` が Bearer および Basic クレデンシャルの主要ヘッダーです。`x-adcp-auth` は adcp 4.5.0 より前の統合向けの後方互換 Bearer エイリアスとして受け入れられます。新しい実装は両方のレッグで標準ヘッダーを使用すべきです。 **adcp 4.5.0 に移行するセラーへ。** 以前 `a2a_header_name` ノブで A2A レッグヘッダーとして `x-adcp-auth` を設定していた場合、`bearerAuth` を宣言するようエージェントカードを更新する前に、そのノブが RFC 6750 のデフォルトに設定されていることを確認してください — レガシーヘッダーからまだ移行していないバイヤーは、さもなくば HTTP 401 を受け取ります。 ## MCP クライアントの設定 MCP プロトコルでは、認証は HTTP ヘッダーの手動付与ではなくトランスポート層で処理されます。 ### MCP クライアントライブラリの利用 The recommended approach is to use an MCP client library: ```typescript TypeScript theme={null} import { Client } from '@modelcontextprotocol/sdk/client/index.js'; import { StreamableHTTPClientTransport } from '@modelcontextprotocol/sdk/client/streamableHttp.js'; const transport = new StreamableHTTPClientTransport( new URL('https://agenticadvertising.org/api/training-agent/mcp'), { requestInit: { headers: { 'Authorization': 'Bearer YOUR_TOKEN_HERE' } } } ); const client = new Client({ name: 'my-client', version: '1.0.0' }); await client.connect(transport); ``` ```python Python theme={null} from mcp import ClientSession from mcp.client.streamable_http import streamablehttp_client async with streamablehttp_client( "https://agenticadvertising.org/api/training-agent/mcp", headers={"Authorization": "Bearer YOUR_TOKEN_HERE"} ) as (read, write): async with ClientSession(read, write) as session: await session.initialize() ``` ### よくある誤り: 生の HTTP ヘッダー追加 生の HTTP リクエストに認証ヘッダーを付けようとするのは誤りです: ```http theme={null} # This won't work for MCP endpoints GET /mcp HTTP/1.1 Authorization: Bearer YOUR_TOKEN ``` MCP は HTTP 上のストリーミングプロトコルです。認証は、プロトコル交渉とメッセージフレーミングを担う MCP クライアントのトランスポート層で設定する必要があります。 ### 認証トラブルシュート "authentication required" が出る場合: 1. **MCP クライアントライブラリを使っているか確認** - 生の HTTP 呼び出しをしていないか 2. **トークンの渡し方を確認** - トランスポート設定に渡しているか 3. **公開テストエージェントで試験** - カスタムエージェント前に動作確認 4. **プロトコルバージョンを確認** - クライアントとサーバーの互換性を確保 OAuth ハンドシェイクの失敗や RFC 9421 署名の問題には、[CLI 認証グレーダー](/docs/building/verification/grading)を使用してください — `diagnose-auth` は RFC 9728 + RFC 8414 のディスカバリーを探索して仮説をランク付けし、`grade request-signing` はすべての署名ベクトルをベクトルごとの診断付きで実行します。 ## 認証情報の取得 ### アカウント開設フロー 認証が必要な操作を行うには、各 sales agent とのアカウント開設が必要です: 1. **Sales agent を特定**: パブリッシャーの `adagents.json` から発見 2. **営業窓口に連絡**: エージェントの営業/提携チームに問い合わせ 3. **オンボーディング**: 企業情報の提供、契約締結、課金設定 4. **認証情報を受領**: API キーまたは OAuth クライアント資格情報を取得 **Note**: 各 sales agent は独立してアカウントを管理します。エージェントごとに別の認証情報が必要です。 ### 動的クライアント登録（オプション） Some sales agents support OAuth 2.0 dynamic client registration: ```http theme={null} POST /oauth/register Content-Type: application/json { "client_name": "Your Company Name", "redirect_uris": ["https://yourapp.com/callback"], "grant_types": ["authorization_code", "refresh_token"], "scope": "adcp:products adcp:media_buys adcp:creatives" } ``` 動的登録に対応しているかは、sales agent のドキュメントや `adagents.json` を確認してください。 ### アグリゲーションプラットフォーム 複数の sales agent との認証情報や関係を一括管理するアグリゲーションプラットフォーム（例: Scope3）の利用を検討してください。これにより次が簡素化されます: * 認証情報管理 * 金銭的なやり取り * 契約手続き * コンプライアンス監視 ## AAO プラットフォームサービスへの認証 上記のメカニズムは**エージェント間**認証（バイヤー ↔ sales agent）を規定します。**AAO ホスト型サービス** — レジストリ書き込み API、AAO MCP エンドポイント、メンバーダッシュボード — への認証は別の面です。 AAO は OAuth 2.1 + OIDC 認可サーバーを運用します。クライアントは標準の well-known を介してそれを発見します: * **認可サーバーメタデータ（RFC 8414）:** `https://agenticadvertising.org/.well-known/oauth-authorization-server` * **保護リソースメタデータ（RFC 9728）:** `/.well-known/oauth-protected-resource/api`（REST API）および `/.well-known/oauth-protected-resource/mcp`（MCP）。どちらも `https://agenticadvertising.org` を認可サーバーとして列挙します。 * **フロー:** PKCE（S256）付き認可コード。ユーザーアイデンティティは WorkOS AuthKit 経由。トークンは署名付き JWT です。 * **動的クライアント登録（RFC 7591）:** `POST /register`。 * **サーバー間:** `client_credentials` グラントはありません。バックエンドサービスは OAuth `/token` エンドポイントではなく、[AAO ダッシュボード](https://agenticadvertising.org/dashboard/api-keys)の WorkOS 組織 API キーを使用すべきです。 すべての AAO エンドポイントは HTTPS 専用です。プレーン HTTP で提供されるディスカバリードキュメントは拒否してください。 AAO から取得したユーザー JWT は AdCP クレデンシャルでは**ありません**。sales agent への呼び出しは、上表に従い依然としてそのエージェントの bearer / 9421 / mTLS クレデンシャルを使用します。完全なリファレンス: [AAO レジストリ — 認証](/docs/registry#authentication)。 **sales agent の RFC 9728 保護リソースメタデータで `authorization_endpoint` を発見した場合**（例: オペレーターアカウントの OAuth フロー向け）、発見された `authorization_servers` の発行者を、そのセラーについて `adagents.json` — または帯域外のオンボーディング — が認可したものに対してピン留めしてください。リソース自体が返した AS URL を盲目的に信頼しないでください。さもなくば、悪意のあるまたは侵害されたセラーがオペレーターのクレデンシャルを攻撃者制御のエンドポイントにルーティングできます。 ## エラーレスポンス ### 保護された操作への未認証リクエスト ```json theme={null} { "error": { "code": "AUTH_REQUIRED", "message": "Authentication required for this operation" } } ``` ### 無効または期限切れの認証情報 ```json theme={null} { "error": { "code": "AUTH_INVALID", "message": "Invalid or expired credentials" } } ``` ### 権限不足 ```json theme={null} { "error": { "code": "INSUFFICIENT_PERMISSIONS", "message": "Agent does not have required permissions for this operation" } } ``` ## ベストプラクティス 1. **安全な保管**: 環境変数やシークレットマネージャーで保護 2. **ローテーション**: 認証情報のローテーションポリシーを実装 3. **スコープ最小化**: 必要最小限の権限のみ要求 4. **トークン更新**: JWT の自動リフレッシュを実装 5. **エラーハンドリング**: 認証エラーをリトライロジックで適切に処理 ## 認証テスト 公開テストエージェントは共有トークンを受け入れます — サインアップは不要です: ```bash theme={null} export ADCP_AUTH_TOKEN="1v8tAhASaUYYp4odoQ1PnMpdqNaMiTrCRqYo9OJp6IQ" export AGENT_URL="https://agenticadvertising.org/api/training-agent/mcp" ``` このトークンでクライアントを設定します: ```json theme={null} { "agent_uri": "https://agenticadvertising.org/api/training-agent/mcp", "protocol": "mcp", "auth": { "type": "bearer", "token": "1v8tAhASaUYYp4odoQ1PnMpdqNaMiTrCRqYo9OJp6IQ" } } ``` 組織スコープの利用状況トラッキングには、公開トークンを [AAO ダッシュボード](https://agenticadvertising.org/dashboard/api-keys)の自身の API キーに置き換えてください。 サンドボックスモードを含むテスト機能の詳細は [Sandbox Mode](/docs/media-buy/advanced-topics/sandbox) を参照してください。