データ取り込み（データインジェスト）とは、複数のデータソースに接続し、それぞれのソースにあるデータを単一のリポジトリへ転送する処理である。 転送先になるのは、多くの場合データベース、データウェアハウス、データレイクのいずれかだ。中央のリポジトリに集まったデータは、アクセス権を持つ組織内の誰もが参照し、分析できる。取り込みは、スケジュールに沿ってまとめて処理するバッチ方式でも、ソースシステムから絶え間なくデータを流し込むリアルタイム方式でも実行できる。
データ取り込みはデータ連携（データインテグレーション）と同じ意味で使われることがあるが、両者は別の処理である。データ取り込みは、元の形式のままの生データを新しいリポジトリへ運び込む。データ連携では、ソースシステムから移動させる過程でETL（Extract, Transform, Load）の変換をかけ、届いた時点で使える形にデータを整える。アーキテクチャによっては、データをソースシステムに置いたまま、検索エンジンのような中央のアプリケーションから参照できる状態にすることを連携と呼ぶ場合もある。
生データのまま運ぶことの利点
データ取り込みの最大の利点は速度である。移動の途中で変換を挟まないため、データは短時間で中央のリポジトリに届く。整合性と正確さを担保するクレンジングも、その先の変換も、取り込んだ後にデータパイプラインの工程として実行すればよい。
データを1か所に集めること自体にも意味がある。データセット全体を横断して傾向を導き出す分析は、対象のデータが各システムに分散したままでは成立しないからだ。
CDPの基盤としてのデータ取り込み
データ取り込みは、CDP（カスタマーデータプラットフォーム）を構成する最下層の基盤である。CDPは、マーケティングオートメーション、CRM、ERP、Web解析、ECサイト、モバイルアプリ、SNS、POS、IoT機器といった数十から数百のソースシステムからデータを取り込む。この対応範囲の広さが、単機能のツールとCDPを分ける違いになる。
バッチ取り込みとストリーミング取り込み
CDPはこの2つを同時に扱わなければならない。バッチ取り込みは、過去分のデータをスケジュールに沿ってまとめて処理する。リアルタイム取り込みとも呼ばれるストリーミング取り込みは、リアルタイムデータ処理によってイベントを発生した順に捉え、その場でのパーソナライズやトリガー配信を可能にする。エージェンティックCDPがストリーミング取り込みを前提とするのは、AIエージェントが1秒未満で判断を下すために、顧客プロファイルが常に最新でなければならないからだ。
| 観点 | バッチ取り込み | ストリーミング取り込み |
|---|---|---|
| 実行のタイミング | 1時間ごと、日次、週次などのスケジュール | イベントの発生と同時に連続的に |
| データの鮮度 | 前回の実行時点まで | 1秒未満から数秒 |
| 適した用途 | レポーティング、履歴分析、解約スコアリング | セッション中のパーソナライズ、トリガー配信、AIエージェントの判断 |
| 1件当たりのコスト | まとめて処理するため低い | 常時稼働する分だけ高い |
| 失敗時の扱い | 次回の実行で再処理しやすい | 再送とべき等性を前提とした設計が必要 |
取り込んだ後に起きること
取り込まれたデータは、まず名寄せによってソースをまたいだレコードの照合にかけられ、重複したプロファイルが統合され、矛盾した値がクレンジングされる。こうして統合されたデータが、分析エンジン、機械学習モデル、そして外部システムへオーディエンスを届けるデータアクティベーションのパイプラインから利用できる状態になる。
スキーマの柔軟性
取り込みの前に厳密なスキーマ定義を求める仕組みは、CDPには向かない。取引記録やフォーム送信のような構造化データ、JSONのイベントログやAPIレスポンスのような半構造化データ、問い合わせの応対記録やSNSの投稿のような非構造化データを、事前の定義なしに受け入れられることが要件になる。ソース側の仕様が変わるたびに取り込みが止まる設計では、数百のソースを維持できない。
取り込みの安全性とデータ品質
顧客データや自社の機密情報を運ぶ以上、取り込みを安全に実行できるかどうかは設計上の前提になる。転送経路と保管先の両方についてデータガバナンスの方針を定め、取り込み先のリポジトリに触れられる範囲を、認可された分析ツール、システム、担当者に限る必要がある。
もう1つの課題はデータ品質だ。生データをそのまま運ぶ方式は速い代わりに、欠損値、表記ゆれ、重複を下流へそのまま送り込む。取り込みの時点で弾くものと、パイプライン側で直すものをどこで線引きするかは、取り込み方式を決める段階で合わせて決めておきたい。
CDPを評価するときの確認点
データ取り込みはどのCDPも備えている機能であり、対応の有無ではなく実装の質で差がつく。選定時には次の点を確認するとよい。
- コネクタの数と保守の主体：主要なSaaSやデータベースへのコネクタが標準で用意されているか、その更新をベンダーが担うのか自社が担うのか
- バッチとストリーミングの両対応：同一のプロファイルに対して、両方の経路から届いたデータを矛盾なく反映できるか
- 取り込みから利用可能になるまでの時間：イベントが届いてからプロファイルに反映され、セグメントやAIエージェントから参照できるまでの実測値
- スキーマ変更への耐性：ソース側で項目が追加されたり型が変わったりしたときに、取り込みが止まるのか、警告を出して継続するのか
- 課金の単位：取り込む行数、イベント数、ソース数のどれに連動するか。高頻度のストリーミングは、この単位次第で費用が大きく変わる
FAQ
データ取り込みとデータ連携の違いは何か
データ取り込みは生データを変換せずに中央のリポジトリへ運び込む処理であり、データ連携は移動の過程で変換と整形を行う処理である。 実務では二者択一にはならない。まず取り込みで生データを1か所に集め、その後の工程で名寄せと整形を行う順序が一般的だ。変換を後ろに置くほど元の値が原形のまま残るため、後から別の用途にデータを使い直しやすくなる。逆に、届いた時点で決まった形式が必要な業務システム向けの受け渡しには、連携の側が適している。
バッチ取り込みとリアルタイム取り込みはどう使い分けるのか
判断の基準は、そのデータが数時間古くても意思決定が変わらないかどうかである。 レポーティング、履歴分析、月次の解約スコアリングであれば、日次のバッチ取り込みで足りる。セッション中のパーソナライズ、かご落ちのトリガー配信、AIエージェントによる応対のように、顧客がまだその場にいる間に判断する用途では、ストリーミング取り込みが必要になる（リアルタイムCDPを参照）。実運用では両方を併用する構成が一般的だ。
CDPにはどのようなデータソースを取り込めるのか
顧客に接するシステムであれば、ほぼすべてが取り込みの対象になる。 CRM、マーケティングオートメーション、WebとモバイルアプリのSDK、ECプラットフォーム、POS、カスタマーサポート、SNS、広告プラットフォーム、外部のデータ提供事業者などである。取引記録のような構造化データに加えて、イベントログのような半構造化データや応対記録のような非構造化データも扱える。この幅の広さが、統合された顧客プロファイルを成り立たせている。
取り込みの基盤を自社で作る場合とCDPを使う場合で何が違うのか
違いは、取り込んだ後の名寄せとアクティベーションまで同じ基盤の内側で完結するかどうかにある。 取り込みそのものは、ストリーム処理基盤やマネージドのパイプラインを組み合わせれば自社でも実現できる。CDPが引き受けるのはその先で、数百のコネクタの保守、届いたイベントのプロファイルへの反映、同意状態の伝播、外部チャネルへの連携までを一体で扱う。取り込みの機能だけを切り出して比較すると、この差は見えにくい。
Related Terms
- データオーケストレーション：取り込みの実行順序とソース間の依存関係を制御する仕組み
- データ検証：取り込んだデータを下流へ渡す前に誤りを検出する工程
- データ集約：取り込んだレコードをレポートや分析のために集計する処理
- ファーストパーティデータ：CDPが取り込むデータの中心となる、自社チャネルから直接得られる顧客データ
- データウェアハウス：取り込み先として選ばれる代表的なリポジトリ