Herdrとは　複数AIエージェントを束ねて永続化する次世代ターミナル基盤

この記事のまとめ

Herdrは、複数のAIコーディングエージェントを1つの画面基盤で束ね、状態の見える化、待機、自動化、そしてセッションの永続化までを担うターミナル向けのランタイムです。既存の端末アプリの中で動くため、フォントや配色、シェル設定はそのまま活かせます。tmuxのようなパネル維持だけでなく、エージェントの状態や再開もHerdrが担います。この記事では、その仕組みと使いどころを順番に見ていきます。

Herdrは既存端末の中で動くエージェント向けランタイムです。
idle／working／blocked／done／unknownの5状態でエージェントを可視化します。
デタッチ、スナップショット、ネイティブ再開、ライブハンドオフで永続化します。
コマンドラインインターフェース（CLI）とソケットAPIで多エージェントの自動化ができます。

Herdrの定義と基本コンセプト

Herdrとは何か

Herdrは、既存の端末の内側で動くターミナル向けワークスペース基盤です。端末を置き換えるのではなく、いま使っている環境に薄く重ねる設計が出発点にあります。

Herdrは、実際のターミナルプロセスを動かし続け、そこに構造を与えるターミナルワークスペースマネージャです。パネルやシェルを起動したまま維持し、そのうえに整理された階層を重ねる形で使います（参照*1）。

加えて、RustとターミナルUIライブラリ（Ratatui）で作られた、ターミナルネイティブなエージェント向けランタイム兼マルチプレクサでもあります。WezTerm、iTerm2、Kittyなど、いま使っている端末を置き換えるのではなく、その中で動く設計です（参照*2）。

つまり、Herdrは端末を乗り換えさせる製品ではなく、いまの環境に薄く重ねてエージェントの土台を用意する層です。フォントや配色、キーバインドを大きく変えずに導入できる点は、日常的な作業への影響を小さくしたい人にとって扱いやすい。複数のAIエージェントを同時に走らせる環境を作るとき、ツールの乗り換えコストが高ければ、試す前に諦めがちです。その摩擦を下げる設計だと、私は見ています。

workspace／tab／pane／agentの構造

Herdrの画面構造は、workspace、tab、pane、agentという階層で整理できます。

workspaceは最上位のプロジェクト単位で、リポジトリやタスク、調査ごとに1つ用意する箱です。workspaceがtabとpaneを持ち、tabがレイアウト、paneが実際のターミナルという関係になります（参照*1）。

agentは、pane内でHerdrが認識するプロセスを指します。フォアグラウンドプロセス、スクリーンマニフェスト、そして任意のインテグレーションを通じてagentを見分ける仕組みです（参照*1）。

この階層を押さえると、どこで何を操作しているかを整理しやすくなります。workspaceは作業テーマ、tabはレイアウト、paneは端末、agentはpane内の主役プロセス、と役割を分けて捉えるのが素直な使い方です。sessionはこれらを保持する独立した名前空間として重なります。

従来ツールとの違い

tmux／Zellijとの比較

Herdrとtmux／Zellijの違いは、pane単位ではなくagent単位で扱う点にあります。

tmuxもHerdrも、ターミナルを生かし続けるという点は共通しています。違いは、Herdrがどのターミナルがエージェントかを知り、それぞれの状態を把握し、待機まで扱える点です。tmuxはあくまでpaneを見ています（参照*3）。

Zellijは、人がターミナルで使いやすいように整えられたワークスペースです。Herdrは、状態、待機、直接アタッチ、そしてAPIを備えた、エージェントのためのランタイムだと位置づけられています（参照*3）。

tmuxはすべてのプロセスを同じように扱い、Claude CodeやCodexが動いていてもテキストストリームとしてしか認識しません。Herdrはこれらを見分け、サイドバーでworking、idle、blocked、done、unknownの状態を示します（参照*1）。

複数のAIを同時に走らせる場合、この視点の違いが日々の運用に直結します。私自身、ChatGPTやClaudeなど複数のモデルを同時に使って検証することがありますが、「今どのエージェントが詰まっているか」を人間が都度確認する手間は、思いのほか重いです。その問題に対してHerdrは明確な答えを持っています。

Warp／cmuxなどAIネイティブ端末との違い

HerdrとAIネイティブ端末の違いは、端末そのものを置き換えるかどうかにあります。

cmuxはエージェントを中心に据えたMac向けのターミナルアプリです。これに対しHerdrはアプリではなく、いま使っている端末の内側で動き、SSH越しにも到達できるランタイムだと説明されています（参照*3）。

