> ## Documentation Index
> Fetch the complete documentation index at: https://auth0.com/llms.txt
> Use this file to discover all available pages before exploring further.

# プリンシパルとしてのエージェント

> AIエージェントを、独自のライフサイクル、credentials、監査証跡を備えたAuth0の第一級のアイデンティティとして登録します。

> [!WARNING]
>
> **Agent as Principal機能は現在、です。**

Agent as Principal は、AI エージェントを Auth0 における第一級のアイデンティティとして扱う機能で、人間のユーザーや従来のマシンツーマシン (M2M) クライアントとは区別されます。エージェントは、安定した識別子を持ち、独自のライフサイクル管理、credentials、監査履歴を備えた登録済みのエンティティです。

Auth0 のプリンシパルとして登録されたエージェントは、次のことができます。

* ユーザーに代わって動作する
* ユーザーセッションなしで自律的に動作する
* トークン交換によるマルチホップの委任を行う

## ユースケース

* 自律型エージェント: AIエージェントがクライアント認証情報を使って、自分自身としてAPIを直接呼び出します。そのアイデンティティはログとトークンに記録されます。
* 委任アクセス: ユーザーがAIエージェントに対し、自分に代わって動作する権限を付与します。エージェントはユーザーのアクセストークンを委任トークンに交換します。この委任トークンでは、サブジェクトはユーザーのまま保持され、エージェントはアクターとして識別されます。
* マルチホップチェーン: オーケストレーションを担うエージェントがサブエージェントに委任します。委任チェーンは入れ子になった `act` クレームに保持されるため、どのリソースサーバーでも完全な追跡が可能です。

## 仕組み

Agent as Principal は、登録、クライアントの関連付け、トークンの発行という 3 つの段階で動作します。

```mermaid theme={null}
flowchart LR
    A([あなた]) -->|"POST /api/v2/agents"| B[("Auth0\n(agent_id を発行)")]
    B -->|"PATCH /api/v2/clients/{id}"| C["M2Mクライアント\n(エージェントに紐付け)"]
    C --> D{"認証"}
    D -->|"クライアント認証情報"| E["トークン\nsub = agent_id\nsub_profile = ai_agent"]
    D -->|"OBO交換"| F["トークン\nsub = user\nact.sub = agent_id"]
    D -->|"標準ログイン"| G["トークン\nsub = user\nact.sub = agent_id"]
    E --> H[("テナントログ\n+ アクション")]
    F --> H
    G --> H
```

1. [エージェントを登録する](https://auth0.com/docs/ja-jp/ai-agents-mcp/agent-as-principal/register-an-agent.md)：Dashboard または Management API を使用して、エージェントを Auth0 に登録します。Auth0 は一意で変わらない `agent_id` を持つ[エージェントオブジェクト](https://auth0.com/docs/ja-jp/ai-agents-mcp/agent-as-principal/register-an-agent.md#agent-object)を作成します。この ID により、ライフサイクル全体を通じてトークン、ログ、Management API をまたいだ追跡が可能になります。

2. [エージェントをクライアントに関連付ける](https://auth0.com/docs/ja-jp/ai-agents-mcp/agent-as-principal/associate-agent-client.md)：エージェント自体は credentials を持たず、関連付けられた 1 つ以上のクライアントを通じて認証します。1 つのエージェントを複数のクライアントに紐付けることもできるため、環境やリージョンごとにクライアントを分けつつ、ログ上では単一の論理的なアイデンティティを維持できます。

3. [トークン内のエージェントアイデンティティ](https://auth0.com/docs/ja-jp/ai-agents-mcp/agent-as-principal/agent-identity-in-tokens.md)：エージェントに紐付いたクライアントが認証されると、Auth0 は付与タイプに応じて、発行するトークンにエージェントのアイデンティティを埋め込みます。

`agent_id` (作成時に設定した場合は `external_agent_id`) は、トークン発行のたびに[テナントログ](https://auth0.com/docs/ja-jp/ai-agents-mcp/agent-as-principal/tenant-logs.md)にも記録されるため、エージェント単位の完全な監査証跡が得られます。さらに、[Actions](https://auth0.com/docs/ja-jp/ai-agents-mcp/agent-as-principal/actions-context.md) では `event.agent` からエージェントアイデンティティを参照し、トークン発行時にカスタムロジックを適用できます。

## 移行ガイダンス

既存のクライアントとリソースサーバーを Agent as Principal に対応するよう移行しましょう。

### クライアント

既存のクライアントは、エージェントと明示的に関連付けない限り影響を受けません。エージェントの関連付けはオプトイン方式で、後から解除することもできます。詳しくは[クライアントとエージェントを関連付ける](https://auth0.com/docs/ja-jp/ai-agents-mcp/agent-as-principal/associate-agent-client.md)をご覧ください。

### リソースサーバー

`sub_profile` および `client_profile` クレームを受け取るには、対象のリソースサーバーの設定で `agent_subject_claims: 'auth0-v1'` を指定します。これはリソースサーバーごとのオプトイン方式です。詳細については、[エージェントのサブジェクトクレームを受け取るためのリソースサーバーの設定](https://auth0.com/docs/ja-jp/ai-agents-mcp/agent-as-principal/agent-identity-in-tokens.md#configure-resource-server-to-receive-agent-subject-claims)をお読みください。