ハクソク

世界を動かす技術を、日本語で。

開発ワークフローにおける tmux の置き換え

2025年8月1日原文(bower.sh)

概要

tmux の長年ユーザーが、セッション永続化やウィンドウ管理の代替を模索した体験談 kitty プロジェクトや作者の議論から、tmuxの複雑性とエコシステムへの影響を再考 shpool などの軽量ツール導入による利便性と課題 SSH 環境下でのウィンドウ管理とセッション自動接続手法 tmuxから脱却した新しいワークフローの実践例

tmuxの課題とkittyプロジェクトからの気づき

  • tmux を7年以上愛用してきたユーザー視点
  • セッション永続化、ウィンドウ分割、プロジェクトごとのウィンドウグループ化、リモートサーバーでの多端末利用など 多機能性 への依存
  • kitty プロジェクトのGitHub Issueでの指摘：
    • マルチプレクサは 不要なオーバーヘッド と複雑性を追加
    • エスケープコードの変換・改変による バグや非互換性 発生
  • 色表示の問題 や スクロールバックの使いにくさ、 マウス選択の不安定さ などtmux特有の悩み
  • kitty graphics protocol など新機能への対応遅れ
  • 作者Kovid氏の主張：「マルチプレクサはエコシステム全体の進化を阻害」

tmuxの代替手段とその現実

  • セッション永続化 は他の方法でも実現可能
    • ctrl-z + fg、nohup {cmd} &、disownなど
    • これらはtmuxほど 柔軟な再接続 は困難
  • ウィンドウ管理 はローカルではウィンドウマネージャで代用可能
    • ただしSSH先では ウィンドウマネージャの制御が及ばない
  • tmux の代替となり得る軽量ツール
    • dtach、 abduco、 shpool
      • UNIX哲学に則った 単機能志向
      • 仮想分割がないため ネイティブスクロールバック が利用可能
      • デーモン化やUNIXソケットでのプロセス管理
      • shpool はdetachコマンドを備え、キーバインド割当も容易
  • nvim 内でのdetach問題や一部バグは存在
    • detachショートカットが nvim に奪われる場合あり
    • shpool はdetachコマンドで回避可能

SSH環境下でのセッション管理とウィンドウ操作

  • ghostty や sway+foot などのローカルウィンドウマネージャ活用
  • クライアント＋サーバ開発フロー ：
    • ローカルマシンから Proxmox VM へ常時SSH接続
  • shpool セッションへの自動接続方法
    • ssh_config でRemoteCommandやControlMaster等を設定
    • 各shpoolセッションごとにsshエイリアス作成
      • 例：ssh d.chat、ssh d.dot、ssh d.term
    • autossh で自動再接続も実現
      • 例：autossh -M 0 d.chat

tmuxからの移行後の変化と課題

  • tmux完全卒業 を実現
    • ワークフローの微調整は必要だが、 大幅な不便さはなし
  • ネイティブスクロールバック、 ターミナル通知、 タイトル表示 などがスムーズに動作
  • shpool の課題
    • 再接続時のターミナル状態復元が不十分（nvim利用時のリサイズ問題）
      • ワークアラウンド例：vim.keymap.set("n", "<leader>l", function() io.stdout:write("\027[?2048h") end, opts)
    • multiplayer非対応 で複数クライアントからのautossh利用時に切断問題
  • 現状の満足度 は高いが、完璧ではない
    • 新たな問題点や改善余地も認識

結論：tmux代替ワークフローへの提案

  • shpool や軽量セッション管理ツール＋ウィンドウマネージャの組み合わせで、
    • セッション永続化
    • ウィンドウ管理
    • SSH環境下での柔軟なマルチセッション運用 がほぼ実現可能
  • tmux の複雑性から解放され、
    • シンプルで拡張性の高いワークフロー 構築が可能
  • まだ発展途上の部分もあるが、
    • tmux以外の選択肢 として十分検討に値する
  • あなたのワークフローにも導入する価値ありか、ぜひ検討・共有を推奨

Hackerたちの意見

「tmuxは必要ないかも」と言うのは、「ブラウザのタブは必要ないかも」と同じようなもんだと思ってる。確かに、ターミナルのセッションが1つか2つ、ウェブページが少しだけなら、別に使わなくても大丈夫かもしれない。でも、それ以上になると、デスクトップがウィンドウをたくさん管理できないから、機能を再実装しなきゃいけなくなるんだよね。

└

最近、ブラウザのタブやtmuxでたくさんのターミナルタブを開くんじゃなくて、自分の好きなウィンドウマネージャーの素晴らしいウィンドウ管理機能を使うように努力してる。もしそれがうまくいかなかったら、もっといいウィンドウマネージャーが必要だっていうサインだと思うし。何百ものタブを開きっぱなしにする代わりに、ブックマークを使うのも悪くないよね。ブックマークバーがあれば、タブバーがなくても全然大丈夫。

└

MS Windowsは、Alt TabやWin Tabなどの優れたマルチウィンドウ管理があって、他のOSよりも遥かに優れてる。ターミナルはそれぞれ異なるアイコンや背景色を設定して、見分けやすくしてる。オペレーティングシステム（Windows）が重い作業をやってくれるんだ。Macを約5年間使ってたけど、「すべてのウィンドウがAltタブできる」MS Windowsが恋しかった。Macは「すべてのアプリがコマンドタブできて、各アプリには独自のサブウィンドウ管理がある」って感じだね。

