Claude Codeクラウドセッションとは — 使えるツールと制限

Claude Codeのクラウドセッションとは、自分のマシンではなくクラウド上のVMで動くClaude Codeのセッションです。ノートPCを閉じても動き続け、ブラウザやスマホから進み具合を見たり指示を足したりできます。ProとMaxとTeamのプランで使え、Enterpriseでは対象のシートが必要です。クラウドのVMに別料金はかからず、利用量はプランの上限に数えられます。

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

ローカルでは動くのにクラウドでは動かない、という食い違いの典型は「リポジトリにコミットされていないものは届かない」です。Web版の始め方そのものはClaude Code Web版とはにあり、ここではセッションの中で何が使えて何が使えないかを扱います。

ローカルで動いた設定がクラウドで効かないとき

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

リポジトリ設定の行に「リポジトリが1つのセッションのみ」と付くのは、複数のリポジトリをまたぐセッションやプロジェクトのスレッドが、クローンの1つ上の階層から始まるためです。その階層にはhooksも.mcp.jsonも置かれておらず、読まれません。

ユーザースコープのMCPサーバーをクラウドでも使いたいときは、claude mcp add --scope projectでリポジトリの.mcp.jsonに書き、その変更をコミットします。プラグインはenabledPluginsに書いてもクラウドには入らない点に注意が必要で、ユーザー設定側で有効にしたプラグインも同様に届きません。

環境変数とセットアップスクリプトは、その環境を使う全員が読める状態で保存されます。外部サービスのキーは、ProとMaxプランなら環境に登録するAPI認証情報(エージェントプロキシが対象ホストへのリクエストに付ける仕組み)に置けます。TeamとEnterpriseプランでは、この仕組みが使えないため環境変数に置くことになり、読める人の範囲がそのまま漏洩範囲になります。

手元のCLIで確認できる範囲

クラウド側の挙動はセッションを起動しないと確かめられませんが、手元のclaudeからは入口だけ確認できます。v2.1.285でログインしていない状態(空の設定ディレクトリ)から試すと、Remote Controlはclaude.aiのサブスクリプションを求められました。

$ claude --version
2.1.285 (Claude Code)
$ claude remote-control
Error: You must be logged in to use Remote Control.
 
Remote Control is only available with claude.ai subscriptions. Run `claude auth login` to sign in with your claude.ai account.

claude --helpには--remote-control [name](Remote Controlを有効にして対話セッションを始める)と--teleport [session](クラウドのセッションを手元で再開する)が並びます。上限に当たったときの逃げ道の1つがサブスクリプション前提であることは、後述の選択肢を考えるうえで先に知っておく価値があります。

クラウドセッションの始め方と手元への戻し方

ターミナルからはclaude --cloud "タスクの説明"で新しいセッションを起動します。VMが複製するのは手元のチェックアウトではなく現在のブランチのGitHubリモートなので、ローカルのコミットは先にpushします。以前の--remoteは非推奨の別名として今も動きます。

claude --cloud "tests/の失敗しているテストを直して"
claude --teleport

走っているセッションを手元で続けるにはclaude --teleportでセッションを選びます。同じclaude.aiアカウントでログインし、同じリポジトリのチェックアウトから実行する必要があります。手元に引き込んだ後の作業はローカルに残り、claude.aiやスマホのセッションには反映されません。逆向きの、既存のターミナルセッションをクラウドへ送る操作はCLIにはありません。

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

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のようなツールチェーンは、レジストリが許可リストに入っていても事前インストールされません。次節のセットアップスクリプトで入れます。

テスト・サービス起動・パッケージ追加はClaudeへの依頼にする

VMへのシェルアクセスはなく、コマンドはすべてClaudeが実行します。「テストを直す」ではなく「tests/の失敗しているテストを直して」のように、プロンプトで依頼します。pytestやcargo testは追加設定なしで動き、jestのようにプロジェクトの依存として宣言したランナーは依存関係のインストール時に入ります。

PostgreSQLとRedisは入っていますが起動していないので、起動もClaudeに頼みます。クラウド外でRedisにMCP経由で繋ぐ手順はRedis MCPサーバーの使い方にあります。

service postgresql start
service redis-server start

Dockerはdocker compose upを頼めばコンテナが立ち上がり、Docker Hubなど主要レジストリは既定の許可リストに入っています。

セットアップスクリプトと環境キャッシュ

事前インストールにないものは、セットアップスクリプトで入れます。Claude Codeの起動前にroot権限で走るBashスクリプトで、書き方の詳細はセットアップスクリプトの解説にあります。ここでは、実行から次のセッションまでの流れを押さえます。

