データ基盤は作るべきか？DWH・データレイク導入を判断する4つの軸と「まだ作らなくてよい企業」の条件

経営層からデータ基盤の整備を求められたり、ベンダーからDWH（データウェアハウス：分析用に整理したデータを蓄積する仕組み）の提案を受けたりして、「まず基盤を作らなければデータ活用は始まらない」と考える場面があります。

この発想には一理あります。データが部門ごとに散在し、集計のたびに手作業が発生している状況では、基盤の整備が有効に働く場合があります。ただし、基盤を作ることと、データが意思決定に使われることは別です。利用の実態に比べて規模の大きい基盤は、構築費や運用負荷に見合う利用が伴わない状態を招く可能性があります。

最初に決めたいのは「どの製品を選ぶか」ではなく、「どの意思決定に、誰が、どの頻度で、どのデータを使うか」です。データ基盤の要否は、使い方から逆算して判断します。目安となるのは、利用ケース・利用頻度・利用人数・データ量の4つの軸と、データソース数などの補助軸です。

本記事では、DWH・データレイクなどの違いを整理したうえで、4つの軸による判断方法、架空の想定ケース、段階的な進め方、費用の見方、見直しのタイミングを解説します。導入しない、小さく始めるという選択肢と、作るべき条件を、同じ比重で扱います。

なぜデータ基盤は「目的化」しやすいのか

データ基盤の導入が目的化する背景には、次のような要因が重なっていることがあります。

「基盤があればデータ活用が進む」という前提が共有されている
提案の規模が、将来起こりうる最大の需要に合わせて設計されている
利用者・利用場面の整理が後回しになっている
導入そのものが、投資の成果として報告しやすい

ただし、これは大規模な基盤が不要という意味ではありません。複数部門で同じ指標を使う需要がすでに見えている場合には、先に整えたほうが手戻りが少ないこともあります。問題は基盤の大小ではなく、利用の実態と基盤の規模が対応しているかどうかです。データ基盤は、意思決定のための手段として位置づけると判断しやすくなります。

DWH・データレイク・データマートの違いを整理する

用語が混在したまま議論すると、提案の比較が難しくなります。まず基本的な違いを整理します。

DWH：業務データを分析しやすい形に整理して蓄積する仕組み。表の定義（スキーマ）を先に決めるのが基本です。
データレイク：加工前のデータを形式を問わず保管し、利用時に構造を与える仕組みです。
データマート：特定の部門や目的向けに切り出した、小規模な分析用データの集まりです。
レイクハウス：データレイクとDWHの特徴を併せ持たせる構成として提案されています（Armbrust et al., 2021）。

データの取り込み方にも違いがあります。ETL（抽出・変換・格納：取り込む前に加工する方式）と、ELT（抽出・格納・変換：格納してから加工する方式）です。クラウド型のDWHでは、保管（ストレージ）と計算（コンピュート）を分離し、使った分だけ課金する従量課金型が採られることがあります。この場合、利用が少ないうちは費用を抑えやすい一方、利用が増えると費用が変動しやすくなります。

種類	主な用途	向く規模の目安	運用負荷	コスト構造
軽量DB（DuckDB、PostgreSQLなど）	個人・小規模チームの結合や集計	数ファイル〜少数のテーブル、少人数	低め。ただし属人化に注意	製品費は抑えやすく、主に担当者の工数
データマート	部門内の共通指標の集計	1部門〜複数部門	中程度。定義と更新の管理が必要	構築・保守の工数と、利用環境の費用
DWH	全社横断の集計、指標の統一	複数のデータソース、多人数	高め。設計・権限・取り込みの管理	初期構築、利用料（従量課金型が多い）、運用保守
データレイク	生データの保管、多様な形式のデータの蓄積	大量・多様なデータ	高め。メタデータ管理が不足すると探索が難しい	保管費、処理費、管理の人材

判断の起点は「使い方」：4つの軸で見る

要否の判断では、次の4つの軸を最初に確認します。

利用ケース：どの意思決定や業務に使うのか。定型の集計か、探索的な分析か
利用頻度：月次、週次、日次、時間単位のどれで使うのか
利用人数：分析する人と、結果を閲覧する人は何人で、何部門にまたがるか
データ量：現在の量と、今後の増え方はどの程度か