Warpは自らを端末そのものおよびプラットフォームとして提供します。Herdrは、いまの端末を残したまま、その中で動くものを引き受ける立場です（参照*3）。

WarpやcmuxのようなAIネイティブ端末はターミナルを丸ごと置き換えるため、独自のキーバインドや設定を受け入れる必要があります。Herdrは既存の端末の中で動くので、フォント、配色、シェル設定、体で覚えた操作をそのまま残せます（参照*2）。

端末を新調してAI前提の体験を得たい人にはWarpやcmuxが向き、既存環境を残しつつAI対応を足したい人にはHerdrが向く、という切り分けになります。

エージェント検出と状態管理

5つの状態と検出の仕組み

Herdrは、エージェントを5つの状態に分類し、1つの情報源で管理します。

エージェントの状態はblocked、working、done、idle、unknownの5種類です。blockedは入力や承認、判断を求めている状態、workingは実際に動いている状態、doneは終わったがまだ確認していない状態、idleは終了もしくは待機中で既に見た状態、unknownは分類に自信が持てない状態を意味します（参照*1）。

Herdrはまず各paneのフォアグラウンドプロセスを検出します。そのうえで、paneごとに状態の権威（authority）を1つに絞る設計になっています（参照*4）。

スクリーンマニフェスト方式のエージェントに対するblocked判定は意図的に厳しく作られています。ライブの下部バッファのスナップショットが、既知の承認、質問、権限確認のUIと一致したときにだけblockedとみなします（参照*4）。

この設計からは、状態を出す情報源を1つに絞ることで矛盾を避け、blockedの誤検知を減らそうとしていることが読み取れます。5状態のうち、doneは未確認のidleという位置づけである点を押さえておくと、サイドバーの見方が安定します。

対応エージェントとインテグレーション

Herdrは、公式インテグレーションを通じて複数の対応エージェントのセッション再開を扱います。

公式のインテグレーションを介して、Herdrはサーバ再起動後のpane再開に使う公式セッション参照を、Claude Code、Codex、Devin CLI、Droid、Kimi Code CLI、Qoder CLI、Cursor Agent CLI、Grok CLI、GitHub Copilot CLI、Pi、OMP、Hermes Agent、OpenCode、Kilo Code CLI、MastraCode、Antigravity CLIについて扱います（参照*5）。

導入は専用コマンドで行います。たとえばClaude Codeの場合、herdr integration install claudeを実行するとフックが入り、セッション開始時にClaude CodeのセッションIDがローカルのHerdrソケットへ通知されます。状態自体はHerdrのスクリーンマニフェスト検出から得ます（参照*5）。

実際に導入したユーザーの手元では、同じコマンドを打つとClaude Code配下にherdr-agent-state.shが配置され、settings.jsonが整えられたことが記録されています（参照*6）。

対応エージェントの多さは、複数のAIを併用する開発者にとって扱いやすさに直結します。導入コマンド一発でIDの受け渡し口が用意される点も、日々のセットアップを軽くする要素です。生成AI導入で最初に詰まるのはモデル選定ではなく「何をどう繋ぐか」の設計ですが、Herdrはその配線部分をかなり引き受けてくれます。

セッション永続化と復元

デタッチと再アタッチ

通常のデタッチでは、Herdrサーバが動き続ける限りプロセスも継続します。

通常のデタッチではHerdrサーバはそのまま動き続けます。pane、シェル、エージェント、サーバ、テスト、コマンドプロセスは、サーバの内側で動作を続けます（参照*7）。

Herdrはpaneをバックグラウンドサーバの中で走らせ続ける仕組みを持ちます。ターミナルクライアントの側は、切断してから後で再接続できます（参照*8）。

この経路は、サーバが動き続けている限り最も強い永続化です。作業を一時中断して端末を閉じても、AIの走行やコマンド実行はそのまま続き、herdrで戻れば元の状態から再開できます。ネットワークをまたぐケースでも同じ考え方が使えます。

スナップショット復元とネイティブセッション再開

Herdrでは、サーバ再起動後の形の復元と会話の再開が別レイヤーで扱われます。

Herdrサーバが停止して再起動すると、元のpaneのプロセスはいなくなります。代わりに、保存されたセッションの形、つまりworkspace、tab、pane、カレントディレクトリ、レイアウト、フォーカスがスナップショットから復元されます（参照*7）。

