Claude Codeをtmuxの複数ペインで同時に走らせていたら、どれが終わったのか、どれが入力待ちなのか、まったくわからなくなった。
既存ツールのREADMEを眺めて「自分には合わない」と判断し、Rust製の監視TUI claude-panesを自作した。Hooks駆動のステータス管理、ライブプレビュー、最小キーワードジャンプ。それなりに気に入っていた。
翌週、workmuxのdashboardを実際に触ってみたら、欲しかった機能が全部あった。
既存ツールを使わなかった理由
Claude Codeの複数インスタンスを管理するツールは2026年2月時点でかなり充実している。
| ツール | Stars | アプローチ |
|---|---|---|
| claude-squad | 6.1k | セッション+worktree |
| vibe-kanban | 21.5k | Web UI+worktree |
| dmux | 623 | ペイン+worktree |
| workmux | 733 | ウィンドウ+worktree |
共通しているのはgit worktreeでファイルを分離し、セッションやウィンドウを新しく作るという設計思想。タスクごとに隔離された環境を作る。大規模な並列開発には合理的なアプローチだと思う。
ただ、その時点では自分のワークフローに合わないと思っていた。同じ経験ある人も多いんじゃないだろうか。
自分の場合、tmuxのペインを手動で分割してそこでClaude Codeを起動する。レイアウトは作業内容に合わせて都度変える。worktreeで分離するほど大きなタスクではないけど、2-4個のClaude Codeを同じリポジトリ内で並列に走らせたい場面が多い。
既存ツールを使うと、自分のtmuxレイアウトを捨ててツールの管理画面に移動することになる。ペインの配置はそのまま、状態だけポップアップで確認して戻りたい。 そう思って、自作に踏み切った。
この判断の問題点は、READMEとスクリーンショットだけ見て「合わない」と決めつけたこと。workmuxのdashboardを実際に触っていなかった。
ペイン単位の監視ツールはほぼなかった
ペイン単位で管理するツールも探した。
- TmuxCC: Rust製でペインのツリー表示ができるが、承認管理やバッチ操作など機能が多く、自分にはオーバースペックだった
- tmux-agent-indicator: ペインボーダーの色でステータスを表示するプラグイン。軽量だけど、中身が見えないし切替もできない
「ペインの状態一覧 + ライブプレビュー + 即ジャンプ」をpopupで出せるツールが見つからなかったので、自分で作ることにした。
claude-panesの仕組み
Hooks → ファイル → TUI
Claude CodeのHooksを使って、各イベントをファイルに書き出す。TUIはそのファイルを1秒ごとに読み取る。Hooksの通知設定については以下の記事で詳しく書いている:
Claude Code × tmux もう完了通知を見逃さない通知設定開発
Claude Code Hooks (tmux-state.sh)
├─ SessionStart → 「○ mono-and.blog」をファイルに書く
├─ UserPromptSubmit → 「▶ mono-and.blog」に更新 + プロンプト保存
├─ PreToolUse → ファイルのmtimeを更新（ハートビート）
├─ Stop → 「● mono-and.blog」に更新
└─ SessionEnd → ファイル削除ステータスファイルは ~/.claude/pane-state/pane-%42 のようにtmuxのペインIDで分離される。ペインごとに独立したファイルを持つので、複数インスタンスが競合しない。Hookのセットアップは claude-panes setup で自動化した。
最小キーワードで即ジャンプ
自分が一番気に入っている機能。
6つのペインがあるとする。
mono-and.blog [m1] working
mono-and.blog [m2] waiting
dotfiles [d] idle
himawari [h1] working
himawari [h2] idle
claude-panes [c] waiting[m1] [d] [c] のような最小キーワードが自動計算される。d とタイプするだけでdotfilesのペインにジャンプする。フィルタ結果が1件になった時点で自動ジャンプするので、実質1-2文字タイプするだけで目的のペインに飛べる。
同じプロジェクト名が複数あれば m1 m2 のように連番が付く。プレフィックスが被る場合（例: claude-panes と claude-test）は claude-p と claude-t のように最短で区別できるところまで伸びる。
fzfのようなfuzzy finderではなく、プロジェクト名から決定的に一意のキーワードを計算する方式にした。fuzzyだと候補が複数出て選ぶ手間がある。最小キーワードなら確実に1発で飛べる。
使い方
インストールとHookのセットアップ、tmuxへのバインドはGitHubのREADMEに書いている。cargo install → claude-panes setup → tmux.confにバインド追加の3ステップで動く。
workmuxを実際に触ってみたら
claude-panesを公開した翌週、workmuxを改めてインストールして触ってみた。
dashboardに全部あった
workmux dashboard を開いた瞬間、目が止まった。Agent一覧、各ペインのライブプレビュー、ステータス表示、選択して即ジャンプ。claude-panesで作った機能がそのまま入っている。
しかもworkmuxはtmuxのウィンドウ管理から一貫してやってくれるので、セッション作成からdashboard監視まで全部workmux1つで済む。
.workmux.yamlの簡潔さ
プロジェクトルートに.workmux.yamlを置くだけで、workmuxがtmuxウィンドウを自動構成してくれる。実際に使っている設定:
files:
symlink:
- node_modules
panes:
- command: npm run dev
- command: <agent>
split: horizontal
focus: true
percentage: 75たった11行。<agent>はworkmuxが自動的にClaude Codeのコマンドに展開してくれる。files.symlinkでnode_modulesをworktree間で共有するので、npm installを何度も走らせなくて済む。
グローバル設定
~/.config/workmux/config.yamlでデフォルト動作を定義する:
nerdfont: true
agent: "cc team"
panes:
- command: <agent>
focus: true
status_icons:
working: ""
waiting: ""
done: ""agent: "cc team" でClaude Codeのteamモードを指定している。Nerd Fontのアイコンでステータス表示もできる。プロジェクトごとの.workmux.yamlがない場合はこのグローバル設定が使われる。
dashboardを開いた瞬間、「これclaude-panesじゃん」と思った。正確にはclaude-panesがworkmuxだったわけだけど。READMEの機能一覧だけ読んで「セッション管理ツールでしょ」と思い込んでいた自分が恥ずかしい。
作って学んだこと
Hooks駆動は正解だった
tmuxのペイン出力をpollingしてClaude Codeの状態を推測する方式も最初は検討した。しかし、Claude Codeの出力にはANSIエスケープシーケンスやスピナーアニメーションが大量に含まれていて、そこから「Working/Waiting/Idle」を正確に判定するのは不安定だった。
Hooksなら、Claude Code自身が「いまプロンプトを受け取った」「ツールを実行した」「処理が終わった」と教えてくれる。状態の推測ではなく、事実に基づいた表示ができる。
ファイルベースのIPC
ペイン間の通信にファイルを使っている。ソケットやパイプではなく、プレーンテキストファイルに ▶ mono-and.blog と書くだけ。
単純だけど、これが一番壊れにくかった。Claude Codeがクラッシュしてもファイルが残るだけだし、TUIが落ちてもHookは動き続ける。片方の障害がもう片方に波及しない。
ratatuiは良い
TUIフレームワークにratatuiを使った。Rustの型システムとの相性が良く、レイアウトの分割やリスト表示が宣言的に書ける。ANSIカラーのプレビュー表示にはansi-to-tuiクレートを使っている。Rust未経験からのTUI開発で考えたことは別の記事にまとめた:
Vibe Codingでコードの価値が消えた先で、エンジニアは「願う人」になる｜Rust未経験TUI開発の記録開発
READMEだけで判断しない
workmuxの本当の価値はdashboardのUXと.workmux.yamlのプロジェクト設定の簡潔さにあった。READMEの機能一覧からは見えなかった部分だ。
ツールの良し悪しはインストールして5分触らないとわからない。「READMEを読んで合わないと判断した」は、ツール選定としては不十分だった。
まとめ
結局、workmuxで全部できた。自作する必要はなかった。
ただ、作ったからこそHooksの仕組みを深く理解できたし、ファイルベースIPCの設計やratatuiでのTUI開発も経験できた。車輪の再発明は無駄ではなかったと思いたい。
ツール選定で学んだのは、READMEを読むだけでは不十分ということ。5分でいいからインストールして触る。それだけで「合わないと思っていたけど実は最適だった」に気づける。
Claude Codeの並列実行環境を整えたい人は、まずworkmuxを触ってみてほしい。
raine/workmux git worktrees + tmux windows for zero-friction parallel dev Rust 800ターミナル環境の最適化はこっちにまとめている:
ターミナルの主役はClaude Code中心になった！ Claude Codeファーストなターミナル構築開発
