Extract Transform Load

定義

Extract Transform Load（ETL） とは、複数のシステムに散在するデータを抽出（Extract）し、ビジネスルールに沿って変換（Transform）し、分析基盤やDWH（データウェアハウス）へ格納（Load）する一連のデータパイプライン工程です。DTC／EC事業では、ShopifyやAmazon、楽天、広告媒体、CRM、在庫管理システム（IMS）、決済代行（Stripe／KOMOJU）など、サイロ化したデータソースを横断的につなぐ「データの動脈」として機能します。

ETLの本質は「生データを意思決定可能な状態に変えること」です。単なる転送ではなく、名寄せ・通貨換算・欠損補完・重複排除といった変換処理を通じて、LTV、CAC、ROAS、在庫回転率などの指標を一貫した定義で算出できるようにします。

類比

ETLはコーヒーショップのオペレーションに似ています。

- Extract＝産地（ブラジル、エチオピア、グアテマラ）から生豆を仕入れる工程。産地ごとに規格・輸送方法・鮮度が異なります。

- Transform＝焙煎・ブレンド・粒度調整。ここで味の一貫性を担保します。同じ生豆でも焙煎度が違えば別商品になります。

- Load＝店舗の棚に並べ、バリスタが即座に抽出できる状態にすること。お客様（アナリストやマーケター）が求めた瞬間に提供できる形にするのがゴールです。

焙煎（Transform）を怠れば、どんなに高級な生豆でも商品になりません。同様に、変換工程を軽視したETLは「データはあるが使えない」状態を生みます。

公式

ETLの処理量と品質は、以下の式で評価できます。

処理スループット = 抽出レコード数 ÷ バッチ実行時間
データ品質スコア = (正常レコード数 ÷ 総レコード数) × 100
変換後ROAS = 広告経由売上（変換後） ÷ 広告費

具体例：

- 日次バッチで120万レコードを抽出し、実行時間40分 → スループットは30,000レコード/分

- 抽出した500,000件のうち、住所正規化・重複排除で485,000件が正常 → データ品質スコアは97.0%

- 広告費¥3,200,000、変換後に正確なアトリビューションで再計算した売上が¥12,800,000 → 変換後ROASは4.0

比較表

項目	ETL	ELT	逆ETL（Reverse ETL）
変換タイミング	格納前	格納後	格納後→外部ツール
主な用途	DWH構築、規制対応	クラウドDWH、大規模分析	CRM／広告媒体への配信
向くデータ量	中〜大（〜数TB）	超大（PB級）	小〜中（施策対象のみ）
代表ツール	Talend、Informatica	dbt、Snowflake、BigQuery	Census、Hightouch
DTCでの例	受注データを整形してDWHへ	生ログをS3に貯めて後処理	セグメントをMeta広告に同期
レイテンシ	バッチ中心（時間〜日次）	準リアルタイム可	分〜時間

応用シーン

1. クロスチャネル売上統合

Shopify、Amazon、楽天、自社アプリの受注データを顧客IDで名寄せし、統合LTVを算出。通貨・税率・返品処理を変換工程で吸収します。

2. 広告アトリビューション

GA4、Meta CAPI、TikTok AdsのログをUTCに統一し、ラストクリック／データドリブン attribution を再計算。ROASの二重計上を排除します。

3. 在庫・需要予測

IMSの在庫スナップショットと販売実績を結合し、SKU別の回転率を算出。欠品率を8.2%→3.1%に改善した事例などが典型です。

4. 顧客セグメンテーション

RFM分析用に最終購買日・購買頻度・購買金額を変換し、休眠顧客（180日以上未購入）を抽出してCRM配信に連携します。

よくある誤解

- 「ETLは単なるコピー」 → 実際はビジネスロジックの実装。定義が曖昧だとKPIが部門ごとにズレます。

- 「変換は後でいい」 → 生データをそのまま溜めると、後工程の修正コストが指数関数的に増大します。

- 「リアルタイムが常に正義」 → バッチで十分な指標（LTV、月次CAC）にストリーミングを導入するのは過剰投資です。

- 「ツールを入れれば解決」 → データ契約（スキーマ、NULL許容、通貨単位）の設計が先。ツールは手段にすぎません。

- 「一度作れば終わり」 → 仕様変更（新チャネル追加、税制改正、通貨追加）でパイプラインは劣化します。監視と再テストが必須です。

Extract Transform Load

定義

類比

公式

比較表

応用シーン

よくある誤解

関連用語

🔗 関連用語