私のWindows Terminalの使い方 – tmuxとカスタムワークフローで実現した究極のターミナル自動化

• tmux、SSH、nvim、強力な検索・自動化スクリプトを組み合わせ、リモートサーバー上のファイルをGUIなしでも即座に探索・修正・検索できる独自のワークフローを実現
• キー操作ひとつでtmuxの複数ウィンドウからファイル名を自動検索してそのまま開き、ファイル切り替えやバッファ管理までをすべてショートカットで処理
• VSCodeの遅さとキーバインドの衝突に不満を感じ、すべての操作をスクリプトで直接統合
• regex、perl、tmux、nvimなどのUnixツールを組み合わせ、ファイルパス・行情報の自動認識とオープンを実現
• 自前での実装過程は非常に複雑だが、ターミナルの強力さと拡張性を最大限に引き出せることを示している

---

自分だけのターミナルの使い方

• この記事は、ターミナルと各種ツールを組み合わせて効率的な開発環境を構築した経験を共有するもの
• 一般的には動画が必要になるほど複雑な内容のため、テキストとあわせて実演動画を用意している（動画視聴推奨）
• 動画内の一部の手順（0:11、0:21、0:41）は、多くの人が「こんなことが可能なのか？」と驚く部分

動画内のターミナルワークフローを段階別に要約

• 0:00 : ノートPCでWindows Terminalを起動
• 0:02 : ctrl + shift + 5 のショートカットで新しいターミナルタブを開き、sshで自宅のデスクトップに接続して、すぐにtmuxを起動
• 0:03 : tmuxで標準シェルのzshを実行し、プロンプトを表示して全体設定を非同期でロード
• 0:08 : zoxideで最近使ったディレクトリをfuzzy検索して移動
• 0:09 : ripgrepコマンドの入力を開始すると、zshが過去の使用履歴にもとづいて自動補完し、ctrl + fで確定
• 0:11 : ctrl + kf ショートカットでtmuxのスクロールバック全体からファイル名を検索し、ファイル名が青色でハイライト表示される
• 0:12 : n キーを押し続けて、検索されたファイル一覧から目的のファイルをたどる
• 0:21 : o キーで選択したファイルを既定アプリ（nvim）で開くと、tmuxが新しいウィンドウで実行される（引き続きリモートサーバー上で動作）
• 0:26 : rust-analyzerでコード内の複数の参照へ移動しようとするが、一部のマクロは認識に失敗し、0:32で正常に移動成功
• 0:38 : ctrl + kh でtmuxのフォーカスを左のウィンドウに切り替え
• 0:39 : n キーを再び押して、"copy-mode" 状態のまま前のファイル検索結果を引き続きたどる
• 0:41 : o キーで今度は別のファイルを既存のnvimインスタンスで開く
• 0:43 : b キーで開いているファイルのバッファ一覧を確認し、2つのファイルを交互に切り替えながら終了

なぜこのようなターミナルワークフローを使うようになったのか？

• VSCodeが遅く、特にvimプラグイン使用時にかなりもたつく
  • エディタ、vimプラグイン、ターミナル、ウィンドウ管理機能の間でキーバインドの衝突が頻繁に発生して不便だった
  • Zedエディタも試したが、当時はまだ未成熟で、キーバインド衝突の問題も依然として残っていた
• nvim（Neovim）をターミナル上で直接使い始めたものの、
  • ripgrepなどで検索したファイル名をいちいちコピーしてエディタに貼り付ける作業があまりにも煩雑だった
  • 特にripgrepの結果にファイル名と行番号が一緒に出ると、
    • 貼り付けるたびに構文エラーが発生する
    • 実際にファイルを開く前に不要な編集をしてしまうことが多くなる
  • VSCodeのctrl-clickのように、ファイルパスをそのまま開けるワークフローが必要だと感じた
• そこでtmuxを使って必要な機能を自分で実装することになった
  • 「なぜtmuxを使うのか」と聞かれたら、まさにこの自動化とセッション維持のためだと説明している
  • ターミナルは思っている以上に強力だが、標準機能だけではこの種の自動化は見えにくい
  • tmuxは古く、文法も複雑でバグもあるが、拡張性とカスタマイズ性を理由に選んだ