注意したいのは、データ量だけで判断しないことです。データ量が少なくても、多くの部門が同じ指標を使い、数値の食い違いが問題になっている場合は、基盤の議論が必要になることがあります。反対に、データ量が大きくても、利用者が限られ、更新頻度が低ければ、大規模な構成が必須とは限りません。

すぐ試せる確認作業として、直近で実際に行っている分析やレポートの上位3件を選び、それぞれについて「利用ケース・頻度・人数・データ量」を1行ずつ書き出してみてください。書き出すだけでも、提案された基盤の規模と利用実態の差が見えやすくなります。

補助軸4つと判断チェックリスト

4つの軸に加えて、次の補助軸も確認します。

データソース数：システム、ファイル、センサー、Webログなど、取り込み元の数と種類
鮮度要件：バッチ処理（まとめて定期的に処理）で足りるか、ストリーミング処理（逐次処理）が必要か
結合の複雑さ：データ同士を結びつけるキーやコード体系がそろっているか
ガバナンス要件：ロールベースのアクセス制御（役割に応じた閲覧・操作権限）、監査ログ（操作の記録）、メタデータ管理（データの意味や出所の記録）、データカタログ、指標定義の管理が必要か

軸	まだ早い目安	検討段階の目安	作るべき目安
利用ケース	1〜2件の定型集計	部門内で複数。追加要望が出始める	複数部門で多数。新規の要望が続く
利用頻度	月次程度	週次	日次〜時間単位
利用人数	数名	10名前後、複数部門	数十名以上、全社
データ量	1台のPCで余裕を持って処理できる	処理に時間がかかり始める	継続的に増加し、1台では扱いにくい
データソース数	数種類以内、ファイル中心	5種類前後	10種類以上、センサーやWebログを含む
鮮度要件	月次・週次で足りる	日次更新が望まれる場面がある	時間単位以下の更新が業務に影響する
結合の複雑さ	少数のキーで結合できる	部門間でコード体系が異なる	指標の食い違いが頻発する
ガバナンス	ファイル単位の権限管理で足りる	部門ごとに閲覧範囲を分けたい	役割別権限、監査ログ、指標定義の全社管理が必要

表の目安は、判断を始めるための例示です。軸ごとに異なる列にまたがる場合は、低い段階から始め、不足が確認できた軸から補うという進め方も選択肢になります。

4つの軸で評価しても、部門によって答えが分かれることは珍しくありません。たとえば、ある部門は日次の数値を求め、別の部門は月次の整合性を重視する、といった状況です。その場合は、基盤の要否を議論する前に「どの意思決定に、どのデータが必要か」を整理する方法があります。

想定ケースA：月1回・3ファイルの会社の場合

ここからは、判断の考え方を示すための架空の想定例を取り上げます。特定企業の事例ではありません。

想定ケースAは、月1回、売上明細（CSV）、顧客マスタ（Excel）、商品マスタ（CSV）の3ファイルだけを分析している会社です。合計の容量は数十MB程度で、分析担当者は2名、結果を見るのは経営会議のメンバー数名とします。リアルタイム性は求められていません。この会社が、大規模DWHの導入を検討しているという設定です。

利用ケース：月次の売上分析が中心（まだ早い寄り）
利用頻度：月1回（まだ早い寄り）
利用人数：分析2名、閲覧は数名（まだ早い寄り）
データ量：数十MB程度（まだ早い寄り）

4つの軸がそろって「まだ早い」側にあるため、大規模DWHは過剰になりやすい構成です。この条件では、軽量な分析環境の整備や、データ定義・保存ルールの整備から始めるほうが適切である可能性が高いと考えられます。たとえば、次のようなコードで、3ファイルの結合と月次集計ができます。

import duckdb
import pandas as pd

# 顧客マスタ（Excel）はpandasで読み込み、DuckDBから同名で参照する
customers = pd.read_excel("customer_master.xlsx")

