Claude Code Remote Control は、手元のマシンで動いている Claude Code を、スマホアプリや claude.ai/code から操作できる機能です。日本語の解説はいくつも出ていますが、「自宅PCに待受ポートが開くのか」「通信はどこへ行くのか」「会社で止められるのか」という、導入判断に直結する部分にはほとんど触れられていません。本記事では v2.1.241 で実際にサーバーを起動し、lsof でソケットを数え、デバッグログから通信方式を特定した結果を示します。

Claude Code Remote Controlの実測サマリ図。待受ポートは0本、外向きのHTTPS接続のみでSSEによる送受信、宛先はAnthropicのアドレス帯であり、組織ではdisableRemoteControlで無効化できることを示す。
実際に起動して測った結果。inbound は1本も開かず、外向きのHTTPSだけで成立している。

30秒でわかる Claude Code Remote Control

・待受ポート（LISTEN）は0本。2回の起動で lsof を実行し、どちらも0本だった
・通信はSSE。受信 …/worker/events/stream／送信 …/worker/events へのPOST。宛先はwhoisで ANTHROPIC-V6 帯
・組織での禁止は managed settings の disableRemoteControl の1本で全経路（コマンド・フラグ・自動起動・トグル）が止まる
・既定は同時32セッション。--spawn=worktree でセッションごとにgit worktreeへ隔離できる
・スマホ/Webでは添付ファイルが見えない。設定変更も effortLevel と ultracode に限られる

Claude Code そのものの導入から運用までは、Claude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引きにまとめてあります。本記事はリモート操作という一点に絞ります。

Claude Code Remote Control の起動と、画面に出るもの

まず実際の挙動を押さえます。作業したいディレクトリで次を実行するだけです。

claude remote-control --name my-session

起動すると、次の情報が順に表示されます（実行結果から、環境固有のIDは伏せています）。

Remote Control v2.1.241
Spawn mode: same-dir
Max concurrent sessions: 32
Environment ID: env_xxxxxxxxxxxxxxxxxxxxxxxx

·✔️· Connected · <ディレクトリ名> · HEAD
    Capacity: 1/32 · New sessions will be created in the current directory

Continue coding in the Claude mobile app or https://claude.ai/code?environment=env_xxxxxxxxxxxxxxxxxxxxxxxx
space to show QR code

読み取れる要素は4つです。

・Environment ID（env_ で始まる）が発行され、接続用URLのクエリになる
・スペースキーでQRコードが出る。スマホから繋ぐときはこれを読む
・Capacity 表示（既定 32）と、セッションがどこに作られるか（same-dir）
・接続が確立するとセッションID（cse_ で始まる）が採番され、claude.ai/code/session_… へのリンクが張られる

claude remote-control --help が示すオプションのうち、判断に効くのは次のあたりです。

オプション 既定 効果
--spawn <mode> same-dir same-dir / worktree / session の3種。worktree はオンデマンドのセッションごとにgit worktreeを切る
--capacity <N> 32 同時セッション数の上限
--permission-mode <mode> — 生成されるセッションの権限モード（acceptEdits / auto / bypassPermissions / default / dontAsk / plan）
--name <name> ホスト名から自動生成 claude.ai/code 上での表示名
-c, --continue — このディレクトリで直近およそ4時間以内に記録されたセッションへ再接続

--permission-mode bypassPermissions は、リモートから繋ぐ用途では意味が変わります。

手元の端末で明示的に承認しながら使うのと違い、Remote Control ではスマホから投げた指示がこのマシンで実行されます。権限モードを緩めるとその承認ステップごと消えるため、外出先での便利さと引き換えに、承認なしでファイル編集やコマンド実行が走る状態になります。既定のままで使うのが無難です。

公式ヘルプが挙げている前提条件も3つあります。サブスクリプションのあるアカウントでログイン済みであること、先に claude を一度実行してワークスペースの信頼ダイアログを通しておくこと、worktreeモードはgitリポジトリ（またはWorktree系フック）を要することです。

Claude Code Remote Control は待受ポートを開くのか——lsofで数えた

ここが本記事の主題です。「スマホからローカルマシンを操作する」と聞くと、ポート開放・DDNS・トンネリングのような準備を連想します。実際どうなのかを測りました。

サーバーを起動した状態で、次の2つを実行します。読者の環境でもそのまま実行できます。

# 1) Remote Control のプロセスIDを確認する
pgrep -fl "claude remote-control"

# 2) そのプロセスが待受（LISTEN）しているTCPソケットを数える
lsof -nP -a -p "$(pgrep -f 'claude remote-control' | head -1)" -i TCP -sTCP:LISTEN

結果は「出力なし」でした。 起動を2回試し、いずれも LISTEN ソケットは0本です。ローカルにサービスが立ち上がるわけではありません。

続けて外向きの接続を見ます。

lsof -nP -a -p "$(pgrep -f 'claude remote-control' | head -1)" -i TCP -sTCP:ESTABLISHED

こちらは確立済みの接続が1〜2本返り、いずれも宛先ポートは 443 でした。宛先アドレスを whois で引くと次のようになります。

