複数のAIエージェントをターミナルで並列管理するOSS「herdr」の仕組み

複数の AI コーディングエージェントを同時に走らせるようになって、「どのエージェントが今どういう状態なのか分からない」という問題に直面していませんか。Claude Code に大きめのリファクタを任せつつ、別のエージェントにテストコードを書かせ、さらに別タスクを並行させる。理屈の上では生産性が上がるはずなのに、実際には「どのペインが入力待ちで止まっているか」を探すために tmux のペインを行き来し続けて、かえって消耗してしまう。

この悩みの本質は、tmux のような従来のターミナルマルチプレクサが「エージェントが存在する前の時代」に設計されている点にあります。tmux は永続セッションやペイン分割といった強力な機能を備えていますが、ペインの中で動いているのが人間のシェルなのか、承認待ちで止まっている AI エージェントなのかを区別する仕組みは持っていません。一方で macOS ネイティブの GUI ツールに乗り換えれば状態は見やすくなりますが、今度は使い慣れたターミナルや SSH 越しのリモート作業という運用を手放すことになります。

この「既存のターミナルを保ったまま、複数エージェントの状態を可視化したい」というニーズに正面から応えようとしているのが、本記事で取り上げる OSS「herdr」です。herdr は Rust で書かれた単一バイナリのエージェントマルチプレクサで、tmux のような永続セッションと、AI エージェントの状態認識（作業中・入力待ち・完了・アイドル）を一つに統合しています。

本記事では、herdr が何をするツールなのか、どんな課題を解決するのか、socket API によるエージェント自身の自動制御という独自機能、そして tmux・cmux・zellij といった類似ツールとの違いや選び方、ライセンス・メンテナンス状況までを、公式ドキュメントと README をもとに整理して解説します。なお本記事は公開情報（README・公式サイト）に基づくドキュメントベースの調査であり、筆者による動作検証は行っていません。導入判断の一次情報としては必ず公式ドキュメントをご確認ください。

herdrとは｜ターミナル内で動くAIエージェントマルチプレクサ

herdr（ハーダー）は、公式の説明によれば「ターミナルの中で動くエージェントマルチプレクサ（agent multiplexer that lives in your terminal）」です。tmux のように複数のターミナルセッションを束ねて管理するマルチプレクサでありながら、束ねる対象として AI コーディングエージェントを第一級の存在として扱い、それぞれの状態を可視化することを目的に設計されています。

最大の特徴は、GUI アプリでも Electron アプリでもブラウザのダッシュボードでもなく、既存のターミナルの中でそのまま動く単一の Rust バイナリである点です。依存パッケージなしで動作し、Linux と macOS の両方に対応します。エージェントの「実際のターミナル」をそのまま表示するため、誰かが解釈・加工したビューではなく、エージェントが出力している生のターミナル画面を確認できます。

基本情報を整理すると次の通りです（GitHub リポジトリのメタデータより、2026 年 6 月 7 日時点）。

作成からまだ日が浅い新興のプロジェクトですが、約 4,800 のスターを集めており、最終更新は本記事執筆の前日にあたります。リポジトリはアーカイブ済み（archived）でもフォーク（fork）でもなく、本家としてアクティブに開発が続いている状態です。詳細な機能やドキュメントは公式サイト herdr.dev と README で確認できます。

「複数のエージェントの状態が見えない」という課題に対して、herdr は「ターミナルマルチプレクサ」というカテゴリのツールとして答えを出そうとしている、という立ち位置をまず押さえておくと、以降の機能解説が理解しやすくなります。

herdrが解決する課題｜複数AIエージェントの状態が見えない問題

複数の AI エージェントを並行させるときに最も困るのは、「どのエージェントが今、自分の操作を待っているのか」が一目で分からないことです。tmux で 5 つのペインにそれぞれエージェントを配置した場合、あるエージェントはコードを書き続け、別のエージェントは「この変更を適用してよいですか？」と承認待ちで止まっています。しかし tmux はどのペインが止まっているかを教えてくれないため、結局すべてのペインを順番に覗いて回ることになります。入力待ちを見落とすと、そのエージェントは何分も無駄に待機し続けます。

