はじめに
VS CodeのRemote Development拡張機能は、今やサーバーサイドエンジニアにとって「なくてはならないもの」でしょうか。SSH越しにローカルと同じ感覚でコードを書き、補完を効かせ、デバッグする。もはやターミナルに戻る理由などないようにも思えます。
しかし、私の開発環境では、今もなお screen（あるいは tmux）が躍動しています。
なぜ、令和の時代にわざわざ四半世紀も前からあるようなツールを使い続けるのか？ それは単なる懐古趣味ではなく、「作業の永続性」と「コンテキストの保持」という、現代の開発環境でも代替できない価値があるからです。
本記事では、VS Code全盛期の今こそ再評価したい、Screen/Tmuxを使い続ける3つの理由を紹介します。
VS Code時代の「盲点」：接続が切れたその瞬間
VS CodeのRemote Development（SSH）は、驚くほどシームレスにリモート環境をローカルのように扱わせてくれます。しかし、その「快適さ」はあくまで安定したネットワークとクライアントPCの生存が前提の、繊細なバランスの上に成り立っています。
「再接続中...」の不安
カフェのWi-Fiが急に不安定になったり、移動中にトンネルに入ってVPNが切れたりしたとき、VS Codeの画面に現れる「再接続しています」というプロンプト。もちろん、VS Codeも優秀なので多くの場合で復帰してくれますが、以下のような状況でヒヤッとしたことはありませんか？
- 数時間かかる重いバッチ処理やビルドを走らせている最中
- 大量のログを tail -f で流し、特定の不具合を待ち構えているとき
- 対話型のスクリプトを実行し、ユーザー入力を待機させているとき
もし接続が完全に切れてしまったら？ そのプロセスは「迷子（孤児）」になり、出力結果を確認する術を失うか、ハングアップして異常終了してしまうかもしれません。
サーバー側に「居場所」を固定する
ここで screen や tmux の真価が発揮されます。これらのツールは、サーバー側で「セッション」を管理します。
私たちがSSHで接続し、screen を起動して作業を始めるということは、サーバーの中に「自分専用の仮想の作業部屋」を借りるようなものです。
| アクション | 説明 |
|---|---|
| Detach（デタッチ） | ネットワークが切れる、あるいは意図的にSSHを閉じる。これは「部屋のドアを閉めて立ち去る」だけで、部屋の中の明かり（プロセス）はついたまま、作業は続いています。 |
| Attach（アタッチ） | 再びSSHでログインし、コマンドを叩く。すると、ドアを開けた瞬間、さっきまで動いていたプログラムがそのままの状態で目の前に現れるのです。 |
「繋がっていること」への依存からの脱却
VS Codeが「クライアントからサーバーを操作する」ツールであるのに対し、Screen/Tmuxは「サーバーの中に自分の作業環境を永続化させる」ツールです。
この「セッションの永続性」を手に入れると、エンジニアの心理的安全性は劇的に向上します。「万が一接続が切れても、サーバー側でプロセスは生き続けている」という確信があるからこそ、私たちはネットワークの不安定な場所でも、長時間かかるリスクのある作業でも、迷いなくコマンドを叩けるようになるのです。
（出典：An Introduction to Terminal Multiplexing with GNU Screen）
「コンテキストの保存」という知的生産術
エンジニアの仕事は、単にコードを書くだけではありません。ログを確認し、DBのクエリを試行錯誤し、サーバーの挙動を監視する。調査や開発に没頭しているとき、私たちのターミナルは「思考の地図」になっています。
思考の「風景」を凍結する
VS Codeの統合ターミナルでも画面分割は可能ですが、一度ウィンドウを閉じたり、プロジェクトを切り替えたりすると、その時の分割状態や実行していたコマンドの履歴、カレントディレクトリの状況を完全に再現するのは意外と手間がかかるものです。
Tmuxを使えば、以下のような「風景」を丸ごとコンテキストとして保存できます（Screenにもsplitコマンドがありますが、私にとって使いづらいので使っていません）。
| ペイン | 役割 |
|---|---|
| 左半分 | 常にエラーログを監視（tail -f） |
| 右上の小窓 | リソース状況を監視（top や htop） |
| 右下のメイン領域 | 試行錯誤中のスクリプト実行 |
この配置は、その時の調査に最適化された「思考のコックピット」です。作業を中断してデタッチするということは、このコックピットのスイッチをONにしたまま、時間を凍結させることに他なりません。
「月曜日の朝」に即座にフルスロットルへ
この恩恵を最も感じるのは、数日ぶりに作業を再開する瞬間です。
金曜日の夜に「今日はここまで」とデタッチして帰宅し、月曜日の朝にアタッチする。すると、数日前の自分が格闘していた画面配置、実行したコマンドの出力、調査の過程がそのままの姿で目の前に飛び込んできます。
「えーと、どこまでやったっけ？」と思い出す時間は不要です。アタッチした瞬間に、脳のメモリに当時のコンテキストがロードされ、即座に作業の「続き」へ没頭できる。この思考のスイッチングコストをゼロに近づける体験こそが、VS Code単体では到達しにくい、Screen/Tmuxが提供する真の生産性です。
「複数画面」の切り替えも瞬時
また、Screen/Tmux内での「ウィンドウ切り替え」は、エディタのタブを切り替えるよりもはるかに軽量です。 「開発用セッション」「運用監視用セッション」といった具合に、複数のコンテキストをサーバー内に保持し、キーボードショートカット一つでそれらを行き来する。マウスに手を伸ばす必要すらありません。
踏み台サーバーでの「最後の砦」
どれだけVS Codeが進化しても、エンジニアが立ち入るすべての環境に「最新の便利さ」が用意されているわけではありません。むしろ、実務における重要な局面ほど、制限だらけの環境であることが多いものです。
「VS Codeが入れられない」現場の救世主
金融系のプロジェクトや、厳格なセキュリティポリシーを持つ本番環境。あるいは、多段SSHを駆使してようやく辿り着く「踏み台サーバー（Bastion）」。こうした環境では、VS Code Remote Developmentのサーバー側コンポーネントをインストールすることすら許されないケースがあります。
そんな「裸のLinux端末」に放り出されたとき、screen や tmux は文字通り最後の砦となります。
- 標準インストールの安心感: 多くのディストリビューションで標準、あるいは yum/apt 一発で導入可能
- 低リソース動作: メモリやCPUをほとんど消費せず、非力なインスタンスでも軽快に動作する
- 多段接続との相性: 踏み台サーバー上でセッションを張っておけば、そこから先の複数サーバーへの接続をまとめて管理できる
最小限の設定で「自分専用」にする
こうした環境では、凝ったプラグインを入れる必要はありません。たった数行の設定ファイル（.screenrc や .tmux.conf）をホームディレクトリに置くだけで、ステータスバーに時刻やウィンドウ一覧が表示され、どんなに味気ないサーバーも一瞬で「自分の仕事場」に変わります。
# --- .screenrc 最小構成サンプル ---
# エスケープキーを Ctrl-z に変更（お好みで）
escape ^z^z
# ステータスライン（画面下部にウィンドウ一覧と時計を表示）
hardstatus alwayslastline "%{= bw} %-w%{= rk} %n %t %{-}%+w %= [%H] %y/%m/%d %c"
# スクロールバッファを増やす
defscrollback 10000
# スタートアップ時にメッセージを出さない
startup_message off
「何も持ち込めない」からこそ「中で作る」
外部ツールの持ち込みが制限される環境において、OSの標準的な機能だけで「画面分割」「セッション保持」「ロギング」を実現できるScreen/Tmuxは、単なる便利ツールを超えたインフラ・運用者の必携装備と言えるでしょう。
「VS Codeが使えないから不便だ」と嘆くのではなく、「どんな環境でも自分を最強の状態に持っていける」という自信を与えてくれるのが、これらのツールを使い続ける理由の一つなのです。
おわりに
「枯れた技術」には、枯れるだけの理由があります。
VS Codeのようなモダンなエディタがどれほど進化しても、サーバーサイドで作業する以上、ネットワークや接続という不確定要素からは逃れられません。その不確定な世界に、「セッション」という武器で対応してくれるScreenやTmuxは、今なお現役の、そして必須のツールです。
もし、まだ「黒い画面」のセッション管理を体験していないなら、ぜひ今日から導入してみてください。
一度、昨日デタッチした画面が、今日そのままの姿で迎えてくれるという快感を味わってしまったら、もう二度と「ただのターミナル」には戻れなくなるはずです。