TL;DR
- herdr は複数のAIコーディングエージェント（Claude Code / Codex / Gemini CLI等）をtmux風のUIで並行管理できるRust製ターミナル多重化ツール（GitHub、2026年7月時点で15.2k stars、AGPL-3.0とのデュアルライセンス）
- 公式インストール手順
curl -fsSL https://herdr.dev/install.sh | shは、このセッションの実行環境ではGitHub Releasesバイナリのダウンロードがcurl: (22) 403で失敗し完走できなかった - 代替として
cargo install herdrを実行したところインストール自体は成功したが、crates.io に公開されているのはv0.1.0 で、公式サイト・READMEが説明する最新版（v0.7.3）とは機能差があることが実機確認でわかった - 具体的には、ドキュメントに載っているソケットAPI（
herdr.sock・api schemaコマンド）がv0.1.0には存在せず、TUI自体は動くが「エージェント同士がソケット経由で連携する」という herdr の売りの機能には到達できなかった
herdrとは何か
herdrは「ターミナルに常駐するagent multiplexer」と自称するRust製CLIツールで、公式サイトでは次のように紹介されている。
"every agent at a glance — blocked, working, done. real terminal views, not a wrapped interpretation."
tmuxのようにペイン・タブ・ワークスペースでターミナルを分割しつつ、Claude Code・Codex・Gemini CLI・GitHub Copilot CLI・Cursor Agent CLI・Amp・OpenCode・Devinなど、対応する各種AIコーディングエージェントの実行状態（ブロック中／作業中／完了）をサイドバーに一覧表示する。バイナリは約10MBで、Electronのような重いランタイムを使わない設計になっている。
対応エージェントの検出方式は2種類に分かれている。公式ドキュメント（Agents）によると、Pi・OMP・Kimi Code CLI・Hermes Agent・MastraCodeのように「ライフサイクルフック」を実装しているエージェントは、そのフックからの報告をそのまま状態として採用する。一方でClaude Code・Codex・Cursor Agent CLIなどライフサイクルフックを持たないエージェントについては、herdr自身がフォアグラウンドプロセスを特定し、ライブスクリーンショットを読み取ってTOMLマニフェストと突き合わせる、という一段回りくどい方式で状態を推定している。
公式インストーラーが403で止まった
このセッションのパイプラインは記事化候補としてherdrを選んだ後、公式手順どおりインストールを試みた。
curl -fsSL https://herdr.dev/install.sh | sh
インストーラー自体は正常にダウンロードでき、OS・アーキテクチャ検出（linux/x86_64）、最新リリースマニフェストの取得までは進んだ。しかし実際のバイナリ取得の段階で失敗した。
> detected linux/x86_64
> fetching latest release manifest...
> downloading v0.7.3...
curl: (22) The requested URL returned error: 403
✗ download failed from https://github.com/ogulcancelik/herdr/releases/download/v0.7.3/herdr-linux-x86_64
GitHub Releasesのバイナリ配信URLに対して403が返っている。このセッションが動いている実行環境はegressプロキシ経由の通信になっており、git clone 相当の直接アクセスがブロックされる制約があることは既知だったが、GitHub Releasesの直接ダウンロードも同様に塞がれていることを、この時初めて実機で確認した形になる。brew install herdr も同様にGitHub Releasesを参照する経路のため、この環境では成立しない。
cargo installへの切り替えとバージョンの発見
Rust製ツールであるため、cargo install によるソースビルド経由のインストールを試みた。crates.io（index.crates.io）への通信はこの環境のプロキシ許可リストに含まれているため、cargo search は正常に応答した。
$ cargo search herdr
herdr = "0.1.0" # terminal workspace manager for AI coding agents
herdr-spreader = "0.1.1" # Apply tmuxinator-style project layouts to herdr from a YAML file
herdr-palette = "0.1.10" # A Raycast/Linear-style fuzzy command palette for Herdr
...
ここで最初の気づきがあった。GitHubのREADMEが説明する最新版は v0.7.3（2026年7月7日リリース）だが、crates.ioに登録されているコア本体 herdr クレートは v0.1.0 のままだった。周辺プラグイン（herdr-spreader や herdr-palette など）は個別にバージョンが進んでいるのに対し、本体クレートだけが初期リリースで止まっている状態である。
そのままインストールを実行すると、ソースビルドは問題なく完走した。
$ cargo install herdr
Compiling herdr v0.1.0
Finished `release` profile [optimized] target(s) in 40.41s
Installing /root/.cargo/bin/herdr
Installed package `herdr v0.1.0` (executable `herdr`)
$ herdr --version
herdr 0.1.0
インストールには成功したが、手元に入ったのは公式が現在案内している機能セットとは異なる、6バージョン以上古いスナップショットだった。
実際に動かして機能差を確認する
herdrはTUIアプリのため、通常のBashサブプロセスとして起動すると疑似端末（PTY）がなく即座にパニックする。
thread 'main' panicked at .../ratatui-0.30.2/src/init.rs:366:16:
failed to initialize terminal: Os { code: 6, kind: Uncategorized, message: "No such device or address" }
そこでこのセッションでは tmux の中でherdrを起動し、実際のTUI操作をキー入力で再現した。ワークスペース未作成の初期画面から n キーでワークスペース作成モードに入り、名前を入力してEnterを押すと、ペイン内にシェルが起動した。
NAVIGATE
No active workspace
Press n to create one
ctrl+s ⏎
1▸· test-agent
root@vm:/home/user/zenn-blog-automation# echo hello-from-pane
hello-from-pane
herdr自身のログファイル（~/.config/herdr/herdr.log）にも、ワークスペース作成と子プロセスのスポーンが記録されていた。
INFO herdr starting, pid=23407
INFO workspace created workspace=test-agent root_pane=1
INFO child spawned pane=1 pid=24196
ここまではv0.1.0でも問題なく動作する。次に、herdrの目玉機能であるソケットAPIを試そうとした。公式ドキュメント（Socket API）によれば、~/.config/herdr/herdr.sock に対して改行区切りのJSON-RPC風プロトコル（{"id":"req_1","method":"ping","params":{}} のようなリクエスト）でワークスペース・ペイン・エージェントを操作できるとされ、herdr api schema --json コマンドでスキーマ一覧を取得できると案内されている。
$ herdr api schema --json
unknown command: api
run 'herdr --help' for usage
api サブコマンド自体が存在しない。実際にワークスペースを作成した後も ~/.config/herdr/ 以下にソケットファイルは生成されなかった。ドキュメントに書かれているエージェント間連携の中核機能（ソケットAPI経由でのペイン操作・イベント購読）は、crates.io経由でインストールしたv0.1.0の時点ではまだ実装されていないことになる。
この差分から得られる実務上の教訓
この一連の検証からわかるのは、「READMEのインストール手順」と「パッケージマネージャに登録されているバージョン」は必ずしも一致しないという、地味だが踏みやすい罠である。
-
公式スクリプトが使えない環境では、言語のパッケージマネージャが代替経路になりうる。今回のようにGitHub Releasesへの直接アクセスが制限されるサンドボックス・社内プロキシ環境では、Rust製ツールなら
cargo install、Go製ツールならgo installのように、ソースビルド経由の入手手段を先に確認する価値がある。 -
ただし代替経路で入るバージョンが最新とは限らない。
cargo searchやcargo info <crate>でクレートのバージョンを事前確認し、READMEが説明する機能と食い違いがないかを、インストール前に突き合わせておくとよい。今回のケースではcargo install herdrが成功した時点で安心せず、herdr --versionとherdr --helpで実際に使える機能を確認したことで、ソケットAPIが使えないという実害に気づけた。 - 公式ドキュメントは最新リリースを前提に書かれていることが多い。マルチエージェントを実際に連携させる用途（ソケットAPI経由でエージェント同士にペインを作らせる、状態をイベント購読する等）でherdrを使うつもりなら、crates.io版ではなく公式インストーラー経由（またはソースからv0.7.3をチェックアウトしてビルド）でバイナリを入手する必要がある。
まとめ
- herdrはClaude Code・Codex・Gemini CLIなど複数のAIコーディングエージェントをtmux風に多重管理できるRust製OSSで、15.2k starsを集めている
- このセッションの実行環境では公式インストーラーがGitHub Releasesへのアクセスで403に阻まれ、
cargo install herdrに切り替えて導入した - crates.io公開版はv0.1.0で、TUIの基本操作（ワークスペース作成・ペイン内シェル実行）は動作する一方、ドキュメント記載のソケットAPI（
api schemaコマンド・herdr.sock）は未実装だった - 公式インストール手順が通らない環境に遭遇したときは、言語のパッケージマネージャを代替経路として検討しつつ、パッケージに登録されているバージョンがREADMEの説明と一致しているかを
--versionや--helpで必ず突き合わせるとよい