本番障害を撲滅せよ：pgAdmin 4のサーバグループ機能と徹底ガード設定術
テックリードの私たちが最も恐れる瞬間。それは、CoffeeBreakの直後、黒い画面（あるいはGUI）に向かってキーを叩き込み、エンターキーを押した瞬間に画面の隅に表示されるデータベース名を見て血の気が引くあの瞬間だ。
「……いま、本番（`prod`）のデータベースに対して、ステージング用のマイグレーションスクリプトを流したか？」
この悪夢を防ぐために、私たちは数々のインフラレイヤーでガードを固めてきたはずだ。AWS IAM、セキュリティグループ、プロキシによるルーティング……。しかし、日々の開発・運用で最も頻繁に触れるDBクライアント（GUIツール）側での「ヒューマンエラー対策」を怠っていはいないだろうか？
今回は、PostgreSQL公式管理ツールである pgAdmin 4 を用い、幾重もの防壁を構築して「誤爆」を物理的・視覚的に根絶するプロの実践テクニックを伝授する。
—
1. 概念設計：サーバグループの階層化と命名規則の鉄則
pgAdminの左ペイン（Browserツリー）をデフォルトのまま使っている現場を見かけるが、これは「爆弾の起爆装置をすべて同じ机の上に並べている」ようなものだ。まずは環境ごとのグループ化と、視認性を極限まで高める命名規則を導入する。
サーバグループの論理分離
pgAdminの「Server Groups」機能を利用し、接続先インスタンスを厳格に階層化する。
- `[PROD]` 🔴 本番環境（アクセス権限を持つ者すら厳選すべき領域）
- `[STG]` 🟡 ステステージング環境（本番同等だが破壊しても許される領域）
- `[DEV]` 🟢 開発・ローカル環境（何度壊してもいい砂場）
視認性を支配する命名規則（Naming Convention）
人間は文字よりも「色と記号」を先に認識する。サーバ名（Name）には必ず環境プレフィックスと、色コードを想起させる絵文字を付与せよ。
- Bad: `users-db-01` （どの環境か分からない）
- Good: `🔴 [PROD] us-east-1 Core Database`
- Good: `🟢 [DEV] Local Docker PostgreSQL`
—
2. 視覚的ハザード：Color Override（カラーテーマ強制）の設定
「今、何処のデータベースを叩いているか」を脳の思考プロセスを介さずに認識させるため、pgAdmin 4の Color Override 機能を使用する。これによって、接続したタブやツリーの背景色・アクセントカラーが環境ごとに強制変更される。
設定手順
1. 対象のサーバを右クリック $\rightarrow$ Properties（プロパティ） を開く。
2. Connection タブ、あるいは Advanced タブにある Color 項目を探す（バージョンによりタブ位置が異なるが、サーバプロパティ内にある）。
3. 本番環境（PROD）には、警戒色である赤系統（例: `#FF4D4D`）を指定する。
4. 開発環境（DEV）には、安全色である緑系統（例: `#2ECC71`）を指定する。
これだけで、クエリツールを開いた瞬間に「あ、いま赤だ。本番だ」と脳の反射神経が警告を発するようになる。
—
3. 禁断の領域：本番環境を「ReadOnlyモード」で縛る
開発環境やステージング環境であれば `DROP TABLE` も `UPDATE` も自由だが、本番環境のpgAdmin接続において、日常的に書き込み権限（Write）を持つ必要性があるか？
答えはノーだ。データ修正は原則としてマイグレーションファイルや管理スクリプト経由で行うべきであり、GUIから直接書き込める状態にしていること自体がリスクである。
pgAdmin 4では、サーバ接続設定で Read-Onlyモード を強制することができる。
堅牢なRead-Only設定の適用
1. 本番サーバの Properties を開く。
2. Advanced タブに移動する。
3. ReadOnly のトグルを 「Yes」 に設定する。
> プロの知見:
> これを設定すると、pgAdmin上のQuery Toolから実行するSQLのうち、`SELECT` 以外のクエリ（`INSERT`, `UPDATE`, `DELETE`, `DROP`, `ALTER` 等）がクライアントサイドで即座に拒絶されるようになる。本番データへの偶発的な変更クエリの送信をゼロにできる、最強の防壁である。
—
4. チーム開発の生産性を爆上げする：設定の共有化（Import/Export）
新しいメンバーが参入するたびに、全員が手動でサーバグループを作り、色を設定し……というのは前時代的だ。また、個人の設定ミスがそのまま事故につながる温床にもなる。
pgAdmin 4は、接続情報やサーバグループの設定をJSON形式でエクスポート・インポートする機能（または設定データベースの共有）を持っている。
サーバ定義のJSONエクスポート・インポート
チームリーダーがあらかじめ構築した「安全な設定済みサーバグループ構成」をファイルとして配布する。
{
“Servers”: {
“1”: {
“Name”: “🟢 [DEV] Local PostgreSQL”,
“Group”: “Development”,
“Host”: “localhost”,
“Port”: 5432,
“MaintenanceDB”: “postgres”,
“Username”: “postgres”,
“Color”: “#2ECC71”,
“ReadOnly”: false
},
“2”: {
“Name”: “🔴 [PROD] Critical Database”,
“Group”: “Production”,
“Host”: “rds-prod.internal.net”,
“Port”: 5432,
“MaintenanceDB”: “app_production”,
“Username”: “app_readonly_user”,
“Color”: “#FF4D4D”,
“ReadOnly”: true
}
}
}
これをインポートするだけで、チームメンバー全員のpgAdminに「絶対に事故らない環境」が構築される。さらに、本番環境の接続ユーザー（Username）にあらかじめ権限の絞られた `app_readonly_user` を強制しておけば、DB権限とクライアント設定の両面から二重・三重のガードが成立する。
—
5. 現場のスピードを加速させるキーボードショートカット＆極意
最後に、安全性を担保しつつ、日々のオペレーションスピードを劇的に高めるpgAdminの隠れたショートカットとテクニックを共有する。
- `F5` / `Ctrl + R` : クエリの実行
- 余計なマウス操作を排除し、コードエディタから一瞬でクエリを飛ばす。
- `Ctrl + Shift + U` : パスワードの安全な管理（マスターパスワード）
- pgAdmin起動時にマスターパスワードを設定し、平文でのパスワード保存を回避する。セキュリティポリシーの厳しい企業では必須。
- Visual Query Builderの活用
- 複雑な結合（JOIN）や条件分岐が必要な際、手書きでミスをするリスクがある場合は、ビジュアルクエリツールを活用してSQLを自動生成させ、それを ReadOnly のQuery Toolで検証する。
—
結びにかえて
ツールは、使う側の意識だけに頼る設計にしている時点で設計ミスである。「人間はミスをする生き物である」という前提に立ち、「ミスしようとしてもツールが物理的・視覚的に止めてくれる環境」を作るのが、私たちテックリードの仕事だ。
今日からあなたのpgAdminの環境を見直し、本番グループを「赤く染め、ReadOnlyで縛り」、チーム全体の事故率をゼロにしてほしい。