*【環境構築】ﾀｰﾐﾅﾙに色をつける：複数サーバを行き来する環境での事故防止

複数サーバを行き来する環境での事故防止

ローカル環境と本番サーバの両方に SSH で接続していると、ターミナルの見た目が同じであるため現在地を見失う。この状態で rm を実行したり、本番サーバに置くべきファイルをローカルに作成する事故が発生する。またサーバごとに何を導入したかが分からなくなり、同じ調査を繰り返すことになる。これは、その対策をまとめたメモである。

特に WSL（Windows Subsystem for Linux） を使っている場合に混同が起きやすい。WSL 自体が Ubuntu であるため、本番サーバの Ubuntu と見分けがつかない。プロンプトの表示が user@HOSTNAME:~$ という同じ形式になるため、意識して確認しない限り区別できない。

現在地の確認

作業前に打つ基本の三点セットにあたる。

pwd       # 今いるディレクトリ
hostname  # 今いるサーバ
whoami    # 今の実行ユーザ

出力例を比較する。

# ローカル（WSL）
$ hostname
DESKTOP-EBI3Q12

# 本番サーバ
$ hostname
ik1-334-27077

この確認を習慣にするだけで事故の大半は防げる。しかし毎回打つのは現実的ではないため、恒久的な対策を併用する。

対策1: プロンプトに色をつける

最も効果が高い対策にあたる。ターミナルを見た瞬間に判別できる状態を作る。

設定方法

各サーバの ~/.bashrc の末尾に追記する。

本番サーバには赤を設定する。

echo 'PS1="\[\e[41;97m\] 本番 \[\e[0m\] \u@\h:\w\$ "' >> ~/.bashrc
source ~/.bashrc

ローカル環境には緑を設定する。

echo 'PS1="\[\e[42;30m\] LOCAL \[\e[0m\] \u@\h:\w\$ "' >> ~/.bashrc
source ~/.bashrc

ステージング環境なら黄色にあたる。

echo 'PS1="\[\e[43;30m\] STG \[\e[0m\] \u@\h:\w\$ "' >> ~/.bashrc
source ~/.bashrc

赤が表示されている間は危険な操作をしているという認識が身につく。視覚的な警告として機能する。

エスケープシーケンスの意味

