tmuxは必須ではないかもしれない：開発ワークフローでtmuxを置き換える方法

 (bower.sh)
17 ポイント 投稿者 GN⁺ 2025-08-04 | 7件のコメント | WhatsAppで共有
  • tmuxを長年使ってきたが、最近は tmux の複雑さと限界（カラー互換性、スクロールバック、マウスでのコピー、プロトコル未対応など）に疑問を感じるようになった
  • セッション永続性（detach/attach）や ウィンドウの分割・管理 など、tmux の主要機能は必ずしも tmux でしか実現できるわけではない
  • dtach, abduco, shpool のような Unix 哲学に沿った軽量ツールを活用すれば、セッション管理に集中しつつ ネイティブのスクロールバック と シンプルさ を確保できる
  • 特に shpool + ssh の組み合わせにより、複数のリモートセッションをウィンドウマネージャで直接管理し、ネイティブ機能（通知、スクロール、タイトルなど）をそのまま使える環境を構築できる
  • 完璧ではないが、筆者にとっては tmux を完全に置き換えられ、シンプルで保守しやすいワークフローに満足している

tmuxの長所と短所

  • セッション維持（detach/attach）、ウィンドウ管理（タブ、split）など、これまで tmux が提供してきた機能がワークフローの中核だった
  • しかし、適切な TERM 設定がない場合の色表示の問題や、ターミナルと tmux 間の相互作用を考慮する必要があるなど、複雑さが増していた
  • スクロールバッファの利用も tmux 独自の方式に慣れる必要があり、マウスを使った範囲コピーも split 環境では不便だった
  • kitty graphics protocol など 新しいターミナル機能 への対応が不十分で、実験的プロトコルをサポートしない問題もある
  • 重複した escape code の再解釈や、セッション/ウィンドウという概念を追加することで、マルチプレクサが ターミナルエコシステムの発展を妨げる という批判もある

tmuxの代替手段を探る

  • セッション永続性:
    • 単純な方法として ctrl-z + fg, nohup, disown などもあるが、完全な代替にはなりにくい
    • セッション維持だけ を目的とした複数のツール（dtach, abduco, shpool）が登場している
      • fork() と UNIX ソケットの組み合わせにより、daemon と client の間を接続する
      • tmux と違って仮想 split を持たないため、ネイティブのスクロールバック をサポートし、バッファ復元機能を備えるものもある
    • 実際の使用感では、代替ツールの多くはバグがあり、nvim 内で detach のキー組み合わせが動かないなど、完成度 は低かった
    • shpool だけが detach/attach コマンドとキーマップのカスタマイズの面で最も完成度が高かった
  • ウィンドウ管理:
    • ローカルではウィンドウマネージャで分割・配置を管理する
    • リモート（SSH）環境でも ssh_config と shpool を組み合わせることで、複数セッションを別々のウィンドウで独立して維持できる
    • autossh と組み合わせれば、ネットワーク再接続時でもセッションを維持できる

新しいワークフロー

  • 筆者は個人的に ghostty（ノートPC）、sway+foot（個人用PC）でウィンドウを管理している。サーバーは Proxmox ベースのヘッドレス VM で、常時 SSH 開発環境を維持している
  • 複数の shpool セッションに ssh のショートカットで自動接続し、ローカルのウィンドウマネージャで独立して制御する
    • ssh_config で各ホストごとに shpool セッションへの attach を自動化
    • ターミナルごとに IRC、dotfiles 管理、別個の neovim 環境など、複数セッションへ個別接続 が可能
  • ネイティブスクロール、通知、ターミナルタイトルなど、tmux では不安定にしか対応できなかった機能が、むしろより自然に動作する
  • 欠点もある: vim 再接続時のターミナル状態の復元に遅延があり、nvim 使用時にはリサイズの問題もある
    • マルチプレイヤー非対応（複数クライアントで autossh が同時発生するとセッション衝突が起きる）
  • それでも筆者基準では tmux の完全代替に成功 した

結論

  • 完全に同一ではないものの、tmux の複雑さと限界から離れ、シンプルで柔軟なセッション管理ワークフロー へ移行できる
  • それぞれのワークフローに応じて、shpool などの代替ツールを検討する価値はある

