Claude Code をスマホから使う。自作クライアントアプリと公式 Remote Control を比べてみた。
この記事は誰向けか
- Claude Code を日常的に使っていて、席を離れても作業を止めたくない人
- 公式の Remote Control(2026年2月リリース)を試した/気になっている人
- Claude Code を「たまに使うツール」ではなく、常駐するエージェント基盤として運用している(したい)人
外出先からちょっと触りたいだけなら、公式の Remote Control で足ります。この記事はその先の話 ── エージェントを常駐させて一緒に暮らす使い方をすると何が足りなくなるのか、そこで必要になった道具について、両方使っている立場から書きます。
Claude Code をスマホから操作する PWA クライアントを自作して、数ヶ月毎日運用しています。
ある日のシーン
電車の中でロック画面に通知が来ます。
この設計、A 案と B 案どちらにしますか?
自宅のマシンで走っているエージェントからの質問です。通知を開いて「A で。ただし移行スクリプトは残して」とだけ返します。数駅先でまた通知 ──「PR を作りました」。家に着く頃には、diff を眺めて merge するかどうか決めるだけの状態になっています。
エージェントが常駐する開発では、**人間の仕事は「操作」ではなく「判断」**になります。判断は数十文字で済むので、届きさえすれば場所を選びません。スマホは端末というより操縦席で、この記事で扱うのはその操縦席をどう用意するかという話です。
スクショ: チャット画面(markdown テーブル・コードブロックのインライン描画)
公式 Remote Control という正解
2026年2月、Anthropic が Remote Control をリリースしました。claude remote-control を一発叩くと、claude.ai/code や Claude モバイルアプリからローカルで動いているセッションをそのまま操作できます。
正直、よくできています。実行はローカルのまま(クラウドに移らない)、MCP サーバーやプロジェクト設定もそのまま、プッシュ通知もあり、サーバーモードなら複数セッションも扱えます。セットアップは実質ゼロ。
「外出先から Claude Code を触りたい」だけなら、これで完結します。問題は、その先に行った時です。
それでも残る領分 ── 比較表
「その先」で何が足りなくなるのか。公式ドキュメントに明記されている制限と、実運用で効いている差分を並べます(2026年7月時点・Claude Code v2.1.x / Remote Control は research preview のため今後変わる可能性があります)。
| Remote Control(公式) | claude-pwa-client(自作) | |
|---|---|---|
| セットアップ | ◎ claude remote-control 一発 |
△ backend + Tailscale の構築が必要 |
| セッションの永続性 | △ ローカルプロセス終了で死ぬ・ネットワーク不達 約10分でプロセスごと終了(docs 明記) | ◎ tmux + 実 PTY 常駐。ターミナルを閉じても・ネットが何時間切れても生存 |
| 経路 | Anthropic API 経由でルーティング | Tailscale の私設網で完結 |
| 認証の自由 | claude.ai OAuth 限定(API key・Bedrock/Vertex・LLM gateway 不可) | 制限なし(公式 CLI をそのまま起動するだけ) |
| 遠隔で使えるコマンド | 対話型ピッカー系(/resume /plugin 等)はローカル限定
|
PTY なので制限なし。picker や y/n 確認はバナーに抜粋表示・ボタンでワンタップ応答 |
| 通知 | プッシュあり(オン/オフ 2 トグル・「イベントごとの設定はありません」) | セッションごとに通知モード切替 |
| ファイル閲覧 |
@ のパス補完 |
ファイルツリー + お気に入り + markdown レンダー / 50+ 言語ハイライトのプレビュー |
| 使用量の可視化 |
/usage をテキストで実行 |
ステータスバーに 5h/7d レート制限・context 使用率を常時表示 |
| 会話フォーク | ─(筆者確認時点でなし) | 任意メッセージから分岐・親子ツリー表示 |
| マルチアカウント | claude.ai ログイン単位 | 設定で個人 / 仕事アカウントを切替 |
| sub-agent / Workflow の中身 | ─ | transcript 専用ビューアで外から監査可能 |
| メッセージ履歴 | サーバー側 | ローカルに圧縮保存 ── 電波のない場所でも過去ログを読み返せる |
| 提供形態 | research preview(仕様変更・組織ポリシーで無効化がありうる) | 自分のコード(明日欲しい機能を明日足せる) |
この中で、自分にとっての決定打は 2 つでした。
決定打①: セッションが死なない
公式 docs の制限事項にこうあります。
ローカルプロセスは実行し続ける必要があります。(中略)マシンが起動しているがおよそ 10 分以上ネットワークに到達できない場合、セッションはタイムアウトしてプロセスは終了します。
普通の使い方なら気にならない制約だと思います。ただ、うちのマシンでは日を跨いで生き続けるエージェントのセッションが常に数本走っていて、回線が 10 分落ちただけでプロセスごと死ぬ設計は、この運用だと受け入れられませんでした。tmux + 実 PTY で起動する自作 backend では、ネットワークもクライアントも「あとから繋ぎ直すもの」であって、セッションの生死に関与しません。
決定打②: エージェント側から話しかけてくる
自作クライアントでは、ファイル監視(Monitor)や時限起床(ScheduleWakeup)によってエージェントが自発的に起こしたターンも、即時にスマホへ届きます。「人がタスクを投げて結果を待つ」だけでなく、「エージェントが見つけた問題を向こうから報告してくる」方向の通知が、セッションごとの粒度で制御できます。ロック画面に「この設計、A と B どっちにする?」が届いて一言返す、みたいなやり取りが日常になります。エージェントと暮らすには、この双方向性が要ります。
仕組み(と、規約の話)
構成は素直です。
iPhone/Android(PWA)
⇅ Tailscale(私設網・外部公開なし)
ホストマシン(backend: FastAPI)
⇅ 実 PTY + tmux
claude CLI(公式バイナリがそのまま動く)
- backend は公式
claudeCLI を実 PTY + tmux のサブプロセスとして起動するだけです。認証も推論も公式バイナリ自身が行います - OAuth トークンの抽出や別クライアントからの API 呼び出しは一切しません。2026年1月に一部のサードパーティツールが規約違反でブロックされたのは「トークンを抽出して自前クライアントで API を叩く」パターンで、本ツールはこれに該当しない設計です(legal-and-compliance 参照)
- self-hosted・シングルユーザー前提です。自分のマシンで自分のサブスクリプションを自分が使う構成であり、backend を第三者に公開して複数人にサービス提供する使い方は Anthropic の規約(consumer 認証を "on behalf of their users" でルーティングする行為の禁止)に抵触するのでやってはいけません
スマホとの接続は Tailscale で閉じているため、会話もファイルプレビューも第三者のサーバーを経由しません(推論のための通常の Anthropic API 通信を除く)。
スクショ: AskUserQuestion がロック画面に届く
セットアップ
リポジトリの docs に一式あります。要件はホストマシン(macOS / Linux / Windows は WSL2)+ Tailscale + Node/Python。正直、Remote Control の「一発」と比べるとセットアップは面倒です(だからこそ、上の条件に当てはまらない人には勧めません)。
まとめ ── Remote Control で足りなくなった人へ
次のどれかに心当たりがあるなら、このクライアントはそのために作られています。
- セッションを何日も生かし続ける運用をしている(long-lived agents)── ネットワーク断でプロセスが死ぬ設計は受け入れられない
- エージェント側からの自発的な通知を受けたい
- API key / LLM gateway 構成で使っている
- 操縦席そのものを自分の手で拡張したい
「長く生きるエージェントの基盤を作る」ことをテーマに開発をしていて、このクライアントはその一部です。次回は、エージェントに commit や push まで任せるための安全装置の話を書く予定です。
質問・指摘は X (@synforger) の DM へどうぞ。
Discussion