本文へスキップ

データ・分析基盤

データウェアハウスとは

でーたうぇあはうす / DWH

業務システムなどのデータを収集し、過去分を含めて集計可能な形で蓄積する分析用のデータベースです。基幹システムの集計表とExcelで履歴の保持・処理速度・管理の要件を充足できているなら、早期に導入する必要はありません。

公開
2026.10.27
更新
2026.10.27
データウェアハウス

データウェアハウスとは

DWH(Data Warehouse)は、業務システムなどのデータを収集し、意思決定のための分析に適合する形式で蓄積するデータベースです。
たとえば受注、会計、顧客管理のデータを毎晩収集し、過去数年分の売上高を商品別や地域別に集計する用途で利用します。
利用者はExcelや、集計結果をグラフや表に加工して表示するBI(Business Intelligence)ツールからDWHのデータにアクセスして数字を確認します。
受注や入金を1件ずつ記録する業務システムのデータベースに対し、DWHは大量の過去データを集計して傾向を把握するために設計されています。
各店舗のレジが業務システムのデータベースなら、全店舗の伝票を年度別・品目別に整理して保管する本社の資料室がDWHです。

業務システムのデータベースは受注を1件ずつ記録し、データウェアハウスは過去データを一括で集計することを示す図

データレイクは加工前のログや画像を元の形式のまま保管する場所です。
DWHは表形式のデータの集計を主な用途とする点でデータレイクと異なります。

業務システムだけでは過去の推移を集計しにくい

業務システムのデータベースは、受注の登録や在庫の引当を1件ずつ迅速に処理する設計です。
全期間・全件を対象とする分析の集計を同じデータベースで実行すると処理が重くなり、受注の入力画面の応答が遅延することがあります。
業務システムが現在の状態だけを上書きで保持している場合、半年前の担当者や価格を後から確認できません。
受注は販売管理、入金は会計、顧客情報は顧客管理と、データが別々のシステムに分散していることも集計を困難にしています。

DWHはこれらのデータを業務システムとは別の場所に複製し、分析の集計と業務の処理を分離します。
分析処理を業務用のデータベースから分離することで、業務処理と分析処理の双方の性能の向上が期待できます。

業務システムのデータを毎晩データウェアハウスへ複製し、BIやExcelからの分析の集計をデータウェアハウスで実行して業務の処理から分離することを示す図

効果

  • 販売管理、会計、顧客管理のデータを結合した集計を、手作業のファイル突合なしで実行可能
  • 必要な履歴を記録する取り込みと保存の方法を設計すれば、業務システムの保持期間に左右されず過去の状態と比較可能
  • 分析の集計の負荷を業務システムから分離可能。ただし業務システムからデータを抽出する処理の負荷は別途確認が必要
  • 多数の利用者による同時の集計を想定した設計のため、複数の部署が同じ表を同時に参照する用途にも対応可能

コストとリスク

販売管理と会計のコードと計上基準を統一し、欠損・重複・取り込みの失敗の有無を確認して、はじめて同じ表で数字が一致することを示す図

DWHを導入するかの判断

検討のきっかけは手作業による突合の負担、業務システムへの集計の負荷、過去の状態と比較する必要の3つです。
いずれにも該当しない場合はDWHを早期に導入する必要はありません。

導入時はすでに利用しているクラウドの従量課金型の製品で、1つの業務領域から小規模に開始するのが妥当です。

基幹システムの集計表とExcelで分析が完結していてもDWHは必要か

基幹システムの集計表とExcelで履歴の保持、処理速度、管理の要件を充足している場合、DWHの導入は急務ではありません。
既存の手段で要件を充足している状態では、DWHで新規に実現できる分析が限定的で、構築と運用の費用を回収しにくいからです。
次のような状態が継続している場合は、導入の検討を開始する目安です。

  • 複数のシステムのデータを同じ指標で定期的に手作業で突合している
  • 集計の手作業に時間がかかり、作業できる担当者が限られている
  • 集計の誤りや部署間の数字の不一致が繰り返し発生している
  • Excelの1シートの行数が上限の1,048,576行に接近している
  • 組織変更や価格改定の前後で過去の推移を比較する必要がある

手作業の突合の負担、業務システムへの集計の負荷、過去の状態との比較のいずれもなければ集計表とExcelのまま、いずれかがあればDWHの導入を検討し、導入する場合は1つの業務領域から開始することを示す図

基幹システムのデータベースにBIツールを直接接続すればよいのか

