tmux リモート Mac のタスクは切断で停止する？2026 設定ガイド

SSH接続が切れても、tmuxのサーバーとセッションが動作していれば、その中のタスクは通常継続します。ただし、macOSのスリープ、システム再起動、プロセス障害、ノード回収までは保護できません。本稿では、現場での切り分け、ログ確認、再接続、復旧テスト、長期運用の判断基準をまとめます。

tmux リモート Mac のタスクは切断で停止する？2026 設定ガイド

目次

tmux リモート Mac のタスクは切断で停止する？2026 設定ガイド

tmux公式のGetting Startedでは、クライアントが切断されてもサーバー側のセッションを保持し、あとから再接続できる構造が説明されています。tmux公式ドキュメントに基づく結論は明快です。SSHが切れただけならtmux内のタスクは通常継続しますが、Macのスリープ、再起動、プロセス障害、ノード回収までは防げません。今週は、実行前にログ保存を追加し、断線と再起動を順番に検証してください。

この判断が必要なのは、SSH経由でコンパイル、テスト、データ処理、AI Agentの長時間処理を実行する開発者です。
DevOpsエンジニアは、端末の切断耐性と無人サービスの可用性を分けて考える必要があります。プラットフォーム担当者は、リモートMacを引き渡す前に断線、スリープ、再起動後の復旧手順を確認してください。

tmux リモート Macで最初に分けるべき4つのプロセス

画面が消えたとき、すぐに「タスクが停止した」と判断してはいけません。SSH接続、ログインシェル、tmuxクライアント、tmuxサーバー、実際のタスクプロセスは別物です。

現象 まず確認する対象 低リスクな判断
SSHクライアントだけ切断された tmux ls、タスクのPID、ログ セッションがあれば再実行しない
シェルを終了した tmux内で起動したか tmux外なら終了の可能性が高い
tmuxセッションが残っている tmux attach -t <session> 画面ではなくプロセスとログを確認
Mac自体がスリープした 電源設定と接続状態 tmuxの問題と決めつけない
Macが再起動した 起動時刻、サービス、ログ 通常のtmuxセッション復元を期待しない

タスクの確認には、まず対象アカウントで次を実行します。<session>、<pid>、<project-dir>は実際の値に置き換えてください。

tmux ls
ps -p <pid> -o pid=,ppid=,stat=,etime=,command=
pwd
tail -n 50 <project-dir>/build.log

tmux lsにセッションがあり、PIDの経過時間が切断前から連続し、ログの末尾も更新されているなら、同じタスクは継続中と判断できます。逆に、空のペインだけを見て再実行すると、同じビルドやデータ処理を二重に走らせる危険があります。

注意：kill、tmuxソケットの削除、ホストの再起動は、証拠を消したり実行中の処理を止めたりします。先にPID、作業ディレクトリ、最終ログ、起動コマンドを保存してください。

第一歩：命名したセッションを作り、切断前の状態を固定する

普通のSSHシェルで直接コマンドを実行すると、SSH接続の終了時にシェルや子プロセスが終了する可能性があります。最初から名前付きセッションを作り、タスクをその中で起動してください。

tmux new-session -s build-job
cd <project-dir>
your-build-command 2>&1 | tee build.log

別の端末から接続を確認するため、作業を止めずにデタッチします。

Ctrl-b d

その後、セッションの存在を確認します。

tmux ls
tmux attach -t build-job

ここで合格とする条件は、単に同じ画面が表示されることではありません。次の項目が切断前後で一致しているか確認します。

tmuxのセッション、クライアント、サーバーの関係は、tmux公式マニュアルで確認できます。セッションを作ったアカウントと、再接続したアカウントが異なる場合、別のtmuxサーバーを見ているように見えるため、セッションが消えたと誤認しやすくなります。

再接続後にPATHやSSH Agentが変わる境界

セッションが残っていても、再接続後に開いた新しいペインの環境が期待どおりとは限りません。ログインシェルの設定、PATH、Homebrewの実行ファイル位置、環境変数、SSH Agentの転送状態は、タスクそのものの生存とは別に確認する必要があります。

echo "$SHELL"
echo "$PATH"
command -v brew
command -v git
printenv | sort
ssh-add -l

