claude --remote-control を最低限だけ#

claude --remote-control は Claude Code v2.1.51 で追加された機能で、要するに 自分のマシン上の Claude Code をスマホ／ブラウザから操舵できるようにする モード¹。 似た名前で Dispatch という機能もあるが、こちらは Claude Desktop 側でタスクを投げて結果を受け取る “投げ放し” の仕組みで、用途が違う²。

起動の選択肢は 3 つあって、いずれも最終的な挙動はほぼ同じ：

• claude --remote-control（--rc でも可）— ローカルにインタラクティブセッションを立てつつ、リモート接続も受け付ける
• claude remote-control — ローカルセッションを作らず、リモート接続だけ待ち受ける
• 既に Claude Code セッション内にいるなら /remote-control でその場で有効化

要件は v2.1.51 以降、かつ Pro / Max / Team / Enterprise プラン。API キー利用は非対応¹。 特に効いている性質はこの 3 つ：

• ローカルで動く — セッションは自分のマシン上で実行され、クラウドに移動しない。ローカルのファイル、MCP、設定がそのまま使える
• アウトバウンド HTTPS のみ — インバウンドポートを開けないので、ファイアウォール越しでも素直に通る
• マシンがスリープしても自動再接続 — ネットが切れても、スリープから復帰しても、戻ったら勝手につなぎ直す

特に最後のひとつが、tobari と組み合わせるときに効いてくる。

仮説 — tobari の画面 wake って、ロックしてないロック画面みたいに扱えるのでは？#

claude --remote-control を試しながら、ふと思った。

tobari の画面 wake って、ロックしてないロック画面みたいに扱えるのかな。

tobari は学習中や深夜作業中に PC をスリープさせずに画面だけ消す ための Web アプリで、Screen Wake Lock API を使って「タブがアクティブな間、画面のスリープを抑止する」設計になっている³。 で、claude --remote-control を有効にしておけば、自分のマシン上のセッションはスマホからでも操舵できる。

つまり：

• PC 本体は生きている（tobari がそうしている）
• 画面は真っ暗（tobari がそうしている）
• でもロックはしていない（パスワード入力なしで戻れる）
• セッションはスマホから操舵できる（--remote-control がそうしている）

これは、状態としてほぼ「ロックしてないロック画面」だな、と思った。

Wake / Sleep を 3 軸で整理する#

ここがこの記事で一番書きたかったところ。 “スリープ” や “wake” という言葉がカジュアルに使われすぎていて、tobari と Remote Control がどこで噛み合っているのかが直感ではわかりにくい。なので、軸を分けて整理しておく。

これを見ると、tobari と Remote Control は 担当している軸が違う ことがわかる。

• tobari は画面スリープ側を押さえる役。Wake Lock を握って、画面が勝手に消えないようにする。OS そのものを起こす機能は持たない
• Remote Control は逆で、OS が一時的にスリープしても、復帰時に自動でセッションを繋ぎ直す。マシンが「起きていること」自体は前提にしない

つまり、tobari は wake 側（画面を起こしておく）を、Remote Control は sleep からの復帰側（寝ても繋ぎ直す）を担当している。 軸がずれているので、ぶつからずに重ねられる。

注意点として、tobari の Wake Lock は 画面のスリープ抑止であって、OS 全体のシステムスリープとは別軸になる³。 Mac で「ディスプレイをオフにしてから 5 分でスリープ」みたいな設定になっていると、画面が起きていても本体は落ちうる。ただこのとき Remote Control は復帰時に自動再接続してくれるので、tobari × Remote Control の組み合わせはこの設定の細部にあまり依存しない。便利。

Remote Control だけで足りる人と、tobari も要る人#

ここで一度立ち止まる。 Remote Control の自動再接続は強力で、これ単体でかなり外出運用が回ってしまう。実際、こう思った人もいるはず。

--remote-control の自動再接続って、tobari いらなくない？

その通りで、ここははっきり分かれる。整理するとこう：

分岐の本質は 「自分が unavailable な時間に、Claude も unavailable でいいか」 の一点。

ここがミソで、Remote Control の自動再接続は 「セッションを失わない」 ための仕組みであって、「スリープ中も Claude を動かす」 ための仕組みではない。 スリープ中、当然ローカルプロセスは止まる。スマホからプロンプトを送っても、PC が起きるまで応答は返ってこない。

自分は完全に 後者 の側で、Claude にはいつでも言うことを聞いて働いていてほしい。 外出中もスマホからプロンプトを送ったら即応答してほしいし、コーヒーを取りに行っている間にテストを回しっぱなしにしておきたいし、カフェに着いた瞬間に「あの続き」を起動待ちゼロで再開させたい。 そういう 「離れているのに動いている」 状態を成立させるには、マシン本体は起きていないといけない。けれど画面は眩しいし、覗かれたくもない。ここで tobari が効いてくる。

自分にとって tobari は単なる視界の道具ではなく、「マシンを起こしておくための器」 として効いてくる、という位置づけになる。

実際にやってみた#

セットアップはこういう順で：

