データレイクとウェアハウスの違い｜AIに渡す前の置き場選び

「AIに分析させたいのに、どのデータがどこにあるのか誰も答えられない」「データレイクを用意したのに、結局みんな元のシステムから抜いて表計算に貼っている」——分析の土台を作ろうとした会社が、決まって一度は通る場所です。大手クラウド事業者の比較資料は、大規模な組織のほとんどがデータレイク・データウェアハウス・データマートの3つを組み合わせて使っており、まずレイクに取り込んでから用途ごとにウェアハウスやマートへ流す形が通例だと整理しています。つまりこれは、3つのどれか1つを選ぶ問題ではありません。本当は、どのデータをどの型に置き、どの型から生成AIに渡すのかを決める問題です。この記事では、3つの型の構造と費用の違い、置き場の決め方、移す順番と失敗を順に見ていきます。

データの置き場が3つに分かれる理由

分析の土台を作ろうとすると、必ず3つの名前が出てきます。データレイク、データウェアハウス、データマート。これは製品の名前ではなく、データの置き方の型の名前です。同じクラウドの上に、同じ製品で、3つとも作れます。だから「どれを買うか」という問いの立て方をすると、いつまでも決まりません。

3つが分かれる理由は一つに絞れます。データの形をいつ決めるかです。入れる前に列と型を設計してから流し込むのか、そのまま放り込んで読み出すときに解釈するのか。大手クラウド事業者の比較資料では、前者を「スキーマオンライト」、後者を「スキーマオンリード」と呼び分けています。

この一点が、後のすべてを決めます。先に形を決めれば読むのは速く、誰が見ても同じ数字になります。かわりに、決めた形に収まらないものは入りません。議事録、通話の音声、問い合わせの文面、画像は行と列に収まりません。逆に形を後回しにすれば何でも入りますが、整える手間が読む側に後払いで回ってきます。速さと自由度のどちらを先に取るか。その選択の結果が、3つの名前になっているだけです。

データレイクは「そのまま置く」置き場

データレイクは、データの構造や種類にかかわらず、集めたものをそのままの形式で置ける置き場です。表形式の構造化データ、半構造化データ、それに画像や音声のような非構造化データを、区別せずに受け入れます。集めるもとになるシステムの数にも事実上の上限がありません。

費用の形にも特徴があります。大手クラウド事業者の資料は、レイクの特徴として「低コストのストレージと、コンピューティングとストレージの分離」を挙げています。噛み砕くと、置いておくだけなら安く、読むときに計算資源を別に立てて払う構造です。だから、めったに読まないが捨てられない大量のデータを持つ用途に向きます。動画や画像を大量に抱える会社が最初にレイクを検討するのは、この費用の形が理由です。

見落としやすいのが、使う人の顔ぶれです。同じ資料では、レイクの利用者としてデータエンジニア、データアーキテクト、データサイエンティスト、そして「キュレートされたデータを使うビジネスアナリスト」が挙げられています。つまり整えられていない状態のまま全社に開放する置き場ではありません。向く分析も、機械学習、探索的分析、データの発見、ストリーミングなど、答えの形が事前に決まっていない仕事です。

もう一つ、レイクを設計するときに効く原則があります。マイクロソフトの技術文書は、生データの層を「アナリストやデータサイエンティストが直接アクセスするためのものではなく、次の層のデータを強化する処理が読むためのもの」と位置づけています。あわせて、増分で足していくので容量は時間とともに増え続けること、すべての履歴を保持することで再処理と監査ができるようになることも挙げています。つまりレイクの価値は「今すぐ読めること」ではなく「後からやり直せること」にあります。ここを取り違えてレイクを分析画面の直結先にすると、読む人ごとに整え方が変わり、同じ問いの答えが散らばります。

データウェアハウスは「整えてから置く」置き場

データウェアハウスは、分析と業績の可視化のために前処理を済ませたデータの中心的な置き場です。基幹の取引システムや業務アプリから吸い出したデータを、テーブルの形に構造化し、あらかじめ設計した形に当てはめて持ちます。集めるもとは多数のシステムで、それらが一箇所に統合されます。

性格を一言で言えば「全社で同じ数字を見るための置き場」です。大手クラウド事業者の資料は、ウェアハウスのデータを「高度にキュレートされたデータで、事実の情報源として機能する」と表現しています。データは要約ではなく完全で詳細な状態で持ち、範囲は集中化され、複数の対象領域が統合されている。だから部署をまたいで数字を突き合わせる場面で強いのです。規模の目安は、同じ資料で数百ギガバイトからペタバイトとされています。

