multi-agent-shogun レビュー: tmux と YAML で組む 8 エージェント並列構成

multi-agent-shogun が埋めようとしている穴

AI コーディング CLI を 1 本だけ使っていると、作業は本質的に直列になる。1 つのタスクが終わるまで次の指示を出せず、待ち時間の分だけ人間の判断が止まる。multi-agent-shogun はこの待ち時間を、複数の CLI プロセスを同時に走らせることで潰そうとする。README の説明では、1 つの命令から 7 体のワーカーと 1 体の戦略役が並列に動き、ユーザーは次の命令をすぐ出せる。対象読者は、Claude Code や Codex などの CLI をすでに日常的に使い、単一セッションでは捌けない量のタスクを抱えている開発者だ。CLI ではなく API を前提にしたフレームワークとの違いは後述するが、この設計は「定額契約の CLI を何本も同時に走らせる」という課金形態を前提にしている点で、他の多くのマルチエージェント構成とは出発点が異なる。

Shogun → Karo → Ashigaru という tmux 上の指揮系統

構成は README の図で明示されている。最上位の Shogun がユーザーの命令を受け、Karo がタスクを分解して 7 体の Ashigaru に配分し、軍師に相当する Gunshi が戦略役として並ぶ。各エージェントはそれぞれ独立した tmux ペインで動くため、進行状況は画面を眺めるだけで把握できる。README はこの点を「Every agent runs in a visible tmux pane」と表現し、ログが黒箱にならないことを利点として挙げている。調整の仕組みは YAML ファイルと tmux そのもので、README の比較表では coordination cost を「Zero (YAML + tmux)」と記載している。エージェント間の受け渡しはディスク上の YAML を介し、ポーリングではなくイベント駆動で進むと説明されている。つまりメッセージバスやブローカーを立てるのではなく、ファイルの読み書きと tmux のペイン間通信に責務を寄せている。この割り切りが、後述する運用上の制約と表裏になっている。

起動までの手順と設定の入口

README の Quick Start は短い。git clone の後、bash first_setup.sh を実行し、source ~/.bashrc で PATH を読み直す。初回のみ claude --dangerously-skip-permissions を起動して OAuth と Bypass Permissions の承諾を行い、/exit で抜けたうえで bash shutsujin_departure.sh を叩くと全エージェントが立ち上がる。first_setup.sh は設定、依存関係、MCP のセットアップを一度に処理すると説明されている。Shogun ペインに自然言語で命令を打ち込むのが操作の基本で、README の例では「Build a REST API for user authentication」のような一文を渡すと、Shogun が委任し、Karo が分解し、7 体が並列実行する流れが示されている。前提は tmux、bash 4 以上、そして Claude Code、Codex、Copilot、Kimi、OpenCode、Antigravity のうち少なくとも 1 つだ。Windows を含む完全なインストール手順は README の別節に譲るとされているため、この記事では確認できていない。設定キーの網羅的な一覧も README の抜粋からは読み取れない。

定額 CLI を前提にしたコスト設計とその帰結

README は「Why CLI (Not API)?」という節を設け、8 エージェントを API 経由で Opus 級で回すと 1 時間あたり 100 ドル超になると試算し、CLI の定額契約なら月およそ 200 ドルで済むと対比している。この数字は README の主張であり、本記事で検証したものではない。重要なのは金額そのものより、設計思想が「使い放題を前提に、遠慮なくエージェントを増やす」という方向に振り切れている点だ。README も「Use AI recklessly」という表現でそれを認めている。裏を返せば、API の従量課金でこの構成を組むと、調整そのものではなく並列度が直接コストに跳ね返る。8 本のペインが同時にトークンを消費する状況では、1 本のときとは費用の伸び方が変わる。定額契約を持たない読者にとって、この設計は魅力的ではなく危険な選択肢になる。

7 つの CLI を混在させられることの実務的な意味

README の比較表では、Claude Code の Task ツールや Agent Teams、LangGraph、CrewAI がそれぞれ 1 社または API 前提なのに対し、multi-agent-shogun は 7 つの CLI を扱えるとされている。対応先は Claude Code、OpenAI Codex、GitHub Copilot、Kimi Code、OpenCode、Cursor、Antigravity で、v5.0.0 のリリース名は「OpenCode First-Class Support」、v5.1.0 は「Karo as Traffic Controller」となっており、対応の広がりと Karo の役割変更がリリース単位で進んでいることが読み取れる。CLI を混ぜられることの実利は、モデルごとの得意分野や契約状況に応じてワーカーを割り当てられる点にある。ただし README の抜粋では各 CLI の設定方法の詳細までは示されておらず、混在構成を組む際にどこでモデルを指定するのかは確認できていない。表の「Default Model」列も途中で切れている。

