こんにちは！データベースの裏側、そしてAPIやインフラストラクチャの設計に魅せられた君なら、きっとこう思ったことがあるはずだ。「データベースのユーザー管理や権限設定って、なんだか黒魔術みたいで怖い……」と。
開発環境でとりあえず `postgres` スーパーユーザーを使って全権限を持たせたままコードを書き殴る。その気持ちは痛いほどよく分かります。私も昔はそうでした。しかし、その甘えは本番環境での重大なインシデントという名の「痛いしっぺがし」となって必ず跳ね返ってきます。
今回は、PostgreSQLの公式管理GUIである pgAdmin を使って、「ロールと権限（ユーザー管理）」を安全に行うための極限の知見を伝授しよう。これをマスターすれば、セキュリティの不安から解放されるだけでなく、チーム開発におけるデータベース設計の解像度が劇的に上がります。
さあ、怖くない。優しく、そして本質的なところから紐解いていこう。
—
1. そもそもなぜ、pgAdminとロール管理を学ぶ必要があるのか？
現代の開発において、データベースは単なる「データの入れ物」ではなく、アプリケーションのセキュリティの最後の砦です。
よくあるアンチパターンとして、「Webアプリもバッチ処理も、みんな同じ `postgres`（管理者）アカウントで接続している」というケースがあります。これだと、万が一アプリケーションの脆弱性（SQLインジェクションなど）を突かれて踏み台にされた場合、データベース内の全テーブルが削除されるだけでなく、最悪の場合はOSのファイルシステムまで乗っ取られる可能性があります。
最小権限の原則（Principle of Least Privilege）：
> 「プログラムやユーザーには、その業務を遂行するために最低限必要な権限だけを与えよ」
この鉄則をpgAdminのGUI操作を通じて体に叩き込むのが、今回のゴールです。
—
2. まずはここから！pgAdminを使ったユーザー（ロール）の作成
PostgreSQLの世界では、「ユーザー」と「グループ」という概念は統合されて「ロール（Role）」と呼ばれます。ログインできるロールを「ユーザー」、ログインできない（グループ化や権限のまとまりとして使う）ロールを「グループ」と呼ぶイメージです。
手順：安全なアプリケーション用ロールの作成
1. pgAdminを起動し、サーバーに接続する
左側のオブジェクトツリーから、管理者アカウント（通常は `postgres`）でサーバーに接続します。
2. 「ログイン/グループロール」を開く
ツリーを展開し、`サーバー` ＞ `(あなたの接続先)` ＞ `ログイン/グループロール (Login/Group Roles)` を選択します。
ここで右クリックし、 [作成 (Create)] ＞ [ログイン/グループロール (Login/Group Role)…] をクリックします。
3. 基本情報の入力（「全般」タブ）
- 名前 (Name): `app_user` （アプリケーション接続用の分かりやすい名前）
4. パスワードの設定（「定義」タブ）
- パスワード (Password): 強力なパスワードを入力します（本番では必ずランダムな強固な文字列に！）。
- 有効期限 (Account expires): 必要に応じて設定します。
5. 権限のコントロール（「権限」タブ ★超重要）
ここが最大のポイントです。絶対に余計な権限を与えてはいけない。
- ログイン可能か？ (Can login?): [はい (Yes)] （※これが「ユーザー」の意味になります）
- スーパーユーザーか？ (Superuser?): [いいえ (No)] （絶対にYesにしてはならない！）
- データベースを作成できるか？ (Create databases?): [いいえ (No)]
- ロールを作成できるか？ (Create roles?): [いいえ (No)]
設定したら [保存 (Save)] を押します。これで、ログイン権限だけを持った「骨組み」のユーザーが誕生しました。
—
3. スキーマ単位の権限付与：ここが実務のキモ
ユーザーを作っただけでは、まだどのテーブルも見ることができません。次は「どのデータベースの、どのスキーマに、どこまでの操作を許すか」を定義します。
ここでは、`my_database` の `public` スキーマに対して、先ほど作った `app_user` に「データの読み書き（SELECT, INSERT, UPDATE, DELETE）」だけを許可する手順を見ていきます。
SQLで理解する（pgAdminの裏側）
pgAdminのGUIでポチポチするのも良いですが、プロのエンジニアなら裏で何が実行されているかを知るべきです。実は、以下のSQLを流すのと同じことをGUIは行っています。
— 1. データベースへの接続権限を与える
GRANT CONNECT ON DATABASE my_database TO app_user;
— 2. スキーマへの利用権限を与える
GRANT USAGE ON SCHEMA public TO app_user;
— 3. 現在存在するテーブルに対するCRUD権限を与える
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO app_user;
— 4. 【重要】今後新しく作られるテーブルにも自動的に権限を付与する設定
ALTER DEFAULT PRIVILEGES IN SCHEMA public
GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO app_user;
pgAdminの「スキーマ・権限ウィザード」を使う
これをGUIでやるには、対象のデータベースやスキーマを右クリックして [プロパティ (Properties)] または [権限 (Privileges)] タブを開きます。
1. スキーマ（例: `public`）を右クリック ＞ [プロパティ]
2. [権限 (Privileges)] タブを選択
3. `+` ボタンを押して行を追加：
- ロール (Grantee): `app_user`
- 特権 (Privileges): `USAGE` にチェックを入れる
4. 同様に、テーブルに対する権限も必要に応じて設定します。
特に4番目の `ALTER DEFAULT PRIVILEGES` を忘れると、ORM（HibernateやPrisma、Djangoなど）が自動マイグレーションで新しくテーブルを作った瞬間に、アプリケーションから「権限がありませんエラー（Permission denied）」が発生して夜中に叩き起こされることになります。必ず設定しておきましょう。
—
4. オブジェクト所有者の変更（Ownerの移行）
開発初期によありがちなのが、「全部 `postgres` ユーザーでテーブルを作ってしまった」という状態です。これでは、後から一般ユーザーを作っても、なぜかアクセスできないという現象が起きます。
実務では、「各テーブルやスキーマの所有者（Owner）は、そのアプリケーション専用のロールにする」のが極めてクリーンで安全な設計です。
pgAdminでオブジェクトの所有者を変更する手順
1. 所有者を変更したいテーブル（またはスキーマ、データベース全体）を右クリック ＞ [プロパティ (Properties)] を開く。
2. [全般 (General)] タブの中にある [所有者 (Owner)] プルダウンを探す。
3. ここを `postgres` から `app_user` に変更し、[保存 (Save)] を押す。
たったこれだけです！
もし一括でスキーマ内の全テーブルの所有者を変えたい場合は、Query Tool（SQLエディタ）を開いて以下のように実行するのが一番確実で早いです。
— publicスキーマ内にある全てのテーブルの所有者を app_user に変更する慈悲深いクエリ
DO $$
DECLARE
r RECORD;
BEGIN
FOR r IN (SELECT tablename FROM pg_tables WHERE schemaname = ‘public’) LOOP
EXECUTE ‘ALTER TABLE public.’ || quote_ident(r.tablename) || ‘ OWNER TO app_user’;
END LOOP;
END $$;
(※こういう泥臭い一括処理をサクッとSQLで書けるようになると、インフラ・DBエンジニアとしての戦闘力が跳ね上がります)
—
5. 動作確認：本当に安全に接続できるか？
さて、正しく設定できたかを自分の目で確かめましょう。これがエンジニアの作法です。
1. pgAdminで新しい接続（Server）を追加する
- 左側のツリーの「サーバー」を右クリック ＞ [作成 (Create)] ＞ [サーバー (Server)…]
- 全般タブ: 名前を `App User Connection` などにする。
- 接続タブ:
- ホスト名: `localhost` （または適切なホスト）
- データベース: `my_database`
- ユーザー名: `app_user`
- パスワード: さっき設定したパスワードを保存（Save passwordにチェック）
2. 接続テスト
無事にツリーに新しいサーバーアイコンが表示され、展開できれば成功です！
3. 権限のテスト（意地悪テスト）
`app_user` で接続した状態で Query Tool を開き、わざと権限のない操作をしてみましょう。
— 例えば、もし権限を与えていないシステムテーブルを覗こうとしてみる
SELECT FROM pg_shadow;
`ERROR: permission denied for table pg_shadow` と返ってきたら大成功です！「狙った通りにセキュリティが機能している」という最高の安心感を味わう瞬間です。
—
さいごに
データベースの権限管理は、最初は面倒くさく感じるかもしれません。「めんどくさいからスーパーユーザーでいいや」の誘惑に負けそうになることもあるでしょう。
しかし、この基礎をきちんと押さえておくことで、あなたの書くコード、そしてあなたが構築するシステムは、プロフェッショナルとして揺るぎない信頼性を獲得できます。
pgAdminという強力な相棒がいれば、GUIの直感的な操作と、裏側で動く堅牢なSQLの仕組みの両方を同時に学ぶことができます。
これをマスターした今、毎日のデータベース作業はもっと安全に、もっと楽しく、そして劇的に楽になるはずです。
さあ、次のデプロイに向けて、安全なロール設計をあなたのプロジェクトでも早速試してみてください！