同じ疑問を何度も持つのは、記憶力の問題ではない。3つの層がひとつの画面に混ざって表示されているためである。まず、これまで繰り返し引っかかってきた点を並べておく。答えは後続のカードで展開する。

すべての混乱は、次の3つを1本の線として意識すれば解ける。ここを飛ばして機能名を覚えると、必ずまた迷子になる。

• サーフェス（surface）＝ 見る窓。ターミナル、ブラウザ、デスクトップアプリ、スマホアプリ。ここは何の能力も決めない。
• ホスト（host）＝ 実際に動いているマシン。手元の Mac mini か、ベンダーのクラウドか。使える機能はここで決まる。
• リポジトリ＝ 保管場所。Git／GitHub。作業机の上の状態とは別に、正典がここにある。

ベンダーの機能に一切依存しない、いちばん素直な経路。手元の Mac mini のターミナルそのものを外から借りる。ローカル LLM を動かしたいなら、実質この経路しかない。

3つの道具は、それぞれ別の問題を解いている

組み立ての骨格

# ── Mac mini 側（1回だけ） ──
# 1. システム設定 > 一般 > 共有 > リモートログイン を ON（＝ sshd が起動する）
# 2. Tailscale をインストールしてサインイン
# 3. スリープしない設定にする（重要）
sudo pmset -a sleep 0 disablesleep 1

# ── 接続するたび（Termius から） ──
ssh nao@macmini            # tailnet 上の MagicDNS 名で届く

# ── 入ったら、まず tmux に入る（ここを飛ばさない） ──
tmux new -s ai             # "ai" という名前で新しい作業台を作る
tmux ls                    # 残っている作業台の一覧
tmux attach -t ai          # 既存の作業台に座り直す
# 抜けるときは Ctrl-b → d（デタッチ。中身は動き続ける）

なぜ tmux を必ず挟むのか

SSH でログインして起動したプロセスは、その接続に紐づいている。電車がトンネルに入って通信が切れれば、走っていたビルドも学習も一緒に落ちる。tmux は接続とプロセスの間に緩衝材を入れる仕組みで、接続が切れても「作業台」はサーバー側に残り続ける。

この点は経路B でも効いてくる。Claude の公式ドキュメントですら、SSH 先のマシンでセッションを維持したいなら tmux か screen の中で起動せよと明記している[3]。tmux は経路A 専用の道具ではなく、全経路の土台である。

ローカル LLM（Ollama）はこの経路の住人

ここが認識のズレやすい点である。Claude や Codex のリモート機能は、それぞれの会社の AI を手元で動かすための仕組みであって、Ollama を外から動かすための仕組みではない。Mac mini の Ollama を外から使いたいなら、選択肢は次の2つに限られる。

• SSH で入って CLI で叩く（ollama run qwen3）。いちばん単純で、追加のリスクがない。
• tailnet 越しに API ポート（11434）へ繋ぐ。Open WebUI などの GUI を使いたい場合。ただし tailnet の中だけに閉じること。インターネットに直接晒すのは論外である。

経路B は SSH を使わない。手元のプロセスが、自分からベンダーのサーバーへ「外向きに」繋ぎに行き、そこで待ち合わせるという設計である。だから自宅ルーターの設定変更が要らない。

覚え方はひとつだけでいい。Remote Control ＝ 続ける（continue）／ Dispatch ＝ 始める（create）。

Remote Control の仕組み（3点）

• 通信は外向きだけ。手元のマシンは外部からの接続口を開かない。Claude Code の側から Anthropic の API へ HTTPS で繋ぎ、作業を取りに行く[3]。ルーターの設定は不要。
• 実行とファイルアクセスは手元に残る。ローカルのファイル、MCP サーバー、入れてあるツール、プロジェクト設定はそのまま使える。@ でのファイル名補完も手元のプロジェクトから効く。
• 会話ログはサーバー側にも保存される。端末間の同期と、切断からの復帰のため。実行そのものは手元のままである。

# A. 受け待ち専用のサーバーモード（複数セッションを受けられる）
claude remote-control
claude remote-control --spawn worktree   # 新規セッションごとに git worktree を分ける（カード08 参照）

