「Claude Codeを3つ、Codexを1つ、別プロジェクトでDroidを1つ——気づけばターミナルのタブが増えすぎて、どのエージェントが手を止めて自分の入力を待っているのか分からない」。複数のAIコーディングエージェントを日常的に走らせる人なら、一度は陥る”放牧崩壊”です。herdr（ハーダー）は、まさにこの問題のために作られた、Rust製のエージェント・マルチプレクサです。ひとことで言えば「AIコーディングエージェントのためのtmux」。GitHubで約9,300スター（2026年7月時点）を集め、単一バイナリで動く軽さから急速に注目を集めています。

この記事を読むと、①herdrで結局何ができるのか（複数エージェントを1つのターミナルに束ね、状態を一望する）、②どんな課題を解決するのか（「どれが止まっているか分からない」放牧崩壊と、閉じると消えるセッションの問題）、③何を代替できるのか（AIエージェント運用に限ればtmuxやGUIエージェント管理ツールの代わりになる）が分かります。なお、そもそもどのエージェント基盤を選ぶか迷っている方は、まずAIエージェントフレームワーク徹底比較2026を合わせて読むと、herdrが担う”運用レイヤー”の位置づけが掴みやすくなります。

herdr：AIコーディングエージェントを1つのターミナルで管理し、claudeはworking・codexはblocked・droidはdoneと状態を可視化する
herdrはサイドバーで各エージェントの状態（作業中・待ち・完了）を一望させる。「誰が自分を待っているか」が一目で分かる。
この記事のポイント
  • ・herdrは複数のAIコーディングエージェントを1つのターミナルで並列管理するRust製マルチプレクサ。
  • ・最大の特徴はエージェントの状態（作業中・入力待ち・完了・アイドル）をサイドバーで可視化すること。
  • ・約10MBの単一バイナリで、GUI・アカウント・テレメトリなし。SSHで再接続してもセッションは死なない。
  • ・ソケットAPIでエージェント同士を連携させ、多段の自動オーケストレーションも組める。
  • ・ライセンスはAGPL-3.0（＋商用）。SaaS組み込み時は条項の確認が必要。

1. herdrとは：AIコーディングエージェントのための「ターミナル・マルチプレクサ」

herdrは約10MBの単一Rustバイナリで複数AIエージェントを1端末に束ね、永続性・状態認識・軽量実行の3要件を同時に満たす
herdrは「永続化・状態の可視化・軽量な単一バイナリ」を1つに束ねた点が新しい。tmux/zellij/GUIツールはどれか1つを取りこぼす。

herdrは、複数のコーディングエージェントを1つのターミナルの中でまとめて動かすためのマルチプレクサです。作者はogulcancelik氏で、実体は90%以上がRustで書かれた単一バイナリ。公式は「tmuxがターミナルに対して果たす役割を、herdrはエージェントに対して果たす」と表現しています。

ポイントは、herdrが単なる画面分割ツールではないことです。tmuxやzellijと同じようにペイン（画面領域）を永続化しつつ、その上で動いているエージェントの”状態”を理解する——ここがherdrの核心です。各ペインは”アプリが模したような疑似端末”ではなく本物のターミナルなので、フルスクリーンのTUI（Claude Codeの対話画面など）もそのまま正しく描画されます。

herdrが立っている場所を整理すると、次の3つの性質を1つに束ねた点が新しいと言えます。

・永続性：端末を閉じてもプロセスは生き続ける（tmux由来の強み）
・エージェント状態の認識：どのエージェントが作業中で、どれが入力待ちかを検出する（従来のマルチプレクサに無い）
・軽量なバイナリ実行：GUIアプリではなく、約10MBの単一Rustバイナリで完結する

