Azure SQLやSQL Server系の業務アプリをAzure Cosmos DB for NoSQLへ移行したい場合、最大の難所は「データをコピーすること」よりも、リレーショナル前提のテーブル設計・JOIN・トランザクション・データアクセス層をNoSQL向けに再設計することです。
2026年6月3日に更新されたAzure Cosmos DBのVisual Studio Code拡張機能ドキュメントでは、Relational Database to Azure Cosmos DB NoSQL Migration Assistantがプレビュー機能として案内されています。結論から言うと、この機能はAzure SQL環境を自動的に置き換える移行ツールではありません。SQL Server、PostgreSQL、Oracle、MySQL、Db2などのRDBMSからAzure Cosmos DB for NoSQLへ移行する際に、スキーマ分析、アクセスパターン整理、コンテナー設計、パーティションキー候補、サンプルデータ、アプリケーションコード移行計画を支援する開発者向けのMigration Assistantです。(Microsoft Learn)
重要なのは、Public Previewである点です。Azure UpdatesではIn previewを「すべてのAzure顧客が非本番用途・テスト用途で利用できる段階」と説明しています。つまり、管理者や開発者はすぐに本番移行へ使うのではなく、PoC、設計検証、移行見積もり、コード改修範囲の把握に使うのが現実的です。(マイクロソフトアジュール)
[In preview] Relational Database to Azure Cosmos DB NoSQL Migration Assistantで何が変わるのか
今回の変更点は、リレーショナルデータベースからAzure Cosmos DB for NoSQLへ移行する際の検討作業を、Visual Studio Code上のガイド付きワークフローとして進められるようになったことです。
従来、Azure SQLやSQL Server系アプリをCosmos DBへ移す場合、チームは次のような作業を個別に行う必要がありました。
- テーブル、外部キー、インデックス、制約の棚卸し
- JOIN前提の読み取り処理を、ドキュメント指向のデータモデルへ変換
- コンテナー単位の設計
- パーティションキーの選定
- RU/sやクエリコストの見積もり
- アプリケーションのデータアクセス層の書き換え
- 移行後のサンプルデータ検証
Migration Assistantは、これらをDiscovery、Assessment、Schema Conversion、Provisioning、Application Code Migrationという段階に分けて支援します。公式ドキュメントでは、スキーマ、アプリケーションコード、アクセスパターンを評価し、パーティションキーやインデックスを含むCosmos DBコンテナー設計を生成し、ターゲット環境のプロビジョニングやサンプルデータ読み込み、コードリファクタリング支援までを1つの流れで扱うと説明されています。(Microsoft Learn)
ただし、これは「SQLをそのままNoSQLへ変換して終わり」という機能ではありません。NoSQL移行では、テーブル単位ではなく、アプリケーションが実際にどうデータを読むか、どの単位で更新するか、どのキーで高頻度にアクセスするかを基準に設計し直す必要があります。
Azure SQL管理者・開発者への影響範囲
Azure SQLの既存データベースに対して、今回のプレビューによる強制的な設定変更はありません。影響を受けるのは、Azure SQL Database、Azure SQL Managed Instance、SQL Server系ワークロードを将来的にAzure Cosmos DB for NoSQLへモダナイズしたいチームです。
| 対象者 | 影響 | まず確認すべきこと |
|---|---|---|
| Azure SQL管理者 | 既存RDBMSのスキーマ、データ量、読み書き負荷を移行検討用に整理する必要がある | DDL、テーブルサイズ、主要クエリ、ピーク時TPS、保持期間 |
| アプリ開発者 | ORMやSQLクエリ、Repository層、データアクセスコードの変更範囲を確認する必要がある | アプリのワークスペース、使用言語、フレームワーク、データアクセス方式 |
| クラウド管理者 | Cosmos DBアカウント、RBAC、ネットワーク、コスト管理の設計が必要になる | サブスクリプション権限、リソースグループ、Entra ID、ネットワーク制約 |
| アーキテクト | テーブル正規化前提の設計を、集約・アクセスパターン中心に見直す必要がある | パーティションキー候補、コンテナー分割、整合性要件 |
| セキュリティ担当 | GitHub CopilotやAI支援へ渡す情報の扱いを確認する必要がある | DDL、コード、サンプルデータ、機密情報の取り扱いルール |
特にAzure SQLの管理者は、「移行元DBをどう安全にエクスポートするか」だけでなく、「どの情報をMigration Assistantに入力してよいか」を事前に整理する必要があります。スキーマDDLやアプリケーションコードには、テーブル名、カラム名、業務ロジック、場合によっては機密性の高い命名規則が含まれるためです。
サポート範囲とできないこと
公式情報では、ソースデータベースとしてSQL Server、PostgreSQL、Oracle、MySQL、Db2が挙げられています。ターゲットはAzure Cosmos DB for NoSQLのみです。また、対象範囲にはスキーマ変換、データモデリング、サンプルデータ生成、アプリケーション移行計画が含まれます。(Microsoft for Developers)
一方で、最も注意すべき制限は「実際の本番データ移行はサポートしない」と明記されている点です。公式ドキュメントでは、Migration AssistantはDiscovery、Schema Conversion、Data Modeling、Provisioning、代表的なサンプルデータ変換、アプリケーションコード移行に焦点を当てており、actual production dataの移行は現在サポートしていないと説明されています。(Microsoft Learn)
| 項目 | 対応状況 | 実務上の見方 |
|---|---|---|
| RDBMSスキーマの分析 | 対応 | DDLを起点に移行候補を整理できる |
| アクセスパターンの整理 | 対応 | 読み取り・書き込み要件をNoSQL設計に反映しやすい |
| Cosmos DBコンテナー設計 | 対応 | パーティションキーやインデックス設計のたたき台になる |
| サンプルデータ生成・読み込み | 対応 | PoCや設計レビューに使える |
| アプリケーションコード移行計画 | 対応 | GitHub Copilotを使った改修計画の作成に役立つ |
| 本番データの一括移行 | 非対応 | 別途ETL、バッチ、カスタム移行処理、検証計画が必要 |
| 本番環境での即時利用 | 非推奨 | Public Previewのため非本番検証から始める |
この制限を誤解すると、「設計はできたが本番データをどう移すかが未定」という状態になります。移行プロジェクトでは、Migration Assistantで設計・コード改修範囲を把握し、その後にデータ移行方式、差分同期、停止時間、切り戻し手順を別途設計する流れが現実的です。
利用前に必要な前提条件
Migration Assistantを試すには、Visual Studio Code、Azure Cosmos DB拡張機能、GitHub Copilot、移行対象アプリケーションのワークスペース、データベーススキーマファイル、Azureサブスクリプション権限またはローカルのAzure Cosmos DB Emulatorが必要です。公式ドキュメントでは、拡張機能IDとしてms-azuretools.vscode-cosmosdbも示されています。(Microsoft Learn)
実務では、いきなり本番リポジトリや本番サブスクリプションで試すのではなく、次の準備をしてから開始してください。
| 準備項目 | 具体例 | 確認ポイント |
|---|---|---|
| スキーマDDL | CREATE TABLE、CREATE INDEX、制約定義 | 最新の本番スキーマと一致しているか |
| ボリューム情報 | 行数、平均行サイズ、読み取りTPS、書き込みTPS | ピーク時と通常時を分けているか |
| アクセスパターン | 顧客別注文一覧、商品検索、ステータス更新など | 実際のAPI・画面単位で整理しているか |
| アプリコード | Repository、DAO、ORM設定、SQLクエリ | 移行検証用ブランチで作業しているか |
| Azure権限 | Cosmos DBアカウント作成、DB・コンテナー作成、RBAC | 最小権限で検証できるか |
| AI利用ルール | GitHub Copilot利用可否、機密情報の扱い | 社内ポリシーに反していないか |
ボリューム情報とアクセスパターンは任意入力とされていますが、実務では非常に重要です。公式ドキュメントでも、ボリューム情報はRU/s見積もりやパーティションキー選定に役立ち、アクセスパターンはコンテナー設計やパーティション戦略に役立つと説明されています。(Microsoft Learn)
実務での移行検証の進め方
Migration Assistantは、Visual Studio CodeのコマンドパレットからAzure Cosmos DB: New Migration…を実行して開始します。既存プロジェクトを開くOpen Existing Migration…や、ワークスペースビューから削除するRemove Migrationも用意されています。(Microsoft Learn)
おすすめの進め方は、次の順番です。
| 手順 | 作業 | 判断ポイント |
| -: | ————————————– | ———————————— |
| 1 | 移行候補のAzure SQL/SQL Server系アプリを1つ選ぶ | いきなり基幹全体ではなく、境界が明確な業務領域を選ぶ |
| 2 | 検証用ブランチと検証用ワークスペースを作る | mainや本番ブランチで直接実行しない |
| 3 | DDL、ボリューム情報、アクセスパターンを用意する | テーブル一覧だけでなく、画面・API単位の読み書きを整理する |
| 4 | Discoveryを実行する | 言語、フレームワーク、ORM、DB種別の推定結果を確認する |
| 5 | Assessmentでドメイン分割を確認する | テーブル単位ではなく、業務上のまとまりになっているかを見る |
| 6 | Schema Conversionでコンテナー設計を確認する | パーティションキー、埋め込み、参照、インデックスをレビューする |
| 7 | Emulatorまたは検証用Cosmos DBへProvisioningする | まずローカルまたは検証用環境でサンプルデータを確認する |
| 8 | Plan Migrationを実行する | 生成されたcode-migration-plan.mdをレビューする |
| 9 | 問題がなければStart Migrationを検証ブランチで試す | 差分をレビューし、単体テスト・結合テストを実施する |
公式ドキュメントでは、Migration Assistantの成果物は.cosmosdb-migration/フォルダーに保存され、停止・再開・出力確認・ソース管理へのコミット・再実行ができると説明されています。これはチームレビューに向いています。生成された設計やコード移行計画をブラックボックスにせず、Pull Requestと同じようにレビュー対象にしてください。(Microsoft Learn)
Azure SQLからCosmos DBへ移すべきかの判断基準
Azure SQLからAzure Cosmos DB for NoSQLへの移行は、すべてのシステムに向くわけではありません。Cosmos DBは柔軟なJSONデータモデル、水平スケーリング、低レイテンシ、RUベースのスループットなどを持つ一方、リレーショナルDBのように正規化テーブルをJOINして使う前提とは設計思想が異なります。(Microsoft Learn)
| 判断軸 | Cosmos DB移行に向くケース | Azure SQL継続が向くケース |
|---|---|---|
| データアクセス | 顧客ID、テナントID、注文IDなど特定キーで高頻度に読む | 複雑なJOINやアドホックSQL分析が多い |
| スケール | グローバル分散、水平スケール、低レイテンシが重要 | 単一リージョン中心でRDBMSの性能改善で足りる |
| データモデル | 集約単位でJSONドキュメント化しやすい | 高度に正規化され、参照整合性が重要 |
| トランザクション | 同一パーティション内の操作が中心 | 複数テーブル・複数エンティティ横断のACID要件が強い |
| 開発速度 | スキーマ変更が多く、柔軟なデータ構造が必要 | 厳密なスキーマ管理とSQL資産を重視する |
| コスト管理 | RU、パーティション、クエリ設計を継続的に最適化できる | 既存のSQL運用・監視・チューニング体制を活かしたい |
「SQLが遅いからCosmos DBに移す」という判断は危険です。遅さの原因がインデックス不足、クエリ設計、ロック、過剰な正規化、アプリ側のN+1問題であれば、Azure SQL側の改善で解決する可能性があります。Cosmos DBへの移行は、単なる性能対策ではなく、アプリケーションのデータモデルを変えるプロジェクトとして扱うべきです。
パーティションキー設計で失敗しないための注意点
Azure Cosmos DB for NoSQL移行で最も重要な設計項目の1つがパーティションキーです。公式ドキュメントでは、パーティションキーはアプリケーションの性能に影響する重要な判断であり、選択後にその場で変更することはできないと説明されています。また、偏ったキーを選ぶと一部パーティションにリクエストが集中し、ホットパーティション、スループット効率低下、レート制限、コスト増につながる可能性があります。(Microsoft Learn)
実務では、次のように考えると判断しやすくなります。
| 候補 | 向いている例 | 注意点 |
|---|---|---|
tenantId | SaaSでテナント単位のアクセスが多い | 大口テナントだけ極端にデータ量が多い場合は偏りに注意 |
customerId | 顧客別注文一覧、顧客別履歴取得が多い | 顧客単位のデータが論理パーティション制限に収まるか確認 |
orderId | 注文単位のポイント読み取りが中心 | 顧客別一覧など別軸の検索が多いと横断クエリが増える |
tenantId + dateなどの合成キー | 書き込みが集中しやすいマルチテナント処理 | クエリ条件と合っていないと扱いにくくなる |
id | 小規模またはポイント読み取り中心 | 汎用ワークロードでは他プロパティ検索が横断クエリになりやすい |
パーティションキーは「値の種類が多い」だけでは不十分です。よく使うクエリ条件に含まれ、読み書き負荷とデータ量を均等に分散できる必要があります。公式ドキュメントでも、パーティションキーは高いカーディナリティを持ち、RU消費とストレージを論理パーティション間で均等に広げることが望ましいと説明されています。(Microsoft Learn)
RU/sとコストは早い段階で見積もる
Azure SQLからCosmos DBへ移行する場合、コストの考え方も変わります。Cosmos DBではRequest Unit、つまりRUがスループットと性能の単位になります。プロビジョニング済みスループット、サーバーレス、オートスケールといったモードがあり、プロビジョニング済みスループットではRU/sを割り当て、時間単位で課金されます。(Microsoft Learn)
RU消費には、アイテムサイズ、インデックス対象プロパティ、プロパティ数、クエリの複雑さなどが影響します。リレーショナルDBから移行するときは、テーブルを単純にJSON化するだけでは、ドキュメントが大きくなりすぎたり、不要なプロパティまでインデックスされて書き込みRUが増えたりすることがあります。
検証段階では、最低でも次を確認してください。
- 代表的な読み取りAPIのRU消費
- 書き込み・更新処理のRU消費
- 一覧検索やソートを伴うクエリのRU消費
- パーティションキーを条件に含む場合と含まない場合の差
- 既定インデックスで十分か、除外すべきプロパティがあるか
- ピーク時に必要なRU/sと通常時のRU/s
- オートスケールを使うべきか、固定RU/sでよいか
Migration Assistantが出す設計案は、あくまで移行設計のたたき台です。最終的なコスト判断には、実データに近いサンプル、代表クエリ、負荷試験、Azure Monitorによるメトリック確認が必要です。
管理者が確認すべき設定・権限・展開上の注意点
Provisioningフェーズでは、Azureへのサインイン、既存または新規のCosmos DBアカウントとデータベースの選択、生成モデルに基づくコンテナー作成、必要に応じたサンプルデータ生成・読み込み、接続テストを行います。ターゲット環境として、ローカルCosmos DB Emulator、既存Azure Cosmos DBアカウント、新規Cosmos DBアカウントが選択肢として示されています。(Microsoft Learn)
管理者は、次の点を事前に決めておくと検証がスムーズです。
| 項目 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| サブスクリプション | 検証用サブスクリプションを使うか | 本番サブスクリプションに検証リソースを作ってしまう |
| リソースグループ | PoC専用に分けるか | 削除対象が分からなくなる |
| RBAC | 管理プレーンとデータプレーンの権限を分けるか | 作成はできるがデータ読み書きができない |
| ネットワーク | Private Endpoint、Firewall、VNet制約の有無 | VS Codeから接続できない |
| 命名規則 | アカウント名、DB名、コンテナー名 | 後で本番命名に合わず作り直す |
| コスト | RU/s、リージョン数、バックアップ、ログ | PoC後にリソースを消し忘れる |
| 監査 | 誰が何を作成・変更したか | AI支援で生成された変更の責任範囲が曖昧になる |
Preview機能の検証では、削除しやすい単位で環境を作ることが大切です。Terraform、Bicep、Azure CLIなど既存のIaC運用がある場合でも、まずはMigration Assistantが生成する構成を確認し、組織標準の命名、タグ、診断設定、Private Endpoint、RBACへ落とし込めるかを見てください。
開発者が確認すべきコード移行の注意点
Application Code Migrationでは、Phases 1〜4の成果物をもとに、VS CodeのCopilot Chatで文脈付きの移行計画を生成できます。Plan Migrationではcode-migration-plan.mdを生成して停止し、Start Migrationでは計画生成後にコード変更の適用を開始します。公式ドキュメントでも、Start Migrationを選んだ場合はワークスペースに適用された変更をレビューし、ソース管理で管理・差し戻しできるようにすることが案内されています。(Microsoft Learn)
実務では、必ずPlan Migrationを先に使ってください。いきなりStart Migrationを実行すると、データアクセス層、SDK呼び出し、クエリ、設定ファイル、テストコードがまとめて変わる可能性があります。
確認すべきコード観点は次の通りです。
- SQLクエリがCosmos DBのクエリに置き換わっているか
- JOIN前提の処理が、ドキュメント取得または複数クエリに変わっているか
- パーティションキーを指定した読み取りになっているか
- 例外処理、リトライ、429レート制限への考慮があるか
- SDKの認証方式が組織標準に合っているか
- ローカル開発、CI、検証環境、本番環境の接続設定が分離されているか
- 既存テストが通るだけでなく、性能テストも追加されているか
特に、SQLのWHERE customer_id = ?のような条件が、Cosmos DBのパーティションキー設計と合っているかを確認してください。パーティションキーを含まない検索が多いと、横断クエリが増え、RU消費やレイテンシに影響します。
よくある誤解と避けるべき失敗
| 誤解 | 正しい理解 |
|---|---|
| Migration Assistantを使えば本番データ移行まで完了する | 現時点では本番データ移行はサポート対象外。別途データ移行設計が必要 |
| Azure SQLのテーブルを1テーブル1コンテナーにすればよい | NoSQLではアクセスパターンと集約単位を基準に設計する |
| AIが提案したパーティションキーならそのまま採用してよい | ボリューム、クエリ、テナント偏り、将来増加を人間がレビューする |
idをパーティションキーにすれば常に安全 | ポイント読み取りには強いが、他プロパティ検索が多いと横断クエリになりやすい |
| PreviewでもPoCで動いたら本番投入できる | Previewは非本番検証から始め、仕様変更やサポート範囲を考慮する |
| コード変換後にテストが通れば完了 | RU、レイテンシ、ホットパーティション、監視、切り戻しまで確認する |
移行で失敗しやすいのは、ツールの出力を「正解」として扱ってしまうことです。Migration Assistantは、設計判断を速くするための支援ツールです。最終的な責任は、業務要件、データ量、アクセスパターン、運用制約を理解しているチーム側にあります。
まず取るべき次のアクション
Azure SQLまたはSQL Server系ワークロードをCosmos DBへ移行する可能性があるなら、最初にやるべきことは本番移行ではなく、候補システムを1つ選んで設計検証を行うことです。
現実的な進め方は次の通りです。
- 移行候補を1つに絞る
顧客管理、注文履歴、通知履歴、IoTデータ、セッション情報など、境界が明確な領域から始めます。 - DDL、アクセスパターン、ボリューム情報を整理する
「どのテーブルがあるか」ではなく、「どのAPIがどの単位で読むか」を中心にまとめます。 - Visual Studio Code上でMigration Assistantを試す
検証用ブランチと検証用Azure環境、またはCosmos DB Emulatorを使います。 - 生成された
model.jsonとcode-migration-plan.mdをレビューする
パーティションキー、コンテナー設計、インデックス、コード変更範囲をチームで確認します。 - 本番データ移行方式を別途設計する
データ抽出、変換、ロード、差分同期、停止時間、検証、切り戻しを計画します。
Relational Database to Azure Cosmos DB NoSQL Migration Assistantは、Azure SQLからNoSQLへの移行を「勘と手作業」だけで進めないための有用な支援機能です。ただし、Public Previewであり、本番データ移行ツールではありません。管理者は権限・ネットワーク・コスト・AI利用ルールを確認し、開発者はアクセスパターンとコード変更範囲をレビューしながら、まずは小さなPoCで移行可能性を判断してください。
コメント