MENU

Azure Synapse Link for Cosmos DB NoSQL廃止｜期限・影響・移行手順

Azure

Azure Synapse Link for Azure Cosmos DB NoSQLは、2029年3月31日に提供終了します。また、新しいAzure Cosmos DB for NoSQLアカウントでは、すでに2026年3月31日以降、Azure Synapse Linkを有効化できません。

既存環境は終了日までサポートされますが、Microsoftは移行先として「Microsoft FabricのAzure Cosmos DBミラーリング」を推奨しています。Azure Cosmos DBやAzure Synapse Analytics自体が廃止されるわけではなく、対象は両サービスを接続する分析機能です。(マイクロソフト Azure)

この記事では、2026年6月10日に公開された公式情報をもとに、影響を受ける環境の見分け方、設定の確認方法、移行手順、料金、期限までに注意すべきポイントを整理します。

目次

Azure Synapse Link for Azure Cosmos DB NoSQLの廃止内容

今回の発表内容は、次のとおりです。

確認項目内容
公式情報の公開日2026年6月10日
新規アカウントでの有効化2026年3月31日以降は不可
既存環境のサポート期限2029年3月31日
推奨される移行先Microsoft FabricのAzure Cosmos DBミラーリング
廃止対象Azure Synapse Link for Azure Cosmos DB NoSQL
廃止対象ではないものAzure Cosmos DB、Azure Synapse Analytics全体

新規アカウントでの有効化停止日は、公式発表日より前の2026年3月31日です。これから新しい分析基盤を構築する場合、Azure Synapse Linkを前提とした設計はできません。

既存利用者も、2029年3月31日まで使い続けることを目的にするのではなく、それまでに移行と動作確認を完了させる必要があります。(マイクロソフト Azure)

何が変わるのか

Azure Synapse Link for Azure Cosmos DBは、Azure Cosmos DBのトランザクション処理とは別に分析用データを保持し、Azure Synapse SQLやApache Sparkから分析できる機能です。

移行後は、Microsoft Fabricのミラーリングを利用して、Azure Cosmos DBのデータをOneLakeへ継続的に複製します。分析先もAzure Synapse Analytics中心の構成から、FabricのSQL分析エンドポイント、Spark、Power BI DirectLakeなどを利用する構成へ変わります。(Microsoft Learn)

比較項目Azure Synapse LinkAzure Cosmos DBミラーリング
分析データの保存先Azure Cosmos DBの分析ストアMicrosoft FabricのOneLake
主な分析手段Synapse SQL serverless、Synapse SparkFabric SQL分析エンドポイント、Fabric Spark、Power BI
データ連携方式分析ストアへ同期継続的バックアップを利用して複製
必要な基盤Azure Synapse AnalyticsMicrosoft Fabric容量とワークスペース
新規採用非推奨、新規アカウントでは有効化不可Microsoftの推奨移行先

ミラーリングは単純な設定変更ではありません。データの保存先、クエリの接続先、アクセス権限、Power BIの接続方法などが変わるため、実質的には分析基盤の移行として計画する必要があります。

影響を受けるユーザーと環境

Azure Cosmos DBを利用していても、すべての環境が直ちに影響を受けるわけではありません。

利用状況影響と必要な対応
Azure Cosmos DBのトランザクションAPIだけを利用今回の廃止による直接的な影響は基本的にない
分析ストアを有効化している移行対象となる可能性が高い
Synapse SQLからCosmos DBを参照しているクエリ接続先やSQLの移行が必要
Synapse Sparkでcosmos.olapなどを利用しているFabric Sparkへの移行とコード検証が必要
Power BIでSynapse Link経由のデータを利用しているデータモデル、更新方法、DirectLake利用可否の確認が必要
新規のAzure Cosmos DBアカウントで分析基盤を構築するAzure Synapse LinkではなくFabricミラーリングを検討する
分析ストアに長期履歴を残している履歴データの退避やバックフィルが必要になる可能性がある

特に見落としやすいのが、Azure Synapse Analytics上のパイプラインやノートブックだけでなく、Power BIレポート、定期バッチ、独自アプリケーションが分析ストアを参照しているケースです。

Azure Cosmos DBの画面だけを確認するのではなく、データの利用先まで一覧化してください。

Azure Synapse Linkの利用状況を確認する手順

Azure Cosmos DBアカウントを洗い出す

最初に、対象となるサブスクリプション内のAzure Cosmos DB for NoSQLアカウントを一覧化します。