名前の”herd”（群れ）が示すとおり、herdrの発想は「増えていくエージェントを一頭ずつ手なずける」のではなく「群れとしてまとめて見張る」ことにあります。これまでも、tmuxで無理やり複数エージェントを並べたり、GUIの管理アプリを併用したりといった工夫はありました。しかしそれらは「永続化はできるが状態が見えない」「状態は見えるが重い・macOS限定・リモートに弱い」といった具合に、必ずどこかで妥協が生じます。herdrが新しいのは、この3つの要件を単一の軽量バイナリで同時に満たし、しかも既存ターミナルの中に溶け込む形で提供した点です。「専用ツールを増やす」というより「今の端末にエージェント視点を1枚足す」感覚に近いと言えます。

ひとことで
  • ・tmux＝ターミナルを多重化する汎用ツール。herdr＝エージェントを多重化する専用ツール。
  • ・「本物の端末を保ちながら、その上のエージェントの状態まで見える」のがherdrの発明。

2. なぜ必要か：複数エージェントの並行運用が「放牧崩壊」する問題

herdrが解決するのは、AIエージェントを複数走らせ始めた瞬間に発生する運用の混乱です。1体だけなら普通のターミナルで足ります。しかし2体、3体と増えると、途端に破綻します。

具体的な症状はこうです。

・エージェントAは長い実装の最中、Bは確認を求めて止まっている、Cはすでに終わっている——でもタブを1つずつ覗かないと分からない
・入力待ちのエージェントに気づかず放置し、全体の進行が詰まる
・ノートPCを閉じたら、走らせていたエージェントのセッションごと消える
・外出先からSSHで様子を見たいのに、元の作業状態に戻れない

従来ツールはこの一部しか解けません。tmuxは永続化とペイン分割を提供しますが、AIエージェントより前の時代の道具なので「どのエージェントが待ちか」という状態の概念を持ちません。一方、状態を見せてくれるGUIのエージェント管理ツールは、ラップされたアプリ（多くはmacOS専用）として動き、軽さやリモート運用で不利になりがちです。

放牧崩壊のコスト
  • ・「気づいたら全部のエージェントが自分の入力待ちで止まっていた」——これは並列化の効果を丸ごと打ち消す。
  • ・状態が見えないと、人間がボトルネックになり、エージェントを増やすほど遅くなるという逆説が起きる。

この問題は、エージェントの性能が上がるほど深刻になります。1体あたりの自律性が高まり、長い作業を任せられるようになるほど、”待ち”が発生するタイミングは読みにくくなり、同時に走らせたくなる数も増えるからです。つまりエージェントが賢くなるほど、束ねる道具の重要性が上がるという関係にあります。tmuxを使い込んだ開発者ほど「永続化はできるが、どのペインのエージェントが止まっているかを目視で探すのが限界だった」という不満を持っており、herdrはまさにその”最後の一歩”を埋める位置づけです。

herdrはこの3つ（永続化・状態認識・軽量実行）を同時に満たすことで、「エージェントを増やすほど速くなる」状態に運用を近づけます。状態のライフサイクルは次のように整理できます。