関連記事

7件のコメント

 
egirlasm 2025-08-05

最近はAIでtmuxみたいなものを生成して使っています。Xterm.js + react + electron なら3〜4時間でああいうものを100個でも作れて、必要ならリアルタイムで修正しながら使えるし、しゃぶしゃぶみたいな感覚です。食べたいものを入れれば、ソースにたっぷり。
 
barca105 2025-08-05

weztermで快適に使っています
 
iolothebard 2025-08-04

Screen最高！
 
helio 2025-08-04

cargo install shpool...やっぱり tmux を使います...OS ごとにパッケージが揃っていないといけません!
 
mineboo 2025-08-04

Zellijという非常に優れた新鋭があります。強くおすすめします。
 
xguru 2025-08-05

Zellij - 開発者＆Opsのためのターミナル

これもかなり前に投稿していましたね（笑）
 
GN⁺ 2025-08-04
Hacker Newsの意見

  • この記事は Linux-on-the-Desktop ユーザー向けの内容だが、tmux は MacBook で iTerm2 と一緒に使うと真価を発揮することを強調したい
    iTerm2 の tmux 統合機能のおかげで、自分のワークフローに tmux が完全に自然に溶け込んでいる
    ~/.ssh/config に以下のように設定しておけば、MacBook を再び起動したりネットワークを切り替えたりしても、いつでも ssh tmux でリモート開発サーバーに簡単にアクセスできる
    iTerm2 と tmux の統合のおかげで、リモート tmux のタブやスクロールバッファがまるでローカルのタブのように動作し、実際には tmux コマンドを知らなくても使える

    • 自分は個人用の機材はすべて Linux を使い、仕事では主に MacBook を使っているが、tmux はプラットフォームに依存せず同じ環境を再現してくれるので本当に便利
      Linux では Alacritty を使っているが、macOS では適切な設定やウィンドウ／スクロール関連の違いのせいで、いつも何かがすぐにはうまくいかない
      こうした OS の違いに時間を使いたくないので、tmux と iTerm2 の組み合わせで Linux とほぼ同じ体験を得られるのがよい
      セッション内スクロールバックが完全に別個に提供される点も、自分には利点
      tmux への批判は、むしろターミナル開発者寄りの問題だと思う
      サポートが不十分なら、よりよいサポートを提供するターミナルに移ればいい

    • 自分は mosh と screen の組み合わせを使っている
      サーバーが再起動してもセッションを復元できるし、ネットワークを切り替えてもセッションが切れない
      参考: Immortal SSH Sessions

    • tmux を何十回も試したが、あまり気に入らず毎回 screen に戻っていた
      でもこのヒントを見て、もう一度試してみたくなった

    • 自分は vim、tmux、iTerm2 の組み合わせで色やフォントの問題によくぶつかり、結局ローカルでは tmux を諦めた
      アップデートをまたいでも生き残ることや、セッション維持によって得られる利点はそれほど大きくなかった
      フォントの問題さえ解決できればまた試すつもりはあるが、今は時間が足りない

    • Linux ターミナルの中に iTerm2 のような tmux 統合機能を提供するものがあるのか気になる
      まだ GNU Screen を使っているが、tmux をもう一度試す気はある

  • このブログ記事を見て、なぜ tmux を使うのかを改めて実感した
    人々が tmux に似たワークフローを実現しようとして膨大な作業をしているのを見ると、ただ tmux を使うほうがずっといい
    ときどきコピペが少し面倒なことはあるが、あまり気にしていない
    「マルチプレクサーが無駄なオーバーヘッドを生む」という批判は、コードベースの保守者でない限り気にする必要はない

    • コピペの問題は tmux だけの問題ではない
      vim のようにターミナル全体を直接描画するアプリならどれでも起こりうる
      OSC52 というターミナルエスケープシーケンスでこの問題は簡単に解決できる
      以下の簡単な Python スクリプトを使えば、grep の結果などもシステムクリップボードへ直接送れる
      tmux と nvim はすでに OSC52 をサポートしており、他の場面でも簡単に活用できる

    • ちなみに自分は tmux に PR を提出したことがあるが、メンテナの Nick Marriott は本当にコミュニケーションがよくて好印象だった
      コードもよく整理されていて、tmux はさらに良くなった

    • ない問題を無理やり作っているような議論にはうんざりする
      著者の言う理由は納得できず、むしろ彼の「7年以上の tmux 使用経験」すら疑わしく感じる

  • 数週間前に Tmux を知り、プログラムから特定のペインにキー入力を送れるスクリプトの可能性に魅了された
    日本のフォーラムに触発されて、Claude Code（以下 CC）が対話を必要とする CLI スクリプトと直接やり取りできるか考え、Tmux を使えば実現できると確認した
    そこで claude-code-tools という小さなツールを作り、CC のような CLI エージェントが Tmux ペインを作成し、その中でスクリプトを実行し、リアルタイムに対話までできるようにした
    ある種の Playwright や Puppeteer のターミナル版のようなもの
    claude-code-tools GitHub リンク
    この方法なら、CC が対話を必要とする CLI スクリプトを自動テストしたり、別のペインで UI を表示して Puppeteer MCP でブラウザからテストしたり、デバッガを有効にしてブレークポイントを張ったり、マルチエージェント連携をしたりと、さまざまな応用が可能
    こうした拡張性を tmux の代替ツールでも実装できるのか気になる

    • ちなみに screen でも stuff というコマンドでペインにプログラムからキー入力を送れる

    • この方法なら Claude Code が Gemini CLI、OpenCode のようなさまざまな CC インスタンスを interactive モードで制御できる
      従来のサブエージェントとは異なる形の連携が可能

    • tmux-cli ラッパーが実際に結果向上に役立つのか気になる
      自分は Claude に既存の tmux コマンドを使わせるだけでうまく動くので、あえて Bash を使わず、すべてのコマンドを tmux セッション内で実行させている

    • こういうことをターミナルレベルでもっと簡単にしたいなら、Kitty の remote control 機能もすばらしい
      Kitty Remote Control 紹介

    • ターミナルは本質的にはファイルディスクリプタにすぎないので、script(1)、expect(1)、chat(8) のような類似ツールは 80 年代から存在していた
      必ずしも tmux が必要というわけではない

  • tmux で TERM 設定を正しく行わないと色などが正しく表示されないという問題は、あらゆるターミナルエミュレータ／プログラムでも同様に起こる問題
    Unix や Linux システムでは TERM と terminfo/termcap の概念自体が本質なので、正しい設定が必須
    これは tmux 固有の問題ではない

    • とはいえ著者が責任を tmux に押しつけているのは残念
      スクロールの問題についても tmux 自体の問題なのか疑問で、tmux は alternate screen buffer を使うが、これはビューポートの基準線を明確にしてカーソル移動をしやすくするために導入されたもの
      現代のターミナルの多くは alternate screen 状態でもローカルスクロールを許可するので、この性質がきちんと守られていない

    • ほとんどのプログラムもデフォルト設定が適切でなければ意図どおりに動かない
      tmux の場合はすぐに「なぜ」が見えないのが不便だが、その解決策が何なのかは不明確（例: デフォルトを 256colors にするべきか?）

    • その通りだが、tmux を使うと気を配るべきレイヤーが一段増える
      tmux の内側では tmux 専用の TERM を使い、外側では自分のターミナルに合った TERM を使わなければならない
      tmux FAQ を見ても、表示問題の大半は TERM 未設定に起因している

  • 「マルチプレクサーが無駄なオーバーヘッドを与える」という指摘は、むしろ自分が tmux を好む理由でもある
    termcap サポートを諦めるアプリが増えている今の状況では、tmux があれば自分の VT520 のような古いターミナルでもまだアプリを動かせる
    どんなターミナル開発者が tmux を嫌おうとあまり気にしない
    最終的にユーザーにとって重要なのは、アーキテクチャの優雅さよりちゃんと動くこと
    ちなみに個人的には alacritty のほうが良いと思っている（ただし主に Konsole を使っている）

    • VT520 を持っているなんてうらやましいと言いたい
      かなり前から VT525 を探しているが、価格も高いし海外の売り手ばかり
      genuine VT525 で nosh realizer がうまく動くのかずっと気になっていた
      tmux がなくなっても、微妙に TERM 非互換なアプリは別の方法で変換できるはず

    • 自分の VT420 はハードウェアフロー制御をサポートしていないのでソフトウェアフロー制御を使わなければならないが、この方式は最近のターミナルアプリと相性があまり良くない
      GNU Screen は非常に優れた解決策になっており、そのほかにもいろいろな機能がある
      tmux は最新のエミュレータではよく使ったが、古い端末ではこの重要なフロー制御機能が不足しているように見える
      termcap/terminfo 非対応アプリを扱うのに tmux が有用だという点には同意する

    • なぜ alacritty のほうが良いと思うのか気になる
      古いハードウェアでは起動も遅く、タブ機能など実用的な機能も不足し、ベンチマークでさえ kitty/ghostty/konsole/foot に劣る
      それでも alacritty を使う人がいるのは、何か理由があるのだろうと思うと興味深い

  • これからも tmux を使うつもり
    複数プロジェクト間のセッション管理や再起動後のセッション復元が簡単なので気に入っている
    mouse copy/paste も tmux-yank でまったく問題なかった
    何年も同じ環境を使っている
    tmux の send-keys 機能で dotfile をリファクタリングするとき、複数のペイン／セッションに同時に alias や設定ファイルの更新を反映し、nvim の再起動まで行う自動化を実装した
    この体験は ブログと動画 にまとめている

  • 自分は "you might not need tmux" を "you might not need browser tabs" の議論に似たものとして見ている
    ターミナルセッションやウェブページが 1 つか 2 つなら不要かもしれないが、それ以上を扱うならウィンドウ管理が不便になりすぎて、結局同じ機能を繰り返し実装することになる

    • 最近の自分は、使っているウィンドウマネージャのウィンドウ管理機能を最大限活用するようにしている
      ブラウザタブやターミナルタブ、tmux の代わりに、ウィンドウマネージャにウィンドウ配置やタブ管理、ブックマークなどを任せても不便ではない

    • タブ管理はアプリケーションではなくウィンドウマネージャが担うべきだという信念に近づいている
      自分のウィンドウマネージャはウィンドウをタイル状に並べたり、重なったウィンドウをタブとしてグループ化したりできる
      これらのタブは同じアプリ同士でも別アプリ同士でも関係なく使える

    • ブラウザタブは別のウィンドウに簡単に分離したり結合したりできるが、tmux タブはその点で柔軟性が足りない
      良いウィンドウマネージャなら、タブとウィンドウを自由に組み替えられる

    • 自分の tmux 設定にはクリック可能なタブがある

    • MS Windows の複数ウィンドウ管理（Alt Tab、Win Tab など）は非常に優れている
      各ターミナルごとにアイコンや背景色を変えて識別でき、OS 自体がウィンドウ管理の多くを肩代わりしてくれる
      Mac も使ったことはあるが、この点では Windows ほど満足できなかった

  • バッファスクロールバックなど、tmux への不満として挙げられる点が、むしろ自分にとっては tmux を使う動機になっている
    2 台目のラップトップは古い Debian のターミナル専用機でマウスが使えず、コピー／ペーストは tmux でしかできない状況
    自分にとって tmux は代替不可能

    • tmux capture-pane - | vim - の組み合わせは、マウスのスクロールホイールより便利なことがある

  • suckless 派は、ターミナルを設計する際に tmux のような機能をあえて実装しないという正反対のアプローチを取っている
    参考: st.suckless.org/goals

    • suckless と Kitty は開発哲学の面で正反対だと言える

  • Kitty はターミナルエミュレータの未来を牽引できそうなので成功してほしい
    ただ、自分は Kitty を業務用には使えず、tmux がないとセッション、ウィンドウ配置、状態、コピーバッファ、スクロールバックがすべて失われるので絶対に手放せない
    適切な代替が Windows に登場するまでは、横で Kitty を使うことがあっても仕事では tmux を使い続けるつもり

    • Kitty も少し使ってみたが、tmux の設定に近い環境を再現できて印象的だった
      しかし結局は tmux と標準ターミナルの組み合わせに戻った
      どこでもちゃんと動き、ツールを組み合わせるやり方のほうが長生きするという点で、tmux が依然として最善だ