宛先の帯 whois の登録 意味
2607:6bc0::/32 ANTHROPIC-V6 / Anthropic, PBC Remote Control の本体通信
2600:1901::/26 GOOGLE-CLOUD / Google LLC 2回目の起動でのみ観測。Claude Code が通常使うテレメトリ等と同帯

2607:6bc0::10 は api.anthropic.com と claude.ai の AAAA レコードと一致します。

したがって、ネットワーク側の準備は不要です。

必要なのは「443番への外向きHTTPSが通ること」だけで、ルーターの設定変更もトンネルも要りません。逆に言えば、社内ネットワークでこの通信を止めたいなら、宛先の443を塞ぐのではなく後述の管理設定で止めるのが正攻法です。宛先は Claude Code が通常の会話でも使うホストと同じなので、ネットワーク層では Remote Control だけを選択的に遮断できません。

Claude Code Remote Controlの通信経路図。ローカルのCLIが待受ポートを開かず、api.anthropic.comへの外向きHTTPS接続を張り、SSEで受信・POSTで送信する。スマホやブラウザはclaude.ai側に接続する。
スマホは手元のマシンへ直接繋がない。双方がAnthropic側へ外向きに接続し、そこで中継される。

通信方式はWebSocketではなくSSEだった

-v（verbose）を付けて起動すると、セッションごとのデバッグログのパスが表示されます。その中に、通信のエンドポイントがそのまま記録されていました。

SSETransport: SSE URL  = https://api.anthropic.com/v1/code/sessions/<session-id>/worker/events/stream
SSETransport: POST URL = https://api.anthropic.com/v1/code/sessions/<session-id>/worker/events

受信は SSE（Server-Sent Events）のストリーム、送信は同じパスへの POST という組み合わせです。WebSocket ではありません。これは「外向きHTTPSしか使わない」という上の観測とも整合します。SSEはHTTPのレスポンスを閉じずに流し続ける方式なので、プロキシやファイアウォールから見れば長時間のHTTPSリクエストに見えます。

Claude Code Remote Control を組織で無効化する設定

企業導入で最初に聞かれるのがここです。実行バイナリには、無効化用の管理設定と、それが効いたときのメッセージが両方含まれています。

Remote Control is disabled by your organization’s policy (managed setting disableRemoteControl).

設定キーは disableRemoteControl、置き場所は managed settings（macOS なら /Library/Application Support/ClaudeCode/managed-settings.json）です。バイナリ内のオプション説明は、これが止める範囲を具体的に列挙しています。

Disable Remote Control (claude.ai/code, claude remote-control, --remote-control/--rc, auto-start, and the in-session toggle). Typically set in managed settings.

つまり claude.ai/code 経由・CLIサブコマンド・起動フラグ・自動起動・セッション内トグルの5経路すべてが1つのキーで閉じます。抜け道を個別に塞ぐ必要はありません。

関連する設定として remoteControlAtStartup（起動時に自動でRemote Controlを有効化するか）も存在します。組織で禁止するなら disableRemoteControl 側だけで足り、こちらは個人が利便性のために使う設定です。

エンタープライズのクラウドゲートウェイ経由では、そもそも使えません。

バイナリには「This session is connected through an enterprise cloud gateway (set up via /login), which does not support Remote Control.」という文字列があります。/login でエンタープライズのクラウドゲートウェイを設定している環境では、ポリシー以前に機能として非対応です。導入検討の前に、自社がどの認証経路を使っているかを先に確認してください。

スマホ／Webから見たときに欠けるもの

「手元と同じ体験が持ち歩ける」と考えると、いくつか齟齬があります。バイナリの文言から確定できる制約が3つあります。

制約 実際の文言（要旨）
添付ファイルが届かない 「N attachments NOT delivered to Remote Control (phone/web) viewers — only visible in the desktop app on this machine」
変更できる設定が限られる 「cannot be changed over Remote Control (only effortLevel and ultracode can)」
一部コマンドが使えない 「isn’t available over Remote Control.」という汎用の拒否メッセージを持つ

添付ファイルの制約は運用に効きます。 画像やスクリーンショットを含むやり取りは、リモートからは本文しか見えません。「外出先で結果を確認する」用途では、テキストで完結する作業に向いていて、視覚的な確認が要る作業は手元に戻ってからになります。

また --teleport で開始したセッションは Remote Control 無しで始まる仕様で、必要なら /remote-control を打って有効化します。--cloud / --teleport 側の挙動と制約はClaude Code Webとは｜–cloudと–teleportの使い方・制約をCLI実測で解説に整理してあるので、どちらを使うかで迷う場合はあわせて読んでください。Remote Control は「手元のマシンを遠隔操作する」もの、--cloud は「Anthropic側の環境で動かす」ものという切り分けになります。

