フレームワーク活用ガイドひとことで言うと#
従来のETL（Extract → Transform → Load）と異なり、データをまずDWHにロードしてから変換する**ELT（Extract → Load → Transform）**の設計パターン。クラウドDWHの計算能力を活かし、柔軟かつ高速にデータパイプラインを構築する。
押さえておきたい用語#
- ELT（Extract, Load, Transform）
- データソースから抽出（Extract）し、先にDWHへロード（Load）してから、DWH内で変換（Transform）する現代的なデータ統合パターン。
- ETL（Extract, Transform, Load）
- DWHにロードする前に中間サーバーで変換を行う従来型のパターン。ELTと対比して使われる概念である。
- インジェスション（Ingestion）
- ソースシステムからデータを抽出してDWHに取り込むプロセスのこと。Fivetran、Airbyte等のツールで自動化されることが多い。
- オーケストレーション
- パイプライン内の各ジョブ（抽出→ロード→変換→テスト）の実行順序と依存関係を管理する仕組み。Airflow、Dagster、Prefectなどが代表的なツールを指す。
ELTパイプライン設計の全体像#
こんな悩みに効く#
- ETLの変換ロジックを変更するたびにパイプラインが壊れる
- データソースが増えるたびにエンジニアの工数が爆発する
- 「先週のデータが見たい」と言われてから準備に3日かかる
基本の使い方#
データソースからDWHへのインジェスションを設定する。
- Fivetran・Airbyte・Stitch等のマネージドツールで300以上のコネクタが使える
- 取り込み頻度はリアルタイム・時間単位・日次と要件次第
- 変更分だけ取り込む増分ロードでコストを抑える
- この段階では変換しない。カラム名もデータ型もソースのまま取り込む
dbtなどのツールでSQLベースの変換モデルを定義する。
- ステージング: ソーステーブルの型変換とリネーム
- 中間モデル: 複数テーブルの結合、重複排除、ビジネスキーの統一
- マート: KPI集計・ディメンション結合の最終アウトプットテーブル
- 各モデルにデータテスト（not_null、unique、freshness）を設定する
パイプラインの実行順序と監視を設定する。
- Extract→Load→Transform→Testの依存関係をDAGで管理
- cron式で定期実行、またはイベントトリガーで実行
- テスト失敗・遅延・データ量異常はSlack等に通知
- Airflow、Dagster、Prefect等のオーケストレーターを使う
具体例#
従業員25名のSaaSスタートアップ。Salesforce、HubSpot、Stripe、GA4、Intercomなど10個のSaaSにデータが分散していた。
FivetranでBigQueryに日次ロード。dbtで変換モデルを構築し、売上・MRR・解約率のGoldテーブルを作成。
| Before | After |
|---|---|
| 各SaaSの管理画面を個別に見て手作業で集計 | BIダッシュボード1つですべて確認 |
| 月次レポート作成に3日 | 自動更新で常に最新 |
| エンジニア2名が手動ETLに週10時間 | Fivetran+dbtで完全自動化 |
データエンジニアの工数 週10時間 → 週1時間（メンテナンスのみ）。MRRの集計ミスも月間 平均3件 → 0件 に。
年商40億円のEC企業（従業員150名）。従来はオンプレのETLツール（Informatica）で基幹DB→DWHの変換を行っていたが、変換ロジックの変更に2週間、新規ソース追加に1ヶ月かかっていた。
Snowflake + dbt + Airbyteに移行し、ELTパターンに切り替え。
- 変換ロジックの変更: 2週間 → 半日（SQLを変更してdbt runするだけ）
- 新規ソース追加: 1ヶ月 → 3日（Airbyteのコネクタ設定 + dbtモデル追加）
- DWHの月額コスト: オンプレ保守費 月120万円 → Snowflake月45万円
ELTへの移行で「ビジネスの質問に即座にデータで答える」体制が整い、データドリブンな意思決定が加速した。
病床数400の総合病院。電子カルテ、検査システム、薬剤管理システムのデータが別々のDBに格納されており、横断分析ができなかった。
ELTパイプラインを構築し、3システムのデータをBigQueryに日次ロード。dbtで患者IDベースの統合テーブルを作成。
- 各システムからCSV/APIで日次抽出、GCSを経由してBigQueryにロード
- 患者IDの名寄せ・診療科コードの標準化・検査値の正規化を変換
- 退院後30日以内の再入院率分析が可能になった。再入院リスクが高い患者を退院前に特定し、退院指導を強化。再入院率が 12.3% → 9.1% に改善
以前は横断分析のたびにIT部門に依頼して3週間待ちだったが、Goldテーブルからダッシュボードで即座に確認できるようになった。
やりがちな失敗パターン#
- ロード前に変換してしまう（ETLに戻る） — 「このカラムは使わないから落とそう」とロード前に加工すると、後から必要になったときに再取り込みが必要になる。まず全部ロードしてからDWH内で変換する
- 変換モデルにテストを書かない — dbtのモデルを作っても
not_nullやuniqueのテストがなければ、品質劣化に気づけない。モデルとテストはセットで作る - オーケストレーションを後回しにする — 手動でdbt runを叩いて運用していると、実行忘れや順序ミスが発生する。早い段階でAirflow等を導入する
- 全量ロードを続ける — データ量が増えると全量ロードのコストと時間が膨大になる。増分ロード（CDC）への切り替えタイミングを見極める
よくある質問#
Q. ETLとELTのどちらを選べばよいですか？ クラウドDWH（BigQuery・Snowflake・Redshift）を使う場合は、ELTがほぼ標準選択です。一方、オンプレミスDWH、大量データの前処理が必要なケース（PIIマスキング・集計縮小）、DWHへのデータ量を最小化したいコスト制約がある場合はETLが適しています。多くのモダンデータスタックでは「ELT＋dbt」が事実上のベストプラクティスになっています。
Q. dbtは必須ですか？ dbtはELTのTransformフェーズを大幅に効率化するツールですが、必須ではありません。SQLをDWH上で直接実行する方法でも構築できます。ただしdbtを使うと、①モデル間の依存関係の自動解決、②データテスト（not_null・unique等）の組み込み、③ドキュメント自動生成、④バージョン管理との統合、という恩恵があり、3〜5人以上のチームであれば導入コストに見合う価値があります。
Q. リアルタイム分析が必要な場合、ELTは使えますか？ ELTの標準構成（日次バッチ）ではリアルタイム分析に対応できません。リアルタイム要件がある場合は、①CDC（Change Data Capture）ツール（Debezium等）でストリーミングインジェスション、②Kafka等のメッセージキューを経由、③BigQuery Streming InsertsやSnowpipeを活用、という構成が必要です。「どこまでの遅延が許容されるか（准リアルタイム＝15分以内か、リアルタイム＝1秒以内か）」を要件定義で明確にすることが先決です。
Q. ELTパイプラインのコストはどれくらいかかりますか？ 主なコスト構成は①インジェスションツール（Fivetran：コネクタ数×データ量課金、Airbyteはセルフホストで安価）、②クラウドDWH（BigQueryはクエリ課金またはフラットレート、Snowflakeはクレジット制）、③オーケストレーター（Airflow：Composer使用時は月数万円〜、Dagster Cloudは無料プランあり）の3つです。スタートアップ規模（10個のSaaS・日次更新）であれば月額3〜10万円程度が相場ですが、データ量と利用頻度によって大きく変動します。
まとめ#
ELTパイプラインは「まずDWHに全部入れてから変換する」パターン。変換ロジックはSQL1行で変更できるし、新規ソースの追加も半日あれば終わる。正直、いまからデータ基盤を作るならELT一択。クラウドDWHがある前提でこれ以外を選ぶ理由がない。