MF Blogs Tools
クラウドVMとローカルターミナルの間で会話セッションが行き来する抽象図

Article

Claude Code on the webの使い方とローカルCLIとの違い:対応プラン・環境・--remote/--teleportを整理

Claude Code on the webの使い方とローカルCLIとの違いを整理します。対応プラン(Pro/Max/Team/Enterprise)、クラウド環境に持ち込めるもの/持ち込めないもの、Setup ScriptとSessionStart Hookの使い分け、--remote/--teleportでのセッション移動、Auto-fix PR、リソース上限と既知の制約まで、ブラウザでClaude Codeを使いたい中級者向けに公式仕様を踏まえて解説します。

0:00 0:00

This article is not published in this language yet, so the Japanese version is shown instead.

Claude Code on the webは、claude.ai/code上でAnthropic管理のクラウドVMにClaude Codeを立ち上げ、ブラウザやモバイルからタスクを進められる仕組みです。本記事では、対応プラン、クラウド環境に持ち込めるもの/持ち込めないもの、--remote--teleportでのローカルCLIとの行き来、Auto-fix PR、リソース上限と既知の制約までを整理します。

結論:ローカルCLIの「PCを開きっぱなしにする」制約を外す仕組み

Claude Code on the webは、ローカルCLIを置き換えるものではなく、**「PCを閉じても進む長尺タスク」「ブラウザ/モバイルからの監視」「並列に走らせるタスク」**を可能にする上乗せレイヤーです。2026年5月時点でPro/Max/Team、およびEnterpriseのプレミアム席かChat + Claude Code席に対してリサーチプレビューとして提供されています。

押さえどころは3つです。

  1. クラウドVMはAnthropic管理:1セッション1VM、ネットワークアクセスは既定で制限付き、別途の計算課金はなく既存のレート制限を共有する
  2. 設定は「リポジトリにコミットしたもの」が正:あなたのPC上の~/.claude/は持ち込まれない
  3. ローカルCLIと相互移動できる--remoteでCLIからクラウドへ送り、--teleportでクラウドからCLIへ引き戻せる

ローカルCLIとCI連携の前提は「Claude CodeとGitHub ActionsでCIを整える手順」、チームでの利用ルールは「チームでClaude Codeを導入するときに最初に決めるルール」で扱っているので、本記事はweb固有の挙動に絞ります。

利用要件とGitHub連携

クラウドセッションを使うにはGitHubアカウントの接続が必要で、公式は2つの方法を案内しています。

方法内容向く相手
Claude GitHub Appブラウザのオンボーディングで承認チーム利用、Auto-fix PRを使いたい
/web-setupターミナルで実行し、ローカルgh CLIのトークンをClaudeアカウントに同期個人で既にghを使っている開発者

公式が重要な注意として書いている通り、どちらの方法でも接続したGitHubアカウントが見える全リポジトリにクラウドセッションがアクセスできるようになります。GitHub App側で「このリポにだけインストール」という設定はセッション粒度のアクセス制限ではなく、Auto-fix用Webhookの送信先設定です。リポを絞りたいなら、GitHub側でアカウントの所属やリポメンバーシップを絞る必要があります。

Zero Data Retentionが有効な組織は、/web-setupを含むクラウドセッション機能を使えません。TeamとEnterprise管理者は、/web-setupを組織レベルで無効化することもできます。

クラウド環境に持ち込めるもの/持ち込めないもの

公式が表で明示している、クラウドセッションに何が引き継がれるかが運用設計の起点になります。

設定・ファイルクラウドで利用可理由
リポジトリのCLAUDE.mdクローンに含まれる
.claude/settings.jsonのHooksクローンに含まれる
.mcp.jsonのMCPサーバークローンに含まれる
.claude/rules/クローンに含まれる
.claude/skills/.claude/agents/.claude/commands/クローンに含まれる
.claude/settings.jsonで宣言したプラグインセッション開始時にマーケットプレイスから取得
ユーザー~/.claude/CLAUDE.mdあなたのPCにあり、リポジトリにない
ユーザー設定のみで有効化されたプラグイン~/.claude/settings.jsonはクラウドに来ない
claude mcp addで追加したMCPサーバーユーザー設定に書き込まれるので来ない。.mcp.jsonに書く
静的なAPIトークン・認証情報専用シークレットストアは未提供
AWS SSO等の対話的認証クラウドセッションではブラウザ起動を伴うログインができない

要点は**「クラウドで動かしたい設定はリポジトリにコミットせよ」**です。MCPサーバーをclaude mcp addで個人設定だけに入れている人は、.mcp.jsonへ移してリポジトリにコミットしないと、クラウドでは消えます。