└

でも、最近のターミナルはタブがあるから、もし単に複数のターミナルを開きたいだけなら、他にも選択肢があるよ。例えばVSCodeとかね！

└

タブ管理は個々のアプリじゃなくて、ウィンドウマネージャーの仕事だって思うようになったよ。俺のウィンドウマネージャーは、ウィンドウをタイルしたり、重なったウィンドウからタブを作ったりできるんだ。タブは同じアプリからでも、違うアプリからでも大丈夫。

「tmuxでTERMを正しく設定しないと、色が正しく表示されない」 これは他のターミナルエミュレーターにも当てはまるし、実際、色だけじゃなくて、機能キーや編集キーも正しく認識されないことがある。REPがうまく機能しないところで使われることもあるし、単純な相対カーソル移動すら間違って行われることがある。TERMとterminfo/termcapに組み込まれたアイデアは、UnixやLinux系のオペレーティングシステムでターミナルデバイスが動作する方法に内在している。異なるターミナルやターミナルエミュレーターが、必ずしも同じプロトコルを話すわけではないという現実も避けられない。TERMを正しく設定するのは、tmux特有の問題じゃないんだ。

└

でも、著者はそれをtmuxのせいにしてるけど、ちょっと違う気がする。記事の印象が悪くなるよね。スクロールの問題が本当にtmuxのせいかどうかも分からないし。tmuxは代替スクリーンバッファを使っていて、これはsmcup/rmcupのterminfo機能を使って有効化されるんだけど、その意味は「ウィンドウのビューポートを固定する」ってことなんだ。だから、絶対的なカーソル移動の位置が分かる状態になる。こうなってると、ネイティブなスクロールの試みは影響がないはずで、キー入力やスクロールホイールのイベントはtmuxに直接送られるべきなんだよね。なのに、他のターミナルエミュレーターは代替スクリーンでローカルスクロールを許可してるから、smcup/rmcupの意味が崩れちゃって、tmuxでの簡単なスクロールも台無しになってる。

└

同意するよ。ほとんどのプログラムに当てはまることだし。設定をちゃんとしないと、期待通りに動かないことがあるからね。TMUXの場合は、何が原因でおかしく見えるのかすぐには分からないから、ちょっとイライラすることもある。でも、解決策が何かは分からないな。デフォルトで256色にする？

└

TERMを正しく設定するのはtmux特有の問題じゃないよ。そうだね、でももう一つのレイヤーを扱う必要があるから面倒なんだ。tmux特有のTERMがあって、それはターミナルエミュレーターのTERMの上に乗っかるべきなんだ。これが僕の言いたかったこと：tmuxを使うときやデバッグするときには、もう一つのレイヤーを意識する必要があるんだ。tmuxのFAQの一番上を見てみて：https://github.com/tmux/tmux/wiki/FAQ > 注意：ほとんどの表示問題は不正なTERMが原因です！問題を報告する前に、tmuxの内外でTERM設定が正しいことを確認してください。 > tmuxの中ではTERMは「screen」、「tmux」またはそれに類似したもの（例えば「tmux-256color」）である必要があります。それ以外のところで問題を報告しても無駄です！ > 外では、ターミナルに合わせて設定するべきです。特に、rxvtやその派生版には「rxvt」を使ってください。

つい数週間前にTmuxについて知ったんだけど、面白い機能の一つがスクリプト可能ってこと。特定のペインにキーストロークをプログラム的に送れるんだ。日本のフォーラムに触発されて、これを使ってClaude CodeがインタラクティブなCLIスクリプトと実際にやり取りできるか考えてみた。CCはbashを通じてスクリプトを起動できるけど、そのスクリプトがユーザー入力を待ってると、CCは（簡単には）やり取りできないんだ。結果的に、Tmuxを活用できることが分かった！それで、Claude Codeを使って「Tmux-cli」っていう小さなツールを作ったんだ。これでCC（または他のCLIコーディングエージェント）がTmuxペインを生成して、そこでスクリプトを起動し、実際にやり取りできるようになった。つまり、ターミナル用のPlaywright/Puppeteerみたいな感じ。これを使うには、uv tool install claude-code-toolsでインストールできるよ。これによって面白い可能性が広がる：CCがインタラクティブなCLIスクリプトを自動でテストできるようになって、私が介入してエラーを指摘する必要がなくなる。CLIコーディングエージェントが別のペインからUIを起動して、Puppeteer MCPを使ってブラウザからテストすることもできる。CCがデバッガーを有効にしたCLIスクリプトを起動して、ブレークポイントを設定することもできるし、トークン効率の良いコード理解、デバッグ、説明ができる。CLIコーディングエージェントが同じまたは他のCLIコーディングエージェントの別インスタンスを生成して操作することもできる。これは「生成して放置」するCCサブエージェントよりもずっと良いよね。話題に上がったTmuxの代替品が、こういうツールを作るのを可能にするのか気になるな。

└

そうそう、これを使ってもう一つ楽しいことができる：Claude CodeにGemini CLIやOpenCode、他のCCインスタンスとインタラクティブモードで話させたり、コントロールさせたりすること！別のサブエージェントのバリエーションだね。 :)

└

科学者たちは、自分たちができるかどうかに夢中になりすぎて、すべきかどうかを考えるのを忘れてしまった。

Hacker Newsで議論の続きを見る