直接接続の可否は利用者の人数だけでは確定しません。
受注や出荷の処理と同じ計算資源を使用する場合は、1人の重い集計でも業務を停止させるおそれがあります。
直接接続で開始する場合は読み取り専用の権限を使用し、集計の実行時間に上限を設定します。
そのうえで業務時間中に代表的な集計を試行し、業務処理への影響を事前に確認します。

次のいずれかに該当した時点で、業務用のデータベースから分析の処理を分離します。

  • 業務処理への影響が発生した
  • 複数システムのデータの結合が必要になった
  • 過去の状態との比較が必要になった

分離の方法にはDWHのほかに分析専用の複製データベースもあり、要件と費用に応じて選択します。

読み取り専用の権限と実行時間の上限を設定して事前に影響を確認し、影響が発生すれば最初から分離し、発生しなければ直接接続で開始して、業務処理への影響・複数システムの結合・過去の状態との比較のいずれかに該当した時点でデータウェアハウスか分析用の複製データベースへ分離することを示す図

費用はどの程度で請求の急増は防止できるのか

クラウドの利用料はデータの容量だけでは確定せず、集計の実行回数、1回に処理するデータ量、計算資源の稼働時間、保存と取り込みの方式に応じて変動します。

総額の算定では取り込み処理の構築費と運用の人件費も計上します。

利用料の桁は集計の書き方次第で変化します。
たとえば1TiB、約1.1兆バイトの表の全列を参照する集計を1日10回、30日間自動実行し、キャッシュの適用がなく毎回1TiB分の課金が発生する場合、課金対象は月300TiBです。
毎月の無料枠1TiBを控除した299TiBにBigQueryの料金表の単価6.25ドルを適用すると1,868.75ドルで、月約1,900ドルになります。
仮に参照する列を限定して1回に処理するデータ量が10分の1の0.1TiBになれば、同じ回数でも課金対象は月30TiBで、無料枠の控除後は181.25ドルです。

導入時に製品の上限設定を有効化すると、集計の費用が急増するリスクを低減できます。
ただし、設定ごとに対象の費用が異なり、請求の総額を保証するものではありません。

上限設定で抑制できる費用は製品ごとに異なり、BigQueryのオンデマンド料金は読み出し量の上限で読み出し量の課金を、Snowflakeは自動停止で計算資源の稼働時間を、Redshift Serverlessは最大使用量の到達時にクエリの停止を選択した場合に計算資源の使用量を抑制し、保存・取り込み処理の構築費・運用の人件費はどの上限設定でも抑制できないことを示す図

上限の設定とは別に、月額の予算アラートも設定します。
たとえばGoogle Cloudの予算アラートは通知のみで、課金を自動では停止しません。
通知の受信担当者と利用制限の要否を決定する手順を事前に策定します。

DWHの対象外の用途とDWH製品の選定基準

  • 在庫の引当や受注の確定など、即時の応答が必要な業務処理は業務システムのデータベースで処理する
  • 画像や音声の元ファイルを大量に保管する用途には、通常はデータレイクなどの安価な保管場所を使用する
  • 会計や顧客管理のクラウドサービスの標準レポートで必要な集計が完結し、履歴の保持、処理速度、管理の要件も充足しているなら、DWHの導入は急務ではない
  • 製品は既存のクラウドとの接続の容易さを重視しつつ、代表的な集計を試行して処理速度と費用を確認したうえで選定する

よくある誤解

DWHのデータは常に最新である

DWHのデータは通常、業務システムから定期的に転送されます。
参照可能なデータの時点は取り込みの時刻、取り込み対象の期間、送信元のシステムの更新状況、取り込みの成否で確定します。
たとえば前日分の取り込みを毎晩実行する運用では前日までの数字が基本で、取り込みに失敗すると鮮度がさらに低下します。
数分単位の鮮度が必要な業務は、取り込みの方式の変更を含めて費用と比較して決定します。

業務システムでは当日の日付まで参照できるのに対し、前日分の取り込みを毎晩実行するデータウェアハウスでは取り込みが成功した翌日は前日分まで、失敗した翌日は前々日分のままになることを示す図

DWHとデータレイクは二者択一である

データベース、データレイク、DWHは併用するのが一般的です。
売上や在庫の集計が目的の場合は、DWHから開始すれば十分です。

お問合せ

事業の課題や技術的な悩みなどどんなことでもお聞かせください

お問合せ