1. やりたい作業のディレクトリで claude --remote-control を起動するだけ。これでもう、スマホの Claude アプリのセッション一覧にこの PC のセッションが緑のランプ付きで並ぶ¹
2. PC 側でブラウザの別タブを開き、tobari の「永遠の帳」か「深海の帳」を起動
3. PC を机に置いたまま、tobari タブをアクティブにしておく

これで、PC の画面は真っ暗。けれどスマホから Claude Code にプロンプトを送ると、ちゃんと応答が返ってくる。 机を 5 分離れる、トイレに立つ、コーヒーを取りに行く、その間も画面は暗いままで、戻ってきて tobari タブをクリックすればすぐ作業に戻れる。普通のロック画面だとパスワードを打って、ターミナルにフォーカスを戻して、コンテキストを思い出して……となるところが、ほぼゼロ摩擦で続く。

公式仕様としては、マシンが一時的にスリープしてもネットが切れても、復帰時に Remote Control が自動で繋ぎ直してくれる¹。ここは tobari がカバーしていない領域なので、Remote Control 側の責任分担として効いてくる。

地味な注意点をいくつか。

• Screen Wake Lock は そのタブがアクティブな間 だけ効くので、別アプリにフォーカスを移すと OS 側で解放されることがある³。tobari は裏に行くと自動解放、戻ると再取得する作りになっている⁴ので、tobari のタブを最前面にしておくのがいちばん素直な運用
• 公式仕様には 「マシンが起きていてもネットに 10 分以上届かないとセッションがタイムアウトしてプロセスが終了する」 という上限がある¹。スリープからの復帰は無制限に拾ってくれるが、長時間のオフラインには弱い
• claude プロセス自体を kill するとセッションは終わる。ターミナルやエディタを閉じないこと¹

「ロックしてないロック画面」の正体#

仮説の答え合わせをすると、これは 厳密にはロック画面ではない。OS の認証レイヤーは挟まっていないし、誰でも触れる状態のまま画面だけが暗くなっている。 ただ体験としては結構ロック画面っぽい：

• 画面は暗い
• 触らなくていい
• 戻ったら即続き
• セッションは寝ていない
• スマホから手は届く

なので呼び方としては「ロックしてないロック画面」というより、「視界だけ落とした非ロック状態」 の方が正確かもしれない。が、語呂が悪いので普段は前者でいい気がしている。

ちなみに「ロックしつつ Claude も動かす」別解もある#

セキュリティ寄りに振りたい派には、tobari を使わない別解もある。フェアに書いておく。

仕様上、Screen Wake Lock は タブの visibility が hidden になると自動で解放される³。OS をロックするとブラウザタブは裏に回って hidden 扱いになるので、ロックした瞬間に tobari の Wake Lock は失効する。「tobari ＋ OS ロック」は重ねても tobari 側が意味をなさない、ということになる。

そこでロックしたうえで Claude を動かし続けたいなら、画面側は OS のロックに任せ、マシン本体のスリープだけ別の道具で抑止する 構成がきれいになる：

• macOS: 別ターミナルで caffeinate -i などを走らせる。アイドルスリープを抑止しつつ、画面の暗転は OS の設定に任せる
• Windows: 電源プランで「スリープしない」に設定し、ディスプレイのオフタイミングだけ別に指定する

この構成だと「画面は OS のロック越しに暗くなる／マシンは起きている／スマホからは即応答」が成立する。tobari ルートとの違いは 戻ったときに認証を挟むかどうか の一点。摩擦は増えるが、共有スペースや出先での安全度はこちらが上。

整理するとこう：

自分のように摩擦のなさを取るなら tobari、安全度を取るなら caffeinate + ロック。 物理的に他人が触れる環境では tobari ルートはセキュリティの層ではない ので、カフェの席を立つ、共有スペースを離れる、みたいな状況なら後者に倒すのが筋。tobari はあくまで自分の視界を落とす道具で、誰かが触る前提の場所ではガードにならない。

おわりに#

書きたかったことを一文にすると、こうなる：

Wake Lock とスリープは別軸なので、tobari と Remote Control はぶつからずに重ねられる。

tobari は画面を起きたままにする側、Remote Control は OS が寝ても復帰時に繋ぎ直す側。それぞれが別の軸を押さえているおかげで、机を離れている間も「画面は暗い／セッションは生きている／スマホから手が届く」という状態が成立する。

claude --remote-control 単体の網羅的な解説はこの記事ではやらなかった。Dispatch との違いや SDK 周りまで含めて整理したい人は、公式ドキュメント¹ を直接読むのが早い。

入り口は /tobari/ と claude --remote-control のどちらからでも。組み合わせは自由に試してみてほしい。

参考文献#

1. Remote Control — Claude Code 公式ドキュメント https://code.claude.com/docs/en/remote-control
2. Dispatch in Claude Cowork — Claude 公式チュートリアル https://claude.com/resources/tutorials/dispatch-in-claude-cowork
3. Screen Wake Lock API — MDN https://developer.mozilla.org/en-US/docs/Web/API/Screen_Wake_Lock_API
4. 学習中PCをスリープさせずに画面だけ消したい人向けに、視界遮断Webアプリ「tobari」を作って公開した — ゆるディープ /posts/web/2026/20260515/