スマホだけでどこまで開発できるか — 2026年の現実的な答え

PC を持たずに出た旅行先で、本番サイトの不具合報告が届く。手元にあるのはスマホだけ。数年前なら、できることは「帰ったら直します」と返信するところまででした。スマホ用のコードエディタを開いても、小さな画面と貧弱な入力環境でコードを打ち、ビルドのたびに端末が熱くなる。「スマホだけで開発できるか」という問いへの答えが「趣味の実験としては面白い」止まりだったのは、できなくはないが、わざわざやる理由がなかったからです。

CLI コーディングエージェントの登場で、この限界線は静かに動いています。何が変わって何が変わっていないのか、現実的な3つの構成、母艦に tmux と VPN を敷いてスマホからつなぐまでの手順と実際に打つコマンド、ありがちな失敗、そして2026年時点での正直な答えを順に見ていきます。結論を先に言えば、「スマホだけで全部」はいまも非現実的ですが、「開発時間のかなりの部分をスマホへ移す」は普通に成立するようになりました。

これまでの「スマホ開発」がうまくいかなかった理由

過去にも、スマホで開発する試みは繰り返されてきました。スマホ用のコードエディタアプリ、外付けキーボードとテキストエディタの組み合わせ、Termux でのローカル環境構築、ブラウザで動くクラウド IDE。どれも一定の支持は得ましたが、主流にはなりませんでした。

理由は共通しています。従来の開発では、人間の主な仕事が「コードを書く」ことだったからです。コーディングは、広い画面での参照の行き来、補完とショートカットの効くエディタ、腰を据えた集中を前提とする作業で、そのすべてがスマホの弱点と正面から衝突します。画面を工夫し、キーボードをつないでも、作業の性質そのものがスマホ向きではなかった。だから「できなくはないが、わざわざやらない」に落ち着き続けたわけです。

この構図を変えたのは、スマホ側の進歩ではありません。開発という作業の側が変わったのです。

何が変わったのか: 開発の主役が「文章」になった

Claude Code や Codex のようなエージェントに開発を任せるスタイルでは、人間の仕事の形が変わります。コードを1行ずつ書く代わりに、何を作るか・どう直すかを文章で指示し、エージェントが書いたコードの diff を読み、方針の判断を返す。このループでは、人間の主な出力はコードではなく指示とレビューの文章です。

ここにスマホとの相性が生まれます。第一に、文章を書くことはコードを書くことよりスマホに向いています。補完もインデントも参照の行き来も要らず、考えを言葉にする作業は小さな画面でも成立します。第二に、レビューと判断は「読む」作業が中心で、読むこともまたスマホの得意分野です。diff を眺めて、方針が合っているかを判断し、「その方向でいい」「テストを足して」と短く返す。この往復は、通勤電車の中でも回ります。

第三に、時間の構造が噛み合います。エージェントは指示を受けると数分から数十分は自走するので、開発が「濃い待ち時間の連続」になります。人間が張り付いている必要はなく、進捗を見て判断を返すタイミングだけ手が要る。この形は、まとまった時間は取れないが細切れの時間ならいくらでもある、というスマホ的な生活時間と好相性です。机の前の連続した数時間を確保できる日だけが開発日、という前提が崩れ始めているのはこのためです。

誤解のないように書いておくと、これは「エージェントがあればスキルは要らない」という話ではありません。むしろ逆で、diff を読んで筋の良し悪しを見抜く力、設計の判断力、テスト結果から原因を推測する力がないと、監督役は務まりません。変わったのは要求されるスキルの中身ではなく、そのスキルを発揮する場所が机に縛られなくなったことです。

変わっていないもの: スマホ単体の性能と画面

一方で、スマホというハードウェアの制約は変わっていません。開発環境そのものをスマホの中に置くのは、依然として苦しい選択です。ビルドの重い言語やコンテナを使う開発は Android の制約と性能の壁に当たりますし、長時間の処理は電池と発熱の問題になります。

だから現実的な答えは、「開発はスマホの外で動かし、スマホは操作端末に徹する」です。エージェントと開発環境は母艦(自宅の Mac / PC)やクラウドに置き、スマホからはそこへ接続する。この整理をすると、スマホに要求されるのは画面とキーボードと回線だけになり、性能の制約が問題から消えます。問いは「スマホで開発できるか」から「スマホは開発の操作端末になれるか」に変わり、こちらの答えははっきりイエスです。

