Claude Codeクラウドセッションで使えるツールとリソース制限

Claude CodeのクラウドセッションはUbuntu 24.04のVM(仮想マシン)を毎回新しく起動し、リポジトリをクローンした状態で始まります。Python・Node.js・Ruby・Go・Rust・Dockerなど主要な言語ランタイムとビルドツールは最初から入っており、GitHubのissueやPRもトークンを意識せず操作できます。一方でVMには4vCPU・16GBメモリ・30GBディスクという上限があり、大きなビルドやテストはここで止まることがあります。

この記事では、クラウドセッションに何が入っていて、ローカル環境の何が引き継がれないか、GitHub連携がどう安全に成立しているか、そしてリソース上限に当たったときの選択肢を、公式ドキュメントの記載に沿ってまとめます。Web版の始め方そのものはClaude Code Web版とはにまとめており、本記事はセッション内で何が使えるかに範囲を絞ります。

クラウドセッションに最初から入っているツール

クラウドセッションのVMには、カテゴリごとに次のツールチェーンがあらかじめインストールされています。

Node.jsは/opt/node20・/opt/node21・/opt/node22に並んで入っており、既定でPATHに通っているのは22です。別バージョンを使うときは、そのバージョンのbinディレクトリをPATHの先頭に足すようClaudeに頼みます。bunは、パッケージ取得時にプロキシとの相性問題がある例として明記されています。

インストール済みツールの正確なバージョンを知りたいときは、クラウドセッション上でClaudeにcheck-toolsというシェルコマンドを実行するよう頼みます。スラッシュコマンドではなくVM上のコマンドなので、/から始める操作とは別物です。Ruby・PHP・bun・PostgreSQL・Redisのようにcheck-toolsが拾わないツールは、psql --versionのようにツール自身のバージョン確認コマンドを頼みます。

# Claudeへの依頼として実行される(VM内のコマンド)
check-tools
psql --version

このリストにない.NET SDKのようなツールチェーンは、パッケージレジストリ自体がネットワークの許可リストに入っていても事前インストールはされません。使うには後述のセットアップスクリプトで自分で入れます。

ローカルの設定は何が引き継がれ、何が引き継がれないか

クラウドセッションはリポジトリのクローンから始まるので、リポジトリにコミットされているものだけが引き継がれます。自分のマシンだけにある設定は届きません。

ユーザースコープのMCPサーバーをクラウドセッションでも使いたい場合は、claude mcp add --scope projectでリポジトリの.mcp.jsonに書き、その変更をコミットします。同様に、個人設定にしているSkillやプラグインも、リポジトリの.claude/settings.jsonに書くかclaude.aiアカウント側で有効化しないと、クラウド側には現れません。

環境変数と設定スクリプトは、その環境を使う全員が読める状態で保存されます。外部サービスのAPIキーのようなシークレットは環境変数に直接書かず、専用のAPI認証情報の仕組みを使うよう公式も明記しています。

GitHubのissueとPRを、トークンを意識せず扱える

クラウドセッションにはGitHub連携ツールが組み込まれており、issueの読み取り、PR一覧の取得、diffの取得、コメント投稿がセットアップなしで動きます。これらは専用のGitHubプロキシ経由で認証されるため、実際のGitHubトークンがコンテナの中に直接入ることはありません。

GH_TOKENまたはGITHUB_TOKENを自分で設定することもできます。設定しない場合はプロキシが認証を肩代わりします。この2つの挙動は明確に分かれます。

• 自分でトークンを設定した場合: そのままコンテナに渡り、gh CLIやスクリプトはそのトークンを直接使う
• どちらも未設定でプロキシが認証する場合: Claudeが実行するコマンド内ではGH_TOKENとGITHUB_TOKENがproxy-injectedというプレースホルダー文字列として見え、実際の認証はプロキシが送信時に差し替える。gh CLI自体はトークンなしで動くが、GITHUB_TOKENを直接読むスクリプトはプレースホルダーを受け取ってしまい使い物にならない

どちらのケースかを確認したいときは、Claudeにecho $GH_TOKENを実行するよう頼めば分かります。ghコマンド自体は事前インストール済みで、gh releaseやgh workflow runのように組み込みツールが対応していない操作もClaude経由でそのまま実行できます。ghはGH_TOKENを自動的に読むため、gh auth loginは不要です。

セッションのトランスクリプトURLは、環境変数CLAUDE_CODE_REMOTE_SESSION_IDから組み立てられます。PR本文やコミット末尾にClaude-Session:という形で自動的に付くのはv2.1.179以降で、Slack投稿やレポートファイルのように別の場所にURLを載せたい場合は、次のコマンドの出力をそのまま使います。

echo "https://claude.ai/code/${CLAUDE_CODE_REMOTE_SESSION_ID/#cse_/session_}"

テスト・サービス起動・パッケージ追加はClaudeへの依頼として書く

クラウドセッションにはVMへのシェルアクセスがありません。すべてのコマンドはClaudeが代わりに実行するので、「テストを直す」ではなく「tests/の失敗しているテストを直して」のように、プロンプトの中で依頼する形になります。

pytestやcargo testのように事前インストール済みのテストランナーは追加設定なしで動きます。jestのようにプロジェクトの依存として宣言されたランナーは、依存関係のインストール時に一緒に入ります。