管理対象が多い場合は、次の情報を台帳にまとめると移行漏れを防げます。

  • サブスクリプション名
  • リソースグループ名
  • Azure Cosmos DBアカウント名
  • データベース名
  • コンテナー名
  • Azure Synapse Linkの利用有無
  • 分析ストアの保持期間
  • 接続先のSynapseワークスペース
  • 利用しているレポート、ノートブック、パイプライン
  • システム担当者と業務担当者

コンテナーのTTL設定を確認する

Azure CLIでは、次のコマンドでコンテナーのトランザクションTTLと分析ストアTTLを確認できます。

az cosmosdb sql container show \
  --resource-group <resource-group> \
  --account-name <account-name> \
  --database-name <database-name> \
  --name <container-name> \
  --query "{name:name, defaultTtl:resource.defaultTtl, analyticalStorageTtl:resource.analyticalStorageTtl}"

主に確認する値は次の2つです。

項目意味
defaultTtlトランザクションストアにデータを保持する期間
analyticalStorageTtl分析ストアにデータを保持する期間

analyticalStorageTtlに-1または正の秒数が設定されている場合は、分析ストアが有効になっている可能性があります。

-1は無期限保持、正の数値は秒単位の保持期間です。0を設定すると分析ストアが無効化され、保存されている分析データが削除されるため、移行確認前に変更してはいけません。(Microsoft Learn)

分析ストアを参照する処理を検索する

Azure Synapse Analyticsやソースコード内で、次の項目を検索します。

  • Cosmos DBのリンクサービス
  • Synapse SQL serverlessのビューやOPENROWSET
  • Synapse Sparkのノートブック
  • cosmos.olapを利用する処理
  • Power BIのデータソース設定
  • Azure Data FactoryやSynapseパイプライン
  • 分析ストアを参照する独自アプリケーション
  • スキーマ変換や列名変更を行う処理

「現在は使われていないと思われる接続」も、削除前に実行履歴や利用部門を確認してください。月次・四半期処理だけで使われている可能性があります。

移行方法はデータの保持期間で判断する

Microsoftの移行ガイドでは、主に2つの移行パターンが示されています。

標準移行

トランザクションストアに必要なデータがすべて残っている場合は、標準移行を選択できます。

たとえば、次のような環境です。

  • トランザクションTTLと分析ストアTTLがどちらも無期限
  • 分析に必要な期間より、トランザクションストアの保持期間が長い
  • 過去データを別のデータレイクやバックアップに保存している

この場合は、Fabricミラーリングで現在のAzure Cosmos DBデータを複製し、利用先を順番に切り替えます。

履歴データを保全する移行

分析ストアの保持期間がトランザクションストアより長い場合は、標準移行だけでは過去データが失われます。

たとえば、次の設定を考えます。

  • トランザクションTTL：30日
  • 分析ストアTTL：365日

この場合、31日前から365日前までのデータは分析ストアにしか存在しません。Fabricミラーリングは現在のトランザクションストアを基に複製するため、この履歴は自動的に移行されません。

履歴を残すには、分析ストアから過去データをDeltaテーブルなどへ書き出し、Fabricのミラーリングデータと統合する必要があります。公式ガイドでは、切り替え時刻を決め、履歴データと切り替え後のミラーデータをSQLビューで結合する方法が案内されています。(Microsoft Learn)

Microsoft Fabricへ移行する手順

前提条件と制限を確認する

Azure Cosmos DBミラーリングを利用するには、主に次の準備が必要です。

  • Azure Cosmos DB for NoSQLアカウント
  • Microsoft Fabric容量
  • Fabricワークスペースへの必要な権限
  • Azure Cosmos DBの継続的バックアップ
  • ネットワークと認証方式の確認

現時点の公式ドキュメントでは、ミラーリングはAzure Cosmos DB for NoSQLが対象です。また、7日間または30日間の継続的バックアップが必要で、複数リージョン書き込みなど、継続的バックアップ側の制限を受けます。(Microsoft Learn)

プライベートエンドポイントや仮想ネットワークを利用している場合は、Network ACL Bypassを含めた接続設計も確認してください。

Fabricでミラーリングを作成する

Fabricワークスペースで「Mirrored Azure Cosmos DB」を作成し、対象のAzure Cosmos DBアカウントへ接続します。

