Agent of Empires (AoE): tmux の上に AI コーディングエージェントの管理層を載せる

解こうとしている問題は「端末が落ちるとエージェントも死ぬ」ではない

AI コーディングエージェントを CLI で走らせる運用の厄介さは、実行そのものより並列化にある。ブランチ A で Claude Code、ブランチ B で Codex CLI を同時に走らせ、片方は入力待ち、片方はまだ生成中という状態を人間が把握し続けるのは、端末タブを増やすほど難しくなる。AoE はこの把握の部分を引き受ける。README の説明では「A session manager for AI coding agents on Linux and macOS」であり、エージェントをブランチ間で並列実行し、TUI またはブラウザから監視し、それぞれを永続セッションに保つ、と位置づけられている。対象読者は、複数のエージェント CLI を日常的に使い分けていて、その待ち行列を人間の記憶で管理している人である。エージェント自体を置き換える道具ではない。すでにインストール済みの CLI を、監視可能な単位に包み直す層だと考えたほうが実態に近い。

実体は tmux セッションで、AoE はその上に状態と画面を足す

README の How It Works は短い。各エージェントは独自の tmux セッションで動くので、TUI を閉じても、SSH を切断しても、端末がクラッシュしてもエージェントは動き続ける。`aoe` を開き直せば、すべてが離れたときのまま残っている。つまりプロセスの永続化は AoE が独自に実装したものではなく、tmux に委譲されている。AoE が付け足すのは、エージェントの状態検出（README では running、waiting、idle、error の 4 状態が挙げられている）、通知、git worktree の管理、Docker によるサンドボックス化、Web ダッシュボード、差分ビューアである。FAQ でも「tmux gives you persistent sessions. AoE adds agent-aware status detection ... all wrapped around your existing tmux workflow」と明言されており、既存の tmux 運用を置き換えるのではなく包む設計だと読める。この構造の帰結として、`tmux attach` で AoE のセッションに直接入ることもできる。AoE が不調でも作業中のエージェントには手が届く、という退避経路が最初から用意されている点は、管理ツールとしては素直な作りである。

インストールは 4 経路、前提は tmux と任意の Docker

README が示す前提は tmux が必須、Docker が任意（サンドボックス用）である。インストール経路は 4 つ。curl で install.sh を流す方法、`brew install aoe`、`nix run github:agent-of-empires/agent-of-empires`、そしてソースからの `git clone` と `cargo build --release` である。起動後の最初の 3 コマンドも README にそのまま載っている。`aoe` で TUI を起動、`aoe add --cmd claude` で Claude Code を走らせるセッションを作成、`aoe serve` で Web ダッシュボードを開始する。TUI 内では `?` でヘルプが出て、下部の情報バーが文脈に応じたキーバインドを表示する。tmux に慣れていない人が最初に覚えるべきは `Ctrl+b d` で、これはセッションからデタッチして TUI に戻る操作だと README が明記している。対応エージェントの一覧は固定ではなく、`aoe agents` を実行すると現在のリストと、そのマシンでの利用可否が表示される。README の説明文では Claude Code、OpenCode に加えて Mistral Vibe、Codex CLI、Gemini CLI、Pi.dev、Copilot CLI、Factory Droid Coding が挙げられているが、どれが実際に動くかは環境依存であり、`aoe agents` の出力で確認するのが唯一の確実な方法になる。

スマホから見られることは、監視の設計を変える

README のデモ画像はデスクトップとスマホの 2 枚に分かれている。デスクトップ側はフルダッシュボード、ターミナル、差分表示。スマホ側は構造化ビューと説明されている。ここは機能リストの 1 行として読み飛ばすより、設計上の選択として見たほうがいい。長い生成を待つ間、PC の前に座り続ける必要がなくなるという意味であり、エージェントの待ち時間を別の作業に充てる前提で作られている。`aoe serve` で起動する Web ダッシュボードは、TUI と同じエージェント群を別の表示形式で見せる。ターミナルビューと構造化ビューの両方が用意されているという記述からは、生の端末出力をそのまま流す画面と、状態や差分を整形して見せる画面が別物として存在すると読める。ただし Web 機能がどのビルド成果物に含まれるかは README からは確定できない。Development の節に `cargo build --features web` という記述があるため、少なくともソースビルドでは feature フラグで切り替わる構成だと推測できるが、Homebrew や Nix 経由のバイナリで同じ機能が有効かは記載がない。ここは導入前に自分で確かめるべき点である。

worktree とコンテナ分離は、並列実行の衝突を減らすための装置