herdr はこの問題を、サイドバーでのエージェント状態の可視化によって解決します。各エージェントが今どの状態にあるかが、サイドバーに一覧で表示されるため、ペインを行き来せずとも「どれに手を入れるべきか」が分かります。

エージェントの4つの状態と検出の仕組み

herdr はサイドバーで、各エージェントを次の 4 つの状態に分類して表示します（README の説明より）。

• 🔴 blocked — 入力・承認待ち（あなたの操作を待っている）
• 🟡 working — 実行中
• 🔵 done — 完了したが、まだ確認していない
• 🟢 idle — 完了済みで確認済み

最も重要なのは、最優先で対処すべき「blocked（入力待ち）」のエージェントが赤色で明示される点です。これにより、入力待ちで止まっているエージェントの見落としという、並列運用で最も起きやすいロスを防げます。

この状態検出は、フォアグラウンドで動いているプロセス名と、ターミナル出力のヒューリスティクス（パターン認識）によって動作します。エージェント側にフックを仕込む必要はなく、設定なし（ゼロコンフィグ）で機能するのが特徴です。つまり、対応エージェントを普段通り起動するだけで、herdr が自動的に状態を判定してくれます。

ワークスペース単位での状態ロールアップ

herdr ではエージェントをワークスペース（プロジェクト単位のコンテナ）にまとめて管理します。各ワークスペースは、内部に含まれるエージェントの中で「最も緊急な状態」へとロールアップ（集約）されて表示されます。たとえばワークスペース内に 1 つでも入力待ちのエージェントがあれば、そのワークスペース自体が緊急状態として目立つように表示されます。

複数プロジェクトをまたいで多数のエージェントを動かしている場合でも、まずワークスペース一覧をひと目スキャンして「どのプロジェクトが手を必要としているか」を把握し、そこから個別のエージェントへ降りていく、という流れで効率よく確認できます。この「状態を構造的に集約して見せる」という設計こそが、tmux で力技管理していたときに失われていた俯瞰性を取り戻してくれる部分です。

herdrの主要機能

エージェント状態の可視化が herdr の中心的な価値ですが、その土台には tmux 譲りのマルチプレクサとしての堅実な機能群があります。ここでは「自分の SSH / Linux 運用で使えるか」「既存のターミナルを保てるか」という採用判断に直結する機能を整理します。各機能の詳細は公式ドキュメントの session-state および persistence-remote に記載されています。

永続セッションとサーバー/クライアント分離

herdr はサーバー / クライアント分離のアーキテクチャを採用しています。herdr コマンドはバックグラウンドで動くサーバーにアタッチする形で動作し、クライアント（あなたが見ている画面）を閉じてデタッチしても、サーバーと各ペインのプロセスはそのまま動き続けます。つまり、エージェントに長時間タスクを任せたまま接続を切っても、エージェントの作業は止まりません。後で再アタッチすれば、続きの状態から確認できます。

サーバーとペインを完全に止めたい場合は herdr server stop を使います。また名前付きセッションにより、herdr session attach work のように完全に独立したランタイム名前空間を持つこともでき、作業文脈ごとに環境を分離できます。フルに再起動した後でもペインを復元できる永続性を備えている点が、使い捨てではない実運用向けの設計を示しています。

ワークスペース・タブ・ペインと「本物のターミナル」表示

herdr の画面構成は、ワークスペース・タブ・ペインの 3 階層です。ワークスペースは git リポジトリやフォルダ単位のプロジェクトコンテナ、タブはワークスペース内でペインをグループ化する単位、そしてペインは実際のターミナルプロセスそのものです。

ここで重要なのが「real terminal views（本物のターミナル表示）」という考え方です。herdr が表示するペインは、エージェントの出力を独自に解釈・整形したダッシュボードではなく、エージェントが実際に動かしているターミナルそのものです。そのため、エージェントが出している生のログやエラーをそのまま確認でき、tmux で見ていたときと同じ感覚で中身を追えます。GUI ツールが提供する「整形されたビュー」とは設計思想が異なる部分で、ターミナルに慣れたエンジニアにとっては挙動が予測しやすい利点があります。

