Claude Codeのリモートコントロール、Desktopアプリでの実際の挙動を確認した話

以前書いた「リモートコントロール機能、試したらドキュメントが追いついてなかった話」の後日談です。

あの回はCLI(ターミナル)前提の話でした。
でも自分の普段の運用はDesktopアプリ前提なので、今回はDesktopアプリで実際にどう動くのかをあらためて確認してみました。

💡 Tips: リモートコントロール機能とは

Macで動かしているClaude Codeのセッションを、スマホやブラウザから続けて操作できる機能です。処理自体は元のMac上で実行され続けていて、スマホ側は会話の様子を見たり、追加の指示を送ったりする窓口になるイメージです。

「スリープ中もスマホから使える」は本当なのか

まず気になっていたのが、「Macがスリープしていてもスマホから操作できる」という噂でした。

外出先から作業を進められるなら便利だなと期待しつつ、公式ドキュメントを確認しにいきました。

書かれていたのは、laptopがスリープしたりネットワークが切れたりしても、Macが復帰すれば自動で再接続すること、その間に届いたメッセージや権限確認は一旦キューに溜められて、再接続後にまとめて届けられることでした。

つまり正確には、スリープ中もメッセージを送ること自体はできるけど、実際に処理されるのはMacが復帰してから、という仕様でした。
留守電に近い挙動です。

「外出先で指示だけ送っておいて、帰宅してMacを開いたら勝手に処理が終わっている」ような使い方を期待していたので、ここは少し肩透かしでした。

裏を返せば、Macが起きている間だけ本当の意味でリアルタイムに動く機能、と捉えておくのが実態に近そうです。

常につながっている状態を期待するなら、電源に挿しっぱなしにするか、スリープを防止するアプリを使う必要がある、という実務的な結論になりました。
以前書いた「クラムシェル運用なのにたまにスリープする謎」の記事とも、地味につながる話です。

ついでに、Macが起きている間の細かい挙動も1つ見つけました。
Claudeが1つの指示に答えている最中に、スマホから続けて次のメッセージを送ると、その場では処理されず、今の返答が終わったタイミングでまとめて処理される仕様でした。
割り込みで指示が混ざって会話が変な順番になる、みたいな事故は起きない作りになっているようです。

Desktopアプリの設定画面、文言がちょっと紛らわしかった

次に、Desktopアプリ側の設定を見に行きました。

設定の中に「新しいセッションをリモートコントロールに接続する」という項目があります。

この説明文に「ターミナルや」という言葉が入っていて、一瞬「これCLI前提の設定で、自分のDesktopアプリ運用には関係ないのでは」と身構えてしまいました。

でも実際に触ってみると、この設定はDesktopアプリ単体で完結していて、コマンド入力は一切不要でした。
トグルをオンにするだけで、Desktopアプリ上のセッションがそのままスマホから見えるようになります。

英語版ドキュメントとの突き合わせ

日本語UIの説明文だけだと判断がつかなかったので、公式ドキュメント(英語版)の該当ページも読み直しました。

Desktopアプリ側にも「Settings > Claude Code > Enable remote control by default」という、同じ機能を有効にするトグルがあることがちゃんと明記されていました。
CLIの設定コマンドから切り替える方法と、Desktopアプリの設定は、同じ機能への別の入り口という位置づけのようです。

日本語UIの文言だけを見て一瞬迷いましたが、英語版ドキュメントまで見に行くと、ちゃんと筋は通っていました。
翻訳の都合で一部の言葉(「ターミナルや」)が残っていただけで、機能自体はDesktopアプリでも問題なく完結する、というのが今回の答えでした。

ついでに、セッションを開始するたびに毎回オンにしなくていいのかも気になったので調べました。
「今後のセッションすべてで自動的にリモートコントロールを有効にする」というトグルが別途あり、オンにしておけばDesktopアプリで新しくセッションを始めるたびに、自動でスマホから見える状態になるようです。
毎回スイッチを入れ直す手間がなくなるので、これはオンにして運用することにしました。

まとめ

今回確認できたのは2点です。

スリープ中は留守電状態で、メッセージは受け取るけど処理は復帰後。
Desktopアプリの設定は単体で完結していて、コマンド入力は不要。

普段使っている環境(自分の場合はDesktopアプリ)と、ドキュメントが想定している環境(CLI)がズレていると、文言だけで勘違いしてしまうことがあるんだなと実感しました。
前回の記事の時点では「機能自体がまだドキュメントに追いついていない」という話でしたが、今回は「機能はちゃんとあるのに、自分が読み違えていた」という、また違う種類のすれ違いでした。

日本語UIの言い回しだけで判断せず、公式ドキュメントの原文まで見に行く。
地味ですが、そういう確認作業の大切さをあらためて感じた回でした。

この記事を書いた人

Web制作歴10年近く。WordPressのテーマカスタマイズやコーディングを中心に、副業・本業ともにweb制作に携わっています。このブログでは、実際に手を動かして分かったことを書いています。

Cat's Handをフォローする

この記事が参考になったら、応援クリックをお願いします

タイトルとURLをコピーしました