herdr実践ガイド：1つのターミナルで全AIコーディングエージェントを管理する（2026年）

Claude CodeとCodex CLIを同時に実行しているとき、どちらが承認待ちになっているか、どうやって把握していますか？多くの開発者の答えはこうです。タブを1つずつ切り替えて、プロンプトが出ていないか確認する。エージェントが1つだけならそれで十分ですが、3つや4つを同時に管理するようになると、タブ切り替えの精神的コストはあっという間に積み上がっていきます。

herdrはAIコーディングエージェント向けのオープンソースランタイムです。各エージェントを永続的なターミナルペインに置き、実行中・入力待ち・アイドルといった状態を1つのワークスペースにまとめます。

TL;DR

herdrはRust製のターミナルエージェントマルチプレクサで、1つのウィンドウからClaude Code、Codex、Devinなど複数のAIエージェントを管理でき、各エージェントのblocked/working/done/idleをリアルタイム表示
tmuxとの本質的な違い：tmuxはエージェントの状態を一切知らない汎用ターミナルマルチプレクサ。herdrはAIエージェント時代のために作られており、状態認識がネイティブ機能として搭載されている
1行でインストール可能（brew install herdr）。安定版v0.8.2は引き続きpre-1.0

複数のAIエージェントを並行実行するとき、どう管理していますか？

複数のコーディングエージェントを同時に開くと、状態を確認するたびにペインを切り替え、ターミナル出力を読み直す必要があります。herdrはプロセスを各ペインに保持しながら状態を1つの画面に集約し、この確認作業を減らします。

マルチエージェントの並行開発はすでに多くの開発者の日常の一部になっていますが、管理ツールはAIエージェントが登場する以前の設計のままです。tmuxはセッションの永続化とpane分割を解決してくれましたが、Claude Codeが今あなたの承認を待っているのか、それともまだ考え中なのかについては、何も知りません。

判断基準は、ペイン分割とセッション永続化に加えて、エージェントの状態認識が必要かどうかです。前者だけならtmuxで足りる場合があります。

マルチエージェント並行ワークフローの全体設計について詳しく知りたい方は、Claude Code並行作業完全ガイドでgit worktreeによる隔離戦略を網羅的に解説しています。

herdrとは何か：tmuxからAIネイティブターミナルへ

herdr（「herd-er」と発音）はRust製のターミナルエージェントマルチプレクサです。各エージェントを実際のターミナルペインに保持し、working・blocked・idleの状態をワークスペース単位で表示します。

機能の定義：herdr = PTYマルチプレクサ + エージェント状態認識 + 永続セッション + Socket API。それぞれの意味を具体的に見てみましょう。

PTYマルチプレクサ：tmuxと同様に、ペイン分割、タブ作成、デタッチ／リアタッチが可能で、エージェントのプロセスは各ターミナルペインに残ります。

エージェント状態認識：これはtmuxにはないコア機能です。herdrのサイドバーは各エージェントの状態をリアルタイム表示します。blocked（入力待ち）、working（実行中）、done（完了）、idle（待機）。タブ切り替えなしで一目確認できます。

永続セッション：バックグラウンドサーバーモードにより、ラップトップを閉じたりSSH接続が切れたりしてもセッションは生き続けます。SSHリモートアタッチにも対応しており、リモートサーバー上のエージェントをローカルから監視できます。

Socket API：ローカルUnixソケットを介して、エージェントがherdrを直接呼び出してpaneの作成、サブエージェントの起動、他のエージェントの出力の読み取り、状態変化イベントのサブスクライブが可能です。この機能がherdrを「ビューワー」から「オーケストレーター」へと昇格させます（後述の「Socket API」セクションで詳しく説明します）。

機能	herdr	tmux
Pane分割 / タブ管理	あり	あり
セッション永続化（デタッチ/リアタッチ）	あり	あり
SSHリモートリアタッチ	あり	あり
エージェント状態追跡（blocked/working/done）	あり	なし
エージェントSocket API	あり	なし
AIエージェントネイティブ設計	あり	なし

注目に値する点として、中国語コミュニティ（moewah blog）ではherdr対tmuxの位置付けを「置き換えではなく補完」と表現しています。これは適切な見方です。herdrにはtmuxのマルチプレクシング機能も含まれているため、tmux経験者にとってはアップグレードの選択肢であり、初心者は最初からherdrを使い始めることもできます。

5分でherdrをセットアップしてClaude Codeの最初のセッションを実行する

ステップ1：インストール（3択）

Macの場合はHomebrew（最速、公式formulaで確認済み）：

brew install herdr

Linuxやその他のプラットフォームはインストールスクリプト：

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

ソースからビルド（Rust環境が必要）：

cargo install herdr

miseとNixにも対応しています。詳細はherdr公式インストールドキュメントをご確認ください。

ステップ2：herdrを起動

herdr

tmuxに似たインターフェースが表示されますが、右側にエージェント状態サイドバーが追加されています。基本的なキーバインド：

