MAKOSOYO Tech

判断・比較

Claude CodeはWebとローカルCLI、どっちで使う？仕事の切り分け方

Claude Codeのクラウドセッション（旧Web版）とローカルCLIは、同じエージェントの置き場所が違う。バグの並列消化や移動中の舵取りはクラウド、手元のMCPや細かい編集はCLI、という使い分けを、サンドボックスとgitプロキシの仕組みから整理する。

Anthropicのコーディングエージェント Claude Code は、もともとターミナル（ローカルCLI）で使う製品だった。そこに、ブラウザやスマホからタスクを投げてクラウド上で動かす クラウドセッション（かつての Claude Code on the web）が加わった。

「どっちが新しい正しい使い方か」ではなく、得意な仕事が違う。この記事では、同じ Claude Code をどこで回すかを、作業の種類とセキュリティの境界から整理する。

※機能と制限は、2026年10月22日時点の Claude Code ドキュメント と Anthropic のサンドボックス解説 にもとづく。プランや提供範囲は変わることがある。

先に結論

日常の細かい編集や、手元の道具との組み合わせはローカルCLI。決まりきった修正の並列消化や、PCを閉じても進めたい作業はクラウドセッション。

やりたいこと 向くほう
今開いているリポジトリで対話的に直す ローカルCLI
MCP・hooks・ローカルツールを使う ローカルCLI
バグバックログを複数まとめて投げる クラウドセッション
通勤中に進捗を見て追加指示する クラウドセッション
GitHub の認証情報をVMに置きたくない クラウドセッション（Anthropicホスト時）
終わったクラウド作業を手元で続きから触る クラウド → CLI の teleport

料金枠は共通だ。クラウドVMに別課金はなく、Pro / Max などの既存の利用量に含まれる。CLIとクラウドを行き来しても、枠は別々に増えない。

何が違うのか

どちらも「リポジトリを見て、コマンドを回し、変更を出す」エージェントだ。違うのは、エージェントがどこで動くかである。

ローカルCLI クラウドセッション
実行場所 自分のマシン Anthropic管理のVM（または組織のセルフホスト環境）
コードの入り方 作業ディレクトリを直接触る GitHubからcloneするか、ローカルをbundleして送る
結果の返し方 手元のファイルが変わる ブランチをpushし、任意でPRを作る
向きやすい作業 対話・探索・手元ツール連携 定義がはっきりしたタスクの並列実行
起動の例 ターミナルで claude claude.ai/code、iOS、または claude --cloud

Anthropic自身も、CLIを「いちばん賢くカスタマイズできる本拠地」に据えつつ、Webとモバイルへ広げると説明している。置き場所が増えたのであって、CLIが廃れたわけではない。

クラウドが向く仕事

クラウドセッションは、次のような作業に合う。

  • バグ修正や定型のリファクタなど、ゴールが文章で書けるタスク
  • 複数リポジトリ、または複数タスクを並列で回したいとき
  • PCを閉じても進めたいとき、スマホから進捗を見て追加指示したいとき
  • バックエンド変更のように、テストで検証しやすい変更

ブラウザから GitHub をつなぎ、やらせたいことを書いて投げる。各セッションは隔離されたVMで動き、途中で追加の指示を送れる。終わるとブランチができ、必要ならPRになる。

調査前に分かりにくかったのは、「Web版＝薄いチャットUI」ではない点だ。中身はクラウド上で動く Claude Code そのものに近く、ローカルCLIと同じ系統のエージェントを、非同期で複数本走らせるための入口になっている。

claude --cloud で端末から新しいクラウドセッションを起こすこともできる。原則としてクラウドがcloneするのは GitHub 上のブランチなので、未pushのコミットや未コミットの作業は載らない。先にpushしてから起動するのが基本だ。

例外はローカルbundleで送る経路だ。リモートが無い、または github.com のリポジトリに Claude GitHub App が入っていないといった条件では、手元のリポジトリをまとめてクラウドへ送る。このとき、追跡対象ファイルの未コミット変更も含まれる（未追跡ファイルは含まれない）。GitLab や Bitbucket など非GitHubのリポジトリでは、CCR_FORCE_BUNDLE=1 を指定してbundle方式に寄せることもできる。bundleは「手元の状態を載せられる」代わりに、その内容がクラウド側へ渡る、というトレードオフでもある。

ローカルCLIが向く仕事

次はローカルのほうが扱いやすい。

  • 今の作業ツリーを見ながら、短い往復で直したい
  • ローカルの MCP サーバー、hooks、LSP、社内CLIを使いたい
  • ネットワークやファイルの境界を、自分のマシン設定で細かく決めたい
  • 大きな設計変更のように、途中で方針が変わりやすい作業

ローカルCLIの Bash には、任意でサンドボックスをかけられる。/sandbox で有効にすると、シェルとその子プロセスに対して、書き込み先と通信先のドメインをOSレベルで制限できる（macOSはSeatbelt、Linux / WSL2はbubblewrap）。Anthropicの説明では、境界を先に決めることで権限確認の回数を減らしつつ、プロンプトインジェクション時の被害範囲を狭められる、としている。

