記事

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を使いたい中級者向けに公式仕様を踏まえて解説します。

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つです。

クラウドVMはAnthropic管理：1セッション1VM、ネットワークアクセスは既定で制限付き、別途の計算課金はなく既存のレート制限を共有する
設定は「リポジトリにコミットしたもの」が正：あなたのPC上の~/.claude/は持ち込まれない
ローカル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には主要なランタイムとツールが事前インストールされています。代表的なもののみ抜粋します。

カテゴリ	同梱内容
Python	3.x、pip、poetry、uv、black、mypy、pytest、ruff
Node.js	20／21／22（nvm）、npm、yarn、pnpm、bun、eslint、prettier、chromedriver
Ruby	3.1／3.2／3.3、bundler、rbenv
PHP	8.4、Composer
Java	OpenJDK 21、Maven、Gradle
Go／Rust／C/C++	標準ツールチェイン
Docker	docker、dockerd、docker compose
データベース	PostgreSQL 16、Redis 7.0（起動はセッションで明示）
ユーティリティ	git、jq、yq、ripgrep、tmux、vim、nano

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

Setup ScriptとSessionStart Hookの使い分け

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

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

Setup Scriptはルートで実行され、5分以内で完了することが目安です。出力はファイルシステムスナップショットとしてキャッシュされ、次回以降のセッション起動が速くなります。サービスやコンテナの起動はキャッシュされないため、postgresqlやredis-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	外部接続なし
Trusted	npm／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に「計画してから実装」させるプロンプト例」を参照してください。