「端末に徹する」構成には副次的な利点もあります。スマホの紛失や故障が、開発環境の喪失を意味しなくなることです。コードも環境も母艦側にあるので、スマホ自体にコードを保存しない構成にできます。ただし接続用の認証情報や、端末に残した下書きの扱いは別に考えます。逆に言えば、母艦側のバックアップと管理が資産のすべてを握る、という責任の集中も起きます。

1. スマホから作業内容や修正方針を伝えます。
2. 端末内、母艦、クラウドなど、実際の処理場所を把握します。
3. 差分や実行結果を確認し、必要なら大きい画面でも検証します。

現実的な3つの構成

1. 母艦 + SSH(本命): 開発環境は自宅の Mac / PC やクラウド上のサーバに置き、tmux の中でエージェントを動かし、スマホから SSH で接続する。tmux は画面から切り離してもバックグラウンドで動き続け、後から再接続できる、とマニュアルの冒頭に明記されています(tmux(1) マニュアル)。接続が切れてもセッションは生き続け、机とスマホのどちらからでも同じ画面に戻れます。構成の詳細は別記事にまとめました。エージェント時代の「スマホだけ」は、実質これを指します
2. クラウド開発環境: GitHub Codespaces などの開発環境サービスをスマホのブラウザや SSH で使う構成。Codespaces は GitHub CLI から gh codespace ssh で SSH 接続できると公式ドキュメントにあり(GitHub CLI での GitHub Codespaces の使用)、つないでしまえばスマホからの操作感は母艦 + SSH と同じになります。母艦の管理(電源、ネットワーク、環境維持)が不要になるのが利点で、家の停電や回線断で作業が止まる心配もありません。代わりに利用料と回線品質が制約になります。母艦を持たない人、環境構築を省きたい人の入口として有力です
3. 端末内完結(Termux): スマホの中に Linux 環境を作る構成。git 操作、スクリプト、静的サイトの修正程度なら端末内で完結します。ビルドの重い開発には向きませんが、オフラインでも動く手元の作業場と、SSH の踏み台として価値があります

クラウド開発環境を選ぶ場合、GitHub CLI(gh)が入った端末から打つのは次の2つです。一覧で codespace の名前を確かめ、その名前で SSH 接続します。

gh codespace list
gh codespace ssh -c CODESPACE-NAME

端末内完結の守備範囲をもう少し具体的に言うと、リポジトリを clone して小さな修正を commit・push する、テキスト処理のスクリプトを書いて回す、ブログ記事やドキュメントを書いて管理する、といった軽量級の作業です。これらは母艦なしでも完結するので、「母艦を立てるほどではないが、スマホをただの閲覧機で終わらせたくない」段階の入口としても機能します。逆に、依存関係の重いプロジェクトのビルドやコンテナが要る開発を Termux でやろうとすると、Android の制約に阻まれて時間を溶かすことになります。この制約は Termux の開発元自身が README の冒頭で注意していて、Android 12 以降では OS がアプリ全体で 32 を超えるプロセス(phantom process)や CPU を使いすぎるプロセスを kill するため Termux が不安定になりうる、シェルを抜けていないのに「Process completed (signal 9)」と表示されることがある、と書かれています(termux/termux-app README)。境界を知って使うのが肝心です。

3つは排他ではありません。母艦 + SSH を本線にしつつ、圏外や母艦障害のときの控えとして Termux を整えておく、という重ね方が実際には多くなります。

選ぶときの判断軸も挙げておきます。初期コストで見ると、Termux が最も軽く(アプリを入れるだけ)、母艦 + SSH は接続と認証の構築、クラウドはアカウント作成と料金体系の理解が要ります。運用では、母艦の電力と管理、クラウドの利用料、端末内環境の通信・保守なども考えます。必要な費用は利用方法で異なります。自由度は母艦が最も高く、自分の環境をそのまま外へ持ち出せます。障害点の観点では、母艦構成は「自宅の停電・回線断で全停止」という弱点を持ち、クラウドはサービス側の障害と料金改定がリスクです。すでに開発機を持っている人は母艦、持っていない人はクラウドから、というのが大まかな入口になります。

SSH を組まずに始める道: Claude Code の Remote Control

Claude Code なら、SSH も VPN も張らずに監督業だけ先に始める道があります。母艦で動くセッションに Claude アプリ(iOS / Android)や claude.ai/code から接続する Remote Control が公式にあるからです。母艦のプロジェクトディレクトリで次を実行すると、プロセスは接続を待つサーバーとして動き続け、接続用のセッション URL が表示されます。スペースキーでスマホ用の QR コードも出ます(Claude Code Docs: Remote Control)。