エージェントの会話まで戻すネイティブセッション復元には、インテグレーションの最低バージョンが決まっています。Piは2でpi –session、Antigravity CLIは1でagy –conversation、OMPは3でomp –resume、Claude Codeは6でclaude –resume、Codexは5でcodex resumeを使います（参照*7）。

つまり、形の復元と中身の復元は別レイヤーで動きます。プロセスは失われるが配置は残る、そして対応エージェントについてはCLI側の再開コマンドを通じて会話が戻る、という二段構えです。この設計は、「途中まで走っていた処理がどこまで戻るか」をあらかじめ整理して運用しないと混乱します。形だけ戻って中身が消えている、という状態を想定外にしないことが重要です。

ライブハンドオフの位置づけ

ライブハンドオフは、動いているpaneプロセスを別サーバへ引き継ぐための仕組みです。

ライブハンドオフは、アップデートやリモートアタッチの流れで、動いているHerdrサーバを別のサーバに置き換えたいときのための仕組みです。古いサーバに対して、生きているpaneを新しいサーバへ渡すよう依頼し、サーバ差し替えをまたいでpaneプロセスを走らせ続けます（参照*7）。

この機能はexperimentalで、opt-inでのみ利用します。使い方はherdr –remote workbox –handoffのように明示的に指定する形です（参照*7）。

なお、Homebrewやmise、Nix経由でインストールした場合、update –handoffは使えません。長時間走るジョブを止めずにサーバを更新したい人にとって便利な経路ですが、有効化と提供経路の制約を確認したうえで使うのが安全です。

自動化とCLI／ソケットAPI

CLIプリミティブと役割分担

HerdrのCLIは、layout、pane、agentの3つのプリミティブに分かれます。

CLIのプリミティブは3つに分かれます。Layoutはworkspace、tab、paneのトポロジを作り、ターミナルの場所を用意する役割です。Paneは生のターミナルを制御し、コマンドの実行、入力、出力の読み取り、出力待ちを担当します。Agentは名前やpaneで指定した認識済みコーディングエージェントを、ライフサイクル状態を通じて操ります（参照*9）。

paneはagentが中にいるかどうかに関わらず存在し、agentはpaneの中で今動いている認識済みのプロセスです。したがってagent startは既存のシェルpaneを必要とし、レイアウトを作ったり分割したり移動したりはしません（参照*9）。

この分担を意識すると、スクリプトの設計が整理しやすくなります。場所を用意するのがlayout、その中身を動かすのがpane、名指しで扱うのがagent、という3層の順で考えると、責務が混ざりにくい。生成AIを業務に組み込む場合、「何が入力で、何が判断で、何が成果物か」を言語化できる人が強いというのは私の持論ですが、HerdrのCLI設計はその考え方と相性がよいです。

自動化ワークフローの例

Herdrでは、paneの作成からagent起動、待機、出力読み取りまでを段階的に自動化できます。

代表的な流れは、まずpane splitで補助のpaneを作り、そこにagent start reviewer –kind codex –pane "$review_pane" –m gpt-5.4でレビュアーを起動し、agent prompt reviewer "Review the current diff" –wait –timeout 120000で結果を待ち、agent read reviewer –source recent-unwrapped –lines 120で出力を読む、という3ステップです（参照*9）。

agent prompt –waitはプロンプトを即座に送ります。エージェントが非稼働状態から始まる場合、Herdrはまず5秒以内にライフサイクルの変化を観測することを求め、状態列が進まなければ無限に待つのではなくagent_prompt_stalledを返します（参照*9）。

応用例として、あるエージェントにセキュリティ監査を任せると、そのエージェントがHerdr CLIを使って2つのpaneを作り、片方でシークレットスキャナ、もう片方で依存関係チェッカを動かし、両方の完了を待って出力を読み、要約レポートを作って一時paneを閉じる、という自己オーケストレーションが可能です（参照*2）。

この一連の設計は、AI同士を橋渡しする土台になります。–waitの停滞検知があることで、詰まった場合の後始末も書きやすくなります。生成AIの業務利用で重要なのは生成そのものより、チェックと補正をどう低コストに組み込むかだと私は考えています。Herdrの停滞検知はその観点で実用的な設計です。

リモートアタッチとマルチクライアント

Herdrは、SSH経由でリモートサーバに接続しつつ、ローカル設定のまま操作できます。

herdr –remote ssh://you@server:2222の形で起動すると、ローカルのHerdrはthin clientとして動きます。SSH越しに接続してリモートのHerdrサーバを起動またはアタッチし、UIをローカル端末にストリーミングして戻します（参照*8）。

