Rust 製の Zellij は tmux を置き換えるのか。両者ともクライアント・サーバ型である以上「セッションが消えない」ことは差にならない——本当の分かれ目は、0.39 から内蔵された Session Resurrection、リポジトリにコミットできる KDL レイアウト、そして Wasm プラグインの実際の利点(速度ではなくサンドボックス)にあります。`Ctrl+Z` で UI が隠せるという誤情報、フローティングペインが Zellij 専売という誤解も `default.kdl` と突き合わせて訂正。最後に AI エージェント用マルチプレクサ herdr との併用可否を、入れ子の「方向」という観点から整理します。
ターミナルマルチプレクサ(Terminal Multiplexer)の世界で、tmux は長らく開発者のデフォルトであり業界標準でした。そこへ近年、Rust で書かれた挑戦者 Zellij が、すぐ使える操作性・モダンな UI・WebAssembly ベースのプラグイン機構を武器に急速に存在感を増しています。
この世代交代の本質は、**「ミニマリズムと高いカスタマイズ性」と「すぐ使えるモダンなアーキテクチャ」**という路線の対立です。本稿ではアーキテクチャ、設定とエコシステム、セッション維持の観点から比較し、最後に最近よく聞かれる問いに答えます——AI 時代の新顔 herdr は、これらとどう組み合わせるべきなのか。
本稿のキーバインドと挙動は、Zellij v0.45.1(2026-08-28 リリース)の
default.kdl、tmux 3.2+、herdr v0.4.0 の公式ドキュメントに突き合わせて確認しています。この領域は動きが速いので、読む時点では手元のzellij --versionを基準にしてください。
1. アーキテクチャと性能:C 言語のベテラン vs Rust の新星
tmux(C):盤石のミニマリズム
tmux は古典的なクライアント・サーバ型アーキテクチャを採用しています。ターミナルエミュレータが落ちても SSH が切れても、バックグラウンドの server プロセスがセッションを保持し続けます。20 年近い実績があり、リソース消費は極めて小さく、古いサーバ、1 コア 1GB の小さなマシン、遅延の大きい回線のいずれでも安定して動きます。
Zellij(Rust):サンドボックス化されたモダン設計
Zellij も同じくクライアント・サーバ型です。つまり「セッションが消えない」という点で両者に優劣はありません。これはマルチプレクサの基本機能であって、どちらかのセールスポイントではないのです。
Zellij の本当の設計上の違いはプラグインの隔離にあります。プラグインは子プロセスとしてシェルスクリプトを走らせるのではなく、WebAssembly にコンパイルされ、独立したメモリ空間と明示的な権限システムを持つサンドボックス内で実行されます。そのため、挙動のおかしいサードパーティ製プラグインがセッション全体を巻き込んで落とすことは起こりにくい構造になっています。
このサンドボックスは、tmux にはない配布方法ももたらします。プラグインを URL から直接ロードでき、リポジトリの clone もプラグインマネージャの導入も設定のリロードも要りません。
代償も明記しておきます。Zellij はバイナリサイズも常駐メモリも tmux より明確に大きい。リソースが本当に厳しいマシンでは、依然として tmux のほうが安心です。ただし Zellij は単一の静的バイナリで外部依存がないため、root 権限のないマシンでは scp で放り込むほうがパッケージを入れるより速い、という場面もあります。
2. 操作体験と学習曲線
- tmux(急勾配):設計思想は「デフォルトでは何も提供しない」。初見のユーザーは黒い画面に向かい、
Ctrl+b(デフォルト prefix)と各種キーの組み合わせを覚えないと分割も移動もできません。天井は非常に高い一方、脱落率も高い。 - Zellij(緩やか):画面下部に対話的なステータスバーが常駐し、現在のモードと使えるキーをそのまま表示します。マニュアルなしで触れる。マウス操作(クリックで移動、ドラッグでリサイズ)もデフォルトで有効で、tmux では
set -g mouse onが必要です。
両者の差は「ヒント行の有無」ではなく、インタラクションモデルそのものの違いです。tmux は prefix モデルで、操作のたびに Ctrl+b を押してからキーを打ち、終われば通常状態に戻ります。Zellij は Vim に似たモードモデルで、Ctrl+p で Pane モードに入ったらそこに留まり、n・d・r と続けて押してペインを 3 つ開けます。抜けるのは Esc か Ctrl+p。
レイアウト調整のような連続操作ではモードモデルのほうが明らかに指が楽ですが、「いま自分はどのモードにいるか」を常に把握する必要があります。ステータスバーが標準で出ているのは、まさにこの認知負荷を肩代わりするためです。逆に言えば、tmux の prefix モデルは冗長でもモード錯誤がほぼ起きない。これは多くのベテランが移行したがらない現実的な理由でもあります。
「UI を隠す」についてよくある誤情報
「Zellij は Ctrl+Z で UI を隠して素のターミナルに戻れる」という説が流布していますが、これは誤りです。Ctrl+Z は Zellij のデフォルト設定では何にもバインドされておらず、ターミナルにおける伝統的な意味は SIGTSTP(フォアグラウンドプロセスの一時停止)です。
default.kdl に照らした正しい操作は次のとおりです。
| 目的 | 実際の操作 |
|---|---|
| ペイン枠の表示切替 | Ctrl+p → z(TogglePaneFrames) |
| UI なしで全画面化 | Ctrl+p → Shift+f |
| 恒久的に UI を簡素化 | pane_frames false / simplified_ui true、または組み込みの compact レイアウト |
tmux ユーザーが知っておくべき 2 点
第一に、Zellij の normal モードでは Ctrl+b が Tmux モードに割り当てられています。tmux 互換のキーセットが公式に同梱されているので、移行時に筋肉記憶をゼロからやり直す必要はありません。
第二に、Zellij のデフォルトキーは Ctrl の組み合わせを大量に消費するため、Vim・Emacs・各種 TUI のショートカットと激しく衝突します。これは実在する痛点で、公式は 0.41 で Unlock-First プリセットを用意しました。普段はインターフェースがロック状態でキーがアプリにそのまま渡り、Zellij を操作したいときだけ「解除」する方式です。TUI を多用するなら最初からこのプリセットに切り替えるか、少なくとも Ctrl+g(Locked モード)を覚えておくべきです。
3. 設定と拡張性:KDL と Wasm プラグインの本当のコスト
| 観点 | tmux | Zellij |
|---|---|---|
| 設定ファイル | 独自の .tmux.conf 構文(3.x 以降は ~/.config/tmux/tmux.conf も読む) | 構造化された KDL |
| レイアウト定義 | 外部ツール頼み(tmuxinator など) | ネイティブのレイアウトファイル |
| キー操作の論理 | prefix キー + アクションキー | モード切替(Vim 風) |
| プラグイン形態 | シェルスクリプト(TPM 管理) | WebAssembly / WASI サンドボックス |
| エコシステム規模 | 大きく成熟 | 小さく若い |
レイアウト・アズ・コード:KDL の実物
この表で日常的な影響が最も大きいのは「レイアウト定義」です。Zellij のレイアウトは、リポジトリにコミットできる KDL ファイルです。
1layout {
2 tab name="web" focus=true {
3 pane split_direction="vertical" {
4 pane command="npm" {
5 args "run" "dev"
6 }
7 pane split_direction="horizontal" {
8 pane command="npm" {
9 args "run" "test:watch"
10 }
11 pane
12 }
13 }
14 }
15 tab name="logs" {
16 pane command="docker" {
17 args "compose" "logs" "-f" "mysql"
18 }
19 }
20}あとは zellij --layout ./dev.kdl の一行で、フロントエンド・テスト・空きシェル・DB ログが同時に立ち上がります。このファイルをプロジェクトに含めておけば、新しいメンバーが clone するだけで同一のワークスペースを得られます。
tmux で同じことをするには new-session / split-window / send-keys を並べたスクリプトを書くか、tmuxinator の YAML を導入するのが一般的です。前者はペインの順序に対して脆く、後者は Ruby 依存が増える。ここが Zellij の最も実利的な優位点であり、「UI が綺麗」という話とは無関係です。
Wasm プラグイン:利点はサンドボックスであって速度ではない
Zellij の Wasm プラグイン機構は確かに最も特徴的な設計です。WASI にコンパイルできる言語なら何でも書け(Rust は一級市民で公式 SDK zellij-tile がある)、Protocol Buffers でホストと通信し、明示的な権限付与を伴うサンドボックスで動作します。
ただし、広く流布した説を訂正しておきます。Wasm プラグイン=「高性能」ではありません。
Zellij のプラグインランタイムは実は二度乗り換えています。0.41 で wasmer から wasmtime へ、0.44 で wasmi——インタプリタへ。公式リリースノートは理由を明確に書いています。プラグインに明示的なコンパイル手順とキャッシュを不要にするためであり、代償として「わずかな性能低下が生じうる」。緩和策として Cargo.toml に lto = true、strip = true、codegen-units = 1 を入れることが推奨されています。
つまり Wasm の実利はサンドボックス隔離・権限モデル・言語の自由・コンパイル不要の配布であって、生の速度ではありません。逆に tmux のプラグインは「古い」シェルスクリプトですが、TPM エコシステムの規模と成熟度は今なお Zellij を大きく上回ります。ニッチな機能が欲しくなったとき、tmux なら誰かが既に書いている可能性が高いのです。
4. セッション維持:切断、再起動、そして「復活」
開発者が最も気にする場面であり、同時に「どちらでも大丈夫」の一言で片付けられがちな論点でもあります。実際には両者の能力の境界は同じではありません。
SSH 切断:引き分け
どちらもクライアント・サーバ型なので、回線が切れても tmux attach / zellij attach で戻れます。ここに勝者はいません。
マシン再起動:Zellij がネイティブで上回る
Zellij は 0.39 から Session Resurrection(セッション復活)を内蔵しています。 セッションは既定でキャッシュディレクトリにシリアライズされ、意図的な終了でもクラッシュでも、終了済みセッションに再 attach すると再構築されます。
設計上の注目点がいくつかあります。
- シリアライズ結果は人間が読める Zellij レイアウトで、同僚に共有したり別マシンへ持ち出したりできる
- 既定ではペイン/タブ構成と各ペインで動いていたコマンドを復元し、設定次第で viewport とスクロールバックまで復元できる
- 復活したコマンドは自動実行されず、「Press ENTER to run...」の手前で止まる。
rm -rfのようなものが再起動後に自動再生されるのを防ぐ安全装置です
tmux で同等のことをするには、TPM 経由で tmux-resurrect + tmux-continuum という 2 つのサードパーティ製プラグインを入れます。
# ~/.tmux.conf
set -g @plugin 'tmux-plugins/tmux-resurrect'
set -g @plugin 'tmux-plugins/tmux-continuum'
set -g @continuum-save-interval '15' # 15 分ごとに自動保存
set -g @continuum-restore 'on' # tmux 起動時に自動復元導入後は prefix + I でプラグインを取得し、保存先は ~/.tmux/resurrect/ です。成熟していて実用的ですが、結局は自分で組み上げる外付け部品であり、標準機能ではありません。新しいマシンで Zellij は入れた時点でこの挙動を持つのに対し、tmux はこの設定一式を先に同期する必要がある、という差です。
見落とされがちな境界も一つ。どちらも既定で復元するのはレイアウトとコマンドであって、プロセスのメモリ状態ではありません。途中まで進んだビルドも、保存していない REPL セッションも、再起動後には戻りません。セッション復活が解くのは「ワークスペースの再構築」であって「プロセスの凍結」ではない——CRIU の代わりにはならない点に注意してください。
フローティングペイン:Zellij の専売特許ではない
「フローティングウィンドウは Zellij の切り札」という説明も正確ではありません。tmux には 3.2 から display-popup があります。
違いは意味論にあります。tmux の popup は表示レイヤが描く一時的なオーバーレイで、コマンドが終わるか Esc を押せば消えます。Zellij のフローティングペインは一級市民のペインで、フロートと埋め込みを行き来させ(Ctrl+p → e)、まとめて表示/非表示を切り替え(Ctrl+p → w)、ピン留めまでできます(Ctrl+p → i)。さらに Zellij には tmux にないスタックペイン(Ctrl+p → s)もあります。
「tmux しか選択肢がない」?それも違う
見知らぬマシンの上では、実は GNU Screen のほうが tmux よりプリインストール率が高いのが現実です。ほかに dtach や abduco もあります。正確な言い方は、tmux が「導入コストが最も低く、ドキュメントと経験知が最も豊富」な選択肢である、ということであって、唯一解ではありません。
5. 番外編:Zellij / tmux は herdr と併用できるか
AI 支援プログラミングが爆発的に広がるなか、Rust 製の agent multiplexer herdr の注目度が高まっています。階層は tmux より一段深く(session → workspace → tab → pane → agent)、サイドバーが各エージェントを 🔴 blocked / 🟡 working / 🔵 done / 🟢 idle の 4 状態に集約して表示し、スクリプトから叩ける CLI と socket API、さらにサーバをリモートマシンで動かす remote モードも備えます。
「もう一つの画面分割ツール」というより、herdr の価値はエージェントのライフサイクルを理解している点にあります。どのエージェントが回答待ちで止まり、どれが完了したのかを、ペインを一つずつ覗いて確かめる必要がなくなる。さらに(Claude Code 自身の resume 機能などを使って)エージェントの実際の会話を復元でき、空のペインを開き直すだけではありません。ここが通常のマルチプレクサには届かない領域です。tmux はシェルを保持できても、会話は保持できないのです。
そこでよく聞かれます。Zellij と herdr は併用できるのか?
結論:できます。そして herdr 自身が「置き換え」ではなく「補完」と位置づけています。
ここで訂正しておきたいのが、「両者は代替関係であり、入れ子にすると herdr が状態を見失う」という説です。herdr の README は tmux について「tmux は永続性とペインを与えてくれるが、エージェントが存在する前に作られた」と述べており、比較表が示すのは二者択一ではなく能力の積み上げです。Zellij 側も v0.45.1 で「SSH 経由の入れ子セッション検出」をわざわざ修正しています。入れ子は正面から想定されたシナリオなのです。
理解すべきなのは方向です。ここが「TTY の状態が遮られる」という説明の歪んでいる箇所でもあります。herdr の状態検出はプロセス名マッチング + ターミナル出力のヒューリスティクスに基づきます(公式連携のあるエージェントは socket API で意味的な状態を直接報告します)。
- herdr を Zellij/tmux のペイン内で動かす(herdr が内側):問題ありません。Zellij は herdr とエージェントの「あいだ」にはおらず、エージェントの PTY は herdr が直接保持したままなので検出に影響しません。実際のコストは prefix キーの衝突だけで、Zellij の
Ctrl+g(Locked モード)や Unlock-First プリセット、あるいは tmux の prefix 変更で解消できます。 - Zellij/tmux を herdr のペイン内で動かす(herdr が外側):問題が起きるのはこちらです。内側のマルチプレクサが間に挟まるため、herdr が見るのはエージェントの出力ではなくその再描画画面になり、出力ヒューリスティクスが狂います。プロセス名マッチングも
claudeではなくzellijを見ることになります。
AI 時代の選定方針
- 従来型の開発フロー(コードを書き、サービスを動かす):前 4 節の結論に従って Zellij か tmux を選ぶ。
- AI 駆動の開発フロー(複数エージェントを並行管理し、確認要求に随時応答する):herdr を最も外側に置くのが最も手間がかかりません。すでに作り込んだ Zellij/tmux 設定があるなら、その内側に herdr を入れる構成も問題なく機能します。
実務上の注意を 2 点。herdr は現在 v0.4.0 で pre-1.0 であり、プロトコル更新時にサーバの再起動が必要になることがあります。またライセンスは AGPL-3.0-or-later と商用ライセンスのデュアルです。クローズドな業務フローに組み込む前に、法務に一度通しておく価値があります。
6. 選定の結論
| あなたの状況 | 推奨 |
|---|---|
| 見知らぬ/古いサーバに頻繁に SSH する | tmux(導入コスト最小、知見が最も豊富) |
| リソースが極端に限られたマシン | tmux |
| Vim/Emacs/TUI のヘビーユーザー | tmux、または Zellij の Unlock-First プリセット |
| ローカル主力機・固定のクラウド開発機 | Zellij(ネイティブレイアウト + セッション復活) |
| マイクロサービスの多プロセス作業環境 | Zellij(KDL レイアウトで一発起動) |
| 再起動後に作業環境を自動復元したい | Zellij は標準機能/tmux は resurrect + continuum が必要 |
| 複数の AI コーディングエージェントを並行管理 | herdr(単体でも、上記との入れ子でも可) |
tmux は今なお、どんな劣悪な環境でも手を差し伸べてくれる頼れるベテランです。Zellij は認知負荷を大きく下げるモダンなワークステーション。そして herdr は、前者二つが生まれた時点では存在しなかった層——エージェントの状態認識——を埋めています。
絶対的な勝者はなく、いまの自分のワークフローに最も合う道具があるだけです。すでに tmux で完成された筋肉記憶があるなら、「モダンだから」という理由で移行する必要はありません。ただし新しい開発マシンを構築中なら、いまは確かに Zellij を試す良いタイミングです。

Comments
Comments (0)