テキストのコピーも、ペインから直接ドラッグ選択・ダブルクリック・キーボードのコピーモード（vim 風の操作）で行えます。マウス操作にもネイティブ対応しており、18 種類の組み込みテーマ（catppuccin / tokyo night / gruvbox などとそのライト版）や、バックグラウンドイベントの通知（サウンド・トースト）も備えています。

SSH 越しのリモートアタッチ

Linux サーバーで作業することが多いエンジニアにとって重要なのが、リモート対応です。herdr は通常の SSH 越しに動作し、herdr --remote workbox や herdr --remote ssh://you@yourserver:2222 のように指定すると、わざわざリモートでシェルを開かなくても、ローカルのターミナルからリモートのサーバー上のセッションへ直接アタッチできます。

リモートアタッチではデフォルトでフォールバックの SSH keepalive が追加され、接続の安定性が確保されます（この挙動は設定で無効化することも可能です）。既存の SSH 運用をそのまま活かしながら、リモートで動いている複数エージェントの状態をローカルから可視化できる点は、サーバー中心で作業する開発者にとって採用の決め手になりうる機能です。

socket APIでエージェント自身がherdrを操作する

ここまでは「人間が herdr を使ってエージェントを管理する」視点で見てきましたが、herdr にはもう一歩進んだ独自機能があります。それが、エージェント自身が herdr を操作できる socket API です。

エージェントが自分の作業環境を制御できる socket API

herdr はローカルの Unix ドメインソケットを通じて、エージェント自身がワークスペースの作成・ペインの分割・ヘルパープロセスの生成・他ペインの出力読み取り・状態変化の待機といった操作を行えるようにしています。公式ドキュメントの socket API によれば、この API は改行区切りの JSON を Unix ドメインソケット越しにやり取りする方式で、pane.split や agent.start のようなドット記法のメソッドを公開しています。イベントの購読や状態遷移の待機にも対応しており、単なる CLI コマンド以上の、プログラムによる制御を可能にします。

これが意味するのは、エージェントが「自分でサブタスク用のペインを立ち上げ、別のヘルパーエージェントを起動し、その出力を読み取って次のアクションを決める」といった、エージェント自身によるオーケストレーションが成立しうるということです。README の比較表でも、この「agents can orchestrate（エージェントがオーケストレーションできる）」という項目は herdr のみが対応（✓）とされ、tmux や GUI マネージャは「?」と記されています。エージェントワークフローの自動化まで見据えている人にとっては、これが herdr を選ぶ強い理由になります。

公式統合と対応エージェント一覧

herdr は多くの AI コーディングエージェントを自動検出します。検出はあくまでプロセス名とターミナル出力のヒューリスティクスで行われるため、原則として特別な設定は不要です。README に挙げられている対応エージェントには、pi / claude code / codex / droid / amp / opencode / grok cli / hermes agent / kilo code cli / cursor agent / antigravity cli / kimi code cli / github copilot cli / qodercli / kiro cli などがあります（gemini cli / cline は検出されるが未テストと注記されています）。

さらに、一部のエージェントには「公式統合（direct integrations）」が用意されており、herdr integration install claude のようなコマンドで導入できます。この公式統合には大きく 2 つの役割があります。

• ネイティブなセッション復元: claude code / codex / opencode などは、herdr にセッションのアイデンティティを報告します。これにより、サーバーの再起動や herdr update による更新の後でも、対応エージェントのペインをネイティブセッションから復元できます。
• セマンティックな状態報告: pi / github copilot cli / hermes などは、セッションのアイデンティティに加えてセマンティックな状態も報告します。画面のヒューリスティクスに頼らず、エージェント自身が「今こういう状態だ」と正確に伝えられるため、状態認識の精度が上がります。

