AI コーディングエージェントを並列で走らせると、詰まる場所は 2 つに絞られます。1 つは「どれが入力待ちか分からない」こと。もう 1 つは「PC を閉じたら止まる」ことです。前者は cmux のようなターミナルアプリが解き、後者は昔から tmux の領分でした。両方をいっぺんに欲しくなると、これまでは組み合わせるしかありませんでした。
herdr は、その 2 つを 1 つのツールで引き受けます。tmux と同じくターミナルの中で動く単一バイナリでありながら、各ペインのエージェントが作業中なのか人間を待っているのかを自動で判定して表示します。GitHub のスターは 3 万を超え、tmux 代替の文脈で名前を見る機会が増えました。この記事では、herdr の設計と使い方、そして tmux・cmux・Orca との使い分けを整理します。
結論｜3 行で押さえる herdr
先に要点だけ整理します。
- tmux 互換の操作感のまま、ペインごとのエージェントの状態が見えるターミナルマルチプレクサです。プレフィックスは
Ctrl + bで、デタッチとアタッチも期待どおりに動きます - バックグラウンドのサーバーがセッションを保持するため、蓋を閉じてもネットワークが切れてもエージェントは走り続けます。SSH 越しに入り直せば続きから見られます
- エージェント自身が叩ける CLI とソケット API を持ちます。ペインの分割・コマンド実行・出力の読み取り・完了待機まで、画面を読む処理を自作せずに行えます
導入は curl -fsSL https://herdr.dev/install.sh | sh の 1 行、または brew install herdr です。ライセンスは Apache License 2.0 で、Electron を使わない単一の Rust バイナリとして動きます。
herdr とは｜「エージェントが住むランタイム」という位置づけ
herdr は、開発元が「コーディングエージェントが動くランタイム」と説明しているツールです。実体は Rust で書かれたターミナルマルチプレクサで、ペイン・タブ・ワークスペースという構成も、Ctrl + b のプレフィックスも、tmux や Zellij を使ってきた人ならそのまま馴染みます。マウスでのペイン選択・境界のドラッグ・右クリックメニューからの分割にも対応していて、マルチプレクサ初心者でも入りやすい作りです。
tmux と決定的に違うのは、ペインの中で何が動いているかをツールが理解している点です。従来のマルチプレクサにとってペインの中身はただの文字列でした。herdr は前景プロセスを見てエージェントを特定し、その状態をサイドバーに出します。「pane 3 で Claude Code が承認を待っている」という情報が、ペインを覗きに行かなくても分かるわけです。
エージェントの並列運用でボトルネックになるのは、モデルの速度ではなく人間が呼ばれたことに気づくまでの時間です。この点は cmux と同じ問題設定で、herdr はそれをターミナルアプリではなくマルチプレクサの層で解いています。
状態検知の仕組み｜フック優先、なければ画面を読む
herdr の中核は状態判定です。ペインの状態は working (作業中)・blocked (入力待ち)・idle (待機)・done (完了) に分類されます。判定は 2 段構えで動きます。
まず、各ペインの前景プロセスを検出してエージェントを特定します。そのうえで、状態を報告する権限をペインごとに 1 つだけ持たせます。公式統合をインストールしてあるエージェントは、ライフサイクルフックからの自己申告が最優先で使われます。フックがないエージェントについては、画面下部のスナップショットを TOML のマニフェストと照合して分類します。
# Claude Code の統合を入れる (フック経由の状態報告が有効になる)
herdr integration install claude
# 入っている統合の一覧と状態を確認する
herdr integration status4 つの状態のうち、idle と done の違いは進捗ではありません。どちらも入力を受け付けられる同じ状態で、分かれ目は人が見たかどうかです。フォーカスされた画面でタブが見られていれば idle、見られないまま裏で作業が終わったものが done になります。CLI から読み取っても既読にはなりません。ほかに unknown もあり、エージェントはいるが分類しきれない状態を表します。完了の証明ではないので、待ちの条件に使うときは注意してください。この定義は herdr --skill の出力に書かれています。
このマニフェストは自動で更新され、エージェント側の UI が変わってもバイナリを入れ替える必要はありません。また、blocked を立てる条件が「承認・質問・権限の UI が実際に画面に見えているとき」に限定されています。作業中のログが少し止まっただけで入力待ちに見えてしまう誤判定を避ける設計で、状態表示を信用して巡回をやめられるかどうかは、この厳しさに懸かっています。
要点
状態表示の価値は、当たっている割合ではなく「見に行かなくて済むと信じられるか」で決まります。herdr がフックからの自己申告を最優先し、画面判定を補助に回しているのはそのためです。
対応エージェントは Claude Code・Codex・Cursor Agent CLI・GitHub Copilot CLI・OpenCode・Grok CLI・Amp・Qwen Code・Droid・Devin CLI・Kiro CLI・Antigravity CLI など 20 種類前後です。Gemini CLI と Cline については、検出はされるが検証が十分でないと公式に明記されています。一覧にないコマンドでも、マルチプレクサとしての機能はそのまま使えます。
常駐サーバー｜蓋を閉じてもエージェントは止まらない
herdr のもう 1 つの柱がセッションの永続化です。ターミナルの UI とセッションの実体が分離していて、バックグラウンドのサーバーがペインを保持します。デタッチしても、ネットワークが切れても、エージェントは走り続けます。マシンを再起動した場合もレイアウトが復元されます。
# 作業ディレクトリで起動する
herdr
# デタッチ (Ctrl + b を押してから q)
# 戻るときは同じコマンドで入り直す
herdrこの性質が効くのは、実行に時間のかかるタスクを任せているときです。長いリファクタリングやテストの修正をエージェントに投げたまま移動したい、退勤したい、といった場面で、ローカルのアプリに縛られなくなります。SSH で入った先で herdr を起動しておけば、手元のマシンを変えても同じセッションに戻れます。GUI を必要としない設計のため、復帰できる経路が「キーボードのあるマシン」まで広がるわけです。
コツ
リモートのサーバーに herdr を入れて、そこでエージェントを走らせる構成にすると、手元のマシンのスリープや再起動を気にせず作業を続けられます。ビルドが重いプロジェクトほど効果が出ます。
ソケット API｜エージェントがターミナルを操作する
herdr はローカルの Unix ソケットに API を公開しており、herdr CLI から同じ操作を呼べます。用途に応じて 3 つの層が用意されています。ペインの中で動くエージェントにはエージェント向けのスキル、シェルスクリプトからは CLI ラッパー、独自ツールからはソケット API を直接、という切り分けです。
# ワークスペースとタブを用意する
herdr workspace create --cwd ~/project --label api
herdr tab create --label logs
# ペインを分割してコマンドを走らせる
herdr pane split w1:p1 --direction right
herdr pane run w1:p2 "npm test"
# 出力の末尾だけを読む
herdr pane read w1:p2 --source recent --lines 50
# 指定ペインのエージェントが終わるまで待つ
herdr agent wait w1:p1 --until done注目したいのは herdr pane read と herdr agent wait です。tmux で同じことをやろうとすると capture-pane の出力を自前で整形し、終了判定も自作することになります。出力の読み取りと完了待機が最初から API になっている点が、herdr を自動化の土台として使いやすくしています。
ソケットのパスは既定で ~/.config/herdr/herdr.sock、名前付きセッションでは ~/.config/herdr/sessions/<name>/herdr.sock です。同じディレクトリにはクライアント用のソケットも並ぶので、接続先を書くときは名前まで含めて指定してください。HERDR_SOCKET_PATH、HERDR_SESSION の順に環境変数が優先されます。使えるコマンドの一覧は herdr api schema で取得できるため、エージェントに渡す説明を手で書く必要もありません。
全体の構造を図にすると次のようになります。
flowchart LR
subgraph server["herdr サーバー (常駐)"]
Panes["ワークスペース / タブ / ペイン"]
State["状態判定 (working / blocked / idle / done)"]
end
Agent["Claude Code などのエージェント"] -- "herdr CLI" --> Socket["Unix ソケット API"]
Socket --> Panes
Panes --> State
State -- "サイドバーに表示" --> Client["ターミナル (ローカル / SSH)"]
Client -- "デタッチしても実行は継続" --> server
Human["人間"] -- "呼ばれたときだけ見る" --> Clientなお、エージェントにターミナル操作の権限を渡す点は cmux と共通の論点です。通知や状態表示は低リスクですが、任意のコマンドを走らせる pane run まで許すかは、エージェント側の権限設定とセットで線を引いてください。考え方は Claude Code の permissions 設定 の整理がそのまま使えます。
エージェント同士にペアプロさせる
herdr がおもしろいのは、この API がエージェント向けにも開かれていることです。agent 系のコマンドを使うと、あるペインのエージェントが別のペインにエージェントを立ち上げ、質問を投げ、返答を読み取れます。
# レビュー役として別ペインに Codex を立ち上げる
herdr pane split w1:p1 --direction right
herdr agent start reviewer --kind codex --pane w1:p2
# プロンプトを送り、応答が落ち着くまで待つ
herdr agent prompt reviewer "この差分の懸念点を 3 つ挙げてください" --wait --until idle --timeout 300
# 返ってきた内容を読み取る
herdr agent read reviewer --source recent --lines 80agent read は直近の出力・表示中の画面・検出に使った領域を切り替えて読めます。対話 UI の操作が必要な場面には agent send-keys があり、esc や up、ctrl+c といったキーも送れます。
実際に隣のペインへ話しかけると、こう動きます。左が指示を出した Claude Code、右が話しかけられた Codex です。
手前で 1 つ用意しておくと安定するのが、エージェントに herdr の使い方を教えることです。herdr 管理下のペインには環境変数が注入されるので、エージェント向けの規約は CLI から取り出せます。
# herdr の中にいるかを確かめる (skill 冒頭の作法)
test "${HERDR_ENV:-}" = 1
# エージェントに読ませる skill を出力する
herdr --skillこれを渡さないと、エージェントは端末の画面を自前で読みにいく回り道を選びがちです。skill には「herdr の中にいるときだけ制御コマンドを出す」「ID は推測せず JSON から読む」といった作法まで書かれているので、最初に読ませておくと事故が減ります。
これで組めるのが、エージェント同士のペアプロやレビューです。実装役の Claude Code が書いたら、レビュー役の Codex に差分を渡して指摘をもらい、その返答を読んで直す。従来もターミナル操作を自動化すれば似たことはできましたが、画面が想定どおり出ているかを毎回自前で確かめる必要がありました。herdr は状態の問い合わせと待機を API 側に持っているため、prompt して wait して read する、という素直な形に落ちます。
コツ
同じ作業を複数のモデルに並べるより、実装役とレビュー役のように役割で分けたほうが構成としては素直です。指摘の観点が重ならず、待機の時間も実装側の作業と重ねられます。
ただし、やっていることの実態は各エージェントの対話 UI へのテキスト送信と画面の読み取りです。エージェント側が UI を変えれば影響を受けますし、当然ながらエージェントの利用料は本数分かかります。常時ペアで回すより、要所でレビュー役を呼ぶ使い方から試すのが無難です。
動かして分かった勘所
ドキュメントを読んだだけでは踏みやすい段差がいくつかあります。手元で 2 つのエージェントを会話させてみて、効いたのは次の 5 点でした。
--wait は返答本文を返しません。 返ってくるのは状態が落ち着いた事実だけなので、中身は agent read で別に取りにいきます。しかも待つ単位はターンではなく状態です。相手がすでに working なら、その作業の完了で待ちが満たされてしまうため、投げた質問の答えとは限りません。
待ちが無限にならない仕組みも入っています。 相手が承認待ちのときは入力を送らずに agent_blocked で拒否され、送信は通ったのに 5 秒以内に状態が動かなければ agent_prompt_stalled が返ります。ただし --timeout を付けない場合、落ち着くまでの待ち自体は無期限です。自動化に組み込むならミリ秒で明示してください。
日本語のログを読むなら --source recent-unwrapped です。 既定の recent は画面上の折り返しがそのまま残るため、全角の会話ログだと行の途中で切れて読みにくくなります。
手で起動したエージェントには名前がありません。 agent start <name> で立てたときだけ名前で呼べます。人間が自分でコマンドを打って起動したペインは、herdr agent list が返す pane_id で狙います。ID は推測せず JSON から読むのが確実です。
背景で相棒を立てるときは 2 つのオプションを添えます。 --no-focus を付けないと画面が新しいペインに飛んでユーザーの作業を邪魔しますし、--cwd "$PWD" を渡さないと相手が別のディレクトリで立ち上がります。
# 背景に相棒を立て、ID は一覧から読み取り、日本語ログを折り返しなしで回収する
herdr pane split --current --direction right --cwd "$PWD" --no-focus
herdr agent list
herdr agent read w1:p2 --source recent-unwrapped --lines 80 --format textなお、TUI で動くエージェントの過去ログは --lines を増やしても遡れません。代替スクリーンから流れた行はスクロールバックに残らないためです。長い回答を確実に受け取りたいときは、相手に「結果をファイルへ書いてパスだけ返して」と頼み、そのファイルを読むほうが安定します。
tmux・Zellij との違い
公式の比較でも、herdr は自らを「ランタイム + クライアント」と位置づけ、tmux や Zellij の「マルチプレクサ」とは区別しています。違いを整理すると次のとおりです。
| 観点 | tmux / Zellij | herdr |
|---|---|---|
| 既存ターミナル内で動作 | 動く | 動く |
| セッション永続化 | サーバー常駐で対応 | サーバー常駐で対応 |
| エージェントの状態表示 | なし (自作すれば可能) | working / blocked / idle / done を自動判定 |
| エージェント検出 | なし | 前景プロセスから 20 種類前後を自動検出 |
| API | send-keys などのスクリプト | 読み取り・送信・待機・分割・接続の API |
| プラグイン | tmux は tpm、Zellij は WASM | マーケットプレイス経由で導入 |
置き換えのハードルは高くありません。プレフィックスもデタッチの挙動も揃えてあるため、tmux の設定ファイルを移植しなくても初日から同じ感覚で使えます。逆に言えば、エージェントを走らせないターミナル作業だけなら、乗り換えて得られるものはほとんどありません。判断の分かれ目は、ペインの中でエージェントを回しているかどうかです。
Orca を使っているなら｜置き換えではなく足りない場所が違う
FIXIT では現在、エージェントの並列運用に Orca を使うメンバーが多く、herdr が話題になったときも最初に出たのは「Orca でも同じことができるのでは」という反応でした。結論から言うと、置き換えの関係にはなりません。重なっているのは状態の可視化だけで、それぞれが埋めている穴が違います。
| 観点 | herdr | cmux | Orca |
|---|---|---|---|
| 形態 | ターミナル内で動く単一バイナリ | macOS ネイティブのターミナル | デスクトップアプリ (ADE) |
| 対応 OS | macOS・Linux・Windows | macOS のみ | macOS・Linux・Windows |
| 環境の隔離 | しない | しない | タスクごとに Git worktree を自動作成 |
| UI を閉じたとき | サーバーがセッションを保持 | アプリ起動中のみ | アプリ中心 (SSH リモート実行あり) |
| 状態の可視化 | 4 状態を自動判定 | 通知リングで入力待ちを表示 | エージェントごとの進捗を表示 |
| 内蔵ブラウザ | なし (プラグインで拡張) | あり (スクリプト API 付き) | あり (Design Mode) |
| 得意な場面 | リモート・長時間の常駐 | 手元の Mac での並列管制 | 環境ごと束ねた比較検証 |
Orca が引き受けているのは環境のほうです。タスクごとに Git worktree を切って作業を隔離し、同じ仕様を複数のエージェントに投げて差分を見比べ、良かったものをマージする。ブランチの取り回しと比較検証まで含めて 1 つのアプリに収まっているのが強みで、日中の実装作業はこれで足ります。
herdr が引き受けているのはセッションのほうです。環境の隔離にも差分比較にも関与せず、ターミナルを常駐させて状態を見せることに絞っています。Orca を使っていて足りなくなるのは、GUI を開いていられない時間帯です。ノート PC を閉じて移動する、リモートのサーバーで重いビルドを回したまま帰る、翌朝に別のマシンから続きを見る。このあたりは herdr の常駐サーバーと SSH アタッチの領分になります。
現実的な組み合わせは、手元の実装と比較検証は Orca、サーバーに寄せる長時間の作業は herdr です。Orca の内蔵ターミナルの中で herdr を動かすこともできるので、どちらかに寄せる必要はありません。逆に、herdr だけで並列運用しようとすると、worktree を自分で切らないとエージェント同士がファイルを踏み合う点に注意してください。
cmux との比較では、動く場所が最大の違いです。cmux は普段使いのターミナルをアプリごと置き換える形なので macOS でしか使えません。herdr は既存のターミナルの中で動くため、Ghostty でも iTerm でも Windows Terminal でも同じものが動きます。チームで OS が混在しているなら、揃えやすいのは herdr です。
導入と最初の 30 分
導入は 1 行です。macOS と Linux はインストールスクリプト、Windows は PowerShell スクリプトが用意されています。
# macOS / Linux
curl -fsSL https://herdr.dev/install.sh | sh
# Homebrew を使う場合
brew install herdr
# mise を使う場合
mise use -g herdr入れたあとは、作業ディレクトリで herdr と打てば起動します。最初にやることは 3 つです。使っているエージェントの統合を入れる、ペインを 2 つに割って別々のエージェントを走らせる、そしてデタッチして戻ってみる。この 3 つで、herdr が何を解決するツールなのかはひととおり体験できます。
cd ~/project
herdr
# herdr の中で統合をインストールする
herdr integration install claude
herdr integration install codexひとつだけ、最初に踏みやすい段差があります。引数なしの herdr はヘルプではなく TUI の起動とアタッチです。さらに、変更を伴うコマンドを引数を省いて覗こうとすると、既定値のまま実行されてしまいます。使い方を調べるときは herdr --help から入り、以降は herdr agent や herdr pane のようにサブコマンドを省いてグループを表示するのが安全です。
Claude Code 側の初期設定がまだの場合は、Claude Code セットアップガイド を先に済ませておくとつまずきません。通知の自動化まで踏み込むなら、Claude Code の hooks 実用パターン集 の考え方をそのまま流用できます。
導入前に押さえておく制約
万能なツールではありません。判断の前に見ておきたい点を挙げます。
まず、herdr は環境を隔離しません。ペインを分けても同じディレクトリで作業していれば、複数のエージェントが同じファイルを書き換えて衝突します。並列で回すなら Git worktree を自分で切るか、Orca のように隔離まで面倒を見るツールを併用してください。
次に、状態検知はエージェント側の実装に依存します。統合が用意されているエージェントは自己申告で正確ですが、それ以外は画面の見た目からの推定です。エージェントが UI を変えればマニフェストの更新を待つ期間が生じます。状態表示に運用を全面的に寄せる前に、手元で数日試して判定の精度を見ておくのが安全です。
注意
ソケット API
はエージェントに任意コマンドの実行権限を渡す入り口にもなります。状態の読み取りや通知は低リスクですが、pane run
を許すかどうかは、エージェント側のサンドボックスや権限設定と合わせて設計してください。
そして、まだ新しいプロジェクトです。急速に伸びている一方で仕様の変化も早く、社内標準として全員に配るより、エージェントを日常的に並列運用している人から順に試すのが向いています。
FIXITうちは Orca を使ってる人が多いよね。これも同じことできるんじゃないの？
Hayate重なるのは状態の可視化だけです。Orca は worktree で環境を隔離するところが本体なので。
FIXITじゃあ herdr のほうが得意なのは？
Hayate常駐です。蓋を閉じても走り続けて、SSH で入り直せば戻れます。GUI が要りません。
FIXITえっ、じゃあ両方入れることになるの？
Hayate使い分けの目安は場所です。手元は Orca のまま、サーバーに寄せる作業だけ herdr でいいです。
まとめ｜マルチプレクサ側でエージェントを面倒見る
herdr の設計は割り切りが明確です。エディタもブラウザも抱え込まず、ターミナルマルチプレクサという枯れた形のまま、「ペインの中身がエージェントである」という前提だけを足しました。その結果、tmux から乗り換えるコストがほぼゼロで、常駐と状態表示と API という現代的な要求を満たしています。
エージェントを 2 本以上並べて回し、しかもそれを手元の GUI に縛られずに走らせたい。この条件に当てはまるなら、試す価値があります。まずはインストールして統合を 1 つ入れ、ペインを 2 つ割って走らせたままデタッチしてみてください。戻ってきたときに作業が進んでいる感覚が、このツールの中心的な価値です。
FIXIT は AI 駆動開発のクリエイティブスタジオとして、エージェントの並列運用やツールチェーンの設計を実プロジェクトで磨いています。チームへの導入を検討している方は AI 開発ツール導入支援 をご覧ください。