result = duckdb.sql("""
    SELECT strftime(s.order_date, '%Y-%m') AS month,
           p.category,
           c.region,
           SUM(s.quantity * s.unit_price) AS sales_amount
    FROM read_csv_auto('sales_detail.csv') AS s
    JOIN read_csv_auto('product_master.csv') AS p USING (product_id)
    JOIN customers AS c USING (customer_id)
    GROUP BY 1, 2, 3
    ORDER BY 1, 2, 3
""").df()

print(result.head())

import duckdb
import pandas as pd

# 顧客マスタ（Excel）はpandasで読み込み、DuckDBから同名で参照する
customers = pd.read_excel("customer_master.xlsx")

result = duckdb.sql("""
    SELECT strftime(s.order_date, '%Y-%m') AS month,
           p.category,
           c.region,
           SUM(s.quantity * s.unit_price) AS sales_amount
    FROM read_csv_auto('sales_detail.csv') AS s
    JOIN read_csv_auto('product_master.csv') AS p USING (product_id)
    JOIN customers AS c USING (customer_id)
    GROUP BY 1, 2, 3
    ORDER BY 1, 2, 3
""").df()

print(result.head())

Python

このコードは、ファイル名や列名を仮定した汎用的なサンプルです。DuckDBは、アプリケーションに組み込んで使う分析向けのデータベースで、個別のサーバーを立てずに利用できます（Raasveldt and Mühleisen, 2019）。本番運用を推奨するものではなく、この規模であれば大規模な基盤がなくても処理できる場合があることを示す例です。

この段階で価値が出やすいのは、ツールの追加よりも、ファイルの命名規則、保存場所、列名と単位の定義、更新日の記録といったルールの整備です。これらは、将来基盤を作る場合にも引き継げる資産になります。

ただし、これは大規模DWHが不要という意味ではありません。あくまでこの条件の会社に限った見立てであり、状況が変われば結論も変わります。見直しの条件は後述します。

想定ケースB・Cと判断マトリクス

比較のために、あと2つの架空の想定例を挙げます。

想定ケースBは、週次で分析し、データソースが5種類、3部門で分析者が10名程度いる会社です。月次集計に、毎月数日程度の工数がかかっています。手作業の削減と指標の共通化に需要があるため、まず部門単位のデータマートを検討し、部門をまたぐ指標定義がそろってから全社基盤を検討する、という段階的な進め方が考えられます。

想定ケースCは、日次〜時間単位で更新し、センサーやWebログを含む10種類以上のデータソースがあり、全社で数十名以上が利用する会社です。データ量は増え続け、部門間で指標の食い違いが頻発しています。この条件では、全社DWHやデータレイクの検討に値する要件がそろっています。ただし、構築すれば解決するわけではなく、指標定義、権限設計、運用体制の整備が並行して必要です。

利用頻度と利用人数による判断マトリクス（概念図）

想定ケースA〜Cは説明用の架空の例です。濃い背景ほど、検討するステージが大きくなる傾向を表します。

利用人数（縦）／利用頻度（横）

月次以下

週次

日次〜時間単位

数十名以上

該当する想定ケースなし

利用頻度：日次〜時間単位／利用人数：数十名以上

想定ケースC

10種類以上のデータソース。全社で利用し、指標の食い違いが頻発。

目安：ステージ3を検討

10名前後

該当する想定ケースなし

利用頻度：週次／利用人数：10名前後

想定ケースB

5種類のデータソース。3部門で分析し、月次集計に数日の工数。

目安：ステージ1〜2を検討

該当する想定ケースなし

数名

利用頻度：月次以下／利用人数：数名

想定ケースA

月1回、3ファイル。分析者2名、閲覧者は数名。

目安：ステージ0〜1から開始

該当する想定ケースなし

この図は概念図であり、セルの境界や配置が一律の基準を意味するものではありません。データ量や補助軸によって、実際の判断は変わります。

3つの例は、説明のために単純化したものです。この配置から結論を断定することはできません。同じ頻度と人数でも、ガバナンス要件やデータソースの性質が異なれば、別の判断になる場合があります。

段階的に進める4つのステージ

データ基盤は、「作る」か「作らない」かの二択ではありません。利用の広がりに応じて、段階的に整備する考え方があります。次の図は、その一例です。

データ基盤の段階的ステップ（概念図）

利用の広がりに応じて、必要な段階を見極めます。

