Azure Cosmos DBの開発で「NoSQLクエリの書き方を毎回調べる」「ポータルとVS Codeを行き来して作業が途切れる」と感じているなら、今回のAI Assistantプレビューは確認する価値があります。2026年6月3日に確認された公式更新では、Azure Cosmos DB extension for Visual Studio CodeにAI支援機能が追加され、自然言語からのクエリ生成、GitHub Copilot Chat上の@cosmosdbコマンド、スキーマを意識した入力補完を使えるようになります。(マイクロソフト Azure)
ただし、これは本番運用を自動化するための完成機能ではありません。Azure Updates上の「In preview」は、すべてのAzure顧客が非本番用途のテスト目的で利用できる段階と説明されています。管理者は権限、データ持ち出し、GitHub Copilotの利用ポリシー、RU消費を確認し、開発者は生成されたクエリを必ずレビューしてから実行する必要があります。(マイクロソフト Azure)
Azure Cosmos DBのAI Assistantプレビューで何が変わるのか
今回の更新の中心は、Azure Cosmos DBをVS Code内で扱う作業にAI支援を組み込むことです。Microsoftの関連ブログでは、Azure Cosmos DB VS Code ExtensionのPre-release version 0.35.1でAI支援の生産性機能がPublic Previewとして発表されたと説明されています。(Microsoft for Developers)
従来は、Azure Cosmos DBのクエリを書くときに、ドキュメントを参照しながら構文を確認し、Azure Portalや別ツールで試行錯誤する流れになりがちでした。今回のAI Assistantでは、VS Code上でデータベースに接続したまま、自然言語で「欲しいデータ」を伝え、クエリ作成や説明、修正を支援してもらえるようになります。
| 変更点 | できるようになること | 実務での使いどころ |
|---|---|---|
| Natural Language to Query | 平易な英語の説明からAzure Cosmos DB NoSQLクエリを生成 | アドホック調査、検証用クエリ作成、新人の学習 |
| Chat Experience Assistant | VS CodeのGitHub Copilot Chatで@cosmosdbを使い、クエリ生成・説明・編集を依頼 | クエリレビュー、最適化案の確認、構文やベストプラクティスの質問 |
| Auto IntelliSense Query Experience | コンテナーのスキーマを踏まえた入力補完を表示 | フィールド名の打ち間違い削減、WHERE句やGROUP BY句の作成支援 |
| MCP連携を土台にした文脈理解 | AIツールがAzure Cosmos DBの文脈を扱いやすくなる | 将来的なエージェント連携やチーム内自動化の検証 |
重要なのは、AIが「正しい本番クエリを保証する」のではなく、開発者の下書き作成や確認作業を短縮する点です。Microsoftもベストプラクティスとして、生成されたクエリは本番データに対して実行する前にレビューし、パーティションキーとの整合性やインデックスのカバレッジを確認するよう案内しています。(Microsoft for Developers)
主な機能は3つ：クエリ生成、チャット、IntelliSense
自然言語からAzure Cosmos DB NoSQLクエリを生成できる
Natural Language to Queryでは、取得したいデータを英語で説明すると、Azure Cosmos DB向けのNoSQLクエリを生成できます。公式ブログでは、たとえば「過去7日間の失敗した配送で、合計金額が500ドルを超える注文を地域別に集計する」といった説明から、SELECT、WHERE、GROUP BYを含むクエリを生成する例が紹介されています。(Microsoft for Developers)
実務では、次のような場面で効果が出やすい機能です。
| 利用シーン | プロンプト例 | 確認すべき点 |
|---|---|---|
| 障害調査 | Find failed orders in the last 24 hours grouped by region. | 時刻フィールド、ステータス値、パーティションキー |
| 運用レポート | Show active users updated in the last 30 days and return only id and lastLogin. | SELECT *になっていないか、必要な列だけ取得しているか |
| データ確認 | Find documents where deviceStatus is offline and tenantId is "contoso". | テナントIDや顧客IDなど機密値をそのまま入力してよい運用か |
| 性能改善の下書き | Rewrite this query to avoid unnecessary cross-partition scans. | 実際にRU消費が下がるか、実行計画やメトリックで検証 |
現時点の公式説明では「plain English」とされているため、初期検証では英語プロンプトを使うのが無難です。日本語プロンプトが実務レベルで安定するかは、利用環境、Copilot側の挙動、対象スキーマによって検証してください。
@cosmosdbでGitHub Copilot Chatから質問できる
Chat Experience Assistantでは、VS CodeのGitHub Copilot Chatで@cosmosdbチャット参加者を呼び出し、Azure Cosmos DBに関する質問やクエリ操作を行えます。Microsoftの説明では、GitHub Copilotが有効であれば、チャットモードで@cosmosdbを使って自然言語でAzure Cosmos DBと対話できるとされています。(Microsoft for Developers)
利用できる主なコマンドは次のとおりです。
| コマンド | 目的 | 使い方の例 |
|---|---|---|
/generateQuery | 自然言語からCosmos DB NoSQLクエリを生成 | @cosmosdb /generateQuery find active users created today |
/explainQuery | 既存クエリの意味を説明 | @cosmosdb /explainQuery SELECT * FROM c WHERE c.status = "active" |
/editQuery | 既存クエリを会話形式で修正 | @cosmosdb /editQuery optimize this query by using tenantId |
/question | Cosmos DBの概念、構文、ベストプラクティスを質問 | @cosmosdb /question How can I reduce RU consumption? |
/help | 利用可能なコマンドや使い方を確認 | @cosmosdb /help |
特に便利なのは、既存クエリの説明と修正です。運用で引き継いだクエリや、過去に作成したクエリの意図が分からない場合、/explainQueryで読み解きの助けを得られます。ただし、説明が正しいかどうかは最終的に開発者が判断する必要があります。
スキーマを意識したAuto IntelliSenseが使える
Auto IntelliSense Query Experienceは、従来の静的な入力補完より踏み込んだ支援です。公式ブログでは、コンテナーのドキュメント構造を読み取り、フィールド名、ネストしたパス、データ型を提示し、クエリパターンに応じた候補を出すと説明されています。(Microsoft for Developers)
たとえば、SELECT c.まで入力したときに、一般的な構文候補ではなく、実際のコンテナーに存在するcustomerId、orderDate、deliveryStatus、totalのようなフィールドが候補として出るイメージです。フィールド名の打ち間違いを減らせるため、手戻りの多い調査クエリや、スキーマに慣れていないメンバーのオンボーディングで効果があります。
一方で、スキーマに似た名前のフィールドが多い場合や、同じコンテナーに複数種類のドキュメントを格納している場合は、候補をそのまま信用しすぎないことが重要です。補完はあくまで入力支援であり、データモデルの設計ミスやクエリ設計の問題を自動で解決するものではありません。
利用前に確認すべき前提条件
AI Assistantを試すには、通常のVS Code拡張機能を入れるだけでは足りない場合があります。Microsoftの関連ブログでは、Azure Cosmos DB extensionをインストールした後、VS Codeで「Switch to Pre-Release Version」を選び、Pre-release版に切り替える必要があると説明されています。(Microsoft for Developers)
また、Visual Studio Marketplaceの拡張機能ページでは、AI-Powered Query AssistanceはGitHub Copilotと統合され、自然言語でCosmos DB NoSQLクエリの作成、編集、理解を支援すると説明されています。利用にはGitHub Copilot拡張機能と有効なCopilotサブスクリプションが必要です。([Visual Studio Marketplace][4])
| 確認項目 | 内容 | 管理者・開発者の判断ポイント |
|---|---|---|
| VS Code | Azure Cosmos DB extensionを利用 | 組織でVS Code拡張機能の利用制限があるか確認 |
| 拡張機能の状態 | Pre-release版への切り替えが必要 | 本番端末へ一斉展開せず、検証端末から開始 |
| GitHub Copilot | Copilot拡張機能と有効なサブスクリプションが必要 | 組織のCopilot利用規約、監査、データ取り扱い方針を確認 |
| 対象API | Azure Cosmos DB for NoSQLが中心 | MongoDB APIなど別APIの業務では対象範囲を誤認しない |
| 接続先 | Cosmos DBアカウントへの接続が必要 | 開発・ステージング環境から始める |
| 権限 | クエリ実行やデータ参照の権限が必要 | 読み取り専用、コンテナー単位など最小権限で付与 |
特に注意したいのは、Visual Studio Marketplaceの既知の問題として、以前含まれていたMongoDB、PostgreSQL、Graph（Gremlin）、Table、Cassandraなどのサポートがこの拡張機能から削除されていると記載されている点です。Azure Cosmos DBという名前だけで全APIを対象にできると考えず、自社のワークロードがNoSQL API中心かを確認してください。([Visual Studio Marketplace][4])
管理者が見るべき影響範囲
本番環境ではなく、開発・検証環境から始める
Public Previewは、便利そうだからすぐ本番運用に組み込む機能ではありません。Azure Updates上のIn previewは非本番用途のテスト向けと説明されているため、まずは開発環境またはステージング環境で検証するのが基本です。(マイクロソフト Azure)
最初の検証では、次のように範囲を絞ると安全です。
| 検証段階 | 対象 | ゴール |
|---|---|---|
| 個人検証 | 1〜2名の開発者、サンプルデータ | 機能が使えるか、生成クエリの傾向を把握 |
| チーム検証 | 開発用Cosmos DBアカウント | 既存クエリと比較し、RU消費や精度を確認 |
| 運用ルール整備 | ステージング環境 | プロンプト入力ルール、レビュー手順、権限設定を文書化 |
| 限定展開 | 対象チームのみ | 開発効率、レビュー負荷、誤実行リスクを評価 |
いきなり全開発者に展開すると、生成されたクエリをそのまま実行する人、機密値をプロンプトに含める人、不要に広い権限で接続する人が出る可能性があります。AI機能そのものよりも、使い方のルール不備がリスクになります。
スキーマサンプリングとクエリ履歴の扱いを確認する
Microsoftの関連ブログでは、AI Assistantはスキーマサンプリングとクエリ履歴のコンテキストを活用し、接続時にコンテナーのスキーマをサンプリングして、生成・説明するクエリの品質を高めると説明されています。(Microsoft for Developers)
ここで管理者が確認すべきなのは、「どのデータやメタデータをAI支援に使ってよいか」です。実データそのものを丸ごと送るという意味に短絡する必要はありませんが、少なくともスキーマ情報、フィールド名、クエリ文、場合によっては業務上意味のある値がプロンプトやクエリに含まれる可能性は考えるべきです。
たとえば、以下のような運用ルールを決めておくと安全です。
| リスク | 避けるべき使い方 | 推奨ルール |
|---|---|---|
| 顧客情報の混入 | 顧客名、メールアドレス、電話番号を含む条件をそのまま入力 | IDをマスクし、検証用データで試す |
| 業務機密の露出 | 未公開プロダクト名や取引先名をフィールド値として入力 | 機密度の高い値はダミー値に置換 |
| 過剰な権限 | 本番アカウントキーで接続 | Entra IDとRBACを使い、読み取り専用から始める |
| 履歴の再利用 | 過去の危険なクエリを参考にしてしまう | クエリ履歴の扱いとレビュー基準を定める |
VS Codeや拡張機能のテレメトリも確認対象です。Visual Studio Marketplaceでは、VS Codeが利用データを収集してMicrosoftに送信する場合があり、無効化したい場合はtelemetry.enableTelemetryをfalseに設定できると説明されています。組織のセキュリティ基準に合わせ、VS Code本体、拡張機能、Copilotの設定をまとめて確認してください。([Visual Studio Marketplace][4])
RBACと最小権限を見直す
AI Assistantを使うからといって、開発者に広い権限を渡す必要はありません。むしろ、自然言語で簡単にクエリを生成できるようになる分、権限はより慎重に設計すべきです。
Microsoft Learnでは、Azure Cosmos DB for NoSQLでMicrosoft Entra IDとロールベースアクセス制御を使って接続する方法が説明されており、RBACは必要最小限のアクセス権を割り当てるための仕組みとされています。(Microsoft Learn)
特にデータプレーンの権限では、アカウント全体、データベース単位、コンテナー単位などのスコープを指定できます。Microsoft Learnでは、最も細かいスコープとして単一コンテナーへの割り当て例も示されています。(Microsoft Learn)
| 利用者 | 推奨権限の考え方 | 理由 |
|---|---|---|
| 新人・学習者 | サンプルDBまたは開発DBの読み取り中心 | 誤更新や本番データ閲覧を防ぐ |
| アプリ開発者 | 担当コンテナー単位の読み取り・必要最小限の書き込み | 調査対象を限定し、影響範囲を狭める |
| SRE・DB管理者 | ステージング、本番で権限を分離 | 本番調査と開発作業を混同しない |
| 外部委託メンバー | 期限付き、コンテナー単位、監査前提 | 契約範囲外のデータ閲覧を避ける |
アカウントキーや接続文字列を共有して使う運用は、誰が何を実行したか追いにくくなります。AI Assistantの検証を機に、Entra IDベースの接続とデータプレーンRBACを見直すとよいでしょう。
開発者向け：安全に使う基本手順
AI Assistantは、クエリ作成を速くする道具です。正確性、コスト、セキュリティの責任は引き続き開発者側にあります。最初は次の手順で試すと、失敗しにくくなります。
| 手順 | 作業 | 確認ポイント |
|---|---|---|
| 1 | VS CodeにAzure Cosmos DB extensionをインストール | 組織で許可された拡張機能か |
| 2 | Pre-release版に切り替える | 対象バージョンでAI支援が有効か |
| 3 | GitHub Copilot拡張機能を有効化 | 有効なCopilotサブスクリプションがあるか |
| 4 | 開発用Cosmos DBアカウントに接続 | 本番アカウントではないか |
| 5 | Query Editorで自然言語からクエリ生成 | 生成結果を実行前に読む |
| 6 | @cosmosdb /explainQueryで説明を確認 | 意図と異なる条件が入っていないか |
| 7 | 実行後にRU消費と結果件数を確認 | 想定より高コストなクエリになっていないか |
| 8 | チームのクエリレビュー基準に反映 | 便利だったプロンプトと失敗例を共有 |
Microsoftは、実際のデータベースに接続するとAI機能がスキーマ文脈を使いやすくなる一方、本番データに対して実行する前に生成クエリを検証するよう案内しています。まずは開発環境やステージング環境に接続し、生成結果の癖を把握するのが現実的です。(Microsoft for Developers)
生成クエリをレビューするときのチェックポイント
AI Assistantで作ったクエリは、見た目が自然でも、そのまま本番向きとは限りません。特にAzure Cosmos DBでは、クエリの書き方がRU消費やレイテンシに直結します。
| チェック項目 | 悪い例 | 良い例 |
|---|---|---|
| 取得列 | SELECT * FROM cを多用 | 必要なフィールドだけSELECT c.id, c.statusで取得 |
| パーティションキー | テナントIDやユーザーIDを条件に含めない | パーティションキーに沿ったWHERE条件を入れる |
| 件数制御 | 全件を一度に取得 | TOPやページング前提で取得 |
| 集計 | 大量データに対して無条件にGROUP BY | 期間、テナント、ステータスなどで絞り込む |
| 並べ替え | 広範囲のクロスパーティションでORDER BY | インデックスやパーティション設計を確認 |
| 日付条件 | 文字列比較で曖昧に判定 | 保存形式とタイムゾーンを確認して条件を書く |
| 機密情報 | 実顧客の値をプロンプトに含める | ダミー値や抽象化した条件で相談 |
公式ブログでも、生成されたクエリについて、パーティションキーの整合性とインデックスのカバレッジを確認すること、RUコストやインデックスのトレードオフ、パーティション戦略の理解にチャットを活用することが推奨されています。(Microsoft for Developers)
実行前レビューでは、次の3つを習慣にしてください。
まず、条件が業務要件と一致しているかを確認します。「過去30日」と指示したのに、日付フィールドが別名だったり、UTC前提でずれていたりすることがあります。
次に、パーティションキーを使えているかを確認します。Azure Cosmos DBでは、パーティション設計に合わないクエリが広範囲をスキャンし、想定以上のRUを消費することがあります。
最後に、結果件数と取得列を絞ります。調査目的なら最初は少ない件数で試し、必要な列だけ返すクエリにするほうが安全です。
導入で失敗しやすいポイント
AIが作ったクエリをそのまま本番で実行する
一番避けたいのは、生成されたクエリを確認せずに本番コンテナーで実行することです。自然言語から生成されたクエリは、下書きとしては便利ですが、データモデル、インデックス、パーティションキー、業務ルールまで完全に理解しているとは限りません。
特に、障害調査中は焦っているため、SELECT *や広範囲スキャンをそのまま実行しがちです。本番では、最初に対象期間、テナント、ステータス、件数を絞るルールを設けてください。
Copilotの利用条件を確認せずに展開する
Marketplaceでは、AI-Powered Query AssistanceにはGitHub Copilot拡張機能と有効なCopilotサブスクリプションが必要とされています。([Visual Studio Marketplace][4])
そのため、「VS Code拡張機能を入れたのにAI Assistantが使えない」という問い合わせが発生する可能性があります。管理者は、Copilotライセンスの有無、組織ポリシー、利用可能なユーザー範囲を先に整理しておくべきです。
対象APIを誤解する
Azure Cosmos DBには複数のAPIがありますが、今回のVS Code拡張機能の説明ではAzure Cosmos DB for NoSQLが中心です。Marketplaceにも、Azure Cosmos DB for NoSQLをサポートしてデータベースの閲覧、管理、クエリ実行ができると記載されています。([Visual Studio Marketplace][4])
MongoDB APIやPostgreSQL系の業務で同じ体験を期待すると、検証計画がずれます。自社のCosmos DB利用状況を棚卸しし、対象APIごとに検証可否を分けてください。
プロンプトに機密情報を入れすぎる
AIに正確なクエリを作らせようとして、顧客名、契約名、メールアドレス、注文番号などをそのまま入力するのは避けるべきです。検証段階では、tenantId = "sample-tenant"やcustomerType = "premium"のように、意味が分かる範囲でダミー化した値を使いましょう。
プロンプトの良し悪しは、精度だけでなく安全性にも影響します。チームで使うなら、「プロンプトに入れてよい情報」と「入れてはいけない情報」を明文化してください。
移行や展開で考えるべきこと
今回の更新は、データベース自体のスキーマ変更やアプリケーション移行を必須にするものではありません。影響が大きいのは、開発者の作業フローです。
従来の「ドキュメントを検索する」「Azure Portalで試す」「ローカルに貼り付ける」という流れから、「VS Code内で質問し、生成し、説明を受け、修正する」流れへ移っていきます。うまく使えば、オンボーディングや調査クエリの作成時間を短縮できます。
一方で、展開時には次の順序をおすすめします。
| フェーズ | やること | 完了条件 |
|---|---|---|
| 準備 | 対象チーム、対象DB、利用ルールを決める | 本番接続禁止、機密値入力禁止などの基本ルールがある |
| 検証 | 既存クエリをAI Assistantで再現する | 結果、RU消費、読みやすさを比較できている |
| 権限設計 | RBACスコープを見直す | 開発者ごとに必要最小限のアクセスになっている |
| 教育 | プロンプト例と失敗例を共有する | チームメンバーがレビュー観点を理解している |
| 限定展開 | 一部プロジェクトで実運用に近い使い方を試す | 問い合わせ、誤実行、コスト増の有無を確認できている |
| 標準化 | チームの開発ガイドに反映する | クエリレビュー、Copilot利用、ログ確認の手順が文書化されている |
Azure Cosmos DB extensionにはMigration Assistant機能も含まれると公式ブログで触れられていますが、今回のAI Assistantプレビューとは目的が異なります。移行評価に使う機能と、日々のクエリ作成を支援する機能を混同しないようにしましょう。(Microsoft for Developers)
どのようなチームに向いているか
AI Assistantの効果が出やすいのは、Azure Cosmos DBを使っているものの、チーム内でクエリ経験に差がある組織です。
| チームの状況 | 期待できる効果 |
|---|---|
| 新人や異動者がCosmos DBを学んでいる | クエリ構文や考え方をチャットで確認しやすい |
| 障害調査でアドホッククエリが多い | 下書き作成が速くなり、調査開始までの時間を短縮しやすい |
| プロダクトマネージャーからデータ確認依頼が多い | 要件を自然言語で整理し、開発者との認識合わせに使える |
| 複数チームが同じコンテナーを扱う | スキーマ補完によりフィールド名の誤りを減らしやすい |
| RUコストの高いクエリが散発する | /explainQueryや/questionで改善観点を学びやすい |
逆に、厳格な本番接続制限があり、開発端末からデータベースに直接接続しない運用のチームでは、導入効果よりもガバナンス調整の負荷が大きい可能性があります。その場合は、サンプルデータや検証用アカウントだけで使う範囲に限定するのが現実的です。
まず確認すべきアクションリスト
Azure Cosmos DBのAI Assistantプレビューを試すなら、次の順番で進めてください。
| 優先度 | アクション | 担当 |
|---|---|---|
| 高 | 利用対象がAzure Cosmos DB for NoSQLか確認する | 管理者・開発リーダー |
| 高 | GitHub Copilotの利用可否とライセンスを確認する | 管理者 |
| 高 | 開発・ステージング環境で検証用Cosmos DBアカウントを用意する | 管理者・SRE |
| 高 | RBACを使い、読み取り中心の最小権限を割り当てる | 管理者 |
| 中 | VS Code拡張機能をPre-release版に切り替えて動作確認する | 開発者 |
| 中 | 既存クエリを使って生成精度とRU消費を比較する | 開発者 |
| 中 | プロンプトに入れてよい情報、入れてはいけない情報を決める | 管理者・セキュリティ担当 |
| 低 | よく使うプロンプト例とレビュー観点をチームWikiにまとめる | 開発リーダー |
今回の更新は、Azure Cosmos DBの開発体験を「手作業で構文を調べる」ものから「VS Code内でAIに下書きと説明を任せる」方向へ進めるものです。まずは非本番環境で、既存の安全なクエリを題材に試してください。そのうえで、権限、プロンプト、RU確認、レビュー手順を整えれば、Azure Cosmos DBの調査・開発作業をより速く、安定して進めやすくなります。
[4]: https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-cosmosdb “
Azure Cosmos DB – Visual Studio Marketplace
“
コメント