課題: マルチエージェント CLI 運用が散らばる
Claude Code、Codex、Gemini CLI を同時に回すと、次がバラバラになりがちです。
📑目次
- ウィンドウ配置
- git worktree
- 危険コマンドの承認
- クラッシュ後の再開
通常のターミナル分割や tmux は「端末」を扱えますが、エージェント本体・worktree・ブラウザ・エージェント間メッセージまでは一体管理しません。
wmux が所有する範囲
wmux（wmux.app）は、そのギャップを埋める workspace multiplexer です。デーモン所有の範囲は次です。
- terminals
- agents
- git worktrees
- browser
- channels
tmux が端末を分割するのに対し、wmux は上記を一体で持ち、アプリ終了や OS 再起動後もワークスペース側の状態から再開できる位置づけです。
配布上の前提
配布上の前提は次のとおりです。
- ライセンス: MIT
- テレメトリ: なし
- アカウント: 不要
この記事の範囲
本記事では機能境界、導入手順、運用ガードレール、採用前チェックリストまでを整理し、今日から試す順番を決められる状態にします。
機能比較サマリー（wmux と周辺ツール）
比較の読み方
結論から言うと、wmux の差分は「分割そのもの」ではなく、マルチエージェント作業台をデーモンが所有し続けるかにあります。公式サイトの比較軸を、導入判断向けに分割して要約します。
多重化・永続の比較
| 観点 | wmux | tmux | Windows Terminal / iTerm | VS Code 統合ターミナル | 一般的な agent manager |
|---|---|---|---|---|---|
| 分割ペイン | あり（独立 PTY） | あり | あり | あり | 製品による |
| セッション永続（アプリ終了） | デーモン所有で復帰 | セッション設計次第 | 弱い／製品依存 | IDE 依存 | 製品による |
| OS 再起動後の workspace 復帰 | ワークスペース・scrollback・channel を復帰想定 | 別途設計が必要 | 基本なし | 基本なし | 多くは弱い |
| worktree fan-out（最大8）と hunk harvest | あり | なし（自前） | なし | なし／拡張依存 | 限定的 |
| Orchestrator / Fleet View | あり（例: Ctrl+Shift+A） | なし | なし | なし | 製品による |
協調・ツール・ライセンスの比較
| 観点 | wmux | tmux | Windows Terminal / iTerm | VS Code 統合ターミナル | 一般的な agent manager |
|---|---|---|---|---|---|
| 危険コマンド承認ゲート | あり | なし（自前） | なし | なし | 製品による |
| channels / agent-to-agent | あり | なし | なし | なし | 製品による |
| 実 Chrome + CDP ブラウザ | あり | なし | なし | なし／拡張 | 製品による |
| zero-config MCP | あり（公式表記 84 tools） | なし | なし | なし／手設定 | 手設定が多い |
| ライセンス | MIT | 各実装 | 各製品 | 各製品 | 各製品 |
出典: wmux.app、GitHub openwong2kim/wmux（2026年7月時点）
数値の目安（公式記載）
- worktree fan-out: 最大 8
- MCP: 84 tools（browser / terminal / panes / channels / A2A など）
- scrollback: 最大 999K 行
- Windows Setup.exe v3.37.2: 約 143MB
- 8-pane echo latency p50: 4.6ms（公式計測記述）
配布チャネルでの位置づけ
Microsoft がホストする winget-pkgs でも、PackageIdentifier openwong2kim.wmux 3.37.2 が「Windows terminal multiplexer with MCP server for AI agents」として公開されており、配布チャネル側でも同クラスの製品として固定されています。
wmux とは何か — 端末多重化ではなくワークスペース多重化
何を指揮するレイヤか
wmux の中心は、複数ベンダーの AI コーディング CLI を同じ作業面で指揮するレイヤであることです。
README が明示する検知対象には次が含まれます。
- Claude Code
- Codex CLI
- Gemini CLI
- Aider
- OpenCode
- GitHub Copilot CLI
tmux との境界
tmux との違いは次の一文に集約できます。
- tmux: 端末（PTY セッション）を多重化する
- wmux: 端末に加え、エージェント運用・git worktree・内蔵ブラウザ・エージェント間チャネルまでをデーモンが所有する
永続化で戻るもの／戻らないもの
永続化の意味も誤解しやすい点です。
- 戻る想定: デーモンが PTY と workspace 状態を持つため、アプリ終了・クラッシュ・OS 再起動後に workspace / scrollback / channel 側は復帰する
- 戻らない前提: エージェントプロセスそのものは OS 停止で終わり、再アタッチや Resume が必要
「会話が魔法のように生きたまま」ではなく、「作業台の状態が消えにくい」と捉えるのが正確です。
プラットフォーム対応
プラットフォーム面では次が実務上重要です。
- Windows: ConPTY を直接利用（WSL 不要）。Windows 10 1903+ x64
- macOS: forkpty + 署名・公証済み DMG（Apple Silicon 向け）
- Linux: experimental な AppImage / .deb / .rpm（本番前提にしない）
第三者による製品クラスの裏取り
第三者側でも、製品クラスは origin 以外で再確認できます。
- 韓国語版 Wikipedia: ConPTY / Electron 基盤の AI エージェント向け端末マルチプレクサとして記載し、
winget install openwong2kim.wmuxを推奨ルートの一つとして挙げる - SkillsLLM / wingetgui.com: Claude Code / Codex / Gemini の並列運用・MCP・セッション持続といった主張をカタログ形式で裏取りする
コア機能 — 並列ペイン、worktree fan-out、協調チャネル
分割ペインでの並列実行
1 ウィンドウ内で Claude Code / Codex / Gemini などを各ペインの独立 PTY として並走できます。
主戦場になりやすい使い方は次です。
- マルチベンダー比較
- 「実装は A、レビューは B」といった役割分担（ウィンドウ散在なし）
Fleet View（公式 UI では Ctrl+Shift+A）は、複数エージェントを俯瞰して役割委譲や done-when ループ（.claude skills）を回す入口になります。
worktree fan-out と harvest
1 プロンプトを最大 8 の孤立 worktree に広げ、差分を hunk 単位で all-or-nothing adopt できます。
fan-out / harvest 側の要点は次です。
- ワンクリック PR と cleanup list で、散らばった実験ブランチの回収コストを GUI 側へ寄せる
- ここが「ただの tmux」では足りない理由の中核
- 既に git worktree を手作業で切って比較しているなら、fan-out → adopt の導線が短縮されるかを重点評価する
channels / A2A と承認ゲート
Slack 風 channels と agent-to-agent メッセージでタスク委譲ができます。
協調と安全の境界は次のとおりです。
- 再起動後も unread を含む履歴保持が想定される
- execute approval gate が
rm -rf、git push --force、DROP TABLEのような破壊的コマンドを実行前に止める - 並列運用で増える事故面を GUI 側で抑える意図がはっきりしている
内蔵ブラウザと MCP
実 Chrome + CDP を内蔵し、React 入力や CJK 合成にも対応しています。
MCP とプロバイダ境界の公式説明は次です。
- 初回起動で zero-config 登録
- browser / terminal / panes / channels / A2A などを含む 84 tools
- workspace-scoped token
- wmux 自体は AI API を呼ばず、エージェント出力の自動キャプチャもしない
- 各プロバイダの利用料と ToS 遵守は利用者責任
導入手順 — Windows / macOS とバージョン確認
Windows（推奨は winget）
推奨ルートは次です。
winget install openwong2kim.wmux
代替ルートと注意点は次のとおりです。
- 代替: Chocolatey、Setup.exe、PowerShell ワンライナー
- Setup.exe 注意: SignPath の test 証明書のため SmartScreen で「不明な発行元」になり得る
- 企業端末・SAC 環境: 公式 FAQ でも winget 優先が妥当
wingetgui.com などの第三者カタログでも、Package として openwong2kim.wmux が掲載され、split terminals・browser automation・MCP・session persistence といった説明が再掲されています。
macOS
GitHub Releases の署名・公証済み DMG を Applications に置き、初回で CLI を PATH に通します。現状の配布は Apple Silicon 向けが前提で、Intel Mac のみの環境は issue ベースの確認が必要です。
Linux
experimental ビルドがある一方、本番標準としては扱わない方が安全です。まずは Windows または Apple Silicon macOS で評価する方が再現性が高いです。
導入直後の最小確認
- 単一ペインで Claude Code（または常用 CLI）が起動するか
- 2 ペインで別ベンダーを並べ、Fleet View が見えるか
- アプリ再起動後に workspace / scrollback が残るか
ここまで通らなければ、fan-out や MCP の評価に進む意味は薄いです。
運用ガードレール — 承認、MCP、Web、依存リスク
並列エージェント運用は便利さと同じだけ、破壊半径も広がります。wmux 側で押さえる境界は次です。
承認ゲートを前提運用にする
危険コマンド検知は「ある」だけでなく、意図的に 1 回発火させて止まることを確認してください。ゲートを無効化したまま fan-out すると、worktree 数だけ事故面が増えます。
MCP のスコープを固定する
zero-config は導入摩擦を下げますが、workspace-scoped token と破壊系ツールの扱いをチーム規約に落とす必要があります。どの workspace でどの tools を許すかを先に決めてください。
wmux web は既定が loopback + read-only
入力や外部公開は明示オプトインです。便利だからといって公開エンドポイント化しないことが、最小限の安全策です。
第三者セキュリティ表示も見る
SkillsLLM のカタログページには npm-audit ベースの WARNING 表示があります。
- 製品そのものの公式監査結果ではない
- 依存更新と SBOM/監査を自前で見るきっかけにはなる
- MIT でテレメトリなしでも、「無料＝運用リスクゼロ」ではない
プロバイダ境界を混同しない
wmux はオーケストレーション層です。各 AI CLI の認証、課金、データ取り扱いは provider 側の条件が残ります。
採用前チェックリスト — いつ試し、いつ見送るか
試す価値が高い条件
- Claude Code / Codex / Gemini など複数ベンダー CLI を物理並列したい
- worktree 実験の harvest（hunk adopt / PR）を GUI で回したい
- Windows ネイティブで、tmux 相当にエージェント運用を載せたい
- 承認ゲートと channels を同じ作業面に欲しい
見送りを検討する条件
- Intel Mac のみ、または Linux 本番必須
- 単一エージェント + 既存 tmux / IDE ターミナルで十分
- 署名・SmartScreen ポリシーが厳しく、winget すら通らない企業端末
- experimental ビルドを本番標準にできない制約がある
今日やる検証チェックリスト
- OS 条件を確認する（Windows 10 1903+ x64、または macOS Apple Silicon）
- winget または DMG でインストールし、1 ペインで常用エージェントを起動する
- 2 ペイン並列（例: Claude Code + Codex）と Fleet View を確認する
- 小さな fan-out（2 worktree）で hunk adopt を試す
- 危険コマンドを 1 つ意図的に実行し、approval gate が止まることを確認する
- アプリ再起動後の session resume（workspace / scrollback / channel）を確認する
- MCP ツール一覧と workspace scope を確認する
- チームなら、Web UI の外部公開禁止と provider ToS を明文化する
この 8 項目のうち 2〜5 が通らないなら、本格採用より「比較検証用」に留める判断が合理的です。
筆者の観点
wmux をマルチエージェント作業台として比較するとき、先に置く軸は次の 3 点です。
- 単一ハーネス設定ではなく、複数ベンダー CLI を同一ウィンドウで物理並列できるか
- worktree harvest が手作業の git worktree より少ない手数で閉じるか
- 承認ゲートと再起動後の workspace 復帰が、説明文だけでなく実機手順で再現するか
この 3 点が弱い場合、MCP の数や UI の見た目だけでは標準化の材料として不足しやすいです。
関連記事:
- グラフとループの使い分け｜導入判断チェックリスト【2026】
- Claude CoworkのRecord a skillとは｜Macで画面録画から再利用スキルを作る手順と導入判断
- Claude Opus 5が浅く感じる原因｜lean promptとCLAUDE.md改修
よくある質問（FAQ）
Q1. wmux は tmux の移植ですか？
いいえ。tmux 風の分割 UI を持つ一方、対象は terminal 単体ではなく workspace（エージェント・worktree・browser・channels）です。
Q2. Windows で WSL は必要ですか？
不要です。ConPTY を直接使う設計です。
Q3. macOS Intel でも使えますか？
現状の署名済み DMG は Apple Silicon 向けが前提です。Intel のみの環境は公式 issue 等での確認が必要です。
Q4. Claude / Codex / Gemini を同時に回せますか？
はい。各ペインが独立 PTY として並走し、channels / A2A で協調できます。
Q5. 再起動後も会話はそのまま続きますか？
workspace / scrollback / channel は復帰想定です。エージェントプロセス自体は OS 停止で終わるため、再アタッチや Resume が必要です。
Q6. 料金とテレメトリは？
wmux 自体は MIT の無料配布で、テレメトリなし・アカウント不要と説明されています。各 AI プロバイダの利用料は別です。
まとめ — 今日やる 3 ステップ
- 入れる: winget（Windows）または署名済み DMG（Apple Silicon macOS）で導入し、単一エージェント起動まで確認する
- 並べる: 2 ベンダー並列と approval gate を 1 回体験し、危険操作が止まることを確かめる
- 広げる: 小さな worktree fan-out で harvest 可否を見て、採用・保留・見送りを決める
wmux は「もう一つのターミナル分割」ではなく、マルチエージェント運用の作業台です。まずは小さな検証順で、自分の OS とポリシーに載るかを確認してください。
著者
krona23
IT業界20年以上の実務経験を持ち、日本国内有数のPVを誇る大規模Webサービスで事業部長・CTOを複数社で歴任。Windows/iOS/Android/Webと技術の変遷を経験し、現在はAIネイティブへの変革に注力。DevGENTでは、AIコードエディタ・自動化ツール・LLMの実践的な使い方を日英西3言語で発信中。
コメントを残す