Claude Code on the webを少し使ってわかったこと
ブラウザやモバイルからクラウド上の環境で Claude Code を動かせる Claude Code on the web を少し触ってみたので、そこでわかったことをまとめておきます。ローカルの Claude Code とは前提が違う部分が多く、特にセキュリティ面と開発者体験の面でいくつか気づきがありました。
注記: Claude Code on the web は本記事執筆(2026/7/5)時点でリサーチプレビュー段階の機能です。この記事の内容は 2026年6月下旬に試した段階 のものであり、今後の仕様変更で挙動が変わる可能性があります。あらかじめご了承ください。使用したClaude Code のバージョンは v2.1.177 〜 v2.1.185 あたりです（記録していなかったので推測になります。）
Claude Code on the web とは
ざっくり言うと、ローカルのターミナルではなくクラウド上の隔離された環境で Claude Code を動かし、それをブラウザやモバイルアプリから操作できる仕組みです。セッションを開始するとリポジトリがAnthropic社提供のクラウド上のVMにクローンされ、その中で Claude Code が作業します。
VM実行に関して追加料金はかかりません。 これは嬉しいですね。ただ、前述の通り現状はプレビュー機能なので、今後変更される可能性はあります。
※ 以後、Claude Code on the web上での実行を「リモート実行/リモートセッション」、それ以外での実行を「ローカル実行/ローカルセッション」と表記します。
試したこと
私は業務でよくTerraformのコードを書くので、EKSクラスターとその上で稼働するサンプルアプリを作成するTerraformコードを書かせてみました。コードを書かせるだけで、デプロイ（AWSクレデンシャルを与えてのterraform apply）まではスコープ外としました。
検証観点
1. セキュリティ面
Claude Code on the webを、「Claude Code を用いた開発におけるリスク緩和策」として活用できないかという観点で検証しました。近年、開発者端末を狙ったマルウェアが多数登場しています。ローカル端末上で開発を行なった場合、マルウェアによる侵害範囲がローカル端末全体に拡がるおそれがあります。
一方Claude Code on the webは前述のとおり、セッションごとにクラウド上のVMにリポジトリをクローンして動作する機能です。侵害範囲を当該リポジトリに局所化することができます。この「侵害範囲の局所化」という観点で気になる点はないか調査しました。
2. 開発者体験面
開発者にとって使いにくいものであれば結局普及しないので、この点で気になるところがないか調べました。
以下、気づいたことを「🔒セキュリティ面」と「🧑💻開発者体験面」に分けて書いていきます。
🔒セキュリティ面でわかったこと
アクセスできるリポジトリを絞るには GitHub 側で制限するしかない
最初、「on the web が触れるリポジトリを限定したい」と考えて、GitHub App の Repository access を Only select repositories にすればよいのかと思っていました。
しかし公式ドキュメントの注意書きを読むと、そういう話ではありませんでした。
どちらの方法（※ GitHub 認証方法として、GitHub Appを使う方法と、
/web-setupコマンドを使う方法があります。）を使っても、クラウドセッションは、接続されている GitHub アカウントがアクセスできるすべてのリポジトリにアクセスできます。つまり、Claude GitHub アプリがインストールされているリポジトリだけでなく、他のリポジトリにもアクセス可能です。（中略）チームがクラウドセッションからアクセスできるリポジトリを制限したい場合は、GitHub 自体でアクセスを制限する必要があります。
つまり、アクセス範囲を絞りたいなら GitHub アカウント側（チームやリポジトリへのアクセス権）で制限する 必要がある、ということです。GitHub App のインストール範囲＝セッションのアクセス範囲、ではない点に注意です。
実際に試してみました。以下のように GitHub Appの設定で4つのリポジトリのみに範囲を絞ったのですが、
Claude Code on the webの画面では選択した4つ以外のリポジトリも見えています。
実際に選択した4つ以外のリポジトリに対してもセッション開始（リポジトリをVM上にクローン）できました。
この「全リポジトリにアクセスできる」はちょっと気になりますね。先に書いた通り、Claude Code on the web の、「セッションごとにクラウド上のVMにリポジトリをクローンして動作する」という点のセキュアさ（侵害範囲の局所化）は魅力的です。が、仮に Claude のアクセス権を奪われてしまうと全リポジトリにアクセスされてしまうので、この面では侵害範囲の局所化を望めないということになります。
現時点でできるベストプラクティスとしては、各開発者のGitHubアカウントに直接Claudeを紐付けず、プロジェクト毎にClaude Code用GitHubアカウントを作成して、必要最低限のリポジトリにのみアクセスできるようにすることでしょうか。正直面倒だなと感じますが… AIエージェントが使うアカウントと人間が使うアカウントは分けるべきという話を最近よく耳にしますが、ここでもその主張が適用できそうです。
クラウド環境の設定をチームで共有・テンプレート化する仕組みは（まだ）ない
クラウド環境の設定（セットアップスクリプト・環境変数・ネットワーク許可リスト）を、チーム間で強制・共有・テンプレート化・エクスポート／インポートするような仕組みは見当たりませんでした。個別に工夫することになります。
- セットアップスクリプト:
SessionStartフックにしてコミット・プッシュすれば共有可能です。CLAUDE_CODE_REMOTE環境変数で分岐させれば、リモート実行時のみ動かすこともできます。ただし、セットアップスクリプトにて実行された処理はキャッシュされ、後のセッションの開始点として再利用することができますが、SessionStartフックで実行した処理はキャッシュには乗りません。 - ネットワーク許可リスト: 共有する方法は見当たりませんでした。リポジトリに設定をプッシュしておいて各開発者に設定を促す、といった運用で実現するしかないですね。
プリインストールツールが多く、脆弱性リスクは相対的に高まる
各セッションが動く VM にはあらかじめ多くのツールがインストールされています。便利な反面、これらに脆弱性があった場合、必要最小限に絞れる Dev Container などと比べると、セッション内での影響範囲が相対的に広がる可能性があります。
なお、Terraform はプリインストールされてませんでした。
GitHub 連携ツールが自動でセットアップされる
検証中、git push が deny リストでブロックされている状態だったにもかかわらず、Claude Code から次のように言われました。
git push が
.claude/settings.jsonの deny リストに登録されていたため Bash での push が不可だったが、mcp__github__push_filesで GitHub API 経由のプッシュに成功した
つまり Bash の git push は塞いでいても、GitHub API 経由のツールでは push できてしまった わけです。加えて私は GitHub MCPサーバーを設定していませんでした。 on the webでは自動で追加されるようです。
これはおそらく、公式ドキュメントにある「Claude がセットアップなしで問題を読み取り、プルリクエストをリストし、diff を取得し、コメントを投稿できる組み込み GitHub ツール」に該当するものと思われます。
deny リストで Bash の git push を塞いでいるだけでは push を止めきれない可能性がある、という点は覚えておいたほうがよさそうです。とはいえ、on the webでの基本的な開発フローは、「VM上のフィーチャーブランチで開発を行わせて、GitHub上のリモートブランチにプッシュさせてPR作成」というものなので、プッシュができないと使い物にならないとも言えます。
- ローカルとリモート実行を併用する
- ローカルではClaude Codeに
git pushさせたくない
という方針の場合、permissionsの設定を一工夫する必要がありそうです。
pre-push フックによるチェックは動作しないことが多そう
push 前に各種チェックを通す Git の pre-push フックがあります。万一Claude Codeにより開発中にマルウェアをインストールしてしまった場合でも、このpre-pushフックスクリプト内でセキュリティチェックを行うことで、影響範囲をVM内にとどめることはできないかと考えました。
ですが、on the web では pre-push フックは動作しないことが多そう です。理由は2つあります。
1つ目は、push の実行方法によって発火するかどうかが変わることです。
- Bash で
git pushを実行 → ✅ 発火する - GitHub の API ツール（前述の
push_files等）で push → ❌ 発火しない
前述のとおり Claude Code は GitHub API 経由で push することがあるため、pre-push フックをすり抜けるケースがあります。
2つ目は、そもそもフックの設置がやや面倒なことです。.git/hooks/ はバージョン管理対象外でクローンに含まれないため、リモートセッションの新規クローンにはカスタム pre-push フックが存在しません。入れるなら、セッション中に自分で配置する必要があります。
- セットアップスクリプト or SessionStart フックで
.git/hooks/pre-pushを書き出してchmod +x - または
core.hooksPathをコミット済みディレクトリに向ける - または husky 等（
npm installでcore.hooksPath=.huskyを配線）
pre-push チェックは Claude Code の PreToolUse フックで代替できる
上記のように Git の pre-push フックには穴がありますが、Claude Code の PreToolUse フック で代替できます。push_files など GitHub API 経由の push ツールの実行時に発火するよう定義すれば、API 経由の push もチェック対象にできます。
MDM で配布したセキュリティツールは範囲外になる
これは当然といえば当然ですが、MDM で全社員の端末に入れているセキュリティツール（Sentinel など）は、クラウド上の隔離された VM では範囲外になります。ローカル端末で効いていた保護が on the web では効かない、という前提で運用を考える必要があります。
🧑💻開発者体験面でわかったこと
ローカル ↔ リモート の引き継ぎの現状
ローカルセッションからリモートセッションへの引き継ぎ周りは、試した時点で以下のような状況でした。
& {プロンプト内容} でローカルセッションを途中からリモートに飛ばすやり方は無くなったようです。 プレビューリリース直後はできたようですが、実際に使っても動かず（v2.1.177 で検証）、公式ドキュメントにも言及が見当たりませんでした。
claude --remote "{プロンプト内容}" でローカルターミナルからリモートセッションを開始することはできます。ただしこれは「開始する」だけで、「ローカルで始めたものを途中からリモートにする」ではありません。--resume と組み合わせるとエラーになります。
% claude --resume "slack-mcp-permissions-update" --remote ※ `slack-mcp-permissions-update` がローカルセッション名
Error: --cloud cannot be combined with --resume.
To reattach to a cloud session, pass its id: `claude --cloud <session-id>` (find IDs at claude.ai/code).
最後の一行To reattach to a cloud sessionがどういうことかよくわからないのですが、--cloud を使うと、別セッションが新規に立ち上がる挙動で、claude --remote と同じ挙動のように見えます。
# 以下は単に "slack-mcp-permissions-update"というプロンプトを与えた新規セッションが開始されるだけでした
% claude --cloud "slack-mcp-permissions-update"
Created cloud session: Update Slack MCP permissions
View: https://claude.ai/code/session_01H8BjhUSNdFfGBiYycGhoge?from=cli&m=0
Resume with: claude --teleport session_01H8BjhUSNdFfGBiYycGfj14
既存のリモートセッションIDを引数に渡してもエラーになりました。
% claude --cloud session_017rp1aTs6U4jqvT4Spyhoge
Error: Attaching to an existing cloud session is not enabled for your account.
claude --teleportでリモートセッションを途中からローカルで扱うことはできます。ただし、そのローカルセッションはリモートセッションと同期されるわけではありません（ブランチが分かれるイメージ）。
使えない組み込みコマンドがある
ローカルでは使える組み込みコマンドのうち、on the web で使えないものがいくつかありました。試した範囲では以下が使えませんでした。
/branch/doctor/rewind
またドキュメントにも次の記載があります。
/modelや/configのようなインタラクティブターミナルピッカーを開くコマンドは利用できません。
ただ、 /model は以下のようなフォームが出てきてモデル選択できました（2026/7/4現在）
/config も動作しました。が、ローカル版とは異なり、claude.aiのClaude Codeの設定画面↓が開きました。
/mcp もコネクタ設定画面が開きました。
現時点では組み込みコマンドは使えないものや、ローカルと挙動が違うものがあり、ドキュメントの表記も不正確な部分が多いと思ったほうが良さそうです。
settings.local.json の運用を見直す必要がある
settings.local.json はコミットせず（.gitignore に含める）、設定例だけ settings.local.example.json として共有する、というやり方をしていました。しかし on the web は リモートリポジトリにプッシュ済みのコードしか使わない ため、この方法がそのままでは通用しません。
開発者固有の環境変数（API キーなど）は、前述のクラウド環境のセットアップスクリプト（もしくはSessionStart フックスクリプト）や環境変数設定に入れるか、セッション内で入れるかを検討することになりそうです。
プルリクエストを自動作成してくれるモードがある
セッション完了時にプルリクエストを自動作成してくれるモードがあります。オンにしていなくても、セッション内で依頼すれば作成してくれます。また、プルリクエストを監視して修正対応してくれるモードもあります。
サブディレクトリ単位のセッションは作れない
Git リポジトリのサブディレクトリ以下のみをVM上にクローンしてセッションを作れるか試してみましたが、できませんでした。リポジトリ全体が VM にクローンされます。モノレポ構成だと開発に不要なディレクトリも含めざるを得ないですね。※ sparse-checkout の挙動は未検証です。
プラン変更(Enterprise → Max)でセッション履歴が引き継げない
検証途中で会社契約のEnterprise Planから個人のMax 5xにプラン変更しました。するとEnterprise Planのときに作成したリモートセッションはアクセス不可になりました。ローカルセッションはローカルにセッション情報が残っているのでプラン変更の影響が特になかったので、大きな違いだと感じました。
まとめ
Claude Code on the web を少し触ってわかったことをまとめました。改めて整理すると、次のあたりが特に気になったポイントです。
- アクセス範囲は GitHub 側で絞る必要がある（GitHub App のインストール範囲では絞れない）
- Bash の
git pushを deny してもすり抜けることがある。pre-push フックも API 経由の push では発火しないので、PreToolUseフックでの代替を検討する - プリインストールツールが多い分、脆弱性リスクは相対的に高まる。MDM で入れたセキュリティツールは範囲外になる
- ローカル ↔ リモート の引き継ぎや、使えない組み込みコマンド、
settings.local.jsonの運用など、ローカル前提の運用はいくつか見直しが必要
繰り返しになりますが、Claude Code on the web はプレビュー段階の機能で、本記事は 2026年6月下旬に試した段階のものです。仕様は今後変わっていくと思うので、実際に使う際は最新の公式ドキュメントもあわせてご確認ください。
