データレイクハウスとは｜データウェアハウス・データレイクとの違いと、AI活用を進める会社が選ぶべき理由

経営者がAIに「一番多い失注要因はなにか」「あの時期に売上が落ちた要因は何か」と尋ねる。
ところが返ってくるのは、社内の商談履歴でも議事録でもなく、どこかネットに転がっていそうな一般論を混ぜ合わせた、当たり障りのない答えです。
経営者は「ChatGPTも、結局この程度か」「うちにはまだ早いな」と、静かに落胆します。

こうした場面を、AI活用を支援する現場では何度も見てきました。
そして多くの場合、落胆の原因はAIの賢さそのものではありません。
AIが参照できる社内データが、使える形で溜まっていない。あるいは、あちこちに散らばっていて、AIのところまで届いていない。
問題はたいてい、そちら側にあります。

この記事は、「肝心な質問をしたときにAIは当てにならない」「でも、なぜ答えてくれないのかをうまく説明できない」——そんな感覚を持ち始めている方に向けて書いています。

「データレイクハウス」という存在を中心に、なぜAIは答えられないのかを「AIの回答の質は、AIが参照できる社内データの質と範囲で決まるため、構造化データだけのデータウェアハウス（DWH）では、AIに聞ける範囲がその枠内に閉じてしまう」と原因を理解したうえで、AIを活用していくにはどうすればよいか、までを記載しています。

なぜAIは「自社のこと」になると、急に的外れになるのか

AIは、自分が参照できるデータからしか答えられないから。それだけです。
世の中の生成AIは、インターネット上に公開された膨大な文章を学んでいるので、一般論ならいくらでも流暢に語れます。
けれど、御社の商談がどう転んで失注したのか、あの月に何が起きていたのかは、ひとつも知りません。知らないことは、一般論で埋めるしかないのです。

ここで見落とされがちなのが、「経営者がAIに本当に聞きたいこと」は、いったいどこに記録されているのか、という点です。
失注の理由、案件が動いた経緯、顧客の温度感——その大半は、きれいな数字の表ではなく、議事録や商談メモ、メール、契約書、問い合わせのログ、さらには電話の録音や図面・画像といった、決まった型を持たない情報の中に残っています。
こうしたデータを非構造化データと呼びます。

そして、企業が持つ情報のおよそ90%は、この非構造化データだと言われています（出典: 企業が持つ情報の90%は非構造化データ — Box Japan（IDC白書を引用））。
裏を返せば、AIに本当に聞きたいことの多くは、この9割のほうに眠っているのです。
にもかかわらず、その9割はAIのところまで届いていません。
だから、売上や件数のような数字なら答えられても、その数字の理由や経緯といった、数字以外のことを聞いたとたんに、AIは急に的外れな回答をしてしまう。
これが、自社のことになるとAIが頼りなくなる、いちばん根っこの理由です。

多くの会社のデータ基盤は、「構造化データ」に最適化されている

では、なぜ非構造化データはAIに届かないのでしょうか。
まずはその手前の、いま自社のデータがどこに、どう貯められているかを見てみる必要があります。

データ分析の土台として長く使われてきたのが、データウェアハウス（DWH）です。
社内のいろいろなシステムから数字を集め、集計や結合、大量のデータの読み出しに向くように整えた、分析専用のデータベースだと考えてください。
売上、在庫数、顧客リストのように、表計算ソフトの行と列にきれいに収まる構造化データを扱い、「先月、地域別でいちばん伸びた商品は」といった問いに、すばやくグラフで答えるのが得意です（出典: いまさら聞けない！「レイクハウス」とDWH、データレイクの違いとは — NTT DATA）。

ただ、DWHには成り立ちからくる得手不得手があります。
データ分析やAIのための基盤を提供する米国企業で、データレイクハウスを提唱したDatabricksは、従来のDWHについて「非構造化データや多様なデータを扱うのには向いておらず、扱えてもコストが高くつく」と整理しています（原文: "were not suited or were expensive for handling unstructured data, semi-structured data, and data with high variety, velocity, and volume." 出典: What is a Data Lakehouse? — Databricks）。

つまりDWHは、構造化データの分析にこそ力を発揮する一方で、議事録や契約書のような非構造化データは、もともと得意な分野ではないのです。

