Keywords: Microsoft Fabric, Databricks, AI Platform, Data Infrastructure, Medallion Architecture, Lakehouse, PoC
データ基盤を4〜5年運用していると、導入当初には見えなかった課題が顕在化します。部門や目的ごとにデータと処理が増え、サイロ化やロジックの重複が進む一方、長年継ぎ足されたソースコードは次第にブラックボックス化していきます。周辺サービスが進化するなかで、当初採用した技術や設計の古さも目立ち始め、新しい分析技術やAI活用に対応するたび、改修と運用の負担が積み上がります。
特に、LLMやAI Agentが急速な成長を遂げるなかで、それらは単なる付加機能ではなく、自らデータを検索・判断・活用する主体になりつつあります。データ基盤そのものがこの変化を前提としていなければ、新しいAI活用へ継続的に追随することはできません。
こうした状況で必要になるのが、データの持ち方、処理、ガバナンス、開発・運用までを見直すデータ基盤のモダナイゼーションです。その中核にあるのは、人間だけでなくAIモデルやAI Agentも、データを正確かつ安全に活用できるAI-Readyな基盤へと発展させることです。そのソリューション選定において、現行システムを移行できるかだけでなく、このAI-Readyなデータ基盤 (Data & AI Platform とも表現される) を数年先まで支えられるかが重要な判断軸になります。
本記事では、Azure SQL DatabaseとAzure Synapse Analyticsを中心としたデータ環境のモダナイゼーションに向け、Microsoft Fabric(以降、Fabricと呼ぶ)、Azure Databricks、Snowflake、Google Cloud（GCP）を調査した事例を取り上げます。当初は既存環境との連続性からFabricへの移行を始めましたが、実務向けPoCを経てDatabricksを比較対象として再評価することになりました。この経緯をもとに、データ基盤のモダナイゼーションにおけるソリューション選定の考え方と、選定基準をどう見直したかをお伝えしたいと思います。
⚠️ 本記事は2026年9月時点のソリューション情報と検証状況に基づきます。記載する評価は、特定の前提条件を持つ一組織の事例であり、各サービスの絶対評価ではありません。
先に結論
PoCでは当初から、既存基盤をFabricへ移行できるかと、将来のAI活用を支えるAI-Readyなデータ基盤として成立するかを、目的の異なる評価軸として分けて検証しました。その結果、移行自体は技術的に可能と判断した一方、AI-Readyな基盤としては、Fabricの発展途上の機能や、OntologyとPurviewに分かれたガバナンスの運用に検討すべき課題が残りました。
| 論点 | 現時点の判断 |
|---|---|
| Fabricへの移行 | 技術的には可能。ただし、AI-Readyな基盤としての成熟度と運用性は別途見極める |
| Fabricの採用判断 | 既定路線とせず、Databricksとの比較結果を踏まえて判断する |
| Databricksへの移行 | 現時点では未決定。比較検証の対象とする |
| 選定の見直し事由 | メダリオンアーキテクチャは変更せず、各コンポーネントと接続設定を中心に移行可能 |
| 次のステップ | Fabricで実装したWorkloadをDatabricks上にも実装し、実用性と運用負荷を比較する |
「移行できるか」だけでなく、数年先のAI活用を支えられるかでソリューションを判断
1. ソリューション選定を左右した前提条件
データ基盤の選定は、機能比較だけでは決まりません。多くの企業には、すでにクラウド環境、データ資産、BI、セキュリティ、運用スキルが積み重なっており、それらが移行の制約であると同時に、次の基盤を考える出発点になります。今回のケースでは、次のような既存資産や前提条件がありました。
- Azure SQL Database, Azure Synapse Analytics, Power BI
- サードパーティの機械学習プラットフォーム
- Azureを前提としたインフラとセキュリティ
- T-SQLやノートブックなどの既存資産
- Azureに関する組織内のスキル
今回の評価で問うべきなのは、「最も高機能なソリューションはどれか」ではなく、既存のAzureデータ基盤を、次のデータ基盤へどう発展させるかです。
最適な選択は、既存のクラウドやデータ資産、BI、技術者のスキル、セキュリティ、移行コスト、将来のAI戦略によって変わります。Google Cloudを全社で利用している企業ならBigQuery、Snowflakeを中心にDWHとデータ共有を確立している企業ならSnowflakeを継続する合理性があるでしょう。
著者の場合、Azureを中心とした既存環境との親和性が高く、Power BIやOneLakeを同じSaaS基盤で扱えるMicrosoft Fabricが、移行コストや難易度を踏まえた有力候補でした。(Microsoftのテクニカルサポートにも現状の課題を相談しましたが、提案は予想どおりFabricでした🤗)
2. Fabric移行前のソリューション調査
Fabricを最初から移行先として決めていたわけではありません。移行に着手する前に、Snowflake、Google Cloud（GCP）、Azure Databricks、Microsoft Fabricを候補として調査し、既存資産との親和性、将来のData & AI活用、移行と運用に伴う負担を比較しました。当時の整理は次のとおりです。
| Platform | 評価したポイント | 当時感じた主な課題 |
|---|---|---|
| Snowflake | DWHとしての成熟度、データ共有 | 今回のData & AI戦略の中核に置く必然性 |
| Google Cloud | BigQuery、AIとの親和性、B2C向けのGA4との連動性 | 新たなクラウド運用体系を持つコスト |
| Databricks | Lakehouse、Data Engineering、ML / AI | 新しいプラットフォームの学習と運用 |
| Microsoft Fabric | Azure、Power BI、既存資産との連続性 | 新しいサービスとしての成熟度 |
この比較は、すべてのソリューションを同規模の本番環境で運用した結果ではありません。公式ドキュメントや技術情報を調査し、LLMも情報の整理に活用しました。
既存環境との連続性、移行のしやすさ、現在の運用スキルを重視した結果、Fabricを選び、SKU-F8/F16(※)環境で移行に向けた検証を開始しました。この時点の判断は、当時の評価軸に対して合理的だったと考えています。
※ SKU: Fabricのサブスクリプション価格体系や容量ユニット(CU)を示す
3. 実務レベルのPoCで見えた課題
PoCには、すでに本番運用の実績がある機械学習パイプラインの一部を選びました。単純な移植可否ではなく、将来のデータ・AI基盤としての実用性を確認するため、Synapse上の既存処理やMLflowの構成をそのまま再現せず、T-SQLやノートブックを次の観点から再設計(Re-Design)しています。
- 不要処理の廃止と重複ロジックの統合
- 処理ごとの責務の整理
- CI/CDと変更管理
- 監視と再実行
- AIからのデータ再利用
前述の通り、検証した点は、「既存処理をFabric上で再現できるか」だけではありません。開発、運用、ガバナンス、AI活用を一体として設計し、継続的に改善できる基盤になるかまでを下表のような軸で評価しました。
その結果、採用を直ちに断念するような単一の問題ではなく、複数の評価領域にあるギャップが積み重なり、基盤全体の運用へ影響する懸念や課題が浮かび上がりました。
| 評価領域 | PoCで検証した項目 |
|---|---|
| ガバナンス | 権限制御、データカタログ、データとAI資産を横断した統制 |
| 開発・運用 | 外部とのデータ連携、ノートブックを含むコード管理、CI/CD、運用監視 |
| AIからの利用 | Text-to-SQL、非構造化データ、AI Agentからの安全なアクセス、AI Agentによるテスト自動化・品質向上 |
| AIライフサイクル | 評価、監視、LLMOps、品質改善の運用 |
詳細な評価は控えますが、期待水準を満たした項目がある一方、追加設計や代替手段が必要な項目が明らかになりました。個々のギャップは補えても、その対応が重なるほど開発・運用は複雑になり、ビジネス上のアジリティが低下すると考え、左記のようなジレンマは、実務レベルのWorkloadを構築してこそ、得られた苦い果実でした。
4. Fabricは発展途上のソリューション？
Microsoft Fabricは、Databricksが提唱したメダリオンアーキテクチャの考え方を取り入れながら、OneLakeを中心にPower BI、Data Factory、Data Engineering、Data Scienceなどを統合しています。Azureサービスとのシナジーを最大化し、既存のMicrosoft環境から一体的なData & AI Platformへ発展できる点は、なんといっても大きな魅力でした。
一方、Fabricの一般提供が開始されたのは2023年11月です。現在も継続的に機能が追加されている発展途上のソリューションであるため、将来性だけで判断せず、必要な機能の安定性や運用性、AI-Readyなデータ基盤としての実用性をPoCで見極める必要がありました。
そこで、Azureとの親和性を重視しつつ、現在の実務要件をどこまで満たせるかを比較するため、Databricksを改めて評価することにしました。
5. Databricksを再評価した理由
Databricksの再評価で着目したのは、データとAI資産を横断したガバナンスを、どこまで一貫した仕組みで実現できるかという点です。
Fabricでは、Fabric IQのOntologyが、業務概念とOneLake上のデータを結び付け、人間とAI Agentが共有できる意味レイヤーを提供します。一方、Microsoft Purviewは、データ資産の検出、分類、系列、保護、監査などを担います。両者の目的は同じではありませんが、カタログ、メタデータ、ガバナンスという接点が複数の仕組みにまたがるため、どれを信頼できる情報源とし、どの機能で統制するかという責務の境界が分かりにくくなります。Ontology自体も現時点ではPreviewで、ソリューション比較時点では公表されてませんでした。
⚠️ Ontology（オントロジー）: 業務上の概念や概念同士の関係を形式化し、データの意味をAIやシステムが解釈できるようにする仕組み
ガバナンスの構成を比べると、Azure DatabricksのUnity Catalogは、テーブルからモデル、サービスまでをセキュリティ保護可能なオブジェクトとして扱い、アクセス制御、系列、監査、品質監視をデータとAIに共通するガバナンスレイヤーへ集約しています。属性ベースのアクセス制御（ABAC）では、管理されたタグを使って行フィルターや列マスクを適用できます。
Fabricに上記の機能がないというよりも、AI-Readyな基盤の中核となるOntologyとガバナンスが、まだ一つの運用モデルとして統合されていない点を課題と捉えました。この責務の分散は、移行後のAI Agent開発・運用における制約になり得ます。
実務への採用には、Preview段階のOntologyが要件を満たすか、Purviewと一貫して運用できるかに加え、仕様変更や代替手段による負荷、Roadmapへの依存度を見極める必要があります。
したがって、Databricksを再評価した理由は、特定のAgentやLLMではなく、AIが参照するデータとAI資産の権限、系列、監査をUnity Catalogへ集約できる点です。Ontologyの実装は別途検証が必要ですが、ガバナンスの基準を一か所に置けることを評価しました。
6. ソリューション選定を見直すことができた背景
ソリューション選定の方針を見直すことができた最大の要因は、全体設計を特定のサービスに依存させず、メダリオンアーキテクチャで構成していたことでした。加えて、Re-DesignしたNotebookなどのソースコードは、そのままDatabricksへ組み込めるので、PoCの必要工数が比較的に軽いことも後押ししました。概略は以下の通りです。
- メダリオンアーキテクチャ： Bronze、Silver、Goldの構成とデータフローは、そのまま移植可能
- 各コンポーネント： Fabric固有の機能をDatabricks側の機能へ置き換えればOK
- ネットワーク： 接続先や認証経路の再設定は必要だが、既存のAzureリソースを継続利用できるため、今回の前提では工数は比較的軽微
- CI/CD： Fabricの設計と切り離して設計しているため、パイプラインの考え方や工程には影響しない。接続先、認証情報、デプロイ先などの初期設定は再構成
このように、長期的に維持するアーキテクチャと、必要に応じて入れ替えるコンポーネントを分けておくことで、ソリューションを変更する際の影響範囲を限定できます。比較対象が同じAzure上のDatabricksであることも、既存リソースを活用しながら再評価した理由でもありました。
7. サンクコスト（Sunk Cost）をどう捉えるか
Project Managerとして今回のソリューション再選定へ戻る決断を行い、データ基盤移行の調査や、機械学習パイプラインとCI/CDの実装に費やした時間・工数を惜しいと感じないわけではありません。しかしながら、今回の取り組みは単なる損失ではなく、AI-Readyなデータ基盤に必要な要件を具体化し、机上調査だけでは得られない知見を蓄積する機会になりました。
損切りをためらわない私自身の性格も相極まり、この段階で方針を見直せた一因と振り返ってます。ただし、最初から方向転換を選んだわけではありません。リーダーやメンバーと代替案を検討し、課題を解決する方法や別のソリューションへ切り替える場合の影響を比較しました。
一方、4つのソリューション候補すべてについて、同じ水準の実務経験を持つ専門家からAssessmentを得ることは、現実的に容易ではありません ——— そういうスキルセットを持つ人材はかなり希少でしょう ———。
とはいえ、DatabricksとSnowflakeの両方を経験した方から話を聞く機会はありましたが、今回の比較は主に公式情報、技術調査、Fabric上のPoC結果に基づいています。そのため、ここでの判断は最終結論ではなく、次の検証へ進むための仮説として位置づけます。
8. 次のステップ
現時点で、Databricksへの移行を決定したわけではありません。次のPoCでは、Fabricで構築した機械学習パイプラインのWorkloadをDatabricks上でも実装し、実用性と運用負荷を同一条件で比較し、ソリューションの再選定を行う計画です。
まとめ
今回のPoCでは、当初から切り分けていた「移行」と「モダナイゼーション」という二つの目的に、具体的な輪郭を与えました。既存処理を新しい環境で動かすだけあれば、移行は可能です。しかし、AI Agentがデータの利用者になる数年先まで見据えると、問うべきなのは現行仕様とのFittingではなく、Ontologyとガバナンスを一貫して扱えるかです。
Fabricでの試行錯誤は遠回りではなく、失敗とも捉えておりません。実装したからこそ、当初は見通せなかった潜在的な課題が明確になり、かつメダリオンアーキテクチャを軸にしたことで、設計を捨てずにDatabricksへの比較に進めました。これは、特定のソリューションに固執せず、目的に合わせて投資オプションを見直せる状態を作ることも、モダナイゼーションの一部だという経験でした。
結論は、次のPoCで同じワークロードを動かしてから出します。