複数のSaaSや業務システムに散らばったデータを集約するときは、最初から大きなデータ基盤を作ろうとせず、「一つの問いに答えるために必要なデータだけを、一か所に、決まった時刻に集める」ところから始めるのが確実です。データ基盤は、データを取り出す（Extract）、形をそろえる（Transform）、保管先に入れる（Load）という三つの工程と、それを置く保管先、そして全体を定期的に動かす仕組みでできています。この骨組みを理解しておけば、規模が小さくても大きくても同じ考え方で設計できます。
この記事は、売上は販売管理、顧客はCRM、広告は各媒体の管理画面、問い合わせはサポートツールというように、データが複数の場所に分かれていて、横断した集計に毎回手間がかかっている会社の事業責任者・データ担当・情報システム担当の方に向けたものです。ETLの基本、データ基盤の構成要素、小さく始める手順、設計で決めておくべきこと、よくある失敗とチェックリストまでを順に説明します。
読み終えるころには、自社で最初に集めるべきデータの範囲と、どこまでを既製のサービスで済ませ、どこから開発が必要になるかの見当がつくはずです。
データ集約が必要になるサイン
データ基盤は、作ること自体が目的ではありません。次のような状態が続いているなら、集約を検討する時期です。
- 会議の前に、複数のシステムからCSVを書き出してスプレッドシートで突き合わせる作業が毎回発生している。
- 「広告からの流入が、最終的にいくらの売上になったか」のように、システムをまたぐ問いに答えられない。
- 同じ「顧客数」でも、CRMと請求システムで数字が違い、どちらが正しいか分からない。
- 担当者によって集計の手順が違い、同じ指標でも人によって結果が変わる。
- SaaSの管理画面では過去のデータを一定期間しか見られず、長期の推移を追えない。
これらはどれも、データの「置き場所」と「定義」がばらばらであることから生じています。集約の目的は、データを一か所に集めることで、定義をそろえ、横断した問いに答えられるようにすることです。
反対に、まだ集約を急がなくてよい状態もあります。主要なデータが一つのシステムに収まっていて、そのシステムの標準の集計画面で必要な問いに答えられる場合や、集計の頻度が四半期に一度程度で手作業の負担が小さい場合です。こうした段階で大きな基盤を作ると、保守の手間だけが先に発生します。手作業の集計にかかっている時間と、その数字で行っている判断の重さを比べて、仕組みにする価値があるかを見極めてください。
ETLとは：取り出す・そろえる・入れるの三工程
ETL・ELTは、データ集約の中心となる処理の呼び方です。それぞれの工程で何をするのかを具体的に見ていきます。
Extract（取り出す）
各システムからデータを取り出す工程です。取り出し方には主に次の三つがあります。
- APIで取得する：多くのSaaSは、外部からデータを取り出すためのAPIを公開しています。定期的に呼び出して、新しいデータや更新されたデータを取得します。
- データベースから直接読む：自社で運用している業務システムであれば、データベースに読み取り専用で接続してデータを取り出せます。
- ファイルで受け取る：APIがないシステムでは、定期的にCSVを書き出し、決まった場所に置いてもらう方法をとります。
Transform（そろえる）
取り出したデータを、分析に使える形に整える工程です。具体的には、日付や金額の形式をそろえる、顧客や商品のコードを各システム間で対応づける、重複を取り除く、キャンセルやテストのデータを除外する、といった処理を行います。この工程で「売上とは何か」「アクティブな顧客とは誰か」といった定義をコードとして書き表すことになるため、データ集約の中で最も事業の知識が必要な部分です。
Load（入れる）
整えたデータを、分析用の保管先に入れる工程です。保管先には、分析向けのデータベースであるDWH（データウェアハウス）を使うのが一般的です。
ETLとELTの違い
最近は、先に生のデータをそのまま保管先に入れ（Load）、保管先の中でそろえる（Transform）ELTという順序もよく使われます。DWHの処理能力が高くなり、生データを残しておけば後から定義を変えても計算し直せるためです。どちらを選ぶかは、保管先の性能、データ量、変換処理を誰が書くかで決めます。
| 比較軸 | ETL | ELT |
|---|---|---|
| 変換の場所 | 保管先に入れる前 | 保管先に入れた後 |
| 生データの保持 | 変換後のデータが中心 | 生データを保持しやすい |
| 定義変更への対応 | 取り込みからやり直しが必要なことがある | 保管先の中で計算し直せる |
| 向いている場面 | 個人情報を除いてから保管したい場合など | DWHを中心に分析を広げたい場合 |
| 変換を書く人 | エンジニアが中心 | SQLを書ける分析担当も関われる |
データ基盤の構成要素
データ基盤は、次の要素の組み合わせで考えると全体像がつかみやすくなります。
| 構成要素 | 役割 | 実現方法の例 |
|---|---|---|
| データソース | 元のデータがある場所 | 販売管理、CRM、会計ソフト、広告管理画面、アクセス解析 |
| 取り込み | データを定期的に取り出して運ぶ | 既製のデータ連携サービス、自作のスクリプト、iPaaS |
| 保管先 | 集めたデータを置いて集計する | クラウドのDWH、分析用のデータベース |
| 変換 | 定義をそろえ、分析しやすい形にする | 保管先の中で動くSQL、変換処理のツール |
| 利用 | 人が見て判断する | BIツールのダッシュボード、スプレッドシート、通知 |
| 運用 | 全体を定期的に動かし、異常に気づく | スケジューラ、失敗時の通知、実行履歴の記録 |
これらの要素を一続きにしたものがデータパイプラインです。どの要素も、既製のサービスを組み合わせるか、自社で開発するかを選べます。取り込みは既製のサービスで済ませ、変換だけを自社で書くといった組み合わせもよく使われます。
保管先として代表的なクラウドのDWHの一つにBigQueryがあります。導入の流れと費用の考え方はBigQueryで事業データを分析するで詳しく説明しています。
小さく始めるデータ基盤の作り方
データ基盤は、最初の一つの問いに答えられる最小限の範囲から作り、使われることを確かめながら広げていきます。
- 答えたい問いを一つ決める：「広告媒体ごとに、獲得した顧客の三か月後の売上はいくらか」「解約した顧客は、解約前にどんな利用状況だったか」など、今は答えられない問いを一つ選びます。
- 必要なデータソースを洗い出す：その問いに答えるために必要なシステムと、その中のどの項目が必要かを書き出します。最初は二つか三つのデータソースに絞ります。
- つなぐためのキーを確認する：システムをまたいでデータを結びつけるには、共通の顧客IDやメールアドレス、注文番号などのキーが必要です。キーがない場合は、どう対応づけるかを先に決めます。
- 取り込み方法を選ぶ：各データソースについて、既製のデータ連携サービスで取り込めるか、APIで自作する必要があるか、CSVで受け取るかを決めます。
- 保管先を用意する：クラウドのDWHなど、分析用の保管先を用意します。アクセス権限と、個人情報の扱いもこの段階で決めます。
- 定義を書いて変換する：問いに答えるための指標の定義を文章で書き、それを変換処理として実装します。
- 元データと突き合わせる：集計結果を元のシステムの数字と比べ、ずれがあれば原因を特定して直します。
- 定期実行と異常通知を設定する：毎日決まった時刻に処理が動くようにし、失敗したら担当者に通知が届くようにします。
- 使ってみてから広げる：最初の問いに答えるダッシュボードや集計を実際に使い、次に答えたい問いと必要なデータを追加します。
この進め方であれば、最初の段階でかかる手間と費用を抑えつつ、本当に必要なデータから順に基盤を育てられます。
設計で決めておくべきこと
小さく始める場合でも、後から変えにくいことは最初に決めておきます。
共通のキーと名寄せ
システムをまたいで顧客や商品を結びつけるには、共通のキーが欠かせません。CRMと請求システムで別々の顧客番号を使っている場合は、対応表を作るか、メールアドレスなどで突き合わせる規則を決めます。表記揺れや重複の扱いは、元のシステム側で直すのか、データ基盤の中で吸収するのかも決めておきます。マスタの整え方はマスタデータ管理の進め方が参考になります。
更新の頻度とタイミング
すべてのデータをリアルタイムで集める必要はありません。毎朝の会議で前日までの数字が見られればよいなら、夜間に一日一回取り込めば十分です。頻度を上げるほど、取り込みの失敗やAPIの利用制限に当たる可能性が増えます。判断に必要な鮮度から逆算して決めます。
履歴の持ち方
顧客の契約プランや担当者は、時間とともに変わります。「現在の状態」だけを保管すると、過去の時点の集計が変わってしまいます。過去の状態を後から再現したいデータについては、変更の履歴を残す設計にします。
権限と個人情報
データを一か所に集めると、本来は一部の人しか見られなかった情報が、広く見える状態になりがちです。誰がどのデータにアクセスできるか、個人を特定できる情報を保管先に入れるか、入れる場合は誰が見られるかを決めておきます。社内規程や法令上の扱いについては、専門家や公的な情報で最新の内容を確認してください。
失敗したときの扱い
APIの仕様変更や認証の期限切れ、元データの形式の変化など、取り込みは必ずどこかで失敗します。失敗に気づく通知、再実行の手順、失敗した日のデータを後から補う方法をあらかじめ決めておきます。連携の障害対策についてはAPI連携の障害対策も参考になります。
既製サービスと自社開発の使い分け
データ集約の各工程は、既製のサービスで済ませるか、自社で開発するかを選べます。判断の目安は次のとおりです。
| 判断の観点 | 既製サービスが向く | 自社開発が向く |
|---|---|---|
| データソース | 主要なSaaSで、標準の接続機能がある | 独自の業務システムや、接続機能のないサービス |
| 変換の複雑さ | 単純な集計や結合が中心 | 業務固有の計算や複雑な名寄せが必要 |
| データ量・頻度 | 一般的な量で、日次程度の更新 | 大量データや高頻度の更新 |
| 費用の構造 | 初期の手間を抑えたい | 利用量に応じた従量課金が膨らむ見込み |
| 運用体制 | 社内に開発者がいない | 開発者が保守を継続できる |
実際には、主要なSaaSの取り込みは既製のサービスに任せ、独自システムの取り込みや業務固有の変換だけを開発する、という組み合わせが現実的なことが多いです。既製サービスの料金や対応しているデータソースは変わりやすいため、最新の情報は各サービスの公式情報で確認してください。
具体例：通販事業のデータを集約した場面
ここでは架空の一般例として、自社のECサイトと大手モールの両方で商品を販売し、広告も複数の媒体に出している通販事業者を想定します。
この会社では、受注データはECサイトとモールの管理画面に、顧客情報はメール配信ツールに、広告費は各媒体の管理画面に分かれていました。経営者が知りたかったのは「どの広告から来た顧客が、その後リピートしているか」でしたが、担当者が毎月三日ほどかけて手作業で突き合わせても、顧客の対応づけが曖昧で、確信を持てる数字は出せていませんでした。
そこで、最初の問いを「初回購入の流入元ごとに、半年以内のリピート率と累計購入額を出す」に絞りました。必要なデータソースは、ECサイトの受注データと、アクセス解析の流入元データの二つだけです。注文番号を共通のキーにして両者を結びつけ、モールの受注は流入元が取れないため最初の範囲から外しました。
取り込みは既製のデータ連携サービスで夜間に一日一回行い、保管先にはクラウドのDWHを使いました。変換処理では、キャンセルと社内テストの注文を除外し、同じ顧客の注文をメールアドレスで束ねる規則を定義しました。元の管理画面の数字と一か月分を突き合わせ、ずれの理由を一つずつ説明できる状態にしてから、ダッシュボードとして公開しました。
その後、広告費のデータを追加して媒体別の費用対効果を出し、さらにモールの受注を別の規則で取り込むなど、問いが増えるたびに基盤を広げていきました。最初から全データを集めようとしていたら、定義の議論だけで数か月かかっていたはずです。
データ集約でよくある失敗と避け方
とりあえず全部集める：使い道が決まっていないデータまで集めると、取り込みの保守負担だけが増え、定義の整理も進みません。問いに答えるのに必要なデータから集めます。
定義を決めずに集計を始める：データが一か所に集まっても、「売上」「顧客」の定義が決まっていなければ、集計結果は信頼されません。変換を書く前に、定義を文章で合意します。
元データの品質を確認しない：入力漏れ、表記揺れ、重複は、集約するとそのまま表に出てきます。取り込みの前に元データの状態を確認し、直すべきものは元のシステム側で直す運用にします。
失敗に気づく仕組みがない：取り込みが止まっても誰も気づかず、古い数字のまま判断していた、という事故はよく起きます。失敗時の通知と、最終更新日時の表示は必須です。
作った人しか分からない：変換処理の中身が作った人の頭の中にしかないと、その人が抜けた途端に誰も直せなくなります。定義と処理の内容を文書に残し、複数人が理解している状態を作ります。
元システムの変更が伝わらない：SaaSの項目追加や業務システムの改修で、データの形が変わることがあります。元システムの変更をデータ担当に伝える連絡経路を決めておきます。
データ基盤づくりのチェックリスト
- 最初に答える問いが一文で書けている
- 必要なデータソースと項目が一覧になっている
- システムをまたいでデータを結びつけるキーが決まっている
- 主要な指標の定義が文章で合意されている
- 取り込みの頻度が、判断に必要な鮮度から決まっている
- 個人情報の扱いと、保管先へのアクセス権限が決まっている
- 集計結果を元システムの数字と突き合わせた
- 取り込みの失敗時に通知が届き、担当者が決まっている
- 再実行とデータ補完の手順が文書になっている
- 変換処理の内容と定義が、作った人以外にも分かる形で残っている
- 元システムの変更を共有する経路がある
よくある質問
Q. データ基盤を作るには、専任のデータエンジニアが必要ですか？
最初の段階では必ずしも必要ありません。既製のデータ連携サービスとクラウドのDWH、SQLを書ける担当者がいれば、小さな基盤は作れます。データソースが増える、独自システムとの連携が必要になる、取り込みの安定性が業務に直結するようになる、といった段階で、専任の担当者や外部の支援を検討します。
Q. スプレッドシートに集める方法ではだめですか？
データ量が少なく、集める元も少ない段階では、スプレッドシートに自動で集める方法も有効です。ただし、データが増えると動作が重くなり、定義を変えたときの計算し直しや、履歴の保持が難しくなります。問いが増えてきたら、DWHへの移行を考える時期です。
Q. 費用は何で決まりますか？
主に、データソースの数と取り込み方式（既製サービスで済むか開発が必要か）、変換処理の複雑さ、データ量と更新頻度、運用・保守の範囲で決まります。既製サービスやDWHの利用料はデータ量や処理量によって変動するため、想定されるデータ量で試算し、最新の料金は公式情報で確認してください。
Q. 既存のBIツールだけでデータを集約できませんか？
BIツールの多くは複数のデータソースに接続でき、画面上で結合することもできます。データソースが少なく、結合や計算が単純なうちは、それで十分なこともあります。ただし、計算が複雑になる、同じデータを複数の画面やツールで使う、過去の履歴を保持したい、といった場合は、BIツールの手前にデータ基盤を置いたほうが管理しやすくなります。
Otsumuに相談できること
主要なデータが二つか三つの有名なSaaSにまとまっていて、SQLを書ける担当者が社内にいる場合は、既製のデータ連携サービスとクラウドのDWHを組み合わせて、この記事の手順で自社で小さな基盤を作れます。最初の問いを一つに絞れば、試行錯誤のコストも小さく抑えられます。
一方で、独自に開発した業務システムや接続機能のないサービスからデータを取り出す必要がある場合、顧客や商品のコードが各システムでばらばらで名寄せの規則づくりが難しい場合、取り込みの安定性が日々の業務や顧客対応に直結する場合などは、設計と開発の経験がある外部の力を借りたほうが確実です。
Otsumuは自らも事業を手がける立場から、「何に答えるためのデータか」という目的を起点に、集めるデータの範囲を絞り、取り込みの開発、保管先と変換処理の設計、ダッシュボードでの可視化、運用後の改善までを一気通貫で支援しています。データの集約と可視化はダッシュボード開発で、システム同士の連携部分はAPI連携開発でご相談いただけます。範囲に応じて個別にお見積もりします。
今使っているシステムの一覧と、答えたい問いをお持ちいただければ、最初に集めるべきデータの範囲を一緒に整理できます。まずは30分の無料相談をご利用ください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01