herdr：コーディングエージェント向けの分離可能な端末ランタイム

背景と概要

Claude Code、Codex、Cursor、OpenCode など、端末で動くコーディングエージェントが増えています。開発者は複数の端末ウィンドウを同時に開くことが多くなりました。一つはフロントエンドを直し、一つはテストを回し、もう一つは権限の確認を待って止まっています。ウィンドウが増えるほど、悩みも増えます。どのエージェントが止まっているのか。SSH が切れたら実行中のタスクはどうなるのか。別のマシンに移ったとき、セッションをどう探し直すのか。

従来の答えは tmux でした。セッションは保てますが、tmux は「エージェント」という概念を知りません。見えているのは文字の流れだけです。herdr はこの隙間を狙っています。Rust で書かれた単一ファイルの端末ランタイムで、自らを「コーディングエージェントが生きるためのランタイム」と位置づけています。新しいエージェントではなく、既存のエージェントを置き換えることもしません。エージェントが動く端末そのものを引き受け、安定して観察でき、ほかのプログラムから編成できる居場所を与えます。

プロジェクトは GitHub で公開され、4万5000を超えるスターを集めています。同じ悩みを持つ人が多いことをうかがわせます。位置づけとしては、エージェントのコマンドラインツールと OS の端末の間に入る層です。エージェント向けの端末マルチプレクサに、スケジューリングの機能を加えたものと考えると分かりやすいでしょう。

深掘り分析

herdr は具体的に何をしてくれるのでしょうか。機能は四つに分けられます。 一つ目は、切り離しても止まらないことです。クライアントを閉じたり SSH 接続が切れたりしても、バックグラウンドのサービスプロセスが端末を動かし続けます。サーバーやマシン全体が再起動した場合、herdr は保存したレイアウトを復元し、対応するエージェントのセッションを再開できます。ただし公式は限界を明言しています。元のプロセスは生き残りません。戻るのはレイアウトとセッションであり、プロセスそのものではありません。 二つ目は、複数のマシンを一つのウィンドウにまとめることです。ローカルの作業と保存済みの ssh マシンを同じウィンドウに並べ、エージェントの一覧も統合して表示します。各マシンは個別に再接続するため、一台が切れても残りには影響しません。 三つ目は状態の表示です。各ペインには working、blocked、idle のいずれかが付きます。エージェントがあなたの回答を待って止まると、herdr が教えてくれます。ウィンドウを一つずつ見回る必要はなくなります。 四つ目が agent-native と呼ばれる仕組みです。エージェントはコマンドラインと socket API で herdr を操作できます。新しいペインを作り、ほかのエージェントにプロンプトを送り、相手が本当にブロックされるまで待ってから動けます。マルチエージェントの連携に、別のオーケストレーション基盤を用意する必要はありません。端末そのものが協調の場になります。

互換性の面では、Claude Code、Codex、Cursor、OpenCode、Grok などがそのまま動きます。herdr が持つのは端末だけで、エージェントをラップしません。操作は tmux 風のプレフィックスキーを基本に、マウスのクリック、ドラッグ、分割も標準で使えます。プラグイン機構とプラグインマーケットもあります。製品は Rust の単一バイナリで、Electron は使わず、今使っている端末の中で動きます。

業界への影響

導入の手順は短く済みます。curl のスクリプト一行、または brew install herdr、mise use -g herdr で入ります。Windows 用の PowerShell スクリプトと、リリースページのビルド済みバイナリも用意されています。作業ディレクトリで herdr を起動し、エージェントを何本か立ち上げ、必要に応じてペインを分割します。ctrl+b q で切り離し、再び herdr を実行すれば接続し直せます。 典型的な場面は、リモートの開発機で複数のエージェントを動かすケースです。夕方にノート PC を閉じて帰り、翌日に再接続しても、レイアウトとセッションは残っています。回答待ちのペインも一目で分かります。ドキュメントサイトは、クイックスタート、基本概念、対応エージェント、キーバインド、設定、セッション状態、複数マシン接続、リモートでの永続化、連携、プラグイン、socket API までを網羅しています。自作のエージェントを herdr に対応させる方法を説明した文書もあります。

リポジトリには AGENTS.md と CONTRIBUTING.md があり、リポジトリで作業する AI エージェントに、変更前に読むよう求めています。エージェントを主要な利用者に想定するプロジェクトとして、筋の通った運用です。開発に参加する人は cargo build --release でビルドし、just test で単体テスト、just check で書式・テスト・保守チェックを実行できます。 業界にとっての意味は、端末をエージェント時代の基盤として設計し直した点にあります。これまでエージェントは、孤立したコマンドラインプログラムでした。今は長時間動き、互いに連携し、複数のマシンに広がります。そこでは、誰が動いていて、誰が止まっていて、誰を起こせるのかを知る土台が要ります。エンジニアリングチームにとっては、複数のエージェントを同時に管理する負担を減らす効果が見込めます。

今後の展望

注意すべきリスクが三つあります。第一に、復元はプロセスの生存を意味しません。再起動後の再開は各エージェント自身のセッション復元機能に依存するため、必ず動くと決めてかからないほうがよいでしょう。第二に、socket API によりエージェントがペインを作り、互いに指示を送れます。権限の境界とセキュリティ上の影響は、特に複数マシンにまたがる場合、利用者が自分で見極める必要があります。第三に、各エージェントの状態を判定するには個別の適応が要ります。エージェントが更新されて挙動が変われば、適応側の追従が必要になる可能性があります。

ライセンスにも注意が要ります。入力資料ではライセンスの記述が途中で切れていました。チームに導入する前に、リポジトリで条項を確認してください。

今後の注目点は三つです。プラグインマーケットが本当のエコシステムに育つか。対応エージェントの範囲がどこまで広がるか。そして、エージェント同士が待ち合い、プロンプトを送り合う協調の形が、実際のプロジェクトで安定した作業フローとして根づくか。この答え次第で、herdr は便利なマルチプレクサにとどまるのか、エージェント駆動開発の標準的なランタイム層になるのかが見えてきます。