amux - 人間と AI エージェントのための terminal multiplexer
AI coding agent は、リポジトリを読み、コードを変更し、テストを実行できるようになっています。それでも、人間と agent が同じ操作面にいるとは限りません。人間は端末ウィンドウを見ていますが、agent はログ断片、スクリーンショット、一時ファイル、あるいはチャット文脈を読んでいることが多いです。コマンド終了を待つ、今の pane を識別する、scrollback を読む、別の agent に出力を渡す、といった場面で、脆い script や text parsing に戻りがちです。
今日紹介する weill-labs/amux は、この問題にかなり直接向き合うツールです。Go 製の terminal multiplexer で、tmux を丸ごと再実装することより、人間と agent が共有できる TUI grid を作ることを重視しています。人間は keybinding で pane を見て操作し、agent は CLI command で structured state を読み、key を送り、条件を待ち、event を購読できます。GitHub の現在の表示では、およそ 29 stars、3 forks、主な言語は Go、ライセンスは MIT。最新 release は v0.5.0 で、2026 年 4 月 15 日に公開されています。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| リポジトリ | weill-labs/amux |
| Stars | 約 29 |
| Forks | 3 |
| 主な言語 | Go |
| ライセンス | MIT |
| 作成日 | 2026 年 3 月 13 日 |
| 最近の更新 | 2026 年 5 月 24 日 |
| 最新 Release | v0.5.0 |
ただの terminal split tool ではない理由
amux の面白いところは、terminal pane の解析済み状態を source of truth として扱う点です。PTY output は VT emulator に入り、その同じ状態から、人間向けの ANSI rendering と、agent 向けの structured output が作られます。
これは「agent に terminal screenshot を見せる」方式とは違います。スクリーンショットは vision model に layout を読ませる必要があり、font、theme、window size の影響も受けます。単純な text capture では、cursor、pane、foreground process、idle state、color などの文脈が落ちやすいです。amux はその状態を明示し、agent が JSON として読めるようにします。
README の方向性をよく表す command は次のようなものです。
amux capture --format json
amux send-keys pane-1 "make test" Enter
amux wait exited pane-1
amux events --filter idleこれは単なる「端末のリモート操作」ではありません。terminal session を、観測でき、待てて、組み合わせられる workspace にする設計です。
Agent API: capture、wait、events
amux の agent API は普通の CLI です。特定の SDK や言語を前提にしません。まず重要なのは capture です。session 全体も、特定 pane も取得できます。plain text でも JSON でも返せます。現在の visible screen だけでなく、retained scrollback history も含められます。
JSON capture には、session、window、pane position、cursor、terminal metadata、pane content、idle/exited state、last output time、current command などが含まれます。agent にとっては、大きな terminal text を読むより、これらの field を見たほうが次の判断をしやすくなります。
次は wait です。代表的には次のような条件があります。
amux wait idle pane-1 --timeout 30s
amux wait ready pane-1
amux wait exited pane-1
amux wait content pane-1 "PASS"これは agent script でありがちな polling を減らします。以前なら sleep し、output を grep し、コマンドが終わったかを推測していたところを、multiplexer 側の状態に基づいて block できます。
三つ目は events です。layout、output、terminal、idle、busy、exited、client connect/disconnect などの event を NDJSON として流します。長く動く agent は毎回 capture するのではなく、event stream を購読できます。自前の orchestration logic にも接続しやすい形です。
同じ pane を人間と agent が見る
amux は人間を外に追い出しません。これは今も TUI です。pane、window、split、zoom、copy mode、keybinding、attach/detach があります。default prefix は Ctrl-a で、split、pane 移動、zoom、copy mode、window 作成、server reload などができます。
この点は AI workflow では重要です。多くの headless automation tool は command 実行には強い一方で、人間が現場を見にくかったり、途中から操作を引き継ぎにくかったりします。amux では、人間と agent が同じ pane 群を共有します。人間は agent が何を実行しているかを観察でき、agent は人間の操作後の状態も読み取れます。
README では、pane history が server 側に保持されることも説明されています。client は attach 時に history を復元し、それぞれの viewer が copy-mode の scroll position や search state を持てます。detach、reattach、hot reload、crash recovery の後も、scrollback が比較的復元しやすい設計です。
Remote host と multi-agent workflow
amux は remote hosts を設定でき、remote session の pane を local view に写せます。現在の実用的な transport は主に SSH です。configuration には transport preference もありますが、mosh は認識されるものの、まだ実装済みの経路ではありません。
このため、amux は単なる local split tool ではありません。local shell、remote GPU machine、build environment、別の開発機を、同じ session view に置けます。agent は pane name や ID で command を送り、人間は TUI で全体を監督できます。
README には、より上位の workflow も出ています。pane に task や issue metadata を付ける、worker PR の CI 状態を確認する、どの pane がどの task を担当しているかを見る、必要なら対応する pane に message を返す、といったものです。これらは core protocol そのものではありませんが、想定している利用場面を示しています。複数の terminal worker、複数の agent、一人の human supervisor、そして復元可能な状態層です。
tmux script との違い
単に画面を分割するだけなら、tmux はすでに非常に成熟しています。amux の違いは、agent が必要とする操作を first-class にしていることです。
tmux でも capture-pane はできますが、取得できるのは人間が読むための text に近いものです。ANSI、line wrapping、pane width、application state によって parsing が難しくなります。amux は structured JSON と retained history を直接提供します。
tmux control mode でも統合はできますが、呼び出し側は raw pane content をかなり処理する必要があります。amux の wait idle、wait content、events は、automation script 用の synchronization primitive に近いです。
expect/pexpect のような headless tool は、独占的な automation には向いています。一方で、人間が自然に介入しにくいです。amux の選択は、共有画面を残しながら、同じ状態に agent-readable/writeable interface を足すことです。
もちろん、tmux の完全な置き換えではありません。README でも、human+agent pairing に必要な splits、windows、zoom、remote hosts、searchable choosers、agent API に集中していると説明されています。tmux の複雑な hooks、session groups、成熟した plugin ecosystem に依存しているなら、今の amux はそのままの代替にはなりません。
インストールと現在の境界
amux にはいくつかの installation path があります。
curl -fsSL https://raw.githubusercontent.com/weill-labs/amux/main/scripts/install-release.sh | bash
brew install weill-labs/tap/amux
go install github.com/weill-labs/amux@latest初回 server start 時には、専用の terminfo entry を入れます。そのため ncurses の tic が必要です。自動設定を避けたい場合は、明示的に次の command を実行できます。
amux install-terminfo現時点では、いくつか境界もあります。
- 2026 年 3 月に作られた新しい project で、interface や behavior は変わる可能性があります。
- stars はまだ数十で、community feedback や cross-platform edge case はこれから積み上がる段階です。
- tmux compatibility layer ではないため、tmux config や plugin をそのまま移せるわけではありません。
- remote transport は現状 SSH が中心で、mosh はまだ将来方向です。
- agent に real shell を操作させること自体にリスクがあるため、まずは管理された repository と command range で試すのが現実的です。
向いている人
amux は次のような開発者に向いています。
- 複数の AI coding agent を同時に動かし、人間がいつでも観察し引き継ぎたい人。
- agent に test、build、deploy の終了を sleep ではなく確実に待たせたい人。
- terminal output を structured JSON にして、script や agent の次処理に渡したい人。
- local と remote が混ざる開発環境で、複数 worker を同じ TUI から監督したい人。
- tmux に慣れているが、より agent-friendly な実験的選択肢を探している人。
自動化がたまに一つ command を実行するだけなら、普通の shell script で十分です。tmux に深く依存していて、agent が pane を読み書きする必要もないなら、amux のメリットはまだ小さいかもしれません。しかし、複数の agent session に日常的に作業を任せているなら、terminal state の構造化はすぐ実用的になります。
まとめ
weill-labs/amux は、terminal multiplexer を AI agent の文脈で考え直している project です。人間だけが見る split screen でも、人間を外した headless automation でもありません。同じ pane 群を、人間と agent の両方に使えるようにする試みです。
特に価値があるのは、structured capture、blocking wait、event stream、retained history という同期のための部品です。これらは派手な機能ではありませんが、agent が real terminal で詰まりやすい細部を解きほぐします。project はまだ若いですが、方向性は明確です。追っておきたい開発者ツールです。