つまり、公式統合を入れていないエージェントでも画面検出で状態は分かりますが、公式統合を入れることで状態報告とセッション復元がより確実になる、という二段構えの設計になっています。対応状況の詳細は公式の integrations ドキュメントで確認できます。

tmux・cmux・zellijとの違い｜どれを選ぶか

herdr の立ち位置を理解するには、近いカテゴリのツールと比較するのが近道です。README には tmux・GUI マネージャ・herdr を並べた比較表が掲載されており、ここではそれを起点に、tmux・cmux・zellij、そして AI 機能を内蔵したターミナル製品である Warp との違いを整理します。

README の比較表は次の通りです（README「how it compares」より抜粋・原文ママ）。

出典: ogulcancelik/herdr README

この表が示しているのは、herdr が「tmux の長所（ターミナル内で動く・永続セッション・本物のターミナル表示・軽量バイナリ）」と「GUI マネージャの長所（エージェント認識・マウスネイティブ）」を両取りしようとしている、という設計意図です。比較対象を個別に見ていきましょう。

主要なツールを比較軸で整理すると、以下のようになります。

• tmux: 2007 年から続く定番のマルチプレクサで、永続セッションとペイン管理は非常に強力です。ただし「エージェントが存在する前に作られた」設計のため、エージェント状態の認識・マウスネイティブな操作・socket 経由でのエージェント制御は持ちません。herdr の直接の比較対象であり、herdr は tmux の永続性を保ちつつエージェント認識を上乗せした位置づけです。
• cmux: Ghostty（libghostty）をベースにした macOS ネイティブの GUI アプリで、垂直タブに git ブランチや PR 状態を表示し、socket API も備えます。状態の見やすさでは GUI ならではの強みがありますが、macOS ネイティブの GUI である以上、既存のターミナルや SSH 中心の運用とは前提が異なります。
• zellij: Rust 製のモダンな汎用マルチプレクサで、WASM プラグインやフローティングペイン、親切な UI が特徴です。tmux の現代版として人気ですが、エージェント状態のネイティブ認識（blocked / working / done）は持ちません。
• Warp: ターミナルエミュレータ自体に AI 機能を組み込んだ製品です。これは「AI 機能を持つターミナルそのもの」であり、herdr の「既存のターミナル上で複数エージェントを束ねるマルチプレクサ」とはレイヤーが異なります。Warp に興味がある場合は別途その製品特性を確認するとよいでしょう。

herdr が向くケース

これらを踏まえると、herdr が特に向いているのは次のようなケースです。

• 使い慣れたターミナルや SSH 越しのリモート作業を手放したくないが、複数の AI エージェントの状態は一目で把握したい
• Linux サーバー上で複数エージェントを動かし、ローカルからその状態を可視化したい
• 将来的に、エージェント自身がワークスペースやペインを制御する自動オーケストレーションまで視野に入れている
• GUI アプリや Electron アプリではなく、軽量な単一バイナリで完結させたい

cmux / zellij / tmux が向くケース

逆に、次のような場合は他のツールが適しています。

• macOS だけで完結し、ネイティブ GUI の見やすさ・タブ表示を最優先したい → cmux
• エージェント管理は必須ではなく、汎用的でモダンなマルチプレクサとして使いたい・プラグインで拡張したい → zellij
• 既存の設定資産が大きく、枯れた安定性とクロスプラットフォーム対応を最重視する → tmux

「既存ターミナル内で動く × エージェント状態の可視化 × エージェント自身による制御」という 3 点が同時に必要かどうかが、herdr を選ぶかどうかの分かれ目になります。

導入とライセンス・メンテナンス状況

最後に、実際に試す際の導入方法と、採用判断で見落とせないライセンス・メンテナンス状況を確認します。

導入方法

herdr は単一バイナリで、主に次の方法でインストールできます（README および公式 install ドキュメントより抜粋・改変なし）。

# インストーラスクリプト
curl -fsSL https://herdr.dev/install.sh | sh

# Homebrew
brew install herdr

# mise
mise use -g herdr

出典: ogulcancelik/herdr README / herdr.dev/docs/install

