> ## 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 キャンペーンガバナンスで、バイヤー側オーケストレーター、セラー、ガバナンスエージェントがどう責任を共有するか。

# ガバナンスの責任: バイヤー対セラー

キャンペーンガバナンスは、トランザクションの 2 つの異なる位置から同じ `check_governance` タスクを使います。バイヤー側オーケストレーターはアクションを送る前に意図をチェックします。セラーはコミットまたは配信変更の前に実行をチェックします。両方のチェックはバイヤーの構成されたガバナンスエージェントに行きますが、異なる証拠を運びます。

## ロール

| Role           | Responsibility                                                                      |
| -------------- | ----------------------------------------------------------------------------------- |
| バイヤー側オーケストレーター | プランを作成または更新し、意図されたアクションをチェックし、承認されたリクエストをセラーに送り、結果をガバナンスエージェントに報告する。                |
| セラー            | バイヤーが有効なガバナンスコンテキストを供給したことを検証し、実行前に計画された配信をチェックし、ガバナンスによって欠けているか拒否された統制アクションを拒否する。  |
| ガバナンスエージェント    | プランとポリシールールを適用し、`approved`、`conditions`、または `denied` を返し、ガバナンスコンテキストに署名し、監査状態を記録する。 |

## セットアップ: セラーをガバナンスエージェントにバインドする

セラーがセラー側チェックを行える前に、バイヤーアカウントは [`sync_governance`](/docs/accounts/tasks/sync_governance) 経由でガバナンスエージェントエンドポイントをセラーと同期しなければなりません。これはアカウントセットアップであり、バイごとの交渉ではありません。

セラーは、アカウントの構成されたガバナンスエージェントエンドポイントと認証情報を保存します。後で、統制リクエストが到着したとき、セラーはどこで `check_governance` を呼ぶかを知ります。

## バイヤー側の意図チェック

バイヤー側オーケストレーターは、統制プランの支出コミットアクションごとの前に [`check_governance`](/docs/governance/campaign/tasks/check_governance) を呼びます。

意図チェックは以下を送ります:

| Field                | Required | Purpose                                                                                                   |
| -------------------- | -------- | --------------------------------------------------------------------------------------------------------- |
| `plan_id`            | Yes      | 強制されるキャンペーンプランを識別。                                                                                        |
| `caller`             | Yes      | ガバナンスチェックを行うバイヤー側オーケストレーターを識別。                                                                            |
| `tool`               | Yes      | オーケストレーターが実行しようとするアクション（`create_media_buy`、`update_media_buy`、`activate_signal`、`build_creative` など）を名指す。 |
| `payload`            | Yes      | オーケストレーターが送ろうとする正確なリクエストボディを運ぶ。                                                                           |
| `governance_context` | 後の呼び出し   | 最初の承認済みチェックの後、ライフサイクル連続性を維持。                                                                              |

ガバナンスエージェントが `approved` または `conditions` を返す場合、`governance_context` トークンを返します。オーケストレーターはそのトークンをセラーに送るリクエストに添付します。レスポンスが `conditions` の場合、オーケストレーターは進む前に条件を適用して再チェックしなければなりません。

## セラー側の実行チェック

セラーが統制された支出コミットリクエストを受け取ると、アクションを確認する前に独立した実行チェックを行います。

セラー側チェックは以下を送ります:

| Field                | Required        | Purpose                                                                           |
| -------------------- | --------------- | --------------------------------------------------------------------------------- |
| `plan_id`            | Yes             | 強制されるキャンペーンプランを識別。                                                                |
| `caller`             | Yes             | 実行チェックを行うセラーを識別。                                                                  |
| `governance_context` | Yes             | バイヤー側意図チェックからの署名付きコンテキストトークン。                                                     |
| `planned_delivery`   | Yes             | セラーの実際の計画された実行: 予算、日付、チャネル、地理、プレースメント、ペーシング、その他の配信パラメーター。                         |
| `phase`              | ライフサイクル明確化に Yes | これが購入、変更、配信チェックのいずれかを示す。                                                          |
| `delivery_metrics`   | 配信フェーズ          | `phase` が `delivery` のとき必須。ペーシング、支出、地理、チャネル、オーディエンスドリフトチェックのため実際の配信パフォーマンスデータを運ぶ。 |

セラーはバイヤーの意図チェックをそれ自体で十分と扱ってはなりません。セラーは実際に配信するものをチェックします。それは在庫可用性、セラーのデフォルト、実装制約のためバイヤーのリクエストと異なりうる。

ガバナンスエージェントが実行チェックを拒否する場合、セラーは進んではなりません。ガバナンスエージェントが条件を返す場合、セラーは計画された配信を調整し確認前に再チェックしなければなりません。

## 結果報告

セラーが応答した後、バイヤー側オーケストレーターは [`report_plan_outcome`](/docs/governance/campaign/tasks/report_plan_outcome) を呼びます。これはガバナンスエージェントが承認されたアクションをセラーの実際の応答と照合し、確認された結果から予算状態を更新できるようにします。

結果報告は、ガバナンスエージェントが試みられたアクションをコミットされた支出として数えることを防ぐものです。ガバナンスエージェントは実際に起こった状態を追跡します。

## よくある間違い

| Mistake                                              | Correct behavior                                   |
| ---------------------------------------------------- | -------------------------------------------------- |
| セラーが後でチェックするからバイヤーが `check_governance` をスキップ         | バイヤーはまず意図チェックを行い、有効なガバナンスコンテキストを添付できるようにしなければならない。 |
| セラーが統制アカウントでガバナンスコンテキストなしのリクエストを受け入れる                | セラーは実行前にリクエストを拒否する。                                |
| セラーが `planned_delivery` の代わりにバイヤーのリクエストされたペイロードをチェック | セラーは実際に実行する配信をチェックする。                              |
| オーケストレーターが `conditions` を承認として扱う                     | オーケストレーターまたはセラーが条件を適用し `check_governance` を再度呼ぶ。   |
| オーケストレーターが `report_plan_outcome` を省略                 | ガバナンス予算と監査状態が実際に起こったことからドリフトする。                    |

## 最小シーケンス

1. バイヤーが `sync_governance` でアカウントにガバナンスを構成。
2. バイヤーが `sync_plans` でプランを作成または更新。
3. バイヤーが `tool` と `payload` で `check_governance` を呼ぶ。
4. バイヤーが `governance_context` でセラーリクエストを送る。
5. セラーがコンテキストを検証し `plan_id`、`caller`、`planned_delivery` で `check_governance` を呼ぶ。
6. セラーがガバナンス判定に基づいて確認、拒否、または調整。
7. バイヤーがセラー結果で `report_plan_outcome` を呼ぶ。

リクエストとレスポンスフィールドについては [`check_governance` タスクリファレンス](/docs/governance/campaign/tasks/check_governance) を、ライフサイクルとトークン検証詳細については [キャンペーンガバナンス仕様](/docs/governance/campaign/specification) を参照してください。