Homebrewでtmuxを導入する場合は、Homebrewのtmux Formulaに掲載された現行の導入方法を使い、導入後にcommand -v tmuxで実体を確認します。Intel向けとApple Silicon向けで実行ファイルの探索経路が異なる場合があるため、設定ファイルに固定パスを書き込む前に、対象ノード上で確認してください。

tmux公式FAQも、セッション内の環境と後から更新される環境を同一視しないよう説明しています。公式FAQの環境変数に関する説明を確認し、認証情報をペインのコマンド履歴へ直接書かない運用にしてください。

新しいペインでbrewやgitが見つからない場合でも、既に実行中のビルドが直ちに停止したとは限りません。まず既存PIDとログを調べ、環境の問題とタスク停止を分離してから、シェル設定を修正します。

スリープはtmuxでは防げない

tmuxが守るのは端末セッションです。Macをスリープさせない機能ではないため、SSH切断後も処理を継続できる設定と、ホストが処理可能な電源状態を維持する設定は分けて考えます。

AppleのRemote Login設定では、SSHで接続するためのmacOS側の許可を確認できます。一方、Macのスリープとスリープ解除に関する設定は、ディスプレイ消灯、システムスリープ、ネットワーク経由の復帰などを別の条件として扱っています。

状態 tmuxが保持できるもの 別途確認するもの
SSH接続の切断 セッション、ペイン、端末状態 タスクPIDとログ
ディスプレイ消灯 tmuxセッション CPU処理とSSH到達性
システムスリープ 端末情報の保持のみ 処理、ネットワーク、復帰条件
受動的なネットワーク断 サーバー側セッション ノードが稼働し続けているか
ホスト再起動 通常は保持しない 起動後のサービスと再実行

一時的な作業であれば、対象ノードの電源設定を確認したうえで、処理中だけスリープを避ける方法を検討できます。ただし、ディスプレイを消すこととMac全体をスリープさせないことは同じではありません。長期運用では、変更した設定、元へ戻す方法、管理者権限の有無を記録してください。

再起動後はセッション復元ではなく、サービス復旧として扱う

tmuxサーバーは通常のユーザープロセスとして動作するため、Macの再起動後も以前のセッションが残るとは限りません。再起動後に同じセッション名を作り直しても、以前のプロセスやペインの状態が復元されたことにはなりません。

再起動を伴う処理では、次の情報をログへ残しておくと安全に再実行できます。

Macの起動後に自動で処理を開始し、異常終了時の扱いも定義したいなら、tmuxではなくlaunchdやCIの管理対象に移します。Appleのlaunchdサービス作成ガイドでは、バックグラウンドジョブの登録や起動条件が説明されています。アプリケーション由来の常駐処理では、AppleのService Managementも確認対象になります。

ただし、いきなり常駐化するのではなく、失敗時に何回再試行するか、入力を二重処理しないか、ログをどこへ保存するかを決めてください。再起動で自動復旧しても、壊れた入力を繰り返し処理する設計なら、可用性ではなく障害の自動拡大になります。

切断・スリープ・再起動を順番に検証する

tmuxの設定が正しいかは、実際の長時間タスクで確認します。短いコマンドを実行して画面が戻るだけでは、ビルドやテストの途中状態まで検証できません。

第二歩：検証用タスクとログを準備する

cd <project-dir>
your-long-running-command 2>&1 | tee -a build.log
echo $!

PIDの記録方法はコマンドの起動方法によって変わるため、実際にはpsで対象プロセスを確認します。ログには秘密情報を出力しないでください。

第三歩：SSHクライアントだけを切断する

SSHウィンドウを閉じる、またはネットワーク接続を一時的に切り替え、しばらくして同じアカウントで再接続します。tmux ls、PID、ログの末尾を確認し、タスクが継続したかを判定します。

第四歩：tmuxから明示的にデタッチする

Ctrl-b dでデタッチし、別のSSH接続から再度attachします。これはSSH障害とは違い、意図的なセッション切り離しの確認です。

第五歩：空き時間と環境を確認する

長時間操作しない状態を作り、定期的にノードへ接続できるか、タスクとログが継続するかを記録します。ここで止まった場合は、tmuxではなくmacOSの電源管理やノード側の運用条件を調査します。

第六歩：管理された再起動を行う

ログとPIDを保存し、再起動してよい時間帯を選びます。起動後にtmuxセッションが戻るかではなく、ログから安全に再開できるか、自動サービスやCIジョブが期待どおり動くかを判定します。

