agent-managerとは｜Claude CodeやCodexをtmuxで並列実行しレビューまで返すAIコーディングTUI

agent-managerは、複数のAIコーディングエージェントをtmux上で並列実行し、状態の把握から差分レビューまでを1つのターミナルUI（TUI）に収めるOSSだ。エージェントを同時に走らせるとまず「どれが止まっているか分からない」に困るが、そこを解決した次に、もう一段面倒な問題が来る。エージェントが書いたコードを、どこで見て、どうやって直させるのか。ターミナルのタブを行き来し、別ウィンドウで git diff を開き、指摘をコピーしてペインに貼り直す——この往復が並列運用の本当のボトルネックになる。

YoanWai/agent-manager（★237・Go・MIT／2026年8月2日時点）は、この2つを同じ画面に載せる。Claude Code・Codex・OpenCode・Grok・Gemini CLIをそれぞれtmuxセッションとして並列実行し、状態を一覧しながら、ctrl+r で差分レビューを開き、行コメントをそのままエージェントへ差し戻すところまでをTUIの中で閉じる。

なおAIコーディングの前提知識——エージェントに任せる範囲の決め方やツールの選び分け——を先に押さえたい場合は、Vibe Codingとは？AIコーディングの始め方・ツール比較・実践ワークフロー2026を読んでおくと、本記事で扱う「運用レイヤー」の位置づけが掴みやすい。

agent-managerとは——5種のAIコーディングエージェントを1つのTUIに束ねる

agent-managerは、AIコーディングエージェントのセッションをtmux上で管理するターミナルUIである。公式の説明は「すべてのAIコーディングエージェントのための最速のワークフロー」で、対応環境はmacOS・Linux、WindowsはWSL2の中に限られる。

中核にあるのは「セッションの木」だ。各エージェントは1つのtmuxセッションとして起動し、backend/api/auth のようなパスで表現されるグループの木構造に並ぶ。深さに制限は無く、セッションはルートを含むどのノードにも置ける。折りたたんだグループはステータスごとの件数を保持するので、畳んだままでも「この配下に自分の返事待ちがいるか」が分かる。

読者が知りたいであろう3点を先に整理しておく。

・何ができるか：複数エージェントの起動・状態把握・プロンプト送信・差分レビュー・セッションの終了と復活を、1つのTUIから行う
・何を解決するか：タブを探して回る時間と、レビュー指摘をコピペでペインに戻す手間
・何を代替できるか：エージェント運用に限れば、手動のtmux操作と外部diffツールの併用

対応ツールの内訳は後述するが、ここで押さえておきたいのは「対応＝ステータスを自動判定できる」という意味だという点だ。公式ドキュメントは、それ以外のCLIも設定ブロックを足せばセッションとして動かせるが、ライブステータスが欲しければ判定ルールを自分で書く必要がある、と明記している。

インストールと起動——tmuxが無いと何が起きるかを実測する

導入経路はHomebrew（cask）とインストールスクリプトの2つが主で、ほかにArch Linux・mise・go install・ビルド済みバイナリが用意されている。

# Homebrew（macOS / Linux）。tmuxが無ければ一緒に入る
brew install yoanwai/tap/agent-manager

# インストールスクリプト。公開チェックサムで検証して ~/.local/bin に入れる
curl -fsSL https://raw.githubusercontent.com/YoanWai/agent-manager/main/install.sh | sh

Homebrew経路は「tmuxが無ければ一緒に入れる」とREADMEに書かれている。一方でインストールスクリプト経路はtmuxを入れてくれない（「自分のパッケージマネージャでtmuxを入れてください」と明記されている）。この差が効いてくるのが、次の実測結果だ。

今回はmacOS 14.5（arm64・tmux未導入）で、v0.17.0のリリースバイナリを公開チェックサムと突き合わせてから各サブコマンドの終了コードを測った。

# 公開チェックサムと一致することを確認してから実行
shasum -a 256 agent-manager_0.17.0_darwin_arm64.tar.gz
# de92d0db07edbc1c237a075c04fdb4f95852ede77f13cb70b8c7ed7e12388aa8

./agent-manager --version   # => agent-manager 0.17.0   終了コード 0
./agent-manager --help      # => tmux not found on PATH  終了コード 1
./agent-manager             # => tmux not found on PATH  終了コード 1
./agent-manager rename foo  # => tmux not found on PATH  終了コード 1

分かったことは3つある。

・tmuxはハードな前提条件で、未導入だとヘルプすら表示されない。--help すらtmux検査の後ろにあるので、「まずヘルプを見て使い方を確かめる」ができない
・例外は --version と mcp サブコマンドで、この2つはtmux検査を通らずに終了コード0を返す
・エラー時の終了コードは1で、メッセージも agent-manager: tmux not found on PATH: exec: "tmux": executable file not found in $PATH と原因が明示される。CIやセットアップスクリプトから叩く場合、終了コードで分岐できる