Ctrl+B プレフィックスキー（tmuxと同じ）
Ctrl+B V 垂直方向のpane分割
Ctrl+B C 新しいタブを作成
Ctrl+B Q デタッチ（バックグラウンドで継続実行）

ステップ3：Claude Code連携を有効化

herdr内で実行：

herdr integration install claude

このコマンドはClaude Codeのhookスクリプトをインストールし、herdrがセッション識別情報を受け取れるようにします。インストール後、任意のpaneでclaudeを起動すると、サイドバーにClaude Codeの状態が表示されます。

ステップ4：動作確認

Claude Codeを起動してタスクを与えてみてください。herdrのサイドバーが現在の状態を更新します。入力待ちの場合はblocked、実行中の場合はworkingと表示されます。

重要：herdrのpane内でtmuxセッションを開くとエージェント状態検出が無効になります。エージェントはherdrのpane内で直接実行し、herdrの中にtmuxをネストしないようにしてください。

エージェント状態追跡：herdrはどうやってClaude Codeの待機状態を検出するのか？

herdrには精度の異なる2種類の状態検出メカニズムがあります。どのエージェントを使用するかによって、取得できる情報の品質が直接変わります。

メカニズム1：ライフサイクルhook／plugin（高精度）

エージェント連携がhookまたはpluginを通じ、idle、working、blockedなどのライフサイクル状態をherdrへ報告します。herdr integration install <agent>で対象エージェントの連携を導入します。明示的な状態報告は画面推定より信頼性が高い方式です。

メカニズム2：スクリーンマニフェストTOMLルール（自動だが精度は低め）

herdrが定期的にターミナル下部のバッファスクリーンショットを読み取り、TOMLルールでUIパターンを照合して状態を推測します。設定不要のゼロコンフィグですが、ライフサイクルフックより精度が低くなります。実行中のエージェントをblockedと誤判定しないよう、blocked検出は意図的に厳しめに設計されています。

各エージェントはどちらのメカニズムを使う？

サポートレベル	代表的なエージェント
フルライフサイクルフック／プラグイン（高精度）	Pi、OMP、Kimi Code CLI、OpenCode、Kilo Code CLI、MastraCode
スクリーンマニフェストのみ（自動）	Claude Code、GitHub Copilot CLI、Codex、Devin CLI、Cursor Agent CLI、Hermes Agent、Droid、Grok CLI、Amp
部分的/実験的	Gemini CLI、Cline

Claude Codeは現在スクリーンマニフェストのみの対応です。 herdr integration install claudeでインストールされるhookはセッション識別情報の報告（どのpaneがどのClaude Codeセッションかherdrに知らせる）のみを担い、blocked/workingなどの状態は依然としてスクリーンの視覚的解析で判断されます。

スクリーンマニフェストはblocked判定を意図的に厳しくしています。未知のプロンプト表示は、ルールが一致するまでidleとして扱われる場合があります。タイミング依存の自動化では、画面検出を前提にせず、ライフサイクル連携または明示的な状態報告を使ってください。

herdr vs tmux vs Warp vs Zellij：どれを使うべきか？

ツールを選ぶ前に、自分自身に1つ質問してみてください。「各AIエージェントの実行状態をリアルタイムで把握する必要があるか？」

答えが「不要、pane分割とセッション永続化だけあれば十分」なら、tmuxで完結します。答えが「必要、複数のエージェントを並行実行していてどれが待機中か知りたい」なら、tmuxをどれだけ使いこなしてもその問題は解決できません。

機能	herdr	tmux	Zellij	Warp
ターミナルネイティブ（CLI環境で使用可能）	あり	あり	あり	なし（GUIアプリ）
セッション永続化 / デタッチ-リアタッチ	あり	あり	あり（部分的）	あり
SSHリモートリアタッチ	あり	あり	なし	なし
エージェント状態追跡	あり	なし	なし	なし
Socket / Agent API	あり	なし	なし	なし
macOS / Linuxサポート	あり	あり	あり	あり
Windowsサポート	あり（pluginsはpreview、`--remote`接続先には不可）	あり	あり	あり

選択の指針：

ターミナルのマルチプレクシングだけが必要 -- tmuxまたはZellijで十分、乗り換え不要
複数のAIエージェントを並行実行していて状態の可視化が重要 -- herdr
GUIが好み、macOSネイティブな体験を求めている -- Warp（ただしエージェント状態追跡なし）
tmuxを使い慣れている -- herdrはtmuxと同じシンタックス（同じCtrl+Bプレフィックス）を採用しており、移行コストが低い

AIエージェントフレームワーク選定の考え方については、AIエージェントフレームワーク比較：LangGraph vs CrewAI vs Google ADK 2026をご参照ください。

Socket API：エージェントがエージェントを管理する

herdrについて書かれた記事の多くは状態の可視化（サイドバーでblocked/workingを見る）に焦点を当てていますが、Socket APIこそがherdrの最も強力で、最も過小評価されている機能です。