ステージ0
表計算・共有フォルダ

向く状況少人数・月次程度で、ファイル数が限られる

主な取り組みファイル命名、保存場所、列定義のルール化
ステージ1
軽量DB・ローカル分析環境

向く状況結合や集計を再現できる形にしたい

主な取り組み集計手順のコード化、クエリの保存
ステージ2
部門データマート

向く状況部門内の複数人が同じ指標を使う

主な取り組み部門の指標定義、更新手順、閲覧権限
ステージ3
全社DWH・データレイク

向く状況複数部門、多数のソース、高頻度の更新

主な取り組み全社の指標定義、メタデータ管理、権限・監査ログ、運用体制

この図は概念図であり、すべての企業がステージ3を目指すべきことを意味しません。段階を飛ばす場合や、前の段階にとどまる場合もあります。

4つの軸の状況を整理する際に、簡易的な関数で目安を確認する方法もあります。次のコードは、各軸の入力値から段階を求め、最も高い段階を返す例です。

def suggest_stage(use_cases, per_month, users, data_gb):
    """4軸の入力から推奨ステージ（0〜3）の目安を返す。しきい値は説明用の例示値。"""

    def level(value, bounds):
        return sum(value >= b for b in bounds)  # 超えたしきい値の数がステージ

    levels = {
        "利用ケース数": level(use_cases, (2, 5, 10)),
        "月あたり利用回数": level(per_month, (2, 20, 100)),
        "利用人数": level(users, (8, 20, 40)),
        "データ量(GB)": level(data_gb, (1, 50, 500)),
    }
    return max(levels.values()), levels


stage, detail = suggest_stage(use_cases=1, per_month=1, users=5, data_gb=0.05)
print(stage)  # 0

def suggest_stage(use_cases, per_month, users, data_gb):
    """4軸の入力から推奨ステージ（0〜3）の目安を返す。しきい値は説明用の例示値。"""

    def level(value, bounds):
        return sum(value >= b for b in bounds)  # 超えたしきい値の数がステージ

    levels = {
        "利用ケース数": level(use_cases, (2, 5, 10)),
        "月あたり利用回数": level(per_month, (2, 20, 100)),
        "利用人数": level(users, (8, 20, 40)),
        "データ量(GB)": level(data_gb, (1, 50, 500)),
    }
    return max(levels.values()), levels


stage, detail = suggest_stage(use_cases=1, per_month=1, users=5, data_gb=0.05)
print(stage)  # 0

Python

しきい値は説明用の例示値で、実際の判断基準ではありません。この関数は重み付けをせず、最も高い軸の段階を返すだけです。1つの軸だけが高い場合は、他の軸や補助軸も合わせて確認する必要があります。自動判定の道具というより、議論の出発点として使うものです。

費用は何で決まるのか：TCOの構成要素

提案の費用を比較する際は、導入時の見積額だけでなく、TCO（総所有コスト：導入後の運用も含めて継続的にかかる費用の総額）の視点が必要です。本記事では具体的な金額には触れず、構成要素の見方を整理します。

構成要素	主な内容	見落としやすい点
初期構築	設計、環境構築、既存データの移行、取り込み処理の開発	見積に含まれる範囲と、含まれない範囲
利用料（従量課金）	保管量や計算量に応じた費用	利用が増えたときの変動と、上限の管理
運用保守	監視、障害対応、権限管理、定義変更への対応	導入後に継続して発生する
人材	設計・運用を担う担当者の確保	異動や退職による属人化
教育	利用者向けの操作説明、データや指標の理解の共有	利用者が増えるほど必要になる

提案を受ける際は、次の問いを確認すると、規模の妥当性を判断しやすくなります。

提案は、どの利用人数・頻度・データ量を前提にしているか
利用が想定より少なかった場合、多かった場合に費用はどう変わるか
導入後の運用は、誰がどの範囲を担うのか
小さく始めて、後から拡張することは可能か

見直しのタイミングと、判断の限界

「まだ早い」という判断は、恒久的な結論ではありません。次のような変化が見られたら、見直しの時期と考えられます。