主な実装方法

tmuxでスクロールバック全体のファイル名を検索

• tmuxのcopy-modeで複雑な正規表現を使ってファイル名パターンをマッチ
• 自作のregexスクリプト（search-regex.sh）でファイルパス、行、カラムまでハイライト
• tmux設定例:

  bind-key f copy-mode \; send-keys -X search-backward '正規表現'  
  

選択したファイルを新規ウィンドウ／現在のウィンドウで開く

• tmuxショートカットで、選択ファイルをデフォルトアプリまたはエディタ（nvimなど）で開くようにカスタム
• 相対パス対応およびtilde展開を含む

  bind-key -T copy-mode-vi o  send-keys -X copy-pipe 'cd #{pane_current_path}; ...'  
  bind-key -T copy-mode-vi O  send-keys -X copy-pipe-and-cancel 'tmux send-keys ...'  
  

すでに開いているnvimインスタンスでファイルを開く

• perlスクリプトでtmuxが特定のnvim paneを見つけ、そのpaneにファイル／行情報まで直接キー入力を送信
• file:line:column 構文をvimコマンドに変換して自動オープン

この方式の利点と限界

• ローカルターミナルの機能制限を克服: tmuxを通じてリモートサーバー上で自由なファイル探索・修正・検索を実現
• エディタがリモート編集プロトコルをサポートしていなくても同じワークフローが可能
• すべてのキーバインド・検索・ファイル切り替え・バッファ管理などを完全に自分好みに統合
• VSCodeプラグインを作るよりも、より速く簡単に自動化できる
• 自作スクリプトは壊れやすく保守も難しいため、人に勧めにくい

代替ソリューション

• おおむねおすすめできるオープンソース／ツールの組み合わせ:
  • fish + zoxide + fzf: fuzzyなディレクトリ移動、コマンド検索、一部のファイル検索ワークフローの代替が可能
  • エディタ内蔵機能（タブ、ウィンドウ、fuzzy finderなど）でも大半のユーザーには十分
  • qf: ターミナル出力からファイル選択はできるが、インタラクティブなツールとは連携不可、viライクなCLIを使用
  • e: file:line パスを認識する小さなツール（エディタの種類ごとに別スクリプトが必要）
  • vim --remote, code filename, emacsclient なども似た効果があるが、file:line認識は不完全

結論と教訓

• ターミナルは思っている以上に強力で、スクリプトで組み合わせればGUIツールでは不可能な自動化も可能
• ただし、保守性やスクリプトに内在するバグなど、実用上の限界はある
• ターミナルワークフローの自動化に関心があるなら、カスタムのtmux/nvim/fzf環境から段階的に構築していくのが現実的

[GN⁺]

Hacker Newsのコメント

• 自分も似たようなトリックを使っている。tmuxのスクロールバックを活用し、トークン化された出力をzshにパイプして、tmux画面に見えているあらゆるものに対して補完機能を使えるようにしている。関連Threads投稿とgistコードも共有している。本当に便利だった

• こういうワークフローのやり方が本当に好きで、自分も何年も同じようなものを繰り返し磨いている。時間が経つにつれて、カスタム層はできるだけ減らそうとしている。オーバーレイが増えるほど保守コストが大きくなるからだ。素のVim（tmuxなし）でも投稿で紹介されていることの大半はできる。たとえば rg --vimgrep restore_tool | vim -c cb - のようにできる（vim -c cb - はVimで一番好きな機能で、みんながほとんど使っていないのが不思議なくらいだ）。もちろん、rg検索を毎回やり直すのは負担が大きいこともあるので、自分は端末で結果を分析して、必要ならtmuxのカスタムコマンドで最後のコマンドの出力をコピーしてvimに送る、という形で使っている。そのときはプロンプトにUnicode文字を活用するトリックを使うこともあるし、tmux saveb - | vim -c cb - で渡すこともある

  • 10年前に巨大なマルチファイル・マルチパッケージのvim設定を捨ててから、毎年1〜2行ずつ程度のごく単純なvimrcだけを作りながら、どんどん簡素化している。長く使われているソフトウェアのデフォルト設定にはたいてい理由があるので、むやみに変える前にまずその理由を理解してみることを勧めたい
  • （vim -c cb - がVimで好きな機能だと言っていたけれど、それが何をするのか説明してもらえるだろうか。ls | vim - と ls | vim -c cb - を試してみても、すぐには違いがわからなかった）
  • vim -q <(ripgrep --vimgrep restore_tool) と同じ用途なのだろうか

