---
title: エージェントアイデンティティと認証情報
url: https://platform.claude.com/docs/ja/managed-agents/self-hosted/agent-identity
description: セルフホスト型のClaude Managed Agentsサーバーに、各エージェントを識別する有効期間の短いトークンへ署名させ、ボールトの認証情報をシークレットマネージャーに保管し、エグレスゲートウェイでシークレットをサンドボックスの外に保ちます。
---
セルフホスト型Claude Managed Agentsへのアクセスをリクエストするには、Anthropicのアカウントチームにお問い合わせください。
このページでは、サーバーの外部にあるシステムがエージェントを信頼できるようにする方法と、エージェントが使用する認証情報の保管場所を示します：
* [エージェントアイデンティティ](https://platform.claude.com/docs/ja/managed-agents/self-hosted/agent-identity#agent-identity)：MCPサーバーまたはゲートウェイが、各エージェントに個別のアクセス権を付与できるようにします。サーバーがエージェントを識別する有効期間の短いトークンに署名します。
* [シークレットマネージャー](https://platform.claude.com/docs/ja/managed-agents/self-hosted/agent-identity#secret-manager)：サーバーは、ボールトの認証情報をAWS Secrets Manager、Google Cloud Secret Manager、HashiCorp Vault、またはAzure Key Vaultに保管します。
* [環境変数の認証情報](https://platform.claude.com/docs/ja/managed-agents/self-hosted/agent-identity#environment-variable-credentials)：サンドボックスがプレースホルダーのみを保持した状態で、エージェントのコマンドがサービスを呼び出せるようにします。「egress gateway」（エグレスゲートウェイ）が実際の値をエージェントのリクエストに挿入します。
## エージェントアイデンティティ
サーバーは、エージェントを識別する有効期間の短い「JSON Web Token」（JSONウェブトークン）、すなわちJWTに署名し、そのエージェントのMCP呼び出しとともに送信できます。受信側（MCPサーバーまたはゲートウェイ）は、あなたが公開する公開鍵を使ってトークンを検証し、その後、各エージェントに個別のアクセス権を付与できます。
### 発行者を設定する
1. **「issuer」（発行者）のURLを選択します。** 手順3でこのURLに公開鍵を公開し、受信側はこのURLから公開鍵を取得します。静的なWebホストで問題ありません。サーバーは受信側が取得するパスで鍵を配信しないため、サーバーのアドレスは使用しないでください。パスや末尾のスラッシュのない`https://` URLを、今後も維持できるホスト名で使用してください。
2. **署名鍵を作成します。** 展開したアーカイブの最上位ディレクトリで次のコマンドを実行します：
```bash
mkdir -m 700 agent-identity
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out agent-identity/signing-key.pem
```
3. **公開鍵を公開します。** このコマンドは公開鍵を`issuer-files/.well-known/`に書き込みます。`issuer-files`を発行者のホスト名のルートに、コンテンツタイプ`application/json`で配信してください。
```bash
CMA_AGENT_IDENTITY__ISSUER=https://agents.example.com \
CMA_AGENT_IDENTITY__KEY_FILE=./agent-identity/signing-key.pem \
./cma-server export-issuer -out issuer-files
```
4. **サーバーに鍵を渡します。**
1. アーカイブに`compose`ディレクトリがある場合は、鍵のディレクトリをその中に移動します：`mv agent-identity compose/agent-identity`。
2. `docker-compose.yml`で、`cma-server`サービスの`volumes: *server_mounts`行を削除し、その下にある`volumes:`ブロックのコメントを解除します。`x-server-mounts`リストを変更した場合は、`cma-server`サービスがそのリストを読み取らなくなるため、そのブロックでも同じ変更を行ってください。
3. macOS上のDocker Desktopまたはrootless Dockerを使用している場合を除き、`agent-identity`があるディレクトリで`sudo chown -R root:root agent-identity`を実行します。
`kubectl -n cma-server create secret generic cma-agent-identity --from-file=agent-identity/signing-key.pem`を実行します。次に、サーバーチャートのvaluesファイルで`server.agentIdentity.secretName`を`cma-agent-identity`に設定します。
5. **[設定ファイル](https://platform.claude.com/docs/ja/managed-agents/self-hosted/configuration-reference#where-settings-go)を変更します。** 受信側のホスト名を[`mcp.allowed_hostnames`](https://platform.claude.com/docs/ja/managed-agents/self-hosted/differences#mcp-servers-need-an-allowlist-entry)に記載し、次のセクションを追加します：
```yaml
agent_identity:
issuer: https://agents.example.com
key_file: /run/cma-server/agent-identity/signing-key.pem
direct:
audiences:
- audience: https://mcp-gateway.example.com
urls:
- https://mcp-gateway.example.com
```
各`audience`は、1つの受信側を`https://` URLとして指定します。その`urls`は、そのaudience向けのトークンを受け取ることができるMCPサーバーのURLプレフィックスです。
6. **サーバーを再起動します。** Composeスタックでは、再起動の代わりにComposeファイルのディレクトリから`docker compose up -d`を実行します。
秘密鍵をファイルに置かないようにするには、`key_secret`（[シークレットマネージャー](https://platform.claude.com/docs/ja/managed-agents/self-hosted/agent-identity#secret-manager)）または`kms_key`（AWS KMSまたはGoogle Cloud KMS）を使用します。[設定リファレンス](https://platform.claude.com/docs/ja/managed-agents/self-hosted/configuration-reference#agent-identity)で、両方の設定について説明しています。
### MCPサーバーにトークンを送信する
[MCPコネクタ](https://platform.claude.com/docs/ja/managed-agents/mcp-connector)では、エージェントのMCPサーバーエントリのフィールドについて説明しています。そのエントリに`auth`フィールドを追加します：
```yaml
mcp_servers:
- type: url
name: tickets
url: https://mcp-gateway.example.com/tickets
auth:
type: agent_token
audience: https://mcp-gateway.example.com
```
ツールの一覧取得またはツール呼び出しのたびに、サーバーは新しいトークンに署名します。トークンは、ボールトの認証情報の代わりに`Authorization: Bearer `として送信されます。モデルもワーカーもこのトークンを受け取りません。
トークンと[ボールト認証情報](https://platform.claude.com/docs/ja/managed-agents/vaults)の両方を送信するには、`auth`フィールドを`agent_token_header`フィールドに置き換えます：
```yaml
mcp_servers:
- type: url
name: tickets
url: https://mcp-gateway.example.com/tickets
agent_token_header:
audience: https://mcp-gateway.example.com
```
ボールト認証情報は、どちらのフィールドもないエントリの場合と同様に、`Authorization`ヘッダーに入れて送信されます。トークンは`Bearer`プレフィックスなしで`Agent-Identity-Token`ヘッダーに入れて送信されます。
SDKには`auth`フィールドと`agent_token_header`フィールドがありません。SDKのコードでは、フィールドをMCPサーバーエントリに追加フィールドとして追加するか、リクエストをプレーンなJSONとして送信してください。
追加フィールドの送信方法は、以下のページに記載されています：
[Python SDK](https://platform.claude.com/docs/ja/cli-sdks-libraries/sdks/python#undocumented-request-params) · [TypeScript SDK](https://platform.claude.com/docs/ja/cli-sdks-libraries/sdks/typescript#undocumented-request-params) · [Go SDK](https://platform.claude.com/docs/ja/cli-sdks-libraries/sdks/go#request-fields) · [Java SDK](https://platform.claude.com/docs/ja/cli-sdks-libraries/sdks/java#undocumented-parameters) · [PHP SDK](https://platform.claude.com/docs/ja/cli-sdks-libraries/sdks/php#undocumented-request-parameters) · [Ruby SDK](https://platform.claude.com/docs/ja/cli-sdks-libraries/sdks/ruby#undocumented-request-params)
これらのページの中には、追加フィールドをリストのエントリ内ではなく、リクエストの最上位レベルでのみ示しているものがあります。その場合は、`mcp_servers`自体を追加フィールドにします。エントリに`auth`または`agent_token_header`を含めて、リスト全体をその方法で送信してください。
エージェントのトークンを停止するには、エージェントからエントリを削除するか、エージェントをアーカイブします。すでに送信されたトークンは、その`exp`まで有効なままです（デフォルトでは最大5分）。
### 受信側が検証する内容
次のすべてが満たされる場合にのみ、受信側がリクエストを受け入れるようにしてください：
* キーセット`/.well-known/jwks.json`内の鍵で署名が検証されること。正しい鍵は、IDがトークンヘッダーの`kid`と一致する鍵です。RSA鍵の場合、アルゴリズムは`RS256`です。
* `iss`が発行者URLと等しく、`aud`が受信側のaudienceと等しいこと。
* `exp`が未来の時刻であり、`iat`が未来の時刻ではないこと。
* トークンヘッダーの`typ`が`agent+jwt`であり、`token_use`が`agent`であること。
次に、以下のルールを適用してください：
* 各エージェントのアクセスルールは、API上のエージェントのIDである`agent_id`クレームに基づいて設定してください。
* 1回の一覧取得または呼び出しで、同じトークンを使って複数のリクエストが行われることがあるため、繰り返される`jti`を受け入れてください。
* ゲートウェイには各ツールをそのツール自身の認証情報で呼び出させ、トークンは決して転送しないようにしてください。
[シングルサインオン](https://platform.claude.com/docs/ja/managed-agents/self-hosted/configure#single-sign-on)を使用すると、ツール呼び出しのトークンには、セッションを作成した呼び出し元も`actor_sub`クレームと`actor_iss`クレームで記載されます。`actor_sub`は、呼び出し元がその呼び出しを承認したことを意味しません。各呼び出しはモデルが選択します。
次のトークンには`actor_sub`がありません：
* ツールの一覧取得のトークン
* サブエージェントの呼び出しのトークン
* サーバーのAPIキーで作成されたセッションのすべてのトークン
ルールが呼び出し元に依存する場合は、`actor_sub`のないツール呼び出しを拒否してください。
### MCPゲートウェイをテストする
`check-gateway`コマンドは、MCPゲートウェイに有効なトークンと無効なトークンを送信します。コマンドに専用の設定ファイル（ここでは`check-gateway.yaml`）を渡します：
1. サーバーの設定のうち、`mcp`セクションと`agent_identity`セクションのみをファイルにコピーし、サーバーが`limits.mcp_call_timeout`を設定している場合はそれもコピーします。
2. コピーで、`key_file`を、コマンドを実行するマシン上の鍵のパス（`./agent-identity/signing-key.pem`など）に変更します。ディレクトリを`compose`に移動した場合は、`./compose/agent-identity/signing-key.pem`になります。
`-agent`には、ゲートウェイが許可するエージェントのIDを指定します。rootが鍵を所有している場合は`sudo`を使用します。
```bash
./cma-server check-gateway -config check-gateway.yaml -agent agent_011CYm1BLqPXpQRk5khsSXrs \
-url https://mcp-gateway.example.com/tickets
```
このコマンドは、送信するリクエストごとに1行を、ゲートウェイの応答とともに出力します。成功した実行は、その後`check-gateway: PASS`で始まる行を出力し、コード`0`で終了します。失敗した実行は、`check-gateway:`で始まる行に問題の内容を示し、コード`1`で終了します。
## シークレットマネージャー
デフォルトでは、サーバーは[ボールトの認証情報](https://platform.claude.com/docs/ja/managed-agents/vaults)のシークレットをデータベースに保存します。`secret_store`セクションを設定すると、サーバーは新しいボールト認証情報それぞれのシークレットを、そのために予約した名前プレフィックスの下で、シークレットマネージャーに書き込みます。データベースには参照のみが保持されます。
使用するシークレットマネージャーのブロックを[設定ファイル](https://platform.claude.com/docs/ja/managed-agents/self-hosted/configuration-reference#where-settings-go)に追加します：
```yaml
secret_store:
type: aws_secrets_manager
region: us-east-1
prefix: cma-server/prod/
```
```yaml
secret_store:
type: gcp_secret_manager
project: my-project # the project ID, not its number
prefix: cma-server-prod--
```
```yaml
secret_store:
type: azure_key_vault
vault_url: https://my-vault.vault.azure.net
prefix: cma-server-prod--
```
```yaml
secret_store:
type: hashicorp_vault
address: https://vault.internal:8200
prefix: cma-server/prod/
approle:
role_id:
secret_id_file: /run/vault/secret-id
#kubernetes: { role: cma-server }
#token_file: /run/vault/token
```
3つのログインメソッドのうち、1つだけを設定してください：
* **`approle`：** Docker Compose、ホスト上、またはサーバーHelmチャートで使用します。サーバーはロールIDと、ファイルから読み取るシークレットIDでログインします。
* **`kubernetes`：** サーバーのPodにサービスアカウントトークンがある、独自のKubernetesインストールでのみ使用します。サーバーはそのトークンでログインします。サーバーHelmチャートはサーバーのPodにそのようなトークンを付与しないため、このメソッドはチャートでは機能しません。
* **`token_file`：** その他のVaultログインメソッドに使用します。サーバーの横でVault Agentを実行し、Vault Agentにトークンをこのファイルへ書き込ませます。
サーバーHelmチャートでは、シークレットIDをSecretでサーバーに渡します：
1. シークレットIDをサーバーの名前空間のSecretに格納し、そのSecretの名前をチャートの`server.extensionFiles.secretName`に指定します。
2. `approle.secret_id_file`をシークレットIDのパスに設定します。チャートはそのSecretの各キーを`/run/cma-server/extension-files/`の下にファイルとしてマウントするため、`secret-id`という名前のキーは`/run/cma-server/extension-files/secret-id`にあります。
`kubernetes`メソッドの場合は、VaultのKubernetesロールを、サンドボックスの名前空間`cma`ではなく、サーバーの名前空間とサービスアカウントにバインドします。
### アクセスを付与する
サーバーに1つのアイデンティティを付与し、そのアクセス範囲をプレフィックスに限定します。アーカイブの`iam/`ディレクトリには、シークレットマネージャーごとのファイルがあります：
* **AWS Secrets Manager：** `aws-secrets-manager-policy.json`内のプレースホルダーを置き換え、サーバーが実行されるアイデンティティにポリシーをアタッチします。
* **Google Cloud Secret Manager：** `gcp-secret-manager-role.yaml`のコメントにあるコマンドを実行します。
* **Azure Key Vault：** Azureのロールはプレフィックスではなくキーボールト全体を対象とするため、Azureのロールベースのアクセス制御を使用する、デプロイメント専用のキーボールトを用意してください。`azure-key-vault-role.json`内の`SUBSCRIPTION_ID`を置き換え、そこからカスタムロールを作成します。キーボールトに対するそのロールを、サーバーが実行されるアイデンティティに割り当てます。
* **HashiCorp Vault：** `hashicorp-vault-policy.hcl`内のプレースホルダーを置き換え、サーバーが実行されるアイデンティティにポリシーをアタッチします。
AWSとGoogle Cloudに対しては、サーバーは推論の場合と同じ方法で認証します。Azure Key Vaultに対しては、[Microsoft Foundry](https://platform.claude.com/docs/ja/managed-agents/self-hosted/inference-provider#microsoft-foundry)の場合と同様に、Microsoft Entra IDで認証します。
### セットアップを確認する
最初の起動前と、ポリシーを変更した後には、`validate-store`を実行してください。このコマンドは、サーバーを起動せずに、プレフィックスの下でテストシークレットを作成、読み取り、削除します。コマンドは、サーバーが実行される場所で、サーバーの環境を使って実行してください：
* **Docker Compose：** サーバーのコンテナ内で実行します。Armでは、このコマンドの`linux_amd64`を`linux_arm64`に置き換えてください：
```bash
docker compose exec cma-server /opt/cma-server/bin/linux_amd64/cma-server validate-store -config /etc/cma-server/config.yaml
```
* **ホスト上：**
```bash
./cma-server validate-store -config /etc/cma-server/config.yaml
```
* **Kubernetes：** 同じコマンドを、サーバーのサービスアカウントでJobとして実行します。
成功した実行は`pass`と書かれた行で終わり、コード`0`で終了します。
Azure Key Vaultを使用する場合は、利用を開始する前に、キーボールトに対してこのチェックを実行してください。
### シークレットマネージャーの制限事項
* **設定は一度だけ選択してください。** 次のいずれかの変更を行うと、サーバーは変更前に書き込んだシークレットを見つけられなくなります：
* `secret_store`セクションを削除する。
* `type`、`prefix`、`region`、`project`、`vault_url`、`mount`、または`namespace`を変更する。最後の2つは、HashiCorp Vaultのオプション設定です。
* `address`を別のVaultに向ける。
古い値を元に戻した場合にのみ、サーバーはそれらのシークレットを再び見つけられます。
* **1つのアイデンティティがプレフィックス全体を読み取ります。** 2つのグループが互いの認証情報にアクセスできてはならない場合は、各グループに独自のデプロイメントを用意してください。各デプロイメントには、独自のプレフィックスまたはキーボールトと独自のアイデンティティが必要です。
## 環境変数の認証情報
[環境変数の認証情報](https://platform.claude.com/docs/ja/managed-agents/vaults#add-a-credential)を使用すると、サンドボックスがシークレットのプレースホルダーのみを保持した状態で、エージェントのコマンドがサービスを呼び出せます。エグレスゲートウェイは、認証情報に記載されたホストへのリクエストに実際の値を挿入します。
ゲートウェイ`cma-egress`は、リリースアーカイブに含まれるプロキシで、サンドボックスとインターネットの間に位置します。ゲートウェイはデフォルトでは無効であり、サーバーはゲートウェイが有効な場合にのみこれらの認証情報を受け付けます。
ゲートウェイを有効にすると、サンドボックスに2つの制限が適用されます：
* サンドボックスはゲートウェイ経由でのみインターネットにアクセスします。
* ゲートウェイは、サーバーの`egress.allowed_hostnames`設定に記載したホストにのみ接続します。
ワイルドカードを使わず、正確なパブリックホスト名を記載してください。エージェントのコマンドがダウンロード元とするすべてのホストを含めてください。
独自のサンドボックスイメージを構築した場合は、[独自のサンドボックスイメージを構築する](https://platform.claude.com/docs/ja/managed-agents/self-hosted/call-the-api#what-an-image-of-your-own-needs)に示すとおり、`cma-with-egress`を介してワーカーを起動してください。
### Composeスタックでゲートウェイを有効にする
`docker-compose.yml`があるディレクトリから、`.env`に2行を追加します。1行目には、ゲートウェイの接続先となるホストをカンマで区切って記載します。2行目は、ゲートウェイのComposeファイルを読み込みます。その後、スタックを起動します：
```bash
echo 'CMA_EGRESS__ALLOWED_HOSTNAMES=api.github.com' >> .env
echo 'COMPOSE_FILE=docker-compose.yml:docker-compose.egress.yml' >> .env
docker compose up --build -d
```
別のComposeファイルも使用している場合は、`COMPOSE_FILE`の行に追加してください。シェルの`COMPOSE_FILE`変数は`.env`内の変数より優先されるため、シェルの変数の設定を解除してください。
ゲートウェイのファイルがサーバーのその他の`egress`設定を行うため、`compose.config.yaml`に`egress`セクションを追加しないでください。
### Kubernetesでゲートウェイを有効にする
これらの手順は、[Kubernetesにデプロイする](https://platform.claude.com/docs/ja/managed-agents/self-hosted/kubernetes)のデプロイを出発点とします。そのページの`REGISTRY`、`TAG`、`PLATFORM`変数と、2つのvaluesファイルを使用します。コマンドは、OpenSSL 3.0以降を使用して、アーカイブの最上位ディレクトリから実行してください。サンドボックスチャートは、Azure Kubernetes Service（AKS）ではゲートウェイを提供しません。
これらの手順でのサーバーチャートのアップグレードでは、サーバーのPodに対するネットワークポリシーも追加されます。開始する前に、このポリシーが対象とするポートのうち2つを確認してください：
* **ポート9464（メトリクスのポート）：** ポリシーはこのポートを閉じます。Prometheusがそのポートをスクレイプする場合は、`cma-server-values.yaml`で`server.telemetry.prometheus.scraper.namespace`を、Prometheusが実行される名前空間に設定してください。
* **ポート8400（APIのポート）：** ポリシーはすべての送信元を許可します。独自のポリシーでポート8400にアクセスできる送信元を制限している場合、その制限は機能しなくなります。ネットワークポリシーは加算的に適用されるため、いずれか1つのポリシーが許可すれば接続は通過します。
```bash
docker buildx build --platform "$PLATFORM" -f kubernetes/egress/Dockerfile -t "$REGISTRY/cma-egress:$TAG" --push .
```
```bash
(umask 077 && openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:P-256 -nodes -days 825 \
-subj "/CN=cma-server egress gateway" \
-addext "basicConstraints=critical,CA:TRUE,pathlen:0" \
-addext "keyUsage=critical,keyCertSign,cRLSign" \
-keyout egress-ca.key -out egress-ca.crt)
kubectl -n cma create secret tls cma-egress-ca --cert=egress-ca.crt --key=egress-ca.key
kubectl -n cma-server create configmap cma-egress-ca --from-file=ca.crt=egress-ca.crt
GATEWAY_KEY=$(openssl rand -hex 32)
printf %s "$GATEWAY_KEY" | kubectl -n cma create secret generic cma-egress-gateway-key --from-file=gateway-key=/dev/stdin
printf %s "$GATEWAY_KEY" | kubectl -n cma-server create secret generic cma-egress-gateway-key --from-file=gateway-key=/dev/stdin
unset GATEWAY_KEY
```
その後、認証局の秘密鍵である`egress-ca.key`を削除します。これを保持する者は誰でも、サンドボックスに対して任意のWebサイトになりすますことができます。証明書の有効期間は825日です。[証明書を更新する](https://platform.claude.com/docs/ja/managed-agents/self-hosted/agent-identity#renew-the-certificate)を参照してください。
環境でセッションを一度も実行していない場合は、この手順をスキップしてください。変更前のサンドボックスは、変更後にワーカーを起動できません。これらのコマンドは、各サンドボックスのワークスペースも削除します：
```bash
kubectl -n cma scale deployment cma-dispatcher --replicas=0
kubectl -n cma delete sandboxwarmpool cma-sandbox
kubectl -n cma delete sandboxclaims --all
```
Google Kubernetes Engine（GKE）では、次のコマンドも実行してください：
```bash
kubectl -n cma delete sandboxes --all
```
`kubectl -n cma get sandboxes,pods,pvc`が何も見つけなくなるまで繰り返します。「サンドボックス側を有効にする」の手順の`helm upgrade`で、ディスパッチャーが再び起動します。
クラスターのServiceの範囲内で、ゲートウェイ用の空いているIPv4アドレスを選択します。`kubectl get svc -A`の`CLUSTER-IP`列に、その範囲内のアドレスが表示されます。次の内容を`cma-server-values.yaml`に追加します。ファイルにすでに`server`ブロックがある場合は、これらの行をそこにマージしてください：
```yaml
egressGateway:
enabled: true
proxyAddress: 34.118.224.53:3128 # the address that you chose, and port 3128
server:
config:
egress:
allowed_hostnames:
- api.github.com
```
その後、アップグレードを実行します：
```bash
helm upgrade cma-server kubernetes/server/chart --namespace cma-server -f cma-server-values.yaml --wait
```
`kubectl -n cma-server get svc`を実行して、サーバーの2つのServiceを一覧表示します。新規インストールでは、それらの名前は`cma-server`と`cma-server-egress`です。
`cma-values.yaml`で、`egress.mode`を`gateway`に変更し、`egress`の下に`gateway`ブロックを追加します。ブロックには、コマンドが一覧表示した2つの名前を指定します：
```yaml
egress:
mode: gateway
gateway:
serviceIP: 34.118.224.53 # the address that you chose
serverService: cma-server
serverEgressService: cma-server-egress
apiServerCIDRs:
- 203.0.113.10/32 # the cluster's API endpoint
```
ファイルのその他の`egress`の値はそのまま残してください。APIエンドポイントのアドレスとポートを表示するには、`kubectl get endpoints kubernetes -n default`を実行します。ポートが443でない場合は、`egress.gateway.apiServerPort`も設定してください。
```bash
helm upgrade cma kubernetes/chart --namespace cma -f cma-values.yaml --wait
```
アップグレードが`.spec.replicas`に関する競合で停止した場合は、`kubectl -n cma scale deployment cma-dispatcher --replicas=1`を実行してから、アップグレードを再度実行してください。
### 認証情報を追加する
[認証情報を追加する](https://platform.claude.com/docs/ja/managed-agents/vaults#add-a-credential)に示すとおりに、環境変数の認証情報を作成します。ホスト型のガイドでは、これらの認証情報はセルフホスト型サンドボックスではサポートされていないとされています。これはあなたのサーバーではなくホスト型サービスについての説明です。
サーバーは独自のルールを追加します。いずれかのルールに違反するリクエストは、該当するフィールド名を示す`400`エラーで拒否されます。そのうち2つのルールを以下に示します：
* `networking` (csharp, go: `Networking`)はタイプ`limited`である必要があり、`allowed_hosts` (java, php: `allowedHosts`; csharp, go: `AllowedHosts`)内のすべてのホストがサーバーの`egress.allowed_hostnames`リストに含まれている必要があります。
* `injection_location` (java, php: `injectionLocation`; csharp, go: `InjectionLocation`)はJSONで`{"header": true}`である必要があり、省略できません。
サーバーのリストにホストを追加した後、変更を適用します。Docker Composeでは、`docker compose up -d`を実行します。Kubernetesでは、サーバーの`helm upgrade`コマンドと`kubectl -n cma-server rollout restart deployment -l anthropic.com/role=server`を実行します。
### エグレスゲートウェイを確認する
認証情報のボールトを使用してセッションを作成し、エージェントに2つのコマンドを実行するよう依頼します。この例は、`api.github.com`を記載した`GITHUB_TOKEN`という名前の認証情報の場合です：
```bash
printenv GITHUB_TOKEN
curl -sS -H "Authorization: Bearer $GITHUB_TOKEN" https://api.github.com/user
```
最初のコマンドは、`cma_ph_`で始まるプレースホルダーを出力します。2番目のコマンドは、ゲートウェイがプレースホルダーをトークンに置き換えたため、トークンのGitHubアカウントのプロフィールを出力します。ゲートウェイは、リストにないホストへのリクエストを`403`エラーで拒否します。
Kubernetesで、すべてのリクエストが`503`エラーになる場合は、kube-proxyの`--masquerade-all`オプションのように、クラスターのネットワークがPodのアドレスを書き換えている可能性があります。ゲートウェイはPodのアドレスによってサンドボックスを区別するため、それらのアドレスが変更されずにゲートウェイに届く必要があります。
### 証明書を更新する
Kubernetesでは、セッションが実行されていない間に証明書を更新してください。[Kubernetesでゲートウェイを有効にする](https://platform.claude.com/docs/ja/managed-agents/self-hosted/agent-identity#turn-on-the-gateway-on-kubernetes)の「認証局とゲートウェイの鍵を作成する」の手順全体を繰り返します。この手順で認証局とゲートウェイの鍵が再度作成されるため、削除した`egress-ca.key`ファイルは必要ありません。変更点は1つだけです。`kubectl create`を実行する4行それぞれの末尾に`--dry-run=client -o yaml | kubectl apply -f -`を追加します。たとえば、`--from-file=gateway-key=/dev/stdin`で終わる行は、`--from-file=gateway-key=/dev/stdin --dry-run=client -o yaml | kubectl apply -f -`で終わるようになります。
その後、サーバーとゲートウェイを再起動します：
```bash
kubectl -n cma-server rollout restart deployment -l anthropic.com/role=server
kubectl -n cma rollout restart deployment/cma-egress
```
### エグレスゲートウェイの制限事項
* **ヘッダー：** ゲートウェイは値をリクエストヘッダーにのみ挿入し、URLやボディには決して挿入しません。デフォルトでは、対象のヘッダーは`Authorization`のみです。他のヘッダーを許可するには、`Authorization`と合わせて`egress.swap_header_names`に記載するか、Composeスタックの場合は`.env`の`CMA_EGRESS__SWAP_HEADER_NAMES`に記載してください。
* **プロキシ変数を無視するプログラム：** サンドボックスは`HTTPS_PROXY`などの関連変数を通じてゲートウェイを見つけます。MavenやGradleなどのJavaツールはこれらの変数を読み取らないため、これらのツールはどこにもアクセスできません。