Claude Code Webのクラウド環境はどんな仕組みで動くか

Claude Code on the webのクラウドセッションは、毎回まっさらな仮想マシンで起動しながら数秒で動き出します。この両立を支えているのが「クラウド環境」という設定の単位と、セッションごとの隔離・キャッシュの仕組みです。本稿は使い方ではなく、どの環境が選ばれ、どう隔離され、何が引き継がれて何が消えるのかという内部の動きを追います。

クラウド環境とは何を束ねた単位か

クラウド環境とは、ネットワークアクセス・環境変数・セットアップスクリプトをまとめて保存した設定のかたまりです。クラウドセッションはすべて、どれか1つのクラウド環境の中で実行されます。

この単位はWeb版だけのものではありません。ターミナルのclaude --cloud、Claude Tagのチャンネルセッション、定期実行のRoutines、モバイル・デスクトップアプリのいずれでクラウドセッションを始めても、同じクラウド環境の仕組みが使われます。Claude Tagのチャンネルセッションだけは組織レベルの環境(組織共有環境かセルフホスト環境)しか選べず、個人のクラウド環境は使えません。

環境を作らなくても最初のセッションは始まります。オンボーディングの経路に応じて「Default」という環境が自動で用意されるためです。DefaultにはTrusted(許可リストのみ)のネットワークアクセスしか設定されておらず、環境変数もセットアップスクリプトも空です。事前インストール済みのツールだけでセッションが始まる、いわば素の状態です。

セッションが使う環境はどうやって決まるか

環境が1つしかない間は、すべてのセッションがその環境で動きます。複数のクラウド環境を作ると、利用面ごとに選び方が変わります。

Web版・デスクトップアプリ・モバイルアプリでは、画面上の環境セレクターで選んだ環境がそのまま使われます。自分でまだ選んでいない場合は、組織のOwnerが設定した既定環境が代わりに選ばれます。Team・Enterpriseでは、この既定環境を含む組織共有環境の作成・編集を管理画面の「Cloud environments」ページで行います。管理できるのはOwnerだけで、Adminロールにはこのページ自体が開けません。共有環境の環境変数はメンバー全員が読み取れる設計なので、値そのものを見せたくない認証情報は、平文の環境変数に置かない構成が安全です(なお後述のAPI認証情報の仕組みはPro・Maxプラン限定で、Team・Enterpriseの共有環境ではまだ使えません)。

CLIからclaude --cloudでセッションを始める場合は選び方が異なります。/remote-envコマンドで選んだ環境があればそれを使い、無ければAnthropicがホストする環境のうち一覧にあるものへ、それも無ければ一覧の先頭にある環境へフォールバックします。この一覧からは「ブリッジ環境」が除外されます。ブリッジ環境とは、クラウド環境そのものではなく、Remote Controlが自分のPCを表すために登録するエントリです。クラウドとローカルの実行場所を混同しないよう、フォールバックの対象から意図的に外されています。

/remote-env

/remote-envはユーザー設定のremote.defaultEnvironmentIdに選択を保存するため、より優先順位の高い設定レイヤー(リポジトリのプロジェクト設定など)で同じキーが指定されていない限り、その端末の全プロジェクトに適用されます。セルフホスト環境のccpool_から始まるIDは扱いが別で、セッションを送信するときに--environmentフラグを付けると、その回に限り/remote-envの選択とフォールバックの両方を上書きします。このフラグはClaude Code v2.1.224以降が必要です。

セッションはどうやって隔離されているか

クラウドセッションは、自分のPCからも他のセッションからも複数の層で切り離されています。まず実行の単位です。Anthropicがホストする環境では、各セッションが独立した仮想マシンで動きます。組織がセルフホスト環境にルーティングしたセッションだけは自社のインフラで動き、隔離の責任も自社のデプロイ側に移ります。

次にネットワークです。ネットワークアクセスのレベルは環境ごとに設定でき、無効化することもできます。ただしネットワークアクセスを無効にしても、Claude Code自体はAnthropic APIとの通信だけは続けられる点に注意が必要です。ここを経由してデータがVMの外に出る余地は残ります。アクセスレベルの4段階と、GitHubプロキシ・セキュリティプロキシによる例外的な経路はクラウド環境のネットワークアクセス設定にまとめています。