PostgreSQLとRedisは入っていますが、既定では起動していません。使うときは起動をClaudeに頼みます。

service postgresql start
service redis-server start

Dockerも使えます。プロジェクトのdocker compose upを頼めばコンテナが立ち上がり、Docker Hub等の主要レジストリは既定の許可リストに含まれます。イメージが大きくて毎回の取得が遅い場合は、docker compose pullをセットアップスクリプトに入れておくと、後述の環境キャッシュが取得済みイメージをディスクに残してくれます(実行中のコンテナ自体はキャッシュされないので、起動コマンドは毎回必要です)。

事前インストールにないパッケージを足したいときは、セットアップスクリプト(新しいセッションが始まるたびに、Claude Code起動前にroot権限で走るBashスクリプト)で入れます。ここでインストールしたものは環境キャッシュに残り、次のセッション以降は再インストール不要です。セッション途中でClaudeに頼んで入れることもできますが、そのインストールは他のセッションには引き継がれません。

リソース上限とその先の選択肢

クラウドセッションのVMには、時期によって変わりうる目安として次の上限があります。

• 4 vCPU
• 16GBのRAM
• 30GBのディスク

大きなビルドやメモリを大量に使うテストは、この上限を超えると途中で止められることがあります。VMのスペックを自分で選ぶ操作はできません。

上限に当たったときの選択肢は2つあり、性格が異なります。

セルフホスト環境はTeamとEnterpriseプランのパブリックベータで、既定では無効です。Ownerが管理画面のCloud environmentsページでAllow self-hosted environmentsを有効にする必要があり、これにはClaude Code on the webが組織で有効になっていることが前提になります。Zero Data Retentionを有効にしている組織では使えません。モデル推論自体はセルフホスト環境でもAnthropic APIを使う点は変わらず、Bedrock・Vertex・Foundry・LLMゲートウェイへの推論ルーティングはできません。

大規模なmonorepoのビルドやリソースを食うE2Eテストを日常的に回すチームは、Anthropic-hosted環境の固定上限に当たる前に、この2つのどちらが自分たちの制約に合うかを事前に確認しておくと安心です。セルフホスト環境の運用手順はClaude Code self-hosted-runnerとはにまとめています。

ネットワークアクセスは環境ごとに設定できる

クラウドセッションが外に出られる範囲は、環境(environment)単位で設定します。既定のTrustedはパッケージレジストリやGitHubなどの許可リストのみ、Fullは任意のドメイン、Noneは外部通信なし、Customは自分で指定したドメインリストです。

どのレベルを選んでも、GitHub通信(専用プロキシ経由)、有効化したMCPコネクタの通信(Anthropicのサーバー経由)、登録済みのAPI認証情報の宛先ホストは、環境のネットワーク許可リストを経由しない別経路で届きます。ネットワークアクセスの設定に関連するエラーが出たときの読み方は、「Host not allowed in a cloud session」の意味と対処で扱っています。

よくある質問

クラウドセッションでローカルにインストールした拡張機能は使えますか

使えません。自分のマシンだけに入っている設定・Skill・MCPサーバーは、リポジトリにコミットされていない限りクラウドセッションには届きません。個人設定として使っているものは、リポジトリの.claude/settings.jsonか.mcp.jsonに移すか、claude.aiアカウント側でSkillを有効化する必要があります。

リソース上限を超えるとどうなりますか

大きなビルドやメモリを多く使うテストは、VMが途中でタスクを止めることがあります。上限自体を上げる設定はなく、恒常的に超える作業がある場合はRemote Controlで自分のマシンを使うか、セルフホスト環境への移行を検討する形になります。

クラウドセッションでDockerは使えますか

使えます。docker・dockerd・docker composeが事前インストールされており、Docker Hubなど主要レジストリは既定の許可リストに含まれます。ただしコンテナは常駐しないため、セッションが始まるたびに起動をClaudeに依頼する必要があります。

自分のリポジトリ以外のGitHub操作はできますか

APIとリリースアセットの取得は、そのセッションに紐づいたリポジトリだけに制限されます。紐づいていないリポジトリのリリースアセットをセットアップスクリプトで取得しようとすると403になります。

check-toolsはスラッシュコマンドですか

いいえ、VM上にインストールされたシェルコマンドです。Claudeに「check-toolsを実行して」と依頼する形で使います。Ruby・PHP・bun・PostgreSQL・Redisのバージョンはcheck-toolsの対象外なので、それぞれの--version系コマンドを個別に依頼します。

まとめ

クラウドセッションは、主要な言語ランタイムとビルドツール、GitHub連携をあらかじめ備えた使い捨てのVMです。リポジトリにコミットした設定はそのまま引き継がれますが、自分のマシンだけにある設定・認証・MCPサーバーは届きません。GitHubのトークンはプロキシが肩代わりするため、GH_TOKENを自分で設定しない限りコンテナの中にトークンの実体は入りません。

4vCPU・16GBメモリ・30GBディスクという上限は、大きなビルドやリソースを食うテストで実際に効いてきます。日常的にここへ当たるチームは、手元のマシンをそのまま使うRemote Controlか、ツールチェーンとリソースを自分たちで管理するセルフホスト環境のどちらが要件に合うかを、上限に当たってから考えるのではなく事前に検討しておく価値があります。