記述	意味
\[ \]	非表示文字の範囲指定。これがないと表示が崩れる
\e[	エスケープシーケンスの開始
41	背景色（赤）
97	文字色（明るい白）
m	指定の終了
\e[0m	色指定のリセット

主な色コードを整理する。

背景色	コード	文字色	コード
黒	40	黒	30
赤	41	赤	31
緑	42	緑	32
黄	43	黄	33
青	44	青	34
白	47	明るい白	97

プロンプト内で使える変数も併せて示す。

記述	表示内容
\u	ユーザ名
\h	ホスト名（最初のドットまで）
\H	ホスト名（完全）
\w	カレントディレクトリ（絶対パス）
\W	カレントディレクトリ（末尾のみ）
\$	一般ユーザなら $、rootなら #
\t	現在時刻（24時間表記）

\[ と \] の囲みを省略すると、bash が文字幅の計算を誤り、長いコマンドを入力した際に表示が崩れる。色指定を含む部分は必ずこの記号で囲む。履歴を遡った際に前のコマンドが消えずに残る現象は、これが原因であることが多い。

ターミナルソフト側での区別

接続先ごとにプロファイルを分け、背景色を変える方法もあたる。

ソフト	設定箇所
Windows Terminal	設定 → プロファイル → 配色
Tera Term	設定 → ウィンドウ → 背景色
PuTTY	Window → Colours
iTerm2	Profiles → Colors

サーバ側の設定と組み合わせると、接続方法を問わず判別できる。SSH クライアントを変えても、サーバ側の PS1 は常に有効に働く。

対策2: サーバごとの記録を残す

何を導入したか、どこに何があるかを記録する。サーバ自身に置くのが確実にあたる。手元のメモは、どのサーバのものか分からなくなる。

vi ~/SERVER_NOTES.md

記載する内容の例を示す。

# 153.126.196.81 (ik1-334-27077)

## 用途
本番。example.com のマルチテナント環境

## 導入済みパッケージ
- apache2         (2026-07-17)
- php8.3          (2026-07-17)
- mysql-server    (2026-07-17)
- whois           (2026-08-27)

## 主なパス
- /var/www/html/{staging,kyoto,osaka}
- /etc/apache2/sites-available/

## 未対応
- 443 未開放。SSL 未設定
- バックアップ cron 未設定

## 注意
- staging は Laravel 稼働中。停止させない

導入したその場で1行追記する運用が要点にあたる。後でまとめて書こうとすると必ず漏れる。

チームで運用する場合は、リポジトリ管理された手順書に集約する方が望ましい。ただし個人開発や小規模案件では、サーバ上のファイルの方が確実に参照される。「見に行く手間」が最小になる場所に置くという判断にあたる。

対策3: 導入済みパッケージを調べる

記録がない場合でも、後から調べる手段はある。

手動導入したパッケージの一覧

apt-mark showmanual

依存関係で自動的に入ったものは除外され、明示的に導入したものだけが表示される。ただし OS 標準で含まれるパッケージも一部含まれる。

件数を絞りたい場合は、よく使うものだけ確認する。

apt-mark showmanual | grep -E "apache|php|mysql|nginx|whois"

導入履歴を日付つきで見る

grep " install " /var/log/apt/history.log

過去のログは圧縮されているため、併せて確認する。

zgrep " install " /var/log/apt/history.log.*.gz

出力例を示す。

Start-Date: 2026-08-27  22:31:05
Commandline: apt install whois -y
Install: whois:amd64 (5.5.22)
End-Date: 2026-08-27  22:31:08

いつ、どのコマンドで、何を入れたかが全て記録されている。記憶に頼るより確実にあたる。

/var/log/apt/history.log は削除やアップグレードの履歴も保持している。「いつからこの挙動になったか」を調べる際にも使える。ログローテーションにより古いものは .gz で圧縮されるため、期間を広げて調べる場合は zgrep を併用する。

特定コマンドの有無を確認する

which whois
command -v whois
type whois

存在しない場合に分岐させたいなら以下にあたる。

which whois > /dev/null && echo "導入済み" || echo "未導入"

複数まとめて確認する場合。

for cmd in whois dig curl git composer; do
  printf "%-10s: " "$cmd"
  command -v $cmd > /dev/null && echo "OK" || echo "未導入"
done

パッケージ単位で確認する

dpkg -l | grep whois          # 導入されているか
dpkg -L whois                 # そのパッケージが置いたファイル一覧
dpkg -S /usr/bin/whois        # このファイルはどのパッケージのものか

dpkg -S は逆引きにあたる。素性の分からないファイルを調べる際に使う。

対策4: SSH 接続設定を整理する

接続先ごとに名前をつけると、IP アドレスを覚える必要がなくなる。手元の ~/.ssh/config に記述する。

Host prod
    HostName 153.126.196.81
    User ubuntu
    ServerAliveInterval 60
    ServerAliveCountMax 30

Host stg
    HostName 192.0.2.10
    User ubuntu
    ServerAliveInterval 60

接続が短くなる。

ssh prod

設定項目	効果
HostName	実際の接続先
User	ログインユーザ
ServerAliveInterval	指定秒ごとに信号を送り切断を防ぐ
ServerAliveCountMax	応答がない場合の再試行回数

ServerAliveInterval を設定しておくと、長時間の作業中に無操作でセッションが切断される問題を防げる。調べ物をしながら作業していると、気づかないうちに接続が切れていることがある。60秒程度に設定しておけば実用上支障はない。

危険な操作の防護

現在地の把握とは別に、操作そのものを慎重にする習慣も併用する。

削除前の確認

find /path/to/target        # 対象を列挙して目視
rm -ri /path/to/target      # 1件ずつ確認しながら削除

-i は対話的な確認を挟むオプションにあたる。

判断に迷う場合は削除せず退避する。

mkdir -p ~/_trash
mv /path/to/target ~/_trash/

mv は取り消せるが rm -rf は取り消せない。この差は大きい。

alias rm='rm -i' を設定する対策も紹介されることがあるが、推奨しない。確認プロンプトに慣れて惰性で y を押すようになるうえ、alias のない別のサーバで同じ感覚のまま rm を実行すると確認なしで削除される。環境に依存した安全性は身につかない。

設定ファイル編集前のバックアップ

sudo cp /etc/apache2/apache2.conf /etc/apache2/apache2.conf.bak
sudo sed -i.bak 's/old/new/' /etc/apache2/apache2.conf

sed -i.bak は書き換え前の状態を .bak として残す。

反映前の構文チェック

sudo apache2ctl configtest && sudo systemctl reload apache2
sudo nginx -t && sudo systemctl reload nginx
sudo sshd -t && sudo systemctl reload sshd

&& は前のコマンドが成功した場合のみ次を実行する。構文エラーがあれば反映されないため、稼働中のサービスを壊さない。

まとめ

複数のサーバを行き来する環境では、現在地の誤認による事故が起きる。ローカルと本番でプロンプトの見た目が同じであることが根本原因にあたる。

対策の優先順位を整理する。

優先度	対策	所要時間
高	プロンプトに色をつける	1分
高	サーバごとに記録ファイルを置く	5分
中	SSH config で接続先に名前をつける	3分
中	削除前に find で目視する習慣	都度
低	導入履歴の調査方法を知っておく	必要時

プロンプトの色分けは1分で終わり、効果が最も大きい。視覚的な区別は意識せずとも働くため、確認を忘れる問題そのものを解消する。

記録については、導入した時点で1行追記する運用が要点にあたる。後でまとめて書く方式は必ず破綻する。記録がない場合でも apt-mark showmanual と /var/log/apt/history.log から復元できるため、まずそこから現状を把握して記録を作り始めるとよい。

確認内容	コマンド
現在地	hostname
手動導入パッケージ	apt-mark showmanual
導入履歴（日付つき）	grep " install " /var/log/apt/history.log
コマンドの有無	command -v コマンド名
ファイルの所属パッケージ	dpkg -S /path/to/file