Azure Cosmos DB Data Explorerでデータベース一覧が読み込めない、エラー調査で何を見ればよいのか分からない――そんな管理者・開発者に関係する更新です。
2026年5月21日時点で確認された「Azure Cosmos DB documentation update: Adding temporary console logging to track down issue」は、Azure Cosmos DB本体のデータベース仕様変更ではなく、Cosmos Explorer / Data Explorer側に不具合調査用の一時的なconsole.logを追加する変更です。結論から言うと、通常のアプリケーションコード、データベース、コンテナー、RU/s、インデックス設定の移行作業は不要です。ただし、Data Explorerの読み込み不具合を調査している場合は、ブラウザコンソール、Microsoft Entra ID RBAC、Azure Monitorの診断ログ、サポートへ共有するログのマスキングを確認しておくべきです。PR #2492は「Adding temporary console logging to track down issue」として、release/build2026ブランチへ2026年5月20日にマージされています。(GitHub)
まず結論：Azure Cosmos DB本体ではなくData Explorer側の調査用変更
今回の変更は、Azure Cosmos DBのデータ保存方式、API互換性、課金、スループット、SDKの利用方法を変えるものではありません。変更の中心は、Azure Cosmos DB Data Explorerでデータベースやコレクションを読み込む処理に、一時的なコンソールログを追加することです。
Microsoft Learnでは、Azure Cosmos DB Data ExplorerはAzure Cosmos DBに保存されたデータを表示・管理するWebベースのインターフェイスとして説明されています。専用のData Explorerは、Azure portal内のData Explorer体験とは別に全画面で使える管理UIとしても利用できます。(Microsoft Learn)
そのため、実務上の判断は次のようになります。
| 観点 | 判断 |
|---|---|
| Cosmos DBアカウントの設定変更 | 基本的に不要 |
| アプリケーションのSDK更新 | 不要 |
| データ移行・スキーマ変更 | 不要 |
| Data Explorerでの障害調査 | 影響あり。ブラウザコンソールの確認が有効 |
| サポート問い合わせ | {{cdbp}}を含むログが調査材料になる可能性あり |
| 自社でCosmos Explorerをフォークしている場合 | 一時ログとlint設定の扱いに注意 |
何が変わったのか
PR #2492では、Data Explorerの読み込み処理に関係する複数のファイルへconsole.logが追加されています。対象はエラーハンドリング、データベース一覧取得、リソースツリー更新、SQL API向けARM要求などです。GitHub上の変更では、.eslintrc.js、ErrorHandlingUtils.ts、readDatabases.ts、Explorer.tsx、sqlResources.tsが変更対象として表示されています。(GitHub)
| 変更箇所 | 追加・変更された内容 | 実務上の意味 |
|---|---|---|
.eslintrc.js | no-consoleルールを一時的に外す変更 | 調査用にconsole.logを許可するための対応。恒久的な運用ルール変更とは見なさない方が安全 |
ErrorHandlingUtils.ts | handleError()でraw errorをコンソール出力 | UI上のエラー表示やテレメトリに加工される前のエラーを確認しやすくなる |
readDatabases.ts | データベース一覧取得の分岐やARM/SDK呼び出し前後をログ出力 | 「DB一覧が取れない」問題で、どの取得経路に入ったかを追いやすくなる |
Explorer.tsx | refreshAllDatabases()やrefreshAndExpandNewDatabases()の進行状況をログ出力 | データベースツリーの更新、差分検出、コレクション読み込みのどこで止まったかを見やすくなる |
sqlResources.ts | listSqlDatabases()のARM要求前後とエラーをログ出力 | API for NoSQL、コード上のSQL API系アカウントでARM経由の一覧取得問題を切り分けやすくなる |
重要なのは、今回のログがData Explorer側の調査補助である点です。Azure Cosmos DBサービス側の監査ログやアプリケーションの分散トレースを置き換えるものではありません。
影響を受けやすい利用者
今回の更新で特に確認したいのは、Azure Cosmos DBを日常的にData Explorerで管理している人です。たとえば、次のようなケースでは影響を理解しておく価値があります。
- Azure portalまたは専用Data Explorerでデータベース一覧が表示されない
- コンテナーやアイテムのツリー表示が途中で止まる
- Microsoft Entra ID RBACでData Explorerを使っている
- キーベース認証を無効化している、または無効化を検討している
- Data Explorerの不具合をMicrosoftサポートへ問い合わせる予定がある
- 自社で
Azure/cosmos-explorerをフォーク、検証、ビルドしている
Data Explorer自体は、Microsoft Learn上でNoSQL、MongoDB、Apache Cassandra、Apache Gremlin、Tableに適用される管理UIとして説明されています。(Microsoft Learn) ただし、今回のPRで追加されたログはすべてのAPIで同じ意味を持つわけではありません。コード上では、AAD認証、SDK操作の有効・無効、Tables APIではないこと、Fabric系コンテキストかどうかなどの条件で処理経路が分かれます。(GitHub)
影響しないもの：データ移行や設定変更は基本不要
今回の「Adding temporary console logging to track down issue」は、Azure Cosmos DBの運用担当者にとって大きな移行案件ではありません。次の項目は、通常は変更不要です。
| 項目 | 対応要否 | 理由 |
|---|---|---|
| データベース・コンテナーの再作成 | 不要 | データ構造を変更する更新ではない |
| パーティションキー設計の見直し | 不要 | 調査ログ追加であり、パーティション仕様の変更ではない |
| RU/sやAutoscale設定の変更 | 不要 | スループット制御に関する更新ではない |
| アプリケーション接続文字列の変更 | 不要 | アプリ側の接続方式変更ではない |
| SDKバージョンの強制更新 | 不要 | SDKリリースではなくData Explorer側のPR |
| Azure Monitor診断設定の置き換え | 不要 | ブラウザコンソールログとAzure Monitorログは用途が異なる |
一方で、Data Explorerで障害調査をしている場合は、従来よりもブラウザの開発者ツールに多くの情報が出る可能性があります。ログの量が増えること自体は大きな問題ではありませんが、スクリーンショットやログ全文を共有するときは、アカウント名、リソースID、エンドポイント、エラー本文、レスポンス内容を確認してから送るべきです。
管理者が確認すべき設定
Microsoft Entra ID RBACの利用有無を確認する
今回のログ追加では、AAD認証時のデータベース一覧取得経路が重要な確認ポイントになります。Data ExplorerにはEnable Entra ID (RBAC)の設定があり、Microsoft Learnでは「自動」「True」「False」の動作が説明されています。Trueではデータ要求にRBACが常に使われ、RBACが正しく構成されていない場合は要求が失敗します。Falseではキーベース認証が使われ、キー認証が無効な場合は失敗します。(Microsoft Learn)
管理者は、Data Explorerで読み込みエラーが出ているユーザーについて、次の3点を確認してください。
| 確認項目 | 見るべきポイント |
|---|---|
| Data ExplorerのRBAC設定 | Enable Entra ID (RBAC)が自動、True、Falseのどれか |
| キーベース認証 | 組織ポリシーやアカウント設定で無効化していないか |
| ロール割り当て | 対象ユーザーにデータプレーン権限と必要なコントロールプレーン権限があるか |
Azure Cosmos DBのMicrosoft Entra ID接続では、コントロールプレーンアクセスとデータプレーンアクセスを分けて考える必要があります。Microsoft Learnでは、コントロールプレーンアクセスはアカウントやリソースメタデータの読み取り、キーや接続文字列の管理、バックアップ、データベースやコンテナーの管理などに関係すると説明されています。(Microsoft Learn)
データプレーンRBACのスコープを確認する
Azure Cosmos DB for NoSQLのネイティブRBACでは、データプレーン固有のロール定義とスコープを使います。Microsoft Learnでは、Azure Cosmos DB for NoSQLに独自のデータアクションとロールがあり、通常のAzure RBACロール定義とは別物であると説明されています。(Microsoft Learn)
Data Explorerで「アカウントには入れるがデータベースやコンテナーが見えない」という場合は、Azure portalのIAMだけで判断しないことが重要です。次のように切り分けます。
| 症状 | 疑うべき原因 |
|---|---|
| アカウント自体は選択できるがDB一覧が出ない | データプレーンRBAC、キー無効化、Data ExplorerのRBAC設定 |
| 特定コンテナーだけ見えない | RBACスコープが特定DBまたは特定コンテナーに限定されている |
| 管理操作はできるがアイテムが読めない | コントロールプレーン権限はあるがデータプレーン権限が不足 |
| 以前は見えていたが急に見えない | ロール割り当て変更、キー無効化、ブラウザキャッシュ、Data Explorer側更新の影響 |
診断ログは「別系統の証拠」として残す
ブラウザコンソールのconsole.logは、Data Explorerのクライアント側で何が起きたかを見るための手がかりです。一方、Azure Cosmos DB側で実際にどのリクエストが処理されたか、失敗したか、どのステータスコードだったかを追うにはAzure Monitorのログが必要です。
Azure Cosmos DBでは、Azure Monitor Logsで診断ログを監視し、Log AnalyticsでKustoクエリを実行できます。Microsoft Learnでは、診断ログをAzure Monitor Logsにルーティングし、データプレーンログやコントロールプレーンログを分析できると説明されています。(Microsoft Learn)
Data Explorerの読み込み不具合を調査する場合は、少なくとも次のクエリで同時刻の失敗を確認します。
CDBControlPlaneRequests
| where TimeGenerated > ago(2h)
| where AccountName == "<account-name>"
| project TimeGenerated, AccountName, OperationName, ActivityId, ApiKind, ApiKindResourceType, DurationMs
| order by TimeGenerated descCDBDataPlaneRequests
| where TimeGenerated > ago(2h)
| where AccountName == "<account-name>"
| project TimeGenerated, AccountName, DatabaseName, CollectionName, OperationName, StatusCode, ActivityId, RequestCharge, DurationMs
| order by TimeGenerated descCDBControlPlaneRequestsはアカウント上のコントロールプレーン操作を記録するテーブルで、IAMロール割り当て、VNet、ファイアウォール、プライベートリンク、アカウント更新などの操作も対象に含まれます。CDBDataPlaneRequestsはデータの作成、更新、削除、取得などのデータプレーン操作を記録します。(Microsoft Learn)
開発者が確認すべきポイント
ブラウザコンソールで{{cdbp}}をフィルターする
今回追加されたログには、{{cdbp}}という識別しやすい文字列が含まれています。Data Explorerでデータベースツリーが表示されない場合は、ブラウザの開発者ツールを開き、Consoleタブでcdbpを検索すると、追加された調査ログを追いやすくなります。PRの変更では、readDatabases()、readDatabasesWithARM()、refreshAllDatabases()、refreshAndExpandNewDatabases()、listSqlDatabases()などにログが追加されています。(GitHub)
確認の流れは次の通りです。
| 手順 | 操作 | 判断ポイント |
|---|---|---|
| 1 | Azure portalまたは専用Data Explorerを開く | 対象アカウントを選択できるか |
| 2 | ブラウザの開発者ツールを開く | ConsoleとNetworkを表示 |
| 3 | Consoleでcdbpを検索 | どの関数まで進んだか確認 |
| 4 | データベースツリーを更新 | readDatabases後に止まるか、loadCollectionsで止まるか確認 |
| 5 | Networkで失敗リクエストを確認 | 401、403、404、429、5xxなどを切り分け |
| 6 | Log Analyticsと照合 | Azure側に到達した要求か、ブラウザ側で止まったか確認 |
特に、calling readDatabasesWithARMが出ている場合はARM経由の一覧取得、calling SDKが出ている場合はSDK経由のデータベース一覧取得に入っていると考えられます。これにより、RBAC、キー認証、API種別、Fabric関連コンテキストなどの切り分けがしやすくなります。
raw errorやレスポンス内容の共有に注意する
ErrorHandlingUtils.tsでは、handleError()内でraw errorをJSON.stringify(error)して出力するログが追加されています。さらに、readDatabasesWithARM()ではARMレスポンスやエラーを出力するログも追加されています。(GitHub)
これは障害調査には有効ですが、ログ共有時には注意が必要です。サポートや社内チャットに貼る前に、次の情報が含まれていないか確認してください。
| マスク対象 | 理由 |
|---|---|
| AzureサブスクリプションID | リソース特定につながる |
| リソースグループ名 | 環境名や顧客名が含まれることがある |
| Cosmos DBアカウント名 | エンドポイント推測につながる |
| データベース名・コンテナー名 | 業務情報を含むことがある |
| エラー本文 | トークン、パス、内部識別子が含まれる場合がある |
| レスポンス全文 | リソース構成やメタデータが含まれる可能性がある |
スクリーンショットで共有するより、必要なログ行だけを抜き出し、識別情報を置換して共有する方が安全です。例として、accountNameは<account-name>、サブスクリプションIDは<subscription-id>、リソースIDは<resource-id>のように置き換えます。
自社フォークではno-consoleの一時解除を戻す
PRでは.eslintrc.jsのno-consoleルールが一時的にコメントアウトされています。これは調査用ログを入れるための対応であり、一般的なプロダクションコードの方針として恒久的に維持すべきものではありません。GitHub上の差分でも、no-consoleルールが//CTODO temp removing thisとしてコメントアウトされています。(GitHub)
自社でCosmos Explorerをフォークしている、または同様の管理UIを開発している場合は、次を確認してください。
| 確認項目 | 推奨対応 |
|---|---|
| 一時ログの残存 | 原因調査後に削除または正式なロガーへ置換 |
| lintルール | no-consoleを恒久的に無効化しない |
| テスト | Console出力を失敗扱いするE2Eテストがないか確認 |
| ログポリシー | PIIやシークレットが出ないルールを明文化 |
| サポート手順 | 取得すべきログ行とマスク方法を定義 |
「Data Explorerが開かない」ときの切り分け手順
今回の更新を踏まえると、Data Explorerの障害調査は「ブラウザ」「Data Explorerの認証設定」「Azure側ログ」の3層で見るのが効率的です。
| 層 | 確認するもの | 代表的な原因 |
|---|---|---|
| ブラウザ | Console、Network、Cookie、ポップアップ許可 | キャッシュ、CORS、ポップアップブロック、拡張機能 |
| Data Explorer | RBAC設定、選択中アカウント、API種別 | Entra ID RBAC不備、キー無効化、APIごとの処理差 |
| Azure側 | Log Analytics、Activity Log、診断設定 | 権限不足、ファイアウォール、Private Link、リージョン障害、429 |
Data ExplorerのMicrosoft Entra ID RBAC設定では、自動サインイン時にポップアップが開く場合があり、失敗時はData Explorerのポップアップを許可する必要があるとMicrosoft Learnに記載されています。(Microsoft Learn) ブラウザ側でポップアップを完全にブロックしている場合、Azure側のロール設定が正しくてもData Explorerの操作が進まないことがあります。
実務では、次の順番で見ると無駄が少なくなります。
- 別ブラウザまたはシークレットウィンドウで再現するか確認する
- Consoleで
{{cdbp}}を検索する - Networkで失敗しているHTTPステータスを確認する
- Data Explorerの
Enable Entra ID (RBAC)設定を確認する - 対象ユーザーのコントロールプレーン権限とデータプレーン権限を確認する
- Log Analyticsで同時刻の
CDBControlPlaneRequestsとCDBDataPlaneRequestsを確認する - ログをマスクしてサポートへ共有する
移行・展開で注意すべきこと
今回の変更は大規模な移行を必要としませんが、展開や運用フローでは注意点があります。
本番環境への影響は「機能変更」より「調査ログ増加」
Data Explorerを使うエンドユーザーにとって、見た目のUIが大きく変わる更新ではありません。主な変化は、ブラウザ開発者ツールに追加ログが出ることです。通常の利用者には見えにくい変更ですが、社内のセキュリティレビューやサポート手順では、ログに何が出るかを把握しておく価値があります。
プレビューリンクは検証用として扱う
PRページには「Preview this branch」リンクが表示されています。これは対象ブランチを検証するための導線であり、Azure Cosmos DB本番サービスのリリース完了を示すものではありません。(GitHub)
社内展開の判断では、プレビューリンクの表示だけでなく、実際に利用しているAzure portalまたは専用Data Explorer上で再現確認を行ってください。特に、権限やネットワーク制約がある環境では、プレビューURLにアクセスできるかどうかと本番Data Explorerの挙動は別問題として扱うべきです。
監視設計ではAzure Monitorを主軸にする
今回のconsole.logは、あくまで一時的な不具合調査の補助です。恒久的な監視、監査、障害検知にはAzure Monitor、診断設定、Log Analytics、Application Insights、OpenTelemetryなどを使うべきです。
Azure Cosmos DB SDKでは、.NET SDKとJava SDKで分散トレースをサポートし、OpenTelemetryやApplication Insights SDK、Azure Monitor OpenTelemetry Distroを使ってリクエストフロー、レイテンシ、診断情報を収集できます。Microsoft Learnでは、失敗したリクエストや高レイテンシのリクエストについて診断ログを取得できると説明されています。(Microsoft Learn)
Data Explorerの問題とアプリケーション本体の問題を混同しないためにも、次のように役割を分けるとよいでしょう。
| ログ・監視 | 主な用途 |
|---|---|
ブラウザConsoleの{{cdbp}}ログ | Data Explorer UI側の読み込み経路の切り分け |
| Networkタブ | ブラウザからの要求失敗、CORS、認証、HTTPステータス確認 |
| Azure Monitor Logs | Cosmos DBアカウント側に到達した要求や操作の確認 |
| SDK診断・OpenTelemetry | アプリケーションからのCosmos DBアクセスの性能・障害分析 |
| Activity Log | Azureリソース操作の外部視点での確認 |
よくある誤解
「Azure Cosmos DBの仕様が変わった」という意味ではない
今回の変更は、Azure Cosmos DBのクエリ仕様、整合性レベル、パーティションキー、インデックス、バックアップ、リージョン構成を変えるものではありません。Data Explorer側で問題の原因を探るために、どの処理を通ったかを見えるようにした変更です。
「診断ログを有効にしなくても全部分かる」という意味ではない
ブラウザコンソールに出るのは、Data Explorerクライアント側の情報です。Cosmos DBサービス側の実リクエスト、ステータスコード、RU消費、Activity ID、コントロールプレーン操作を追うには、Azure Monitor Logsの診断ログが必要です。Azure Cosmos DBの監視データリファレンスでは、ControlPlaneRequests、DataPlaneRequests、MongoRequests、GremlinRequests、QueryRuntimeStatisticsなど複数のリソースログカテゴリが整理されています。(Microsoft Learn)
「ログが出るから安全にそのまま共有してよい」という意味ではない
raw errorやレスポンスを含むログは、調査には便利ですが、情報漏えいリスクもあります。サポートへ共有する場合でも、アカウント名、リソースID、データベース名、コンテナー名、エラー詳細、レスポンス内容は必ず確認してから送付してください。
実務での対応チェックリスト
最後に、管理者・開発者がすぐ確認できるチェックリストを整理します。
| 対象者 | 確認すること | 対応 |
|---|---|---|
| Azure管理者 | Data Explorerで対象アカウントを開けるか | 再現するユーザー、ブラウザ、時刻を記録 |
| Azure管理者 | Entra ID RBAC設定 | 自動、True、Falseのどれで動いているか確認 |
| Azure管理者 | キーベース認証の状態 | 無効化している場合はRBAC権限を重点確認 |
| 開発者 | Consoleの{{cdbp}}ログ | どの処理で止まったかを記録 |
| 開発者 | NetworkのHTTPステータス | 401/403/429/5xxなどを切り分け |
| 運用担当 | Log Analyticsの診断ログ | 同時刻の操作と失敗を確認 |
| セキュリティ担当 | 共有ログの内容 | リソースID、アカウント名、エラー本文をマスク |
| フォーク利用者 | no-console一時解除 | 調査後にlintルールを戻す |
今回のAzure Cosmos DB documentation updateは、サービス仕様の大きな変更ではなく、Data Explorerの問題調査を進めるための一時的な可視化強化です。まずは移行作業が不要であることを押さえたうえで、Data Explorerの読み込み不具合がある環境では、{{cdbp}}ログ、RBAC設定、Azure Monitorログをセットで確認してください。これにより、「ブラウザ側で止まっているのか」「認証・権限で失敗しているのか」「Cosmos DB側に要求が届いているのか」を短時間で切り分けられます。
コメント