データソースが増え、ファイルでの管理が追いつかなくなった
利用する部門や人数が広がった
更新頻度の要望が、月次から週次・日次へ上がった
部門間で指標の食い違いが起き、集計の工数が増えた

一方で、小さく始める判断にも限界があります。軽量な環境で個人が作った集計が属人化したり、定義がそろわないまま利用者が増えたりすると、後の移行が難しくなる可能性があります。これを避けるには、データの定義、命名、保存ルール、集計ロジックを、将来の移行に使える形で残しておくことが有効です。

反対に、需要が明確な場合に全社基盤を先行して整えることは、合理的な選択です。ケースCのように複数の軸が上位にそろっている場合に、段階を踏むことで部門ごとの仕組みが乱立すると、統合のコストが大きくなることもあります。要否の判断は、軸ごとの状況と今後の見通しを合わせて行う必要があります。

今すぐできる確認作業とチェックリスト

基盤の議論に入る前に、次の項目を確認してみてください。完璧に整備してから始める必要はなく、小さな範囲の確認から始められます。

実際に使っている分析・レポートの上位3件を、4つの軸で書き出した
各レポートを、誰がどの意思決定に使うかを説明できる
指標の定義（計算方法、対象範囲）が文書化されている
提案された基盤の規模と、利用実態の差を確認した
「導入する」「導入しない」「段階的に進める」の根拠を、3点程度で説明できる

よくある質問

データ量が少なければ、DWHは不要ですか。

データ量だけでは決まりません。データ量が少なくても、利用部門が多く、指標の統一やアクセス権限の管理が課題になっている場合は、部門データマートなどの検討が有効になることがあります。4つの軸と補助軸を合わせて確認してください。

データレイクとDWHは、どちらから作るべきですか。

利用目的によります。定型の集計や指標の統一が主な目的であればDWH側、多様な形式のデータを保管して将来の用途に備える場合はデータレイク側が候補になります。ただし、利用目的が決まらないまま保管だけを進めると、後から探索や品質確認の負担が増える可能性があります。

ベンダー提案の規模が妥当かは、どう確認しますか。

提案が前提としている利用人数・頻度・データ量を確認し、自社の実態と照らし合わせます。あわせて、小さく始めて拡張できるか、利用が増減した場合に費用がどう変わるかも確認してください。

軽量な環境から始めると、後で作り直しになりませんか。

作り直しが生じる場合はあります。ただし、データ定義、命名、保存ルール、集計ロジックは、基盤が変わっても引き継ぎやすい資産です。移行を見据えて、これらを文書やコードとして残しておくことが有効です。

まとめ

データ基盤の要否は、製品や流行からではなく、使い方から逆算して判断します。利用ケース・頻度・人数・データ量の4つの軸と、データソース数・鮮度要件・結合の複雑さ・ガバナンス要件の補助軸を確認すると、導入の要否と適切な段階が整理しやすくなります。

月1回・3ファイルのような小さな利用であれば、軽量な環境とデータ定義・保存ルールの整備から始める選択肢があります。一方、複数部門で高頻度に使い、指標の食い違いが起きている場合は、全社基盤を検討する条件がそろっています。どちらも、利用実態の確認が出発点です。

次に確認したいのは、直近の分析・レポートが「誰の、どの意思決定に使われているか」と、現在の基盤の提案がその実態に合っているかどうかです。

データ基盤は、作ること自体が目的ではありません。判断に迷う場合、経営層への説明根拠が必要な場合、部門間で要件が割れる場合には、利用実態の棚卸しから「今作るべきか、まだ早いか、どこから始めるか」を整理する方法があります。SCI総合研究所のRASHINRAは、導入しない選択や小さく始める選択も含めて、中立的な立場で判断を支援します。

RASHINRA｜経営データ活用・意思決定支援について詳しく見る

参考文献

Armbrust et al. 2021. Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics. Proceedings of the 11th Conference on Innovative Data Systems Research (CIDR 2021). https://www.cidrdb.org/cidr2021/papers/cidr2021_paper17.pdf
Raasveldt and Mühleisen. 2019. DuckDB: an Embeddable Analytical Database. Proceedings of the 2019 International Conference on Management of Data (SIGMOD). pp. 1981-1984. https://doi.org/10.1145/3299869.3320212