MicrosoftとDatabricksが提携を拡大、2030年代まで｜データ基盤の選定は「製品選び」から「陣営選び」に変わった

結論：データ基盤は、一度決めると10年動かせない類の意思決定である

2026年7月23日、MicrosoftとDatabricksが戦略提携を拡大したことが発表されました。枠組みは**2030年代まで（into the 2030s）**続くとされています。

内容は抽象的な「提携強化」ではありません。Microsoft公式の発表によれば、Databricks側は自社の中核業務と分析基盤の運用にAzure Databricksへの依存を深め、Azure Cobalt 200プロセッサの採用を広げます。Microsoft側は、Databricksの機能を自社製品群へ統合します。具体名として挙がっているのは、AIコワーカー「Databricks Genie」とMicrosoft 365の統合、ガバナンス層の「Unity AI Gateway」、そしてEntra、Azure Data Lake Storage、OneLake、Power BI、Purview、Foundry、Power Platform、Teams、Copilot への横断的な統合です。

この発表を「大手同士の提携」で読み流すと、中堅企業にとっての意味を取り逃がします。押さえるべき論点は一つです。クラウド事業者とデータ基盤ベンダーの結びつきが深まるほど、利用者側の選択は「製品を選ぶ」から「陣営を選ぶ」に近づくということです。

製品を選ぶだけなら、合わなければ乗り換えればよい。しかし陣営を選ぶということは、その先のデータの置き場所、連携するAIサービス、社内の人材が身につけるスキル、周辺ツールの選択肢まで、まとめて方向が決まるということです。そして、その方向は数年では変えられません。

中堅企業の経営者にとって、この話は縁遠く見えるかもしれません。「うちはまだExcelで集計している段階だ」と。しかし、だからこそ重要です。最初の一歩をどの方向に踏み出すかが、その後10年の自由度を決めるからです。

3行サマリー（先に結論）

• MicrosoftとDatabricksが2026年7月23日に戦略提携の拡大を発表。データ基盤とAIの統合が2030年代まで続く枠組みとされる。
• 利用者にとっての含意は、データ基盤の選定が単一製品の比較ではなく、長期にわたる陣営の選択に近づいたということ。
• 中堅企業が判断すべきは「どの製品が優れているか」ではなく、①データを取り出せるか ②人材を確保できるか ③費用がどう伸びるか ④やめるときに何が起きるか、の4点。

要点表：発表の内容と読み取り方

※提携の対象製品・提供時期の詳細については、Microsoftおよび Databricks の公式発表を一次情報としてご確認ください。

なぜ「陣営選び」になるのか

データ基盤は、単体では成立しません。次の要素が組み合わさって初めて機能します。

• データを貯める場所：データウェアハウス、データレイク、ストレージ。
• データを運ぶ仕組み：基幹システムやSaaSからデータを取り込む処理。
• データを整える処理：形式の統一、重複の除去、項目の定義合わせ。
• データを見せる道具：BIツール、ダッシュボード、レポート。
• データを使うAI：予測、分類、要約、自然言語での問い合わせ。

以前は、この5要素をそれぞれ別々のベンダーの製品で組み合わせるのが普通でした。しかし近年は、クラウド事業者が5要素を一体で提供する方向に進んでいます。今回のような提携は、その流れを加速させます。

今回の発表で注目すべきは、統合先として挙げられた製品名の広がりです。認証基盤（Entra）、ストレージ（Azure Data Lake Storage、OneLake）、可視化（Power BI）、データ統制（Purview）、AI開発（Foundry）、業務アプリ（Power Platform）、コミュニケーション（Teams、Copilot）。これはデータ基盤の話にとどまらず、社員が日々触れる業務環境まで含めた一体化です。「データ基盤だけを別のベンダーにする」という選択の難度は、この統合が進むほど上がります。

一体化には利点があります。連携の作り込みが減り、導入が速くなり、運用も簡素になる。中堅企業にとっては、むしろ歓迎すべき変化です。

同時に、副作用もあります。5要素が絡み合うほど、一部だけを取り替えることが難しくなります。BIツールだけ別のものに替えようとしたら、データの持ち方から見直しが必要になった。AIの利用先を変えようとしたら、データの置き場所から動かす必要があった。こういう事態が起きます。

これがロックインです。悪意があるわけではなく、統合の利便性と表裏一体の性質です。だから「ロックインを避ける」ではなく、ロックインの程度を認識した上で選ぶという姿勢が現実的です。

