PostgreSQLユーザ一覧の確認方法｜\du・pg_roles・権限監査まで完全解説

「PostgreSQLでユーザ一覧を確認したい」
「\duとpg_rolesの違いが分からない」
「ログイン可能なユーザだけを抽出したい」
「権限棚卸しや監査で、どこまで見ればいいのか不安…」

PostgreSQLのユーザ管理は、一見シンプルに見えて実は奥が深い領域です。
なぜなら、PostgreSQLでは“ユーザ＝ロール”という設計思想で統一されているからです。

本記事では、

ユーザとロールの正しい理解
psql（\du）による一覧確認
pg_user / pg_roles / pg_shadow の使い分け
ログイン可能ロールの抽出方法
メンバーシップ（所属ロール）の確認
権限・所有権・RLSまで踏み込んだ実務視点
よくあるエラーとバージョン差分

までを体系的に解説します。

単なるコマンド紹介ではなく、実務で事故を防ぐための確認手順まで落とし込みます。

PostgreSQLにおける「ユーザ」と「ロール」の本質

PostgreSQLではユーザはロールの一種

PostgreSQLでは、すべての権限主体は「ロール（role）」です。

アプリ接続用アカウント
管理者アカウント
権限グループ
レプリケーション用アカウント

これらはすべてロールです。

いわゆる「ユーザ」と呼ばれるものは、LOGIN可能なロールを指します。

rolcanlogin = true

つまり、

ユーザ一覧＝ロール一覧のうち LOGIN可能なもの

という理解が正確です。

公式情報はPostgreSQL公式ドキュメントを参照してください。

https://www.postgresql.org/docs/current/user-manag.html

psqlでユーザ一覧を確認する方法（\du）

最も手軽な方法：\du

psqlに接続して以下を実行します。

\du

これでロール一覧が表示されます。

表示項目：

Role name
Attributes
Member of

\duで見るべきポイント

1. Login属性

Loginが付いているものが「ユーザ」です。

2. 強い権限

Superuser
Create role
Create DB
Replication
Bypass RLS

特にSuperuserやBypass RLSは要注意です。

3. Member of（所属ロール）

この項目を見ないと、実効権限を正しく理解できません。

\duの限界とSQLを使うべき場面

\duは便利ですが、

条件抽出できない
CSV出力しづらい
自動化に不向き

という制約があります。

監査・棚卸し・証跡保管にはSQLを使いましょう。

SQLでユーザ一覧を取得する方法

1. pg_userを使う（初心者向け）

select usename from pg_user;

主な列：

usename
usesuper
usecreatedb
usecreaterole

簡易確認には便利ですが、ロール設計全体を把握するには不十分です。

2. pg_rolesを使う（実務推奨）

select
rolname,
rolsuper,
rolcreatedb,
rolcreaterole,
rolcanlogin
from pg_roles
order by rolname;

pg_rolesはロール管理の中心ビューです。

公式カタログ情報：

https://www.postgresql.org/docs/current/view-pg-roles.html

ログイン可能なユーザのみ抽出する

実務で最も使うクエリです。

select
rolname,
rolsuper,
rolcreatedb,
rolcreaterole,
rolinherit,
rolreplication,
rolconnlimit
from pg_roles
where rolcanlogin = true
order by rolname;

rolinheritの重要性

rolinherit = false の場合：

メンバーシップの権限が自動で継承されない
SET ROLEが必要

権限が効かない原因の多くはここです。

pg_shadowで詳細情報を確認する

select usename, valuntil from pg_shadow;

確認できる内容：

パスワード有効期限
認証関連情報

注意

スーパーユーザ権限が必要
情報漏えいリスクが高い
出力の取り扱いは慎重に

公式カタログ情報：

https://www.postgresql.org/docs/current/view-pg-shadow.html

現在接続しているユーザを確認する

作業事故防止の基本です。

select current_user;
select session_user;
select current_database();

特に踏み台環境や本番作業では必須確認です。

ユーザの所属ロール（メンバーシップ）確認

psqlの場合

\du

Member of列を確認。

SQLで厳密に追う

select
r.rolname as member,
m.rolname as role
from pg_auth_members am
join pg_roles r on am.member = r.oid
join pg_roles m on am.roleid = m.oid;

多段ロール構成では必須です。

オブジェクト権限の確認（実務で重要）

属性だけでは不十分です。

確認すべき権限：

DATABASE権限
SCHEMA権限
TABLE権限
SEQUENCE権限
DEFAULT PRIVILEGES

例：

\l
\dn+
\dp

特に所有者（OWNER）は強い影響力を持ちます。

SUPERUSERでなくてもDDL可能な場合があります。

よくあるエラーと原因

1. permission denied on pg_shadow

→ 正常動作。保護ビューです。

2. 権限が効かない

→ rolinherit確認

→ SET ROLEの有無確認

→ 所属ロール確認

3. DB取り違え

select current_database();

を必ず確認。

バージョン差分（PostgreSQL 15以降）

pg_rolesの列は増減する可能性あり
select * に依存しない
必要列を明示する

公式リリースノート：

https://www.postgresql.org/docs/current/release.html

実務での安全な確認フロー（推奨手順）

\duで全体像把握
pg_rolesでLOGINロール抽出
強権限ロールを確認
メンバーシップ確認
オブジェクト権限確認
必要ならpg_shadow参照

この順番で進めると事故が減ります。

まとめ

PostgreSQLのユーザ一覧確認は、以下の使い分けで整理できます。

目的	方法
すぐ確認	\du
条件抽出	pg_roles
ユーザ中心表示	pg_user
パスワード期限	pg_shadow

重要なのは、

LOGIN可能ロールの理解
メンバーシップ確認
属性だけで判断しない
所有権とオブジェクト権限も見る

という実務視点です。

次にやるべきこと

この記事を理解できた方は、次のステップとして：

自社環境でLOGINロール一覧を抽出する
強い権限ロールの棚卸しを行う
所属ロール構造を可視化する

ことをおすすめします。

データベースの安全運用は、単なるコマンド知識ではなく、設計思想を理解できるエンジニアによって支えられています。

私たちは、PostgreSQLを含むRDBMSの設計・運用・パフォーマンス最適化まで深く向き合うエンジニアチームです。

もしあなたが、

権限設計を本質から理解したい
インフラとアプリの境界まで踏み込みたい
データベースを武器にしたエンジニアになりたい

と考えているなら、ぜひ私たちの技術ブログや採用情報もご覧ください。

高度な技術議論を楽しめる仲間を、私たちは探しています。