費用は、レイクとちょうど逆の形になります。入れる前に整える工程に手間と処理費用が先にかかり、そのぶん読み出しは速い。同資料も、ウェアハウスは「ローカルストレージを使用し、問い合わせ結果の取得は最速」と整理しています。なお近年のクラウド型のウェアハウスでは、先に入れてから置き場の中で変換する順番が主流になっているとされます。整える工程が消えたわけではなく、整える場所が手前から中に移ったと理解するのが実態に近いです。

データマートは「目的に絞って切り出す」置き場

データマートは、利用目的や利用部門に応じて、必要なデータだけを抜き出して加工し、置いておく置き場です。財務、マーケティング、営業といった特定の部門のために作られ、集めるもとは1つか少数に限られます。要約された状態のデータを持つこともできます。

特徴は範囲の狭さです。大手クラウド事業者の資料は、マートの範囲を「集中化されていない、特定のサブジェクト領域」、利用者を「単一のコミュニティや部署」、規模を「小規模。通常は最大数十ギガバイト」と整理しています。設計の向きも逆で、ウェアハウスはトップダウン、マートはボトムアップです。全体像から降りてくるのではなく、目の前の部門の問いから積み上げるのがマートです。

技術としては、マートはウェアハウスと同じ仕組みを使うことが多く、同資料は「同じテクノロジーを指す別の呼び名」だとまで書いています。つまり違いは技術ではなく範囲と目的です。ここを混同すると「マートを作るために新しい製品を買う」という無駄な検討が始まります。多くの場合、マートはすでにあるウェアハウスの中に別のスキーマを切るだけで作れます。

3つを1枚で見比べる

ここまでの違いを1枚にまとめます。表の値は大手クラウド事業者の比較資料の整理をもとにしています。数字の大小より、行ごとに性格が反転していることに注目してください。

見る点	データレイク	データウェアハウス	データマート
入れるもの	構造化・半構造化・非構造化のすべて	業務システムのリレーショナルデータ中心	目的に絞って抜き出した加工済みデータ
形を決める時点	読み出すとき（スキーマオンリード）	入れる前に設計するのが基本	切り出す時点で用途に合わせて決める
集めるもとの数	事実上の上限なし	多数のシステムを統合	1つか少数
規模の目安	画像や動画を含む大容量に向く	数百ギガバイトからペタバイト	小規模・通常は最大数十ギガバイト
主に使う人	データの技術者と分析の専門職	全社のアナリストと開発者	単一の部署
向く仕事	機械学習・探索・データの発見	全社共通のレポートと可視化	部門の定型分析と判断
費用のかかり方	保管は安く、読むたびに計算代	整える工程に先払い、読むのは速い	小さく安いが数が増えると保守が重い

この表の使い方は「どの列を選ぶか」ではありません。自社のデータを行ごとに当てはめて、必要な列が何列あるかを数えるのが正しい使い方です。非構造化のものが一切なく、使うのが1部署だけなら、必要な列は1つで足ります。逆に、議事録も動画も抱えていて、全社共通の数字も必要なら、3列すべてが必要になります。

費用は「何に払うか」が違う

置き場の費用を比べるとき、多くの会社が単価表を並べます。しかし実務でずれるのは単価ではなく、何に対して課金されるかという費目の形です。データの置き場の費用は、大きく3つの費目に分かれます。置いておく代（保管）、読む代（計算）、そして整える代（処理と人の時間）です。

この3費目の比重が、型ごとにはっきり違います。レイクは保管が安く、読むたびに計算代がかかり、整える代は読む側に後払いで乗ります。ウェアハウスは整える代を先に払い、読むのが速いので読む回数が多いほど有利になります。マートは範囲が小さいので保管も計算も安いのですが、数が増えるほど「定義の保守」という見えない費目が重くなります。同じ商談数を5つのマートが別々に計算していれば、その5つを合わせ続ける仕事が毎月発生します。

もう一つ、稟議の段階で見ておくべきものが費用の按分です。課金の単位が問い合わせ単位だと、どの部署がいくら使ったかを後から分けるのが難しくなります。計算資源の単位で課金されるなら、部署ごとに資源を立てて費用を分けられます。ここは製品によって仕組みが違うため一律には言えませんが、社内で費用を分担する予定があるなら、単価より先に課金の単位を確認するほうが後で揉めません。

取り込む頻度が費用を決める

費用を動かすつまみは、型の選択だけではありません。マイクロソフトの技術文書は、レイクハウスの設計の中で取り込みの頻度が費用と遅れを決めるという関係を、はっきり表にして示しています。同じデータ量でも、入れ方で費用が変わるということです。

取り込みのしかた	費用	データが届くまでの遅れ
絶えず少しずつ入れ続ける	高い	小さい
きっかけを決めて少しずつ入れる	低い	中くらい
時間を決めてまとめて入れる	低い	最も大きい

この表が効くのは、要件を決める場面です。「リアルタイムで見たい」という要望は必ず出ますが、絶えず入れ続ける形は費用が最も高く、しかも鮮度が上がっても判断が速くなるとは限りません。月次で振り返る指標をリアルタイムにしても、意思決定は月に一度のままです。

実務では、指標ごとに必要な鮮度を先に決めます。当日中に手を打つ指標だけを短い間隔にし、週次と月次で見る指標はまとめて入れる。鮮度の要件を指標ごとに書き分けるだけで、取り込みの費用は目に見えて下がります。逆に、全部を同じ頻度でそろえると、要らない鮮度に毎月払い続けることになります。

誰が触る置き場なのかで決まる

型を選ぶとき、規模より効く判断軸があります。その置き場を誰が触るのかです。マイクロソフトの技術文書は、層ごとの想定利用者を明記しています。生データの層はデータエンジニア、運用担当、そしてコンプライアンスと監査のチーム。検証済みの層はデータエンジニア、データアナリスト、データサイエンティスト。集計済みの層はビジネスアナリストと可視化の開発者、データサイエンティストと機械学習の担当者、役員と意思決定者、そして運用チームです。

この対応表は、権限設計の下敷きとしてそのまま使えます。経営会議で見る数字は集計済みの層に置く。機械学習に食わせる学習データは検証済みの層から取る。監査で「元はどうだったか」を追う必要があるものは生データの層に残す。層の名前ではなく、閲覧できる人の範囲が層の意味です。

逆の失敗も分かります。生データの層を全社に開けると、同じ問いに対して人によって違う数字が出ます。重複も未検証の値もそのまま入っているので、切り口が少し違うだけで結果が変わるからです。数字が合わない問題の半分は、開放してよい層を決めていないことから起きます。置き場の設計は、実は誰に何を見せるかの設計と同じものです。

レイクハウスと呼ばれる形の現在地

ここ数年、レイクとウェアハウスを別々に持つのではなく、レイクの安さと柔軟さの上にウェアハウスの整え方を載せる形が広く採られるようになりました。レイクハウスと呼ばれる形です。置き場を2つ持って同じデータを二重に抱える無駄を避けられるのが利点です。

その中でよく使われる整理が、メダリオンアーキテクチャです。マイクロソフトの技術文書によれば、これはデータを論理的に整理するための設計パターンで、ブロンズ（未加工）、シルバー（検証済み）、ゴールド（エンリッチ済み）の順に品質を段階的に上げていきます。マルチホップアーキテクチャとも呼ばれます。各層で起きることは、生データの取り込み、データのクリーニングと検証、そして集計とモデリングです。同じ製品の中に、性格の違う3つの置き場を作るという発想です。

ここで押さえておきたい留保があります。同じ文書は「メダリオンアーキテクチャに従うことを推奨するが、必須条件ではありません」と明記しています。3層でなければならない決まりではなく、実際に人事・財務・情報システムなど目的ごとに複数の集計層を作る例もあります。名前と層数をそろえること自体が目的ではありません。目的は、目の前のデータがどの段階の品質なのかを人が判別できることです。この一点が守れていれば、層が2つでも4つでも設計としては成り立ちます。

層を分ける利点は、同じ計算を何度も組み直さずに済むことにもあります。同文書は、週ごとの予約や売上を問われるたびに各自が同じ集計を作り直さないよう、あらかじめ集計した表を集計層に用意しておく例を挙げています。集計層に含まれるデータセットの数が、生データの層や検証済みの層より少なくなるのはこのためです。よく使われる形だけに絞って作り置きしておく場所だからです。逆に、問われるたびに新しい集計表を足していくと、集計層そのものが誰も把握できない数に膨れ、どれが正しいのか分からなくなります。

生成AIに渡すのはどの層か

ここが、置き場選びが分析基盤の話から生成AIの話に変わる分岐点です。同じ会社のデータでも、どの層を渡すかで答えの質がはっきり変わります。RAGのように社内データを参照させる仕組みを作るとき、参照先の指定はモデルの選定より効きます。

渡してはいけないのは生データの層です。マイクロソフトの技術文書は、この層では「データのクリーンアップや検証は実行されません」と明言しています。重複も、値の空欄も、遅れて届いた記録もそのまま入っています。ここを参照させると、同じ取引が二重に数えられた数字を、AIは平然と答えます。しかも根拠として実データを示すため、読む側は疑いません。

集計済みの層も、それだけでは足りません。集計は元の1件を消す操作なので、「先月の売上は」には答えられても「なぜ落ちたのか」には答えられません。理由をたどるには、集計前の1件が残っている必要があります。同文書はシルバー層の要件として「常に、各レコードの少なくとも1つの検証済みの非集計表現を含める必要があります」と書いています。検証は済んでいて集計はしていない層こそが、生成AIに渡す前段として都合がよいのです。

履歴の扱いも同じ考え方になります。同文書は「大量の履歴データは通常シルバー層でアクセスされ、ゴールドレイヤーでは具体化されません」としています。数年分を横断させて傾向を聞きたいなら、参照先は集計層ではなく検証済みの層です。集計層に履歴を全部持たせようとすると、保管と再計算の費用が膨らむだけで、AIの回答も良くなりません。

AIに判断させない範囲を先に決める

置き場が整うと、「あとはAIが判断すればいい」という話が必ず出ます。ここで線を引いておかないと、後から戻せなくなります。AIに任せてよいのは、どのデータを見に行くかの絞り込みと、出てきた集計結果の言い換えまでです。それ以上を渡すと、間違いに気づく仕組みがなくなります。

任せてはいけないものは3つに絞れます。指標の定義を決めること。数字の異常を「問題なし」と判定すること。データの欠けを推測で埋めること。特に危ないのが3つめです。生成AIは、空欄を空欄のまま返すよりも、もっともらしい値を入れて滑らかな文章にするほうが得意です。取れていない期間は取れていないと書かせるには、そう書くよう先に指示し、根拠として使った件数と期間を必ず添えさせる必要があります。

そのうえで、人が確認する範囲を先に決めます。次の3つの場面は、置き場を作る段階で承認の手順に入れておくと、後から定義が静かに動く事故を防げます。

• 指標の定義を変えるとき：商談数や有効リードの数え方を変える判断は人が持つ
• 集計の対象期間や除外条件を変えるとき：テスト取引の除外なども含めて記録を残す
• 社外に出す数字を作るとき：提案書や公表資料に載る数字は必ず人が元データまで戻って確認する

この3つを決めずに置き場だけ作ると、数か月後に「去年と数字が合わない」という調査が始まります。置き場の設計と同時に決めるべきなのは、技術ではなく承認の線引きです。

規模と用途から型を選ぶ3つの問い

ここまでを判断に落とします。実務では、次の3つの問いに答えるだけでほぼ決まります。置き場の絵から考えず、扱うものと使う人から逆算するのが要点です。

1. 扱うデータに、行と列に収まらないものが含まれるか（議事録・通話の音声・画像・動画・問い合わせの文面など）
2. 部署をまたいで同じ数字を見る必要があるか（会議で突き合わせる指標があるか）
3. 使うのは1部署だけで完結するか（他部署が同じデータを別の目的で見るか）

1つめが「ある」ならレイクが必要になります。2つめが「ある」ならウェアハウスが必要です。3つめが「完結する」ならマートで足ります。多くの会社では複数に当てはまり、そのときは組み合わせが答えになります。大手クラウド事業者の資料も、大規模な組織のほとんどが3つを組み合わせ、まずレイクに取り込んでから用途ごとにウェアハウスやマートへ流す形が通例だと整理しています。

逆の判断も同じくらい重要です。扱うものが基幹システムのリレーショナルデータだけで、量も数十ギガバイトに収まり、使うのがマーケティング部門だけなら、レイクを作る理由はありません。同資料も、顧客データや業務プロセスのデータのようなリレーショナルデータを保存する場合はウェアハウスのほうが適していると書いています。規模が伴わないうちに「まずレイク」を選ぶと、読まれない置き場だけが残ります。これがデータの沼と呼ばれる状態です。

移す順番

型が決まったら、作る順番です。ここを間違えると、費用も手戻りも一気に増えます。問いから始めて、生のまま置く層を飛ばさないのが原則です。

順番の失敗として最も多いのが、3つめを飛ばして2から4に進むことです。マイクロソフトの技術文書も、取り込みから直接検証済みの層に書き込むことは推奨せず、その理由として送り元のスキーマ変更や壊れたレコードでエラーが起きることを挙げています。生のまま置く層は、やり直しと監査のための保険です。ここを省くと、事故が起きたときに戻る場所がありません。

置き場づくりでよくある失敗

最後に、実際につまずきやすい形を並べます。どれも、置き場の絵を先に描いたことから始まります。

• 全社レイクを先に作る：答えたい問いが決まっていないので誰も読まず、置いただけのデータの沼になる
• 部署ごとにマートが乱立する：同じ商談数が別の定義で計算され、会議で数字が合わない状態が常態化する
• 集計済みの層に履歴を全部持たせる：保管と再計算の費用が膨らむうえ、理由をたどる粒度は戻らない
• 取り込みから直接検証済みの層に書く：送り元の形が変わると止まり、やり直すための元データが残っていない
• 最初から全部リアルタイムにする：鮮度が要らない指標にも、絶えず入れ続ける費用を毎月払い続ける

並べてみると、共通の原因が見えます。置き場の図が整っているほど、その図に「誰のどの問いに答えるか」が一行も書かれていないことが多いのです。データの沼は容量の問題ではなく、問いの不在から生まれます。

防ぎ方も一つです。置き場を作る稟議に、答えたい問いを3つと、その数字を毎月見る人の名前を書いておく。読む人が決まっているデータは沼になりません。逆に、読む人が決まっていないデータをいくら整えても、費用だけが増えます。

実務仕様の一覧

検討の場で確認を求められる項目を、出典が確かめられたものだけ並べます。数値や層の呼び名は、そのまま社内資料の脚注に使える粒度にしてあります。

• 形を決める時点：入れる前に決める（スキーマオンライト）と、読むときに決める（スキーマオンリード）の2通り。レイクは後者
• 変換の順番：入れる前に整えるETLと、入れてから中で整えるELT。クラウド型のウェアハウスでは後者が主流とされる
• 規模の目安：ウェアハウスは数百ギガバイトからペタバイト、マートは通常最大数十ギガバイト（大手クラウド事業者の整理）
• 層の呼び名：ブロンズ（未加工）・シルバー（検証済み）・ゴールド（エンリッチ済み）。マルチホップアーキテクチャとも呼ぶ
• 生データ層の格納方針：ほとんどの項目を緩い型で持つことが推奨される。送り元の形が変わってもデータを落とさないため
• 検証済み層で行うこと：スキーマの適用、値の空欄の処理、重複除去、遅れて届いたデータの解決、型の変換、結合
• 取り込み頻度と費用：絶えず入れ続ける＝費用が高く遅れが小さい、きっかけ式とまとめて入れる＝費用は低く遅れが大きい
• 費用の確認順：単価より先に課金の単位を見る。部署ごとに費用を分けられるかが変わる（仕組みは製品ごとに異なる）

この一覧のうち、社内で議論が割れやすいのは最後の2項目です。技術の議論に見えて、実は予算と組織の議論になっているためです。取り込み頻度と課金の単位は、決めた後で変えると作り直しが発生します。設計の初期に、情報システム部門と予算を持つ部門が同席して決めておくのが安全です。

まとめ

データレイク・データウェアハウス・データマートの違いは、容量ではなくデータの形をいつ決めるかの違いです。読むときに決めるレイクは何でも入るかわりに整える手間が読む側に回り、入れる前に決めるウェアハウスは全社で同じ数字を見るのに強く、範囲を絞るマートは部門の判断を速くします。多くの会社では3つの組み合わせが答えになり、まずレイクに入れて用途ごとに切り出す形が通例です。そして生成AIに渡すのは、検証済みで集計前の層。生データは重複が残り、集計済みは理由をたどる粒度が消えています。まずは、毎月必ず聞かれている問いを3つ書き出し、その答えに必要なデータがどのシステムに何種類あるかを数えるところから始めてください。置き場の絵は、その後で描くほうが安く済みます。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。