コーディングエージェントを4つ、別々のペインで走らせているとする。仕様変更のリファクタを1つ、テスト書きを1つ、ログ調査を1つ、依存の更新を1つ。少し目を離してSlackに返信して戻ってくると、画面の前でひとつ問いが浮かぶ。「今、どれが俺の返事を待って止まってる?」。結局あなたはペインを順番にスクロールして、Do you want to proceed? (y/n) で固まっているやつを探すことになる。

並列でAIを回すほど、詰まるのは計算資源ではなく人間の注意になる。この一点を正面から設計に据えたのが、7月に GitHub トレンドへ上がってきた herdr だ。作者は ogulcancelik、Rust製の単一バイナリで、最新は v0.7.5(2026-07-21)。日本語での紹介はまだほとんど無いので、一次ソースを突き合わせて要点を整理しておく。

tmuxの上位互換ではなく、「エージェント」を一級市民にした端末

herdr自身は「ターミナル多重化ツール(multiplexer)」を名乗る。ペインを分割し、セッションをデタッチして後から再アタッチできる。SSH越しでも生き残り、ターミナルを閉じても走り続ける。ここまでは tmux や zellij と同じで、公式ドキュメントも「detach/reattach は tmux/zellij と同じ流儀」と認めている。マウス操作を第一級にして、キーバインドを覚えなくても始められる点はUXの工夫だが、本質ではない。

本質は、herdr が画面の中身を「ただのバイト列が流れる端末」ではなく、状態を持ったエージェントとして扱うところにある。README によれば、各エージェントの状態を blocked(入力待ちで止まっている)/ working(処理中)/ completed(完了)としてサイドバーに表示する。冒頭の「どれが待ってる?」に、スクロールではなく一覧で答えるということだ。人間の役割が「実装する人」から「複数エージェントの交通整理をする人」へ寄っていく流れに、UIを合わせにきている。

導入は用途に応じて選べる。手元のmacOS/Linuxならワンライナーが早い。

# インストール(いずれか一つ)
curl -fsSL https://herdr.dev/install.sh | sh
brew install herdr
mise use -g herdr

# 起動(プロジェクトのルートで)
herdr

起動後は tmux 流のプレフィックスキー(既定は ctrl+b)に続けて q でデタッチ、herdr を再実行すれば元のセッションに戻る。claude や codex は名前で検出でき、herdr integration install claude のように統合を入れられる(agent guideで確認)。

エージェントがエージェントを起動する、というもう一段

tmux にもスクリプト用のインターフェイスはある。send-keys でキー入力を流し込むこともできる。ではherdrの何が新しいのか。差分は、エージェントを操作するためのCLI/ソケットAPIが最初から用意されていることにある。リポジトリの SKILL.md には、エージェント自身が別のエージェントを立ち上げて指示を出すための一連のコマンドが並んでいる。

# 隣に新しいペインを作り、そこでエージェントを起動する
herdr pane split --current --direction right --cwd "$PWD" --no-focus
herdr agent start reviewer --kind <type> --pane <id>

# サブエージェントに仕事を投げ、"入力待ち"になるまで待つ
herdr agent prompt reviewer "このdiffをレビューして" --wait --timeout 120000
herdr agent wait reviewer --until blocked --timeout 120000

# 出力を読む・状態を取る・キーを送る
herdr agent read reviewer --source recent-unwrapped --lines 120
herdr agent get reviewer
herdr agent send-keys reviewer esc

応答はすべて JSON で返り、w1:p1(ワークスペース修飾されたペインID)のような識別子を次の操作に使い回す。ここで効いてくるのが agent wait --until blocked だ。tmux で同じことをやろうとすると、ペインの出力を自分でポーリングして「入力待ちらしき文字列」を正規表現で拾う、という手作りの監視ループを書く羽目になる。herdr はその「エージェントが今どの状態か」をAPIの一級概念にしているので、待ち合わせをコマンド一発で表現できる。オーケストレータ役のエージェントが、レビュー役・テスト役のサブエージェントを起こして、それぞれが詰まるまで待ってから次に進む、という再帰的な構成が素直に書ける。

状態検出はヒューリスティックだ、という但し書き

ここは冷静に見ておきたい。blocked かどうかの判定は、結局のところ各エージェントCLIの画面出力を観察して「入力待ちっぽい」と推測している。つまり検出は本質的にヒューリスティックで、エージェント側のCLIが表示を変えれば当たり外れが出る。

その脆さは、herdr自身の変更履歴に痕跡として残っている。v0.7.5 では、ラッパー越しに動くエージェントでも正しく画面検出できるように HERDR_AGENT=<agent> という前景プロセスのヒントを macOS で受け付けるようになり、agent prompt の待機は状態変化が5秒間ないと無限に待たず agent_prompt_stalled を返すよう変わった。どちらも「素直に状態を読み切れないケースがある」ことの裏返しだ。プロダクションで無人運用に振る前に、自分の使うエージェントで wait --until blocked が本当に信頼できるかは、手元で確かめる価値がある。

もう一点、運用者として引っかかるのは権限の広がりだ。エージェントがペインを割り、別のエージェントを起動し、プロンプトまで送れるということは、スループットと同時に「暴走したときの被害範囲」も掛け算で広がるということでもある。エージェントのスキルに悪意あるコードが混じるリスクや、サンドボックス化の議論と地続きの話で、herdr agent start を無人ループに組み込むなら、その手前に承認や隔離の層を挟む前提で考えたい。

で、いつ使うのか

一人で1つのエージェントとペアを組んでいる間は、tmux でも zellij でも困らない。herdr が効いてくるのは、3つ、5つとエージェントを並走させ始めて、「どれが自分を待っているか」を探すこと自体がボトルネックになってきたときだ。その段階に来ている人にとって、状態表示のサイドバーと agent wait は、いま自作のスクリプトで埋めている隙間そのものを埋めてくれる。

逆に、まだ手動で1つずつ回している段階なら、無理に足すツールではない。導入コストは低い(単一バイナリ、1行インストール)ので、並列運用に踏み込むタイミングで思い出せばいい。まずは herdr を起動して claude を1枚立て、herdr agent list が何を返すかを眺めるところからで十分だ。ここが手作りポーリングの卒業ラインになるかどうか、しばらく触って見極めたい。