データ基盤の構築の進め方

販売管理、会計、顧客管理など、データが社内の複数のシステムに分かれていると、横断した集計や分析のたびに、各システムからの出力と突き合わせの作業が必要になります。こうしたデータを集約し、集計や分析に使える状態にする仕組みは、データ分析基盤と呼ばれます。各システムから定期的にデータを取り出し、一か所に蓄積したうえで、集計や分析に適した形に加工します。集約したデータは、経営会議で用いる指標の集計だけでなく、機械学習モデルや生成AIを業務に活用する際の前提にもなります。

なお、データを蓄積し、複数の業務やシステムから使えるようにする仕組みを、広くデータ基盤と呼ぶこともあります。たとえば、Power Apps や Dynamics 365 の業務データを保存する Microsoft の Dataverse は、業務アプリケーションのためのデータ基盤です。本記事で扱うのは、こうした業務システムのデータを集めて集計や分析に使うためのデータ分析基盤で、その主な蓄積先はデータウェアハウスです。

ただし、データを一か所に集めるだけでは、業務で信頼して使える基盤になりません。どの指標をどのような定義で算出するか、元のシステムの数値とどのように照合するか、データの誤りをどのように検出するかを、構築にあたって定める必要があります。

データ分析基盤の構築が適する状況と適さない状況

データ分析基盤は、集計や分析に必要なデータが複数のシステムに分かれており、その集計を毎月、手作業で繰り返している場合に有効です。たとえば、経営会議の資料を作成するために、各部署のシステムから出力した表をExcelで結合している場合や、販売と会計のデータを横断して顧客別・商品別の採算を把握したい場合です。

AIの活用を検討している場合も同様です。需要予測や解約予測といった機械学習モデルの構築には、多くの場合、複数のシステムに分かれた取引や顧客の情報を一か所に整備する必要があります。生成AIに社内のデータについて質問し、集計や分析を行わせる仕組みも、参照するデータが各システムに分かれたままでは構築が難しくなります。こうした場合は、AIの導入に先立って、データ分析基盤の構築を検討する必要があります。

一方で、データが1つのシステムに収まっており、量も多くない場合は、そのシステムの集計機能や、既存のBIツールを直接つなぐ方法で足りることがあります。また、集計したい指標が定まっていない場合や、元のシステムにAPIやファイル出力といったデータを取り出す手段がない場合は、基盤の構築の前に、指標とその定義の整理や、データを取り出す手段の確保が必要です。

システムの構成

データ分析基盤は、データの取得、蓄積、加工、処理の実行管理、利用の5つの要素で構成されます。

蓄積先には、クラウドのデータウェアハウスを使うことが一般的です。データウェアハウスは、複数のシステムから集めたデータを、集計や分析に適した形で保存するデータベースです。例として、Microsoft Fabric の Warehouse、Google Cloud の BigQuery、Snowflake、Amazon Redshift があります。Dataverse に保存されている業務データは、データを取り出す処理を作成せずに Microsoft Fabric と連携できます（2026年6月時点）。データ量が少なく、社内のサーバーで運用したい場合は、PostgreSQL などのデータベースを用いて構築することもできます。構築する環境は、社内ですでに利用しているシステム、データの量、運用を担う人員を踏まえて決定します。

指標の定義と元データとの照合

データ分析基盤が業務で使われるには、そこで集計した数値を、会計で確定した数値やこれまで手作業で作ってきた集計表と照合できることが必要です。基盤で集計した売上が会計の売上と合わず、その差を説明できなければ、利用者は基盤の数値を信頼せず、従来の手作業の集計に戻ります。

売上の数値に限っても、食い違いの原因は多くあります。

そのため当社では、指標ごとに、算出に使う元データ、計算の方法、上記の各点の扱いを定義書にまとめ、指標の内容に応じて利用部門や会計の担当者の確認を得たうえで構築します。構築後も、基盤の数値と会計の月次の数値を定期的に突き合わせ、差額が生じた場合に原因を特定できるようにします。この照合は、必要に応じて自動化します。

