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

# エージェントの運用

> プロトコル準拠エージェントの背後にあるもの — プロダクト、アクティベーション、ホスティング、提携・セルフホスト・構築のいずれか。

2〜8 分の [エージェントを構築する](/docs/building/by-layer/L4/build-an-agent) パスはプロトコル準拠エージェントを得ます。このページはその後に来るもの — 各ツール呼び出しの背後にあるビジネスインフラ、そして誰がそれを実行するかを決める方法です。

ここの実践例は **セールスエージェント** です。それが最もインフラ重いケースだからです。短いコールアウトが、シグナル、クリエイティブ、リテールメディアのエージェントで運用上の関心事が分岐する場所をマークします。

## SDK が既に扱うもの

欠けているものをリストする前に、ストーリーボード検証済みのエージェントが既にあなたに何を与えるかを明示するのが役立ちます:

* AdCP ツールスキーマと型付き登録
* コンプライアンスを通過するリクエスト/レスポンス形状
* エラー形式とバージョンネゴシエーション
* 実際のものにスワップできる例プロダクトを持つ出発点

下のすべては、それらのツールハンドラーの背後にあるものです。

## 提携、セルフホスト、または構築

ライブエージェントへの 3 つのパスがあります。それらは、そもそも何かを所有するかではなく、どれだけ所有するかで異なります — どのケースでも、あなたは依然としてプロダクト、価格、アドサーバーへのアクティベーションを所有します。

**マネージドセールスエージェントプラットフォームと提携。** プラットフォームがエージェントエンドポイントを実行し、状態を保持し、広告運用チームがプロダクト、価格、承認を管理する管理 UI を公開します。あなたはアドサーバーを接続し、プラットフォームがプロトコルとその周りの運用を扱います。ライブへ最速、最小の制御。

