2026.10.27 Webシステム

データ統合とは？種類・方式の違いと名寄せの壁から導入判断まで解説

データ統合とは、販売管理・会計・顧客管理といった複数のシステムに散らばったデータを、一貫した形で参照できる状態にそろえる取り組みです。この記事では、データ連携やAPI連携との違いを先に整理し、データ統合の種類を物理統合・仮想統合・同期連携の3系統に分けて解説します。そのうえで、鮮度とソースへの負荷で方式を選ぶ手順、競合の解説がほとんど触れない名寄せとコード対応表という「意味の統合」、統合基盤を作るべき場面と見送る場面、内製と外注の目安までをまとめます。

まとめ：データ統合は置き場所を決める方式選びと意味をそろえる作業の二本立て

データ統合で決めることは2つあります。1つは、データをどこに置いて束ねるかという方式の選択です。DWHへ集める物理統合、元の場所に置いたまま束ねる仮想統合、業務システム同士を同期させる連携型のいずれかを、反映の鮮度とソースへの負荷から選びます。

もう1つは、システムごとに別々に付いた顧客IDや商品コードを「同じもの」と判定できるようにする意味の統合です。実務で工期が延びるのは、たいてい後者。方式を決める前に、統合したい対象の名寄せキーとコード対応表を誰が持つかを決めてください。逆に、データ源が2〜3個で月次の集計しか要らないなら、統合基盤は作らず、CSVの取り込みとBIツールの結合で足ります。

データ統合とは何かと複数システムのデータを一貫した形で使える状態にする仕組み

最初に言葉の範囲をそろえます。データ統合は特定の製品名ではなく、目的と状態を指す言葉です。そのため、同じ「データ統合ツール」という呼び名で、ETLツールもiPaaSもデータ仮想化製品も売られています。

データ統合の定義とサイロ化したデータを一つの見え方にそろえる目的

AWSは、データ統合を「企業内のあらゆる種類のデータについて、一貫したアクセスと配信を実現するプロセス」と定義しています（AWS「データ統合とは何ですか?」）。IBMも、複数のソースから得たデータを統一された一貫性のある形式に結合し、分析・運用・意思決定に使えるようにするプロセスと説明しています（IBM「データ統合とは」）。

両者に共通する要点は「一貫した形で」という部分です。営業はSFAの顧客一覧、経理は会計システムの取引先マスタ、物流はWMSの出荷先を見ている状態では、同じ会社の売上と入金と出荷を1行に並べられません。この分断がサイロ化で、データ統合はそれを解消して、部門をまたいだ集計や照合ができる状態を作ることを指します。

データ統合とデータ連携・API連携の違いと手段と結果という関係

混同されやすいのがデータ連携との違いです。データ連携は、あるシステムから別のシステムへデータを受け渡す行為そのものを指します。データ統合は、その受け渡しを積み重ねた結果として、複数のデータが一貫して扱える状態になっていることを指す。連携は手段、統合は結果、と整理すると線が引けます。

たとえば受注システムから会計システムへ売上を毎晩送るだけなら、それはデータ連携です。送った先で取引先コードを突き合わせ、受注・請求・入金を同じ取引先として集計できて初めて、データ統合と呼べる状態になります。API連携はデータ連携の手段の1つで、仕組みとCSV連携・RPAとの使い分けはAPI連携の仕組みとデータ連携との違いを解説した記事で扱っています。

データ統合の種類を物理統合・仮想統合・同期連携の3系統で整理する見取り図

データ統合の種類は、解説によって5つとする場合も7つとする場合もあり、数え方が異なるものです。AWSはETL・ELT・データレプリケーション・データ仮想化・データフェデレーションの5つを、IBMはそこにリアルタイム統合・変更データキャプチャ（CDC）・アプリケーション統合を加えて挙げています。数え方の違いに惑わされないよう、ここでは「データを実際に動かすか」「何のために束ねるか」で3系統にまとめます。