ここに、冒頭の落胆の正体があります。
自社のデータ基盤がDWHを中心に組まれていると、AIに聞ける範囲は、そのDWHに入っている構造化データの枠内に、自然と閉じてしまう。
数字で答えられることには強くても、「なぜ失注したのか」という、数字の表には残らない問いには、構造化データだけでは応えようがありません。
AIが一般論に逃げるのは、参照できる引き出しが、はじめから狭く区切られているからなのです。

3つの選択肢を整理する——DWH・データレイク・データレイクハウス

では、構造化に強いDWHを使いながら、非構造化データもAIに届けるには、どうすればよいのか。
ここで出てくるのが、データレイクと、データレイクハウスという選択肢です。
先ほどのDWHも含めて、3つを順に並べて整理します。

まず、これまで見てきたDWHは、構造化データをきれいに整理して分析するのが得意な一方で、議事録や契約書のような非構造化データは扱いにくい、というものでした。

次に、データレイクです。
これは、構造化データも非構造化データも、加工せずそのままの形で、ひとまとめに貯めておける保管場所です。
保存する時点ではデータの型を決めず、使うときに初めて整える——この「とりあえず全部入れておく」やり方を、スキーマオンリードと呼びます（出典: AWSにおけるデータレイクの基礎知識 — サーバーワークス）。
安く大量に、文章も画像も貯められるのが強みです。

ただ、自由さの裏返しの弱点もあります。
何でも入れられるぶん、いざ分析しようとすると目当てのデータが見つからない、品質の管理が行き届かず信頼できる数字を取り出しにくい、といった問題が起きやすい。
整理されないまま放置されたデータレイクが「データの沼（データスワンプ）」と呼ばれて敬遠されるのは、このためです（出典: データレイクとは — DWH、データマートとの違いと導入時の注意点 — 大和総研）。

そして、このDWHとデータレイクの「いいとこ取り」をしたのが、データレイクハウスです。
DWHの「整理して、信頼できる形で分析できる」強みと、データレイクの「構造化も非構造化も、安く大量に貯められる」強みを、一つの土台で両立させようという考え方で、Databricksが2020年に提唱し、広く知られるようになりました（レイクハウスと略されることもありますが、本記事ではデータレイクハウスで統一します）（出典: Evolution to the Data Lakehouse — Databricks）。
Databricksはこれを「データレイクの柔軟性・低コスト・スケールと、データウェアハウスのデータ管理・信頼性をあわせ持ち、あらゆるデータの上でBIと機械学習を実行できる、新しいオープンなアーキテクチャ」と定義しています（出典: What is a Data Lakehouse? — Databricks）。

おおまかには、これまでのDWHを、非構造化データまで扱えるように発展させたもの——いわばDWHの次の世代だと捉えると、分かりやすいかもしれません。

3つの違いを、表にまとめます。

※技術補足：技術的には、データレイクハウスは安価なストレージの上に、Delta LakeやApache Icebergと呼ばれる「テーブル管理の層」を重ね、データベースなら当たり前の整合性の担保（専門的にはACIDと呼ばれる仕組み）を後から持たせています。データを貯める部分と、計算する部分を切り離せるため、必要なときに必要なぶんだけ処理能力を足せる、という設計上の利点もあります。

なぜ「AI・生成AIを使いこなす土台」として、データレイクハウスなのか

ここまでは、データの貯め方の話でした。これがAI活用と、どうつながるのか。
鍵になるのが、RAG（検索拡張生成）という仕組みです。

RAGは、AIに質問が来たときに、まず社内のデータの中から関連しそうな情報を検索して取り出し、それをAIに渡したうえで答えさせる、という手順を指します。
AIに自社の資料をその場で参照させ、一般論ではなく自社の文脈で答えさせるために、いま広く使われている方法です（出典: RAG for structured data: the pitfalls of data lakes — K2view）。

つまりRAGの良し悪しは、「AIが何を参照できるか」、すなわち参照元のデータがどれだけ揃っているかに、そのままかかってきます。