# B. ふつうの対話セッション＋外からも触れるようにする
claude --remote-control "Mac mini 作業"

# C. 作業中のセッションを途中から外に出す
/remote-control

Dispatch（ディスパッチ）

スマホからタスクを投げると、手元のデスクトップアプリ側で新しいセッションが起きて処理する仕組み。公式は「スマホからタスクをメッセージすると、Desktop セッションを立ち上げて処理させられる」と説明している[3]。ペアリングは QR コードで1回だけ。

Remote Control が CLI／VS Code をホストにするのに対し、Dispatch はデスクトップアプリをホストにする。両者は別々の入口で、組み合わせて使うものとしては説明されていない。まず「続けたいのか、投げたいのか」で選ぶ。

覚えておくべき制約

• 手元のプロセスが死んだら終わり。ターミナルを閉じる、VS Code を終了する、Mac がスリープする——どれでもセッションは終了する。だから SSH 先で使うなら tmux の中で起動せよと公式に書かれている[3]。
• ネットが約10分切れると、タイムアウトしてプロセスが終了する。再度立ち上げが必要。
• Dispatch はデスクトップアプリが起きていることが前提。ノートの蓋を閉じれば止まる。「クラウド実行」ではなく、あくまでリモコンである。
• API キーでは使えない。claude.ai のアカウントでログインしている必要がある。

骨格は Claude と同じ（「手元で動かして外から操る」か「最初からクラウド」か）。違いは3点に集約される。

実務的な差が出るのは「別マシンを使えるか」の行である。常時起動の Mac mini を持っているなら、Codex 側の構成のほうが素直に組める。デスクトップアプリが SSH で Mac mini に入り、スマホはそのデスクトップアプリに繋ぐ、という二段構えになる。

Handoff（ハンドオフ）

チャットと Git の状態を、ローカルと接続済みホストの間で移動させる機能。手元で始めた作業を Mac mini 側の worktree に移し、あとで手元に戻せる。条件がひとつある——移動先のホストにも、同じ Git リポジトリのプロジェクトを保存しておく必要がある。これがカード08 の話に直結する。

優劣ではなく階層である。経路A が「家の基礎工事」、経路B が「家具」。基礎（Tailscale + 常時起動 + tmux）を先に固めておけば、上に載る各社の機能が仕様変更で壊れても、作業自体は止まらない。

ここまで来れば、この問いはもう解けている。WEB もアプリもターミナルも、すべて同じセッションを覗く窓にすぎない。窓の種類で挙動が変わるのではなく、そのセッションがどのマシンで動いているかで使える機能が決まる。

それでも混乱するのは、一覧に混ざって並ぶから

claude.ai/code のセッション一覧には、手元で動いているセッションとクラウドで動いているセッションが区別なく並ぶ。見た目がほぼ同じなのに、中身は次のように違う。

混同しやすいフラグ

--cloud（クラウドで新規実行）と --remote-control（手元で実行しつつ外から見えるようにする）は、名前が似ているが正反対の機能である。さらに --teleport でクラウドセッションを手元に引き取ると、それ以降クラウド側の画面には反映されない。スマホから操作を続けたいなら、引き取ったあとでもう一度 /remote-control が要る。

迷ったときの3つの確認

1. 手元にしかない環境（ローカルの DB、社内ネット、ローカル設定の MCP、未コミットのファイル）が必要か？ 必要 → Remote Control / Codex の Remote。クラウド環境からは手元の資産は見えない。
2. PC を閉じて出かける、あるいは電源を落とす予定か？ その予定 → クラウド側（web セッション / Codex cloud）。リモート接続はホストが止まった時点で終わる。
3. 常時起動のマシンを1台用意できるか？ できる → それをホストにするのが最も安定。Codex なら SSH ホスト構成、Claude Code ならそのマシンで claude remote-control を tmux 内に常駐させる形になる。

この2つが混ざるのは、デスクトップアプリが新しいセッションを作るたびに、裏で自動的に作業ディレクトリとブランチを生やしているからである。「プロジェクトを作った」と「ブランチができた」が同時に起きるので、同じ操作に見えてしまう。

