--- title: セルフホスト型Claude Managed Agentsをアップグレードする url: https://platform.claude.com/docs/ja/managed-agents/self-hosted/upgrade description: KubernetesまたはDocker Composeでセルフホスト型Claude Managed Agentsのデプロイメントをアップグレードし、新しいリリースが動作しない場合はロールバックします。 --- セルフホスト型Claude Managed Agentsへのアクセスをリクエストするには、Anthropicのアカウントチームにお問い合わせください。 このページでは、KubernetesまたはDocker Composeでデプロイメントをアップグレードする方法と、ロールバックする方法を説明します。Kubernetesでは、ダウンタイムはアップグレードの範囲によって異なります。 | アップグレード | 最初にデータベースをバックアップする | Kubernetesでのダウンタイム | | ------------------------------------------------ | ---------------------- | ---------------------------------------------------- | | パッチ：3番目の数字のみが変わる | いいえ。データベーススキーマは変わりません。 | なし | | マイナー：2番目の数字が1つ上がる（`1.2.0`から`1.3.0`など） | はい。スキーマが変わります。 | なし（`CHANGELOG.md`のセクションにサーバーを停止する必要があると記載されている場合を除く） | | マイナーリリースをスキップする（`1.1.0`から`1.3.0`など）、または最初の数字が変わる | はい。スキーマが変わります。 | 古いサーバーを停止した時点から、新しいサーバーの準備が整うまで | Docker Composeスタックは、どの種類のアップグレードでも再起動中に停止します。 ## アップグレードする前に 展開したアーカイブの最上位にある`CHANGELOG.md`で、新しいリリースのセクションを読んでください。そのセクションは、そのリリースに固有のアップグレード手順から始まります。リリースをスキップする場合は、現在のバージョンより新しいすべてのセクションに、古いものから順に従ってください。 次に、[確認する設定とパス](https://platform.claude.com/docs/ja/managed-agents/self-hosted/upgrade#settings-and-paths-to-check)に目を通してください。 マイナーアップグレードまたはメジャーアップグレードには、データベースのバックアップが含まれます。ダンプにはすべての会話が平文で含まれるため、このページのコマンドでは[age暗号化ツール](https://age-encryption.org)を使って暗号化します。キーペアを一度作成し、秘密鍵`cma-backup.agekey`はバックアップとは別の場所に保管してください。 ```bash age-keygen -o cma-backup.agekey age-keygen -y cma-backup.agekey > cma-backup.agepub ``` ## Kubernetesでアップグレードする このページの`kubectl`コマンドは、サーバーのDeploymentの名前をシェル変数から読み取ります。コマンドを実行する各ターミナルで、次の2行を実行してください。1行目は名前を調べ、2行目はその名前を出力します。 ```bash server=$(kubectl -n cma-server get deployment -l anthropic.com/role=server -o jsonpath='{.items[*].metadata.name}') echo "$server" ``` 2行目が`cma-server`と出力した場合は、先に進んでください。別の名前が出力された場合は、アップグレードする前に[オブジェクトの名前](https://platform.claude.com/docs/ja/managed-agents/self-hosted/upgrade#object-names)を読んでください。何も出力されない場合は、`kubectl`が正しいクラスターを指していることを確認し、2行を再度実行してください。 新しいアーカイブを展開します。[イメージをビルドしてプッシュする](https://platform.claude.com/docs/ja/managed-agents/self-hosted/kubernetes#build-and-push-the-images)のとおりに、その3つのイメージを新しいバージョンでビルドしてプッシュします。[エグレスゲートウェイ](https://platform.claude.com/docs/ja/managed-agents/self-hosted/agent-identity#environment-variable-credentials)を実行している場合は、そのイメージもビルドしてプッシュします。 独自のサンドボックスイメージをビルドしている場合は、それも新しいバージョンで再ビルドしてプッシュします。そのDockerfileを新しいアーカイブの`kubernetes/sandbox/Dockerfile`と比較し、[独自のイメージに必要なもの](https://platform.claude.com/docs/ja/managed-agents/self-hosted/call-the-api#what-an-image-of-your-own-needs)を参照してください。 valuesファイルで`image.tag`を設定している場合は、新しいバージョンに変更してください。 この手順は次の場合にのみ行ってください。 * 実行しているサーバーが、新しいリリースよりマイナーリリース2つ以上遅れている。 * 最初の数字（メジャーバージョン）が上がる。 * `CHANGELOG.md`のうち、実行しているリリースより新しいセクションに、サーバーを停止する必要があると記載されている。 この手順から新しいサーバーの準備が整うまで、クライアントはデプロイメントにアクセスできないため、メンテナンス期間を計画してください。 ```bash kubectl -n cma-server scale deployment/$server --replicas=0 kubectl -n cma-server wait --for=delete pod -l anthropic.com/role=server --timeout=90s ``` マイナーアップグレードまたはメジャーアップグレードの前、またはサーバーを停止した場合に、これを行ってください。旧リリースが変更後のスキーマで動作できない場合、このバックアップが元に戻す唯一の手段です。 データベースサーバーと同じメジャーバージョンのPostgreSQLの`pg_dump`を使用してください。``と``には、`cma-server-values.yaml`の`database.url`の`user`と`dbname`の値を使用してください。`pg_dump`はロールのパスワードの入力を求めます。 ```bash set -o pipefail PGSSLMODE=require pg_dump -h -U -d -Fc \ | age -r "$(cat cma-backup.agepub)" -o cma_server-.dump.age ``` どちらかのコマンドがエラーを出力した場合、残されたファイルはバックアップではありません。原因を修正し、先に進む前にコマンドを再実行してください。 サーバーが実行中の場合、バックアップにはダンプの開始前にクライアントが書き込んだ内容のみが含まれます。 インストール時のvaluesファイルを使用して、新しいアーカイブの最上位ディレクトリから次のコマンドを実行します。 ```bash helm upgrade cma-server kubernetes/server/chart --namespace cma-server -f cma-server-values.yaml --wait helm upgrade cma kubernetes/chart --namespace cma -f cma-values.yaml --wait ``` 複数の環境を実行している場合は、各サンドボックスリリースについて、そのリリースの名前、名前空間、valuesファイルを指定して2番目のコマンドを実行してください。 サーバーを停止した場合、1つ目のコマンドはスキーマを移行し、サーバー数を元に戻し、新しいサーバーの準備が整った時点で戻ります。 サーバーが実行中の場合、Helmは古いサーバーを停止する前に新しいサーバーを起動するため、準備が整ったサーバーの数が減ることはありません。マイナーアップグレードでは、1つ目のコマンドは古いサーバーがサービスを提供している間にスキーマを変更し、その後、古いサーバーを置き換えます。置き換え中のサーバー上で開いているイベントストリームは正常に終了するため、ストリームを追跡しているクライアントは再接続する必要があります。 コマンドが失敗した場合は、[アップグレードが失敗した場合](https://platform.claude.com/docs/ja/managed-agents/self-hosted/upgrade#if-the-upgrade-fails)を参照してください。 ## Docker Composeでアップグレードする 手順はどの種類のアップグレードでも同じです。各`docker compose`コマンドは、リリースのComposeディレクトリ（`docker-compose.yml`を保持するディレクトリ）から実行します。展開したアーカイブでは、そのディレクトリは`compose`です。`ANTHROPIC_BASE_URL`、`ANTHROPIC_API_KEY`、`ANTHROPIC_AUTH_TOKEN`が設定されていないターミナルを使用してください。Composeはシェルにあるこれらの変数の値をサーバーに渡すためです。 マイナーアップグレードまたはメジャーアップグレードの前に、古いリリースのComposeディレクトリから次を実行します。 ```bash set -o pipefail docker compose exec -T postgres sh -c 'pg_dump -U "$POSTGRES_USER" -d "$POSTGRES_DB" -Fc' \ | age -r "$(cat cma-backup.agepub)" -o cma_server-.dump.age ``` コマンド内の`$POSTGRES_USER`と`$POSTGRES_DB`はそのままにしてください。シングルクォート内のテキストは`postgres`コンテナ内で実行され、コンテナはこれらの変数にロールとデータベースの名前を保持しています。 バックアップ中もスタックはサービスを提供し続けるため、ダンプには開始後にクライアントが書き込んだ内容は含まれません。どちらかのコマンドがエラーを出力した場合、残されたファイルはバックアップではありません。原因を修正し、先に進む前にコマンドを再実行してください。 新しいアーカイブを、古いリリースの親ディレクトリなど、新しいリリースを置いておけるディレクトリに置きます。コマンドはそこでアーカイブを展開し、新しいスタックは展開されたファイルから実行されます。 umaskが`022`より厳しい場合は、先に`umask 022`を実行してください。次に、古いリリースのComposeディレクトリから以下を実行します。``を新しいアーカイブを保持するディレクトリのフルパスに、``をアーカイブの名前（`.tar.gz`を除いたもの）に置き換えてください。 ```bash releases="" tar -xzf "$releases/.tar.gz" -C "$releases" && cp .env compose.config.yaml "$releases//compose/" ``` 2行目は、`.env`と`compose.config.yaml`も展開された`compose`ディレクトリにコピーします。古いスタックは両方の行の実行中も動作し続けます。いずれかの行がエラーを出力した場合は、原因を修正して両方の行を再実行してください。 引き継がれるのは`.env`と`compose.config.yaml`のみです。その他の変更は、新しいリリースのComposeディレクトリで再度行ってください。 * **追加したファイル:** コピーします。 * **編集した同梱ファイル:** 新しいリリースのコピーで同じ編集を行います。古いファイルで上書きしないでください。リリースでのそのファイルへの変更が元に戻ってしまいます。 * **エージェントアイデンティティ:** `agent-identity`ディレクトリを`cp -a`でコピーし（rootが所有している場合は`sudo`を使用）、`docker-compose.yml`の`volumes:`ブロックを再度編集します。 * **独自のComposeファイル:** コピーし、その相対パスを確認します。 次に、[確認する設定とパス](https://platform.claude.com/docs/ja/managed-agents/self-hosted/upgrade#settings-and-paths-to-check)にあるDocker Composeの変更を行います。 これらの行は、アーカイブを展開したターミナルの`$releases`変数を使用するため、そのターミナルで実行してください。古いリリースのComposeディレクトリにとどまり、``を同じ名前に置き換えてください。古いスタックのために`COMPOSE_FILE`をエクスポートしていた場合は、先に同じ値をエクスポートしてください。 ```bash ls "$releases//compose/.env" && docker compose down cd "$releases//compose" && docker compose up --build -d ``` 1行目は、新しいリリースの`.env`が配置されている場合にのみ古いスタックを停止します。`docker compose down`はデータベースを保持します。`-v`を追加しないでください。データベースが削除されます。新しいスタックはデータベースを引き継ぎ、その`migrate`コンテナがサーバーの起動前にスキーマを更新します。 コマンドが失敗した場合は、[アップグレードが失敗した場合](https://platform.claude.com/docs/ja/managed-agents/self-hosted/upgrade#if-the-upgrade-fails)を参照してください。 ## アップグレードが失敗した場合 ロールバックする前に、ログで原因を確認してください。 * **Kubernetes:** マイグレーションJobが失敗した場合、`helm upgrade`はJobが再試行する間数分待機し、その後失敗します。その待機中に、2つ目のターミナルで、[Kubernetesでアップグレードする](https://platform.claude.com/docs/ja/managed-agents/self-hosted/upgrade#upgrade-on-kubernetes)のとおりに`$server`を設定して`kubectl -n cma-server logs job/$server-migrate`を実行してください。Jobが再試行を停止すると、Kubernetesはログを削除します。ログを見逃した場合は、`helm upgrade`を再度実行してください。これによりJobが再び開始されます。 * **Docker Compose:** `docker compose up --build -d`の出力に原因が表示されないことがあります。`docker compose logs`を実行して原因を確認してください。 | ログに表示される内容 | 意味 | 対処方法 | | --------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `refusing to migrate: servers of another release are still running against this database`を含む行 | 一部のアップグレードでは最初にすべてのサーバーを停止する必要がありますが、古いリリースのサーバーがまだ実行中です。マイグレーションは何も変更していません。 | [Kubernetesでアップグレードする](https://platform.claude.com/docs/ja/managed-agents/self-hosted/upgrade#upgrade-on-kubernetes)のとおりにすべてのサーバーを停止し、`helm upgrade`を再度実行します。サーバーが正常にシャットダウンしなかった場合は、先に20秒待ってください。それまでは、マイグレーションはそのサーバーを実行中とみなします。 | | 旧リリースを再度デプロイしたときの、`cannot downgrade`を含む行 | 旧リリースは変更後のスキーマで動作できません。 | [ロールバックする](https://platform.claude.com/docs/ja/managed-agents/self-hosted/upgrade#roll-back)のとおりにバックアップを復元します。 | | マイグレーションからのその他のエラー | ロールバックする必要はありません。Kubernetesでは、マイグレーションが成功するまでサーバーはそのままです。 | 原因を修正し、`helm upgrade`または`docker compose up --build -d`を再度実行します。 | マイグレーションは成功しても、新しいサーバーが準備完了にならない場合があります。原因を確認するには、サーバーのログを読んでください。 * **Kubernetes:** `kubectl -n cma-server logs -l anthropic.com/role=server --prefix --tail=20` * **Docker Compose:** `docker compose logs cma-server` たとえばKubernetesでは、`has invalid keys`を含む行は、新しいリリースが受け付けない`server.config`の下の設定を示しています。バックアップの復元を検討する前に、原因を修正してアップグレードコマンドを再度実行してください。復元するとデータが失われるためです。Kubernetesでは、スキーマが変更された後も、実行中の古いリリースのサーバーはサービスを提供し続けますが、停止すると再度起動できない場合があります。 ## ロールバックする このセクションの`kubectl`コマンドは、[Kubernetesでアップグレードする](https://platform.claude.com/docs/ja/managed-agents/self-hosted/upgrade#upgrade-on-kubernetes)の`$server`変数を使用します。ロールバックする前に、[アップグレードが失敗した場合](https://platform.claude.com/docs/ja/managed-agents/self-hosted/upgrade#if-the-upgrade-fails)を確認してください。その後、アップグレードの種類に応じてロールバックします。 * **パッチアップグレードの後:** [旧リリースを再度デプロイする](https://platform.claude.com/docs/ja/managed-agents/self-hosted/upgrade#deploy-the-old-release-again)の手順に従ってください。両方のリリースは同じスキーマを使用します。 * **マイナーアップグレードまたはメジャーアップグレードの後:** 新リリースのアーカイブの`CHANGELOG.md`を開いてください。戻す先のリリースより後に出たすべてのリリースのセクションを読んでください。 * 旧リリースがマイグレーション済みのデータベースでは起動できないとセクションに記載されている場合は、バックアップを復元してください。 * それ以外の場合は、旧リリースを再度デプロイしてください。それが`cannot downgrade`で失敗した場合は、バックアップを復元してください。 復元すると、バックアップの開始以降にクライアントが書き込んだものはすべて失われます。 ### 旧リリースを再度デプロイする * **Kubernetes:** 旧アーカイブの最上位ディレクトリに移動します。[Kubernetesでアップグレードする](https://platform.claude.com/docs/ja/managed-agents/self-hosted/upgrade#upgrade-on-kubernetes)の2つの`helm upgrade`コマンドを、そのリリースで使用していたvaluesファイルで実行してください。たとえば、アップグレードのために`earlierNames`を追加した場合は、それを削除します。2番目のコマンドは、最初のコマンドが成功した場合にのみ実行してください。 * **Docker Compose:** 新リリースのComposeディレクトリで`docker compose down`を実行し、次に旧リリースのComposeディレクトリで`docker compose up --build -d`を実行してください。 旧リリースが変更後のスキーマで動作できない場合、ログには`cannot downgrade`が表示されます。 * **Kubernetes:** マイグレーションJobは失敗し、サーバーはそのまま変わりません。Jobのログを読む方法は[アップグレードが失敗した場合](https://platform.claude.com/docs/ja/managed-agents/self-hosted/upgrade#if-the-upgrade-fails)に記載されています。 * **Docker Compose:** サーバーは起動しません。`docker compose logs migrate`でログを読んでください。 Docker Composeでは、代わりに`docker compose logs`の出力に`stored value is encrypted but no encryption key is configured`と表示される場合があります。その場合、旧リリースの`.env`に`CMA_STORE__CREDENTIALS_ENCRYPTION_KEY`の行がありません。新リリースの`.env`からその行をコピーし、`docker compose up --build -d`を再度実行してください。 ### Kubernetesでバックアップを復元する データベースサーバーには、データベースの2つ目のコピーを置く容量が必要です。``と``には、`cma-server-values.yaml`の`database.url`の`user`と`dbname`の値を使用してください。 データベースサーバー上の`postgres`データベースに管理者として接続し、次を実行してください。 ```sql CREATE DATABASE _restored OWNER ; ``` 次に、バックアップを保持しているマシンで、キーとバックアップファイルのパスを指定してこれを実行してください。データベースサーバーと同じメジャーバージョンの`pg_restore`を使用してください。ロールのパスワードを要求され、成功した場合は何も出力されません。 ```bash age -d -i cma-backup.agekey cma_server-.dump.age \ | PGSSLMODE=require pg_restore -h -U -d _restored --no-owner --exit-on-error ``` エラーが出力された場合は、中止してください。データベースは変更されていません。管理者として`DROP DATABASE _restored;`を実行してから、この手順をやり直してください。 ```bash kubectl -n cma-server scale deployment/$server --replicas=0 kubectl -n cma-server wait --for=delete pod -l anthropic.com/role=server --timeout=90s ``` 管理者として`postgres`データベースに接続し、次を実行してください。 ```sql ALTER DATABASE RENAME TO _upgraded; ALTER DATABASE _restored RENAME TO ; ``` 最初のステートメントで他のセッションがデータベースを使用していると表示された場合は、それらのセッションを閉じてから、両方のステートメントを再度実行してください。コネクションプーラーがそのようなセッションを保持している場合があります。 [旧リリースを再度デプロイする](https://platform.claude.com/docs/ja/managed-agents/self-hosted/upgrade#deploy-the-old-release-again)のKubernetesの項目に従ってください。最初のコマンドはサーバー数も元に戻します。コマンドが失敗したものの、`kubectl -n cma-server get pods`で旧リリースのサーバーが準備完了と表示される場合は、[キーの確認が失敗した場合](https://platform.claude.com/docs/ja/managed-agents/self-hosted/upgrade#if-the-key-check-fails)を参照してください。 そのデータベースには、バックアップ後にクライアントが書き込んだ内容が残っています。旧リリースが動作したら、`DROP DATABASE _upgraded;`で削除してください。 #### キーの確認が失敗した場合 「旧リリースをデプロイする」の手順では、最初の`helm upgrade`コマンドは旧リリースのサーバーが準備完了になるまで待機します。その後、サンドボックスが接続に使用するキーを確認します。コマンドが失敗したものの、`kubectl -n cma-server get pods`で旧リリースのサーバーが準備完了と表示される場合は、その確認が失敗しています。 データは復元され、サーバーは動作していますが、サンドボックスはまだサーバーに接続できません。サンドボックスは、自身の名前空間`cma`にある`cma-environment` Secretのキーで接続します。そのキーはバックアップより新しいため、復元したデータベースはそのキーを認識しません。 原因を確認するには、最初のコマンドを再度実行します。待機している間に、2つ目のターミナルを開き、そこでも`$server`を設定します。次に、`default`を環境の名前に置き換えて`kubectl -n cma-server logs job/$server-environment-default`を実行します。`Secret cma/cma-environment records key`を含む行を探してください。ログに別のエラーが表示される場合は、そこに示されている問題を修正してください。 ログにその行が表示される場合は、`kubectl -n cma delete secret cma-environment`でSecretを削除し、最初のコマンドを再度実行します。これにより、新しいキーでSecretが再作成されます。その後、2番目のコマンドを実行します。 ### Docker Composeでバックアップを復元する 新リリースのComposeディレクトリで`docker compose down`を実行します。次に、旧リリースのComposeディレクトリで`docker compose up -d --wait postgres`を実行します。以降の手順では、そのディレクトリにとどまってください。 旧リリースのComposeディレクトリから、キーとバックアップファイルのパスを指定して次を実行してください。 ```bash docker compose exec -T postgres sh -c 'psql -U "$POSTGRES_USER" -d postgres \ -c "DROP DATABASE IF EXISTS ${POSTGRES_DB}_restored" -c "CREATE DATABASE ${POSTGRES_DB}_restored"' \ && age -d -i cma-backup.agekey cma_server-.dump.age \ | docker compose exec -T postgres sh -c 'pg_restore -U "$POSTGRES_USER" -d "${POSTGRES_DB}_restored" --no-owner --exit-on-error' ``` `DROP DATABASE`と`CREATE DATABASE`が出力され、エラーがなければ成功です。 ここでも以降の手順でも、`$POSTGRES_USER`と`$POSTGRES_DB`はそのままにしてください。シングルクォート内のテキストは`postgres`コンテナ内で実行され、コンテナはこれらの変数にロールとデータベースの名前を保持しています。 エラーが出力された場合、データベースは変更されていないため、コマンド全体を再度実行できます。バックアップを復元できない場合は、新リリースのComposeディレクトリで`docker compose up --build -d`を実行して、そのリリースを再び起動してください。 ```bash docker compose exec -T postgres sh -c 'psql -U "$POSTGRES_USER" -d postgres \ -c "ALTER DATABASE $POSTGRES_DB RENAME TO ${POSTGRES_DB}_upgraded" \ -c "ALTER DATABASE ${POSTGRES_DB}_restored RENAME TO $POSTGRES_DB"' ``` `docker compose up --build -d`を実行してください。 そのデータベースには、バックアップ後にクライアントが書き込んだ内容が残っています。旧リリースが動作したら、そのデータベースを削除してください。 ```bash docker compose exec -T postgres sh -c 'psql -U "$POSTGRES_USER" -d postgres -c "DROP DATABASE ${POSTGRES_DB}_upgraded"' ``` ### 復元した後 復元すると、環境キーはバックアップを取得した時点の状態に戻ります。 * **バックアップ後に失効させたキー:** 再び有効になります。もう一度失効させてください。 * **バックアップ後に作成したキー:** 失われます。そのキーを使っていたワーカーのために新しいキーを作成してください。 コマンドは[自身のワーカーの環境キーを置き換える](https://platform.claude.com/docs/ja/managed-agents/self-hosted/kubernetes#replace-an-environment-key-for-your-own-workers)にあり、Docker Composeでも使用できます。Docker Composeスタックが起動するサンドボックスについては、スタックの起動時にキーが置き換えられるため、対応は不要です。 失効したキーを含む環境のキーを一覧表示するには、次のように`list-keys`を実行してください。 * [セルフホスト型サーバーでAPIを呼び出す](https://platform.claude.com/docs/ja/managed-agents/self-hosted/call-the-api)で設定したターミナルを使用してください。`docker compose`を実行するターミナルは使用しないでください。 * Kubernetesでは、まず別のターミナルで、そこでも`$server`を設定したうえで`kubectl -n cma-server port-forward svc/$server 8400:8400`を実行してください。 * アーカイブの最上位ディレクトリから、環境ごとに1回、その環境のIDを指定してコマンドを実行してください。 ```bash echo "$ANTHROPIC_API_KEY" | ./cma-server-admin list-keys \ -base-url http://127.0.0.1:8400 -env env_01595EKxaaTTGwwY3kyXdtbs \ -key-file - -all ``` ### バックアップをテストする ダンプが復元できることを確かめるには、「バックアップを新しいデータベースに復元する」の手順のみを実行します。この手順は[Kubernetesでバックアップを復元する](https://platform.claude.com/docs/ja/managed-agents/self-hosted/upgrade#restore-the-backup-on-kubernetes)と[Docker Composeでバックアップを復元する](https://platform.claude.com/docs/ja/managed-agents/self-hosted/upgrade#restore-the-backup-on-docker-compose)にあります。この手順は使用中のデータベースを変更しません。その後、新しいデータベースを削除します。Docker Composeでは、その名前はデータベースの名前の末尾に`_restored`を付けたものです。 ## 確認する設定とパス アップグレードコマンドを実行する前に、このセクションを読んでください。 [設定ファイル](https://platform.claude.com/docs/ja/managed-agents/self-hosted/configuration-reference#where-settings-go)の`web_tools`セクションを確認してください。ファイルにこのセクションがない場合、またはセクションでキーが1つも設定されていない場合、アップグレード後は`web_search`ツールと`web_fetch`ツールがオフになります。その場合、デフォルトのツールセットを使用するエージェントはエラーを出さずにこれらのツールなしで実行されます。ツールセットでいずれかのツールを有効にしているエージェントはセッションを開始できません。ツールを維持するには、[Webツールにはサーバー設定が必要](https://platform.claude.com/docs/ja/managed-agents/self-hosted/differences#web-tools-need-a-server-setting)を参照してください。 Kubernetesでは、各サンドボックスのvaluesファイル（`cma-values.yaml`など）で`egress.mode`が設定されていることを確認してください。サンドボックスからパブリックインターネットへのアクセスを維持するには、`egress`の下に`mode: publicInternet`を追加します。ファイルでモードが設定されていない場合、チャートはデフォルトのモードである`closed`を適用します。その場合、サンドボックスチャートの`helm upgrade`コマンドは`egress.mode is closed and egress.closed.hosts is empty`などのエラーで停止し、何も変更しません。 同じファイルで`sandbox.idleTimeout`を確認してください。ファイルで設定されていない場合、セッションのPodはエージェントのターンが終了してから約5分後に削除されます。エージェントが実行したままにしたプロセスは、Podとともに停止します。デフォルトでは、`/workspace`内のファイルは保持されます。Podを30分間保持するには、`sandbox`の下に`idleTimeout: 30m`を追加します。 設定ファイルに`inference.attribution`がないか、またサーバーの環境に`CMA_INFERENCE__ATTRIBUTION`がないかを確認してください。見つかった場合はその行を削除します。アップグレード先のリリースにはこの設定がなく、どちらかが設定されているとサーバーは起動しません。 Claude APIが推論プロバイダーである場合、アップグレード後は、各モデル呼び出しにそのセッションのID、およびそのセッションのエージェントと環境のIDが含まれます。[サーバーが推論プロバイダーに送信するもの](https://platform.claude.com/docs/ja/managed-agents/self-hosted-data-and-access#what-the-server-sends-to-its-inference-provider)を参照してください。 ### Kubernetes：オブジェクトの名前 `cma-server-values.yaml`の`earlierNames`設定で、インストールがどの名前を使用しているかを指定する必要があります。サーバーのDeploymentの名前を確認するには、`kubectl -n cma-server get deployment -l anthropic.com/role=server`を実行します。 | Deploymentの名前 | `cma-server-values.yaml`の行 | | ------------- | -------------------------- | | `cma-onprem` | `earlierNames: true` | | `cma-server` | `earlierNames: false` | ファイルにこの行がない場合は、アップグレードする前に追加し、以降のすべてのアップグレードでも残しておいてください。この行がないと、サーバーチャートの`helm upgrade`コマンドは`earlierNames`を示すエラーで停止し、何も変更しません。 `earlierNames: true`の場合、チャートのオブジェクトは`cma-onprem`の名前を保持し、サーバーはそれらの名前で作成したSecretを引き続き見つけます。これらのページでは中央の列の名前を使用します。`earlierNames: true`の場合は、代わりに最後の列の名前を使用してください。 | オブジェクト | これらのページでの名前 | `earlierNames: true`での名前 | | ------------------------- | ------------------------------- | ------------------------------- | | サーバーのDeploymentとService | `cma-server` | `cma-onprem` | | マイグレーションJob | `cma-server-migrate` | `cma-onprem-migrate` | | 各環境のJob | `cma-server-environment-` | `cma-onprem-environment-` | | データベースのパスワードを含むSecret | `cma-server-db` | `cma-onprem-db` | | 推論プロバイダーの認証情報を含むSecret | `cma-server-upstream` | `cma-onprem-upstream` | | サーバーのAPIキーと暗号化キーを含むSecret | `cma-server-keys` | `cma-onprem-server` | `earlierNames`の設定にかかわらず、名前空間の名前は`cma-server`、サーバーのイメージの名前は`cma-server-image`です。 `egress.mode: gateway`を設定する各サンドボックスのvaluesファイルでは、`egress.gateway`の下にサーバーの2つのServiceの名前を指定する必要があります。ファイルで指定されていない場合は、両方の行を追加してください。この例には、`earlierNames: true`のインストールでの名前が含まれています。 ```yaml egress: gateway: serverService: cma-onprem serverEgressService: cma-onprem-egress ``` ### Docker Compose：アーカイブのレイアウトとパス アップグレード元のリリースに`compose`ディレクトリがない場合、その`docker-compose.yml`はアーカイブの最上位、`bin`の隣にあります。新しいアーカイブでは、そのファイルは1階層深い`compose`にあります。 「その他の変更を繰り返す」の手順で、次の変更も行ってください。 * **独自のComposeファイル:** 古いアーカイブに`compose`ディレクトリがなかった場合、ファイルも1階層深くなります。ファイル内の`./bin`などのパスは`../bin`になります。ファイルで`cma-onprem`サービスを指定している場合は、その名前を`cma-server`に変更します。 * **`/etc/cma-onprem/`または`/run/cma-onprem/`の下のパス:** それぞれのパスを`/etc/cma-server/`または`/run/cma-server/`で始まるように変更します。新しいリリースの`.env`と`compose.config.yaml`、独自のComposeファイル、および追加した各`volumes:`行を確認してください。`volumes:`行では、最初のコロンより後の部分（コンテナ内のパス）のみを変更してください。