pgAdmin 4のマスターパスワードを忘れた夜に：全設定を飛ばさずに復旧する極限のリカバリ手順と、チーム開発のためのセキュア運用術
テックリードの私だ。夜間バッチが失敗し、緊急で本番同等のステージング環境に接続しようとしたその瞬間、悪夢は訪れる。
「Master Password Required: Enter the master password to unlock your saved passwords.」
……頼む。思い出してくれ。昨週変更したあのパスワードはなんだ？
外した。3回ミスし、pgAdminはセキュリティポリシーに従って平然と言い放つ。「間違っています。これ以上入力すると、保存された全接続パスワードのメタデータはパージされます」と。
冷や汗が背中を伝う。ここで安易に「初期化だ」とアプリケーション全体をアンインストールしてはならない。あなたがこれまで積み上げてきた数十個の接続情報、SSHトンネル設定、保存されたクエリの履歴が一瞬で灰と化すからだ。
今回は、pgAdmin 4の心臓部であるマスターパスワードの仕組みを暴き、「設定や接続情報を一切失わずに強制リセットする裏技」と、二度と言い訳のできない「組織的なセキュア接続管理のベストプラクティス」を授けよう。
—
1. そもそもなぜ、マスターパスワードで地獄を見るのか？
pgAdmin 4（特にデスクトップモード）は、接続先のデータベースパスワードやSSH秘密鍵のパスフレーズを、ローカルのSQLiteデータベース（`pgadmin4.db`）内に暗号化して保存している。この暗号化の鍵（Salt & Key）を生成するための「ソルト」となるのが、あなたが最初に設定したマスターパスワードだ。
マスターパスワードを忘れたということは、暗号化された金庫の「合鍵の型」を失ったと同義である。pgAdminの内部アーキテクチャ上、暗号化されたパスワードを復元することは数学的に不可能だ。
しかし、絶望するのは早い。「パスワードの暗号化データ（鍵のペアループ）」をリセットしつつ、「接続先ホスト名やポート、ユーザー名といった非機密のメタデータ」を救出することは完全に可能である。
—
2. 【実録】設定を全ロスしないための強制リセット手順
デスクトップモードであれ、サーバーモード（Webコンテナ）であれ、pgAdmin 4のデータ実体はSQLiteのデータベースファイルだ。ここを直接外科手術する。
Step 1: プロセスとコンテナの完全停止
まずはpgAdminのプロセスを完全に殺す。バックグラウンドで動いているデーモンやDockerコンテナがファイルを掴んでいると、データベースの破損を招く。
Docker環境の場合
docker stop pgadmin4
Linuxデスクトップ環境の場合
pkill -9 -f pgadmin4
Step 2: 救出対象のSQLiteを特定する
OSごとの設定ディレクトリ（プロファイル）の場所を把握せよ。
- Linux: `~/.lib/pgadmin/` または `~/.config/pgadmin/`
- macOS: `~/Library/Application Support/pgadmin/`
- Windows: `%APPDATA%\pgadmin\`
この中にある `pgadmin4.db` がすべての命を握るファイルだ。必ずこのファイルのバックアップ（コピー）を別ディレクトリに退避させろ。これがエンジニアの最低限の命綱だ。
Step 3: 鍵の再生成と接続情報の維持（SQLハック）
マスターパスワードのハッシュ値と、保存されたパスワードの暗号化トークンは、`pgadmin4.db` 内の特定のテーブルに格納されている。
Pythonスクリプトを使い、暗号化されたパスワード（復元不可能なゴミデータとなる）をパージしつつ、接続ホストやユーザー名といったインフラ情報は保持したまま、マスターパスワードのロックを強制解除する。
以下のPythonスクリプトを、`pgadmin4.db` と同じ階層、あるいは適切なパスを指定して実行せよ。
import sqlite3
import os
pgadmin4.dbのパスを指定
db_path = ‘pgadmin4.db’
if not os.path.exists(db_path):
raise FileNotFoundError(f”Database not found at {db_path}”)
conn = sqlite3.connect(db_path)
cursor = conn.cursor()
print(“[] 接続情報のメタデータを保持したまま、破損した暗号化キーとマスターパスワードをパージします…”)
try:
# 1. 保存されたサーバーパスワードの暗号化データをクリア
# サーバーの接続設定自体（ホスト、ポート、DB名、ユーザー名）は残る
cursor.execute(“UPDATE server SET password = NULL;”)
# 2. マスターパスワードのメタデータを削除（再起動時に新規設定を促すため）
# テーブル名はバージョンによって異なる場合があるが、通常は
# user または preferences に関連データが保持される。
# 現代のpgAdmin 4では、マスターパスワードのハッシュは keyring または
# 内部設定テーブル（preference）の特定キーに格納される。
cursor.execute(“DELETE FROM preference WHERE plugin_name = ‘browser’ AND name = ‘MasterPassword’;”)
conn.commit()
print(“[+] パージ成功。接続先ホスト等の設定は維持されました。”)
except Exception as e:
conn.rollback()
print([-] エラー発生: {e})
finally:
conn.close()
この処理により、接続先のIPやポート、ユーザー名はそのままに、「パスワードだけが未入力の状態（初期状態）」でpgAdminが起動するようになる。再びpgAdminを立ち上げれば、新しいマスターパスワードの入力を求められるはずだ。
—
3. 開発スピードを極限まで高める：pgAdminの真の実力解放テクニック
マスターパスワードの危機を脱したところで、日々の開発効率を劇的にブーストするプロの技を授けよう。GUIツールを「重いおもちゃ」から「最強のDBクライアント」に変えるアプローチだ。
隠れたキラー・キーボードショートカット
マウスに手を伸ばしている時点で、エンジニアとしてのロスタイムが発生している。これを覚えろ。
- `F5`: クエリの実行（全選択、またはカーソル行）
- `Ctrl + Space` (Mac: `Cmd + Space`): オートコンプリート（入力補完）の強制呼び出し。スキーマ、テーブル名、カラム名を爆速で補完する。
- `Shift + Alt + Down`: 複数行エディット（同値の一括編集）
- `F7`: エクスプローラーツリーのフォーカス切り替え
チーム開発で絶対にやるべき「設定の共有化ルール」
個人のPC環境に依存した接続設定は、チームのオンボーディングコストを跳ね上げる。
Docker環境でpgAdminを運用する場合、接続情報をJSON形式で定義し、コンテナ起動時に自動インポートさせるのがモダンなテックリードのやり方だ。
以下の `servers.json` を用意し、ボリュームマウントせよ。
実用的な `servers.json` のベストプラクティス構成
{
“Servers”: {
“1”: {
“Name”: “Staging-Cluster-Readonly”,
“Group”: “Staging Environment”,
“Host”: “staging-db.internal.net”,
“Port”: 5432,
“MaintenanceDB”: “postgres”,
“Username”: “readonly_user”,
“SSLMode”: “require”,
“PassFile”: “/tmp/pgpass”,
“Color”: “#336699”
},
“2”: {
“Name”: “Local-Docker-Postgres”,
“Group”: “Local Development”,
“Host”: “host.docker.internal”,
“Port”: 5433,
“MaintenanceDB”: “app_development”,
“Username”: “postgres”,
“SSLMode”: “disable”,
“Color”: “#228B22”
}
}
}
これをコンテナの `/pgadmin4/servers.json` に配置し、環境変数で読み込ませる。
docker-compose.yml の模範解答
version: ‘3.8’
services:
pgadmin:
image: dpage/pgadmin4:latest
container_name: pgadmin4_pro
environment:
PGADMIN_DEFAULT_EMAIL: “lead-engineer@example.com”
PGADMIN_DEFAULT_PASSWORD: “SuperSecureAdminPassword123!”
PGADMIN_CONFIG_SERVER_MODE: ‘True’
volumes:
- ./servers.json:/pgadmin4/servers.json
- pgadmin_data:/var/lib/pgadmin
ports:
- “5050:80”
restart: unless-stopped
volumes:
pgadmin_data:
この構成であれば、仮にマスターパスワードを忘れてローカルDBが吹き飛ぼうとも、`servers.json` と `docker-compose.yml` さえあれば、コンテナを再ビルドするだけでチーム全員の接続環境が数秒で完全復旧する。個人管理からコード管理（GitOps的アプローチ）への移行こそが、最大のセキュリティ対策なのだ。
—
4. 組織で安全にパスワード管理を行うための鉄則
最後に、セキュリティガバナンスの観点から、DB接続情報の管理ポリシーを再確認する。
1. 本番環境のパスワードをpgAdminに保存しない:
本番環境（Production）のパスワードをローカルのSQLiteに保存することは論外である。マスターパスワードの有無に関わらず、端末がマルウェアに感染した瞬間に全環境が踏み台にされる。本番環境への接続時は、都度パスワードを手入力するか、短命なIAM認証・トークン認証を利用しろ。
2. `.pgpass` ファイルの併用:
スクリプトや自動接続を行う場合、ホームディレクトリに `.pgpass`（パーミッションは `0600` 必須）を配置し、pgAdminのマスターパスワード機能に依存しないセキュアなパスワード供給経路を確保する。
3. マスターパスワードの共有・平文保存の禁止:
「忘れたからチームメンバーの誰かに教えてもらう」という文化を根絶やしにしろ。マスターパスワードはあくまで個人のローカル暗号化鍵であり、チームで共有するものではない。個々人が管理し、忘れた場合は前述のスクリプトで速やかにリセットして再設定するフローを共通認識とせよ。
結びにかえて
ツールの仕様に振り回されるな。仕様の裏側にあるデータ構造（SQLiteの実体やJSONインポートの仕組み）を理解し、手足を動かしてコントロールできれば、どんなトラブルも「想定内のイベント」に変わる。
明日から、いや、今すぐあなたのローカル環境のバックアップ体制と `servers.json` による構成管理を見直してほしい。チームの生産性とあなたの平穏な夜は、こうした泥臭くも洗練されたエンジニアリングによってのみ守られるのだから。