はじめに
Claude Codeには、ターミナルで動いているセッションをスマホやブラウザから継続操作できる「Remote Control」という機能があります1。さらに2026年7月時点でTeam/Enterprise向けに、Remote Controlへのアクセスを「登録済みデバイス+直近18時間以内のサインイン」で縛る「Trusted Devices」がベータ提供されています2。
本記事では、このプロジェクトが実際に動いているClaude Code on the web(クラウド実行環境)のセッション内から claude remote-control を叩くとどうなるかを検証しました。結論から言うと 一発でエラーになって拒否されました。単なる紹介記事にせず、この拒否の理由をアーキテクチャ面から読み解き、Remote Control本体の使い方とTrusted Devicesの設定手順も合わせてまとめます。
この記事で学べること
- Claude Code on the web(クラウドセッション)から
claude remote-controlを実行した際の実際のエラーメッセージと、拒否される設計上の理由 - ローカル環境でRemote Controlを使う3つの起動方法(サーバーモード/インタラクティブセッション/既存セッションからの切り替え)と主要フラグ
- Team/Enterprise管理者向けTrusted Devicesの有効化手順とデバイス登録の仕組み(保存されるのは公開鍵と表示名等のメタデータのみ・生体情報自体は保存しない)
前提環境
- Claude Code v2.1.207(2026-07-11リリース・記事執筆時点の最新版)3
- 検証は本プロジェクトが実行されているClaude Code on the webのクラウドセッション上で実施
TL;DR
- Claude Code on the webのセッション内で
claude remote-control --helpを実行するとError: Remote Control is not available inside a cloud session.と即座に拒否される(実機確認済み) - 理由は公式ドキュメントの設計思想と整合する: Remote Controlは「ローカルマシンで動くセッションを別デバイスから覗く」機能で、クラウドセッション自体が既に「別デバイスからアクセスするリモートな実行環境」であるため、その中でさらにRemote Controlを起動する対象が存在しない
- Remote Controlは個人のPro/Maxプランでも使え、Bedrock/Google CloudのAgent Platform/Microsoft Foundryや
ANTHROPIC_BASE_URL経由のプロキシ環境では利用不可 - Team/EnterpriseはTrusted Devicesで「登録済みデバイス+18時間以内のサインイン」を必須化できる。生体認証の結果自体はAnthropicに送信されず、公開鍵とメタデータのみ保存される
実際に検証してみた
このセッションには claude CLIがインストール済みだったため、まずバージョンを確認しました。
$ claude --version
2.1.207 (Claude Code)
claude remote-control はサブコマンドとして存在し、--help を渡してもサーバーは起動しないはずですが、実行すると即座に次のエラーで止まりました。
$ claude remote-control --help
Error: Remote Control is not available inside a cloud session.
--help すら処理されず、コマンド自体がクラウドセッション判定の時点でブロックされています。念のため --remote-control フラグの存在自体は claude --help のオプション一覧に載っていることも確認しました。
$ claude --help | grep -A2 remote
--remote-control [name] Start an interactive session with Remote
Control enabled (optionally named)
--remote-control-session-name-prefix <prefix>
Prefix for auto-generated Remote Control session names (default: hostname)
つまりCLIのオプションパーサーレベルではフラグが認識されているものの、実行時にクラウドセッションであることを検知して起動前に弾いている、という挙動です。
なぜクラウド環境では拒否されるのか
公式ドキュメントの説明を踏まえると、この挙動は仕様として筋が通っています1。
Remote Control connects claude.ai/code or the Claude app... to a Claude Code session running on your machine... Unlike Claude Code on the web, which runs on cloud infrastructure, Remote Control sessions run directly on your machine and interact with your local filesystem.
Remote Controlは「ローカルマシンで動いているセッションに、別のデバイス(スマホ・ブラウザ)から接続して覗き見・操作する」ための機能です。一方Claude Code on the webは、そもそも Anthropic管理のクラウドインフラ上で動くセッション であり、ブラウザやモバイルアプリはその「窓」に過ぎません。
つまりクラウドセッションの内側は「ローカルマシン」に相当する実行主体そのものであり、そこからさらに「別マシンとして登録して覗いてもらう」という入れ子構造を組む対象が存在しないのです。公式ドキュメントの「Remote Control vs Claude Code on the web」の説明でも、Remote Controlの実行場所は明確に「your machine」、Claude Code on the webは「Anthropic-managed cloud infrastructure」と切り分けられています1。今回の実機エラーは、このアーキテクチャ上の切り分けをCLI側が起動前チェックとして強制している証拠と言えます。
ローカル環境でのRemote Control使い方
ローカルのターミナルでは、3つの方法でRemote Controlを起動できます1。
1. サーバーモード(複数セッションを同時に扱う)
claude remote-control --name "My Project" --spawn worktree --capacity 32
| フラグ | 内容 |
|---|---|
--name |
claude.ai/code のセッション一覧に表示するタイトル |
--spawn |
same-dir(既定)/ worktree(セッションごとに独立したgit worktree)/ session(単一セッション専用) |
--capacity |
同時セッション数の上限(既定32) |
--sandbox |
ファイルシステム・ネットワーク隔離を有効化(既定オフ) |
起動するとセッションURLとQRコードが表示され、スマホでQRを読み込むかブラウザでURLを開くだけで接続できます。
2. インタラクティブセッション
claude --remote-control "My Project"
ターミナルで通常どおり対話しながら、同時に別デバイスからも同じ会話に参加できます。
3. 既存セッションからの切り替え
/remote-control My Project
会話履歴を保持したまま、途中からRemote Controlを有効化できます。
利用条件: Pro/Max/Team/Enterpriseプランで利用可能(APIキー認証は非対応)。Amazon Bedrock・Google CloudのAgent Platform・Microsoft Foundry上では使えず、ANTHROPIC_BASE_URL がLLMゲートウェイ等 api.anthropic.com 以外を指している場合も無効化されます1。
Team/Enterprise向け Trusted Devices の設定
Trusted Devicesは組織単位の設定で、有効化すると全メンバーがRemote Controlを閲覧・操作する前に「デバイス登録」と「直近18時間以内のサインイン」の両方を満たす必要があります2。
設定手順は次のとおりです。
- Ownerが claude.ai/admin-settings/claude-code を開く
- Remote Control設定の下にある Require trusted devices をオンにする
- 既に動いているセッションは遡って保護されない(有効化後に開始したセッションのみ対象)ため、事前にメンバーへ周知する
デバイス登録は「サインイン直後」にのみ提示され、バックグラウンドで静かに登録されることはありません。日常利用では、サインインが18時間を超えて古くなった際にFace ID・Touch ID・Windows Helloまたはパスキーでのワンタップ確認が挟まるだけです。Anthropic側が保存するのは デバイスの公開鍵と表示名・プラットフォーム・登録日時などのメタデータのみ で、指紋や顔認証データそのものは送信・保存されません2。
実務への影響
この検証で分かったのは、「Remote Controlが使えない」というエラーに遭遇したとき、原因を素早く切り分けられるという実務的なメリットです。公式のトラブルシューティングにも記載がありますが、Remote Controlが動かない主な原因は次の4パターンに整理できます1。
-
クラウドセッション内から実行している(今回検証したケース。
Error: Remote Control is not available inside a cloud session.) - APIキー認証やConsoleアカウントでログインしている(claude.ai OAuthでの
/loginが必要) - Team/EnterpriseでOwnerがトグルを有効化していない
- Bedrock/Google CloudのAgent Platform/Foundry、または
ANTHROPIC_BASE_URLがプロキシを指している
「クラウド上のセッションだからRemote Controlも動くはず」という直感は誤りで、Remote ControlはあくまでローカルマシンのCLIプロセス専用の機能です。この前提を知らずにクラウドセッション内でハマると、エラーメッセージだけを見て「バグでは」と誤解しかねません。
著者視点の発見ポイント
筆者が実際に手を動かして意外だったのは、エラーが --help の時点で発生したことです。通常、CLIツールの --help はサブコマンドの実処理を一切走らせずにヘルプテキストだけを表示するのが一般的な設計です。しかしRemote Controlのクラウドセッション判定は --help の解釈より前段、つまりサブコマンドのエントリポイントそのものに組み込まれていることが実機で確認できました。これは「機能を使う前に環境要件を必ずチェックする」という、Remote Controlの設計思想の徹底ぶりを示す小さな発見だったと思います。同種の「クラウド実行環境限定の制約」を調べるときは、ドキュメントの記述だけでなく、実際にコマンドを叩いてエラーメッセージの発生タイミングまで確認する価値があると感じました。
まとめ
- Claude Code on the webのクラウドセッションから
claude remote-controlを実行するとError: Remote Control is not available inside a cloud session.で即座に拒否される(実機確認済み、v2.1.207) - 理由はアーキテクチャ上の設計: Remote Controlは「ローカルマシンのセッションを別デバイスから覗く」機能であり、クラウドセッション自体がその対象になり得ないため
- ローカル環境ではサーバーモード/インタラクティブセッション/既存セッション切り替えの3方式でRemote Controlを使える
- Team/EnterpriseはTrusted Devicesで「デバイス登録+18時間以内のサインイン」を必須化でき、生体情報自体はAnthropicに送信されない
参考リンク
- Continue local sessions from any device with Remote Control(公式ドキュメント) — Remote Control本体の仕組み・起動方法・利用条件・トラブルシューティングの引用元
- Claude Code Docs: What's new — Week 28 — v2.1.202–v2.1.206のリリース内容
- Claude Help Center: Release notes — 月次の機能ハイライト