コードの分析・変更自体も、PRを作る前の段階まではすべてセッションの隔離環境内で完結します。CPU・メモリー・ディスクの上限や、標準で使えるツールの範囲はClaude Codeクラウドセッションで使えるツールとリソース制限を参照してください。

認証情報はどうやってサンドボックスの外に守られるか

クラウドセッションが扱う認証情報には、性格の異なる2種類があります。

1つ目はgitの認証情報と署名鍵です。Anthropicがホストする環境では、これらは最初からサンドボックスの外に置かれます。git操作が必要になると、プロキシがセッションの代わりにスコープ済みの認証情報で認証を行い、鍵そのものはセッションの中に一度も入りません。この仕組みに設定は要りません。

2つ目はAPI認証情報です。こちらはPro・Maxプランで任意に追加できる仕組みで、登録したAPIキーはエージェントプロキシがリクエストに後付けし、Claudeにもセッションの環境変数にも値そのものは渡りません。どのリクエストに付与され、どのリクエストには付与されないかという条件はcloud environmentの組織共有をTeam/Enterpriseで設定するで扱っています。

同じ「認証情報をセッションに見せない」という設計でも、gitの認証情報は環境を作った時点で自動的に外側に置かれるのに対し、API認証情報は登録して初めて外側の扱いになります。両者を混同すると、「gitはなぜ何も設定していないのに安全なのか」が説明できなくなります。

環境キャッシュは何を覚えていて、何を覚えていないか

セットアップスクリプトは、その環境で最初にセッションを始めたときだけ実行されます。完了すると、Anthropicはファイルシステムのスナップショットを撮り、以降のセッションはそのスナップショットを起点に始まります。新しいセッションはツールチェーンやDockerイメージが最初から乗った状態で始まり、セットアップスクリプトの実行そのものをスキップします。これが、まっさらな仮想マシンのはずのクラウドセッションが数秒で起動する理由です。

キャッシュはファイルシステムのスナップショットなので、覚えているものと忘れるものがはっきり分かれます。インストールしたパッケージ、pullしたDockerイメージ、書き込んだファイルはディスク上に残るため引き継がれます。一方、スクリプトが起動したデータベースやdocker compose upで立てたスタックのような「動いていただけ」のプロセスは引き継がれません。毎回起動し直したいプロセスは、Claudeへの依頼かSessionStartフックで個別に始める必要があります。

キャッシュが再構築されるのは、セットアップスクリプトか許可ネットワークホストを変更したとき、そしてキャッシュがおよそ7日で期限切れになったときの2パターンです。既存セッションを再開するだけなら、セットアップスクリプトは二度と実行されません。キャッシュの有効化や管理を自分で行う必要はなく、すべて自動です。

使い捨てなのに速いのはキャッシュと隔離を分けているからか

セッションが仮想マシン単位で使い捨てになる設計と、起動が数秒で終わる体感は、一見両立しなさそうに見えます。実際にはこの2つは別の層で解決されています。隔離はセッション単位(実行のたびに新しいVM)で行われ、キャッシュは環境単位(設定が変わらない限り使い回すスナップショット)で行われます。セキュリティ上の境界と、起動速度を左右するキャッシュの境界が一致していないからこそ、毎回隔離されたVMを使いながらも起動コストは環境を作った最初の1回だけで済みます。

まとめ

クラウド環境は、ネットワークアクセス・環境変数・セットアップスクリプトをまとめた設定単位で、セッションはこの環境を1つ選んで実行されます。環境が複数あるときの選び方は利用面ごとに違い、CLIでは/remote-envの選択かAnthropicホスト環境へのフォールバックが働きます。隔離はVM単位、キャッシュは環境単位という別々の層で成り立っているため、使い捨てのセキュリティと高速な起動が同時に成立しています。gitの認証情報は環境作成時から自動でサンドボックスの外にあり、API認証情報は登録して初めて同じ扱いになるという違いも押さえておくと、認証まわりのトラブルシューティングが早くなります。

Web版・モバイル・Remote Controlの使い分け全体はClaude Code Web版とは、セットアップスクリプトとSessionStartフックの役割分担はセットアップスクリプトとフックの使い分けにまとめています。