Azure Cosmos DB for MongoDB API を Microsoft Entra ID（Azure AD）のサービスプリンシパルで認証すると、ドキュメントのCRUDは成功するのに、コレクション／インデックスの作成・更新だけが 403 Forbidden（Substatus: 5300）になることがあります。本記事では原因を整理し、Azure ADを活かした実務的な回避策（ポータル・CLI・PowerShell・IaC）まで具体例つきで解説します。
結論：Azure AD認証のまま「MongoDB経由」でコレクション／インデックス作成は通らない
まず結論から言うと、Azure Cosmos DB for MongoDB API × Azure AD（Microsoft Entra ID）認証では、MongoDBの管理系コマンド（コレクション作成・更新、インデックス作成・更新など）が403 Forbidden（Substatus: 5300）でブロックされる挙動は既知の制限として扱われています。
Microsoft Q&A でも「現時点では、Azure ADでの管理操作（コレクション／インデックス作成・更新）はできず、ポータル／CLI／キーで実施が必要」と明記されています。つまり、Azure ADでログインしているのに弾かれているのは「ロールが足りない」というより、認証方式と実行経路の組み合わせがサポート外という性質が強いです。
403 Forbidden（Substatus: 5300）は何を意味するのか
Substatus 5300 が出るケースで代表的なのが、「AAD（Entra ID）トークンではそのリクエストを認可できない」というパターンです。実際に、データプレーンSDKでデータベース作成などを行うと、エラーメッセージに「AAD token では認可できない」旨が含まれる例があります。
MongoDB APIでも「ドキュメントCRUDは通るのに、コレクション／インデックス作成が 403（5300）で止まる」という症状は同系統で、“非データ操作（管理操作）”として扱われるコマンドがAzure ADトークン経由では許可されないことが根本原因になりやすいです。
なぜCRUDは成功するのに、作成・更新だけ失敗するのか
ここが混乱しやすいポイントです。Cosmos DB は大きく分けて、操作の性質が2つあります。
| 区分 | 例 | 主な実行経路 | 典型的な認証・権限 |
|---|---|---|---|
| データ操作（Data plane） | ドキュメントのfind/insert/update/delete など | データエンドポイント（MongoDB wire protocol / SDK） | Mongoの認証（キー・ユーザー）や、Entra IDを使ったデータアクセス（構成による） |
| 管理操作（Control plane / 非データ操作） | アカウント/DB/コレクションの作成・更新、スループット設定、構成変更 など | Azure Resource Manager（ARM）経由、ポータル、CLI、PowerShell、IaC | Azure RBAC（Contributor 等） |
Azure RBACのContributorや Microsoft.DocumentDB/* を含むカスタムロールは、基本的にコントロールプレーン（ARM）側の操作に効きます。一方で、アプリやMongoDBドライバから実行するコマンドはデータプレーン経由になるため、同じサービスプリンシパルでも「通る操作」と「通らない操作」が発生し得ます。
Microsoft Q&Aの回答でも、CRUDはできてもコレクション／インデックス作成は制限される旨が示され、現時点ではAzure AD経由でMongoDB側から管理操作を実行する道は用意されていない、という整理になっています。
Azure AD認証で「管理操作」を実現する現実解
「Azure ADだけで全部やりたい」という気持ちは自然ですが、実務では次の分離が最も事故が少なく、監査にも強いです。
| やること | おすすめ実施タイミング | おすすめ実施手段 | キーは必要？ |
|---|---|---|---|
| コレクション作成・スループット設定 | デプロイ時（IaC/パイプライン） | Azure Portal / Azure CLI / PowerShell / ARM/Bicep/Terraform | 不要（Azure AD + Azure RBACで可） |
| インデックス定義（TTL/ユニーク含む） | 基本はデプロイ時（特にユニーク） | Portal / CLI / PowerShell / テンプレートのindexes定義 | 不要にできるケースが多い |
| ドキュメントCRUD（アプリ本体） | 実行時（ランタイム） | アプリからMongoDBドライバ | 設計次第（Entra ID/キー/ユーザー） |
ポイントは、管理系はARM（コントロールプレーン）に寄せることです。これにより、サービスプリンシパルのContributor権限が素直に効くようになり、アプリ起動時に“勝手にスキーマを変える”設計も避けられます。
具体策：Azure CLIでコレクション作成とインデックス定義を完結させる
Azure CLI には MongoDB コレクション作成コマンドがあり、インデックスをJSONで渡すこともできます。これはARM経由の管理操作なので、Azure ADログイン（サービスプリンシパル）＋Azure RBACで実施できます。
代表的な形は次のとおりです（コマンド例は最小構成にしています）。
az cosmosdb mongodb collection create \
-g <ResourceGroup> \
-a <CosmosAccountName> \
-d <MongoDatabaseName> \
-n <CollectionName> \
--shard <ShardKey> \
--throughput 400 \
--idx @indexes.json--idx は、TTLやユニークのようなオプションを含むインデックス定義を渡せます（CLIヘルプにも例が載っています）。
例：TTL（expireAfterSeconds）とユニークインデックスのイメージ（実際の要件に合わせてキー名は調整してください）。
[
{
"key": { "keys": ["_ts"] },
"options": { "expireAfterSeconds": 604800 }
},
{
"key": { "keys": ["user_id", "user_address"] },
"options": { "unique": true }
}
]このアプローチの利点は、アプリの実行経路にCosmos DBのキー（アカウントキー）を持ち込まなくて済むことです。管理操作はデプロイパイプラインに閉じ、運用上の責任分界（誰がスキーマを変えたか）も明確になります。
具体策：PowerShell（Az.CosmosDB）でインデックスとコレクションをコード化する
PowerShell でも MongoDB コレクション作成時にインデックスを渡せる仕組みが用意されています。New-AzCosmosDBMongoDBIndexでインデックスオブジェクトを作り、New-AzCosmosDBMongoDBCollection の -Index に渡す流れです。
$ttlInSeconds = 604800
$index1 = New-AzCosmosDBMongoDBIndex -Key @("partitionkey1", "partitionkey2") -Unique 1
$index2 = New-AzCosmosDBMongoDBIndex -Key @("_ts") -TtlInSeconds $ttlInSeconds
New-AzCosmosDBMongoDBCollection `
-ResourceGroupName "<rg>" `
-AccountName "<account>" `
-DatabaseName "<db>" `
-Name "<collection>" `
-Shard "<shardKey>" `
-Index $index1,$index2PowerShell運用のメリットは、Azureの他リソースと合わせてスクリプトで一貫管理しやすい点です。CI/CDでサービスプリンシパルを使って実行する場合も、権限はコントロールプレーン側（Azure RBAC）で管理できます。
具体策：Bicep/ARM/Terraformで「コレクション＋インデックス」を宣言的に管理する
IaCで管理したい場合、MongoDBコレクションのリソースにはindexesを含めて宣言できるAPIがあります。テンプレート参照でも、MongoDBコレクションのリソースにインデックス配列（キーとオプション）を持てることが示されています。
IaCに寄せると、次のような運用改善が狙えます。
- 変更履歴がGitに残る（いつ誰がインデックスを追加したか追える）
- 環境差分が減る（開発・検証・本番で同じ定義を適用しやすい）
- ロール設計が明確になる（デプロイ用のContributorと、アプリ用の最小権限を分けやすい）
「SDKで作れるはず」なのに403になるときの典型パターン
Microsoft Learn の「Create a collection in Azure Cosmos DB for MongoDB」では、MongoDBドライバで customAction: "CreateCollection" を実行してコレクションを作る例が載っています。ただし、ここで使っている認証方式がAzure AD（Entra ID）トークンの場合、前述の制限に当たりやすく、403（5300）になることがあります。
つまり、同じ「SDKで作成」という言葉でも、
- どの認証（キー／ユーザー／Entra ID）で
- どの経路（データプレーン／コントロールプレーン）で
実行しているかで結果が変わります。この違いを曖昧にしたままだと「権限を足したのに直らない」という状態に陥りがちです。
それでもキー（アカウントキー）を使うべきケースと、セキュリティの落としどころ
理想は「管理操作もアプリから実行したい」「起動時にマイグレーションしたい」ですが、Cosmos DB for MongoDB API のAzure AD認証には制限があるため、どうしてもアプリ起動時にスキーマ操作が必要なら、現実的には次の選択肢になります。
- アカウントキーで別経路を用意する（マイグレーション専用ジョブ・一時的な管理ツールなど）
- アプリ本体からの実行はやめ、デプロイ時にIaC/CLI/PowerShellで反映する（推奨）
キーを使う場合の最低限のルールは次のとおりです。
- キーはコードやリポジトリに直書きしない（Key Vaultなどで保管し、参照権限も最小化）
- キーを使う処理は「アプリ本体」と分離し、実行者・実行タイミングを限定する
- 定期的なキーのローテーション手順を最初から用意する（事故対応の速度が変わる）
補足：RBACという言葉が指すものが2種類ある（混乱ポイント）
Cosmos DB for MongoDB では「RBAC」という単語が出てきますが、文脈によって指している仕組みが違います。
| 仕組み | どこで設定する？ | 何を守る？ | 今回の403（5300）との関係 |
|---|---|---|---|
| Azure RBAC（Contributorなど） | Azure portal / ARM | アカウント・DB・コレクションなどリソース管理 | CLI/PowerShell/IaCでの管理には効くが、MongoDB経由の操作は別経路 |
| MongoDB側のRBAC（ユーザー/ロール） | CLI/PowerShell等でユーザー/ロール定義 | find/insert/update/createIndex 等のMongoDBコマンド権限 | 制限事項がある（例：listCollections等が除外） |
また、MongoDB側RBACには「一部コマンドがRBAC対象外」などの制限が明記されています。問題切り分けの際は、いま見ているのがAzure RBACの話なのか、MongoDB側RBACの話なのか、Azure ADトークンの話なのかをまず揃えるのが近道です。
403（5300）を最短で切り分けるチェック表
| 症状 | 可能性が高い原因 | 確認ポイント | 対処 |
|---|---|---|---|
| CRUDは成功、作成系だけ403（5300） | Azure ADトークンで非データ操作がブロック | createCollection/createIndexなどの管理系コマンドを実行していないか | 管理操作をPortal/CLI/PowerShell/IaCへ移す |
| すべての操作が403 | そもそもRBAC未設定、スコープ不一致、ネットワーク制限 | 割り当てスコープ、利用テナント、ネットワーク（IP/Private Link） | RBAC/ネットワークの基本設定を見直す |
| listCollections等の一部コマンドだけ失敗 | MongoDB RBACの既知制限 | FAQにある除外コマンドに該当していないか | 設計を変える（別手段でメタ情報取得） |
公式リファレンス（一次情報）
本件の説明や、実装に使える公式ドキュメントは以下です（URLはコピーしやすいようにコード形式で掲載します）。
Microsoft Q&A（MongoDB API + Azure AD認証で管理操作が403/5300になる話）
https://learn.microsoft.com/en-us/answers/questions/5542949/why-are-management-operations-(collection-index-cr)
Azure Resource Manager：コントロールプレーンとデータプレーンの違い
https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/control-plane-and-data-plane
Microsoft Learn：MongoDBコレクション作成（Portal/CLI/PowerShell/SDKなど）
https://learn.microsoft.com/en-us/azure/cosmos-db/mongodb/how-to-create-container
Azure CLI：az cosmosdb mongodb collection create（--idxでインデックス指定）
https://learn.microsoft.com/en-us/cli/azure/cosmosdb/mongodb/collection?view=azure-cli-latest
PowerShell：New-AzCosmosDBMongoDBCollection（-Indexあり）
https://learn.microsoft.com/en-us/powershell/module/az.cosmosdb/new-azcosmosdbmongodbcollection
PowerShell：New-AzCosmosDBMongoDBIndex
https://learn.microsoft.com/en-us/powershell/module/az.cosmosdb/new-azcosmosdbmongodbindex
テンプレート参照：MongoDBコレクション（indexesプロパティ）
https://learn.microsoft.com/en-us/azure/templates/microsoft.documentdb/databaseaccounts/mongodbdatabases/collections
MongoDB（RU）FAQ：RBACの制限事項
https://learn.microsoft.com/en-us/azure/cosmos-db/mongodb/faqまとめ
- 403 Forbidden（Substatus: 5300）でコレクション／インデックス作成が失敗するのは、Cosmos DB for MongoDB APIにおけるAzure AD（Microsoft Entra ID）認証の既知の制限として整理されます。
- Azure RBAC（Contributor等）を付与していても、MongoDB経由の管理系コマンドはAzure ADトークンでは通らないことがあります。
- 回避策は「キーを使う」だけではなく、Portal/CLI/PowerShell/IaCに管理操作を寄せることで、Azure ADのまま管理を完結できるケースが多いです。
- 運用では、アプリはデータ操作に専念し、スキーマ・インフラ管理はデプロイ工程に分離するのが最も安全で再現性も高いです。
コメント