claude remote-control

通信は母艦からの外向き HTTPS だけで、母艦側で受け付けポートを開くことはない、と同じページにあります。VPN も SSH クライアントも要らないので、母艦 + SSH を組む前の最短の入口になります。制約は、ローカルの claude プロセスを動かし続ける必要があり(ターミナルを閉じればセッションは終わる)、通信障害やプロセス停止時の復帰は利用する版の仕様に従い、API キーでは使えず claude.ai アカウントでのサインインが要ります。tmux の操作やシェルでのログ確認といった「ターミナルそのもの」の操作もできません。監督業には十分、母艦の中を歩き回るには SSH が要る。そう整理して本線と併用します。

手順: 母艦 + SSH 構成を作る

構成の準備に必要な時間は、既存の環境とネットワークによって異なります。

1. 母艦に tmux を導入し、エージェント(Claude Code / Codex など)を tmux セッションの中で動かす習慣に変える。これは机で作業する日にも損のない変更です
2. 母艦とスマホの間に Tailscale などのプライベート VPN を張る。Tailscale は WireGuard プロトコルで端末同士を直接つなぐメッシュ型の VPN で、ファイアウォールや NAT の内側にある端末同士でもポート転送や複雑なファイアウォール設定なしにつながり、始め方はアカウントを作って各端末にクライアントを入れてログインするだけ、と開発元の解説にあります(What is Tailscale?)。母艦のポートをインターネットへ開放するより安全で、設定も軽く済みます
3. スマホに SSH クライアント(Termius / ConnectBot など)を入れ、母艦への接続プロファイルを作る。選び方の軸は別記事にまとめています
4. 接続直後に tmux attach する設定を仕込み、「アプリを開いてタップ1回で、家で開いていた画面に座っている」状態を作る
5. ターミナル向けのキーボード環境を整える。Ctrl や Esc、スラッシュコマンドが打てない標準キーボードのままでは、この構成は歩けても走れません
6. 最後に運用ルールをひとつ決める。「家を出る前に、エージェントへ大きめのタスクを渡しておく」。外出先での自分は、その進捗を確認して判断を返す監督役になります

手順1と4で実際に打つ tmux のコマンドは次の3つだけです。-s はセッション名、-A は「同名のセッションがあれば attach として振る舞う」、attach の -d は「同じセッションにつないでいる他のクライアントを切り離す」で、いずれもマニュアルにある通りの意味です(tmux(1) マニュアル)。

# 母艦: dev という名前のセッションを作り、この中でエージェントを起動する
tmux new -s dev

# スマホから接続したとき: dev があればそこに入り、なければ新しく作る
tmux new -A -s dev

# 家の端末がつないだままなら、それを外して自分がつなぐ
tmux attach -d -t dev

構築の順番にも意味があります。tmux と VPN が土台、SSH クライアントが通路、キーボードが仕上げです。よくあるのは、仕上げのキーボードだけ整えて土台を飛ばすパターンで、これだと接続が切れるたびに作業が失われて、構成そのものへの信頼を失います。土台から順に、それぞれ動作を確認しながら積んでください。全部そろって初めて、この構成は「使える」から「頼れる」に変わります。

まだ PC に残るもの

限界線が動いたとはいえ、机と PC にしか置けないものは残っています。

• 大きな diff を腰を据えて読む作業。数ファイルの変更ならスマホで読めますが、設計にまたがる大規模な変更のレビューは、広い画面で並べて読むほうが確実です。画面サイズは正義です
• GUI が必須の作業。デザインツール、実機シミュレータ、動画編集などは、リモートデスクトップ越しでは操作性が大きく落ちます
• 長時間の集中セッション。姿勢と目の負担は道具では解決しません。スマホでの開発参加は、1回数分から十数分の短い往復に向いています
• ゼロからの環境構築や込み入ったデバッグ。試行錯誤の密度が高い作業は、画面を何枚も並べて情報を突き合わせる場面が多く、スマホの1画面では思考の足場が足りなくなります

「スマホだけで全部」を目指すより、判断と小仕事はスマホ、腰を据える作業は机、と役割分担するのが2026年の現実解です。スマホへ移せる割合は、作業内容と確認のしやすさによって変わります。移動や待ち時間に進められる作業があるかを、自分のプロジェクトで確かめます。机の時間が減るのではなく、開発に使える総時間が増える方向に働きます。