向かないケース: 並列度が判断コストを上回るとき

この構成の最大の制約は、技術的なものではなく人間側にある。8 本のペインが同時に動くと、出力も 8 本分になる。README は可視性を利点として挙げているが、可視性が高いことと読み切れることは別だ。さらに README 冒頭には、作者自身が 10 エージェント構成を解体し、判断を担う単一エージェントへ縮小したうえで後継の kagemusha を作ったと書かれている。後継が運ぶのはエージェントではなく「judgment loop（修正→原則→常設ルール）」の形式だと説明されており、並列に走らせること自体が目的化していたわけではないことがうかがえる。したがって、単発の小規模タスク、仕様が固まっていない探索的な作業、あるいは出力を最後まで読む時間が取れない状況では、この構成はオーバーヘッドの方が大きくなる。multi-agent-shogun 自体は現在もそのまま動作すると README は述べているが、作者の運用がそこから離れたという事実は、採用判断の材料として重い。

LangGraph や CrewAI との設計上の違い

比較対象として README が挙げる LangGraph は、グラフベースの状態機械としてエージェント間の遷移を定義し、LangSmith によるトレースを備え、v0.2 以降で並列ノードを扱う。CrewAI はロールベースのエージェントを pip で導入し、OpenTelemetry で観測する。どちらも調整の状態をプロセス内部または専用基盤に持つのに対し、multi-agent-shogun は調整の状態をディスク上の YAML と tmux ペインに置く。この違いは、障害時の復旧と再現性に直結する。YAML は diff もバージョン管理もできるが、LangGraph のような実行トレースや再開機構は README からは読み取れない。逆に LangGraph 側は Postgres や Redis といったインフラを要求すると表に記載されており、シェルスクリプトだけで完結する multi-agent-shogun とは導入の重さが質的に異なる。どちらが優れているかではなく、状態をどこに置くことを許容できるかの選択だ。

ライセンスと保守の見通し

ライセンスは MIT で、リポジトリはアーカイブされておらず、最終 push は 2026 年 8 月 6 日、直近のリリースは v5.1.0、v5.0.0、v4.6.0 と 2026 年 4 月から 5 月にかけて続いている。MIT なので fork して自組織向けに改変する余地は広いが、これは法的助言ではないため、実際の利用条件は各自で確認してほしい。保守の観点で見落とせないのは、README 冒頭の後継プロジェクト kagemusha への言及だ。multi-agent-shogun はそのまま動くと明記されている一方、作者の関心が judgment loop の形式を運ぶ側へ移っているなら、今後の変更が並列オーケストレーションの改善に向かうとは限らない。依存先は tmux と bash、そして各社 CLI の認証とコマンド体系であり、CLI 側の破壊的変更がそのまま影響する。7 つの CLI を追い続けるコストは、単一 CLI 前提のツールより確実に高い。導入前に、自分が使う CLI だけに絞って動かせるかを first_setup.sh の設定で確かめておく価値がある。

編集部の結論

導入を検討すべきなのは、Claude Code などの CLI を定額サブスクリプションで契約済みで、tmux と bash 4+ の環境があり、8 エージェント分の作業を並列に流すだけのタスク量があるチームだ。逆に向かないのは、API の従量課金で運用している場合、Windows ネイティブ環境しかない場合、あるいは単発の小規模タスクしかない場合である。導入前に確認すべきは first_setup.sh が書き換える設定ファイルの場所と、claude --dangerously-skip-permissions で Bypass Permissions を許可する運用が自組織のポリシーに合うかどうか。加えて、作者自身が 10 エージェント構成を解体して単一エージェントの kagemusha に移行しているという事実は、この構成が万人向けの完成形ではなく、並列度を上げるほど管理側の判断コストが増えることを示している。まずは Karo 1 体と Ashigaru 2 体程度に減らして tmux ペインのログを読み切れるかを試し、読み切れないなら並列化自体を見送る判断が妥当だ。

公式情報源

1. Issues
2. License: MIT
3. README
4. Releases
5. yohey-w/multi-agent-shogun on GitHub