AI時代における開発者のためのtmuxガイド

tmuxはターミナルマルチプレクサです。マシン上で永続的なサーバープロセスを実行することで、セッション、ウィンドウ、ペインがターミナルの切断後も維持されます。セッションからデタッチし、ラップトップを閉じ、別のマシンからSSH接続し直しても、すべてのプロセスが元の状態のまま待っています。この一点こそが、tmuxが10年前よりも今日重要視される理由です。開発者は長時間稼働するプロセス——開発サーバー、ビルドウォッチャー、そしてClaude Codeやaiderのような自律型AIコーディングエージェント——を実行するようになっており、これらはSSH接続の不安定さやラップトップの蓋を閉じても動き続ける必要があります。

本ガイドでは、まずメンタルモデル（セッション、ウィンドウ、ペイン、プレフィックスキー）を構築し、一度ペーストすれば触らなくて済む最小限の設定を提供します。そして他のtmuxガイドでは扱われていない部分——tmuxをAIコーディングエージェントの永続的なホストとして使う方法——に十分な時間を割きます。最後に、tmuxを使うべき場面と、ZellijやWarpのようなモダンなターミナルの方が適している場面を率直に比較します。

tmuxとは何か、そして解決する問題

tmuxはターミナルマルチプレクサであり、1つのターミナルウィンドウで多くの永続的なセッション、ウィンドウ、ペインをホストできます。その永続性を支えるのはクライアント・サーバーアーキテクチャです。tmuxを実行すると、セッションを管理する長期稼働のサーバープロセスが起動し、ターミナルはそのサーバーにクライアントとして接続します。SSH接続が切れても、tmuxセッションは切れません——サーバープロセスはクライアント接続とは独立して動作しているからです。ターミナルはただのビューであり、接続しているかどうかに関わらずセッションは動き続けます。

tmuxは2つの問題を同時に解決します。1つ目は永続性です。40分かかるビルド、開発サーバー、タスク実行中のAIエージェントは、sshセッションが切れた後も動き続けます。再接続して再アタッチするだけです。2つ目はレイアウトです。ターミナルタブを切り替える代わりに、1つのウィンドウをペインに分割できます——左にエディタ、右にサーバーログ、下にシェル——すべてを同時に表示し、再現可能な形で。

tmuxは2007年にNicholas Marriottによって、GNU screenのISCライセンスの代替として作成されました。本ガイドの例はtmux 3.6bを使用しています。パッケージマネージャーでインストールしてください：

# macOS
brew install tmux

# Debian / Ubuntu / WSL
sudo apt install tmux

# Fedora / RHEL
sudo dnf install tmux

tmux -V   # バージョンを確認

セッション、ウィンドウ、ペインの階層構造

tmuxは3つの層で作業を整理します。セッションは名前付きの永続的なワークスペース（プロジェクトごとに1つ）、ウィンドウはそのセッション内のタブ、ペインはウィンドウ内の分割領域です。プレフィックスキー——デフォルトはCtrl+b、慣例的にCtrl+aにリマップされます——はすべてのtmuxコマンドへの入り口です。プレフィックスを押して離してから、コマンドキーを押します。

最もわかりやすい例えは、すでに使い慣れたエディタへの対応です。セッションはプロジェクト用のエディタウィンドウ全体、ウィンドウはその中のタブ、ペインはタブ内の分割ビューに相当します。frontendセッションとbackendセッションを持ち、backendの中にはアプリ用のウィンドウとデータベース用のウィンドウがあり、アプリウィンドウの中にはサーバーを実行するペインとアドホックなコマンド用のペインがある、といった構成が考えられます。

プレフィックスがコマンドへの入り口となるため、以下のすべてのキーバインディングはプレフィックスを先に押すことを前提としています。デフォルトのプレフィックスはCtrl+bですが、次のセクションの設定ではCtrl+aにリマップします。こちらの方が押しやすいためです。

必須コマンドセット

以下のコマンドで日常的なtmux操作の90%をカバーできます。セッションの作成と命名、デタッチと再アタッチ、ペインの分割とナビゲーション、出力のスクロールバックです。セッションレベルのコマンドはシェルから実行し、ペインとウィンドウのコマンドはtmux内でプレフィックスを使って実行します。

シェルからのセッション管理：

tmux new -s project       # 名前付きセッションを作成
tmux ls                   # 実行中のセッションを一覧表示
tmux attach -t project    # セッションに再アタッチ
tmux kill-session -t project

セッション内でのプレフィックス使用（ここではリマップ済みのCtrl+aとして表記）：