イメージの取得が遅いときは、スクリプトにdocker compose pullかdocker compose buildを入れておくと、取得済みイメージがディスクに残ります。セッション途中でClaudeに頼んだインストールは他のセッションに引き継がれない点が、スクリプトとの違いです。

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

組み込みのGitHubツールで、issueの読み取り、PR一覧の取得、diffの取得、コメント投稿がセットアップなしで動きます。認証は専用のGitHubプロキシが受け持つため、実際のトークンがコンテナに入ることはありません。

GH_TOKENかGITHUB_TOKENを自分で設定するかどうかで、コンテナの中の見え方が変わります。

どちらの状態かは、Claudeにecho $GH_TOKENを頼めば分かります。ghは事前インストール済みで、gh releaseやgh workflow runのように組み込みツールが扱わない操作もClaude経由で実行できます。ghはGH_TOKENを自動で読むので、gh auth loginは要りません。

プロキシには3つの制限があります。1つ目はGraphQLで、PR系のワークフロー向けに決められた操作しか通りません。Projects v2のようにGraphQLでしか提供されない機能は、GH_TOKENを自分で設定していてもThis GraphQL query is not enabled for this sessionという403で拒否され、メッセージはgh api repos/{owner}/{repo}/...というREST代替を案内します。2つ目はリポジトリの範囲で、APIとリリースアセットの取得はセッションに紐づいたリポジトリだけが対象です。紐づいていないリポジトリのアセットをセットアップスクリプトで取得すると403になります。3つ目はgit pushで、通るのはセッションの作業ブランチに対してだけです(Push protection)。クローン・フェッチ・PR操作は通常どおり動きます。

ローカルで通っていた別ブランチへのpushがクラウドで拒否されるときは、まずこの制限を疑います。なお、このプロキシはAnthropic-hosted環境の仕組みで、セルフホスト環境では展開側の資格情報を使います。

セッションのURLを別の場所に載せる

クラウドセッションが作るコミットにはClaude-Session: <url>のトレーラーが付き、PR本文にもセッションURLが入ります。この付与を止めたいときは、v2.1.183で追加されたattribution.sessionUrlをfalseにします。Slack投稿やレポートファイルのように別の場所へURLを載せたいときは、環境変数CLAUDE_CODE_REMOTE_SESSION_IDから組み立てるコマンドの出力を使います。

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

リソース上限と時間の上限

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

時間の上限は、リソースとは別に効きます。

• Claudeが実行するコマンド: 環境は独自のタイムアウトを持たず、Bashツールの既定が使われる。既定は2分で、Claudeは最大10分まで求められる。タイムアウトに達したコマンドは停止でなくバックグラウンドへ移る(sleepで始まるコマンドを除く)
• SessionStartフック: timeoutを指定しなければ600秒でキャンセルされる。async: trueのフックには適用されない
• アイドル状態のセッション: 数分操作がないとVMは一時停止し、ファイルは保存される。次のメッセージで同じVMが復元される。停止したVMは後で回収されることがある。MCPコネクタのツール呼び出しの承認待ちやMCPサーバーへのサインイン待ちも、非アクティブに数えられる

コマンドのタイムアウトは、環境変数BASH_DEFAULT_TIMEOUT_MSとBASH_MAX_TIMEOUT_MS(ミリ秒)で環境ごとに延ばせます。たとえばBASH_DEFAULT_TIMEOUT_MS=600000で既定が10分になります。回収されたセッションは、claude.ai/codeから開き直すと新しいVMに会話履歴が復元されます。ただし、回収時に動いていたサブエージェントやシェルコマンドは復元されません。

上限に当たったときの選択肢

CPU・メモリ・ディスクの上限を上げる設定はないので、選択肢は2つで、性格も対象プランも違います。

社内ネットワークのサービスやDBに到達させたい、独自のツールを事前に焼き込みたい、コード実行を自社インフラに留めたい、という要件ならセルフホスト環境の領分です。個人のProやMaxで手元のマシンの余力を使いたいだけなら、選べるのはRemote Controlのほうです。

セルフホスト環境は既定で無効です。Ownerが管理画面のCloud environmentsページでAllow self-hosted environmentsを有効にする必要があり、これにはClaude Code on the webが組織で有効になっていることが前提です。Zero Data Retentionを有効にしている組織では使えません。推論はセルフホスト環境でもAnthropic APIを使い、Bedrock・Vertex・Foundry・LLMゲートウェイへのルーティングはできません。運用手順はClaude Code self-hosted-runnerとはにあります。

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

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

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

まとめ

クラウドで動かないものは、まずリポジトリにコミットされているかで切り分けられます。VMの上限を恒常的に超える作業は、Remote Controlかセルフホスト環境へ移すのが前提になります。