ETL・ELT・レプリケーションでDWHへ集める物理統合の仕組みと向く用途

物理統合は、各システムからデータを抜き出し、DWHやデータレイクといった1か所へ実際にコピーして束ねる方式です。抜き出したデータを整えてから格納するのがETL、先に格納してからDWHの中で整えるのがELT、表をそのまま別のデータベースへ複製するのがレプリケーションにあたります。

コピーを持つぶん保管の費用はかかりますが、分析のクエリがソースの業務システムに届かないため、本番の処理を遅くしません。過去数年分の推移を見る、複数部門の数字を突き合わせる、といった分析用途の統合はこの系統が基本です。抽出・変換・格納の工程の中身はETLの仕組みとELTとの違いを解説した記事で詳しく説明しています。

データ仮想化とフェデレーションでデータを動かさずに束ねる仮想統合

仮想統合は、データを元のシステムに置いたまま、問い合わせのたびに各ソースへ取りに行き、1つのデータベースのように見せる方式です。コピーを作らないので、ソースの最新値をそのまま読めます。

BigQueryの連携クエリは、この仕組みを手軽に試せる例です。Cloud SQLやSpanner、AlloyDBへSQLを送り、結果を一時テーブルとして受け取れます（BigQuery「連携クエリの概要」）。DWH側の受注テーブルと、Cloud SQL上の業務DBにある最新の在庫を、コピーせずに結合する書き方は次のとおりです。

SELECT
  o.product_id,
  SUM(o.quantity) AS ordered_qty,
  s.stock_qty
FROM dwh.fact_orders AS o
JOIN EXTERNAL_QUERY(
  "my-project.asia-northeast1.erp-connection",
  "SELECT product_id, stock_qty FROM stock"
) AS s
  ON o.product_id = s.product_id
WHERE o.order_date >= DATE '2026-10-01'
GROUP BY o.product_id, s.stock_qty;

手軽な反面、制約もはっきりしています。同ドキュメントは、連携クエリがBigQueryのストレージだけを読む場合ほど速くない可能性があること、読み取り専用であること、一意の接続は最大10個、クロスリージョンの連携クエリはプロジェクトごとに1日1TBまでであることを明記しています（2026年10月時点）。仮想統合をどこまで任せてよいかは、後の判断章で扱います。

CDCとアプリケーション統合で業務システム同士を同期させる連携型の統合

3つ目の系統は、分析のためではなく、業務システム同士が同じデータを持ち続けるための統合です。IBMは人事システムと財務システムに同じデータを持たせる例を、アプリケーション統合として挙げています。

この系統でよく使われるのがCDCです。データベースの更新ログを読み、変更をほぼ即時に別のシステムへ反映します。OSSのCDC基盤であるDebeziumは、ログベースの方式の特徴として、すべての変更を取りこぼさないこと、削除も捕捉できること、「最終更新日時」列のようなデータモデルの変更が不要なこと、MySQLやPostgreSQLではミリ秒単位の遅延で変更を出せることを挙げています（Debezium「Features」）。更新日時列を定期的に見に行く方式では削除を拾えない、という差は設計時に効いてきます。3方式の実装と設定はCDCの3方式と実装設定を解説した記事にまとめています。

比較軸	物理統合	仮想統合	同期連携
代表的な手法	ETL・ELT・複製	データ仮想化	CDC・API
データの移動	1か所へコピー	移動しない	相手側へ反映
主な目的	分析・集計	横断参照	業務の整合
ソースへの負荷	抽出時のみ	照会のたび	ログ読み取り

3系統は排他ではありません。CDCで業務DBの変更をDWHへ流し込めば、同期連携の技術で物理統合を実現する形になります。系統は「何のために束ねるか」を確かめる地図として使ってください。

データ統合の方式を鮮度とソース負荷とデータ量の3つの問いで選ぶ手順