このモードでは、サーバはリモートマシン上で動き、リモートのファイルや計算資源にアクセスします。クライアントはローカルで動き、ローカルの~/.config/herdr/config.tomlを読みます。ローカルのキーバインドやテーマ、設定はすべてリモートセッションにも適用されます（参照*2）。

アタッチ方法にも種類があります。フルHerdrアタッチはワークスペースUI全体を開き、ダイレクトアタッチは今のターミナルの中にサーバ所有のターミナルを1つだけ開きます（参照*8）。

リモートでもローカルと同じキー操作と見た目で作業できるのは大きな利点です。用途に応じて、UIごと開くか、既存端末に1枚だけ差し込むかを選び分けられます。

導入と設定の勘所

インストールと初期設定

Herdrは複数の導入経路を持ち、設定ファイルなしでも動きます。

macOSやLinuxではHomebrewからの導入が使えます。Linuxではインストールスクリプト、NixOSではflake経由での導入も紹介されています（参照*2）。

設定ファイルは、LinuxとmacOSでは~/.config/herdr/config.toml、WindowsではAPPDATA配下のherdr\config.tomlに置きます（参照*10）。

デフォルト設定をまるごと確認したい場合は、herdr –default-configで全ての初期値を出力できます。そのままconfig.tomlへ書き出せば、完全な出発点として使えます（参照*10）。

導入経路が複数あるので、普段のパッケージ管理に合わせて選べます。まずherdr –default-configで雛形を吐き出し、それを土台に調整していく流れが分かりやすいはずです。設定ファイルなしでも動く点は、最初の一歩を踏み出しやすくしています。

tmuxからの移行のポイント

tmuxからHerdrへ移るときは、prefix、テーマ、シェル設定から合わせると移行しやすくなります。

tmuxでC-qをprefixにしていたユーザーは、Herdrのconfig.tomlで[keys]セクションにprefix = "ctrl+q"と書くことで、同じ操作感を持ち込んでいます（参照*6）。

同じ移行事例では、[theme]でname = "catppuccin"を指定し、[terminal]でdefault_shell = "/bin/zsh"を設定しています。テーマとログインシェルを最初に決めておくと、見た目と使い勝手が安定します（参照*6）。

このユーザーは、tmuxからHerdrに移して得たものとして、エージェント状態のネイティブな可視化、マウス操作、リモートアタッチの3点を挙げています（参照*6）。

これは特定ユーザーの体験ですが、tmuxの設定資産をそのまま持ち込みやすいことは読み取れます。prefix、テーマ、シェルの3つを合わせるだけでも、乗り換えのハードルはかなり下がります。生成AI導入は「小さな業務で入力、出力、確認、修正を回してノウハウを貯める」のが現実的だと私は見ています。Herdrへの移行も同じで、まず1つのエージェントと1つのワークスペースで試すところから始めるのが無難です。

おわりに

Herdrは、pane単位で端末を維持するだけの道具ではなく、エージェント単位で状態、待機、再開、自動化までを引き受けるランタイムです。既存の端末の内側に薄く重なる形で動くため、いまの見た目や操作感を捨てずに、複数AIを束ねる土台を得られます。私が生成AIツールを評価するとき、「技術的性能」と「現場への定着しやすさ」を分けて考えるようにしていますが、Herdrは後者への配慮がある設計だと感じます。

5つの状態管理、公式インテグレーションによるネイティブ再開、CLIとソケットAPIによる多エージェント連携、そしてリモートアタッチまでを1つの設計で扱えるのが特徴です。複数のAIエージェントを実務で使い始めると、「どれが動いていて、どれが詰まっているか」を把握する仕組みが意外と重要になります。tmuxからの移行も含めて、まずは雛形設定と1つのエージェント連携から試してみてください。

監修者

安達裕哉（あだちゆうや）

デロイトトーマツコンサルティングにて品質マネジメント、人事などの分野でコンサルティングに従事しその後、監査法人トーマツの中小企業向けコンサルティング部門の立ち上げに参画。大阪支社長、東京支社長を歴任したのち2013年5月にwebマーケティング、コンテンツ制作を行う「ティネクト株式会社」を設立。ビジネスメディア「Books&Apps」を運営。
2023年7月に生成AIコンサルティング、およびAIメディア運営を行う「ワークワンダース株式会社」を設立。ICJ2号ファンドによる調達を実施(1.3億円)。
著書「頭のいい人が話す前に考えていること」が、95万部（2026年6月時点）を売り上げる。
（“2023年・2024年上半期に日本で一番売れたビジネス書”（トーハン調べ／日販調べ））