> ## 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 においてバイヤーとセラー間の請求関係を表します。セールスエージェントはアカウントを使用して料金（レートカード）、請求エンティティを決定し、異なるバイヤー間のデータアイソレーションを適用します。

## 認証

すべてのリクエストは標準の `Authorization` ヘッダーにベアラートークンを使用して認証する必要がある:

```
Authorization: Bearer <your_token>
```

サーバーはこのトークンを検証し、リクエストを行っている**エージェント**を識別します。エージェントは1つ以上のアカウントにアクセスできます。

認証情報の取得と認証方法の詳細は [Authentication](/docs/building/by-layer/L2/authentication) を参照。

### エージェントとアカウント

AdCP は以下を区別する:

* **エージェント**: API コールを行う認証済みエンティティ（例: `"pinnacle_trading_desk"`）
* **アカウント**: メディアバイの請求関係（例: `"acme_c/o_pinnacle"`）

エージェントは複数のアカウントで操作できます。例えば、エージェンシーのトレーディングデスクは複数の広告主のアカウントと自社のハウスアカウントを管理する場合があります。詳細は [Accounts and Agents](/docs/building/by-layer/L2/accounts-and-agents) を参照。

## データアイソレーション

認証は厳格なデータアイソレーションの基盤を提供します。セールスエージェントは以下のルールを適用**しなければなりません** (MUST):

1. `MediaBuy` などのオブジェクトが作成される場合、そのリクエストで使用されたアカウントと**永続的に**関連付けなければなりません (MUST)。
2. そのオブジェクトを読み取るまたは変更するその後のリクエストでは、サーバーはエージェントがそのアカウントへのアクセスを持つことを検証しなければなりません (MUST)。
3. エージェントがアクセスを持たない場合、サーバーは権限拒否エラーを返さなければなりません (MUST)。

このモデルにより、1つのアカウントのデータが認可されていないエージェントにアクセスされないことが保証されます。アクセス権を持たないアカウントの `account_id` を渡すとエラーになります。

## セキュリティ要件

完全な規範的実装リファレンス——二段階認可、行レベルセキュリティ、IDOR 防御、およびより広範なセキュリティ体制（Webhook、冪等性、署名済みガバナンスコンテキスト）——は、[セキュリティ — エージェントとアカウントのアイソレーション](/docs/building/by-layer/L1/security#agent-and-account-isolation)を参照してください。

### 必須セキュリティ対策

セールスエージェントの実装は以下を**しなければなりません** (MUST):

* すべての認証済みリクエストでベアラートークンを検証します
* アカウントベースのデータアイソレーションを適用します
* すべての通信に TLS を使用します
* セキュリティ監視のために認証失敗をログに記録します

### 推奨セキュリティ対策

セールスエージェントの実装は以下を**すべきだ** (SHOULD):

* エージェントとアカウントごとにレート制限を実装します
* トークンの有効期限とリフレッシュをサポートします
* コンプライアンスのために監査ログを提供します
* 高セキュリティアカウントのための IP ホワイトリストをサポートします