生成AIに社内のデータについて質問する仕組みを設ける場合も、AIが答える売上の数値は、基盤に定めた定義に従って算出されます。定義が定まっていなければ、AIの回答も、人が集計した数値と同じように食い違います。

更新の頻度と処理の方式

データの更新の頻度は、指標を使う業務に合わせて決定します。月次の会議資料に使う指標であれば1日1回の取り込みで足りることもあり、日中の受注や在庫の状況を見る指標であれば、より短い間隔が必要になります。取り込みの処理は、何度実行しても結果が同じになる性質（冪等性）を持つように実装し、途中で失敗して再実行しても同じデータが二重に登録されないようにします。

データの品質検査

元のシステムのデータには、同じ顧客の重複登録、必須項目の欠損、部署ごとに異なるコードの付け方といった問題が含まれていることがあります。取り込みのたびに、次のような検査を自動で行い、問題があれば担当者に通知します。

例として、加工の処理を dbt で実装する場合は、こうした検査を処理と同じ場所に定義できます（データテスト）。

アクセス権限と個人情報

基盤の構築後にアクセス権限の設定を加えると、構成の大幅な見直しが必要になることがあるため、顧客や従業員の情報を集約する場合は、データを閲覧できる者と範囲を設計の段階で定めます。個人を特定できる項目を伏せた複製を用途ごとに作る方法もありますが、同じデータの写しが社内に増え、管理が難しくなることがあります。そのため当社では、基盤の中で、データを閲覧できる人と範囲をアクセス権限で制限する方法をとることが多くあります。

進め方

1. 利用目的と指標の洗い出し

最初に、利用される数値を、それを使う人や会議・業務とあわせて具体的に集めます。現在の集計表や会議資料があれば、それを材料にします。ここで挙がった指標が、後の工程で設計と検証の基準になります。

2. 元データの調査

指標の算出に必要なデータについて、どのシステムにあるか、どのような手段で取り出せるか、どの頻度で更新されるか、項目の定義と品質に問題がないかを調査します。この段階では、多くの場合、次のような問題が見つかります。

これらを、基盤で補正するもの、元のシステムの運用で修正していただくもの、指標の対象から除外するものに分類します。

3. 設計

指標の定義書を作成し、データの取得と加工の流れ、テーブルの構成、更新の頻度、アクセス権限、ダッシュボードの画面の構成を設計します。構築先の環境もこの段階で決定します。

4. 構築と検証

設計に沿って基盤とダッシュボードを構築し、集計結果を既存の集計表や会計の数値と突き合わせます。差額が生じた場合は、原因が元データ・加工の処理・指標の定義のいずれにあるかを特定し、対処します。

5. 本番への移行と引き継ぎ

定期的な取り込みと品質検査、異常時の通知を本番の環境で稼働させます。運用を担う方にシステムの構成をご説明し、日常の運用と、障害が発生した場合の対応手順を引き継ぎます。

6. 運用と改善

元のシステムの項目の追加や変更、新たな指標の要望に合わせて、取り込みと加工の処理、ダッシュボードを更新します。

ご依頼時にご用意いただく資料

構築には、主に次のような資料を用います。すべてが揃っていない場合も、お手元の資料と各システムの状況を伺ったうえで、進め方を検討します。

元のシステムからデータを取り出すための権限や、構築先の環境（すでにお使いのクラウドや社内のサーバーなど）は、お使いのシステムに応じてご相談します。

成果物

ご依頼の範囲に応じて、主に次のような成果物をご提出します。

期間と費用の決定要因

期間と費用は、データの量と対象とする範囲によって大きく変わるため、ご相談の際に対象の範囲を伺い、個別にお見積もりします。期間と費用を左右する主な要素は次のとおりです。

クラウドを使う場合、その利用料は別途お客様の契約で発生します。利用料は、データの量と更新の頻度に加えて、ダッシュボードや分析で行う集計の量と頻度によっても変わります。設計の段階で、これらを前提とした見込みをお示しします。