方式の候補が見えたら、次は自社の要件に当てはめます。製品の比較から入ると、機能の多さで選んでしまい、要らない仕組みまで抱えがちです。先に3つの問いに答えてから候補を絞ります。

反映の鮮度とソースDBへの負荷から物理統合か仮想統合かを決める基準

1つ目の問いは、統合したデータを見る人が「何分前のデータなら許容できるか」です。翌朝の集計で足りるなら夜間のバッチによる物理統合で十分で、仕組みも安く済みます。数分以内の反映が要るなら、CDCで変更を流し込む構成か、仮想統合で都度読みに行く構成が候補に入ります。

2つ目は、ソースの業務システムが分析の問い合わせに耐えられるかです。仮想統合は照会のたびにソースへSQLを投げるため、日中の受注処理と重なると本番を遅くします。ソースが基幹系で、昼間の負荷を増やせないなら、仮想統合は外し、物理統合かCDCに寄せてください。iPaaS・ETL・ELT・ESB・API直実装の5方式を6観点で並べた詳しい選定表は、iPaaSとETLの違いと連携方式5種の選定表を解説した記事に載せています。

ビッグデータ統合でELTとデータレイクを選ぶ条件とツール種別の目安

3つ目はデータ量です。アクセスログやセンサーの記録のように、1日で数千万行単位に増えるデータを束ねるビッグデータ統合では、抜き出す途中で整えるETLより、いったんデータレイクやDWHへそのまま入れて中で整えるELTが向きます。変換の処理をDWHの計算資源に任せられるためです。生データをためる層と整えた後の層の分け方はデータレイク・DWH・データマートの違いを比べた記事で整理しています。

「データ統合ソリューション」として売られている製品は、おおむね次の種別に分かれます。

ETL・ELTツール：DWHへの取り込みと変換が中心。分析用の物理統合に向く
iPaaS：SaaS同士のイベント連携が中心。業務の同期連携に向く
CDCツール：データベースの変更ログを流す。低遅延の取り込みに向く
データ仮想化製品：複数ソースを1つに見せる。横断参照に向く

実務でまず決めるのは、分析用か業務の同期用か、の1点だけです。ここが決まれば種別は1つか2つに絞れます。

方式より先に詰まる名寄せ・コード対応表・マスタ統一という意味の統合

ここからが、競合の解説ではほとんど扱われない部分です。方式を決めてデータを1か所に集めても、それだけでは統合は終わりません。IBMも課題として、異なるシステムが同じ情報を別の用語・コード・構造で表すため、対応関係を定義するマッピングが要ると指摘しています。実際の工数の多くは、このマッピングに費やされます。

同じ顧客が別IDで登録されている問題と名寄せキーの決め方の実例

SFAでは「株式会社サンプル商事」、会計では「（株）サンプル商事」、EC基盤では担当者の個人名で登録されている。こうした状態では、顧客IDをキーに結合しても1件も一致しません。必要なのは、どの項目が一致すれば同じ顧客とみなすかという名寄せキーの決定です。

法人の場合に最も強い名寄せのキーになるのは、国税庁が付番する13桁の法人番号です。法人番号を持たない取引先には、正規化した会社名と電話番号の組み合わせを補助キーにする、といった優先順位を決めます。正規化と照合のSQLは、たとえば次のような形になります。

WITH sfa AS (
  SELECT sfa_id,
         corporate_number,
         REGEXP_REPLACE(
           REPLACE(REPLACE(name, '（株）', '株式会社'), '(株)', '株式会社'),
           r'\s', ''
         ) AS norm_name,
         REGEXP_REPLACE(phone, r'[^0-9]', '') AS norm_phone
  FROM raw.sfa_accounts
)
SELECT s.sfa_id, a.account_code
FROM sfa AS s
JOIN staging.acc_customers AS a
  ON (s.corporate_number IS NOT NULL
      AND s.corporate_number = a.corporate_number)
  OR (s.norm_name = a.norm_name AND s.norm_phone = a.norm_phone);