このほか、GitHub の releases ページからプラットフォーム別（Linux / macOS）のバイナリを直接ダウンロードする方法もあります。具体的な手順やパッケージマネージャごとの注意点は公式の install ドキュメントを参照してください。

ライセンス（デュアルライセンス）

ライセンスは採用判断で特に注意が必要なポイントです。GitHub の API 上ではライセンスが NOASSERTION（自動判定不可）と表示されますが、これは「ライセンス未設定」という意味ではありません。README の license セクションに明記されている通り、herdr は次のデュアルライセンスを採用しています。

• オープンソース: GNU Affero General Public License v3.0 or later（AGPL-3.0-or-later）
• 商用: AGPL の条件を遵守できない組織向けに、別途商用ライセンスを提供（連絡先 hey@herdr.dev）

GitHub の自動判定が NOASSERTION になるのは、このようにデュアルライセンスとして記述されているために SPDX による単一ライセンスの自動特定ができないためです（出典: ogulcancelik/herdr README の license セクション）。

ここで実務上重要なのは、AGPL-3.0 がネットワーク越しに提供するソフトウェアにもソース公開義務を及ぼす強いコピーレフトライセンスである点です。社内ツールとして個人で使う分には問題になりにくい一方、herdr を組み込んだサービスを外部に提供するなど、AGPL の条件を満たせない使い方を検討している場合は、商用ライセンスについて連絡先（hey@herdr.dev）に問い合わせる必要があります。導入前にライセンス条件を必ず確認してください。

メンテナンス状況

メンテナンスの健全性は、新興 OSS を採用するうえで欠かせない判断材料です。herdr は 2026 年 3 月 27 日に作成された比較的新しいプロジェクトですが、本記事執筆時点（2026 年 6 月 7 日）で約 4,807 のスター・292 のフォークを集め、最終更新（push）は前日の 2026 年 6 月 6 日です。オープンな issue は 21 件で、リポジトリはアーカイブもフォークもされていない本家として、活発に開発が続いている状態が確認できます。

ただし、本記事は公開情報（README・公式サイト・公式ドキュメント）に基づくドキュメントベースの調査であり、筆者による実際のインストール・動作検証は行っていません。新しいプロジェクトであるため仕様が変わる可能性もあります。導入を検討する際は、必ず公式サイト herdr.dev と最新の README で現在の仕様を確認してください。

まとめ

herdr は、「複数の AI コーディングエージェントを並列で動かすと、どれが入力待ちか分からなくなる」という、エージェント時代に新しく生まれた課題に正面から答えようとする OSS です。その固有の価値は、次の 3 点が同時に成り立っていることにあります。

• 既存のターミナル内で動く: GUI アプリでも Electron でもなく、Rust 製の単一バイナリ。Linux / macOS に対応し、SSH 越しのリモート作業もそのまま活かせる
• エージェント状態の可視化: blocked / working / done / idle の 4 状態をサイドバーで一覧表示し、ワークスペース単位で最も緊急な状態にロールアップ。入力待ちの見落としを防ぐ
• socket API でエージェント自身が制御できる: エージェントがワークスペースやペインを自分で操作し、ワークフローを自動オーケストレーションする道を開く

tmux の永続性とターミナル内動作を保ちつつ、GUI マネージャが持っていたエージェント認識を取り込んだ「両取り」の設計が、herdr を tmux・cmux・zellij とは異なる立ち位置に置いています。使い慣れたターミナルと SSH 運用を手放さずに、複数エージェントの状態を可視化して並列管理したいエンジニアにとっては、試す価値のある選択肢と言えるでしょう。

一方で、macOS の GUI を最優先するなら cmux、汎用マルチプレクサとしての拡張性を求めるなら zellij、というように、求める要件によって最適なツールは変わります。herdr が新しいプロジェクトである点と、AGPL-3.0-or-later + 商用のデュアルライセンスである点を踏まえ、まずは公式サイト herdr.dev と README で最新の仕様とライセンス条件を確認したうえで、自分の環境に合うかを判断することをおすすめします。