tmux：汎用ステータスバー、画面分割、リモートから
複数エージェントの分業まで
2026年2月にopenclawに触発されてtmuxを使い始め、ステータスバー、画面分割、リモート開発から複数エージェントの分業へと積み上げてきました。
まずステータスバーを整える
最初に手を入れたのはステータスバーです。手元にある多くのAIエージェントCLIの状態を1本のbarにまとめました。2026年2月、 openclaw に触発されてtmuxを使い始めた私にとって、これが最初の実践でした。
tmuxを使い始めた頃には、定番のCLIに加えて時々試すCLIもいくつか併用していました。terminalのウィンドウを複数開くと収拾がつきません。YouTubeの 『tmuxの使い方と基本設定 入門から残業まで、1本の動画で全部わかる！』 を見ながらコマンドに慣れ、まずClaude Codeのstatuslineに手を入れました。
~/.claude/settings.json を設定し、 statusLine.command 自作のものを指すようにします。 statusline.sh：
statusline.sh の中ではいろいろやっています。session ID、cwd、git branchと変更ファイル数、model display name、session cost、contextの使用率を取得し、1回のjqですべて抽出します（毎秒15回forkするoverheadを避けるためです）。
書き慣れてくると、もっと見たくなりました。Claude / Codex / Geminiそれぞれの5時間・7日間の利用枠に、CPU、MEM、DISK、NETもです。ただ、Claude Codeのstatuslineで見えるのは現在のsessionだけで、sessionをまたいだ累積の利用枠は見えません。この層を切り出してtmuxのステータスバーに載せました。
~/.tmux.conf 長い status-format[1]を書き、各欄で自作の tmux_status.sh を呼んでデータを取得し、catppuccinの配色を当てました。
status-interval 5 で5秒ごとに更新します。このscriptは最初Pythonで書いていました。5秒ごとにinterpreterをforkし、13欄なら13個のprocessが立ちます。tmux serverが一度落ちた後、shell + jqに書き直してinterpreterのstartup overheadを省きました。
この時点で、私にとってtmuxはまだ「きれいなステータスバーを載せる容器」でした。その後ようやく本来の用途である画面分割を使い始めます。
繰り返し使う3種類のpaneレイアウト
繰り返し使うpaneレイアウトは3種類で、特に多いのが縦4列の等幅配置です。基本コマンドを覚えた後は、この数種類に落ち着きました。
1. 縦4列を等幅に分割
4つのAIエージェントCLIを実際に同時稼働させます。各列に独立した会話を1つずつ置き、taskをdispatchしたら4列を見渡すだけで、誰が終わり、誰がまだthinking中で、誰に返事が必要か分かります。等幅なので左から右へ1秒で見渡せ、どれがどこにあるか覚える必要もありません。
2. 中央を十字に分ける4分割
画面が大きいときに使います。4つの区画にそれぞれ固定の役割を割り当てます。今は左上にメインの会話、右上にcodeやファイルツリーのプレビュー、左下に比較用の情報（CLIの機能表、provider/modelの仕様）、右下に補助CLI（qwenなど）を置いています。
縦4列と比べると、「縦方向」の情報密度を増やせます。logのように縦長が向くpaneもあれば、表やcodeのように四角い領域が向くpaneもあります。十字レイアウトなら両方を収められます。
3. メイン + サブのsub-agentレイアウト
左の大きなpaneでmain agent（ほとんどの場合Claude Code）を動かし、右側は横に4つの小さなpaneへ分けてsub-agentや子taskを動かします。mainがタスクを振り、右のpaneが並行して動きます。状態も並行して見られ、終わったら左へ報告します。
このレイアウトが、後述する中継システムの原型です。「私が手動でdispatch」を「skillが自動でdispatch」に置き換えただけです。
接続が切れるたびにやり直すなんて、ばかばかしい
tmuxを入れる前は、sshで開発マシンに入って長いbuildを走らせても、接続が切れると最初からやり直しでした。tmuxに変えてから、この流れが途切れることはなくなりました。
その瞬間に気づきました。tmuxは画面分割ツールではなく、processの容器なのだと。
それ以来、リモートのsessionはすべてtmux経由にしました。hostごとにdefault sessionを1つ置き、sshで入ったらまず tmux a || tmux new -s defaultします。素のshellで直接何かを実行することはありません。
さらに tmux-resurrect + tmux-continuum の2つのpluginを入れ、15分ごとにレイアウト全体を自動snapshotします。再起動後にtmuxが立ち上がると自動でrestoreします。~/.tmux.conf に書くのは2行だけです。
自宅のmac miniを再起動しても、戻ってくるとsessionは元の位置にあります。
自宅のMac mini、外出先のMacBook、移動中のiPhone
tmux-resurrect + tmux-continuum 運用が安定すると、自宅のmac miniを24/7稼働させ、メインの開発マシンにしました。
私のdefault sessionはtmuxで常に動いています。ソースコードはそのマシンにあるので、クラウドストレージでファイルを同期する必要も減りました。MacBookを持って外出 → sshで自宅に接続 → tmux a → 午前中に書きかけたpromptの続きを書きます。通勤中にideaを思いついたら、メモする代わりにそのsessionへ直接入力します。
「そのsessionへ直接入力する」のはノートパソコンなら快適ですが、スマートフォンではつまずきます。
私は4つのエージェントを見るために縦4列の等幅レイアウトを使っています。スマートフォンからsshすると横幅が足りず、どの列を見るにも prefix + z zoom inして全画面に広げ、見終わったらzoom outして次の列に切り替えなければなりません。エージェントとやり取りするたびに2つの操作が増え、少し作業するだけで疲れます。
tmux-webuiを作った
スマートフォンからtmuxへ接続するため、まず既存の選択肢を3つ試しましたが、どれも足りませんでした。
iSH
iPhoneで使える無料のLinux shellです。リモートのtmuxへssh attachするには十分ですが、長期の作業には向きません。Alpineといくつかのツールしか動かせないからです。
Blink Shell（自分でビルド）
App Store版は有料ですが、GitHubにあるオープンソース版は自分でビルドできます。iOS開発はまったく未経験だったので、sideloadの一連の作業をClaude Codeに手伝ってもらいました。free developer accountでは7日ごとに再署名が必要です。
mosh（断念）
ネットワークを切り替えても接続が切れないようにしたかったのです。理屈の上では魅力的ですが、メインのmacにはメモリの余裕がなく、mosh-serverを長く動かすとメモリを使い果たしてマシン全体が固まりました。
3つとも行き詰まったので、tmux-webuiを作ることにしました。tmuxのpaneを直接ブラウザに持ち込み、ssh clientやmoshで苦労する部分を飛ばします。この発想はClaude Code自身のremoteモードより先です。remoteが出た後も、私はtmuxを使うことのほうが多いです。
nativeのiOS appではなくwebを選んだ理由は現実的です。XcodeもTestFlightも、年間99米ドルも不要で、ブラウザがあるデバイスなら何でも使えます。その代わり、authと通信の暗号化を自分で処理する必要があり、この層はCloudflare Tunnelに任せました。
機能はシンプルです。すべてのsessions / windows / panesを一覧表示し、paneをタップするとそのリアルタイム出力を見られます。左右のスワイプで切り替え、2本指で拡大縮小し、PWAをホーム画面に追加してappとして使います。タッチ操作はBlink Shellから学びました。1か月以上使ったので、毎日使うgestureとdemo用でしかないものの違いが分かります。入力側にはskill補完用のpaletteも付け、一覧を見れば何を呼べるか分かるようにしました。
意外にも、いちばん便利だったのは画像のアップロードです。スマートフォンで写真やスクリーンショットを撮ってwebuiにドラッグすると、バックエンドが uploads/ に保存してローカルのパスを返します。そのパスを開いているエージェントのpaneへ貼れば、エージェントはReadで直接読み取れます。通勤中に見つけた面白いデザイン、bugのスクリーンショット、ホワイトボードのラフをその場でエージェントに渡して質問を続けられます。帰宅を待つ必要はありません。
複数エージェントに戻る。今度はtmuxのpaneをcellとして使う
複数エージェントに取り組んだ理由は5つあります。最大の理由は、メインのcontextを雑務で埋めたくなかったことです。
メインのcontextを圧縮せずに済む
ほかのエージェントに任せた細部（資料探し、testの実行、boilerplateの作成）がmainのcontextを埋めません。残った容量を、本当にメインの頭脳による推論が必要な部分に使えます。
並行して速く進める（git worktreeと併用）
1つのtaskを並行できる子タスクに分けられます（複数ブランチでの試行錯誤、N個のPRの同時進行など）。各paneにgit worktreeを割り当てれば、作業ディレクトリも干渉しません。一本だった時間軸を平らにできます。
理由を整理した後は、既存の選択肢の制約を、浅いものから順に3つ見ていきます。
Headlessモード
claude -p、codex -p などです。速く動き、スクリプトにも組み込みやすい一方で、機能が減ります。skillは読み込まれず、MCPにも接続できず、自作のエージェントも使えません。呼び出すたびにゼロから始まり、会話の文脈が続きません。独立したtaskならOKですが、状態を共有する協業には足りません。
私が欲しいのは「CLIをまたぎ、各CLIの機能をフルに使う複数エージェント構成」です。1つのtaskの中で、各CLIの得意分野に応じて仕事を割り振り、それぞれが自分のskill / MCPを使い、互いに通信できるものです。既存の3案では実現できないので、tmuxのpaneを土台に自分で仕組みを重ねました。この仕組みを tmux-relayと呼びます。以下の「中継システム」は、すべてこれを指します。
仕組みは3層
最下層には作業用windowを1つ置きます。paneは常駐させません。main agentがtaskに合うCLIを選び（得意分野はコミュニティの評価と自分で使った好みから判断します）、そこで初めてpaneを開いてそのCLIを起動します。使い終わっても待機させ、長くidleなら回収します。
idleかどうかは、その時点のpaneの画面から判断します。エージェントが入力待ちなのか実行中なのかを出力内容で見分けます。lockも履歴も持たず、毎回画面を見直します。
このidle判定の層は、現時点ではClaude Codeのpaneでしか検証していません。promptや処理中を示す文言はCLIごとに異なるため、ほかのCLIをサポートするには、それぞれの判定ルールを書く必要があります。
完了通知にはpollingを使わず、tmux自身のhookを使います。paneが終了すると、blockされているdispatcherを起こします。
この仕組みには、team agentにある最後の一要素が欠けています。pane同士が直接呼び合えないことです。そこでpublish/subscribeの小さなサービスを別に作り、 session-channel この層を補いました。pane同士はchannelで直接通信でき、中継役を挟む必要がありません。
tmuxがCLIをまたぐエージェントの橋になる
send-keys + capture-panewait-for + Stop hooktmux a どのデバイスからでも接続できますtrade-offは明確にしておく
send-keysはプレーンテキストでtyped schemaがありません。stdoutのJSON Linesで補います。- pane bufferにはhistory-limitがあります（私は10000行に設定しています）。長いtaskの途中の出力は切り捨てられます。
- tmuxは元々message busではありません。message reliabilityは自分で処理する必要があります（signal file + retry）。
- フル機能で動かすとheadlessよりリソースを使います。複数のpaneでそれぞれフル機能のCLIを動かせば、メモリはすぐに消費されます。
おまけのコツ：contextが埋まりかけたときのhandoff
これは「複数のpaneを同時に動かせる」環境でしかできません。あるsessionのcontextが70-80%まで使われ、このまま書き続けるとcompact後に品質が落ちそうなとき、新しいtmux paneで同じCLIを起動します。そして、埋まりかけたsessionに戻ってこう伝えます。
書き終えたら新しいpaneに handoff.md を読ませて作業を続けます。元のsessionは自然にcompactするか、終了させます。1つのCLI sessionが自分でcompactすると、失われた細かなニュアンスを引き継ぐ先がありません。複数paneなら受け取る相手がいます。
この仕組みで得られるのは「今、誰が何をしているか、いつでも見える」+「CLIを選ばない」+「contextの引き継ぎで取りこぼさない」ということです。複数エージェントのdebugで詰まったらtmuxを開けば、各エージェントがpromptのどの行で止まっているかひと目で分かります。
サブスクリプションで使うQAエージェントを常駐させ、APIは使わない
日常のQAには、サブスクリプション版のCLIをtmuxのpaneで動かすほうが、token課金のAPIよりずっと安く済みます。複数エージェントの仕組みは「taskが来たときだけ割り振る」ものですが、QAは別の場面です。エージェントに作業をさせるのではなく、調べてもらったり、一緒に考えたり、その時点の状況を整理してもらったりします。ここをAPI（Anthropic / OpenAI / Google API）で動かすと、質問するほど費用が増えます。
私はtmuxにpaneを1つ常駐させてサブスクリプション版のCLIを動かし（Claude Code、Codex、Geminiはいずれも月額プランがあります）、スマートフォンの自作dashboard widgetから質問を入力しています。裏側では同じように send-keys でそのpaneへ送りますが、「token従量課金」ではなく「サブスクリプションの定額枠」で動きます。
画像にある立ち絵はLive2Dで作りました。マウスを動かすと視線が追いかけ、エージェントの回答がstreamingされている間は口が開閉します。純粋に見た目の細部ですが、長く話していると確かに少し相棒がいるような感じになります。
API課金 vs サブスクリプション + tmux pane
- APIを使う場合：質問のたびにtoken単位で課金され、質問が増えると請求額も跳ね上がります。利点は時間帯ごとの利用枠がなく、無制限に並行実行できることです。
- tmux pane + CLIのサブスクリプションを使う場合：月額固定で、5時間 / 7日間の利用枠を使い切っても予想外の請求は来ません。その代わり利用枠には厳格な上限があり、並行実行を無制限に増やすことはできません。
tmux paneがこの方法の鍵です。CLIの「対話モード」をリモートからsend-keysで呼び出せる端点に変え、どのデバイスからでも操作できるようにします。
今のstackの全体像
自宅のmac miniではdefault sessionが24/7で動いています。朝は書斎で起動してssh attachし、外出時にdetach、通勤中はスマートフォンのPWAから接続し、外ではMacBookに切り替えます。その間ずっと同じsessionを使い続け、途切れません。ステータスバーでCLIをまたぐ利用枠とシステムの状態を見えるようにし、複数エージェントが必要なtaskは中継システムへ渡して調整させます。私は結果を見て判断するだけです。
この3か月を振り返ると、ステータスバーから画面分割、リモート、複数エージェントの編成まで、どの層も事前に計画したものではありません。そのときの困りごとを解決するために手を動かし、終わってから次の困りごとを見てきました。tmuxをずっと土台に置き換えずに済んだのは、その都度ちょうど必要なだけの機能があったからです。
この一式は元々自分だけで使うつもりでした。今後、順次整理してオープンソースにします。tmux-webui、tmux-relay、session-channel…各ツールをきれいに切り分け、文書を明確にし、単独でインストールできるまで依存関係を削ります。具体的な時期は決めていません。できたものから公開します。
譲れない要件を選び、どの方式が先に候補から外れるかを見る
headless、sub agent、team agentの3つのカードには、私自身が使って行き詰まった点を書いています。あなたの条件に置き換えれば、先に候補から外れる方式は別かもしれません。下の譲れない要件を選ぶと、5行の表が得られます。この記事で挙げた5種類の実行方式を1行ずつ並べ、候補から外れたセルには、その理由となった本文の原文をそのまま表示します。すべてブラウザ内で動き、何かを貼り付ける必要も、データが外へ送信されることもありません。
判定に使う定数はすべて本文から取っています。各セルに表示する除外理由は本文の原文です。headlessの2項目は「Headlessモード」のカード、sub agentとteam agentはそれぞれのカード、中継システムの項目は「trade-offは明確にしておく」とidle判定の段落にあります。元々は別の方式を論じた引用を他の行にも当てはめる場合、そのセルには括弧書きで説明を加えます。これらの制約は、2026年2月からの3か月間、1人が自分のmacでいくつかのCLIを使った観察であり、各CLIベンダーの仕様書ではありません。本文に書かれていないセルはすべて「記載なし」とし、既定値を勝手に補いません。そのセルに表示される引用符のない文は、本文に何が書かれていないかを説明するもので、本文の原文ではありません。
まず1つの方向を選ぶ。4つ同時には進めない
この記事では4つの活用の方向を挙げました。多くの人が一度にすべて導入しようとすると行き詰まります。順序を間違えて環境を散らかすと、元に戻すのも大変です。
あなたの開発環境と今いちばん困っている点をAIに伝え、どれから試すとよいかと、最初の1週間にやる具体的な3つのことを選んでもらってください。
関連資料
この3か月間に実際に参照し、設計上の判断にも影響した資料です。
| 資料 | 重要な理由 |
|---|---|
| tmux man page | 最初から通して読むと、普段使っていない機能がいかに多いか分かります。pipe-pane / capture-pane -p / wait-for 見落としていたこうしたprimitiveが、後にCLIをまたぐ編成の土台になりました。 |
| 『tmuxの使い方と基本設定 入門から残業まで、1本の動画で全部わかる！』 | この3か月間、tmuxの基本的な操作感を身につける上で主に参考にした動画です。中国語で、実践中心、無駄がありません。 |
| openclaw | 私がtmuxに触れるきっかけです。openclaw自体はtmuxではなくprocess spawnを使いますが、「複数のエージェントを一緒に働かせる」という発想をくれました。 |
| Blink Shell | 高品質なiOS向けSSH clientで、タッチgestureの設計も優れています。後にその操作をtmux-webuiへ取り入れました。 |
| iSH | iPhoneで使える無料のLinux shellです。mac miniへssh attachするために最初に試したツールです。 |
| mosh | ネットワーク切り替え時の接続切れを解消するためにsshの代わりにしたかったのですが、メモリを多く使い、主力マシンでは快適に動かず、最終的に断念しました。 |