以前、tmux の代替を探して、dtach、abduco、zmxなどを比較しました。 そのときは、100並列のセッション保持という観点でtmuxの効率が目立つ結果になりました。
最近、Herdr というツールを見つけました。 公式サイトでは「Agent multiplexer」と説明されています。つまり、複数のAIエージェントを1つのターミナルから管理するためのターミナルマルチプレクサです。
では、Herdrはtmuxと同じ用途で比べるべきツールなのでしょうか。 実際に入れて、メモリ使用量と機能の違いを確認しました。
結論
先に結論を書くと、同じセッション保持だけで比較するとtmuxのほうが小さく収まります。
ただし、それだけでHerdrを評価すると見誤ります。 Herdrはtmuxの単純な置き換えではなく、AIエージェント向けの状態管理やAPIを持った別カテゴリのツールとして見るべきです。
ざっくり分けるとこうです。
| 用途 | 選ぶもの |
|---|---|
| 100並列プロセスを最小構成で保持したい | tmux |
| SSH先でセッションを残したい | tmuxまたはHerdr |
| 複数のClaude Code / Codex / OpenCodeを状態付きで管理したい | Herdr |
| エージェントをCLI/APIから読んだり待ったりしたい | Herdr |
Herdrとは何か
Herdrは、既存のターミナル内で動くAIエージェント向けマルチプレクサです。 マルチプレクサとは、1つの端末画面の中で複数の仮想端末やセッションを扱う仕組みです。
Herdr公式の比較ページ では、tmuxやZellijとの違いを次のように説明しています。
- 既存のターミナル内で動く
- 永続的なPTYセッションを持つ
- SSH経由で再接続できる
- agent stateを扱える
- CLIとSocket APIで操作できる
ここで重要なのは、agent stateです。 これは、エージェントが「作業中」「ブロック中」「完了」「待機中」のような状態を持つことです。
tmuxは端末を残せますが、その端末の中のClaude CodeやCodexが今どんな状態かは知りません。 Herdrはそこを見に行くツールです。
比較方法
今回は「前回の記事と同じ方向」で見ます。 つまり、100個の小さなセッションを立てたときに、管理ツール自体がどれくらいメモリを使うかです。
環境は以下です。
| 項目 | 値 |
|---|---|
| OS | macOS arm64 |
| tmux | 3.6a |
| Herdr | 0.7.1 |
| 実行内容 | sleep 600 |
| セッション数 | 1 / 10 / 100 |
Herdrは公式のインストール手順 に従い、GitHub ReleasesからmacOS arm64向けバイナリを一時ディレクトリに置いて測定しました。 Homebrew環境にはインストールせず、検証用に隔離しています。
実測結果
結果はこちらです。
| セッション数 | tmux RSS | Herdr RSS | 差 |
|---|---|---|---|
| 1 | 3.4MB | 19.1MB | Herdr 約5.6倍 |
| 10 | 3.8MB | 22.6MB | Herdr 約5.9倍 |
| 100 | 4.5MB | 56.3MB | Herdr 約12.6倍 |
RSSはResident Set Sizeの略で、プロセスが実メモリ上で使っている量の目安です。 厳密なベンチマークというより、同じ環境での実用的な比較として見てください。
作成時間も測りました。
| セッション数 | tmux | Herdr |
|---|---|---|
| 1 | 0.014秒 | 0.142秒 |
| 10 | 0.077秒 | +0.123秒 |
| 100 | 0.662秒 | +1.350秒 |
この測定では、tmuxのほうが短い時間で作成できました。 Herdrも実用上は十分速いですが、セッション保持だけを測ると差が出ます。
バイナリサイズも差があります。
| ツール | バイナリサイズ |
|---|---|
| tmux | 941KB |
| Herdr | 14.4MB |
Herdrは単なるdetachツールではなく、UI、状態検出、API、連携機能を持つため、そのぶん大きくなっています。
測定に使ったコマンド
tmux側は、専用ソケット名を使って既存セッションと混ざらないようにしました。 以下は100セッションの例です。
|
|
Herdr側は、HOMEとHERDR_SESSIONを一時ディレクトリに向けて隔離しました。
HerdrのCLIはJSONを返すので、作ったpane IDに対してpane runでコマンドを流しています。
|
|
jqはJSONを読むためのコマンドラインツールです。
HerdrのCLIはスクリプトから扱いやすい形で結果を返すため、こういう自動化はtmuxより書きやすいです。
なぜtmuxは小さく収まるのか
tmuxは、成熟したC製のターミナルマルチプレクサです。 やることが明確です。
- セッションを持つ
- ペインを持つ
- 入出力をつなぐ
- detach / attachする
今回のように100個のsleepを保持するだけなら、tmuxの設計はとても合っています。
セッション数を増やしても、tmuxサーバのメモリ増加は小さく済みます。
前回の比較でも、dtachやabducoは1セッションあたりの構成は小さいものの、セッションごとにプロセスが増えるため、100並列ではtmuxの共有サーバ方式が有利でした。 今回も同じ傾向です。 大量セッションの保持だけなら、tmuxは適した選択肢です。
Herdrは何にリソースを使っているのか
Herdrは、単に端末を保持するだけでなく、エージェントの状態を扱います。 たとえば、CLI reference を見ると、次のような操作があります。
|
|
これはtmuxでも一部は頑張ればできます。 ただし、tmuxでは「どのペインがAIエージェントか」「今ブロック中か」「完了したか」を自前で判定する必要があります。
Herdrはその判定と操作面を最初から持っています。 ここが価値です。
tmuxとHerdrは競合というより層が違う
最初は「tmuxの代替として同じ土俵で比べられるのか?」という見方をしました。 しかし、使いどころは少し違います。
flowchart TB
subgraph tmux["tmux"]
T1[端末セッション]
T2[ペイン]
T3[detach / attach]
end
subgraph herdr["Herdr"]
H1[端末セッション]
H2[ペイン]
H3[detach / attach]
H4[agent state]
H5[CLI / Socket API]
H6[agent wait / read / send]
end
tmuxは汎用の端末管理です。 HerdrはAIエージェントを束ねるための端末管理です。
なので、比較表はこうなります。
| 観点 | tmux | Herdr |
|---|---|---|
| 100並列メモリ | 小さく収まる | 状態管理込みで増える |
| 起動/作成速度 | 短い | 十分短いが追加処理がある |
| セッション永続化 | 強い | 強い |
| SSH再接続 | 強い | 強い |
| 汎用端末管理 | 強い | できる |
| エージェント状態 | なし | あり |
| CLI/API制御 | 低レベル | 高レベル |
| AIエージェント運用 | 自作が必要 | 目的に合っている |
どちらを使うべきか
自分ならこう使い分けます。
tmuxを使うケース
- SSH先で作業を残したい
- 100並列の小さなプロセスを保持したい
- 管理プロセスのメモリを抑えたい
- 既存のtmux設定やキーバインドで十分
- エージェント状態は自分で見ればよい
特に、単にopencodeやclaudeをたくさん起動しておくだけなら、tmuxで十分です。
Herdrを使うケース
- 複数のAIエージェントを同時に動かす
- blocked / working / doneを一覧したい
- エージェントの出力をCLIから読みたい
- エージェントに入力を送ったり、完了まで待ったりしたい
- スマホやSSH越しでも状態を追いたい
- Claude Code、Codex、OpenCodeなどをまとめたい
ここまで来ると、tmuxの上に自前スクリプトを積むより、Herdrを試す価値があります。
まとめ
Herdrをtmuxの単純な代替として見ると、セッション保持だけの測定ではtmuxのほうが小さく収まりました。
100セッションでは、tmuxが約4.5MB、Herdrが約56MBでした。 この数字だけを見ると、tmuxは今でも効率のよいターミナルマルチプレクサです。
一方で、Herdrは単なるtmux代替ではありません。 AIエージェントの状態を見て、読み、待ち、操作するためのランタイムです。
なので結論はこうです。
- セッション保持だけならtmux
- AIエージェント管理まで含めるならHerdr
- 「tmuxを置き換える」より「AI用の運用レイヤーとして足す」ほうが自然
自分の用途では、普段のセッション管理はまだtmuxです。 ただ、AIエージェントを大量に走らせて、状態をまとめて見たい場面ではHerdrを試す価値があります。