flowchart LR I["idle
アイドル"] --> Wk["working
作業中"] Wk --> B["blocked
入力待ち"] B --> Wk Wk --> D["done
完了"] D --> I

herdrはこのライフサイクルを、プロセス名の照合とターミナル出力のヒューリスティックで自動判定し、サイドバーに色分けで表示します。人間は「赤（＝入力待ち）から先に対応する」というシンプルな運用に集中できます。

3. herdrの主な機能：状態の可視化・永続セッション・リモート

herdrの主要6機能：本物の端末（実PTY）・状態の可視化・ワークスペース/タブ/ペイン・永続セッション・単一バイナリ・スクリプタブルなソケットAPI
herdrの主要6機能。エージェントを放牧するための最小十分に絞られている。

herdrの機能は「エージェントを放牧するための最小十分」に絞られています。主要機能を整理します。

エージェントごとに本物のターミナル：各エージェントは独立した実PTY（疑似端末）を持ちます。アプリの模造端末ではないため、対話型TUIも崩れません。

状態のサイドバー表示：作業中・入力待ち・完了・アイドルの4状態を一覧化。「誰が自分を待っているか」が一目で分かります。

ワークスペース・タブ・ペイン：プロジェクトやフォルダ単位でワークスペースを分け、マウス操作でタブ追加やペイン分割ができます。

永続セッション：デタッチしてもエージェントは動き続け、任意のターミナルから再アタッチできます。

どこでも動く単一バイナリ：約10MBのRustバイナリ1つ。Linux・macOS・Windows（ベータ）に対応し、外部依存はありません。

スクリプタブル：ローカルのUnixソケットAPIとCLIから、エージェントの起動・操作を自動化できます。

対応エージェントも広く、Claude Code・Codex・Devin CLI・GitHub Copilot CLI・Droid・Amp・OpenCode・Grok CLI・Cursor・Kimi Code など15種類以上で動作確認されています。基本は「ターミナルで動くCLIエージェント」なら載せられる設計です。

herdrがエージェントの状態をどう知るのかも押さえておきましょう。仕組みはプロセス名の照合とターミナル出力のヒューリスティックの二段構えです。たとえば「入力プロンプトが出て待機している」「処理中のスピナーが回り続けている」といった端末上のサインから、作業中・入力待ち・完了を推定します。この方式のおかげで、herdr側にエージェントごとの深い作り込みがなくても、多くのCLIエージェントを”それらしく”扱えます。さらに一部のエージェントには、セッション復元やセマンティックな状態報告を強化する公式連携が用意されており、検出精度や再アタッチ時の復元をより確実にできます。汎用のヒューリスティックで広くカバーしつつ、要所は公式連携で精度を上げる——この二層構造がherdrの現実解です。

もうひとつ地味ながら効くのが「各ペインが本物の端末である」ことです。エージェントのTUIは、進捗バーやカーソル移動、色付き差分など、端末制御シーケンスを多用します。アプリが端末を”それっぽく”再現しただけの環境ではこれらが崩れがちですが、herdrは実PTYをそのまま見せるため、Claude Codeの対話UIやgitの差分表示もネイティブのターミナルと同じ見え方になります。「エージェントの画面が変に化ける」ストレスがない、という当たり前を確実に満たしているのは、日常運用で効いてきます。

設計思想が効くところ
  • ・「GUIなし・アカウントなし・テレメトリなし」。ツールに縛られず、既存のWezTerm/iTerm2/Kittyの中で完結する。
  • ・重いElectronアプリを常駐させないので、サーバーやリモート環境でも気軽に使える。

4. herdrのインストールと基本操作

herdrの流れ：ワンライナーでインストール→herdr起動→ctrl+bでワークスペース分割→サイドバーで放牧・監視→デタッチして再接続
インストールから放牧までの流れ。操作系はtmuxを踏襲し、プレフィックスも同じ ctrl+b。

導入は非常に簡単で、ワンライナーで入ります。まずはインストールから。

# Linux / macOS（公式インストーラ）
curl -fsSL https://herdr.dev/install.sh | sh

# Homebrew
brew install herdr

# mise（ツールバージョン管理）
mise use -g herdr

# Nix（ビルドせず即実行）
nix run github:ogulcancelik/herdr

Windows（プレビュー）はPowerShellから入れられます。

powershell -ExecutionPolicy Bypass -c "irm https://herdr.dev/install.ps1 | iex"

起動は、ただコマンドを打つだけです。

# herdr を起動（永続サーバーが立ち上がる）
herdr

リモートのマシンでエージェントを走らせたい場合は、--remote を付けます。手元の端末はビューア、実行はリモート側、という分離ができます。

# 事前に登録したリモート名を指定
herdr --remote workbox

# SSH先を直接指定
herdr --remote ssh://you@yourserver:2222

操作はtmuxに近く、プレフィックスキー ctrl+b の後にコマンドキーを押します。主なキーバインドは次のとおりです。

・ctrl+b → shift+n：新しいワークスペースを作る
・ctrl+b → v または minus：ペインを分割する
・ctrl+b → c：新しいタブを作る
・ctrl+b → w：ワークスペースを切り替える
・ctrl+b → q：デタッチする（セッションは生きたまま離れる）

tmux経験者なら、ほぼ学習コストゼロで移行できるのが分かるはずです。プレフィックスが同じ `ctrl+b` なのは、意図的に既存の指の記憶を活かす設計になっています。

典型的な「放牧」ワークフロー

herdrの真価は、実際の運用フローに落とすと見えてきます。よくある流れはこうです。

まず herdr を起動し、プロジェクトごとに ctrl+b → shift+n でワークスペースを分けます。1つのワークスペース内では ctrl+b → v でペインを割り、左ペインでClaude Codeに機能実装を、右ペインでCodexにテスト作成を同時に指示します。あとはサイドバーだけを見て、”入力待ち”になったエージェントから順に対応していくだけです。実装の手を動かす主体はエージェントで、人間は”詰まり”を解く交通整理役に回ります。

長時間かかる処理は ctrl+b → q でデタッチして放置し、昼休みや移動中に別マシンからSSHで再アタッチして結果を確認します。この「投げて、離れて、戻る」サイクルこそ、herdrがもっとも輝く使い方です。ここで本質的なのは、人間の仕事が「実装そのもの」から「待ちエージェントの解消」へと変わる点です。状態が見えないと、エージェントを増やすほど人間がボトルネックになって全体が遅くなります。herdrは状態を可視化することで、この逆説を「詰まりを順に解くだけ」の軽い作業に変えます。

なお、インストール後は herdr を打つだけで常駐サーバーが立ち上がり、以降はそのサーバーにアタッチ／デタッチする形になります。複数のインストール手段が用意されているのは環境に合わせて選べるようにするためで、チーム内では手段を1つに統一しておくとバージョン差異のトラブルを避けられます。

5. herdrの仕組みとアーキテクチャ：セッション・ワークスペース・ペイン・エージェント検出

herdrの内部は、いくつかの概念の入れ子で理解できます。上から順に、セッション → ワークスペース → タブ／ペイン → エージェントという階層です。

・セッション：ペインとエージェントを生かし続ける、永続的なバックグラウンドサーバー。デタッチ／再アタッチの土台。
・ワークスペース：プロジェクトやフォルダ単位のまとまり。文脈ごとに画面を分ける。
・タブ／ペイン：クリック・ドラッグ・分割でレイアウトを組む単位。
・エージェント検出：プロセス名の照合と、ターミナル出力のヒューリスティックで状態を判定する仕組み。

全体像を図にすると次のようになります。1つの端末（あなた）から、永続サーバーを介して複数のエージェントを束ねている構造が見えます。

flowchart TD U["あなた（1つの端末）"] --> S["herdr サーバー
永続セッション"] S --> W1["ワークスペースA
プロジェクトX"] S --> W2["ワークスペースB
プロジェクトY"] W1 --> P1["ペイン claude
状態 working"] W1 --> P2["ペイン codex
状態 blocked"] W2 --> P3["ペイン droid
状態 done"] P1 --> A1["実PTY 本物のシェル"] P2 --> A2["実PTY 本物のシェル"] P3 --> A3["実PTY 本物のシェル"]

技術的な土台も要点だけ押さえておきましょう。herdrは疑似端末の管理に portable-pty を使っており、これがデタッチ／再アタッチをまたいでエージェントのプロセスを生かし続ける鍵になっています。並行I/Oは tokio の非同期ランタイムが受け持ち、複数ペインからの入出力をブロックせずさばきます。「本物の端末を保ちながら永続化する」という一見両立しにくい要件を、Rustの堅牢なPTY管理で実現しているのがアーキテクチャ上の妙です。

この階層構造には運用上の意味もあります。セッション＝サーバーが独立しているからこそ、クライアント（あなたが今見ている端末）を落としても中身は無傷で、別の端末から入り直せます。ワークスペースで文脈を分けることで、プロジェクトAのエージェント群とプロジェクトBのエージェント群が画面上で混ざらず、状態サイドバーも文脈ごとに整理されます。そしてペイン＝1エージェントという素直な対応づけが、後述するソケットAPIでの「ペインを作る／コマンドを送る／完了を待つ」という自動化の単位ともきれいに一致します。概念がシンプルなぶん、手動運用からスクリプト自動化まで同じメンタルモデルで扱えるのが、herdrの設計上の強みです。

6. tmux・zellij・GUI管理ツールとの比較とソケットAPI連携

では、herdrは既存ツールとどう違うのか。よく比較される対象を表で整理します。

観点 herdr tmux zellij GUIエージェント管理ツール
主目的 AIエージェントの多重化 汎用ターミナル多重化 汎用ターミナル多重化 エージェントの可視化・管理
エージェント状態表示 あり（作業中/待ち/完了/アイドル） なし なし あり
ペイン永続・再アタッチ あり あり あり ツールにより異なる
リモート/SSH運用 得意（--remote） 得意 得意 不利なことが多い
実行形態 単一Rustバイナリ(~10MB) 単一バイナリ 単一バイナリ GUIアプリ(Electron等)
プラットフォーム Linux/macOS/Win(β) Linux/macOS Linux/macOS/Win macOS専用が多い
ライセンス AGPL-3.0(＋商用) ISC MIT 製品による

要するに、汎用の多重化は tmux/zellij、エージェント運用に特化した多重化は herdr、という住み分けです。GUI管理ツールは状態こそ見せてくれますが、リモートや軽量性でherdrに分があります。

補足すると、herdrはtmuxを”敵”とは見ていません。プレフィックスキーやペイン分割の操作系はtmuxを踏襲しており、tmuxで培った運用感覚をそのまま持ち込めます。既存のtmux設定を捨てる必要はなく、”エージェントを走らせるとき用の端末”としてherdrを併用する、という段階的な導入も現実的です。GUIエージェント管理ツールと比べた最大の差別化は、ヘッドレスなサーバーやリモート環境でそのまま動くこと。クラウド上の開発マシンでエージェントを回す用途では、この軽さが決定的な差になります。

そしてherdrがユニークなのは、ソケットAPIによるエージェント間オーケストレーションを備える点です。herdrはUnixドメインソケット経由のAPIを公開しており、あるエージェントが別のエージェント用のペインを作り、コマンドを実行し、その完了を待つことができます。これは「人間が複数エージェントを見る」だけでなく、「エージェントが他のエージェントを指揮する」多段自動化への入口です。

flowchart TD M["親エージェント
（オーケストレータ）"] -->|"ソケットAPI"| H["herdr サーバー"] H --> C1["子ペインを生成
テスト実行エージェント"] H --> C2["子ペインを生成
リファクタ実行エージェント"] C1 -->|"完了を通知"| H C2 -->|"完了を通知"| H H -->|"結果を集約"| M

この仕組みが効くのは、たとえば次のようなパターンです。①分担並列——1つのタスクを「実装・テスト・ドキュメント」に割り、それぞれ別エージェントのペインに投げて、完了したものから親が回収する。②検証ループ——実装エージェントが書いたコードを、別ペインのレビュー用エージェントに渡し、指摘が出たら実装側へ差し戻す。③長時間バッチ——時間のかかる移行作業を複数ペインに分散し、人間はサイドバーで全体の進捗だけを監視する。いずれも「人間が手動でタブを行き来する」代わりに、herdrのペインを”作業単位”として機械的に扱える点が肝です。

ソケットAPIはローカル前提（Unixドメインソケット）なので、ネットワーク越しの複雑な権限管理を持ち込まずに、まずは手元やサーバー内で完結した自動化を組めます。「人がエージェントを見る」から「エージェントがエージェントを指揮する」へ——その最初の一歩を、追加インフラなしで踏めるのがherdrの面白さです。なお、公開されているサブコマンドやAPIの正確な仕様は更新が入りやすいため、実装時は必ず公式ドキュメントで最新の形を確認してください。

使い分けの目安
  • ・サーバー管理・ログ監視など汎用作業 → tmux/zellijのままでよい。
  • ・Claude CodeやCodexを複数走らせる開発ワークフロー → herdrが刺さる。
  • ・エージェント同士を自動連携させたい → herdrのソケットAPIを検討。

7. herdrの導入判断：向いている人・注意点（AGPLライセンス）

herdrが向いている人（CLIエージェントを複数・デタッチ放置・リモート監視・軽量志向・自動連携）と慎重に判断すべきケース、AGPL-3.0の注意点
herdrの導入判断。向いている人と慎重に判断すべきケース、そしてAGPL-3.0ライセンスの注意点。

最後に、導入すべきかの判断材料を整理します。

herdrが向いている人

・Claude Code・CodexなどのCLIエージェントを日常的に2体以上走らせる
・長時間実行をデタッチして放置し、後で再アタッチしたい
・リモートサーバー上でエージェントを動かし、手元から監視したい
・Electronアプリを常駐させたくない、軽量・端末完結が好み
・将来的にエージェント同士の自動連携まで視野に入れている

慎重に判断すべきケース

・エージェントは常に1体しか使わない（tmuxや素の端末で十分）
・GUIのリッチな管理画面が必須（herdrは端末UI）
・Windowsが主環境（対応はベータ段階）

特に注意したいのがライセンスです。herdrはAGPL-3.0-or-laterのオープンソースで、AGPLの条件を満たせない組織向けに商用ライセンスも提供されています。AGPLは、ネットワーク越しにソフトを提供する場合でもソース公開義務が及ぶ強いコピーレフトです。個人利用や社内利用では通常問題になりませんが、自社SaaSのバックエンドに組み込んで外部提供するような使い方では、事前に条項を確認し、必要なら商用ライセンスを検討してください。

補足として、herdrは約9,300スターと勢いこそありますが、バージョンはまだ0.7系で、活発に開発が進む若いプロジェクトです。これは裏を返せば、機能追加や改善が速い一方で、キーバインドやCLIの細部が将来変わる可能性があるということです。チームで使うなら、インストール手段とバージョンを揃え、アップデートは変更点を確認してから適用するのが安全です。とはいえ「エージェントを複数走らせる」というニーズ自体は今後さらに一般化していくため、この領域の専用ツールを早めに触っておく価値は十分あります。

導入前チェック
  • ・AGPL-3.0の影響範囲を法務・ライセンス面で確認する（SaaS組み込み時は特に）。
  • ・Windows運用はベータ。主環境がWindowsなら、まずは検証から始める。
  • ・v0.7.x系と比較的若いプロジェクト。破壊的変更の可能性を見込み、バージョンを固定して運用する。

まとめ

herdrは、「AIコーディングエージェントを複数走らせる時代」に生まれた、専用のターミナル・マルチプレクサです。tmuxの永続性を受け継ぎながら、エージェントの状態を可視化するという一点で明確に一歩踏み込みました。

結論
  • ・herdrは複数のAIエージェントを1つの端末に束ね、状態（作業中/待ち/完了）を一望させる専用ツール。
  • ・約10MBの単一Rustバイナリで、GUI・アカウント・テレメトリなし。SSH再接続でもセッションは死なない。
  • ・ソケットAPIでエージェント間の自動オーケストレーションまで組める。
  • ・汎用作業はtmux、エージェント運用はherdr、という住み分けが現実的。
  • ・AGPL-3.0のため、SaaS組み込み時はライセンス確認を忘れずに。

複数エージェントの”放牧崩壊”に心当たりがあるなら、まずは curl -fsSL https://herdr.dev/install.sh | sh で入れて、いつものClaude CodeやCodexを2〜3体、herdrの中で走らせてみてください。エージェント運用を本番品質へ引き上げる設計思想については本番投入できるAIエージェントの12原則が、エージェントに”記憶”を持たせて長時間タスクを回す発想についてはエージェントの永続メモリ入門が参考になります。

参照ソース

・ogulcancelik/herdr (GitHub) — 公式リポジトリ。README・リリースノート・対応エージェント一覧の一次ソース。
・herdr 公式サイト・ドキュメント — インストール・概念（Sessions/Workspaces/Panes）・設定の公式ドキュメント。
・herdr — command-line utility in Rust (lib.rs) — Rustクレートとしてのメタ情報・バージョン。