• prefix d — デタッチ。セッションはバックグラウンドで動き続けます。
• prefix c — 新しいウィンドウを作成。
• prefix n / prefix p — 次 / 前のウィンドウへ移動。
• prefix % — 現在のペインを垂直分割（左右）。
• prefix " — 水平分割（上下）。
• prefix + 矢印キー — ペイン間を移動。
• prefix z — 現在のペインをフルスクリーンにズーム。もう一度押すと元に戻ります。
• prefix [ — コピーモードに入り、スクロールや検索が可能。viモードでは/で検索、n/Nでマッチ間を移動、qで終了。

デタッチ/再アタッチのループがコアワークフローです。prefix dでデタッチし、別のマシンに切り替え、tmux attach -t project-nameで再アタッチすれば、まったく同じ状態から再開できます。キーバインディングの完全なリファレンスはtmuxチートシートを手元に置いておくとよいでしょう——manページ全体を暗記する必要はありません。

一度ペーストすれば済む最小限の~/.tmux.conf

最小限のtmux設定に必要なものはたった4つです。プレフィックスキーのリマップ（Ctrl+aはCtrl+bより人間工学的）、マウスサポート（set -g mouse on）、viコピーモード、そして直感的な分割バインディング——それ以外は見た目の問題であり、後回しにできます。以下がその設定で、各行に存在理由のコメントを付けています。~/.tmux.confにペーストし、tmux source-file ~/.tmux.confでリロードしてください。

# --- prefix -------------------------------------------------
unbind C-b                 # デフォルトのプレフィックスを解除
set -g prefix C-a          # Ctrl+aはホームロウに近い
bind C-a send-prefix       # Ctrl+aを2回押すとリテラルのCtrl+aを送信

# --- usability ----------------------------------------------
set -g mouse on            # ペインのクリック、ボーダーのドラッグ、ネイティブスクロールを有効化
set -g history-limit 10000 # デフォルトの2000より多くのスクロールバックを保持
set -g base-index 1        # ウィンドウ番号を0ではなく1から開始
setw -g pane-base-index 1  # ペイン番号も1から開始

# --- copy mode ----------------------------------------------
setw -g mode-keys vi       # コピーモードでviキーを使用
bind v copy-mode           # prefix vでコピーモードに素早く入る

# --- saner splits -------------------------------------------
bind | split-window -h -c "#{pane_current_path}"  # |で左右に分割
bind - split-window -v -c "#{pane_current_path}"  # -で上下に分割
# どちらも現在のペインのディレクトリで開く

# --- reload -------------------------------------------------
bind r source-file ~/.tmux.conf \; display "reloaded"

構文とバージョンについていくつか補足します。set -g mouse onはtmux 2.1以降で正しい単一オプション形式です。tmux 2.1（2015年）では、4つの古いオプション（mode-mouse、mouse-select-pane、mouse-resize-pane、mouse-select-window）が1つに統合されました。古い設定でmode-mouse onを見かけた場合、それが理由です。-c "#{pane_current_path}"フラグにより、新しい分割が現在のディレクトリを引き継ぎます——小さな機能ですが、ないとすぐに不便さを感じるでしょう。

これが設定の全てです。初日からステータスバーのテーマを追加しようとするのは控えてください。後で追加したい場合、Catppuccin tmuxプラグイン（現在のタグv2.3.0）はtmux 3.2+が必要で、名前の競合のためプラグインマネージャーではなく手動クローンを推奨しています。

モダンなワークフロー：AIコーディングエージェントのホストとしてのtmux

tmuxはAIコーディングエージェントの長時間実行に最適なホストです。ラップトップを閉じる前にClaude Codeやaiderのセッションをデタッチし、どのマシンからでもtmux attach -t agentで再アタッチすれば、エージェントのプロセスと完全な出力履歴がそのまま待っています。Claude CodeもaiderもターミナルCLIであるため、これは特別な統合ではありません。tmuxセッション下でフォアグラウンドプロセスとして実行されるあらゆるツールに共通の標準的な動作を、長時間無人で実行できるツールに適用しているだけです。

エージェントによるコーディングセッションは、まさにtmuxが保護するために設計されたワークロードです。大規模なコードベースをリファクタリングしたり、長いテストループを実行したりするエージェントは、SSH接続のライフタイムに縛られてほしくないプロセスです。tmux内で起動すれば、接続が切れても動き続けます。

作業しながらエージェントを監視する

最も便利なレイアウトは、エージェントを一方のペインに、エディタをもう一方のペインに並べたものです。セッションを起動し、分割し、片側でエージェントを実行します：

tmux new -s agent
# セッション内で：
#   prefix |   -> 左右に分割
#   左ペイン:  claude   (または: aider)
#   右ペイン: nvim .

左でエージェントの推論とdiffを確認しながら、右でレビューや編集を行えます。1つのウィンドウ内で、切断後も両方が生き続けます。

同期ペインで複数のエージェントを管理する

複数のエージェントを並行して実行する場合——たとえば異なるブランチで同じタスクを実行する場合——同期ペインを使えば一括操作が可能です。setw -g synchronize-panes onを設定すると、入力したすべてのキーストロークがウィンドウ内のすべてのペインに同時に送信されます。複数のエージェントセッションに同じプロンプトを発行したり、並行プロセスのセットを一括リセットしたりする際に便利です。個別のペインを操作したい場合は同じ方法でオフにします（synchronize-panes off）。同期ペインでよくある失敗は、同期がオンになっていることを忘れて破壊的なコマンドをすべてのペインにブロードキャストしてしまうことです。状態が常に明確になるよう、視覚的なインジケーター付きのキーバインドに割り当てることをお勧めします。

スクリプト化されたエージェントレイアウト

追加の依存関係なしに、再現可能な3ペインの監視レイアウト——左にエージェント、右上にエディタ、右下にログ——を作成するには、このスクリプトを~/bin/tmux-agent.shに保存してください：

#!/usr/bin/env bash
set -euo pipefail
SESSION="agent"

# 最初のペイン：エージェント（左）。-dはセッションをデタッチ状態で作成。
tmux new-session -d -s "$SESSION" -x "$(tput cols)" -y "$(tput lines)"
tmux send-keys -t "$SESSION" "claude" C-m          # エージェント、左

# エディタ用に右側を分割。新しいペインがアクティブになる。
tmux split-window -h -t "$SESSION"
tmux send-keys -t "$SESSION" "nvim ." C-m          # エディタ、右上

# ログ用に右ペインを分割。新しいペインがアクティブになる。
tmux split-window -v -t "$SESSION"
tmux send-keys -t "$SESSION" "tail -f dev.log" C-m # ログ、右下

# エージェントペインにフォーカスしてアタッチ。方向（-L）でターゲット指定することで、
# base-indexの設定に関わらず正しく動作する。
tmux select-pane -t "$SESSION" -L
tmux attach -t "$SESSION"

一度chmod +x ~/bin/tmux-agent.shを実行し、作業開始時にtmux-agent.shを呼び出すだけです。デタッチしてもエージェントは動き続け、どこからでも再アタッチできます。

永続性とプラグイン

tmuxセッションは切断後も生き続けますが、再起動後は自動的には復元されません。そのためには、状態をシリアライズして復元するプラグインが必要です。標準的な構成はTmux Plugin Manager（TPM）にtmux-resurrectとtmux-continuumを加えたものです。TPMは以下でインストールします：

git clone https://github.com/tmux-plugins/tpm ~/.tmux/plugins/tpm

次に~/.tmux.confの末尾にプラグイン行を追加し、prefix + Iを押してインストールします：

set -g @plugin 'tmux-plugins/tpm'
set -g @plugin 'tmux-plugins/tmux-resurrect'
set -g @plugin 'tmux-plugins/tmux-continuum'
run '~/.tmux/plugins/tpm/tpm'   # この行を最後に置く

各プラグインが実際に何をするのかを理解しておきましょう。tmux-resurrectはセッションレイアウト——ウィンドウ、ペイン、作業ディレクトリ——を自動的に保存・復元します。実行中のプログラムの復元はオプトイン方式で、設定したホワイトリスト（@resurrect-processes）に限られます。エディタセッションは@resurrect-strategy-vim/nvimで処理され、ペインのテキストは@resurrect-capture-pane-contents 'on'を設定した場合のみ保持されます。ホワイトリストに追加していない限り、エージェントが復元時に自動再起動するとは思わないでください。

tmux-continuumはデフォルトで15分ごとに自動保存を行い（@continuum-save-intervalで設定可能）、@continuum-restore 'on'を有効にした場合のみtmuxサーバー起動時に復元します。これらを組み合わせることで、再起動のコストはレイアウトの再ロードだけになり、ゼロから再構築する必要がなくなります。

tmuxpによる宣言的レイアウト

繰り返し起動するレイアウトは、tmuxp（リポジトリ：tmux-python/tmuxp）またはRuby製のTmuxinatorを使ってYAMLで一度定義しておきましょう。tmuxpはXDGディレクトリ~/.config/tmuxp/（レガシーの~/.tmuxp/パスも引き続き機能します）から設定を読み込みます。以下はエージェント監視レイアウトを~/.config/tmuxp/agent.yamlとして定義した例です：

session_name: agent
windows:
  - window_name: supervise
    layout: main-vertical
    shell_command_before:
      - cd ~/code/project
    panes:
      - claude
      - nvim .
      - tail -f dev.log

tmuxp load agentで読み込みます。ここで使われているキー——session_name、windows、window_name、layout、shell_command_before、panes——はすべてtmuxp 1.70.x現在のものです。これは上記のbashスクリプトの宣言的な等価物です。1つのコマンドで、毎回同じ再現可能なレイアウトが得られます。

tmuxを使うべきでない場面

ローカルで作業しており、リモートマシンへのSSH接続や長時間稼働するバックグラウンドプロセスの実行が不要な場合は、ZellijやWarpのようなモダンなターミナルの方がより良いデフォルト設定でマルチプレクシングを提供でき、プレフィックスキーを覚える学習コストもありません。tmuxの優位性は特にSSH越しのサーバーサイド永続性とスクリプタビリティにあります。ターミナルのネイティブタブで十分な場面でtmuxを使うのは、メリットのない複雑さの追加です。

いくつか重要な補足があります。ZellijはRust製のマルチプレクサで、単一のプレフィックスキーの代わりにモードベースのシステムを採用し、セッション永続性とシリアライズが組み込まれており、オプションでtmux風のプレフィックスプリセットも使えます。活発に開発中ですが、まだ1.0以前です。WarpはmacOS、Linux、Windowsに対応したクロスプラットフォームのターミナルで、AIを統合したコマンド提案機能を持ち、クライアントは2026年4月にオープンソース化（MIT + AGPL v3）されたため、LinuxでもmacOS専用ツールではなく実用的な選択肢となっています。tmuxを選ぶべきは、リモートマシンにSSH接続する場合、長時間稼働するプロセス（ビルドウォッチャー、開発サーバー、AIエージェント）を実行する場合、またはスクリプト化された再現可能なレイアウトが必要な場合です。セレモニーを減らしつつ同様の機能を求め、tmuxのスクリプタビリティやプラグインの豊富さが不要な場合はモダンなターミナルを選んでください。

まとめ

tmuxがエージェント中心のワークフローで重宝される理由は、かつてSSHで重宝された理由と同じです。実行中のプロセスをそれを監視するターミナルから切り離せることです。次の長時間エージェント実行をtmux new -s agentの中で始め、席を離れる前にデタッチし、どこからでも再アタッチしてください——作業はあなたなしで続きます。上記の最小限の設定をペーストし、再起動でレイアウトを失うようになったらtmux-resurrectを追加し、エージェントレイアウトを一度スクリプト化して手動再構築を不要にしましょう。

よくある質問

tmuxサーバーがkillされたりマシンが再起動した場合、tmux内で実行中のプロセスはどうなりますか？

プロセスは終了します。tmuxの永続性はクライアントの切断から保護するだけであり、サーバーのシャットダウンには対応していません。そのため、tmux kill-serverでサーバーをkillしたりマシンを再起動したりすると、すべての実行中プロセスが終了し、すべてのセッションが失われます。再起動後も生き残るには、tmux-resurrectでレイアウトを保存し、tmux-continuumでサーバー起動時に復元する必要があります。ただし、resurrect-processesオプションで特定のプロセスをホワイトリストに追加しない限り、復元されるのはレイアウトであり、実行中のプログラムではありません。

tmuxのウィンドウとペインの違いは何ですか？

ウィンドウはセッション内のフルスクリーンのタブであり、ペインは1つのウィンドウ内の分割領域です。prefix nまたはprefix pでウィンドウを切り替えると画面全体が別のタブに置き換わりますが、ペインは1つの表示ウィンドウを左右または上下に分割した領域であり、prefixと矢印キーでナビゲートします。アプリとデータベースのような別々のタスクを分けるにはウィンドウを使い、エディタとライブログのように関連するプロセスを同時に表示するにはペインを使いましょう。

プレフィックスキーをCtrl+bからCtrl+aにリマップする必要がありますか？

いいえ、リマップは任意であり、純粋に人間工学上の選択です。デフォルトのプレフィックスCtrl+bは設定なしですべてのtmuxコマンドで動作します。多くのユーザーがCtrl+aにリマップするのはキーボード上でキーが近いためですが、GNU screenの同じバインディングや、カーソルを行頭に移動するreadlineショートカットと競合します。Ctrl+aにリマップする場合は、bind C-a send-prefixを追加して、2回押すとリテラルのCtrl+aがシェルに送信されるようにしてください。

SSH越しにコーディングエージェントを実行する場合、tmuxとZellijのどちらを使うべきですか？

どちらもリモートホスト上でサーバーを実行し、切断後もセッションを維持するため、選択はデフォルトとエコシステムによります。大規模で成熟したプラグインエコシステム、bashやtmuxpによる深いスクリプタビリティ、そしてほとんどのサーバーに既にインストールされているバインディングが必要な場合はtmuxを選んでください。プレフィックスキーモデルではなく発見しやすいモードベースの操作を好み、プラグインを設定せずにセッションのシリアライズが欲しい場合はZellijを選んでください。Zellijはまだ1.0以前であるため、長期稼働のセットアップにはtmuxの方が保守的な選択です。