運用方式はタスクの復旧要件で選ぶ

タスクの性質 適した方式 tmuxの位置づけ 不合格になる条件
人が接続して確認するビルド tmux 主たる作業環境 再接続後にPIDやログを確認できない
数時間のテストやデータ処理 tmux＋ファイルログ 監視付きの実行容器 スリープや再接続の結果が未検証
再起動後も自動で再開する処理 launchdまたはCI 必要時の手動調査用 手動attachがないと復旧できない
リリース用の反復ビルド CI Runner 一時的なデバッグ用 成果物、再試行、秘密情報を管理できない
物理ノードの交換があり得る処理 外部スケジューラーと永続ログ 状況確認用 ノード消失時に入力と状態を失う

[ ] タスクを名前付きtmuxセッション内で起動した
[ ] PID、作業ディレクトリ、開始コマンドを記録した
[ ] 標準出力と標準エラーをファイルへ保存した
[ ] SSH切断後に同じPIDまたは安全な復旧状態を確認した
[ ] 新しいペインでPATH、Homebrew、Git、SSH Agentを確認した
[ ] スリープ時の処理とSSH到達性を別々に確認した
[ ] 受動的な再起動後にログと成果物を確認した
[ ] 再実行時の重複処理を防ぐ条件を決めた
[ ] 常駐が必要な処理をlaunchdまたはCIへ移す判断をした
[ ] ノードが使えない場合の代替アクセス経路を確認した

FAQ：復旧条件を運用前に確認する

SSH切断後もtmux内のタスクは続くのか

tmuxサーバーとタスクプロセスが残っていれば、SSHクライアントが切れても処理は通常続きます。再接続後は、画面表示だけでなくtmux ls、ps、ログの更新時刻を組み合わせて判定してください。セッションが見つからない場合も、別アカウントや別ノードへ接続していないかを先に確認します。

リモートMacの再起動後にセッションを戻せるのか

通常のtmuxは、Macの再起動をまたいでセッションを保存する仕組みではありません。再起動後に同名セッションを作成しても、以前のペインやタスクが戻ったことにはならないため、ログ、入力状態、成果物から安全な再実行方法を判断します。継続的な自動復旧が必要なら、tmuxからサービス管理へ移行します。

Macがスリープすると処理が止まる理由

tmuxは端末の切断を吸収しますが、Macのスリープ状態やCPU、ネットワークを制御しません。スリープ中に処理を続けられるかは、macOSの電源設定とノードの運用条件で変わります。ディスプレイ消灯だけを確認して「常時稼働」と判断せず、実際のタスクとSSH接続を別々に検証してください。

tmuxのビルドログを再接続後に確認する方法

対象アカウントでtmux lsを実行し、セッション名を確認してからtmux attach -t <session>で再接続します。画面の履歴だけでは重要な出力を失うことがあるため、ビルド開始時からteeなどでログファイルへ保存してください。ログの末尾、PID、成果物の更新状態を同時に見ると、停止と単なる表示欠落を区別できます。

長期スクリプトにtmuxを使い続けてよいのか

人が必要に応じて接続し、途中経過を確認する処理ならtmuxで十分な場合があります。しかし、再起動後の自動起動、異常終了からの復旧、重複実行の防止、定期実行が必要なら、macOSのバックグラウンドサービスやCIスケジューラーを使う方が適切です。tmuxだけで本番サービスの可用性を保証しないでください。

VPSMACのリモートMacを使う場合も、tmuxがSSH切断を吸収する一方で、スリープ、再起動、ノード交換まで自動的に解決するわけではありません。自前のMac mini構成では、物理障害、電源、回線、保守作業を自分で管理する必要があり、一般的なクラウド環境ではmacOS専用ツールチェーンを使えない場合があります。固定された開発環境を一定期間使い、ログと別経路の復旧手順まで確認したいなら、VPSMACのリモートMac構成を候補に入れ、まず断線と再起動の実地検証を行ってください。

地域や接続経路を選ぶ必要がある場合は、VPSMACの東京ノードなどの提供条件を確認し、手元からのSSH遅延、予備アクセス、ログ保存先を先に決めるのが安全です。短期の対話的作業にはtmux、無人で復旧すべき処理にはlaunchdやCIという分担にすると、tmuxへ過剰な役割を持たせずに運用できます。