作成後、初期複製が完了するまで待ち、次の項目を検証します。

  • コンテナーごとの件数
  • 最新レコードの反映状況
  • 日時や数値のデータ型
  • 配列や入れ子になったJSONの展開結果
  • 欠損値やスキーマ変更の扱い
  • クエリの応答時間
  • Power BIレポートの集計結果
  • 利用者ごとのアクセス権限

単純な件数比較だけでは不十分です。業務で利用する集計値や代表的な検索条件でも、旧環境と新環境の結果を比較してください。

旧環境と並行稼働する

Azure Cosmos DBミラーリングは分析ストアを使用しないため、Azure Synapse Linkと並行して動かせます。移行期間中は、旧環境を残したまま新環境の検証が可能です。(Microsoft Learn)

ただし、並行稼働中はAzure Synapse AnalyticsとMicrosoft Fabricの両方に費用が発生する可能性があります。検証期間と終了条件を先に決めておくことが重要です。

クエリとレポートを切り替える

検証が完了した処理から、利用先を切り替えます。

  • Synapse SQLのクエリをFabric SQL分析エンドポイントへ移行
  • Synapse SparkノートブックをFabricノートブックへ移行
  • Power BIの接続先をFabricへ変更
  • パイプラインや定期処理の接続情報を更新
  • 監視、アラート、障害対応手順を更新

SQL構文が似ていても、データ型や入れ子構造の見え方、サポートされる機能が同一とは限りません。既存SQLをそのままコピーして完了と判断せず、結果と性能をテストしてください。

履歴データを移行する

分析ストアだけに残っている履歴がある場合は、切り替え時刻を決めて過去データを書き出します。

重複や欠落を防ぐには、次のように範囲を分けます。

  • 切り替え時刻より前：履歴用Deltaテーブル
  • 切り替え時刻以降：ミラーリングされたテーブル

両方を統合するビューを作成し、レポートやアプリケーションからは統合後のビューを参照させます。

検証完了後にAzure Synapse Linkを停止する

次の確認がすべて終わってから、分析ストアを無効化します。

  • 必要な履歴データを移行した
  • レポートと集計結果が一致している
  • 定期処理が新環境で正常に完了した
  • 障害時の復旧手順を確認した
  • 利用部門から切り替え承認を得た
  • 旧環境へ戻す必要がないと判断した

分析ストアのTTLを0にすると、保存されていたデータは削除されます。移行前の試験として安易に設定しないでください。(Microsoft Learn)

移行時に見落としやすい設定

継続的バックアップを有効化できるか

Fabricミラーリングは、Azure Cosmos DBの継続的バックアップを利用します。

既存アカウントの構成によっては、継続的バックアップへの切り替えに制約があります。特に複数リージョン書き込み、過去の分析ストア設定、バックアップポリシーは事前確認が必要です。

現在の本番アカウントをそのまま変更できない場合は、別アカウントへのデータ移行を含めた構成変更が必要になる可能性があります。

認証情報の更新手順

Fabricからの接続にアカウントキーを利用する場合、Azure Cosmos DB側でキーをローテーションした後にFabricの接続情報も更新しなければ、ミラーリングが停止する可能性があります。

Microsoft Entra IDを利用する場合も、対応するロールと権限範囲を確認してください。マネージドIDや読み取り専用キーなど、希望する認証方式が利用できるとは限りません。(Microsoft Learn)

セキュリティ要件

移行前に次の点を確認します。

  • OneLake側のデータ暗号化要件
  • カスタマーマネージドキーの要否
  • Fabricワークスペースへの参加者
  • SQL分析エンドポイントの共有範囲
  • 開発、検証、本番ワークスペースの分離
  • 個人情報や機密情報へのアクセス制御
  • 監査ログの保存方法

Fabricワークスペースへの権限付与が、ミラーリングされたデータへのアクセス権に影響します。Azure側だけでなく、Fabric側の権限棚卸しも必要です。

停止と再開の挙動

ミラーリングを停止して再開すると、対象テーブルが再同期される場合があります。大量データを扱う環境では、再同期に必要な時間、容量、業務への影響を検証しておきましょう。(Microsoft Learn)

移行に伴う料金の考え方

今回の廃止により、自動的に一律の追加料金が発生するわけではありません。ただし、移行先では料金の構成が変わります。

フェーズ主に確認する料金
現行環境Cosmos DB分析ストア、Synapse SQLやSparkなどのコンピューティング
並行稼働中現行環境の料金に加えてFabric容量、クエリ処理、ストレージ
移行完了後Fabric容量、SQL・Spark・Power BIの処理、OneLakeストレージ
旧環境停止後不要になった分析ストアやSynapseリソースが残っていないか