なお、この線引きは固定ではありません。エージェントが自走できる範囲は広がり続けており、人間側に残る仕事が「読む・判断する」へ寄るほど、スマホで担える割合も上がっていきます。今年の限界線を来年もそのまま信じないほうがいい、というのがこの数年の教訓です。だからこそ、割合の数字を暗記するより、「自分の作業のどれが監督業で、どれが職人業か」を見分ける目を持つほうが長持ちします。監督業はスマホへ移せて、職人業は机に残る。この分類は道具が進化しても使えます。

1日の運用イメージ

仮定の運用例として、一日の流れを描いてみます。朝、家を出る前に5分。昨夜の続きのタスクをエージェントに渡し、自走を始めさせてから家を出ます。通勤電車で tmux attach。家で開いていたセッションがそのまま現れるので、状況の把握に時間はかかりません。進捗を確認し、エージェントからの質問に2つ答え、方針のずれをひとつ指摘して閉じます。ここまで親指だけです。

昼休み、テストが落ちたという報告を確認します。ログを読むと原因は明白だったので、修正の方針を短く指示してまた閉じる。夕方の移動中に diff を流し読みして、細部の気になる点をメモ。帰宅後、机に座って初めて PC を開き、スマホでは読みづらかった部分のレビューと、自分の手を動かす必要のある箇所だけを片付けます。

休日の使い方も変わります。買い物や家事の合間、以前なら「開発が中断される日」だった時間に、エージェントは自走を続けています。出先のベンチで5分だけ進捗を見て、次のタスクを渡す。夕方に机へ座る頃には、朝に仕込んだ数件が形になっていて、自分は仕上げから始められる。フルタイムで机に向かった休日と同じではありませんが、「開発ゼロの日」が「少し進んだ日」に変わる効果は、積み重なると無視できません。

机の前の時間は以前より短いのに、1日の終わりに進んでいる量は増えている。この構成が回り始めたときの感覚はそういうものです。ポイントは、スマホの出番を「監督と判断」に絞っていることです。スマホで全部やろうとした瞬間に、この滑らかさは崩れます。

スマホから監督するためのコツ

同じ構成でも、エージェントへの仕事の渡し方で、スマホ時間の使いやすさは大きく変わります。仕事の渡し方のコツを3つと、入力の工夫を1つ挙げます。

まず、外出前に渡すタスクは「自走できる大きさ」に切ることです。数分で終わる小タスクだと、移動中に何度も指示を出す羽目になり、細切れ時間が細切れのまま消えます。逆に方針の曖昧な大タスクは、外で長文の設計議論をする羽目になります。「方針は決まっていて、実装に時間がかかる」仕事が、外出前に渡すのに最適です。タスクの切り方そのものが、この構成の運転技術だと言えます。

次に、報告の形をあらかじめ指定しておくことです。「終わったら変更点の要約と、判断が必要な点を箇条書きで」と頼んでおくと、スマホで最初に読むものが要約になり、diff の全文を小さい画面で追う場面が減ります。読む量を減らす工夫は、画面を広げる工夫よりスマホでは効きます。

最後に、判断に迷ったら保留する勇気です。スマホで見て確信が持てないレビューは、無理にその場で承認せず「帰ってから見る」と返して構いません。エージェントには別のタスクを渡しておけば時間は無駄になりません。小さい画面での生煮えの承認は、後で机の前の時間を余計に食います。

指示の入力自体にも工夫の余地があります。エージェントへの指示は自然言語の文章なので、歩いているときや手がふさがっているときは音声入力で下書きし、送る前に目で整える、という使い方が成立します。コードは音声で書けませんが、指示は書けます。人間の出力が文章になったことの恩恵は、こんなところにも表れます。

よくある失敗と対処