機能一覧には git worktree と multi-repo workspace、そして Docker、Podman、Apple Containers によるサンドボックス化が並んでいる。エージェントをブランチ単位で並列に走らせるとき、同じ作業ツリーを共有すると互いの編集が衝突する。worktree を分けるというのは、その衝突をファイルシステムの層で避けるという意味であり、エージェント側に特別な対応を要求しない。コンテナ分離も同じ発想で、エージェントが実行するコマンドをホストから切り離す。README の前提に Docker が任意として挙がっているのは、この分離を使う場合だけ必要になるからだと読める。注意したいのは、これらが既定で有効なのか、セッション作成時に明示的に選ぶものなのかが README からは読み取れないことだ。`aoe add --cmd claude` という最小の例が示されている一方で、worktree やコンテナを指定する例は README には載っていない。CLI リファレンスへのリンクが別途用意されているので、実際に使う場合はそちらを参照する必要がある。機能があることと、既定で安全側に倒れていることは別の話である。

Windows ネイティブは対象外、WSL2 のみ

README の FAQ は明快である。Windows で動くのは WSL2 経由のみで、ネイティブ Windows はサポートされない。理由も書かれている。AoE は tmux と POSIX のプロセス処理に依存しているためだ。これは実装の手抜きではなく、設計の中心を tmux に置いたことの直接の帰結である。Windows ネイティブを求めるのであれば、この依存を外さない限り対応は来ない。もうひとつの制約は、tmux を必須としている点そのものだ。tmux を使いたくない、あるいは使えない環境では AoE は成立しない。コンテナ内や制限された実行環境で tmux サーバーを立てられない場合も同様である。さらに、状態検出が running、waiting、idle、error の 4 分類である以上、エージェントの出力をどう解釈してこの分類に落としているかが精度を決める。README には検出の仕組みまでは踏み込んでおらず、エージェント側の出力形式が変われば検出がずれる可能性は残る。通知や状態表示を信用しきる前に、自分の使うエージェントで表示が実態と合うかを確かめたほうがいい。

tmux 直使い、あるいは agent-deck との違い

最も近い比較対象は tmux そのものである。tmux は永続セッションを提供するが、エージェントが入力待ちなのか生成中なのかを区別しない。ウィンドウを 5 つ開けば、どれが動いているかは人間が目で見て回るしかない。AoE はこの区別を状態として持つ点で tmux と重ならない。逆に、tmux の設定やキーバインドをすでに作り込んでいる人にとっては、AoE の TUI がもう 1 枚の管理画面として増えることになる。README は `tmux attach` で直接入れることを保証しているので、その往復は許容できる範囲だろう。もうひとつ、README の Acknowledgments は agent-deck（Go + Bubble Tea）に触発されたと書いている。同じ問題領域に対する別実装であり、言語も TUI の実装基盤も異なる。どちらが優れているかを README は主張していないし、この材料から性能や安定性を比較することはできない。判断材料になるのは、実装言語、対応エージェントの範囲、Web ダッシュボードやコンテナ分離といった付随機能の有無である。AoE の場合、Rust で書かれ、MIT ライセンスで、Web と HTTP API のサーフェスを持つことが README から確認できる。

ライセンスと保守コスト

ライセンスは MIT で、リポジトリ直下の LICENSE に全文がある。ただし README は、`src/tui/hyperlink.rs` の 1 ファイルが Apache License 2.0 の下で公開されている herdr 由来のコードを含むと明記し、THIRD_PARTY_NOTICES.md を参照するよう求めている。MIT の単一ライセンスではない部分が 1 ファイルだけ存在するという構成なので、再配布や派生物を作る場合はこの通知ファイルを確認する必要がある。ここでは法的助言はできない。ライセンス判断は自分で、あるいは専門家に確認してほしい。保守の観点では、リリースが v1.15.1 から v1.15.3 まで数日おきに並んでおり、更新の頻度は低くない。追従コストを見積もるなら、自分の環境でどのエージェント CLI を使っているかと、その CLI 側の出力形式の変更に AoE の状態検出がどれだけ追随するかが実質的な変数になる。開発体制については、コミュニティが維持し、Mozilla.ai の支援を受けていると README に記載がある。継続性をこの 1 文だけで判断するのは危ういが、少なくとも単独の個人プロジェクトとして書かれているわけではない。

編集部の結論

採用すべきなのは、Linux か macOS で tmux をすでに使っており、Claude Code や Codex CLI をブランチごとに並列で走らせたい開発者である。ネイティブ Windows しか使えない場合、tmux を増やしたくない場合、あるいはエージェントの実行そのものを自作の仕組みで握っている場合は向かない。導入前に確認するのは `aoe agents` の出力で自分の環境で対象エージェントが利用可能と表示されるか、`aoe add --cmd` でセッションを作ったあと `Ctrl+b d` でデタッチしてもプロセスが残るか、そして Web 機能を使うなら `cargo build --features web` 相当のビルド経路が自分のインストール方法で有効かの 3 点である。

公式情報源

1. agent-of-empires/agent-of-empires on GitHub
2. License: MIT
3. Project website
4. README
5. Releases