Azure Database for PostgreSQL Flexible Server（PostgreSQL 15）で azure_storage や azure_ai を CREATE EXTENSION すると、permission denied to alter restricted role "azure_pg_admin" で失敗することがあります。原因の考え方、切り分け手順、サポート依頼のコツまでまとめます。
起きている現象：CREATE EXTENSION が azure_pg_admin の権限エラーで止まる
対象は Azure Database for PostgreSQL の Flexible Server（例：PostgreSQL 15.13）です。ドキュメントに従って拡張機能を有効化しようとしたところ、次のようなエラーで拡張作成に失敗します。
CREATE EXTENSION azure_storage;エラーメッセージの例：
ERROR: permission denied to alter restricted role "azure_pg_admin"同様のパターンとして、別環境で azure_ai 拡張を作成しようとしても同じエラーになる一方、vector など他の拡張は作成できる（＝ユーザー権限や接続自体は問題なさそうに見える）ケースがあります。
結論：azure_pg_admin はプラットフォーム管理の「制限付きシステムロール」
この事象のポイントは、azure_pg_admin が一般ユーザーが自由に操作できるロールではなく、Azure 側（プラットフォーム）が管理する制限付きのシステムロールであることです。
Flexible Server は、オンプレの PostgreSQL と違い、利用者が superuser を持てないマネージドサービスです。そのため、特定のロールや権限操作はサービス側で制限されます。今回のエラー文言は「ユーザーが何かを間違えた」というより、拡張作成の内部処理が、制限されたロールを変更しようとしてブロックされた状況を示唆します。
そして今回の結論としては、前提手順を満たしてもなお同じエラーが継続する場合、ユーザー側で解決できないサービス側（バックエンド）起因の問題に当たっている可能性が高い、という判断になります。実際に、Microsoft 側でバックエンドの問題が緩和（是正）された後、対象サーバーで拡張が正常に作成できるようになった、という解消パターンが確認されています。
なぜこのエラーが出るのか（状況から分かる範囲の整理）
エラーの主語は「現在の接続ユーザー」ではなく、azure_pg_admin という制限付きロールです。つまり、拡張作成に伴って内部的にロールや権限が触られる過程で、何らかの理由で azure_pg_admin への操作が発生し、そこでブロックされていると考えるのが自然です。
ここで重要なのは、ユーザーができるのは「拡張を使う側の設定」までであり、プラットフォームが管理するロールの状態や、拡張提供基盤の状態に起因する不整合は、利用者が直接直せない点です。そのため「手順は合っているのに、同じサーバーだけおかしい」「他の拡張は作れるのに、特定の拡張だけ落ちる」といった挙動が起き得ます。
ユーザー側でまず確認すること（切り分けの最短ルート）
とはいえ、サポートに投げる前に「本当に前提条件を満たしているか」「見落としがないか」を短時間で確認できるチェックがあります。ここを押さえておくと、切り分けが早くなり、サポートへの説明も通りやすくなります。
| チェック項目 | 目的 | 確認コマンド／操作例 | OK の目安 | NG のときの次アクション |
|---|---|---|---|---|
| 接続ユーザーが想定どおりか | 管理者ユーザーで実行しているか確認 | SELECT current_user; | サーバー作成時の管理者ユーザー名になっている | 接続文字列／GUI の接続プロファイルを見直す（別ユーザーで接続していないか） |
| PostgreSQL バージョン確認 | 対象拡張が想定するバージョン帯か確認 | SHOW server_version; | 例：15.x など、想定バージョン | 拡張の対応状況を再確認（必要なら別バージョンの検証環境を用意） |
| 拡張が提供されているか | そもそもサーバーで提供されている拡張か確認 | SELECT name, default_version, installed_version FROM pg_available_extensions WHERE name IN ('azure_storage','azure_ai','vector'); | azure_storage / azure_ai が一覧に出る | 一覧に出ない場合は、サーバーパラメーター（allowlist 等）やリージョン／SKU の制限の可能性を疑う |
拡張 allowlist（例：azure.extensions） | 拡張を許可するサーバーパラメーターが入っているか確認 | SHOW azure.extensions; | 値の中に azure_storage / azure_ai が含まれる | ポータルの「サーバーパラメーター」で allowlist を見直し、保存→再起動まで実施 |
| 拡張ライブラリ読み込み | ライブラリ読み込みの反映確認 | SHOW shared_preload_libraries; | 必要なライブラリが含まれている | ポータルのサーバーパラメーター設定を見直し、反映のため再起動する |
| パラメーター変更後に再起動したか | 反映漏れの排除（Flexible Server で頻出） | ポータルから再起動（または運用手順に沿った再起動） | 再起動後に SHOW の値が意図どおり | 再起動していない場合は必ず実施。再起動済みでも反映しないならサポート候補 |
上の表を踏んだうえで、pg_available_extensions に拡張が見えていて、必要な前提も満たしているのに、CREATE EXTENSION が azure_pg_admin のエラーで落ちる場合は、次の「ハマりどころ」と「サポート依頼」へ進むのが効率的です。
よくあるハマりどころ：回避策っぽく見えて実は効かないパターン
このエラーが厄介なのは、ぱっと見「権限不足」なので、つい GRANT やロール付与で解決できそうに見える点です。しかし、Flexible Server 固有の制限や実装都合で、ユーザー側の権限付与では解決できないケースがあります。
| 試しがちな対応 | 結果 | なぜ効かない／注意点 | 次にやるべきこと |
|---|---|---|---|
GRANT azure_storage_admin TO <user>; | 環境によってはロールが存在せず失敗 | 拡張関連ロールは、環境や提供状況によって「そもそも作られていない」ことがある | ロールの有無を確認し、無い場合はユーザー側で無理に作ろうとしない |
GRANT azure_ai_settings_manager TO <user>; | 付与が通っても CREATE EXTENSION が失敗する | 設定ロールの付与と、拡張作成内部で必要な操作は別物。根本原因が azure_pg_admin 制限なら回避できない | 前提確認→再起動→再現するならサポートへ |
| 「管理者ユーザーだから必ず作れるはず」と考える | 管理者でも失敗することがある | Flexible Server の管理者は superuser ではなく、制限付きロールに触れない | current_user を確認し、制限事項として受け止める |
vector が作れるので「権限は問題ない」と判断 | 誤った安心材料になりやすい | 拡張ごとに内部処理・前提が違う。vector は作れても azure_storage/azure_ai は別の制限に当たることがある | 拡張単位で切り分けし、エラー文言を重視する |
切り分けの実務フロー：最小コストで「ユーザー起因」か「サービス起因」かを判定する
サポートへ連絡する前に、次の順番で切り分けると、時間を溶かしにくいです。ポイントは「同じサーバー内で条件を変えても再現するか」と「別サーバーでも再現するか」を押さえることです。
- エラー文言を固定化する
CREATE EXTENSION azure_storage;（またはCREATE EXTENSION azure_ai;）を実行し、同じエラー（permission denied to alter restricted role "azure_pg_admin"）が毎回出るか確認します。エラーが揺れる場合は、前提条件が揃っていない可能性が高いです。 - 同一サーバーで「新規データベース」に対して試す
既存 DB に他の拡張や権限設定が入っていても、azure_pg_adminエラー自体は通常変わりません。新規 DB で同じエラーなら「DB 内の状態が原因ではない」確度が上がります。 - 同一サーバーで「別の拡張」を作って比較する
vectorなど作成できる拡張がある場合、「接続ユーザー／基本権限は動いている」が確認できます。逆に、どの拡張も作れないなら接続ユーザーや権限の見直しが先です。 - 別サーバー（可能なら別リージョンや別 SKU）でも試す
もし別サーバーで同じ手順を踏んで問題なく作れるなら、特定サーバーの状態やバックエンドに寄った問題の可能性が上がります。逆に「どのサーバーでも同じエラー」なら、手順の見落とし、提供制限、または広域のサービス不具合の可能性を疑います。
サポートに依頼すべき判断基準：「前提 OK」なのに azure_pg_admin が出続ける
次の条件が揃ったら、ユーザー側の調整で粘るより、Microsoft サポートへエスカレーションしたほうが結果的に早いことが多いです。
pg_available_extensionsにazure_storage/azure_aiが表示される- allowlist、ライブラリ読み込みなど、公式手順に沿った前提設定を済ませている
- パラメーター変更後にサーバー再起動まで実施している
- それでも
permission denied to alter restricted role "azure_pg_admin"が継続する
この状態は「ユーザーが付与できないロールに関わる処理で止まっている」ため、ユーザー側でできる手当てが枯渇しやすいです。
Microsoft サポートへ渡す情報（そのまま貼れるテンプレ）
サポートは再現性と環境情報が揃うほど、バックエンド調査が進みやすくなります。以下を揃えて連絡すると、やり取りの往復を減らせます。
| 項目 | 例 | 意図 |
|---|---|---|
| サービス種別 | Azure Database for PostgreSQL Flexible Server | Single Server / Hyperscale 等との取り違え防止 |
| PostgreSQL バージョン | 15.13 | 拡張の提供状況・既知不具合の切り分け |
| リージョン／SKU | （例）Japan East、General Purpose など | リージョン依存・クラスター依存の可能性を判断 |
| 実行した SQL | CREATE EXTENSION azure_storage;（または CREATE EXTENSION azure_ai;） | 再現手順の中核 |
| エラー全文 | permission denied to alter restricted role "azure_pg_admin" | エラーの種類が重要（似た別エラーと切り分け） |
| 前提確認結果 | SELECT current_user; / SHOW azure.extensions; / SHOW shared_preload_libraries; / pg_available_extensions の結果 | 「ユーザー側でできることはやった」証跡になる |
| 再起動実施有無 | （例）2025-xx-xx に再起動済み | 反映漏れを先に潰す |
連絡文の例（調整して使ってください）：
Azure Database for PostgreSQL Flexible Server（PostgreSQL 15.13）で azure_storage（/ azure_ai）拡張を作成しようとすると、
CREATE EXTENSION 実行時に「permission denied to alter restricted role 'azure_pg_admin'」が発生して作成できません。
pg_available_extensions には拡張が表示され、allowlist（例：azure.extensions）と shared_preload_libraries の設定、再起動まで実施済みです。
同一サーバーの別拡張（例：vector）は作成できるため、接続ユーザーや基本権限の問題ではない可能性を疑っています。
バックエンド側の状態確認／是正をご支援ください。最終的な解消パターン：バックエンド是正で CREATE EXTENSION が通るようになった
今回のように、ユーザー側の前提条件を満たしてもエラーが変わらない場合、最終的に Microsoft 側でバックエンドの問題が緩和（是正）され、対象サーバーで拡張が正常に作成できるようになった、という形で解消することがあります。
このタイプの不具合は、利用者ができる設定変更ではなく、サービス内部の状態（拡張のプロビジョニング状態、制限ロール周りの内部処理、クラスター固有の設定など）に依存して発生することがあるため、サポート経由での対応が現実的です。
復旧後にやるべき動作確認（「作れた」で終わらせない）
バックエンド是正後に CREATE EXTENSION が成功したら、実運用に入る前に最低限の確認をしておくと安心です。
| 確認内容 | SQL 例 | 期待する状態 |
|---|---|---|
| 拡張の作成が成功する | CREATE EXTENSION azure_storage; | エラーが出ずに完了する |
| インストール済みとして登録されている | SELECT extname, extversion FROM pg_extension WHERE extname IN ('azure_storage','azure_ai'); | 該当拡張が表示され、バージョンが入っている |
| 再起動要否の確認 | SHOW azure.extensions; SHOW shared_preload_libraries; | 設定が想定どおり（運用手順と一致） |
| 実際の機能を軽く疎通 | （拡張の基本操作・最小機能で確認） | 認証・接続・簡易処理が通る |
運用上のコツ：同じトラブルを繰り返さないために
- 「サーバーパラメーター変更→再起動」をセットで記録する
Flexible Server はパラメーター反映に再起動が絡む項目があり、設定だけ変えて安心しがちです。変更履歴と再起動実施を運用記録に残しておくと、切り分けが早くなります。 - 拡張は「作成できるか」だけでなく「いつから作れたか」をメモする
サービス側の是正で改善するケースでは、同じ手順でも「ある日突然通る」ことがあります。時系列が残っていると、原因の特定や再発時の説明がしやすくなります。 - 回避策よりも「エラー文言」を信じる
今回のようにazure_pg_adminが絡むエラーは、ロール付与で殴っても解決しないことがあります。ユーザーが触れない領域に踏み込んでいるサインとして扱い、サポートへ切り替える判断基準にすると消耗を減らせます。
まとめ
Azure Database for PostgreSQL Flexible Server で azure_storage（/ azure_ai）拡張が permission denied to alter restricted role "azure_pg_admin" で作成できない場合、azure_pg_admin がプラットフォーム管理の制限付きロールである点が重要です。前提手順（allowlist、ライブラリ読み込み、再起動など）を満たしても改善しないときは、ユーザー設定ミスではなくサービス側の問題に当たっている可能性が高く、Microsoft サポートでのバックエンド調査・是正が近道になります。
コメント