ただしこのサンドボックスが包むのはシェルコマンドが中心だ。Read / Edit などの組み込みツールや、ローカルMCP、hooksは別経路で動く。全部を一つのOS境界に入れたいなら、Claude Codeプロセスごとコンテナやサンドボックスランタイムに入れる必要がある。クラウドとローカルでは、「何が隔離されているか」の形が違う。

セキュリティの切り分けが、使い分けの理由にもなる

クラウド（Anthropicホスト）では、GitHubの認証情報や署名鍵をセッションVMの中に置かない。公式の説明では、VM内のgitはスコープ付きのcredentialでプロキシに接続し、プロキシが操作内容（認可されたリポジトリか、設定されたブランチへのpushかなど）を確かめたうえで、本物のトークンを付けてGitHubへ送る、とされている。

つまりクラウドは、「エージェントが暴走しても、GitHubの本トークンごと奪われにくい」置き方になっている。一方で、認可済みブランチへの悪いコミット自体は防ぎきれない。隔離は鍵の流出対策であって、変更内容の品質保証ではない。

ここで分けておきたいのは、鍵の保護とソースコードの機密性は別の判断軸だ、ということだ。gitプロキシは「VM内に本物のGitHubトークンを置かない」ための仕組みであり、「コードやリポジトリ内の機密がクラウドに渡らない」ことを意味しない。クラウドセッションでは、cloneやbundleで渡したコードがAnthropic管理（またはセルフホスト）の環境で扱われる。鍵をVMに置きたくない話と、ソースを外に出したくない話は、同じ「セキュリティ」でも答えが分かれる。

ローカルCLIは、実行場所が自分のマシンである点でクラウドと違う。ただしアクセス範囲は無制限ではなく、権限の承認設定や /sandbox の有無で変わる。柔軟な代わりに、どこまで読ませ・書かせ・外へ出させるかを自分で決める必要がある。ソースを外のVMに出したくないならローカル、エージェント環境にGitHubの本トークンを置きたくないならクラウド（Anthropicホスト時）、という切り分けになる。

GitHubへのつなぎ方も二通りある。Claude GitHub App を入れる方法と、端末で /web-setup してローカルの gh トークンをClaudeアカウントへ渡す方法だ。Auto-fixなど一部機能はAppのインストールが前提になる。

行き来するなら teleport

クラウドとローカルは、完全に別世界ではない。クラウドで進めたセッションを、手元のCLIへ取り込む teleport がある。

流れのイメージは次のとおりだ。

  1. クラウドでブランチまで作らせる
  2. 手元の同じリポジトリで teleport する
  3. 会話履歴とブランチをローカルCLIが引き継ぐ

その先の作業はローカル側のコピーになる。クラウド側の画面やモバイルから同じセッションを続けて舵取りしたい場合は、別の手順（ドキュメント上の remote-control など）を使う必要がある。

行き来の向きにも注意がある。CLIからは、既存のローカルセッションをそのままクラウドへ送ることはできない。クラウドへ載せたい作業があるなら、--cloud などで新しいクラウドセッションを起こす。一方、Claude Desktopアプリでは、Codeタブのメニューからローカルセッションをクラウドへ移す機能がある。端末だけ見ていると「ローカルからクラウドへは送れない」と誤解しやすいが、入口はクライアントによって違う。

「ざっくり直すのはクラウド、仕上げと手元ツール連携はCLI」という二段構えが、公式の機能の向きと揃いやすい。

つまり誰がどう使うとよいか

  • バグ票や小さな修正が溜まっている人
    クラウドに複数投げ、PR単位でレビューする。本業の編集はCLIのまま。

  • MCPや社内スクリプト前提の開発をしている人
    主戦場はローカルCLI。クラウドは、依存が薄い定型タスク用。

  • 移動が多い人
    クラウドで起動し、スマホで進捗を見て追加指示。戻ってから teleport で細部を詰める。

  • GitHubの鍵管理を厳しくしたいチーム
    Anthropicホストのクラウドセッションのgitプロキシを前提に、触らせるリポジトリをAppの範囲で絞る。

Codex Cloud や Google Jules など、同系統の「クラウドで非同期にコードを書くエージェント」もある。Claude Codeを選ぶ理由が「すでにCLIのワークフローがある」なら、クラウドはその延長として足すのが自然だ。いきなり全部をクラウドに寄せる必要はない。

現時点で押さえておきたい制限

  • クラウドのclone / PR作成は、基本的にGitHub向けの話としてドキュメントが書かれている。GitLabやBitbucketなどは、ローカルbundleで送れる場合でも、結果をそのリモートへpushできないことがある。
  • クラウドがcloneするのは、原則としてリモート上の状態だ。未pushの作業を前提にしない。ローカルbundleの経路では追跡対象の未コミット変更も送られるので、何がクラウドへ渡るかを経路ごとに確認する。
  • レート制限はCLIとクラウドで共有される。
  • 組織のポリシーや Zero Data Retention、顧客管理鍵（CMEK）などの設定によっては、クラウドセッション自体が使えない。

迷ったら、いま画面の前で往復したいか、投げてあとで見たいかで選ぶとよい。往復ならローカルCLI、投げてあとで見るならクラウドセッション、という分け方がいちばん崩れにくい。

← 記事一覧へ