Fabricのミラーリング用ストレージには、購入しているFabric容量に応じた無料枠があります。無料枠を超えた場合やFabric容量を一時停止している場合は、OneLakeストレージ料金が発生する可能性があります。料金条件はリージョンや契約によって変わるため、実際のデータ量とクエリ負荷で試算してください。(マイクロソフト Azure)

また、ミラーリングによる複製処理は、Azure Cosmos DBのトランザクション処理に対する追加のRequest Unit消費を発生させないと案内されています。ただし、Fabric上で実行するSQL、Spark、Power BIなどの処理には、それぞれのコンピューティング料金が関係します。(Microsoft Learn)

料金を比較するときは、ストレージ単価だけでなく、次の項目を含めます。

  • Fabric容量の常時稼働時間
  • Power BIの利用形態
  • SQLとSparkの実行量
  • 履歴データの保存容量
  • 並行稼働期間
  • 移行作業やクエリ改修の工数
  • 監視、バックアップ、運用変更のコスト

2029年3月31日までの推奨スケジュール

2029年3月31日は、移行を開始する日ではなく、移行を完了しておくべき最終期限です。

実務上は、次のスケジュールを目安にすると余裕を持って進められます。

時期の目安実施内容
2026年中利用環境、TTL、依存システム、データ量の棚卸し
2026年後半から2027年Fabricミラーリングの概念実証、性能と料金の比較
2027年から2028年履歴データ移行、SQL・ノートブック・レポートの改修
2028年中本番の並行稼働と段階的な切り替え
2029年1月まで本番移行を完了し、旧環境停止の承認を取得
2029年2月から3月残存リソース、権限、料金、監視設定の最終確認

内部期限を2029年3月31日と同日にすると、性能問題やデータ不整合が見つかった際に修正する時間がありません。少なくとも数か月の予備期間を設けるのが安全です。

よくある疑問

Azure Cosmos DB自体が使えなくなるのか

Azure Cosmos DB自体の廃止ではありません。

今回の対象は、Azure Cosmos DB for NoSQLのデータをAzure Synapse Analyticsから分析するためのAzure Synapse Linkです。通常のアプリケーションからAzure Cosmos DBへ読み書きする処理は、今回の発表だけを理由に停止するものではありません。

Azure Synapse Analyticsも2029年に廃止されるのか

今回の発表は、Azure Synapse Analytics全体の廃止を意味しません。

ただし、Azure Synapse Linkを利用しているSQLクエリ、Sparkノートブック、パイプラインなどは、接続先や処理方式の変更が必要になります。

既存環境は2029年まで何もしなくてよいのか

2029年3月31日までは既存利用者へのサポートが案内されていますが、移行作業を先送りするのは危険です。

履歴データが多い環境、複数のPower BIレポートが接続している環境、プライベートネットワークや複数リージョン書き込みを利用している環境では、設計変更に時間がかかる可能性があります。

Fabricミラーリングへ切り替えるだけで移行できるのか

データの複製だけであれば比較的少ない操作で開始できますが、分析基盤全体の移行は別です。

クエリ、Power BI、Spark、権限、監視、料金管理、履歴データの扱いを個別に確認する必要があります。特に分析ストアにしか残っていない過去データは、自動では移行されません。

移行先の制限に現在の構成が対応していない場合はどうするか

分析ストアを無効化せず、現在のネットワーク構成、バックアップ方式、リージョン構成、暗号化要件を整理してください。

Fabricミラーリングをそのまま利用できない場合は、別のAzure Cosmos DBアカウントへの移行、データパイプラインによるOneLakeへの連携など、代替構成をMicrosoftまたは構築パートナーと検討する必要があります。

まず実施すべきこと

Azure Synapse Link for Azure Cosmos DB NoSQLを利用している可能性がある場合は、次の3点から着手してください。

  1. Azure Cosmos DBコンテナーのanalyticalStorageTtlを確認する
  2. Synapse SQL、Spark、Power BI、パイプラインの依存関係を一覧化する
  3. トランザクションTTLと分析ストアTTLを比較し、標準移行か履歴保全移行かを判断する

新規アカウントではすでにAzure Synapse Linkを有効化できません。既存環境についても、2029年3月31日の直前ではなく、Fabricミラーリングとの並行稼働と業務データの検証を早めに開始することが重要です。

Azure
Azure Cosmos DB Microsoft Fabric Azure Synapse Analytics Azure Synapse Link

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次