もう一点、実測して分かった副作用がある。tmuxが無くて起動に失敗した実行でも、設定ファイルは生成される。macOSでは ~/Library/Application Support/agent-manager/config.toml（Linuxは ~/.config/agent-manager/config.toml、XDG_CONFIG_HOME を尊重）に149行のTOMLが書き出されていた。この中身が、このツールの仕組みを読むうえで一番の資料になる。

自分のtmuxを汚さない——専用サーバー「agentmgr」という設計

tmuxを使うエージェント管理ツールで気になるのは「自分が普段使っているtmuxと混ざらないか」だ。agent-managerはここを、tmuxのサーバー分離という機能で解いている。

tmuxはソケット名を変えることで、完全に独立したサーバーを複数動かせる。agent-managerはこれを使い、エージェントのセッションを agentmgr という名前のサーバー上、am_* という名前空間に置く。公式ドキュメントによれば、この設計から次の性質が出る。

・自分のソケットで tmux kill-server を実行しても、エージェントのセッションは巻き添えにならない
・逆に、素のシェルからエージェントのセッションへ触るときはサーバー名の明示が要る
・agent-manager（TUI）を終了しても、セッションはtmuxの中で動き続ける

素のシェルから触る場合のコマンドはこうなる。

tmux -L agentmgr ls                 # エージェントのセッション一覧
tmux -L agentmgr attach -t am_<id>  # 特定のセッションへ直接アタッチ

セッション内のキー割り当ても分離されている。セッションの中で Ctrl+Q を押すとマネージャへ戻り、Ctrl+R でそのセッションの差分レビューが開く。TUI側からは enter でその場フォーカス（キーがエージェントへ渡り、一覧は残る）、A で全画面アタッチと使い分ける。

なお本記事の検証環境にはtmuxを導入していないため、この節のサーバー分離の挙動については公式ドキュメントの記述を根拠としており、筆者の実機で再現したものではない。断定できるのは前節の終了コードまでである。

ステータス判定の仕組み——自動生成されたconfig.tomlを読む

「どのエージェントが待ちか」を出すには、各CLIの画面から状態を読み取る必要がある。agent-managerがこれをどうやっているかは、初回起動時に生成される config.toml を読むと具体的に分かる。READMEには書かれていない部分だ。

まずステータスは6種類ある。

そのうえで、ペインは既定で2秒ごと（poll_interval = "2s"）にポーリングされ、可視テキスト（ANSI除去済み）に対して正規表現ルールが上から順に当てられる。生成された設定には、claude・opencode・codex・grok・geminiの5ツール分の定義が入っていた。判定ルールの数はcodexが6本、claudeとgrokが5本、opencodeとgeminiが4本である。

各ツールの「働いている最中」を何で見分けているかは、CLIごとの画面設計をそのまま反映していて面白い。

・claude：✻✳✶✽✢·✦✧+* のスピナー行（✳ Drizzling… (6s · thinking) のような形）と esc to interrupt
・opencode：▣ Build · GLM-5.2 のような実行中行（終わると末尾に所要時間が付く）
・codex：esc to interrupt、ターン終了は ─ Worked for 12s ─ の区切り線
・grok：点字スピナー ⠋⠙⠹⠸⠼⠴⠦⠧⠇⠏ と経過秒
・gemini：esc to cancel、エラーは ✕ 始まりの行

ここで1つだけ、他と設計が違うツールがある。Claude Codeだけはペインの見た目を読まずに済む。

[tools.claude]
command = "claude"
session_id_flag = "--session-id"
resume_by_id_command = "claude --resume {id}"
revive_command = "claude --continue"
# hooksが直接ステータスイベントを報告する。下のペインルールはフォールバックとして残る
status_source = "claude-hooks"

status_source = "claude-hooks" を指定すると、セッション起動時に生成される --settings ファイル経由でClaude Codeのフックがライフサイクル状態をファイルへ書き、ポーラーがそれを最優先で読む。ただし公式ドキュメントは、フックでは「平文の質問・Escによる中断・エラー行」が見えないため、ペインルールによる判定が一致した場合はそちらで上書きする、と説明している。フック連携は精度を上げるが、ペインの読み取りを不要にはしていない。Claude Codeのフック自体の仕組みはClaude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引きが詳しい。

判定が落ちてくる順序を図にすると次のようになる。分岐の精度が要るところなので、ここは図解ではなくフロー図で示す。

つまり「スピナーが無い＝止まっている」と単純に決めつけず、①明示ルール →②ターン終端マーカー →③疑問符の有無 →④前回ポーリングからの変化、という4段で降りてくる。ターン終端の行が出ないまま静かに終わったケースも、変化が止まった時点で finished か waiting に解決される設計になっている。