ロックインを評価する4つの軸

契約前に確認すべき4点を挙げます。ベンダーの提案書には書かれていないことが多いので、こちらから聞く必要があります。

軸1：データを取り出せるか

自社のデータを、標準的な形式で、まとめて、追加費用なく取り出せるか。これが最も重要です。確認すべき具体的な質問は次のとおりです。

• 全データを一括でエクスポートする機能はあるか。
• 形式は何か（独自形式か、CSV・Parquet等の汎用形式か）。
• 取り出しに費用は発生するか（データ転送量に応じた課金があるか）。
• 契約終了時、データはいつまで保持され、いつ削除されるか。

「データは自社のもの」という認識は当然に見えますが、取り出せる形で自社のものである必要があります。

軸2：人材を確保できるか

その基盤を扱える人材を、採用または育成できるか。ここは技術的な優劣より、市場の厚みの問題です。

• 国内でその技術を扱える技術者・パートナー企業はどれくらいいるか。
• 学習用の日本語資料、認定資格、コミュニティはあるか。
• 現在の委託先が対応できなくなった場合、他に頼める先はあるか。

選択肢の少ない技術を選ぶと、特定の担当者・特定の会社に依存することになります。これは製品のロックインより深刻な場合があります。

軸3：費用がどう伸びるか

導入時の見積もりより、3年後の費用のほうが問題になります。

• 課金の単位は何か（保存容量、処理時間、ユーザー数、問い合わせ回数）。
• データ量が2倍になったとき、費用は何倍になるか。
• 利用部門が増えたときの費用の伸び方はどうか。
• 過去の価格改定の履歴と、改定時の通知条件はどうなっているか。

データ基盤の費用は、使われるほど増える構造になっていることが多くあります。「活用が進んだら費用が跳ね上がった」という事態を避けるため、伸び方を先に把握してください。

軸4：やめるときに何が起きるか

最も聞きにくく、最も重要な質問です。

• 移行するとしたら、何を作り直す必要があるか（データ、処理、レポート、権限設定）。
• 移行にかかる期間と概算費用はどの程度か。
• 移行中、業務は止まるか。

この質問に対して具体的に答えられるベンダーは、信頼できます。逆に「移行することは想定していません」という回答しか返らないなら、その提案は検討を続けるべきか考え直す材料になります。

最も多い失敗：可視化から入って、データが整っていない

中堅企業のデータ活用で最も頻繁に見る失敗の順序があります。

1. 経営会議で「データに基づいた意思決定が必要だ」という話になる。
2. BIツールの提案を受け、ダッシュボードのデモを見て導入を決める。
3. 導入後、各システムからデータを集めようとして、初めて問題に気づく。
4. 販売管理システムと会計システムで、同じ「売上」の定義が違う。顧客コードの体系が部門ごとに異なる。マスタが更新されていない。
5. データを整える作業が想定の何倍もかかり、プロジェクトが停滞する。
6. 結局、一部のデータだけを表示する簡易なダッシュボードができ、誰も見なくなる。

この失敗の本質は、見せる道具から入ったことにあります。ダッシュボードは、整ったデータがあって初めて機能します。データが整っていない状態で可視化ツールを入れても、映るのは整っていないデータです。

正しい順序は次のとおりです。

第1段階：何を判断したいかを決める 「データを活用したい」ではなく、「どの判断を、何を見て決めたいか」を具体化します。例えば「どの得意先の粗利が実際にはマイナスかを毎月見たい」「在庫の滞留を早期に把握したい」といった水準です。

第2段階：その判断に必要なデータを特定する 上の例なら、売上・原価・配送費・値引き・返品のデータがどこにあるか、どの粒度で記録されているかを確認します。この時点で「必要なデータが記録されていない」ことが判明する場合があります。それも成果です。

第3段階：定義を統一する 「売上」は税抜きか税込みか、計上のタイミングはいつか。「顧客」は請求先か納品先か。この整理を飛ばすと、後工程のすべてが揺らぎます。地味ですが、ここが最も価値のある工程です。

第4段階：集める仕組みを作る ここで初めて技術的な話になります。どこに貯め、どう運ぶか。

第5段階：見せる ダッシュボードの構築。ここまで来れば、作業自体は難しくありません。

多くの提案は第5段階から始まります。第1〜第3段階は地味で、外部に委託しても見栄えがしないためです。しかし、投資対効果を決めるのはこの前半部分です。