シークレット管理について公式は「専用ストアは未提供。環境変数として渡せるが、その環境を編集できる全員に見える前提で考えること」と注意しています。本番秘密はクラウドセッションに直接渡さないのが原則です。秘密情報の3層防御は「Claude Codeに秘密情報を渡さないための実践ルール」を踏まえてください。

同梱されている言語ランタイムとツール

クラウドVMには主要なランタイムとツールが事前インストールされています。代表的なもののみ抜粋します。

カテゴリ同梱内容
Python3.x、pip、poetry、uv、black、mypy、pytest、ruff
Node.js20/21/22(nvm)、npm、yarn、pnpm、bun、eslint、prettier、chromedriver
Ruby3.1/3.2/3.3、bundler、rbenv
PHP8.4、Composer
JavaOpenJDK 21、Maven、Gradle
Go/Rust/C/C++標準ツールチェイン
Dockerdocker、dockerd、docker compose
データベースPostgreSQL 16、Redis 7.0(起動はセッションで明示)
ユーティリティgit、jq、yq、ripgrep、tmux、vim、nano

公式が明記している通り**gh CLIは未同梱**です。gh releasegh workflow runが必要なら、setup scriptでapt install -y ghしてからGH_TOKENを環境変数で渡す方式が案内されています。

Setup ScriptとSessionStart Hookの使い分け

クラウド環境のカスタマイズは、setup scriptとSessionStartフックの2層で行います。違いが分かりにくいので公式の整理を表で抜き出します。

Setup ScriptSessionStart Hook
紐づく対象クラウド環境リポジトリ
設定場所クラウド環境のUI.claude/settings.json
実行タイミングClaude Code起動前、キャッシュがない時Claude Code起動後、毎回(resume含む)
スコープクラウド環境のみローカルとクラウドの両方

Setup Scriptはルートで実行され、5分以内で完了することが目安です。出力はファイルシステムスナップショットとしてキャッシュされ、次回以降のセッション起動が速くなります。サービスやコンテナの起動はキャッシュされないため、postgresqlredis-serverの起動はSessionStart Hookか手動で都度行います。

クラウドでだけ動かしたいSessionStartフックは、CLAUDE_CODE_REMOTE=trueをチェックして分岐します。

#!/bin/bash
if [ "$CLAUDE_CODE_REMOTE" != "true" ]; then
  exit 0
fi
npm install
pip install -r requirements.txt

Hooks全般の作法は「Claude CodeのHooksで開発ワークフローを自動化する方法」に整理しています。

ネットワークアクセスとセキュリティプロキシ

クラウドVMからの外向き通信は4段階で制御できます。

レベル内容
None外部接続なし
Trustednpm/PyPI/RubyGems/crates.io/GitHub/クラウドSDK等の既定許可ドメインのみ
Full全ドメイン
Custom自前のallowlist(既定リストとの併用可)

GitHubの操作は専用プロキシ経由で行われ、git pushはセッション中の作業ブランチに限定されるなど、安全側に倒した設計です。実トークンはサンドボックスに入らず、スコープ付きの代替認証で動きます。

Trusted既定でも、Bunのように一部のパッケージマネージャはセキュリティプロキシと相性が悪いという既知の注意があります。bun installが失敗したら、setup scriptで個別対応するかnpm/pnpmに寄せる、というのが現実的です。

—remoteと—teleport:ローカルCLIとの行き来

ローカルCLIからクラウドへ送るのが--remote、クラウドからローカルCLIへ引き戻すのが--teleportです。

ローカルからクラウドへ:

claude --remote "Fix the authentication bug in src/auth/login.ts"

このコマンドは、現在のディレクトリのGitHubリモートと現在のブランチをVMがクローンし、新規クラウドセッションを開始します。ローカルの未コミット変更はクラウドに行かないので、必要なら先にpushします。GitHub未接続のリポジトリの場合は、ローカルリポをバンドルしてアップロードするフォールバックが自動で動きます(100MB上限)。

クラウドからローカルへ:

claude --teleport

未コミット変更があればstashを促され、対応するブランチを自動でfetch・チェックアウトして、フルの会話履歴をターミナルに読み込みます。/teleport(または/tp)として既存セッション内からも呼び出せます。

公式が強調しているように、CLIからのセッション移動は片方向で、--teleportでクラウド→CLIに引き戻せても、CLI→クラウドへ「既存セッション」を押し戻すことはできません。--remoteは新規クラウドセッションを作るコマンドで、--remote-control(ローカルセッションをWebから監視する別機能)とは無関係である点も公式の注意です。