データレイクハウスは、ここで力を発揮します。
構造化データの隣に、議事録や契約書といった非構造化データも一元的に置いておけるため、RAGの参照元として、両方をまとめてAIに供給できるのです（出典: AI Data Lakehouse — Architecture for AI Workloads — Lifebit）。
文章を検索しやすい形に変換しておく処理（細かく分割するチャンク化や、意味の近さで探せるようにするベクトル化と呼ばれる工程）も、同じ土台の上で行えます（出典: Enabling AI at Scale with Unstructured Data Integration and Governance — IBM）。構造化だけのDWHでは届かなかった9割の非構造化データにAIが届くようになる、というわけです。

具体的に、何ができるようになるのかを記載します。
たとえば「あの案件は、なぜ失注したのか」という問い。
データレイクハウスに商談の議事録、先方とのメール、提案書、見積りの履歴までが一元的に貯まっていれば、RAGはそこから当該案件に関する記録を拾い集め、AIは「価格よりも導入時期の条件が折り合わなかった」「決裁の直前に競合が別提案を出していた」といった、記録に裏打ちされた答えを返せるようになります。
一般論ではなく、自社の事実にもとづいた振り返りです。

あるいは、「なぜ昨年の第1四半期は、売上が落ちたのか」という問い。
売上の数字そのものはDWHでも分かりますが、その裏側にある理由——主力顧客の発注が止まった、ある地域で競合が値下げに動いた、大口案件の検収が翌期にずれ込んだ——は、当時の商談メモや日報、社内外のメールのやりとりの中にしか残っていません。
これらも一元的に貯まっていれば、AIは数字の増減と、その背景にある出来事を突き合わせて、「該当四半期の落ち込みは、特定の大口案件の検収時期がずれた影響が大きい」といった、筋の通った説明を返せるようになります。
経営者が知りたいのは多くの場合、数字そのものより、その数字が動いた理由のほうです。違いを生んでいるのは、AIが急に賢くなったことではなく、参照できるデータの範囲が構造化の枠を越えて広がったこと。
突きつめれば、それだけなのです。

DWHもデータレイクハウスも、ただの「箱」にすぎない

ここまで読むと、「では、自社もデータレイクハウスを入れさえすれば、すぐにAIが使えるようになるんだな」と思われたかもしれません。
けれど、ここで一つ、注意していただきたいことがあります。
基盤を入れることと、AIを使いこなせるようになることは、決してイコールではありません。

DWHであれデータレイクハウスであれ、それ自体は、データを入れておく「箱」にすぎない、ということです。
箱を立派にすること、つまり基盤を構築・導入すること自体が目的になってしまうと、待っている結末は、たいてい決まっています。
多大なコストをかけて基盤を整えたのに、誰もそれを使ってAIに問いを投げず、ただデータが溜まっただけの箱になる——というものです。

意味があるのは、箱を作ったその先です。
整えた基盤の上でAIに自社のことを問い、返ってきた答えから示唆を読み取り、そこで見えた課題を、実際の打ち手や業務の改善につなげる。
さらに、その結果として生まれた新しいデータをまた基盤に貯め、次の問いに活かしていく。この一連の流れを、現場の業務として回し続けて初めて、基盤への投資は報われます。
逆に言えば、この「使い続ける」運用が伴わないなら、どれだけ高機能なデータレイクハウスを入れても、宝の持ち腐れになりかねません。

まとめ——AIの回答の質は、参照できる社内データで決まる

AIが自社のことに的外れな答えしか返さないとき、まず疑うべきはAIの性能ではなく、AIが参照できる社内データの範囲です。

経営者が聞きたいことの大半は、議事録や契約書といった非構造化データにあるにも関わらず、多くの会社のデータ基盤は構造化データを中心に組まれており、AIに聞ける範囲が狭く閉じています。

だからこそ、構造化データと非構造化データを一元的に扱い、RAGの参照元としてAIに供給できるデータレイクハウスが、AI・生成AIを本当に使いこなすための土台として、これから必要になってくるのではないかと考えています。

とはいえ、急いで基盤を入れ替える必要はありませんし、基盤を構築すること自体がゴールでもありません。
DWH・データレイク・データレイクハウスの違いを押さえたうえで、本当に大事なのは、整えた箱を実際に使い、AIから得た示唆を課題解決や業務改善まで回し続けることです。

まずは「自社のAIが伸びないのは、データ基盤に原因があるのかもしれない」と社内で言語化できること。
そして、AIに聞きたいことを一つ決め、必要最低限のデータを使いながら広げていくこと。その一歩から始めてみてはいかがでしょうか。