Azure Cosmos DB for MongoDB (vCore) で「Create or Update Mongo Cluster」を実行した直後に Failed になり、アクティビティログに UnprocessableEntity（422 相当）が残る――この症状は“原因が一つに見えない”のが厄介です。本記事では、最小構成での再現確認から、HA・Private Link・CMK を段階的に有効化して原因を切り分ける実務手順を、チェック表と具体例つきで整理します。
症状：クラスター作成が実行直後に失敗するパターン
ポータルで Azure Cosmos DB for MongoDB (vCore) のクラスター作成（Create or Update Mongo Cluster）を実行すると、待ち時間がほとんどないまま失敗し、アクティビティログ（Activity log）のイベント JSON に以下のような情報が残ることがあります。
| ログ上の項目 | 例 | 読み取りのポイント |
|---|---|---|
| status | Failed | 操作自体が失敗として確定している状態 |
| error.code | ResourceOperationFailure | リソース側のプロビジョニングが失敗（ARM の入り口は通ったが内部処理で失敗） |
| terminal provisioning state | Failed | 最終状態が Failed で確定（再試行の余地がある失敗のことも多い） |
| details[0].code | UnprocessableEntity | 要求を処理できない（構成不整合、前提不足、内部例外などを広く含む） |
| details[0].message | An unknown error occurred... Tracking id: ... | 原因を JSON だけで断定できないため、Tracking ID を軸に切り分け・サポート連携が重要 |
特に「実行直後に即失敗」する場合は、実データの配置やノード構築が進む前に落ちている可能性が高く、次のような“作成リクエストの前提条件”で詰まっているケースが目立ちます。
- 作成時オプション（Private Link / CMK / 高可用性(HA) / SKU など）の組み合わせに矛盾がある
- vNet・サブネット・Private Endpoint・Private DNS のどこかが未設定/不整合
- CMK 利用時の Key Vault / マネージド ID の権限・ネットワーク設定が不足
- リージョン固有の制約・一時的なサービス側事象（混雑、内部障害、ロールアウト中など）
- サブスクリプションのクォータ、ポリシー（Azure Policy）、命名衝突などのガードレールに抵触
まず押さえるべき前提：UnprocessableEntity は“原因の箱”
Azure の 422 相当（UnprocessableEntity）は、入力値が明らかに間違っている場合だけでなく、「その構成では作れない」「必要な準備が揃っていない」「内部処理で例外が起きた」などが同じ表現に丸められることがあります。さらに、ポータルのウィザードは裏側で複数の設定（ネットワーク、暗号化、ID など）をまとめて作成・更新するため、失敗地点が見えにくいのが現実です。
そこで効果的なのが、原因を推測で当てにいくのではなく、構成を極限まで単純化して「通る最小構成」を確立し、そこから 1 個ずつ要素を足していくという切り分けです。これにより、失敗の境界（どの要素を追加した瞬間に落ちるか）を高い確度で特定できます。
切り分けの全体像：最小構成 → 追加テストの順番が重要
| フェーズ | 目的 | やること | 失敗したら疑う範囲 |
|---|---|---|---|
| 最小構成 | ベースの作成が可能か確認 | Public、CMK/HA なし、小さめ SKU で作成 | リージョン、クォータ、ポリシー、権限、サービス事象 |
| スケール変更 | サイズ要因の切り分け | ノード Tier / ディスク等を段階的に上げる | クォータ、在庫/容量、SKU 制約 |
| HA 有効化 | 可用性要因の切り分け | HA をオンにする（作成後に変更） | ゾーン対応、リージョン制約、クォータ |
| Private Link | ネットワーク要因の切り分け | クラスター作成後に Private Endpoint/DNS を追加 | DNS、サブネット、NSG/UDR、名前解決 |
| CMK | 暗号化要因の切り分け | Key Vault/MI を整えた上で CMK を有効化 | 権限（wrap/unwrap）、Key Vault FW、テナント/リージョン整合 |
ポイントは順番です。いきなり「HA + Private Link + CMK + 大きな SKU」にすると、失敗の原因が複数重なり、Tracking ID があっても現場で切り分けに時間がかかります。まずは「素の状態で作れる」ことを確認し、再現性のある差分テストに持ち込むのが最短ルートです。
手順：最小構成でクラスター作成を試す
最小構成の目安（最初の一回は割り切る）
- Private Link なし（パブリックネットワーク）
- CMK なし（Microsoft 管理キー）
- HA なし
- 小さめの SKU（例：M10 相当）
- 可能なら別リージョンでも同一手順で試す（リージョン要因の排除）
この段階では「セキュアな最終構成」を目指すよりも、作成の成否を分ける要素を切り出すことを優先します。
Azure Portal で試す場合のコツ
- クイックスタート／ウィザードで、まずはデフォルトに近い設定で進める
- ネットワークは可能な限りシンプルに（Public を許容できる環境なら最初は Public）
- 暗号化・ID・Private Endpoint あたりを作成時に盛らない
- 組織ポリシーで Public が禁止されている場合は「Private Link のみ有効（CMK/HA はオフ）」を“最小構成”として扱う
企業環境では Azure Policy により「許可リージョン限定」「必須タグ」「Public 禁止」などが設定されていることが多く、ウィザード上は正しく見えても背後で Deny されるケースがあります。最小構成の定義は、あなたの組織の制約の範囲内で最小にするのが現実的です。
Azure CLI で試す（作成リクエストを安定して再現できる）
Azure CLI で作成できると、ポータル UI 特有の問題や、入力のブレを排除しやすくなります。以下は最小構成の例です（値は適宜置き換えてください）。
# cosmosdb-preview CLI 拡張が初回実行時に自動インストールされる前提
az cosmosdb mongocluster create \
--cluster-name mytestcluster \
--resource-group <リソースグループ名> \
--location eastus \
--administrator-login <管理者ユーザー名> \
--administrator-login-password '<強力なパスワード>' \
--server-version 7.0 \
--shard-node-tier M10 \
--shard-node-disk-size-gb 128 \
--shard-node-ha false \
--shard-node-count 1運用上は、パスワードをコマンドラインに直書きすると履歴に残りやすい点に注意してください。検証時は使い捨ての資格情報にする、環境変数経由にする、実運用ではシークレット管理に寄せるなどの対策が安全です。
作成結果の確認（成功/失敗の判定を機械的に）
「ポータルの画面が戻った」「通知が消えた」ではなく、プロビジョニング状態で判定すると迷いが減ります。
# クラスターの状態確認（例）
az cosmosdb mongocluster show \
--resource-group <リソースグループ名> \
--cluster-name mytestcluster \
--query "{state:provisioningState, location:location, name:name}" \
-o tableここで最小構成が成功するなら、Cosmos DB for MongoDB (vCore) を作る“土台”は整っています。次は差分テストに移行します。
最小構成でも即失敗する場合のチェックリスト
最小構成で落ちる場合は、Private Link や CMK 以前の問題（リージョン・権限・ポリシー・クォータ）が濃厚です。以下のチェックを上から順に潰すと、調査が発散しにくくなります。
| チェック項目 | 確認方法（例） | なぜ効くか |
|---|---|---|
| リージョン要因 | 別リージョンで同じ最小構成を試す | リージョン固有の制約や一時的な事象を切り離せる |
| サービス健全性 | Azure の Service Health / Resource Health を確認 | 障害・メンテ・制限が原因なら構成をいじっても直らない |
| サブスクリプションの権限 | 作成者が対象 RG に対して作成権限を持つか（RBAC） | 権限不足は“即失敗”の典型。UI 上のメッセージが薄い場合もある |
| リソースプロバイダー登録 | Microsoft.DocumentDB 等が Registered か確認 | 未登録だと内部処理に入れず失敗することがある |
| Azure Policy（Deny / 必須タグ / 許可リージョン） | 管理グループ/サブスクリプション/RG に割り当てられたポリシーを確認 | 「Public 禁止」「タグ必須」などは構成と衝突しやすい |
| クォータ/上限 | ポータルの「使用量 + クォータ」、該当リージョンの上限を確認 | vCore やストレージ/コア数上限に当たると作成が落ちる |
| 命名衝突（DNS/名前） | クラスター名を十分ユニークにして再作成 | DNS 名生成や内部リソース名の衝突で失敗するケースがある |
| リソースロック | RG/関連リソースに Lock がないか確認 | 作成/更新系の派生操作がブロックされると失敗が見えにくい |
CLI で確認しておくと強いポイント
組織環境では「たまたま自分の権限だけ弱い」「プロバイダー未登録」「ポリシーで Deny」などが混在しがちです。代表的な確認例をまとめます。
# リソースプロバイダー登録状態（例）
az provider show -n Microsoft.DocumentDB --query "registrationState" -o tsv
# 未登録なら登録（権限が必要）
az provider register -n Microsoft.DocumentDB
# リソースグループのロック確認
az lock list -g <リソースグループ名> -o tableまた、必須タグを強制する Azure Policy がある場合、ポータルでは自然に入力していても CLI では抜けることがあります。CLI で作るときは、組織ルールに合わせてタグも付与しておくと不要な失敗を避けられます。
# 例：タグ必須ポリシーがある環境での考え方（実際のタグキーは環境に合わせて）
# CLI の対象コマンドがタグに対応していない場合は、作成後にタグ付け/ARM で作成する等を検討
az group show -n <リソースグループ名> --query tags -o json最小構成で成功したら：オプションを一つずつ戻して原因を特定する
最小構成で成功した時点で、「サービスが作れない」「リージョンが完全に壊れている」「サブスクリプション全体が詰んでいる」といった可能性は大きく下がります。ここからは、失敗が再現する“差分”を作るフェーズです。
おすすめの追加順（失敗箇所が見えやすい）
| 追加する要素 | 追加の狙い | この段階での確認観点 |
|---|---|---|
| スケールアップ（Tier/ディスク/ノード数） | サイズ・在庫・クォータ要因の検出 | クォータ、SKU の制約、リージョンの容量 |
| HA（高可用性） | 可用性オプションの制約検出 | ゾーン対応、ノード構成の要件、コスト/上限 |
| Private Link / Private Endpoint | ネットワーク要因の切り分け | DNS、サブネット、NSG、ルート、接続確認 |
| CMK（お客様管理キー） | Key Vault・権限・暗号化要因の切り分け | MI 権限、Key Vault の FW/PE、同一テナント整合 |
特に Private Link と CMK は、それぞれ単体でも前提条件が多い機能です。同時に有効化すると「ネットワークが原因なのか権限が原因なのか」を見失いやすいため、段階導入が有効です。
HA（高可用性）を有効化するときの実務ポイント
HA は可用性を上げる一方、ノード構成やリージョンの要件、クォータの消費量に影響します。最小構成で成功した後に HA をオンにすることで、「作成時に HA が絡むと落ちる」のか、「HA 自体が組織やリージョンで許可されていない」のかを切り分けられます。
- まずは作成済みクラスターが正常（Succeeded）であることを確認してから変更する
- HA の前に、Tier/ノード数などを段階的に上げ、上限に当たらないことを確認する
- リージョンがゾーン冗長に対応しているか、組織の制約がないかも併せて確認する
現場感として、HA の有効化は「作成は通るが変更で落ちる」ケースと、「作成時に HA が入ると落ちる」ケースで対応が変わります。前者ならクォータやリージョン容量、後者ならオプション組み合わせや前提不足（別設定との衝突）を疑うのが近道です。
Private Link / Private Endpoint で“Unknown error”になりやすい落とし穴
Private Link を作成時から有効にすると、クラスター側の作成とネットワーク側の準備が同時進行になり、どこで失敗したかが見えにくくなります。まずはクラスター作成後に Private Endpoint を追加し、ネットワーク問題を独立して検証できる状態を作るのがおすすめです。
実装時に押さえるチェックポイント
| チェックポイント | よくあるミス | 症状 | 確認・対処 |
|---|---|---|---|
| サブネット | Private Endpoint 用サブネットに制約（ポリシー/委任/枯渇）がある | 作成が失敗、または作成できても接続不可 | 十分な IP がある専用サブネットを用意し、NSG/UDR の影響も確認 |
| Private DNS | DNS ゾーンを作っただけで VNet にリンクしていない | 名前解決が Public 側を向く | VNet リンクと A レコードの自動作成/関連付けを確認 |
| 名前解決経路 | オンプレ/別 DNS を使っていて Private DNS が参照されない | 社内から接続できない、環境により挙動が違う | クライアントが参照している DNS を特定し、転送/条件付きフォワーダ等を設計 |
| NSG/Firewall/UDR | アウトバウンド制御で必要な宛先がブロックされる | 接続タイムアウト | 疎通テストでポート到達性を確認し、ルーティングと FW ルールを見直す |
| 作成タイミング | クラスター作成と同時に PE を作成し、どちらが原因か不明に | Unknown error で即失敗し原因が追えない | クラスター作成→Succeeded→PE 追加、の順で差分検証 |
名前解決とポート疎通の確認例（最短で詰まり箇所を特定）
Private Link 構成で重要なのは、まず名前解決が Private IP を返すか、次に接続文字列に書かれたポートへ到達できるかです。
Windows（PowerShell）例
# 名前解決（返ってくる IP が Private Endpoint の IP か確認）
Resolve-DnsName <クラスターのホスト名>
# ポート疎通（ポートは接続文字列に合わせる）
Test-NetConnection <クラスターのホスト名> -Port <ポート番号>Linux 例
# 名前解決
nslookup <クラスターのホスト名>
# ポート疎通
nc -vz <クラスターのホスト名> <ポート番号>ここで名前解決が Public IP 側を向いているなら DNS が原因、Private IP なのに疎通できないなら NSG/UDR/FW が原因、疎通できるのにアプリが繋がらないなら TLS 設定や接続文字列の問題、といった具合に切り分けが一気に進みます。
CMK（お客様管理キー）で失敗する代表パターンと対策
CMK を有効化する場合、Cosmos DB 側が Key Vault のキーを使って暗号化処理を行うため、権限とKey Vault のネットワーク到達性の両方が揃っていないと失敗しやすくなります。しかも失敗時の表現が UnprocessableEntity などに丸められやすく、見た目は「未知のエラー」になりがちです。
CMK 構成で最低限そろえる要件（チェック表）
| 要件 | 満たすべき内容 | 落ちたときに起こりがちな症状 |
|---|---|---|
| マネージド ID | ユーザー割り当てマネージド ID（推奨）を用意し、クラスターに関連付け | Key Vault 側の監査/権限が追えない、意図しない ID で拒否される |
| キー権限 | Key Vault のキーに対して get, wrapKey, unwrapKey（相当の権限）を付与 | 作成・更新が即失敗、内部エラー扱い |
| 権限モデル | Access policy 方式または RBAC 方式のいずれかに統一し、設定を二重管理しない | 付与したはずの権限が効かない、環境によって挙動が違う |
| Key Vault のネットワーク | Key Vault がクラスターから到達できる（Public 許可 or Private Endpoint + DNS） | 権限はあるのに“Unknown error”で失敗 |
| テナント整合 | Key Vault / マネージド ID / クラスターが同一テナントで整合 | 認可が通らず失敗、原因が見えにくい |
| リージョン設計 | 設計上、Key Vault と暗号化対象が近いリージョンで管理（運用要件に合わせる） | ネットワーク設計が複雑化し失敗率が上がる |
現場で多い“CMK だけ通らない”ケース
- Key Vault の FW が厳しすぎる：Public を閉じ、Private Endpoint も未整備で到達できない
- 権限の付与先が違う：想定と別の ID（システム割り当て/ユーザー割り当て）に権限を付けている
- RBAC と Access policy が混在：運用の途中で切り替えたが、実際に評価される設定が想定と違う
- キーの指定が不適切：無効化されたキー、バージョンの扱い、キーの状態が想定外
CMK の切り分けは、Private Link の切り分けと同様に単体で検証できる状態を作るのが重要です。具体的には、「クラスターは Public のまま」「Key Vault も一旦 Public 許可（検証環境のみ）」「必要権限を付与した MI を使う」という“通るはずの前提”を先に揃え、成功確認ができてから段階的に Key Vault のネットワークを閉じていくと、原因が一点に収束しやすくなります。
「ポータルだと失敗、CLI だと成功/失敗が違う」場合の考え方
ポータルは便利ですが、背後で複数の API を呼び分けたり、既定値としてオプションを補完したりします。そのため、次のようなときは CLI の併用が効果的です。
- ポータル上はエラーが「Unknown」で、どの入力が悪いか分からない
- 同じ画面操作のはずなのに、担当者によって成否がぶれる
- Azure Policy や権限の影響を受けやすい環境で、作成条件を固定したい
また、同じ最小構成を CLI で何度でも再現できる状態を作っておくと、リージョン差や時間帯差などの外部要因も比較しやすくなります（例：eastus では成功、別リージョンでは失敗、など）。
アクティビティログの見方：Tracking ID を“調査の主キー”にする
UnprocessableEntity が出たとき、現場で最も価値があるのは「どの操作の」「どの失敗なのか」を一意に示す情報です。ポータルの通知だけでは足りないため、アクティビティログのイベント JSON から以下を確実に控えます。
| 控える情報 | 例 | 用途 |
|---|---|---|
| Tracking ID | Tracking id: ... | サポート/内部調査で失敗を特定するキー |
| 操作名 | Create or Update Mongo Cluster | どの API 操作が失敗したかを明確化 |
| 発生日時（UTC/ローカル） | 2025-xx-xx xx:xx | ログ突合・事象確認の基準 |
| 対象リソース ID | /subscriptions/.../resourceGroups/.../providers/.../... | 対象範囲の特定 |
| 失敗コード一式 | ResourceOperationFailure, UnprocessableEntity | 分類（ネットワーク/権限/サービス）を絞る材料 |
| 関連する設定差分 | HA on/off、CMK on/off、PE 有無、SKU など | 再現条件の整理（差分テストの説明に必須） |
サポートに問い合わせる場合は、Tracking ID に加え「最小構成で成功/失敗したか」「どのオプションを追加した瞬間に失敗へ転じたか」を添えると、調査が格段にスムーズになります。単に“失敗します”ではなく、再現条件（成功条件と失敗条件の差）があると強いです。
それでも直らないときの“現実的な打ち手”
ここまでの切り分けをしても、最小構成で即失敗が続く、あるいは特定オプションを有効化した瞬間に必ず Unknown error になる場合は、次の順に対処すると無駄が減ります。
- 別リージョンで同一の差分テストを再現し、リージョン依存かどうかを確定させる
- サブスクリプションのクォータ、組織のAzure Policy、権限（RBAC）を再点検する
- ポータルではなくAzure CLI で同一パラメータで作成し、再現性を確保する
- アクティビティログのTracking IDを添えて、Azure サポートに問い合わせる
特に “Unknown error + Tracking ID” まで出ている場合、内部ログを参照できるのはサポート側になるため、最後は Tracking ID 付きでのエスカレーションが最短になることがあります。重要なのは、問い合わせ時点で切り分けが終わっている（どの条件で落ちるか説明できる）状態を作ることです。
よくある質問
最小構成で成功したのに、Private Link を入れると作成や更新が失敗します。何から見ればいいですか？
最優先は DNS です。クラスターのホスト名が Private IP を返しているか、次に接続文字列のポートへ到達できるかを確認してください。DNS が Public を向いたままだと、ネットワークをいくら調整しても直りません。名前解決が Private なのに疎通できない場合は NSG/UDR/FW の順で疑うと早いです。
CMK を入れると Unknown error になります。Key Vault の権限は付けたはずです。
「どの ID に付けたか」と「Key Vault にネットワーク的に到達できるか」をセットで見直してください。ユーザー割り当て MI を使う場合、Key Vault に権限を付ける対象がその MI になっているか、Key Vault が Public を閉じているなら Private Endpoint + DNS が整っているか、RBAC/Access policy の方式が混在していないか、が典型的な落とし穴です。
組織ポリシーで Public が禁止です。最小構成はどう定義すべきですか？
その場合は「Private Link のみ有効、CMK と HA はオフ、SKU は小さく」を最小構成として扱うのが現実的です。Public を試せない環境では、最初に DNS とサブネット設計を確実にし、Private Endpoint を最小の要素として“通る形”を作ってから追加要素を積むのが安全です。
まとめ：即失敗エラーは“構成の最小化”が最短ルート
Azure Cosmos DB for MongoDB (vCore) のクラスター作成が UnprocessableEntity で即失敗する場合、JSON だけで原因を決め打ちするのは難しい一方で、切り分けの手順さえ守れば原因は高確度で絞れます。
- まずは Public / CMK なし / HA なし / 小さめ SKU の最小構成で作成し、土台が通るか確認する
- 最小構成で成功したら、HA → Private Link → CMKの順で 1 つずつ戻し、どこで失敗へ転じるかを特定する
- 最小構成でも失敗するなら、リージョン、クォータ、権限、Azure Policy、命名衝突など環境側の要因を優先的に疑う
- 最後は Tracking ID を主キーにして、差分条件（成功/失敗）を添えてサポートへつなぐ
この流れを徹底することで、「作成直後に Unknown error で落ちる」という最も消耗しやすいトラブルでも、再現性のある手順で原因を段階的に特定しやすくなります。
コメント