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

Claude Code on the webのクラウドセッションは、毎回まっさらな仮想マシン(VM)で始まります。それでも起動が重くならないのは、設定の単位である「クラウド環境」と、セッションごとの隔離、環境ごとのキャッシュを、別々の層で持っているからです。本稿は使い方ではなく、どの環境が選ばれ、VMがどんな状態を行き来し、何が引き継がれて何が消えるのかという内部の動きを追います。

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

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

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

環境を作らなくても最初のセッションは始まります。「Default」という環境が、オンボーディングの経路に応じて用意されるためです。CLIの/web-setupとPro・Maxのウェブオンボーディングでは自動で作られます。Team・Enterpriseのウェブオンボーディングでは、OwnerがQuick web setupを有効にしていない限り作成フォームが出て、既定値のまま作成すると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に選択を保存します。より優先順位の高い設定レイヤー(リポジトリのプロジェクト設定など)で同じキーが指定されていない限り、その端末の全プロジェクトに適用されます。

もう1つ、セルフホスト環境のccpool_から始まるIDを渡す経路があります。v2.1.287のclaude --helpでは、--environmentが次のように説明されています。

  --environment <environment_id>        Create a new cloud session that runs on
                                        the given self-hosted environment
                                        (ccpool_...).

このフラグを付けると、その回に限り/remote-envの選択とフォールバックの両方を上書きします。Anthropicホスト環境のenv_から始まるIDを渡すとClaude Code側で拒否されるので、そちらを狙うときは/remote-envで選びます。フラグにはClaude Code v2.1.224以降が必要です。

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

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

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

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

手元の設定はどこまでセッションに届くか

セッションはリポジトリの新しいクローンから始まるので、コミットしたものは届き、手元のPCにしか無いものは届きません。境界は次のとおりです。

claude.aiで有効にしたスキルは、例外としてクラウドセッションが自動で読み込みます。

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

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

gitの側にも制限があります。GitHubプロキシはブランチの削除とタグなどブランチ以外のpushを拒否しますが、どのブランチを更新できるかまでは絞りません。そこはGitHubのブランチ保護ルールで止めます。セッションに付けたリポジトリ以外へのGitHub APIやリリースアセットの要求は403になり、GraphQLも固定された一部の操作しか通りません。

API認証情報のほうは、登録できる人と、付与される範囲に条件があります。

• 追加できるのは自分の組織の管理者ロールの人です。Pro・Maxでは本人がこのロールを持っています
• 追加後は編集できません。ホストや値を変えるときは、削除して入れ直します
• 登録したホストは、環境のネットワークアクセスレベルが許さない場合でも通信できます
• api.anthropic.comと主要なパッケージレジストリ(npm・PyPI・crates.io・Go)、GitHub、セットアップスクリプトの通信には付与されません。Claude Codeがエージェントプロキシにつながるのはセットアップの後だからです
• Claude Code自身が送るテレメトリの通信にも付与されません

付与の条件の詳細はcloud environmentの組織共有をTeam/Enterpriseで設定するで扱っています。

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

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

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

キャッシュが作り直されるのは、セットアップスクリプトか許可ネットワークホストを変更したときと、期限が過ぎたときです。キャッシュの有効化やスナップショットの管理は自動で、利用者が触る場面はありません。

使い捨てのVMはどこで再利用されるのか

「セッションごとに新しいVM」という言い方は、半分だけ正確です。1つのセッションの中では、VMは作られて、止まって、戻ってきます。

各状態で何が起きるかは、環境変数・セットアップスクリプト・実行中の作業で変わります。

この表から、環境の編集が既存セッションに届くタイミングが決まります。変数もスクリプトも、編集後に届くのは次の復元か再構築からです。VMを手動で止められないので、すぐ試したい値はLOG_LEVEL=trace npm testのようにClaudeへ頼むコマンドの頭に付けるか、新しいセッションを始めます。

環境変数には例外が2つあります。OTEL_*で始まる変数はClaude Codeのテレメトリ用で、コマンドには渡されません。CLAUDE_AUTOCOMPACT_PCT_OVERRIDEはセッション側が設定した値が優先されるため、環境に追加しても効きません。

隔離とキャッシュの境界が一致していない点が、起動の速さを支えています。隔離はセッションの単位で、キャッシュは環境の単位です。新しいセッションは毎回別のVMですが、起点になるスナップショットは同じ環境のセッションで共有されます。

まとめ

環境を複数持つなら、CLIの/remote-envと、プロジェクトのスレッド、組織の既定環境が別々に効く点を先に押さえると、意図しない環境でセッションが動く事故を避けやすくなります。環境の編集が効かないときは、VMが復元と再構築のどちらを通ったか、セットアップが5分に収まっているかが見る場所です。

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