段階的に進めるための現実的な設計

「順序が大事なのは分かったが、全部やる余力がない」という声には、次のような進め方を提案します。

進め方1：一つのテーマから始める 全社のデータ統合を目指さず、一つの判断テーマ（例：得意先別の実質利益）に絞って、第1〜第5段階を通します。小さく通すことで、自社のデータの実態と、必要な作業量が分かります。

進め方2：既存の道具で始める 最初からデータ基盤を構築する必要はありません。ExcelやスプレッドシートでもGoogleフォームでも、定義の統一と手順の確立はできます。手作業でも回るようになってから、自動化と基盤化を検討します。

進め方3：作らずに済む部分を探す 基幹システムやSaaSに標準で備わっている分析機能で足りる場合があります。「基盤を作る」前に、今あるもので何が見られるかを確認してください。

進め方4：出口を先に決める どの基盤を選ぶにせよ、前掲の4軸のうち「データを取り出せるか」だけは最初に確認しておいてください。ここさえ押さえておけば、方向転換の可能性が残ります。

データ定義の統一は、具体的に何をする作業か

「定義を統一する」と書くと抽象的ですが、実際には非常に具体的な作業です。最初の1ヶ月で何をするかを示します。

作業1：用語の一覧を作る

経営会議や各部署の資料に出てくる主要な用語を書き出します。「売上」「粗利」「顧客数」「稼働率」「在庫」「リードタイム」など、10〜20語程度から始めます。

作業2：部署ごとの定義を集める

同じ用語について、各部署がどう定義しているかを聞き取ります。ここで必ず食い違いが見つかります。よくある例を挙げます。

いずれの定義も、その部署の業務上は正しいものです。問題は、これらを突き合わせずに「全社の数字」を作ろうとすることです。

作業3：正式な定義を決める

用語ごとに、全社で使う定義を決めます。ここで重要なのは、他の定義を否定しないことです。「全社の売上は検収基準とする。営業部門が使う受注ベースの数字は『受注高』と呼び分ける」というように、呼び名を分けて併存させます。無理に一本化しようとすると、現場の業務が回らなくなります。

作業4：文書にして共有する

決めた定義を一覧にし、全社で参照できる場所に置きます。ExcelでもWikiでも構いません。重要なのは、後から入った人が参照できることです。

作業5：システム上の項目と対応づける

各定義が、どのシステムのどの項目に対応するかを記録します。「全社の売上＝販売管理システムの売上計上テーブルの計上金額列」といった形です。ここまでやると、後の実装がほぼ機械的に進みます。

この5工程は、外部に発注する必要がありません。社内の会議室で、関係部署が集まって進められます。費用がほぼゼロで、投資対効果が最も高い工程です。

最初の3ヶ月で何をするか

「データ活用を始めよう」と決めてから、最初の3ヶ月の進め方を具体化します。

1ヶ月目：見たいものを決める 経営として、どの判断のためにどの数字が欲しいのかを3つに絞ります。多く挙げすぎると進みません。前掲の定義統一の作業も、この3つに関係する用語から始めます。

2ヶ月目：手作業で作ってみる その3つの数字を、手作業で作ってみます。各システムからデータを出し、Excelで突き合わせ、集計する。手間はかかりますが、この過程で「必要なデータが取れない」「定義がずれている」といった問題がすべて露呈します。

3ヶ月目：自動化の範囲を決める 手作業でやってみた結果をもとに、どこを自動化すれば効果が大きいかを判断します。ここで初めて、ツールや基盤の検討に入ります。

この進め方の利点は、3ヶ月目の時点で「何が必要か」を自分の言葉で説明できることです。ベンダーの提案を評価する材料が、実体験として手元にあります。

逆に、1ヶ月目からツール選定に入ると、提案の中身を評価する基準がないまま契約することになります。

費用をどう見積もるか

データ基盤に関する費用は、次の4種類に分かれます。見積もりを受け取ったら、この4区分で整理してください。

4つ目を計上していないために、プロジェクトが途中で止まるケースが多く見られます。データの定義を決められるのは社内の人だけであり、その人たちの時間は本業と取り合いになります。着手前に、誰がどれくらいの時間を割けるかを確認してください。

既存システムのデータをどう扱うか

もう一つ、中堅企業に固有の論点があります。データ基盤の議論は「新しく作る側」の話として語られがちですが、実際の課題は既存の基幹システムにデータが閉じ込められていることにあります。