機械的に一致しなかった残りは、人が目で確かめて対応表に登録するしかありません。この手作業の件数を最初に見積もっておくと、統合プロジェクトの工期を読み違えずに済みます。

システムごとに違うコード体系を対応表で吸収するマッピング設計

顧客と同じ問題は、商品コード・部門コード・勘定科目でも起きます。販売管理では商品を8桁、生産管理では品目を12桁で管理している、という組み合わせは珍しくありません。このずれは、どちらかのシステムを書き換えるのではなく、統合側に「販売のコード」と「生産のコード」を1行ずつ対応づける対応表を持って吸収します。

設計で決めるのは3点です。対応表を誰が更新するか、新しいコードが追加されたときに対応が未登録のデータをどう扱うか（集計から外すのか、「未分類」に入れるのか）、そして対応が1対1にならないとき（1つの商品が複数の品目からなる場合など）の按分ルール。この3点が決まらないまま構築に入ると、集計値が元のシステムと合わない原因を毎月調べ直すことになります。

マスタデータ管理（MDM）を統合の前に置くべき組織の規模と登録件数の条件

名寄せと対応表を統合のたびに作り直すのではなく、顧客・商品・取引先の「正」を1か所で管理する考え方がマスタデータ管理（MDM）です。対象システムが5つを超える、あるいは取引先の新規登録が月に数百件ある組織では、統合側で後から照合するより、登録の時点で正のマスタを参照させるほうが手戻りが少なくなります。

反対に、対象が2〜3システムで、マスタの追加も月に数件なら、MDM製品を入れる必要はありません。統合側の対応表で十分に回ります。マスタとトランザクションの違いとMDMの進め方はマスタデータの意味とMDMの進め方を解説した記事で扱っています。

データ統合基盤を作るべき場面と作らずにCSVやBIで足りる場面の判断基準

ここでは立場をはっきりさせます。データ統合基盤は、作ればそのぶん抽出処理と対応表の保守が毎月発生する。作る価値がある条件と、作らないほうがよい条件を分けて示します。

統合基盤への投資が回収できる組織に共通するソース数と利用頻度の条件

基盤を作るべきなのは、次の条件が重なるときです。第一に、統合したいシステムが4つ以上あり、Excelでの手作業の突き合わせに毎月まとまった工数がかかっている。第二に、統合した数字を経営会議や日々の営業判断で週1回以上見ている。第三に、部門ごとに集計した数字が合わず、照合のやり取りが定例化している。この3つがそろうと、基盤の費用は手作業の削減と数字の確認時間の削減で回収しやすくなります。

反対に、データ源が2〜3個で、集計が月次レポートだけなら、統合基盤は作りません。各システムからCSVを書き出し、BIツールの結合機能で突き合わせる運用で足ります。基盤を作るのは、その運用が回らなくなった時点で遅くありません。

仮想統合を分析の主軸に据えて失敗するパターンと見送るべき場面

よくある失敗は、「コピーを作らずに済む」という理由で、仮想統合を全社分析の主軸に据えるケースです。立ち上げは速いものの、ダッシュボードを開くたびに基幹DBへ集計のSQLが飛び、月末の締め処理と重なって業務画面が遅くなる。過去データもソース側の保持期間に縛られ、3年前との比較ができないことが後からわかります。

次の場面では、仮想統合を主軸にするのは見送ってください。ソースが日中に高負荷の基幹系である場合、過去数年分の推移を見る分析が主目的である場合、ソースの数が増え続ける見込みの場合です。BigQueryの連携クエリでいえば一意の接続は10個までという上限があり、ソースの増加にはそもそも向きません。仮想統合は、物理統合の上に「最新の在庫だけを都度読む」といった限られた用途で足す位置づけが安全です。