• このセットアップはtmux、fzf、rg、zoxide、そしてすっきりしたnvimまで入っていて見栄えがいい。もし入っていないなら、atuin、starship、bat、glow、duf、dogdns、viddy、gum/sesh、dust、btopなども勧めたい。GitHubのAwesome Terminal XYZ系のリストに全部載っている。atuinは本当に必須級で、zoxideがないなら、アスリートなのに靴が合っていない感じだ。端末の動画を撮るならasciinemaの方がよい選択だ。実際、昔はこういうセットアップのことを「プログラマー」と呼んでいた。今はVSCode、Zed、Cursorのようなツールも必須で、どのLLMに何を任せるべきかも把握していないといけない。こうしたツールは今や新しい「最低限」ではあるが、既存の環境を置き換えるものではない。Claude Codeやgptelをどれだけうまく使っても、時にはツリーを壊すこともあるし、magitなしでgitを使うなんて想像できない。もしCursorの素の状態でOPより速いと思うなら、その人にはLLMを実戦で使っている動画を一度撮ってみてほしい

  • プログラマーであることは開発環境の設定がすべてではない。著名なプログラマーの中にはexエディタを愛用する人もいるし、初心者の中にはIDEだけは立派でも根本的な理解が足りない場合が多い。もちろん良い道具が役に立つことはあるが、実際の成功に与える影響はたいてい小さい。LLMがこれを変える可能性はあるが。たとえばランニングシューズが合わなくて5%遅くなったとしても、スタートアップで成功と失敗を分けるのはそんな微細なことではない。原因の多くは共同創業者との不和、動機の喪失、プロダクト・マーケット・フィットの不一致のような、もっと大きな問題だ
  • 君のツール一覧はいいが、atuin、dogdns、btopなどツール名の大半を知らない人から見ると、やや馴染みがないかもしれない
  • コマンドの一覧が本当に好きだ。ここにfd（作者: sharkdp）もぜひ加えたい。findの代替で、使い勝手の面で素晴らしい。そしてatuinは自分のCLI人生で最大のアップグレードだった。6か月前に打った珍しいコマンドでもとても簡単に見つけられるようになる
  • 道具選びにこだわりすぎている気がする。本当に優れた開発者は裸の環境でも素早く結果を出す。もちろん良い道具がわずかに助けになることはあるが、たいていは自分の楽しみや好みの問題だ。生産性がIDEにそこまで依存していると本当に感じるなら、まだこれから学んで成長する余地が大きいということだ。昔から「道具を知っている = プログラマー」という図式ではなかった。自分が見てきた最高の開発者たちの多くは、more/grep/viに少しの思考を載せるだけで圧倒的な成果を出していた。価値創出は結局のところ思考から生まれる。LLM時代でもこれは同じだ

• すべてのvim/tmuxユーザーは、半分バグっているけれど高速な非公式の「エミュレーションEmacs」を自作している可能性が高い

  • 自分は2キープレフィクスのtmuxを、すべてのコマンドのための単一のctrl修飾キーに変えるターミナルエミュレータまで作った。プロジェクトリンク
  • 自分のようにvim/tmuxとemacsの両方を使う人間からすると（そして以前は長い間emacsしか使っていなかったが）、自分のemacs環境の方がはるかに即興的で、文書化もされておらず、バグも多かった。vim+tmuxのセットアップは相対的に安定している
  • その言葉には強く共感する。自分は今のワークフローでnvimの中から:Termを動かしている
  • vim+tmux環境は、パイプ、ファイル、シグナル、スクロールバックといったシステムのプリミティブに大きく依存している。だからツール群がさまざまな環境やssh、制限されたシェルでも自然かつ透過的に動く。これは移植性とデバッグの面で大きな利点だ。つまり、こうした基本保証の上で自分のワークフローが自由に分解できる感覚があるので、vim設定を自作するのがとても自然な選択に思える