右側のプレビューが効いているのが分かる。waiting のエージェントが何を聞いてきたのかを、セッションにアタッチせず一覧のまま読める。ヘッダーにはステータス別の件数と、全エージェントのプロセスツリー合計のCPU・RAM使用率が出る。

差分レビューを差し戻す——ctrl+rからCまでがTUI内で閉じる

ここがagent-managerの一番の特徴だ。状態を可視化するツールは他にもあるが、レビューして直させるところまで同じ画面に置いたのがこのツールの設計判断である。

セッション上で ctrl+r を押すと全画面のレビューが開く。左が変更ファイルと増減行数、右がファイル全体（変更行に色が付く）だ。差分だけを抜き出すのではなくファイル全文を出すので、変更が周囲の文脈の中で読める。エージェントが編集を続けていれば差分も更新される。

レビュー画面の主なキーは次のとおり。

肝は最後の C だ。書いたコメントは送信するまでレビュー画面に留まり、C を押すと全部が1つのプロンプトに平坦化され、確認を挟んでエージェントのペインへ届く。差分を見ながら指摘を溜め、まとめて投げ、エージェントが直し始めるのを同じ画面で眺める——という往復になる。GitHubのプルリクエストレビューに近い操作感を、ローカルのエージェントに対してやる形だ。

スコープに「比較先との差分」があるのも実務的で、エージェントが作業ブランチで積んだ変更を、マージ先ブランチと比べて読める。比較先はエージェント自身に宣言させることもできる（次節）。

worktree・revive・MCP——エージェント自身に申告させる

並列運用でもう1つ問題になるのが、複数エージェントが同じ作業ディレクトリを踏み合うことだ。agent-managerはセッション単位のgit worktreeでこれを分ける。

n（新規セッション）フォームの worktree 項目、クイックプロンプトの alt+w、あるいは設定の既定値でオンにすると、セッションはリポジトリの隣の <repo>-worktrees/<名前> に、am/<名前> という新規ブランチで作られる。分岐元はリモートの既定ブランチ（origin/HEAD）が解決すればそれ、駄目ならローカルの main か master、最後に HEAD という順で決まる。gitリポジトリでないディレクトリや、worktree作成に失敗した場合は、共有ディレクトリにフォールバックせずエラーで停止する。

セッションは x で終了できる。終了するのはtmuxセッションであって記録ではないので、行は dead として木に残り、名前・グループ・会話IDを保つ。v を押すと同じIDで復活し、会話IDが分かっていればその会話そのものを再開する。生成された設定から、各ツールの再開コマンドはこうなっていた。

IDの入手経路は2通りに分かれている。claude・grok・geminiは session_id_flag = "--session-id" でマネージャ側が採番したIDを渡して起動する。codexとopencodeはツール自身がIDを作るので、起動後に読み取る（session_store）。IDが取れないときは作業ディレクトリの直近の会話を再開するフォールバックになり、その旨がステータス行に表示される。同じディレクトリを共有するセッションが複数あると別の会話に着地しうるためだ。

さらに、agent-managerはエージェント側から自己申告させる経路を持つ。バイナリ自身がMCPサーバー（agent-manager mcp、stdio）を内蔵しており、マネージャが起動・復活させたセッションにはこれが載る。MCP対応エージェントからは rename・review_repo・review_base・review_mode がネイティブのツールとして見える。

・rename——名前を付けずに起動したセッションは claude-a1b2 のような仮名になり、最初のプロンプトでエージェント自身に短い名前を付けさせる
・review_repo——作業ディレクトリが複数リポジトリを抱える親フォルダのとき、エージェントが「自分が触っているのはこれ」と宣言する。gitリポジトリ内かどうか検証されるので、宣言は推測でなく事実になる
・review_base——自分のブランチが何と比較されるべきかを宣言する

登録方式はツールごとに異なり、claudeは生成した --mcp-config ファイル、codexは -c mcp_servers... の上書き、opencodeは OPENCODE_CONFIG のマージファイル、grokとgeminiは初回起動時の mcp add --scope user を使う。MCPを使わない場合でも rename・review-repo・review-base はCLIサブコマンドとして機能する。

類似ツールとの比較——agent-managerとherdr・ルーター型・統制型の違い

「複数のAIエージェントを扱うツール」は増えており、名前だけでは違いが分からない。どの層の問題を解いているかで並べると整理できる。

※★数・ライセンスは2026年8月2日にGitHub APIで取得した実測値。

この表から読み取れることを言葉にしておく。