データ統合を内製するための社内体制の条件と基盤設計から外部支援を使う目安

内製で回せるのは、統合したいシステムのデータ構造を社内で説明でき、SQLを書ける担当がいて、名寄せと対応表の更新を業務部門と一緒に持てる場合です。この状態なら、ETLやELTのクラウドサービスを使って、対象を1システムずつ足していく進め方が続けられます。

一方、基幹系を含む複数システムの統合を初めて行う場合や、CDCで業務DBから低遅延で取り込む構成を組む場合は、最初の設計で後の保守のしやすさがほぼ決まります。初期のDWH設計・名寄せキーの決定・対応表の運用ルールまでを外部と組み、システムの追加と日々の運用は社内に引き継ぐ形が、費用と自走のバランスを取りやすい進め方です。統合の方式選びから基盤の構築・運用設計までをまとめて相談するなら、データ分析基盤構築・MLOps構築支援のように、方式と意味の統合の両方を見渡せる体制を選ぶと、集めたのに数字が合わない状態を最初から防げます。

データ統合の意味と導入の進め方に関するよくある質問と実務での回答

データ統合を検討する担当者からよく挙がる質問を、5つに絞って答えます。

データ統合とETLの違いは何ですか？

データ統合は「複数のデータを一貫して扱える状態にする」という目的や状態を指し、ETLはそれを実現する手法の1つです。ETLはデータを抽出し、整えてからDWHなどへ格納する処理の流れを指します。データ統合の手法にはETLのほか、ELT、レプリケーション、データ仮想化、CDCなどがあり、ETLだけで統合が完結するとは限りません。分析用にDWHへ集める物理統合の場面では、ETLかELTが中心の手段になります。

データ統合のメリットは何ですか？

部門ごとに別々に持っていたデータを同じ定義で並べられるため、売上・入金・出荷といった数字の突き合わせを手作業でしなくて済む点が最も大きな効果です。加えて、集計の元が1か所に決まることで、会議で数字の正しさを確かめる時間が減ることも効果の1つです。AWSは、データの品質と完全性を高めること、正確なデータから素早く示唆を得られることを挙げています。ただし、名寄せと対応表が整っていないと、集めても数字が合わないままになる点には注意が要ります。

データ統合とデータファブリックの違いは何ですか？

データ統合という言葉が指すのは、複数のデータを一貫して扱える状態にする取り組み全般です。データファブリックは、分散したデータを物理的に1か所へ集めきらずに、メタデータを手がかりに横断して見つけ・つなぎ・管理するための設計の考え方で、データ統合を進めるアーキテクチャの1つにあたります。仮想統合やデータカタログを組み合わせた構成になることが多く、構成要素と実装はデータファブリックの構成要素と実装を解説した記事で扱っています。

Excelでデータ統合はどこまでできますか？

データ源が2〜3個、行数が数万行程度で、月次の集計に使う範囲なら、ExcelのPower Queryで複数ファイルを結合する運用でも統合できます。限界は、名寄せや対応表を担当者ごとに手元で持ち始めたときに来ます。同じ顧客の扱いが人によって変わり、統合の結果が担当者の数だけ生まれるためです。対応表を1か所に置けなくなった時点、あるいは更新に毎月数日かかるようになった時点が、DWHを使った統合へ移る目安です。

データ統合の導入にかかる期間と費用の目安は？

期間と費用を最も左右するのは、方式や製品よりも、対象システムの数と名寄せの難しさです。共通のキーで結合できるシステム同士なら、クラウドのETLサービスを使って1システムあたり数週間で取り込めることもあります。一方、顧客IDが共通化されておらず、人手での照合が数千件残るような場合は、工期の大半を占めるのがその確認作業です。見積もりを取るときは、対象システム数、統合したい対象（顧客・商品など）、更新頻度、名寄せが必要な件数の概算を条件として示すと、比較しやすい見積もりが得られます。