• スマホで全部やろうとして挫折する: 最も多い失敗です。大きな diff のレビューや設計の書き物までスマホに載せると、画面と入力の限界に正面からぶつかり、構成ごと放棄することになりがちです。スマホの守備範囲は「読む・判断する・短く指示する」。それ以外は机に残すのが長続きの条件です
• tmux なしで運用して、接続が切れるたびに絶望する: モバイル回線の SSH は日常的に切れます。tmux がなければ切断のたびにセッションが失われますが、あれば tmux attach で何事もなかったように戻れます。tmux はこの構成の贅沢品ではなく土台です
• 入力環境を整えずに試して「使えない」と結論する: 標準キーボードには Ctrl も Esc もなく、tmux の操作すらままなりません。キーボードを整える前の体験でこの構成全体を評価しないでください。評価はボトルネックを外してからです
• セキュリティを後回しにする: SSH は公開鍵認証にし、VPN の外へポートを晒さない。ここを雑にした構成は、便利になった分だけ攻撃面も広がります。導入後も端末、鍵、アクセス範囲の変更に応じて見直します
• エージェントへの自動承認を広げたまま外出する: 出先では確認の目が届きにくくなります。危険な操作の承認ポリシーは、外出時はやや保守的に振るのが無難です
• 通知に反応しすぎて生活が侵食される: いつでも見られることと、いつも見るべきことは違います。進捗を見るタイミングを移動中などに決めておき、それ以外は放置する。エージェントは待たせても文句を言いません
• 母艦のスリープ設定を忘れて外から届かない: 外出先で接続できない原因の定番は、母艦が省電力でスリープしていることです。Mac なら、システム設定でノートブックは「バッテリー」の「オプション」にある「電源アダプタ使用時はディスプレイがオフのときに自動でスリープさせない」を、デスクトップは「エネルギー」にある「ディスプレイがオフのときに自動でスリープさせない」をオンにします。同じ設定画面の「ネットワークアクセスによるスリープ解除」も併せて確認しておきます(Macのスリープ/スリープ解除を設定する)。外から試す前に、まず家の中の別回線(モバイル回線)で接続確認しておくと、原因の切り分けが楽になります

最後のボトルネックは入力

この運用で最後まで残るボトルネックは、スマホの入力です。指示の文章そのものは普通のキーボードで打てますが、問題はその周辺の操作です。Ctrl+C での中断、Esc、矢印キー、tmux のプレフィックス。標準キーボードにはこれらを修飾キー付きのキーイベントとして送る手段がそもそもなく、/clear や /compact のようなスラッシュコマンドを予測変換と戦いながら打つのも地味に消耗します。

個々のつまずきを挙げると、エージェントの自走を止めたいのに中断のキーがない、履歴から前の指示を呼び出せない、tmux のウィンドウを切り替えられない、といった具合です。PC では無意識にやっている操作が、キーがないという理由だけで全部つっかえる。指示の文章は打てるのに操作ができない、というアンバランスが、この構成の初期に感じる違和感の正体です。

対策は2段階です。持ち歩きゼロで済ませるなら、修飾キーとスラッシュコマンド入力を備えたターミナル向けキーボードアプリ(The KeyBoard はまさにこの用途のために設計されています)。腰を据える日があるなら、物理キーボードの追加。どちらも、この構成全体の律速段階への投資であって、キーボードという部品の話ではありません。ボトルネックに投資するのが最も効率が良い、というのは開発でもこの構成でも同じです。

よくある質問

iPhone でもこの構成は組めますか

母艦 + SSH という構成自体は OS を選びません。iPhone にも SSH クライアントはあり、tmux のセッションに接続して同じ運用ができます。差が出るのは入力環境の自由度で、Android はキーボードアプリがキーイベントを送る仕組みを持つため、修飾キーやトラックパッドまで含めた入力の作り込みができます。このサイトのキーボード関連の記事が Android を前提にしているのはそのためです。構成の考え方は共通、入力の解決策は OS ごとに違う、と整理してください。

電池や通信量は問題になりませんか

SSH はテキストのやり取りなので通信そのものは軽く、必要な帯域も通信量も、画面転送型のリモートデスクトップよりはるかに小さく済みます。電池の消耗の主因は画面の点灯時間で、これは他のスマホ利用と変わりません。移動中に数分ずつ画面を見る使い方なら、体感が大きく変わるほどの消耗にはなりません。問題になるのは帯域より安定性で、トンネルや地下での切断は避けられません。だからこそ tmux でセッションを守る構成が前提になります。長時間の連続作業をするなら、それはそもそも机でやるべき作業だ、というこの記事の役割分担がそのまま答えになります。

PC を持っていない初心者でも、スマホだけで開発を学べますか

学習の入口としては成立します。Termux でシェルと git に触れる、クラウド開発環境でコードを書いてみる、という始め方は現実的です。ただし、学習が進むほど画面と入力の制約が学習効率を削り始めます。学習には「書いて、動かして、壊して、直す」の反復が必要で、この反復の回転速度が環境の質にそのまま比例するからです。続ける意思が固まった段階で、中古でも構わないので PC かクラウド環境を母艦として用意するほうが、結果的に早く進めます。スマホは学習の入口と、学んだ後の運用でこそ活きる道具です。