--remoteを複数回打てば、それぞれが独立した並列クラウドセッションになります。/tasksコマンドで進行状況を一覧できます。

Auto-fix PR:CI失敗と指摘に自動で反応する

Claude GitHub Appを入れている場合、PRに対してClaudeにCI失敗とレビュー指摘を継続監視させ、必要に応じて修正コミットを自動pushさせるAuto-fixを有効化できます。

有効化の方法は4通り公式に案内されています。

  • ClaudeコードのWebセッションで作ったPR:CIステータスバーの「Auto-fix」をON
  • ターミナル:PR該当ブランチで/autofix-prを実行(裏でWebセッションが立ち上がる)
  • モバイルアプリ:「このPRを監視して」と指示
  • 任意の既存PR:PR URLをセッションに貼って「監視して」と指示

ClaudeはPRのGitHubイベント(レビューコメント・チェック失敗)を受け取り、「明確な修正」「曖昧で確認が必要」「重複や追加対応不要」を判定して動きます。レビューコメントへの返信は接続GitHubアカウント名義になりますが、各返信に「Claude Codeから」のラベルが付くため、人間との見分けはつく設計です。

公式は重要な警告として、issue_commentイベントで動くCI(Atlantis、Terraform Cloud、独自Actions等)を使っているリポでは、AIによるPRコメントが意図せず本番デプロイ等を引き起こし得るので、有効化前に自動化を確認するように案内しています。チームでの導入ルール整備は「チームでClaude Codeを導入するときに最初に決めるルール」が参考になります。

リソース上限と既知の制約

クラウドセッションには次の概算上限が公式に明示されています。

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

大規模ビルドやメモリ集約的なテストは失敗・強制終了する可能性があるとされており、それを超えるワークロードはRemote Controlで自社ハードウェア上のClaude Codeを動かす選択肢が示されています。

そのほか、押さえておくべき制約は次のとおりです。

  • /clearはWebでは使えない:サイドバーから新規セッションを作る運用に切り替える。/compact/contextは使える
  • API key/Bedrock/Vertex/Foundryで認証している場合は--teleport不可/loginでclaude.aiアカウントに切り替える必要がある
  • 環境はアイドルで失効する:再オープン時は会話履歴を保ったまま新環境がプロビジョニングされる
  • IPアロウリストを使う組織は要例外申請:クラウドセッションはAnthropic管理インフラからAnthropic APIを叩くため、組織のIP制限を通らない
  • GitLab/Bitbucket等の非GitHubリポ:ローカルバンドル経由で送れるが、結果をリモートにpushはできない

レート制限はClaudeアカウント全体と共有で、クラウドVMの計算料金は別途課金されません。複数並列で走らせれば、当然レート消費もそれだけ増えます。

ローカルCLIとの使い分けの目安

ローカルCLIとClaude Code on the webの選び分け方は、おおまかに次のように整理できます。

シナリオ推奨
1〜2ファイルの編集、対話的に進めるローカルCLI
1時間以上かかる長尺タスク、複数並列Claude Code on the web(--remote
PR作成後のCI失敗を自動でつぶしたいClaude Code on the web(Auto-fix)
設計相談・Plan Modeでの計画ローカルCLI(必要に応じてUltraplan)
モバイル/別PCから監視・指示Claude Code on the web
MCPやサブエージェントを個人設定で使い分けているローカルCLI(クラウドに持ち込むならリポジトリへ)

「計画はローカルで、実行はクラウドで」というパターンを公式は推奨しています。Plan Modeで作った計画ファイルをコミット・pushしてからclaude --remote "Execute the migration plan in docs/migration-plan.md"で投げる、という流れです。

Plan Mode自体の使い方は「Claude Codeに「計画してから実装」させるプロンプト例」を参照してください。

Claude Code on the web利用前チェックリスト

  • 自分のプラン(Pro/Max/Team/Enterprise premium)が対応していることを確認した
  • GitHub接続方法(App or /web-setup)を選んだ
  • ZDR有効組織でないことを確認した(有効ならクラウドセッションは使えない)
  • CLAUDE.md.mcp.json.claude/配下をリポジトリにコミットした
  • 個人だけで使っていたMCPサーバーを.mcp.jsonに書き直した
  • Setup ScriptとSessionStart Hookの役割分担を決めた
  • 既定のTrustedネットワークで届かないドメインがあればCustomで許可した
  • シークレットは環境変数で渡す前提のリスクを理解した
  • Auto-fixを有効化する前に、issue_comment連動の自動化を点検した
  • 4 vCPU/16GB/30GBで足りないワークロードはRemote Controlを検討した

次に読むおすすめ記事: