データ基盤の構築手順｜DWH・データレイクの使い分けから運用まで
売上、在庫、顧客、広告、Webアクセスなどのデータが部署ごとのシステムやExcelに散らばっていると、月次の数字をまとめるだけで数日かかったり、会議のたびに「どの数字が正しいのか」を確認する時間が発生したりします。こうした状態を解消する手段として検討されるのが、データを一か所に集めて分析しやすい形に整える「データ基盤」です。
一方で、データ基盤は「とりあえずDWHを契約してデータを入れる」だけでは定着しません。誰が何の判断に使うのかが決まっていないと、データは集まっても使われず、クラウドの費用だけが毎月発生する状態になりがちです。逆に、使い道が明確であれば、最初から大がかりな構成にしなくても小さく始められます。
データ基盤の構築で迷いやすいのが、DWH（データウェアハウス）とデータレイクの使い分けです。どちらも「データをためる場所」ですが、ためるデータの形と、使う人の想定が異なります。ここを曖昧にしたまま設計すると、後から作り直しが必要になることがあります。
この記事では、データ基盤を構成する要素の役割、DWHとデータレイクの使い分けの基準、構築の手順、規模や体制に応じた構成の選び方、運用で気をつけるポイントを、発注側の判断に使える形で解説します。
データ基盤を構成するデータレイク・DWH・データマートの役割
データ基盤は、ひとつの製品の名前ではなく、データを「集める」「ためる」「整える」「使う」ための仕組み全体を指します。一般的には、次のような層に分けて考えると全体像をつかみやすくなります。
| 層 | 役割 | 主なデータの形 |
|---|---|---|
| データソース | 販売管理、会計、CRM、広告、Webアクセス解析など、データが発生する元のシステム | 各システムの形式のまま |
| データ連携 | 元のシステムからデータを取り出し、基盤へ定期的に送り込む | ファイル、APIの応答、DBの抽出結果 |
| データレイク | 加工前のデータを、そのままの形で大量に保管する | CSV、JSON、ログ、画像など構造がまちまちなデータ |
| DWH | 分析しやすいように整理したデータを保管し、SQLで集計する | 列と型が決まった表形式のデータ |
| データマート | 特定の部署や用途向けに、必要な項目だけを集計・抽出した小さな表 | レポートやダッシュボードに直結する集計表 |
| BI・活用 | ダッシュボード、レポート、機械学習、業務システムへの連携 | グラフ、指標、予測結果 |
すべての層を最初から用意する必要はありません。扱うデータが販売管理と会計の表形式データだけなら、データレイクを置かずにDWHへ直接取り込む構成で十分なことも多いです。反対に、Webのアクセスログやセンサーデータのように量が多く形も揃っていないデータを扱うなら、加工前の状態で保管しておく場所としてデータレイクが役に立ちます。
発注や社内検討の場面では、製品名から入るよりも「どの層が自社に必要か」から整理したほうが、見積もりの比較や費用の妥当性を判断しやすくなります。
DWHとデータレイクはどう使い分けるか
DWHは、あらかじめ列や型を決めた表にデータを入れ、SQLで高速に集計することを得意とします。データレイクは、形を決めずに何でも保管できる代わりに、使うときに中身を解釈して整える手間がかかります。両者は対立するものではなく、役割分担で考えるのが基本です。
| 判断の観点 | DWHを中心にする | データレイクを併用する |
|---|---|---|
| 扱うデータ | 販売、会計、顧客など表形式の業務データが中心 | ログ、JSON、画像、音声など形が揃わないデータが多い |
| データ量 | 業務システム由来で、増え方が予測しやすい | アクセスログや機器データなど、日々大量に増える |
| 使う人 | 経営者や事業部門が、決まった指標を定期的に見る | データ分析者や機械学習の担当者が、生データから試行錯誤する |
| 用途の確定度 | 見たい指標がほぼ決まっている | 将来の分析に備えて、加工前の状態でも残しておきたい |
| 社内の体制 | 専任のデータエンジニアがいない | データを整える役割の担当者を置ける |
中小〜中堅企業で、まず月次の売上や粗利、在庫回転などを正しく見たいという目的であれば、DWHを中心に据え、必要になった時点でデータレイクを追加する順番が現実的です。データレイクは「とりあえず全部ためておく」使い方をすると、何がどこにあるのか誰も分からない状態になりやすく、整理のコストが後から膨らみます。
一方、機械学習で需要予測をしたい、Webの行動ログを細かく分析したいといった目的があり、元データをそのまま残す必要があるなら、最初からデータレイクを設けておく価値があります。その場合も、保管する場所のルール（フォルダ構成、ファイル名、保存期間）を決めてから使い始めることが前提です。
レイクハウスという選択肢
最近は、データレイクに置いたファイルに対してDWHのようにSQLで集計できる「レイクハウス」と呼ばれる構成も広がっています。DWHとデータレイクを別々に持つ手間を減らせる一方で、ファイルの管理方式やテーブル形式への理解が必要になります。社内に運用できる担当者がいない場合は、まずDWH中心で始め、データ量や用途が増えてから検討しても遅くありません。
データ基盤の構築手順
データ基盤の構築は、ツールの選定から始めるのではなく、使い道の確認から始めます。おおまかな手順は次のとおりです。
1. 判断に使う指標と利用者を決める
最初に、誰がどの判断のために、どの数字を、どの頻度で見たいのかを書き出します。「経営会議で毎週、商品カテゴリ別の粗利を見る」「営業部長が毎朝、案件の進捗を見る」のように、利用者と場面まで具体的にすることが大切です。ここが決まると、必要なデータソース、更新頻度、集計の粒度が自然に決まります。
2. データソースと現状のデータ品質を棚卸しする
指標を作るために必要なデータが、どのシステムにどんな形で入っているかを確認します。あわせて、顧客コードの表記揺れ、部署ごとに異なる商品分類、手入力の欠損といった品質の問題を洗い出します。データ基盤の工数の多くは、実はこの「揃っていないデータを揃える」作業にかかります。
3. 構成と製品を選ぶ
必要な層とデータ量、社内の体制をもとに、DWHやデータ連携ツール、BIツールを選びます。すでにGoogle WorkspaceやGoogle広告を使っているならGoogle Cloud系、Microsoft 365やAzureを使っているならMicrosoft系、といったように、既存の契約や認証基盤との相性も判断材料になります。
4. 小さな範囲で取り込みと集計を作る
最初からすべてのデータを取り込もうとせず、手順1で決めた指標のうち優先度の高いものに絞って、取り込みから集計、ダッシュボード表示までを一通り作ります。ここで実際の利用者に見てもらい、数字が既存の帳票と一致するか、見たい切り口になっているかを確認します。
5. 対象データと利用者を広げる
最初の範囲が業務で使われ始めてから、データソースや指標を追加していきます。追加のたびに、指標の定義（たとえば「売上」は税込か税抜か、返品を含むか）を文書に残しておくと、部署ごとに数字が食い違う問題を防げます。
6. 運用ルールを決めて引き継ぐ
データ連携が失敗したときに誰が気づき、誰が対応するのか、新しい項目を追加したいときにどこへ依頼するのかを決めます。外部の開発会社に構築を依頼する場合も、運用手順書と障害時の連絡経路を納品物に含めておくと、担当者が替わっても基盤が止まりません。
規模と体制で変わる構成の選び方
同じ「データ基盤」でも、会社の規模や社内の体制によって適した構成は変わります。大きく分けると、次の3つのパターンで考えると判断しやすくなります。
| 状況 | 向いている構成 | 注意点 |
|---|---|---|
| データソースが数個で、見たい指標が決まっている。社内にデータ担当者がいない | DWHと既製のデータ連携ツール、BIツールの組み合わせ。データレイクは置かない | 連携ツールが対応していないシステムは、CSV出力や個別開発が必要になる |
| データソースが多く、ログなど大量データもある。兼任でもデータ担当者を置ける | データレイクとDWHを併用し、変換処理をコードで管理する | 変換処理の管理方法を決めないと、担当者しか分からない処理が増える |
| 機械学習や外部へのデータ提供など、分析以外の用途もある | データレイクを中心に、DWH、特徴量の管理、APIなどを組み合わせる | 構成が複雑になるため、設計と運用を担う技術パートナーとの継続的な体制が必要 |
判断の目安として、社内に運用できる人がいないなら、構成要素を減らしてマネージドサービスに寄せるほうが安全です。自前で組み合わせた構成は柔軟ですが、その分だけ保守の手間がかかります。反対に、扱うデータの種類が多く、既製のツールでは対応できない連携が多いなら、個別開発の比率を上げたほうが総コストは下がることがあります。
当社が関わった不動産販売業者向けの物件データ収集基盤では、データの持ち方とクエリを見直し、機械学習で処理対象を事前に絞り込むことで、データ処理コストを80%削減しつつ抽出できる物件数を2倍にしました。データ基盤のコストは製品の選択だけでなく、データをどう持ち、どう処理するかの設計で大きく変わります。
外部に構築を依頼するときに確認したいこと
データ基盤の構築を開発会社に依頼する場合、見積もりの金額だけで比較すると、後から運用の負担や追加費用が見えてくることがあります。提案を受けた段階で、少なくとも次の点を確認しておくと判断しやすくなります。
- クラウドの利用料金の見込みを、データ量と利用者数の前提つきで示しているか
- データ連携が失敗したときの検知方法と、復旧の手順が提案に含まれているか
- 変換処理や指標の定義が、担当者以外にも読める形で残されるか
- 納品後に指標やデータソースを追加する場合、どこまで自社で対応できる設計か
これらに具体的に答えられる提案は、構築後の運用まで見据えて設計されている可能性が高いといえます。反対に、製品の機能説明が中心で運用の話が出てこない場合は、構築後に誰が面倒を見るのかを改めて確認しておくべきです。
運用で差が出るポイント
データ基盤は、構築した時点がスタートです。使われ続ける基盤と使われなくなる基盤の差は、主に運用の設計で生まれます。特に押さえておきたいのは次の点です。
- 指標の定義を一か所にまとめ、BIツールごとに計算式がばらばらにならないようにする
- データ連携の失敗や件数の急減を自動で検知し、担当者に通知する
- テーブルやデータセットごとに、管理者と利用者、保存期間を決めておく
- 個人情報を含むデータは、閲覧できる人を絞り、アクセス権限を定期的に見直す
- クラウドの利用料金を月次で確認し、急増した場合の確認手順を決めておく
この中でも見落とされやすいのが費用の管理です。クラウドのDWHは、データ量やクエリの実行量に応じて費用が増える料金体系が多く、ダッシュボードの更新設定やクエリの書き方次第で、同じデータでも費用が大きく変わります。予算の通知を設定し、毎月の請求額と主な費用の内訳を確認する担当者を決めておくことが、最低限の備えになります。
もうひとつは、利用者からの要望の受け付け方です。「この項目も見たい」という要望に都度対応していると、似たようなテーブルやダッシュボードが乱立します。要望は一か所で受け付け、既存の指標で代替できないかを確認してから追加する流れを作っておくと、基盤が複雑になりすぎるのを防げます。
まとめ
データ基盤は、データを集める、ためる、整える、使うための仕組み全体です。DWHは整理済みの表形式データを集計する場所、データレイクは加工前のデータを形を問わず保管する場所であり、扱うデータの種類と社内の体制によって使い分けます。表形式の業務データが中心で専任の担当者がいないならDWH中心で始め、ログや機械学習の用途が出てきた段階でデータレイクを追加する順番が現実的です。
構築は、判断に使う指標と利用者を決めるところから始めます。明日できることとしては、自社で毎月手作業で集計している数字を書き出し、それぞれ誰が何の判断に使っているのか、元データはどのシステムにあるのかを一覧にしてみてください。その一覧が、データ基盤の範囲と優先順位を決める出発点になり、開発会社に相談する際の資料としてもそのまま使えます。