5つの言葉を、それぞれの階層に置く

なぜ混ざるのか

Claude のデスクトップアプリは、Git リポジトリの場合、セッションごとに自動で worktree を切って隔離する。既定の保存先は <プロジェクトの根>/.claude/worktrees/ である[5]。CLI でも claude remote-control --spawn worktree で同じ挙動になる。

つまり「新しいセッションを作る」という1つの操作が、フォルダの複製とブランチの作成を同時に引き起こしている。ここが「プロジェクト＝ブランチ」という誤解の発生源である。正しくは：

• セッションを作る → アプリが worktree（机）を用意する → その机に新しいブランチが割り当てられる
• プロジェクトは、その机の場所を指すアプリ側の登録であって、ブランチではない
• だからホストが変われば、プロジェクトの登録も別に必要になる（Git の状態は共有されていても）

この理解が効いてくる場面

• Codex の Handoff。移動先のホストに「同じ Git リポジトリのプロジェクト」を保存していないと、移動先の候補にすら出てこない。リポジトリのサブディレクトリを使っている場合は、両ホストで同じサブディレクトリを登録する必要がある[4]。これは Git の問題ではなく、付箋を貼っていないという問題である。
• クラウドセッションと手元の食い違い。クラウド VM から見えるのは GitHub にコミット済みのものだけ。手元の worktree にある未コミットの変更は、当然そこにはない。
• 「変更が消えた」という錯覚。別のセッション＝別の worktree で作業していただけ、というケースが多い。まず git worktree list と git branch を見る。

常時起動の Mac mini がある、という前提で最も素直な形は次のとおり。

1. 土台：Mac mini を「起きたまま」にし、Tailscale を入れ、リモートログインを有効にする ここが崩れると、上のすべてが崩れる。スリープ設定の確認を最優先にする。
2. 常駐：tmux の中で claude remote-control を走らせておく ターミナルを閉じてもセッションが生き残る。公式が推奨している唯一の「常駐」の作り方である。
3. 日常：スマホ／ブラウザからは、その常駐セッションに繋いで承認と確認をする Remote Control は「続ける」ための機能。投げっぱなしにしたいなら Dispatch かクラウド側を使う。
4. ローカル LLM を使うときは、Termius から SSH で入って tmux の別ペインで動かす Ollama は各社のリモート機能の管轄外。経路A でしか触れない。
5. PC を落として出かける日は、最初からクラウド側（web セッション／Codex cloud）に投げる 手元のホストが要らない作業か否かを、着手前に判断する習慣をつける。

セッション／チャット

1本の会話とその作業状態。どの画面から見ても、同じものは同じ内容。

サーフェス（surface）

セッションを操作する窓。ターミナル、IDE、デスクトップアプリ、ブラウザ、スマホアプリ。実行場所とは無関係。

ホスト

実際にコードを動かしているマシン、またはその常駐プロセス。Claude Code では CLI／VS Code、Codex ではデスクトップアプリ。

tailnet

Tailscale が作る自分専用の仮想ネットワーク。参加した機器同士だけが直接届く。

MagicDNS

tailnet 内で、IP アドレスの代わりに機器名（macmini など）で呼べるようにする仕組み。

tmux（ターミナルマルチプレクサ）

1つのターミナル画面を分割し、かつ接続が切れても残り続けるセッションを作る道具。Ctrl-b d でデタッチ、tmux attach で復帰。

Remote Control（Claude）／ Remote（Codex）

手元で動いているセッションを、ブラウザやスマホから操作できるようにする機能。

Dispatch（Claude）

スマホからタスクを投げ、手元のデスクトップアプリ側でセッションを起こさせる仕組み。

Teleport（Claude）

クラウドセッションを手元のターミナルに引き取ること。一方向。

Handoff（Codex）

チャットと Git の状態を、ローカルと接続済みホストの間で双方向に移動させること。クラウドへは不可。

worktree

1つの Git リポジトリに対して複数の作業ディレクトリを持たせる仕組み。並行作業でファイルが衝突しなくなる。