ターミナルマルチプレクサの herdr を Kiro CLI で試してみた
はじめに
herdr は、複数のコーディングエージェントを扱うためのターミナルマルチプレクサです。tmux や zellij のように、ペインに分けたターミナルを server が保持し、画面（client）を切り離しても再接続できます。
herdr は、サブコマンドやローカルソケット API を備えており、Claude Code などの AI エージェントが操作するターミナルとしても使えます。
人間が操作する Kiro CLI（オーケストレータ）から、herdr 経由で別の Kiro CLI（worker）を起動し、次の 3 点を確認した結果を紹介します。
- worker とチャット UI で会話できるか
- worker の確認ダイアログに同意できるか
- herdr の画面を切り離して再接続しても worker が残るか
実行環境
| 層 | 内容 |
|---|---|
| ホスト | Mac mini、Apple M4 Pro、macOS 27.0.1 |
| container CLI | 1.4.1 |
| イメージ | ghcr.io/kirodotdev/kirocrew:stable、digest eed9690d99b5、linux/arm64 |
| コンテナ OS | Debian GNU/Linux 13.7（trixie）、Linux 6.18.35 aarch64 |
| Kiro Crew | kirocrew 0.8.0 |
| CLI | kiro-cli 2.28.0（v2 は kiro-cli chat、v3 は kiro-cli --v3） |
| herdr | 0.9.3 |
herdr で操作する Kiro CLI は、Kiro Crew の公式イメージに同梱されているものです。コンテナの実行環境には、Mac mini の Apple container を使いました。Kiro Crew のコンテナの構築手順は、次の記事を参照してください（Docker on EC2 の例です）。
herdr を入れて起動する
herdr の公式ページでは、パイプでシェルに渡すインストーラと、OS 別のバイナリ（GitHub Releases）が公開されています。Kiro Crew のイメージには herdr が含まれないので、起動したコンテナに導入します。インストーラは常に最新版を入れるため、検証に使った 0.9.3 に揃えるには、バイナリを直接取得して配置します。
コンテナは Mac mini の Apple container で動いているため、Mac mini のホストから container exec を使い、コンテナ内のシェルでコマンドを実行します。TTY は不要で、-it は付けません。Mac mini には SSH で接続しており、SSH 経由の非対話シェルでは PATH に /usr/local/bin が入らないので、container はフルパスで呼びます。
/usr/local/bin/container exec kirocrew sh -c '
curl -fsSL -o /tmp/herdr-linux-aarch64 https://github.com/herdrdev/herdr/releases/download/v0.9.3/herdr-linux-aarch64 &&
install -D -m 0755 /tmp/herdr-linux-aarch64 ~/.local/bin/herdr &&
~/.local/bin/herdr --version'
この herdr を、人間が Kiro Crew のターミナルで起動します。初回起動では案内ダイアログが表示され、マウス操作が中心であることと、prefix が ctrl+b であることが書かれています。
settings の integrations 画面の一覧に Kiro の項目はありませんが、herdr は画面の表示から状態を推定する方式で Kiro CLI を検出して操作できます。
Kiro CLI の検出への対応が記載された v0.6.0（2026 年 5 月 20 日公開）のリリースノート
検証の構成
人間が Kiro Crew のターミナルで herdr を起動し、そのペイン（w4:p1）でオーケストレータの Kiro（v2）を起動します。herdr の server と client、オーケストレータ、worker の Kiro は、すべてコンテナの中で動きます。worker の Kiro は、herdr のペイン上で動かします。
herdr のペインの中では、環境変数 HERDR_ENV と HERDR_PANE_ID が設定されます。オーケストレータのシェルでは、HERDR_ENV=1、HERDR_PANE_ID=w4:p1 でした。オーケストレータは、herdr のサブコマンドをそのまま実行できます。
herdr pane list
worker の Kiro を起動する
workspace create で作業用のワークスペースを、pane split で worker 用のペインを作成し、agent start でそのペインに Kiro を起動します。-- の後ろに渡す引数で、v2（chat）と v3（--v3）を切り替えます。
mkdir -p /tmp/herdr-kiro-demo/orch /tmp/herdr-kiro-demo/worker-v2 /tmp/herdr-kiro-demo/worker-v3
herdr workspace create --cwd /tmp/herdr-kiro-demo/orch --label verify --no-focus
herdr pane split w7:p1 --direction right --cwd /tmp/herdr-kiro-demo/worker-v2 --no-focus
herdr agent start worker-v2 --kind kiro --pane w7:p2 --timeout 60000 -- chat
herdr pane split w7:p2 --direction down --cwd /tmp/herdr-kiro-demo/worker-v3 --no-focus
herdr agent start worker-v3 --kind kiro --pane w7:p3 --timeout 90000 -- --v3
--cwd に指定したディレクトリが無いと、エラーにはならず、ペインの作業ディレクトリは /home/kirocrew になります。先に mkdir -p で作っておきます。
workspace create が作るワークスペース（この例では w7）の最初のペイン w7:p1 は、素のシェルです。--pane には、pane split が返した pane_id（この例では w7:p2 と w7:p3）を指定します。
起動直後の状態は、どちらも idle で、interactive_ready は true でした。
v3 を初めて起動すると、Kiro CLI のカスタムエージェント設定を 3.0 形式へ移行するかを尋ねる画面が出ます。agent start は idle を返して終了しますが、実際の画面は確認待ちのままです。今回は設定を変えないよう、次のコマンドで画面を確認し、down キーで Not now に移して Enter で確定しました。
herdr agent read worker-v3 --source recent-unwrapped --lines 10
herdr agent send-keys worker-v3 down
herdr agent send-keys worker-v3 enter
2 回目以降の起動では、この画面は出ませんでした。
人間が見ている herdr の画面では、左に素のシェルのペイン、右に worker-v2 と worker-v3 が上下に並びます。
会話を往復する
合言葉を伝える依頼と、その合言葉を尋ねる依頼を、agent prompt の --wait 付きで順に送りました。--wait を付けると、送信後に worker が作業中または承認待ちへ移ったことを確認し、その後 idle・done・blocked のいずれかになるまで待ってから返ります。
herdr agent prompt worker-v2 合言葉を『青いカワセミ』にします。覚えて、『了解』とだけ返してください。 --wait --timeout 120000
herdr agent prompt worker-v2 さっきの合言葉は何でしたか？合言葉だけ答えてください。 --wait --timeout 120000
herdr agent read worker-v2 --source recent-unwrapped --lines 60
合言葉を『青いカワセミ』にします。覚えて、『了解』とだけ返
してください。
• 了解
▸ Credits: turn 0.06 • session 0.06 | Time: 1s
────────────────────────────────────────────────────────────
さっきの合言葉は何でしたか？合言葉だけ答えてください。
• 青いカワセミ
▸ Credits: turn 0.03 • session 0.10 | Time: 1s
v3 に同じ依頼を送った場合も、1 ターン目は「了解」、2 ターン目は「青いカワセミ」でした。v2・v3 とも、戻り値の agent_status は、idle の場合と done の場合がありました。idle と done は、どちらも入力待ちを意味します。herdr の公式スキル（herdr --skill が出力する、エージェント向けの説明）によると、両者は完了した画面を人間が見たかどうか（seen）で区別されます。今回は、人間が画面に表示していないワークスペースでは done、表示しているワークスペースでは idle でした。
確認ダイアログに同意してファイルを作る
/tmp 配下のファイル作成を依頼すると、worker に書き込みの確認ダイアログが出ました。このとき --wait は agent_status を blocked として返しました。
herdr agent prompt worker-v2 "ファイル /tmp/herdr-kiro-demo/out-v2.txt を作り、1行目に合言葉、2行目に『v2 で作成』と書いてください。" --wait --timeout 90000
herdr agent read worker-v2 --source recent-unwrapped --lines 40
v2 のダイアログです。
↓ Write /tmp/herdr-kiro-demo/out-v2.txt
added 2 lines in out-v2.txt
1+ 青いカワセミ
2+ v2 で作成
────────────────────────────────────────────────────────────
write requires approval
❯ Yes, single permission
Trust, always allow in this session
No (Tab to edit)
────────────────────────────────────────────────────────────
esc to close · ↑↓ to navigate · ↵ to select · Tab to edit
v3 に同様の依頼（ファイル名は out-v3.txt）を送ったときのダイアログです。
Write File requires approval
fs_write → /tmp/herdr-kiro-demo/out-v3.txt
❯ Allow
Always allow
Deny
Always deny
────────────────────────────────────────────────────────────
esc to close · ↑↓ to navigate · ↵ to select · Tab to edit
Enter で同意する
同意するには、send-keys で Enter を送ります。送る前に agent read で、ダイアログに出たツール名とパスが依頼どおりかを確認しました。Enter を送ると、既定で選択されている選択肢（v2 は Yes, single permission、v3 は Allow）が確定します。同意したのは、依頼したファイルの書き込みだけで、「常に許可」は選んでいません。
herdr agent send-keys worker-v2 enter
herdr agent send-keys worker-v3 enter
v2 のファイルの内容は次のとおりです。
青いカワセミ
v2 で作成
v3 では 2 行目が「v3 で作成」でした。
herdr の公式スキルには、承認や質問のダイアログが出ているエージェントについて、内容を調べ、答える前にユーザーへ確認するよう書かれています。この記事のように同意を代行するのは、公式の推奨より踏み込んだ運用です。
確認そのものを出さない起動オプションもあります。kiro-cli 2.28.0 の chat のヘルプには、-a, --trust-all-tools（確認なしで全ツールを実行）と --trust-tools（信頼するツールを絞る）が載っています。Kiro CLI v3 では、Permissions の仕組みが trust フラグを置き換えると公式ドキュメントに書かれています。
スラッシュコマンドを送る
worker に /changelog などのスラッシュコマンドを agent prompt で送ることもできます。ただし、パネルを開くだけのコマンドに --wait を付けると、終了コード 1 で agent_prompt_stalled のエラーが返ります。これは、送信後に worker が作業中や承認待ちへ移らないためです。エラーが返っても、スラッシュコマンド自体は実行されています。
herdr agent prompt worker-v2 /changelog --wait --timeout 30000
{"error":{"code":"agent_prompt_stalled","message":"agent prompt produced no observed working or blocked state within 5000 ms; current status is idle"},"id":"cli:agent:prompt"}
画面は agent read で確認します。v2・v3 とも、2.28.0 の changelog のパネルが開いていました。パネルは worker に esc を送って閉じます。
herdr agent read worker-v3 --source recent-unwrapped --lines 30
herdr agent send-keys worker-v3 esc
別のモデルに回答の裏取りを任せる
Sonnet 5.5 の worker（v2）が出した回答を、オーケストレータが Opus 5.5 の worker（v3）に渡し、裏取りとセカンドオピニオンを求めました。オーケストレータの Kiro があるペイン（w4:p1）を分割して、右の上下に worker を置きます。
mkdir -p /tmp/herdr-kiro-demo/sonnet-v2 /tmp/herdr-kiro-demo/opus-v3
herdr pane split w4:p1 --direction right --cwd /tmp/herdr-kiro-demo/sonnet-v2 --no-focus
herdr agent start sonnet-v2 --kind kiro --pane w4:p2 --timeout 60000 -- chat --model claude-sonnet-5.5
herdr pane split w4:p2 --direction down --cwd /tmp/herdr-kiro-demo/opus-v3 --no-focus
herdr agent start opus-v3 --kind kiro --pane w4:p3 --timeout 90000 -- --v3
v2 は --model でモデルを指定できます。v3 は kiro-cli --v3 --model … が unexpected argument '--model' found で失敗しました。そのため、起動してから /model のピッカーで選びました。この環境では claude-opus-5.5 が一覧の 2 番目だったため、down を 1 回送って Enter で確定しました。
herdr agent prompt opus-v3 /model
herdr agent send-keys opus-v3 down
herdr agent send-keys opus-v3 enter
画面に Switched to claude-opus-5.5 と表示されます。
まず、Sonnet に herdr の状態の違いを尋ねました。
herdr agent prompt sonnet-v2 "herdr の idle・done・blocked の違いを、300 字以内で説明してください。" --wait --timeout 120000
Sonnet は herdr を知らないと判断し、先に Web 検索を試みて、確認ダイアログで止まりました（--wait は blocked で返ります）。
オーケストレータが Web 検索とファイル検索の確認を拒否すると、Sonnet は「確認できていない前提の一般的な解釈」と断ったうえで、次のように答えました。
- idle: エージェントが起動していて、次の指示を待っている状態です。
- done: 割り当てられたタスクが完了した状態です。
- blocked: 承認、入力、エラーなどで、人の対応がないと進めない状態です。
オーケストレータは、この回答をファイルに書き出し、herdr の公式スキル（herdr --skill の出力）とあわせて Opus に渡して、裏取りを求めました。
herdr --skill > /tmp/herdr-kiro-demo/herdr-skill.md
herdr agent prompt opus-v3 "/tmp/herdr-kiro-demo/sonnet-answer.md は、別のモデルが書いた回答です。/tmp/herdr-kiro-demo/herdr-skill.md（herdr の公式スキル）と照らして、正しい点と誤っている点を、300 字以内で指摘してください。" --wait --timeout 180000
Opus には、2 つのファイルの読み取りについて、確認ダイアログ（fs_read）が 2 回出ました。ダイアログに出たパスが、渡したファイルであることを確認して、Allow で同意しています。
Opus の指摘は次のとおりです。
- done は「タスク完了」ではない。idle と done はどちらも入力を受け付けられる状態で、違いは完了をサーバーが「見た（seen）」かどうか。
- blocked に「エラー」は含まれない。herdr が承認や質問の UI を認識した状態に限られる。
- working と unknown が抜けている。
Opus の指摘のうち idle と done の違いは、公式スキルの「idle and done both mean the agent is ready for input」で始まる段落（seen の説明）と一致しています。ただし、Opus は seen の主体を「サーバー」としました。公式スキルでは、完了した画面を人間が表示したかどうかで区別すると説明されています。
消費したクレジットは、Sonnet が 0.30、Opus が 1.07 でした。
この裏取りが成り立ったのは、Opus に根拠となる資料（公式スキル）を渡したためです。Opus の知識だけで herdr の定義を判断させたわけではありません。
画面の分割とズームを CLI で操作する
人間が見ている herdr の画面の配置も、CLI で変えられます。ペインの分割比は pane resize、1 つのペインだけの全画面表示は pane zoom です。
pane resize の --direction は境界線を動かす向きで、--amount は分割比の増減幅です。50:50 の左ペインを 30% にするには、右ペイン（w7:p2）を指定し、その左側の境界線を左へ 0.2 動かします。
herdr pane resize --pane w7:p2 --direction left --amount 0.2
左ペインが 109 桁から 65 桁に、右ペイン（worker）が 108 桁から 152 桁になりました。
続けて、30:70 から 70:30 にするには、境界線を右へ 0.4 動かします。
herdr pane resize --pane w7:p2 --direction right --amount 0.4
worker だけを全画面で表示するには、pane zoom に --on を付けます。フォーカスも、そのペインへ移ります。
herdr pane zoom --pane w7:p2 --on
v3 も同様に全画面で表示できます。
herdr pane zoom --pane w7:p3 --on
全画面表示を解除するには --off を付けます。ズームは表示だけの切り替えで、分割比は変わりません。
herdr pane zoom --pane w7:p3 --off
接続を切っても worker は残るか
Kiro Crew のターミナルで動いている herdr の client を、人間が ctrl+b → q で切り離し、引数なしの herdr で再接続しました。
切り離している間に、herdr の CLI から worker の状態を確認しました。合言葉の確認では、agent 名の登録が切り離し後も残っていることを確かめるため、ペイン ID ではなく worker の名前だけを指定して依頼を送りました。
herdr pane process-info --pane w7:p2
herdr agent prompt worker-v2 合言葉は何でしたか？合言葉だけ答えてください。 --wait --timeout 120000
worker-v3 にも同じ依頼を送りました。
| 項目 | 切り離し前 | 切り離し中 | 再接続後 |
|---|---|---|---|
| worker-v2 の kiro-cli | PID 13184 | PID 13184 | PID 13184 |
| worker-v3 の kiro-cli | PID 13381 | PID 13381 | PID 13381 |
| herdr の server | PID 710 | PID 710 | PID 710 |
| herdr の client | PID 709 | 終了 | PID 14379 |
| 「合言葉は？」への応答 | - | v2・v3 とも「青いカワセミ」 | - |
worker の terminal_id も、切り離し前・切り離し中・再接続後で同じでした。切り離し中も、pane list や agent list は応答しました。
再接続すると、右ペインの上下に v2 と v3 の画面が戻りました。
ワークスペースやペインを閉じる操作は、切り離しとは異なり、中のプロセスを終了させます。ワークスペースを閉じると、中の worker と素のシェルは終了しました。
herdr のドキュメントにも、client を切り離してもペインと agent は動き続けると書かれています。
Kiro Crew の外から同じ herdr に接続する
Kiro Crew のターミナルとは別に、macOS 標準のターミナルからも、コンテナ内の同じ herdr に接続しました。ターミナルから Mac mini に SSH 接続し、container exec でコンテナに入り、herdr を起動します。
/usr/local/bin/container exec -it kirocrew bash -c "stty cols $(tput cols) rows $(tput lines); exec /home/kirocrew/.local/bin/herdr"
container exec -it だけで herdr を起動すると、次のエラーになりました。
herdr: cannot attach without a usable terminal: terminal reported a zero-sized grid; run inside a terminal
そのため、手元の端末サイズを stty で設定してから、herdr を起動しています。
接続すると、Kiro Crew のターミナルで見ていた verify ワークスペースと、worker-v2・worker-v3 の会話履歴が、そのまま表示されました。画面は、配色を変えた macOS のターミナルのものです。
macOS 側から接続しても、Kiro Crew 側の client は切り離されませんでした。macOS 側を切り離す操作も、これまでと同じ ctrl+b → q です。
herdr の server を再起動した場合
herdr server stop で server を止めると、ペインで動いていたプロセスもすべて終了します。
herdr server stop
Kiro Crew のターミナルで引数なしの herdr を実行して起動し直すと、ワークスペースとペインの配置、作業ディレクトリは元に戻りました。会話の復帰のしかたは、v3 と v2 で異なりました。
| 再起動後 | 合言葉への応答 | |
|---|---|---|
| v3 | herdr が kiro-cli chat --agent-engine=v3 --resume-id sess_… を自動で実行し、同じ会話で復帰 |
「青いカワセミ」 |
| v2 | 素のシェルに戻る。kiro-cli chat --resume で再開 |
「青いカワセミ」 |
herdr のドキュメントでは、エージェントの会話が戻るのは、エージェントがセッションの参照を herdr に渡している場合だけとされています。
v2 は、素のシェルで kiro-cli chat --resume を実行すると、そのディレクトリで最後に使った会話に戻れます。worker ごとのディレクトリで作業していたので、worker-v2 の会話へ戻れました。再開した v2 には agent の名前が付かないため、ペイン ID で指定します。
herdr pane run w7:p2 "kiro-cli chat --resume"
herdr agent prompt w7:p2 "さっきの合言葉は何でしたか？合言葉だけ答えてください。" --wait --timeout 120000
制約事項
herdr は、現時点では Kiro CLI にネイティブ対応しておらず、画面の検出によって Kiro CLI を扱っています。確認できた制約は次のとおりです。
- 状態の判定は、画面の検出だけに頼っています。エージェント自身が状態を通知する方式ではありません。
- 承認待ち（blocked）の検知は、ペインの幅に左右されます。ペインが狭く、ダイアログの表示が検出規則に一致しないと、状態は idle にフォールバックしました。この場合、
--waitが blocked で返らず、承認待ちに気づけないことがありました。 - server の再起動後に会話が自動で戻ったのは、今回確認した範囲では v3 だけです。v2 は素のシェルに戻るので、
kiro-cli chat --resumeを実行して手動で再開します。
まとめ
herdr は、現時点では Kiro CLI にネイティブ対応していません。それでも、AI エージェントが Kiro CLI を操作するためのターミナルとして使えること、client を切り離して再接続してもセッションを維持できることが確認できました。
Kiro CLI 単体でも、サブエージェントやヘッドレスモードでバックグラウンド処理を行えます。herdr を使うと、それに加えて、Kiro CLI の作業を別の Kiro に監督させたり、Kiro CLI 同士のやり取りを人間が画面で見守ったりできます。
Kiro CLI をより便利に使うためのターミナルマルチプレクサとして、herdr をぜひ試してみてください。