herdrはローカル制御インターフェースを公開します。Unixのデフォルトソケットは~/.config/herdr/herdr.sock、Windowsではnamed pipeを使用します。通常の自動化はCLI wrapperから始め、直接のrequest/response制御や長時間のイベント購読が必要な場合にJSON-RPCを使います。

spawn pane：指定タブに新しいpaneを作成
spawn agent：新しいpaneで特定のエージェントを起動
read pane output：任意のpaneのターミナル出力を読み取る
subscribe state events：エージェント状態変化イベントをサブスクライブ（エージェントAがdoneになったときにトリガー）

これにより、herdrは「マルチウィンドウ監視ボード」から「エージェントオーケストレーションレイヤー」へと進化します。

具体的なユースケース：Claude CodeがcollectタスクをこなすことでhookがSocket APIを呼び出し、herdrに次のClaude CodeインスタンスをsynthesizeのためにStartするよう通知します。手動の切り替えは不要で、herdrが連携を担います。

# ペインを作成し、そのペインでCodexエージェントを起動
herdr pane split w1:p1 --direction right
herdr agent start reviewer --kind codex --pane w1:p2

明確にしておくべき点として、Socket APIを使うには基本的なシェルスクリプティングまたはプログラミング能力が必要です。点数クリックで設定できる機能ではありません。FossEngineerの実践的なレポートには具体的な呼び出し方法が示されていますが、エンドツーエンドのオーケストレーションワークフローは自分で組み上げる必要があります。herdrをパイプラインのトリガーとして活用したい開発者には、ここが最も深堀りする価値のある領域です。

制限事項と知っておくべきこと

herdr v0.8.2は引き続きpre-1.0です。以下の制限はプラットフォームと自動化設計に直接影響します。

1. Windows：clientとして対応、--remoteの接続先には非対応

Windowsではローカルの永続セッション、ConPTYペイン、Linux／macOSホストへのherdr --remote接続を利用できます。一方、Windowsをremote target hostにはできません。Windows pluginsはpreviewのため、本番利用前に必要なpluginとterminalの組み合わせをテストしてください。

2. pre-1.0のプロトコルバージョンアップ（影響：本番のCI/CD）

アップグレード時にプロトコルの互換性がない場合、herdrは稼働中の旧serverを停止するか確認します。serverを停止するとpane processも終了するため、事前に作業を保存し、停止時間を確保してください。Unixでは実験的なherdr update --handoffも評価できますが、一般的な無停止保証ではありません。

3. Claude Codeはスクリーンマニフェストのみのためblockedステータスが不正確（影響：正確なblocked検出に依存するユーザー）

前述の通り、Claude Codeのblocked状態はライフサイクルイベントではなく画面から推定されます。未知のpromptは最初にidleと表示される場合があるため、タイミングに敏感な自動化の唯一のトリガーには適しません。

4. herdrのpane内でtmuxを使うとエージェント検出が機能しない（影響：既存のtmuxワークフローを持つユーザー）

herdrのpane内でtmuxセッションを開くと、herdrはその中身を検査できなくなります。DockerやVM内で実行しているエージェントには環境変数HERDR_AGENT=<agent>を設定する必要があります。

5. Apache-2.0ライセンス（影響：herdrを改変・再配布するチーム）

リポジトリはApache License 2.0を採用しています。利用、改変、再配布、商用利用が可能ですが、通知・帰属表示などの条件を守る必要があります。依存関係やpluginのライセンスは別途確認してください。

まとめ：今すぐherdrを導入すべき人は？

herdrは、複数エージェントを並行実行するときの状態把握という具体的な問題を、低い導入コストで解決します。しかし、すべての人に必要なわけではありません。

今すぐ導入をおすすめするケース

2つ以上のAIコーディングエージェントを同時に実行していて、どのエージェントが入力待ちのためblockedになっているかを把握する必要がある開発者。特に、Claude Code + Codexの並行実行ワークフローがすでにある方や、エージェントパイプラインを構築中の方には、herdrの状態サイドバーとSocket APIが直接的な価値をもたらします。

様子を見ることをおすすめするケース

Windowsをremote target hostとして使う必要がある場合、previewのWindows pluginsに依存する場合、またはpre-1.0のツールを長期CI/CDへ組み込みたい場合です。まずstagingでアップグレード、再接続、復旧手順を確認してください。

現時点では不要なケース

単一のAIエージェントだけを使用していてtmuxのセッション永続化で十分な開発者。または、どのエージェントが待機中かを気にせず、主に同期的なワークフローで作業している方。

試してみたい方は、まずインストールしてサイドバーの違いを体感してみましょう：

brew install herdr
herdr

公式ドキュメントはherdr.dev/docsにあります。自動化インターフェースはSocket APIドキュメントを参照し、pipelineへ組み込む前にherdr api schemaでインストール済みバージョンのschemaを確認してください。