概要記事で「どれを使うべきか」を整理した。この記事では、最も開発者が触れるRemote Controlの具体的な使い方と、クロスマシン運用のワークアラウンドを手を動かせるレベルで解説する。

起動の3パターン

Remote Controlの起動方法は3つある。状況に応じて使い分けるのがコツだ。

パターン1: サーバーモード。claude remote-control を叩くと、専用のRemote Controlプロセスが立ち上がる。--name "My Project" でセッションに名前をつけられるし、--spawn worktree --capacity 32 でワークツリーの自動生成と並列処理数の指定もできる。長時間放置するならこれが最も安定する。

パターン2: セッション併用。claude --remote-control で通常のインタラクティブセッションにRemote Control機能を追加する。ターミナルで直接操作しながら、同時にスマホからも見られる状態になる。

パターン3: 既存セッション有効化。作業中のセッションで急にリモートアクセスしたくなったら、/remote-control または /rc My Project で即座に有効化できる。

接続する側の操作

起動するとQRコードが表示される。スマホのClaude アプリでスキャンすればすぐに接続できる。PCのブラウザからは、セッションURLを直接開くか、claude.ai/code のセッション一覧からPCアイコン＋緑のドット表示を選択する。

地味に便利なのが、複数マシンのセッションを1台から管理できる点だ。Windows、Mac、Linux、それぞれで claude remote-control を起動しておけば、claude.ai/code からチャットスレッドを切り替えるように行き来できる。リモート開発環境の集中管理に使える。

Windows固有の注意点

Windows対応はv2.1.51以降だが、初期は「not yet enabled for your account」エラーが頻発していた。v2.1.76（2026年3月14日）でRemote Control関連の複数バグが修正されており、アイドル環境でのセッション停止やJWT更新後の再配信問題が解消されている。

注意すべきは、CLAUDE_CODE_USE_BEDROCK 等のサードパーティプロバイダー設定があると動作しないこと。AWS Bedrock経由でClaude Codeを使っている環境ではRemote Controlは利用できない。

クロスマシン運用の実際

「WindowsからMacに作業を引き継ぎたい」——これは現時点で完全な解はない。ただし、擬似的に実現するワークフローは確立されつつある。

最も確実なのはWeb セッション経由のパターンだ。

[Windows] git push → claude --remote "タスク指示" → [Cloud]
                                                       ↓
[Mac]   claude --teleport <session-id> ← ← ← ← ←  [Cloud]

重要なのは /teleport の方向性を理解すること。クラウド→ローカルの一方通行 であり、ローカル→クラウドへのpushはできない。Windowsのローカルセッションを直接Macに送ることはできないが、クラウドを中継点にすることで会話コンテキストを維持した移行が可能になる。

ただしMCP設定やローカルツールの設定は引き継がれない。完璧を求めるなら、もうひとつの選択肢——WindowsでRemote Controlを起動し、Macのブラウザから接続する方式——も検討すべきだ。実行環境はWindowsのままだが、Macから操作できる。PCを閉じない限りセッションは維持される。

Teleportの前提条件

teleportは便利だが、前提条件が地味に厳しい。

  • クリーンなgit状態（未コミット変更なし）
  • 正しいリポジトリでの実行
  • リモートブランチがpush済み
  • 同一アカウントで認証済み

つまり「作業途中でteleportしたい」場合は、まずgit stashかcommitで状態をクリーンにしてからpushする必要がある。この手間を許容できるかどうかが、運用フローを選ぶ分岐点になる。

今後に期待するもの

個人的には、GitHub Issue #30447の headless remote-control が実現すれば運用が劇的に変わると思っている。TTY不要のデーモンモードで、Mac miniやクラウドサーバー上でClaude Codeを常時稼働させ、どこからでもRemote Controlで接続する。常時起動マシンさえあれば、クロスマシン問題はそもそも発生しなくなる。

マネージャーとしては、今はRemote Controlの「個人利用」を許可しつつ、headlessモードが来たらチーム共有のリモート開発サーバー構想を本格検討する——という段階的アプローチが現実的だろう。