flowchart TD A["外出先から作業したい"] --> B{"コードは
どこにあるか"} B -->|"手元のマシンにしかない
ローカル環境に依存"| C["Remote Control"] B -->|"リポジトリにあり
どこでも再現できる"| D["--cloud / Claude Code Web"] C --> E{"組織のポリシーは？"} E -->|"managed settings で
disableRemoteControl"| F["使えない
（5経路すべて閉じる）"] E -->|"エンタープライズ
クラウドゲートウェイ経由"| G["機能として非対応"] E -->|"制限なし"| H["claude remote-control
待受ポートは開かない"] H --> I["スマホ/Webでは
添付ファイルは見えない"]

リモートセッションでも、手元のMCPサーバーは起動する

見落とされやすい点があります。Remote Control 越しに作られたセッションでも、手元に設定してあるMCPサーバーはそのまま初期化されます。

-v を付けて起動すると出力されるデバッグログ（/tmp/claude-501/bridge-session-<セッションID>.log のようなパスに書かれます）を確認したところ、検証環境に設定してあった4つのMCPサーバーが起動時に初期化されていました。プラグイン経由のもの、HTTPトランスポートのもの、claude.ai のプロキシ経由のものが混在しています。

# Remote Control のデバッグログからMCPサーバーの初期化を確認する
grep -oE 'MCP server "[^"]+"' /tmp/claude-501/bridge-session-*.log | sort -u

つまり、スマホから投げた指示で、手元のマシンに設定したMCPサーバーのツールが動きます。 GitHubやチャットツールに書き込むMCPサーバーを常用しているなら、その権限がリモート経由でも同じように使えるということです。これは便利さそのものですが、権限モードを緩めた状態と組み合わせると影響範囲が一気に広がります。

ただし採用の範囲には制限があります。バイナリには次の文言があります。

server(s) not adopted: a Remote Control bridge only honors the injected Project servers

bridge が採用するのは注入された Project スコープのサーバーだけで、それ以外は「採用されなかった」として扱われます。手元のすべてのMCP設定が無条件に持ち込まれるわけではありません。

Remote Controlセッションで手元のMCPサーバーが初期化される様子の図。プラグイン経由・HTTPトランスポート・claude.aiプロキシ経由のサーバーが起動し、スマホからの指示でローカルのMCPツールが動作する一方、bridgeが採用するのはProjectスコープのサーバーに限られることを示す。
リモートから来た指示も、実行されるのは手元のマシン。MCPサーバーの権限もそのまま乗る。

ログ側の扱いは妥当でした。

同じデバッグログを Authorization で検索すると、値はすべて [REDACTED] に置き換えられていました（3箇所）。MCPサーバーへ渡すトークンが平文でログに残ることはありません。ログを共有してトラブルシュートを頼む場合でも、この点は心配しなくて済みます。

一方でログにはディレクトリの絶対パス・セッションID・設定ファイルの探索結果が残ります。第三者に渡すときは中身を確認してからにしてください。

セッションの隔離——same-dir と worktree の違い

--spawn の3モードは、複数人・複数タスクで使うときに効いてきます。

モード 挙動 向く場面
same-dir（既定） すべてのセッションが同じディレクトリで動く 1人で1つの作業を継続する
worktree オンデマンドのセッションごとにgit worktreeを切って隔離 並行して別の変更を試す
session 従来の単一セッション。そのセッションが終わるとサーバーも終了 使い切りで起動したい
Claude Code Remote Controlのspawnモード3種の比較図。same-dirは全セッションが同じディレクトリ、worktreeはセッションごとにgit worktreeで隔離、sessionは単一セッションでサーバーも終了することを示す。
既定は same-dir。並行して別の変更を試すなら worktree、使い切りなら session。

worktree モードは実行中に w キーで same-dir と切り替えられます（ヘルプに明記）。また --[no-]create-session-in-dir で、起動時に現在のディレクトリへセッションを1つ先に作るかどうかを制御できます。既定はオンで、これがあるおかげで接続直後にすぐ入力できます。

同時実行の上限が既定32というのは、個人利用では触ることのない値です。逆に言えば、このコマンドは「1セッションを飛ばす」ものではなく「セッションを供給する常駐サーバー」という設計思想で、そこが --teleport との性格の違いになっています。

Claude Code がそもそも何をするツールで、どの環境で動くのかを先に押さえたい場合はClaude Codeとは？できること・動く4環境・料金とライセンスを公式情報で整理を参照してください。

まとめ

・Claude Code Remote Control は待受ポートを1本も開かない。 lsof でLISTENを数えて2回とも0本
・外向きの443だけで成立する。 宛先はwhoisで ANTHROPIC-V6（Anthropic, PBC） 帯と確認
・通信はSSE。受信 …/worker/events/stream、送信は同パスへのPOST。WebSocketではない
・組織で止めるなら managed settings の disableRemoteControl 1本。コマンド・フラグ・自動起動・トグル・claude.ai/code の5経路が閉じる
・エンタープライズのクラウドゲートウェイ経由は機能として非対応
・スマホ/Webでは添付ファイルが見えない。 設定変更も effortLevel と ultracode に限られる
・常駐サーバー型で既定32セッション。--spawn=worktree でセッションごとに隔離できる

ネットワークの準備が要らないぶん、判断の軸は「通信が通るか」ではなく「この経路を組織として許すか」になります。そこを決める材料として、待受ポートが開かないこと、宛先が通常のClaude通信と同じであること、そして1つの管理設定で全経路が閉じることの3点を押さえておけば十分です。

参照ソース