Fragments of verbose memory

冗長な記憶の断片 - Web技術のメモをほぼ毎日更新

Jul 1, 2026 - 日記

Herdr性能比較: tmuxとは用途が違うAIエージェント管理ツール

Herdr性能比較: tmuxとは用途が違うAIエージェント管理ツール

以前、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セッションの例です。

1
2
3
4
5
6
7
for i in $(seq 0 99); do
  tmux -L hb100 new-session -d -s "bench-$i" "sleep 600"
done

ps -axo pid=,ppid=,rss=,comm=,command= | grep "tmux -L hb100"

tmux -L hb100 kill-server

Herdr側は、HOMEHERDR_SESSIONを一時ディレクトリに向けて隔離しました。 HerdrのCLIはJSONを返すので、作ったpane IDに対してpane runでコマンドを流しています。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
export HOME=/tmp/hb2/home
export HERDR_SESSION=b

herdr server &
sleep 1

for i in $(seq 0 99); do
  pane_id=$(
    herdr workspace create \
      --cwd "$PWD" \
      --label "bench-$i" \
      --no-focus \
    | jq -r '.result.root_pane.pane_id'
  )

  herdr pane run "$pane_id" "sleep 600"
done

ps -axo pid=,ppid=,rss=,comm=,command= | grep "herdr.*server"

herdr server stop

jqはJSONを読むためのコマンドラインツールです。 HerdrのCLIはスクリプトから扱いやすい形で結果を返すため、こういう自動化はtmuxより書きやすいです。

なぜtmuxは小さく収まるのか

tmuxは、成熟したC製のターミナルマルチプレクサです。 やることが明確です。

  • セッションを持つ
  • ペインを持つ
  • 入出力をつなぐ
  • detach / attachする

今回のように100個のsleepを保持するだけなら、tmuxの設計はとても合っています。 セッション数を増やしても、tmuxサーバのメモリ増加は小さく済みます。

前回の比較でも、dtachやabducoは1セッションあたりの構成は小さいものの、セッションごとにプロセスが増えるため、100並列ではtmuxの共有サーバ方式が有利でした。 今回も同じ傾向です。 大量セッションの保持だけなら、tmuxは適した選択肢です。

Herdrは何にリソースを使っているのか

Herdrは、単に端末を保持するだけでなく、エージェントの状態を扱います。 たとえば、CLI reference を見ると、次のような操作があります。

1
2
3
4
5
herdr agent list
herdr agent read <target> --source recent-unwrapped --lines 120
herdr agent send <target> "次にこれをやって"
herdr agent wait <target> --status blocked --timeout 60000
herdr pane run <pane_id> "just test"

これは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設定やキーバインドで十分
  • エージェント状態は自分で見ればよい

特に、単にopencodeclaudeをたくさん起動しておくだけなら、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を試す価値があります。

参考リンク