会社の仕事のコードもこの構成で触っていいですか

技術の問題ではなくルールの問題です。私物端末からのアクセスや社外からの接続は、組織のセキュリティポリシーに従ってください。会社が用意する正規のリモートアクセス手段があるならそれを使い、なければ勝手に経路を作らないこと。便利な構成ほど、無断で持ち込んだときの問題も大きくなります。この記事の構成は、自分の管理下にあるコードと環境、つまり個人のプロジェクトや自分に権限のある環境で使うのが前提です。

自分の作業をどれくらい移せるか、どう判断しますか

作業を入力・調査・差分確認・動作検証などに分け、スマホで最後まで確認できたものを記録します。移動中に編集できても PC で再確認が必要なら、その時間も含めます。一定の割合を目標にせず、確認の質を保って進められる作業を探します。

次の一歩

今日できる最小の一歩は、母艦で tmux new -s dev を打ち、いつも使っているエージェントをその中で起動することです。スマホがなくても意味のある変更で、この構成のすべてがその上に載ります。Claude Code を使っているなら、同じ日に claude remote-control を一度試して、スマホのアプリから自分のセッションが見える感覚を先に掴んでおくのも手です。次の週末に母艦とスマホへ Tailscale を入れてログインし、SSH クライアントから母艦につないで tmux new -A -s dev が家のソファで通ることを確かめます。家の中で確認した後、モバイル回線など実際の外部接続条件でも確かめます。最初の1週間は「移動中に進捗を1回見る」だけでも十分で、そこから自分に合う監督のリズムを探していけばいい。あとは入力環境(スマホでターミナルを使う3つの方法参照)を整えれば、机の前の時間だけが開発時間、という前提はあなたの中でも崩れ始めるはずです。

机が開発の中心であることは、当分変わりません。変わったのは、机を離れた時間が開発から切り離されなくなったことです。限界線はこれからも動きます。道具立てをその変化に合わせて更新するかどうかは、もう技術の問題ではなく、好みと決断の問題です。

小さな変更を、最後の確認まで一度通してみる

スマートフォンでできる作業を判断するには、編集の途中までではなく、結果を確認するところまで一つの変更を通してみます。最初は、自分の練習用プロジェクトの説明文を直すなど、影響が小さく、結果が見える題材を選びます。

流れは、対象を読む、変更を加える、差分を見る、必要な確認を行う、結果を記録する、です。文章の修正でも、違うファイルを変えていないか、表示で文字が欠けていないかを確認します。公開を伴わない練習なら、保存したファイルやローカルの表示までを終了条件にできます。

編集は簡単でも差分が読みにくいなら、そこが現在の構成の限界です。入力方法だけを改善し続けず、確認の段階を別の画面へ移すことも含めて考えます。

オフラインの下書きと、共有した変更を区別する

圏外でもできる作業と、接続が必要な作業を分けておくと、移動中の時間を使いやすくなります。要件の整理や文章の下書きは手元で進められる場合がありますが、接続先の現在のコードを確認したり、変更を共有したりするには通信が必要です。

たとえば、外出中に修正案を書いたとしても、それだけでリポジトリが変更されたわけではありません。「下書き」「ファイルへ反映済み」「確認済み」「共有済み」を別の状態として記録します。再接続したら、先に対象の最新状態を読み、下書きが今も適用できるかを確かめます。

複数の端末で同じファイルを扱う場合は、古いコピーを新しいものへ上書きしないよう、差分を見てから取り込みます。スマートフォンを作業の入口にする利点は、どこでも変更を確定できることではなく、確認できる範囲で前へ進めることです。どこまでが済み、どこからが未確認かを残せば、PC へ戻るときも続きを選びやすくなります。

参考リンク

• tmux(1) マニュアル(OpenBSD) — 切り離し後も動き続ける仕組みと new -A / attach -d の意味
• What is Tailscale?(Tailscale Docs) — WireGuard ベースで、ポート転送なしに NAT 越しで端末同士がつながること
• GitHub CLI での GitHub Codespaces の使用(GitHub Docs) — gh codespace list / ssh の書式と用途
• termux/termux-app README(GitHub) — Android 12 以降で OS がプロセスを kill し Termux が不安定になりうる注意
• Macのスリープ/スリープ解除を設定する(Apple サポート) — スリープさせない設定とネットワークアクセスによるスリープ解除の項目名
• Claude Code Docs: Remote Control — 起動コマンド、通信経路、プロセス継続やタイムアウトなどの制限事項