・agent-managerとherdrは近い層にいるが、tmuxとの関係が正反対。herdrは自前の多重化実装でtmuxを置き換える方向、agent-managerはtmuxに乗ったうえで自分専用のサーバーへ隔離する方向。既存のtmux運用や設定を活かしたいならagent-manager、単一バイナリで完結させたいならherdrという分かれ方になる
・差分レビューを内蔵しているのは、この5つの中ではagent-managerだけ。他はいずれも「状態を見る」「接続先を決める」「工程を縛る」までで、コードを読んで指摘を返す部分は担当外だ
・ルーティング層と統制層は競合しない。Claude Code Routerとは｜9種のAIコーディングエージェントを1つのローカル窓口に束ねる制御盤が扱うのは「どのモデルへ流すか」で、agent-managerが扱うのは「どのセッションが今どうなっているか」。同時に使える

agent-managerが対応ツールとして挙げるGrok Buildについては、CLI側の実体をGrok Buildとは｜xAI公式grok CLIの使い方と「★23K OSS」の正体を実測で解説で扱っている。また、agent-managerが持たないコスト集計の機能は、agentsview徹底解説｜AIコーディングエージェントの履歴・コストをローカル可視化するOSSが扱う領域と重なる——併用すれば埋められる穴だ。

導入前に確認しておきたい点

良いところばかりではない。採用判断に効く事実を並べる。

READMEが自ら挙げる未実装。「まだ無いもの」として、コスト集計・マウスによる操作・エージェント同士が対話する機能の3つが明記されている。最後の点は重要で、agent-managerは複数エージェントを人間がさばくための道具であり、エージェントを自動で協調させるオーケストレーターではない。実際、ステータスの waiting は「人間待ち（ダイアログ・許可確認・平文の質問）」と定義されており、設計思想は「止まったエージェントを検出して人間に見せる」方向にある。自律的に最後までやり切らせる用途を期待すると噛み合わない。

マウスが効かないのは意図的な仕様だ。マウストラッキングをオフにしているため、クリック&ドラッグでのテキスト選択がターミナル本来の挙動のまま使える代わりに、ポインタで一覧を選べない。

tmuxが無いと何もできない。前述のとおり --help すら表示されない。Homebrew経路なら同時に入るが、インストールスクリプト経路では自分で入れる必要がある。

開発が非常に若い。最初のリリースは2026年7月16日で、そこから16日で33リリース。コントリビューターは実質1名（YoanWaiが307コミット、残りはbot 2つ）、オープンなissueは20件ある。仕様やキー割り当てが変わる前提で使うのが安全だ。

ドキュメント間に食い違いがある。docs/configuration.md は初回生成される設定について「Claude Code・OpenCode・Codex・Grok Buildの4つの既定値」と書いているが、v0.17.0で実際に生成された config.toml にはgeminiを含む5ツールの定義が入っていた。READMEの側は5ツールと書いており、configuration.mdの記述が追いついていないと見られる。細かい話だが、ドキュメントを読んで挙動を決め打ちせず、生成された設定を実際に開いて確かめたほうがよい。

worktree削除でgitignore対象ファイルが消える点は前述のとおり。.env を作業worktreeに置く運用をしているなら注意が要る。

まとめ

agent-managerは、AIコーディングエージェントの並列運用を「見る」だけで終わらせず、「読んで直させる」ところまで1つのTUIに畳んだツールだ。他の同種ツールと比べたときの輪郭は次の3点に集約される。

・tmuxを置き換えず、専用サーバー agentmgr へ隔離する。既存のtmux運用と共存でき、TUIを閉じてもセッションは生き続ける
・差分レビューが内蔵され、行コメントが1つのプロンプトになってエージェントへ戻る。この往復が同じ画面で閉じるのが最大の差別化点
・エージェント側から自己申告させる経路（内蔵MCPサーバー）を持つ。セッション名・レビュー対象リポジトリ・比較先をエージェント自身に宣言させられる

一方で、コスト集計もマウス操作もエージェント間の自動協調も現時点では無い。tmuxは必須で、開発は始まったばかりだ。「複数のエージェントを人間がさばく」という一点に絞られた道具として見れば、その一点についてはよく作り込まれている。まずは --version が通ること、そしてtmuxが入っていることを確かめるところから始めるのがよい。

参照ソース

・YoanWai/agent-manager (GitHub) — リポジトリ本体。README・LICENSE（MIT）・リリース情報
・agent-manager docs/usage.md — キー割り当て、クイックプロンプト、worktree、kill/revive、MCP、差分レビュー、グループ、ステータス、統計、テーマの仕様
・agent-manager docs/configuration.md — config.toml の置き場所と [tools.<name>] の各フィールド仕様
・agent-manager 公式サイト — プロジェクトのランディングページ
・本記事の実測値（終了コード・生成された config.toml・チェックサム）は、2026年8月2日にmacOS 14.5（arm64・tmux未導入）で v0.17.0 のリリースバイナリに対して確認したもの