• 彼はWindowsでtmuxを使うと言っているが、実際にはどう使っているのか気になる。説明できる人がいるといいのだが

  • 自分の考えでは、Unixシステムにリモート接続して実際の作業をしているのだと思う。Unixサーバー上ならtmuxは完全に動かせる。自分もVirtualBoxのVMにSSH接続して、WSLよりきれいな互換レイヤーとして使うことがある。そういう意味でtmuxが他の方法より強い理由でもある。サーバーにインストールされてさえいれば、リモートでも本来の役割を果たせる。関連説明リンク

• こういうワークフロー共有のやり方が本当に好きだ。対象読者にぴったり合っている。動画に音があればよかったとは思うが、あとでアクションリストを読むのも悪くなかった。自分のワークフローにも参考になる点があって学びがあった。tmuxの難解なキーボードショートカットに触れていたが、ここでbyobuを使ったことがある人はいるだろうか。byobuはtmuxのラッパーで、ほとんどのコマンドをF#キーに割り当てている。10年前に初めて触れて以来、ずっと使っている。その前の数年は純粋なtmuxだけを使っていた

  • コンテンツを楽しんでもらえてうれしい :) できるだけ明快で一目で追えるように作るよう努めた。自分はtmuxのショートカットの大半をリマップして使っている。ctrl-k がプレフィクスで、h は「左のペインを選択」のデフォルトではない。byobuは使ったことがないが、説明を聞く限りではデフォルトショートカットを少し便利にした程度のようなので、あまり追加で載せたいとは思わない

• こういう形なら、自前の巨大な正規表現がなくてもtmuxプラグインでコピーモード機能などを拡張できる。tmux-fpp、tmux-copycat、tmux-fingers、tmux-urlview などがある。速度面では内蔵機能にできるだけ依存した方が有利かもしれないので参考までに。自分は特にtmux-resurrect（セッション保存/復元）、tmux-continuum（自動化機能）、Oh-My-Fish向けのtmux-zenもとても気に入っている。tmux-resurrect、tmux-continuum、tmux-zen を紹介したい。格好いいtmux環境の構築は思ったより本当に簡単だという点も強調したい

  • 自分もtmux-copycatから元の正規表現を持ってきた。ただ、a) その正規表現は : をうまく拾えず、b) copycatは独自のビューア抽象化を使っているため、1回の検索で実行できるアクションが1つしかない。自分の方法はtmuxの内蔵検索を再利用しているので、ハイライトされたファイルに対して好きなアクションを自由にバインドできる。多くのプラグインがコピー/ペーストしかサポートしないか独自モードを上に載せる理由も、tmuxがハイライト制御をほぼ内蔵検索でしかできないからだ

• こういうセットアップは本当に美しい。なのに、まともなAIのタイプアヘッドがまだターミナルに現れていないのは不思議だ。Cursor Tabがまさに合いそうなのに、ターミナルへの適用ができていない。暫定的には、ターミナル出力を偽のファイルにパイプしてcursorに送る製品をさっと作りたくなる

• 記事のタイトルは実際には "How I use my terminal" だ

  • HNの自動機能は、タイトルの最初の単語がHowだと切り落としてしまう。特に根拠はなく、管理者はクリックベイト防止だと説明しているが、実際には混乱を招くだけだ
  • 最初はこの投稿が映画『ゼア・ウィル・ビー・ブラッド』のパロディかと思った（今のタイトルが "I use my terminal" なのでそう思った）
  • 自分も、これが誰かの自作ターミナルエミュレータの使用記なのだと思っていた
  • 自分もそれを知った。記事をざっと見た感じでは、完全なタイトルは "I use my terminal (and so should you )" あたりだろう。ターミナル関連の記事はいつでも歓迎だし、Chromebookユーザーとしてはブラウザとターミナルさえあれば十分だった。Macに移るとあまりに散漫になるので、普段はターミナルかブラウザしか使わない
  • HNではタイトル登録時に、よくある接頭辞や接尾辞を自動で切り落とすことが多い