Claude Code を開いて、Codex CLI も立ち上げて、気づいたら Gemini CLI のウィンドウも増えていた——そんな経験、最近ありませんか。
AI コーディングエージェントが実用になってから、「複数エージェントを並列で走らせる」という使い方が急速に広まっています。
でも、ツールが増えるほどターミナルは散らかる一方で、どのウィンドウで何のエージェントが動いているか、だんだんわからなくなってきます。
herdr は、そのカオスを整理するために作られた agent multiplexer です。
インストールから基本操作、実務での並列シナリオまでを具体的に見ていきます。
読み終わったあとに「1エージェント1ターミナル」運用を卒業して、複数エージェントを束ねるワークフローに移行するイメージが持てるはずです。
ターミナルが散らかり始めたら、運用を変えるタイミングだ
エージェントを1つだけ使っているうちは、何も問題ありません。
ターミナルを1枚開いて、claude と打って、指示を出す。
シンプルで、迷いようがない。
問題が起きるのは、2つ目・3つ目のエージェントを同時に使い始めたときです。
たとえばフロントエンドの実装を Claude Code に任せながら、バックエンドの API 設計を Codex に相談したいとします。
自然な流れで、ターミナルウィンドウかタブを新しく開きますよね。
そこに「ちょっとこのエラーを調べたい」と Gemini CLI のウィンドウが加わると、もう3枚のターミナルが並ぶことになります。
3枚くらいならまだ管理できます。
でも実際に作業が進むと、「どのウィンドウがどのタスクを担当していたか」が曖昧になってきます。
Alt+Tab で切り替えるたびに、前の会話の文脈を読み直す時間が発生する。
そして最悪なのが セッションの消失 です。
ターミナルを誤って閉じたり、SSH 接続が切れたりすると、エージェントとの会話履歴ごと消えてしまいます。
これは個人の習慣や注意力の問題ではありません。
「1エージェント1ターミナル」という運用モデル自体が、複数エージェントの並列利用を想定していないのです。
ツールが現実の使い方に追いついていない、という構造的な問題です。
herdr は、この問題に正面から向き合って作られたツールです。
「agent multiplexer」と名乗るとおり、複数のエージェントを1つの画面の中で束ねて管理することを目的にしています。
次の節で、その概念をもう少し具体的に掘り下げます。
tmux を知っているなら、herdr はすぐ掴める
tmux を使ったことがある人なら、herdr の概念はかなり直感的に理解できます。
tmux が解決した問題を思い出してください。
「SSH 接続が切れてもプロセスを生かし続けたい」「複数のシェルを1画面で切り替えたい」——そういった ターミナルプロセスのセッション管理 の課題でした。
herdr がやろうとしていることは、これとほぼ同じ構造です。
ただし対象が「シェルプロセス」ではなく「AI コーディングエージェント」に変わっています。
tmux との決定的な違いは、エージェントの 意味的な状態 を理解できる点です。
tmux はプロセスが生きているかどうかは知っていますが、「そのエージェントが今タスクを処理中なのか、人間の入力を待っているのか、エラーで止まっているのか」は関知しません。
herdr はエージェントの状態を working / blocked / done / idle の4つで自動検出して、blocked になったときにはシステム通知まで飛ばします。
「エージェントが詰まって待っているのに、別の作業に集中していて気づかなかった」という無駄な待ち時間を減らせるわけです。
herdr が持つ主な機能をまとめると、こんな感じです。
- エージェント状態の自動検出と通知: working / blocked / done / idle をリアルタイムで検出し、blocked 時にシステム通知を発火
- セッション永続化と detach/reattach: ターミナルを閉じてもセッションが生き続け、あとから再接続できる
- タブ・ペイン分割・マウス操作: tmux ライクなペイン分割に加え、マウスでの操作にも対応
- SSH 越しのリモート利用: ローカルと同じ操作感でリモートサーバーのエージェントを管理できる
- ソケット API によるスクリプト連携: Unix ソケット経由で CLI からエージェントを操作・自動化できる
- 公式インテグレーション: Claude Code・Codex・Amp・OpenCode などに対応し、ネイティブなセッション復元と状態レポートが使える
Rust 製のシングルバイナリという点も、実用上の意味があります。
Electron のような重いランタイムは不要で、依存関係もありません。
既存のターミナル（Ghostty・Alacritty・WezTerm など）の中でそのまま動き、tmux の中で herdr を動かすことも可能です。
SSH 越しでも同じバイナリを持っていけば動くので、リモート開発環境でも使い勝手が変わりません。
ライセンスについて一点だけ触れておきます。
herdr は AGPL v3 で公開されています。
個人利用や AGPL に準拠できる環境なら問題ありませんが、組織として商用利用する場合は商用ライセンスが必要になります。
導入前に確認しておいてください（問い合わせ先は hey@herdr.dev です）。
インストールから最初のエージェント起動まで
インストールは2通りあります。
Rust の開発環境が手元にある人は cargo 経由が一番手軽です。
cargo install herdr
Rust 環境がない場合は、herdr.dev の公式サイトからビルド済みバイナリをダウンロードできます。
シングルバイナリなので、パスの通ったディレクトリに置くだけで動きます。
インストールできたら、まず herdr を起動してみます。
herdr
これだけで TUI が立ち上がります。
既存のターミナルの中で動くので、環境を壊す心配はありません。
tmux セッションの中から起動しても問題なく動作します。
次に、ワークスペースを作ってペインを分割し、エージェントを起動する流れを見てみます。
# 新しいワークスペースを作成
herdr new workspace my-project
# ペインを分割する
# Ctrl+w | で縦分割、Ctrl+w - で横分割
# 左ペインで Claude Code を起動
claude
# 右ペインに移動して Codex を起動
codex
ペイン間の移動は Ctrl+w に続けて矢印キーで行えます。
tmux を使ったことがある人なら、プレフィックスキーの感覚でそのまま慣れると思います。
公式インテグレーションを有効にすると、エージェントの状態検出とセッション復元がより正確になります。
herdr integration install
このコマンドを実行すると、Claude Code・Codex・Amp などの対応エージェントに対してネイティブな統合が設定されます。
状態検出の精度が上がるので、インストール直後に一度実行しておくことをおすすめします。
3つのエージェントを並列で走らせる――フロント・バック・テスト分担シナリオ
実際に herdr が効いてくるのは、複数のエージェントを同時に走らせるときです。
「フロントエンドの実装・バックエンドの API・テストコードの生成」を別々のエージェントに分担させるシナリオで、操作の流れを見てみます。
まず、3ペインのワークスペースを用意します。
# herdr を起動してワークスペースを作成
herdr new workspace feature-x
# 3ペインに分割する
# Ctrl+w | で縦分割 → Ctrl+w - で横分割
# 左ペイン: フロントエンド担当
claude
# 右上ペイン: バックエンド担当
codex
# 右下ペイン: テスト生成担当
claude # 別インスタンスとして起動
これで3つのエージェントが1画面に並びます。
各ペインに移動して、それぞれのエージェントに指示を出していきます。
# エージェントの現在の状態を確認
herdr status
herdr status を叩くと、各ペインのエージェントが今どの状態にあるかが一覧で確認できます。
working なら処理中、blocked なら人間の入力待ち、done なら完了、idle なら待機中、という具合です。
blocked 通知を受け取ったとき の対処が、このワークフローの核心です。
たとえばバックエンドのエージェントが「この API の認証方式はどうしますか？」と聞いてきて blocked になったとします。
herdr はその時点でシステム通知を飛ばしてくれるので、フロントエンドの実装に集中していても気づけます。
# blocked になったペインに移動して回答する
# Ctrl+w → で右上ペインに移動
# エージェントに回答を入力して処理を再開させる
# 回答したら Ctrl+w ← でフロントペインに戻る
この切り替えが、「ウィンドウを探してさまよう」のではなく「ペインを移動するだけ」で済むのが大きいです。
コンテキストが1画面に収まっているので、「あのウィンドウで何を頼んでいたっけ」と思い出す時間がほぼゼロになります。
一点、運用上の注意を正直に書いておきます。
エージェント間のコンテキスト共有は herdr の責務ではありません。
フロントのエージェントがバックエンドの API 仕様を知るためには、人間が橋渡しする必要があります。
たとえば「バックエンドが決めた認証方式をフロントのエージェントに伝える」「テストエージェントに実装済みのコードを貼り付けて渡す」といった作業は、今のところ手動です。
herdr はあくまで「複数エージェントを1画面で管理するレイヤー」であって、エージェント間のオーケストレーションを自動化するものではありません。
そこを期待しすぎると、使い始めてから「あれ、思ってたのと違う」となるので注意してください。
現時点での限界と、それでも使い始める理由
herdr は今、v0.7.x のステージにあります。
GitHub では12,000超のスターを集め、66リリースを重ねていて、2026年6月末には GitHub Trending の Rust カテゴリで1位を獲得しています。
勢いは本物ですが、v0.x であることは正直に受け止めておく必要があります。
破壊的変更が入る可能性はあるし、実運用でバグに当たることもあるでしょう。
それでも、試す価値がある理由はシンプルです。
ターミナルが散らかっている状態というのは、思っている以上に認知コストを食います。
「どのウィンドウで何が動いているか」を頭の中で管理し続けるのは、地味に疲れる作業です。
herdr を入れて1画面に整理するだけで、その疲れがかなり減ります。
シングルバイナリで既存環境を壊さないので、試すコストも低い。
気に入らなければ使わなければいいだけです。
もう少し大きな視点で言うと、「1エージェント1ターミナル」という運用は、エージェントが1つだった時代の名残です。
複数エージェントを並列で走らせることが当たり前になってきた今、それを管理するためのレイヤーが必要になるのは自然な流れです。
tmux がシェルプロセスの管理を整理したように、herdr はエージェントの管理を整理しようとしています。
まずは手元のプロジェクトで2〜3エージェントを並べてみてください。
「ターミナルを束ねる」感覚が掴めると、エージェントへの指示の出し方そのものが変わってくるはずです。
株式会社ホコサキは、山口県宇部を拠点に Web 制作・業務システム開発・AI 活用支援を手がけています。
「エージェントを実務にどう組み込むか」という相談も受け付けていますので、気になる方は お問い合わせページ からどうぞ。