**事前構築されたエージェントをセルフホスト。** 既存のオープンソースエージェント — 今日これは通常 [Prebid Sales Agent](https://github.com/prebid/salesagent)、GAM 統合を持つコミュニティフルスタックセラーエージェント — を自身のインフラにデプロイし、システムに接続します。プロトコル層と管理 UI の記述をスキップしますが、ホスティング、アップグレード、データベース、アドサーバー配線を所有します。中間: 提携より制御が多く、構築より作業が少ない。

**独自に構築。** SDK とスキルファイルを使ってカスタムエージェントを書きます。ビジネスロジック、価格モデル、アクティベーションパスの完全な制御を得ますが、他のすべてと並んでコードを所有するコストがあります。事前構築されたエージェントがあなたのスタックや価格モデルに合わないとき正しい答え。

SDK とストーリーボードは 3 つすべてのパスでプロトコルコンプライアンスをカバーします。下の表のすべては、どのパスを取るかにかかわらず、その線の外にあるものです。

## まだ構築またはプロビジョニングが必要なもの

| Component            | What it does                                                                                                                | Example approaches                                                                                                                                                                 |
| -------------------- | --------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **プロダクトと価格の管理**      | 広告運用がコード変更なしにプロダクト、レートカード、パッケージング、可用性を定義できる。スキルファイルは例プロダクトをハードコードする。実際のエージェントはこれらを動的で編集可能にする必要がある。                          | パートナープラットフォームのプロダクトカタログ、事前構築されたエージェントの管理 UI（例: Prebid Sales Agent）、またはデータベース裏付けのカスタム管理 UI。                                                                                         |
| **永続ストレージ**          | リクエストをまたいでプロダクト、価格、メディアバイ、クリエイティブ割り当て、配信状態を保存。                                                                              | PostgreSQL、MySQL、またはチームが運用に快適な任意のデータストア。                                                                                                                                           |
| **クリエイティブレビューとポリシー** | クリエイティブがライブになる前にブランドセーフティ、法的、フォーマットチェックを適用。プロトコルはクリエイティブを運び、あなたのポリシーがそれを受け入れるかを決める。                                         | 人間レビューキュー、自動ポリシーエンジン（IAB カテゴリー、ブランドリスト）、またはハイブリッド。広告運用チームが最初に過小評価するもの。                                                                                                             |
| **トラフィッキングと履行**      | 販売されたメディアバイをアドサーバーのライブキャンペーンに変える。これは完全に AdCP の外にあり、通常最も難しい部品。                                                               | *手動:* 広告運用に GAM でキャンペーンを設定するよう促すメールまたは Slack アラート。*半自動:* ラインアイテムを作成しクリエイティブを割り当てる Google Ad Manager API。*完全自動:* バイ確認からライブ配信までのエンドツーエンドパイプライン。                                      |
| **配信レポートとパフォーマンス**   | `get_media_buy_delivery` と `provide_performance_feedback` を実際の数字で駆動。プロトコルツールは存在するが、その背後のログ取り込み、集約、アトリビューションパイプラインはあなたが構築する。 | アドサーバーレポート API プル、ウェアハウスへのログレベル取り込み、またはエージェントに供給するマネージド分析ツール。                                                                                                                      |
| **オーダー管理**           | プロトコルのタスクライフサイクルがカバーするものを超えて、バイステータス、承認ワークフロー、クリエイティブ締め切り、ペーシングを追跡。                                                         | 開始時はデータベースのステータスフィールド。ボリュームが増えるとダッシュボード。                                                                                                                                           |
| **ホスティング**           | オペレーター `brand.json` とパブリッシャー `adagents.json` で宣言する URL でエージェントをライブに保つ。ダウンタイムや URL ドリフトはバイヤー検証を壊す。                           | クラウド VM、コンテナサービス（Cloud Run、ECS、Fly.io）、またはマネージドホスティングプラットフォーム。                                                                                                                     |
| **ディスカバリーと認可レコード**   | エンドポイントを誰が運用するか、その署名鍵がどこに存在するか、どのパブリッシャーがどのインベントリにそれを認可するかをバイヤーエージェントに伝える。プロトコルサポートは `get_adcp_capabilities` で宣言。           | オペレーター `brand.json` とパブリッシャー `adagents.json` を公開。[Seller setup](/docs/brand-protocol/seller-setup) と [Authorized Properties](/docs/governance/property/authorized-properties) を参照。 |

## プロトコルが終わりあなたのビジネスが始まる場所

AdCP はエージェント間の会話の形状を定義します。次を定義しません:

* **価格戦略** — インベントリをどう価格設定、レートカードがどう柔軟、いつ割引が適用されるか
* **承認ポリシー** — どのキャンペーンを受け入れまたは拒否、どの根拠で
* **課金と請求** — 仕様レベルの課金なし。バイヤーと帯域外で再照合
* **アイデンティティと同意** — ユーザーレベルのアイデンティティ、同意取得、データ主体の権利は規制され実装固有
* **SLA 監視** — エージェントエンドポイントのアップタイム、レイテンシー、エラー予算
* **広告運用ワークフロー** — チームがペーシング、makegood、エスカレーションをどう監視するか

パートナープラットフォームはこれらのほとんどにデフォルト選択をします。セルフホストの事前構築されたエージェントは上書きするデフォルトを与えます。自己構築のエージェントはすべての判断をあなたにさせます。

## エージェントタイプでどう異なるか

上のコンポーネント表はセールスエージェントを仮定します。他のエージェントタイプはそのほとんどを共有しますが特定の追加を持ちます:

* **シグナルエージェント** — 同意と来歴が負荷を担う。防御可能なデータリネージ（セグメントがどこから来たか、どの同意がそれをカバーするか）とオプトアウトを尊重する能力が必要。アクティベーションはアドサーバートラフィッキングより、既にセグメントを取り込むプラットフォームへのセグメント配信について。
* **クリエイティブエージェント** — アセットストレージ、トランスコーディング、レンダリング SLA がアドサーバートラフィッキングを置き換える。クリエイティブレビューは、トラフィックするものではなくレンダリングするものについてのポリシーになる。
* **リテールメディアエージェント** — カタログ鮮度が運用上の制約。SKU が変わるにつれプロダクトが変わる。アクティベーションはしばしば GAM ではなくリテール固有の広告プラットフォームを通る。

## 本番でのエージェントの運用

プロトコル準拠エージェントは、うまく運用されたエージェントと同じではありません。それは 2 つの異なる関心事です: **継続的な広告運用の健全性**（プロトコルのものが実際に仕事をしている）と **セキュリティ**（プロトコルのものがそうするとき信頼できるままでいる）。両方を、アドサーバー統合に与えるのと同じ真剣さで扱ってください。

### 広告運用の健全性監視 — 実際に何を見るか

これは日々の仕事です。そのほとんどは、任意の広告運用チームが既に実行する監視のプロトコル認識の拡張です。ポイントは「学ぶ新しい概念」ではなく「これがダッシュボードが必要な特定のプロトコルシグナル」です。Addie がこれらのセットアップを助けられます。

| What to watch        | Why it matters                                                                                                     | Signals to alert on                                                                                                   |
| -------------------- | ------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------- |
| **オープンタスクキュー深度**     | 非同期タスク（`create_media_buy` プロポーザル、`sync_creatives` 承認、`si_initiate_session`）は承認者が遅れると積み重なる。深いキューはバイヤーが待っていることを意味する。 | SLA を超えたオープンタスク（例: クリエイティブ承認 > 4h）、最古タスクの経過時間上昇、キューが排出より速く成長。                                                         |
| **クリエイティブ承認スループット**  | クリエイティブは実際に承認または拒否される必要がある。黙って動かなくなるキューは「すべて順調」と同一に見える — バイが起動していないことを除いて。                                         | 承認/拒否率対提出率、期待レビューウィンドウより古いまだ `pending` のクリエイティブ、拒否理由分布。                                                               |
| **ライフサイクル遷移が時間通り発火** | セラーはフライト日が来たとき `pending_start` → `active` を遷移しなければならない（MUST）。逃した遷移は、「正常に作成」されてもキャンペーンを never-delivered に残す。        | フライト開始を過ぎてまだ `pending_start` のバイ、クリエイティブ到着を過ぎて `pending_creatives` のバイ、自動再開すべきだった `paused` バイ。                        |
| **Webhook 配信の健全性**   | Webhook はバイヤーが非同期状態変更を学ぶ方法。黙った配信失敗はバイヤーが代わりにポーリングする — またはしないでイベントを完全に逃すことを意味する。                                    | 失敗配信率、リトライバックログ、デッドレターキューサイズ、状態変更から成功プッシュまでの時間。                                                                       |
| **起動不能なバイのステータス正しさ** | ライブに *なれない* キャンペーン（クリエイティブ拒否、アカウント停止、ポリシー拒否）は、黙って詰まるのではなくステータスに反映されなければならない（MUST）。ガバナンスがこれに依存する。                   | 配信しておらず終端/ブロックステータスも示していないバイ、アドサーバー状態と AdCP 状態の不一致。                                                                   |
| **配信レポートの鮮度と精度**     | `get_media_buy_delivery` は現在の数字を返すべき。古いレポートはバイヤーが嘘に最適化することを意味する。                                                   | last-updated タイムスタンプの遅れ、アドサーバーログと再照合しない支出デルタ。                                                                         |
| **冪等性キャッシュ動作**       | リトライされた `create_media_buy` は重複を作るのではなくキャッシュされたレスポンスを返さなければならない。コンプライアンスがこれをサンドボックスでテストする — 本番ドリフトは独自のシグナル。         | `IDEMPOTENCY_CONFLICT` 率（バイヤーのバグまたは攻撃者のプロービング）、進行中の作業の `IDEMPOTENCY_EXPIRED`（TTL が短すぎ）、アドサーバーで作成された重複メディアバイ（キャッシュ失敗）。 |
| **エラーコード分布**         | 特定のバイヤーからの特定のエラーコードのスパイクは通常、実際の問題の最初のシグナル。                                                                         | バイヤーごと時間ごとの上位 N エラーコード、見たことのない新しいエラーコード。                                                                              |

これは、誰がコードを書いたかにかかわらずセールスエージェントが必要とする監視です。パートナープラットフォームはこのほとんどのダッシュボードを公開すべき。セルフホストの事前構築されたエージェントはそれらを配線することを要求する。自己構築のエージェントはすべての行をあなたのチームに置く。

### セキュリティ監視 — コンプライアンスがカバーするもの対あなたに残るもの

**ほとんどの AdCP セキュリティメカニクスは [コンプライアンススイート](/docs/building/verification/validate-your-agent) によって強制されます — 手で検証する必要はありません。** ストーリーボードランナーは、認証、冪等性、スキーマ適合性、エラー処理、ガバナンス動作をエージェントに対して検証します。スイートが通過すれば、ワイヤーレベルの動作は正しいです。エージェント/アカウントスコーピングの内部、JWS 検証ステップ、正準 JSON を学ぶ必要はありません — テストが学びます。

コンプライアンススイートが確認するもの（そのためあなたが教える必要がない）:

| Storyboard                             | What it verifies                                                                                            |
| -------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| `security_baseline`（universal）         | 保護された操作で認証が必要。無効な鍵が拒否される。API キーまたは OAuth 2.0 の少なくとも一方が正しくアドバタイズされる。                                         |
| `idempotency`（universal）               | 変更リクエストが `idempotency_key` を尊重: リプレイがキャッシュを返し、衝突が `IDEMPOTENCY_CONFLICT` を返し、欠けている鍵が `INVALID_REQUEST` を返す。 |
| `schema-validation`、`error-compliance` | レスポンスがスキーマに一致。エラーが標準タクソノミーを使う。                                                                              |
| プロトコル + 専門分野ストーリーボード                   | プロトコルごとの動作（メディアバイライフサイクル、クリエイティブワークフロー、シグナルアクティベーション）がエンドツーエンドで正しい。                                         |
| リクエスト署名テストベクター                         | RFC 9421 署名付きリクエストが 25 以上の肯定的・否定的ケースにわたって正しく検証される。                                                          |

**あなたが依然として所有するもの**、誰がコードを書いたかにかかわらず:

| Concern                        | What you decide and run                                                                                                                                                                                  |
| ------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **認証情報のストレージとローテーション**         | トークンを KMS/シークレットマネージャーに保存。短命のトークンを使う（書き込み可能に 24h 以下、支出をコミットできるトークンに 1h 以下を検討）。完全にログしない、決してコミットしない。正しいローテーションケイデンスは漏洩トークンの影響範囲に依存 — あなたのを正当化する、数字をコピーしない。                                                 |
| **鍵儀式とブレークグラス**                | 高価値の鍵（webhook シークレット、ガバナンス署名鍵）を生成、輸送、破棄する文書化されたプロセスを持つ。インシデント回復のため封印されたブレークグラス認証情報を維持 — そして監査証跡を残すそれらの使用手順。                                                                                              |
| **冪等性リプレイ TTL**                | `capabilities.idempotency.replay_ttl_seconds` を宣言 — 下限 1h、推奨 24h、最大 7d — し、宣言された値が実際のキャッシュ保持に一致することを検証。事前構築されたエージェントはこれを設定として公開。自己構築は焼き込む。                                                               |
| **クロスインスタンスとマルチリージョンフェイルオーバー** | 冪等性キャッシュ、セッションストア、webhook 重複排除状態はインスタンス再起動を生き残り、水平スケールされたインスタンス間で共有されなければならない。マルチリージョンデプロイでは、リージョン B にルーティングされたリトライがリージョン A で元々処理されたバイをリプレイするのに十分な一貫性がキャッシュに必要。メモリのみの状態は最初の pod 再起動で at-most-once 保証を壊す。 |
| **セキュリティシグナル監視**               | `IDEMPOTENCY_CONFLICT` スパイク（プロービング）、失敗したガバナンス検証（なりすまし）、単一の当事者からの SSRF 拒否、1 つのピアからの 401/403 スパイクを監視。運用監視と同じダッシュボード — アラートが異なるだけ。                                                                          |
| **当事者のベンダーリスク**                | あなたのガバナンスエージェント、シグナルプロバイダー、クリエイティブベンダーはすべて、キャンペーンに影響する認証情報を保持するか署名付きトークンを発行する。任意のプロセッサーを評価するように評価: 開示ポリシー、侵害通知コミットメント、コンプライアンスアテステーション、アップタイム SLA。                                                       |
| **インシデント対応ランブック**              | 1 時間未満で侵害された認証情報を失効、webhook シークレットをローテーション、当事者に通知、ガバナンストークンを発行するなら `revoked_kids` エントリを公開する方法を知る。必要になる前に卓上演習する。                                                                                          |

**提携** しているなら、ベンダーに尋ねてください: 「すべてのリリースで AdCP コンプライアンススイートを通過しますか？ どのバージョン？ 最新の実行を見られますか？」その単一の質問がコード制御サーフェスのほとんどをカバーします。また、SOC 2 Type II、ISO 27001、またはあなたの業界の同等のアテステーションを保持するか — そして侵害通知コミットメントが何かを尋ねてください。**事前構築されたエージェントをセルフホスト** しているなら、あなたのデプロイに対して自分でコンプライアンススイートを実行してください。**自己構築** しているなら、コンプライアンススイートがあなたの回帰ハーネスです。

<Note>
  **セキュリティと IT リーダー向け:** [Security Model](/docs/building/concepts/security-model) ページはあなたのために書かれています — ブランド、代理店、パブリッシャー、プラットフォームの CISO、セキュリティアーキテクト、サードパーティリスクレビュアー。脅威の風景と AdCP が設計上何を防御するかを説明し、ローンチ前にエンジニアリングチーム（またはベンダー）に尋ねる質問のチェックリストを含みます。
</Note>

## 次は

* **[エージェントを検証する](/docs/building/verification/validate-your-agent)** — 上で参照されたコンプライアンススイート
* **[Security](/docs/building/by-layer/L1/security)** — HMAC、冪等性、SSRF、ガバナンス検証の規範的リファレンス
* **[エージェントの通信方法](/docs/building/concepts/how-agents-communicate)** — `adagents.json` と `brand.json` 経由のディスカバリー
* **[セラー統合](/docs/building/operating/seller-integration)** — エージェントをアドサーバーに接続するパターン
* **[Authorized Properties](/docs/governance/property/authorized-properties)** — 誰が何を販売できるか、それがどう宣言されるか