• 長年使っている基幹システムから、データを外に出す手段が限られている。
• 出せてもCSVの手作業ダウンロードで、自動化できない。
• ベンダーに依頼するとデータ抽出のたびに費用が発生する。
• そもそも、どのテーブルに何が入っているかの資料がない。

この状態でデータ基盤を導入しても、供給元が細いままなので効果は限定的です。したがって、データ活用を本気で進めるなら、既存システムからデータを取り出せる状態にすることが前提工事になります。

これは基幹システムの刷新と隣接する話です。刷新を検討している企業なら、その要件に「データを外部に連携できること」を必ず入れてください。刷新の予定がないなら、既存システムからのデータ連携手段を個別に整備する必要があります。どちらにせよ、可視化ツールの選定より先に来る論点です。

FAQ

Q1. うちはまだExcelです。データ基盤の話は早いですか。 A. 基盤の構築は早いかもしれませんが、定義の統一と「何を判断したいか」の整理は今すぐできます。むしろその段階で整理しておくと、後で基盤を入れるときの投資が無駄になりません。

Q2. Microsoft系で統一すれば楽ではないですか。 A. 既にMicrosoft製品を多く使っているなら、統合の利便性は実際にあります。判断すべきは、それを承知の上で選ぶかどうかです。4軸のうち「データを取り出せるか」だけは確認した上で進めてください。

Q3. ロックインは避けるべきものですか。 A. 必ずしもそうではありません。統合された環境の利便性は実利です。問題は、ロックインしていることを認識せずに選び、数年後に身動きが取れなくなることです。

Q4. BIツールの提案を受けています。どう判断すればよいですか。 A. 「そのツールで何を見たいか」を先に自社で言語化してください。その上で、必要なデータが現在どこにあり、どの状態かを確認します。ここが曖昧なまま導入すると、高確率で使われなくなります。

Q5. データの定義を統一する作業は誰がやるのですか。 A. 業務を知っている社内の人でなければできません。外部委託できるのは進行と整理の支援までです。ここを外部に丸投げすると、現場が納得しない定義ができあがります。

Q6. 費用はどれくらいかかりますか。 A. 範囲によって大きく変わるため一概には言えません。ただし、第1〜第3段階（何を見たいか、どのデータが必要か、定義の統一）は、社内の時間を使えば費用をほぼかけずに進められます。

Q7. 既存の基幹システムからデータが出せません。 A. 出せるようにするための追加開発を既存ベンダーに依頼するか、刷新のタイミングで要件に入れるかの二択になります。どちらの場合も、「どのデータを、どの頻度で、どの形式で出したいか」を先に決めておくと交渉が具体的になります。

GXOに相談すべきタイミング

次のいずれかに当てはまるなら、ツール選定より前の段階から整理することをおすすめします。

• BIツールやデータ基盤の提案を受けているが、自社に本当に必要か判断できない。
• データを見たいが、そもそもどこに何があるか把握できていない。
• 既存の基幹システムからデータを取り出せず、活用が進まない。
• 特定のクラウド・ベンダーに寄せてよいか、経営判断として決めきれない。

GXOは特定のデータ基盤・BI製品を販売する立場ではないため、製品比較の前に「何を判断したいか」から一緒に整理することができます。データ基盤・BIの構想と設計はデータ基盤・データ活用の相談、既存システムからのデータ連携や基幹システムの見直しはシステム開発・DXの相談、AI活用まで見据えた検討はAI開発・活用の相談、現状把握から始めたい場合はDX成熟度診断が入口です。「何を見たいか」の整理からご一緒することも可能です。お問い合わせより、現在お困りの点をお知らせください。

データ基盤の選定で本当に怖いのは、間違った製品を選ぶことではありません。整っていないデータの上に、立派な可視化の仕組みを載せてしまうことです。

参考文献

• Microsoft Source「Databricks and Microsoft expand partnership」（一次・公式）: https://news.microsoft.com/source/2026/07/23/databricks-and-microsoft-expand-partnership/
• IT Leaders「カプコン、オンプレミスのデータ分析基盤をクラウドDWHで刷新」（二次・報道／事例参考）: https://it.impress.co.jp/articles/-/29604

※提携の具体的な範囲、対象となる製品、提供時期については、各社の公式発表を一次情報としてご確認ください。本稿は2026年7月24日時点で入手可能だった情報に基づいています。