herdrとは──複数のAIコーディングエージェントを1つのターミナルで束ねる「エージェント版tmux」¶

対象 / ポイント

対象: Claude CodeやCodexなど複数のCLIエージェントを並行運用し、ターミナルの巡回に時間を取られている開発者。

ポイント:

herdrは永続ターミナルにblocked / working / done / idleの状態集約を重ねる
Claude CodeとCodexの状態は、フックではなく画面下部のスナップショットから推定する
Socket APIで完了待ちや出力取得まで自動化できるが、v0.7系のpre-1.0である

Claude CodeとCodexを4つのペインで走らせると、次に詰まるのは計算資源ではない。どのペインが承認待ちで、どれが完了したかを巡回する人間の注意だ。herdrは、この確認コストをターミナルのサイドバーへ集約する。

この記事の問いは1つだ。herdrはtmuxの見た目を変えただけなのか、それとも複数エージェントを制御する新しい層なのか。

herdrが解くのは「起動」ではなく「注意配分」¶

herdrは、実行中のエージェントを本物のターミナルペインに残したまま、その状態を一覧化するマルチプレクサだ。Rust製の単一バイナリで、Electron製アプリやホスト型ダッシュボードではない。ワークスペース、タブ、ペインを持ち、クライアントを閉じてもサーバー側のプロセスは動き続ける¹。

tmuxやZellijもペインを永続化できる。しかし、ペイン内のClaude Codeが承認を待っているかまでは知らない。herdrはblocked、working、done、idleの4状態をペインからタブ、ワークスペースへ積み上げる。どこか1つがblockedなら、ワークスペースの表示だけで介入先が分かる²。

比較すると、違いは画面分割ではなく状態を制御信号として扱えるかにある。

選択肢	セッション永続化	エージェント状態	主な利用場所
tmux / Zellij	あり	認識しない	ターミナル、SSH
デスクトップ型管理アプリ	製品による	認識する	GUIを動かすマシン
herdr	あり	4状態を集約	ターミナル、SSH

では、エージェントを改造せずに状態をどう判定するのか。

状態検知はフックと画面推定の二層構造¶

herdrは最初に、各ペインのフォアグラウンドプロセスを識別する。その後はペインごとに1つの「状態の権威」を決め、ライフサイクルフックか画面マニフェストのどちらかでidle、working、blockedを判定する²。

フック権威: Pi、OpenCode、Hermes Agentなどは、対応統合が動いている間、フックやプラグインの報告だけを状態の情報源にする
画面推定: Claude Code、Codex、GitHub Copilot CLIなどは、ライブ画面下部のスナップショットをTOMLルールで評価する

Claude CodeやCodexにも統合はあるが、主な役割はセッション識別だ。許可承認の結果やEscによる中断など、フックだけではライフサイクル全体を捕捉できないため、herdrは意図的に画面推定を状態の権威として残している²。

この設計は誤検知より見逃しを選ぶ。既知の承認UIに一致しない画面はblockedではなくidleへ落ちるため、新しいプロンプト形式が一時的にidleと表示される可能性がある。検知マニフェストはherdr.devから更新され、判定根拠は次のコマンドで確認できる。

herdr agent explain w1:p1

ゼロ設定は「常に正確」という意味ではない。画面推定型では、サイドバーを絶対的な監査ログではなく、介入先を絞るセンサーとして使うのが現実的だ。

3コマンドで始める最小構成¶

LinuxまたはmacOSなら、インストールからClaude Code統合まで3コマンドで進められる³。

curl -fsSL https://herdr.dev/install.sh | sh
herdr
herdr integration install claude

任意のペインでclaudeやcodexを普段どおり起動すれば、サイドバーに状態が現れる。操作はtmux型のprefix方式で、Ctrl+b qでデタッチし、herdrで再接続する。Homebrewではbrew install herdrも使える¹。

SSH先で起動すれば、ノートPCを閉じても処理は続く。公式サイトはスマートフォンのSSHクライアントからの再接続や、herdr --remoteによるリモート接続も主要用途として示している⁴。

永続化だけならtmuxでも足りる。herdrの境界を越える機能は、状態を外部から待てるAPIだ。

Socket APIが監視をオーケストレーションへ変える¶

herdrはローカルソケット上に改行区切りJSONのAPIを公開する。ワークスペース操作、ペイン出力の読み取り、エージェント状態の待機、イベント購読を、CLIラッパーまたは生のプロトコルから扱える⁵。

herdr agent start reviewer --cwd ~/project --split right -- claude
herdr wait agent-status w1:p1 --status done
herdr pane read w1:p1 --source recent --lines 50

これで「エージェントAの完了を待つ→出力を読む→エージェントBを起動する」という連携をシェルから組める。pane.agent_status_changedのイベント購読もあり、エージェント自身に操作方法を教えるSKILL.mdも公式に提供されている⁵⁶。

ただし、wait agent-statusが待つのはコマンドの終了ではなく、herdrが判定した意味上の状態だ。画面推定がidleへフォールバックすれば、自動化側もその判定を受け取る。APIがあることと、状態の精度が保証されることは分けて考える必要がある。

導入判断──向く環境とpre-1.0の制約¶

herdrが効くのは、複数のCLIエージェントを日常的に並走させ、SSH先でも作業し、状態待機を自動化したい環境だ。単一エージェントを前景で使うだけなら、tmuxや通常のターミナルタブで十分な場面が多い。

2026年7月16日時点の安定版はv0.7.4で、まだ1.0前にある⁷。Windowsは実験的なプレビューベータで、UnixのPTYではなくConPTYを使うため、Linux/macOSと同じ機能保証ではない⁸。画面推定型エージェントには、プロンプト変更による検知遅れや取りこぼしも残る。

ライセンスはAGPL-3.0-or-laterと商用ライセンスのデュアル方式だ。AGPLに準拠できない組織向けに商用ライセンスが案内されているため、改変版のネットワーク提供や社内配布を検討する場合は、利用形態と義務を事前に確認する¹。

まとめ¶

herdrはtmux型の永続ペインに、エージェント状態の集約を加える
Claude CodeとCodexは画面推定型なので、blocked検知を絶対視しない
Socket APIにより、状態確認を「人が見る作業」から「スクリプトが待つ処理」へ移せる

herdrの設計が示す次の論点は、マルチプレクサの優劣ではない。エージェントが標準化された状態イベントを自ら発信するようになれば、画面推定は不要になる。herdrは、その標準がまだない時代に、ターミナル画面を暫定的な制御面へ変える実装だ。