Claude Code に仕事を頼んでも、進むのは私が机の前にいる間だけだった。席を立てば止まり、帰ってきて画面を見ると、朝と同じところで止まっている。この記事では、それをスマホから動かせるようにするまでに、何を試して何を外し、どこで予想が外れ、最後に何を自作したかを、順に書く。
書いている内容はすべて、その時点の私の環境でそうだったことである。Claude まわりは仕様が動くので、いまも同じとは限らない。
机に向かう習慣がなかった
私はもともと、本業のほかに自宅でずっとパソコンに向かう習慣がなかった。AI に任せられる仕事が増えるほど、任せたあとの待ち時間が増える。その待ち時間は、パソコンの前にいないと回収できない。
最初に考えたのは、指示をうまく書くことではなく、どこからでも触れる場所に Claude を置けないかということだった。
外した方法が 2 つある
1 つ目は、作業フォルダごとクラウドのドライブに置いて、どこからでも開く方法である。ファイルはどこからでも開けたが、Claude を動かすのに必要なものはファイルだけではなかった。セッションの履歴は動かしているパソコンの中に残り、プラグインも、そのパソコンを使う人ごとに入れる置き方にしていたので外へは出ていかない。同じファイルは開けても、同じ環境は再現できなかった。作業フォルダをドライブに置くこと自体は、バックアップとして今も続けている。外したのは「これで外から動かせるはずだ」という見込みのほうである。
2 つ目は、Telegram や Discord のようなチャットから、動いている Claude Code にメッセージを流し込む公式の仕組み（Channels）である。Discord でつないでみた。公式の説明は、動作中のセッションにイベントを送り込む MCP サーバだというもので、届け先は起動時にオプションを付けたその 1 本になる。私は話の内容ごとにセッションを分けて立てておくほうが好きなので、1 本を延々と使う形とは噛み合わなかった。機能の出来の問題ではなく、使い方の相性である。当時は研究プレビューの段階でもあった。
公式のリモートコントロールを常用にした
そのあとに落ち着いたのが、公式の Remote Control だった。手元の Mac で動いているセッションに、スマホの Claude アプリやブラウザからつなぐ機能である。私は最初、ブラウザ専用だと思い込んでいたが、ドキュメントには最初から両方が書かれていた。スマホ側ではアプリの Code から、セッションの一覧に入れる。
良かったのは、スマホから打った指示が、ターミナルで打ったものと同じように実行されたことである。簡易版を触っている感じがせず、待ち時間を外で回収できるようになった。設定は /config で全セッションに対して有効にしておけば、あとは claude と打つだけでつながる。
置き方は単純で、MacBook Air を自宅に据え置き、充電しながら蓋を少しだけ開け、輝度を 0 にしてスリープさせない。出かける前にセッションを立てて最初の指示を出し、通勤中と休憩中に結果を見て次を頼み、寝る前に翌日の分を投げておく。変わったのは、指示を出すときにそれがどのくらい長く走るかを考えるようになったことだった。すぐ終わって私の返事待ちになる頼み方をすると、次に画面を開くまでの数時間が空いてしまう。
外から画面が見えない問題は、ブラウザを自分で開いて確認する役を Claude 側に持たせることで減らした。Chrome の拡張を入れておくと、Claude が画面を撮って見せてくれるので、スマホでも確認できる。
ただし、この形には当時から不便が残っていた。作られたファイルは Mac の中にあり、ドライブアプリで場所までは分かっても、スマホからは中身を開けないことがある。読むだけのために全文をチャットに出させると、コンテキストを余計に使う。
サーバーモードを実機で検証した
公式ドキュメントを読み直していて、起動のしかたが 2 通りあることに気づいた。claude --remote-control は、いつもの対話画面を外からも操作できるようにするもので、私が使ってきたのはこちらである。もう一つの claude remote-control は、ハイフンの有無が違うだけの別のコマンドで、ドキュメントは「サーバーモード」と呼んでいる。手元に対話セッションを持たず、ターミナルは接続待ちの受付になる代わりに、手元の端末からセッションを新しく作れる。常用で残っていた「新しい話を始めたいときだけ Mac の前に戻る」が消えるなら、移す価値があると考えて、Claude Code v2.1.228 で 2 日かけて確かめた。
私の予想は、サーバーモードで立てたセッションを、あとからターミナルの claude --resume で開けるというものだった。外で走らせた話の続きを机で詰めたい場面が多いからである。結果は次のとおりで、予想はほとんど外れた。
/resumeの一覧に、さっきまで話していたセッションが出てこなかった。ログのファイルは確かに残っていた。同じ現象は GitHub の Issue にすでに報告されており、対応予定なしで閉じられていた/teleportで開くと通ったが、移動ではなく複製だった。新しいセッションの中に元の履歴が丸ごと写され、持ち主のセッション ID だけが書き換わり、両方が生きたまま並んで動いた。どちらの画面にも、そのことを知らせる表示は出なかった。気づけたのは、ログのファイルを開いて中を数えたからである- 使える MCP サーバが、スマホ側 8 個、ターミナル側 10 個だった。ターミナル側にしかなかったのは、Mac の画面を操作する computer-use と、ブラウザを操作する claude-in-chrome の 2 つで、逆はなかった。接続待ちの欄は空のままで、設定で切っていたわけでもなかった
- セッション ID を直接指定した
claude --resume <ID>は通り、複製もされなかった。ただ、開いた直後に追加されていたのは、やはりその 2 つだけだった
3 つ目の欠け方については、ドキュメントの 3 か所を並べると説明がつく。リモートコントロールのページは、リモートセッションでもツールや MCP サーバは使えると書いている。computer-use のページは、対話セッションが必要だと書いている。そしてサーバーモードは、対話セッションを持たない。3 つは別のページにあり、互いを参照していない。これは私の推測であり、公式がそう明言しているわけではない。
いちばん厄介だったのは、ターミナルで開いたあとにスマホからも打てたことだった。ログは 1 本のファイルに追記されるが、各行は直前の行を親として指しているので、実体は木になっている。ターミナルが開いた時点から、会話は 2 本の枝に分かれていた。両方に「直前に何の話をしていたか」を聞くと、返ってくる答えがまったく別だった。いったん閉じて同じ ID で開き直すと、戻ってきたのは片方の枝だけで、もう片方のやりとりは会話としては無かったことになる。ファイルの中には両方残っているので、読めば取り出せる。同じセッションを開くことはできても、2 つの画面から同時に使うことはできなかった。
結論として、日々の使い方は従来の対話モードのままにした。理由は、外から頼める仕事が減ることと、気づかないうちに会話が 2 本になって片方が見えなくなることの 2 つである。いちばん効いたのは、うまくいかないときに自分の操作を疑うのをやめて、ログを開いて数えたことだった。複製も、道具の欠けも、会話の分岐も、画面を見ているだけでは分からなかった。
ここに書いた手順や仕様は、いずれ古くなる。それでも、なぜその手順を選んだのかは古くならない。ドライブに置いても環境は再現できないこと、1 つのセッションを 2 つの画面から同時に使うと枝が分かれること、ログを開いて数えれば分かることは、更新で機能が増えても、考え方としては使い続けられる。
問いに答える中継を作った
常用を続けるうちに、公式の機能だけでは足りないと感じる場面がはっきりしてきた。Claude Code は作業の途中で、「A 案と B 案のどちらで進めるか」「このコマンドを実行してよいか」と訊いてくる。訊かれた瞬間に私がターミナルの前にいなければ、そこで止まる。しかも判断の材料が HTML や Markdown の下書きのとき、スマホの小さな画面では描画された状態で確かめにくく、読む場所と答える場所も離れていた。
そこで、同じセッションを外から見るもう 1 つの窓を、Mac の側に置くことにした。最初に作った別の形の中継は、いまは常駐を止めてある。作り直したこの中継は session-gateway と呼んでいて、Mac で常駐し、スマホのブラウザから開く。Tailscale の中だけで開けるようにして、インターネット全体には出していない。1 つのセッションに、スマホ、デスクトップアプリ、tmux attach のターミナルという 3 つの窓から入れる。
仕事は 4 つに分けた。
| 仕事 | 手段 |
|---|---|
| 打つ | tmux の中で claude --remote-control を起こし、そこへキーを送る |
| 読む | Claude Code が残す会話記録（jsonl）を追う |
| 知らせる | hook |
| 聞く | 自作のツールで、スマホにカードを 1 枚出す |
打つ口をフラグ形式の claude --remote-control にしたのは、検証で見たとおり、あとで再開できる普通の対話セッションになるからである。サブコマンド形式で起こすと再開できない。コマンドの見た目はほとんど同じなので、検証をしていなければ選び分けられなかったと思う。
研究プレビューの機能は土台にしないとも決めた。中継は上流の仕様が変わると一緒に壊れる道具で、以前に作った別の道具では、自動更新で中身の仕様が変わり、4 時間止まっても誰も気づかなかったことがある。ただ、これは当時の私の判断であり、いまの扱いは確かめていない。背景セッションの機能は、--help に載っていたので公式ページを確かめる前に一度採用し、あとでプレビューだと気づいて外した。そのせいで、同じ日に「打つ」経路を 3 回変えている。
聞く口の設計では、答えは後から届くものとして作った。ツール呼び出しには多くの環境で 60 秒ほどの上限があり、外出先で判断を求められて 60 秒以内に答えるのはほぼ無理だからである。ツールは「表示した」とだけ返し、Claude はそこでターンを終える。私がスマホで答えると、中継が答えを ［回答 <ID>］ で始まる普通の発言として tmux 経由で打ち込む。Claude から見れば、私がターミナルで答えを打ったのと同じである。組み込みの質問ツールは使わせず、自作のカードでしか訊けないようにしてあり、カードの型は選ぶ、確認する、入力する、項目ごとに判定する、現場で確かめてくる、の 5 つにした。
許可の確認には、スマホで私が押した答えを届けることはするが、中継が自分で押すことはしない。時間切れでも押さない。ただ、コードを点検すると、この取り決めの周りに同じ型の穴が見つかった。フォルダの信頼を訊く画面で 600 秒答えがないと、中継が「断る」を選んで Enter を送っていた。/clear を送るときに画面を見ずに Enter を押していたので、許可の確認が開いていれば既定の選択肢を確定してしまう筋もあった。原因は 1 つで、キーを送る前に画面の種類を見ていなかったことだった。いまは送る前に必ず画面を読み、許可や信頼の確認が出ているときは送らず、スマホにはターミナルで答える番だという表示を出している。
使い始めた初日に壊れた
作ったあと、AI に人物像を演じさせたレビューを 3 周回して 13 項目の改善点を得たが、実運用の初日に手が止まる不具合が 3 件同時に出た。
1 つ目は、iPhone で「どれも違う」を押したカードが 4 時間届かなかったことである。送り先のセッション情報の status が、Claude Code がバックグラウンドのシェルを抱えている状態を表す shell になっていた。送信側は idle 以外なら全部待つ作りだったので、知らない値のまま無期限に待っていた。待つのは busy のときだけにし、30 分の上限も付けた。
2 つ目は、止まった送信が「送信中」のまま残り、回答待ちにも回答済みにも出ないカードになったことである。起動時に「送信中」が残っていれば失敗として閉じ、回答待ちに戻すようにした。
3 つ目は、報告が出ていたのにセッションを見に行くまで気づけなかったことで、報告を回答待ちのすぐ下に出すようにした。
1 件目を直したことで、さらに別の穴が開いた。答えが 6 分半待たされている間に Claude が新しいカードを出していて、遅れて届いた古い答えが新しいカードを「返事済み」と判定させ、画面から消していた。待てるようになったせいで、待っている間に新しいカードが出る確率が上がっていた。答えの頭に付けた ID を読み、別のカード宛の答えは判定に使わないように直した。
レビューが挙げた 13 項目のうち、実運用で私の手を止めたものは、その時点で 0 件だった。実際に止めた 5 件は、どのレビューも挙げていなかった。レビューの材料に自分で書いた設計書を渡していたので、設計書に書いてあることだけが議題になった、というのが私の見立てである。
残っている不便
通知はしないので、開いたときにしか分からない。公式のプッシュ通知を有効にしてみたが、中継から起こしたセッションでは届かず、原因はまだ調べていない。答えのときに材料が Claude に戻らず、選んだ札だけが届く。画面のテキストの形、会話記録の jsonl の形式、セッションごとの状態ファイルは、どれも公式の約束ではないので、Claude Code の更新で壊れる前提で使っている。確かめているのは macOS だけである。
振り返って
流れを並べると、机の前でしか進まない状態から、常用、検証、前提の変化、問いに答える中継という順で、毎回 1 つ前の不便を次が直していた。効いた判断は、どれも作らないものを決めたことだった。セッションの管理は tmux に、デスクトップへの経路は Remote Control に、ホスティングと認証は Tailscale に任せ、中継が持つのは、材料を読める形で出して、答えを持ち主の発言として届けるところだけにした。
この記事は、note に書いた 2 本と Zenn に書いた 1 本を、一本の経緯として書き直したものである。検証の手順を細かく追う場合や、中継の設計を詳しく見る場合は、元の記事のほうが細かい。