Azure Database for PostgreSQL Flexible Server を削除しようとすると、Azure ポータルでは「状態：Ready」に見えているのに、削除操作では ResourceNotFound が出て詰まることがあります。さらに Azure CLI の az postgres flexible-server list では Dropped と表示され、表示と実態が食い違って混乱しがちです。本記事では、この現象が起きる理由と、現場での確認手順・待つべきタイミング・サポートへ切り替える判断基準をまとめます。
現象：ポータルは Ready、削除は ResourceNotFound、CLI では Dropped
典型的な症状は次の組み合わせです。
- Azure ポータル上では PostgreSQL Flexible Server が 状態：Ready のまま表示され続ける
- しかし削除操作を行うと、以下のようなエラーで止まる
- ポータル：
ResourceNotFound - Azure CLI：
The requested resource of type 'Microsoft.DBforPostgreSQL/flexibleServers' with name 'XXXX' was not found. Code: ResourceNotFound
- ポータル：
- 一方で、
az postgres flexible-server listの結果において対象サーバーの状態がDroppedになっている
この状態は「削除できない」というより、削除の内部処理が“見えないところで進んでいる（または中途半端に止まっている）ことが多く、表示レイヤー（ポータル）と実体レイヤー（バックエンド）の同期ズレで発生します。
| 観測ポイント | 表示・結果 | 何が起きている可能性が高いか | 最初にやるべきこと |
|---|---|---|---|
| Azure ポータル | 状態：Ready のまま残る | 表示更新が遅れており、実体は削除処理中／論理削除済みの可能性 | CLI で state を確認し、待機判断へ |
| 削除操作（ポータル/CLI） | ResourceNotFound | バックエンドでは「既に存在しない」扱いになっている（再削除が NotFound になる） | 連打せず、整合が戻るまで待機 or サポート |
az postgres flexible-server list | Dropped / Dropping | 削除処理が進行中、または論理削除状態のまま固着 | 時間を置いて再確認し、長期化ならエスカレーション |
なぜ ResourceNotFound になるのか：表示と実体の“非同期”が原因
Azure のリソース削除は、画面上のボタンを押した瞬間に「すべてが即時に消える」動きではなく、複数の内部処理（コンピュート、ストレージ、ネットワーク、監査情報、バックアップやメタデータの掃除など）を順番に進める非同期処理になっていることが多いです。
このとき発生しやすいのが、次のようなズレです。
- バックエンド側では削除が進み、論理的には“存在しない”状態になっている
- しかしポータル側の表示はすぐに反映されず、Ready に見え続ける
- その状態で削除を再実行すると、バックエンドは「もう無い」前提で処理するため
ResourceNotFoundが返る
つまり、ResourceNotFound は「何も起きていない」ではなく、むしろ削除が進んでいて再操作が噛み合っていないサインになり得ます。ここで焦って削除操作を繰り返すと、状況が改善するどころか「状態確認が難しくなる」「オペレーションログが増えて判断が遅れる」ことがあるため、いったん落ち着いて観測に切り替えるのが実務的です。
Dropped / Dropping は何を意味する？
az postgres flexible-server list に表示される state は、ポータル上の表記と一致しないことがあります。特に Dropped は、一般的な感覚だと「もう消えている」ですが、現場では次のように捉えると事故が減ります。
Dropping：削除フローが走っている途中（内部処理が残っている）Dropped：バックエンド上は削除済み（または論理削除）扱いだが、表示や参照が完全に消えるまでラグがある／不整合で固着している可能性
結果として「ポータルには見えるのに、削除 API では NotFound」「リストには残るのに show は NotFound」など、矛盾した見え方になります。
| state（CLI） | 現場での解釈 | やってよいこと | 避けたいこと |
|---|---|---|---|
Ready | 通常稼働。削除操作が通るべき状態 | ポータル/CLI で削除を実施、削除開始を確認 | 別サブスクリプション/別 RG を誤って操作すること |
Dropping | 削除進行中。内部処理の完了待ちが必要 | 待機して定期的に再確認、ログ収集 | 削除の連打（改善しにくい） |
Dropped | 論理削除済み or 削除完了目前だが表示が残る／不整合の可能性 | 待機→消えないならサポートへ切替 | 「まだあるはず」と決め打ちして再削除を繰り返す |
まずやるべき確認：本当に“正しい場所”のサーバーを見ているか
この手のトラブルはバックエンド不整合が原因で起きることがある一方で、初動で切り分けないといけない「よくある勘違い」も混ざります。特に複数サブスクリプションや複数環境（dev/stg/prod）を跨ぐ運用では、確認不足が原因で同じように見えることがあります。
サブスクリプションの確認
CLI は「今どのサブスクリプションを見ているか」で結果が変わります。まずは現在のコンテキストを確認します。
az account show想定と違う場合は切り替えます。
az account set --subscription "<サブスクリプションID or 名称>"リソースグループとサーバー名の確認
同名サーバーを別 RG に作っていた、削除対象が別環境だった、という事故も多いので、一覧と対象の突合を必ず行います。
az postgres flexible-server list -o tableリソースグループを絞って確認するのも有効です。
az postgres flexible-server list --resource-group "<RG名>" -o tableポータル表示が怪しいときの“見え方”対策
- ポータルをリロードしても残る場合、ブラウザのキャッシュや表示更新の遅延が疑われます
- 別ブラウザやシークレットウィンドウで同じリソースを検索し、見え方が一致するか確認します
- 可能なら Azure Resource Graph（ポータルの Resource Graph Explorer）でも検索し、実際にリソースが引けるか確認します
表示だけ残っている場合、見た目は「削除できていない」ですが、バックエンドでは削除完了に向けて収束しているケースがあります。
実務的な対処フロー：待機→再確認→エスカレーション
このトラブルは、ユーザー操作で“押し切る”より、状態を観測して適切に待つほうが解決に近いことが多いです。現場で使えるフローを、迷いにくい形に落とします。
状態確認の基本コマンド
まずは一覧で state を確認します。
az postgres flexible-server list -o table対象だけを取りたい場合の例です（環境に合わせて変更してください）。
az postgres flexible-server list \
--query "[?name=='XXXX'].[name,resourceGroup,state,location]" \
-o tableここで state が Dropping / Dropped なら、ポータルが Ready に見えても「裏では削除が動いている（または論理削除済み）」可能性が上がります。
短時間でやること：待機して“消えるか”を観測する
Dropped が出ているのに削除が通らない場合、追加操作で改善することは多くありません。まずは以下を“セット”で確認します。
- ポータル上で対象サーバーが一覧から消えるか
az postgres flexible-server listの一覧から対象が消えるか- 同名サーバーの再作成を考えている場合、名前が再利用できる状態になっているか（消えるまで待つほうが安全）
今回のように、数時間放置したら自然に詰まりが解消し、削除できる状態に戻る（あるいは表示から消える）ことがあります。これは、Azure 側のバックグラウンド処理が完了し、整合性が回復したパターンです。
やりがちだが効きにくい行動：削除の連打
ポータルで削除→失敗→CLIで削除→失敗…を繰り返したくなりますが、ResourceNotFound 系は「すでに無い扱い」で返っていることが多く、同じ操作を重ねても状況が変わりにくいです。
- 削除要求が重複し、状況がわかりにくくなる
- ログが増えて、どの操作が有効だったか追いにくい
- オペレーションの最終状態が収束する前に別操作が入り、判断がブレる
このため、削除の成否を「操作」ではなく「観測」で判断するのがポイントです。
原因の本命：バックエンド不整合（いわゆる“腐敗”）で固着するケース
Flexible Server の削除が Dropping で止まったり、Dropped 表示のまま残り続けたり、ポータル表示と噛み合わない動きをする場合、バックエンド側のデータ整合が崩れている（不整合が起きている）ケースがあります。
このタイプは、ユーザー側でできることが限られます。理由は単純で、リソースの実体管理（内部メタデータの掃除、割り当て解除、残骸の除去など）が Azure 側の管理領域にあり、ユーザー操作で強制的に直せないためです。
そのため長期化した場合は、最終的にMicrosoft 側の内部チームがバックエンドから強制的に drop（削除完了に収束させる処理）を行う必要が出ます。過去に同様の事象が複数回起き、サポート対応で解消したケースがあるなら、今回も同系統である可能性が高いと言えます。
サポートへ切り替える判断基準
待てば直るケースがある一方で、「待っても直らない」ケースもあります。運用上は、次のような条件がそろったらサポートへ切り替えると合理的です。
Dropping/Droppedの状態が長時間変わらない- ポータルでは残り続け、CLI では
ResourceNotFoundが繰り返し出る - 同名で再作成したい、環境のクリーンアップ期限があるなど、ビジネス上の制約がある
- 同じ事象が過去にも発生しており、サポートのバックエンド作業が必要だった実績がある
現場の体感としては、削除が収束する兆し（表示から消える、一覧から消える）が見えない状態が続くほど、ユーザー側で解決できる確率は下がります。逆に、時間経過で少しでも表示が変化するなら、バックグラウンド処理が進んでいる可能性があるため、もう少し待つ判断がしやすくなります。
サポート依頼で渡すべき情報（早く片付けるためのテンプレ）
サポートに投げるときは「状況の再説明」に時間が溶けがちです。最初から必要情報を揃えると、一次切り分けが短縮されやすくなります。
| 項目 | 例 | 補足 |
|---|---|---|
| サブスクリプション ID | xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | CLI の az account show でも確認 |
| リソース グループ名 | rg-example-prod | 対象が複数あるなら環境名も明記 |
| サーバー名 | pg-flex-xxxx | ポータルに見えている表示名と一致させる |
| 発生日時（開始・継続） | 削除実行した日時、現在も継続中 | タイムゾーンも書くと会話が早い |
| 観測結果 | ポータル：Ready のまま／削除で ResourceNotFound、CLI：list で Dropped | 矛盾している点をそのまま書くのが重要 |
| エラーメッセージ全文 | Code: ResourceNotFound など | 省略せず貼る（コピペ推奨） |
依頼文の例（要点だけ）をそのまま使える形にすると次のようになります。
Azure Database for PostgreSQL Flexible Server の削除が完了せず、ポータル表示と CLI の state が不一致です。
- Subscription: <ID>
- Resource Group: <RG>
- Server: <name>
- Portal: 状態 Ready に見えるが削除操作で ResourceNotFound
- CLI: az postgres flexible-server list で state が Dropped
バックエンドの整合性不整合が疑われるため、内部側での強制 drop を含めた調査・解消をお願いします。削除完了の確認方法：消えた“つもり”を防ぐ
この現象は「消えたように見える」「残っているように見える」が揺れるのが厄介です。最終確認は、複数の視点で行うのが安全です。
- ポータル：対象サーバーが一覧・検索に出てこない
- CLI：
az postgres flexible-server listから対象が消えている - 運用目線：同名再作成が必要なら、名前が再利用可能になっている（再作成フローで確認）
また、削除が絡むトラブル時は「コストが心配」という声も出ます。基本的には稼働しているリソースに対して課金が発生しますが、表示が不安定な期間は判断が難しいこともあります。必要に応じて、対象期間のコスト分析や請求明細（サービス別）で“課金対象として残っていないか”を合わせて確認すると安心です。
再発を減らす運用のコツ
バックエンド不整合はユーザーの責任で起きるものではありませんが、運用設計でダメージを小さくできます。頻繁に作成・削除を繰り返す環境ほど、次の対策が効きます。
環境ごとにリソースグループを分離し、掃除を簡単にする
dev/stg/prod が同一 RG に混在していると、削除の影響範囲が大きくなり、切り分けも難しくなります。環境単位で RG を分けておくと、障害時に「どこまで影響しているか」が明確になります。
サーバー名にユニーク性を持たせ、削除ラグの影響を受けにくくする
削除直後に同名で作り直したい運用は、削除ラグや名前再利用の制約にぶつかりやすくなります。CI/CD で短命環境を作るなら、日付やビルド番号、ランダムサフィックスを付けて衝突を避けると、詰まったときの逃げ道が増えます。
削除は“バッチ化”して監視し、詰まったらすぐ検知する
手作業削除だと「いつから詰まっているか」が曖昧になります。削除ジョブを決まった時間にまとめ、結果（成功/失敗/残存）をログとして残すと、長期化を早期に検知できます。特に柔軟サーバーを頻繁に作り直す開発環境では、運用の差がトラブル時の復旧速度に直結します。
まとめ：Ready に見えても、実体が Dropped なら“待つ”が第一手
PostgreSQL Flexible Server の削除で ResourceNotFound が出るのに、ポータルでは Ready のまま残る現象は、ポータル表示とバックエンド状態の不一致によって起きることがあります。CLI の state が Dropping / Dropped なら、内部では削除処理が進行中、または論理削除済みで参照がズレている可能性が高く、削除の連打で改善するケースは多くありません。
実務としては、まず CLI で状態を確認し、一定時間待機して収束するか観測するのが現実的です。それでも長時間変化がない場合は、ユーザー側でできる対処は限られるため、必要情報を添えて Azure サポートへ依頼し、バックエンド側での強制 drop を含む対応を取ってもらうのが最短ルートになります。
コメント