ETL・ELT ― Fivetran+dbt+DWHが現代の定石 ― 生成AI時代のアーキテクチャ超入門

flowchart LR
    subgraph ETL_FLOW["ETL (従来型・2000年代)"]
        E1[Extract] --> T1[Transform<br/>専用ETLサーバ]
        T1 --> L1[Load → DWH]
    end
    subgraph ELT_FLOW["ELT (クラウド型・2015年〜)"]
        E2[Extract] --> L2[Load → DWH]
        L2 --> T2[Transform<br/>DWH内SQL/dbt]
    end
    classDef old fill:#fee2e2,stroke:#dc2626;
    classDef new fill:#dcfce7,stroke:#16a34a;
    class ETL_FLOW,E1,T1,L1 old;
    class ELT_FLOW,E2,L2,T2 new;

	ETL（従来型）	ELT（クラウド型）
順序	Extract → Transform → Load	Extract → Load → Transform
変換場所	専用サーバー（ETLツール）	DWH内のSQL
主役時代	オンプレ・2000年代	クラウド・2015年〜
変換言語	GUI・独自DSL	SQL中心（dbt等）
代表ツール	Informatica・Talend	dbt・Fivetran

クラウドDWHが十分速くなったため、変換もDWH内でやるELTが主流になりました。ETLで変換サーバーを別に用意する時代は終わりつつあります。

現代の典型構成

現代のデータパイプラインは「抽出 → 投入 → 変換 → 活用」の流れで、各段階に役割特化のツールが使われます。ベストプラクティスとしては以下のような構成が定着しています。

[業務DB / SaaS]
      │
      ▼ Fivetran / Airbyte（抽出＋投入 = EL）
[DWH: BigQuery / Snowflake]
      │
      ▼ dbt（変換 = T）
[整ったデータマート]
      │
      ▼ Looker / Tableau / Metabase
[ダッシュボード・BI]

抽出＋投入（EL）を Fivetran が担当、変換（T）を dbt が担当、というレイヤー分けが現代の標準パターンです。

抽出＋投入ツール（EL層）

業務DB・SaaSからDWHへの取り込みを自動化するツール群です。以前は各システムごとに独自スクリプトを書くのが普通でしたが、現代はコネクター済みのSaaSツールが一般的で、接続設定だけで数百種類のソースから取り込めます。

Fivetran（Starburst傘下）は業界標準のマネージドELです。300以上のソースコネクタを提供し、接続設定だけで Salesforce・Stripe・PostgreSQL 等からDWHへ自動同期されます。差分同期・スキーマ変更追従・リトライまで全自動で、エンジニアの手がほぼ要らないのが強みですが、データ量課金で月数十万〜数百万円になり得ます。

Airbyte はOSS版 Fivetran で、セルフホストで無料（有料のクラウド版もあり）で使えます。コネクタ数は増え続けており、コストを抑えたい中小企業の第一候補です。Fivetran ほどの安定性・サポートはまだ劣りますが、機能的な差は年々縮まっています。

ツール	こんな時に選ぶ
Fivetran	予算があり、運用負荷を最小化したい大企業
Airbyte（OSS or Cloud）	コスト重視・セルフホスト運用できる中小
Stitch	小規模・シンプルソースのみ
Hevo	日本でサポート重視したい中堅
自作スクリプト	特殊ソース・ごく小規模（推奨しない）

変換ツール（T層）

DWH内のデータをSQLで変換して分析用に整えるツールです。現代のデファクトスタンダードは dbt（data build tool、SQLでデータ変換パイプラインを定義するツール）で、SQLで書いた変換ロジックをバージョン管理＋テスト＋ドキュメント化する仕組みを提供します。

dbt以前は、変換ロジックがSQLファイル・ストアドプロシージャ・Excelマクロに散在し、誰がどう作ったかわからない数字が経営会議に出る事故が頻発していました。dbtはこの問題を「SQL + Git + テスト」で解決した、データ基盤の革命的ツールです。

ツール	特徴
dbt Core	OSS・SQLで変換・最も普及
dbt Cloud	dbt Coreのマネージド版
Dataform	Google版 dbt（BigQuery統合）
Matillion	GUI中心・エンタープライズ向け

dbtを使わない理由を探す方が難しいほど、現代データ変換の事実上の標準になっています。

オーケストレーション（スケジューリング）

パイプラインは「毎日午前2時に実行」「前段のジョブが成功したら次を実行」といったスケジューリングと依存関係管理が必要です。これを担うのがオーケストレーターで、Airflow が長年のデファクトですが、現代は Prefect・Dagster も台頭しています。

ツール	特徴	向くケース
Apache Airflow	業界標準・コミュニティ最大	大企業・既存資産あり
Prefect	モダンUI・障害対応強い	新規構築・中堅
Dagster	データ中心設計・テスト容易	データエンジニア主体
Cloud Composer	Airflowのマネージド（GCP）	GCP利用企業
Cron + スクリプト	超軽量	小規模・シンプル

dbt Cloud・Fivetran のスケジュール機能で完結する規模なら、専用オーケストレーターは不要です。

データ品質テスト

変換したデータが正しいかを自動テストで検証するのが現代の常識です。「NULLが無いこと」「ユニーク制約」「値の範囲」「参照整合性」などをdbtの tests 機能でコードとして書き、パイプライン実行時に自動検証します。

テストが無い時代は月次レポートの数字がおかしい問題が頻発し、原因追跡に「数週間」かかることもありました。dbtのテスト機能により、不正データが入った瞬間にパイプラインを止めることができます。

テスト種別	内容
not_null	NULLがないこと
unique	重複がないこと
relationships	外部キーが実在すること
accepted_values	許可された値のみであること
custom SQL	任意のビジネスルール

テストなしのデータパイプラインは信用できません。経営判断に使うなら必ずテストを書きます。

データリネージュ（系譜）

あるダッシュボードの「売上金額」が「どの業務DBのどのカラムから、どんな変換を経てここに来たか」を追跡可能にする仕組みがデータリネージュです。大きな組織では「この数字は信用できる？」という問いが日常的に発生するため、リネージュが整っていないと数字の信頼性が担保できません。

dbtは自動的にリネージュグラフを生成します。モデル同士の依存関係が DAG（有向非巡回グラフ）として可視化されるため、このテーブルを削除するとどこが壊れるかが事前にわかります。

ツール	リネージュ可視化
dbt	自動生成（DAG）
DataHub	組織全体のカタログ＋リネージュ
OpenLineage	OSS標準仕様
Collibra / Alation	エンタープライズ商用

判断基準

① 組織規模

規模	推奨構成
小規模（数人・数十万行）	cron + Pythonスクリプト + BigQuery
中規模（SaaS企業）	Fivetran + dbt Cloud + BigQuery/Snowflake
大規模(多部署・多ソース)	Fivetran/Airbyte + dbt + Airflow + カタログ
超大規模・上場企業	エンタープライズ商用ツール一式

② データ鮮度の要求

「毎朝のレポート」で十分か、「リアルタイムのダッシュボード」か、で構成が大きく変わります。

鮮度要求	実装
日次（朝にあればOK）	バッチETL/ELT（夜間実行）
数時間遅れOK	数時間ごとのバッチ
数分遅れOK	マイクロバッチ（15分サイクル等）
リアルタイム（秒単位）	ストリーミング（次章で解説）

多くの業務要件は日次で十分。リアルタイムを安易に目指すと、コストと複雑性が跳ね上がります。

③ チームスキル

dbtはSQLが書ければ使えますが、AirflowはPythonの知識が必要です。チームのスキル構成で選定が変わります。

SQL中心の組織 → dbt（ほぼSQLだけで完結）
Pythonエンジニア主体 → Airflow / Prefect / Dagster
非エンジニア含む → Fivetran + dbt Cloud（GUI寄り）

ケース別の選び方

スタートアップ・データエンジニア0人

Fivetran + dbt Cloud + BigQuery。SQL書ければ回る最小構成。月10万円程度から。

中堅企業・社内にSRE（Site Reliability Engineering）あり

Airbyte（OSS）+ dbt Core + BigQuery/Snowflake + Airflow。コストを抑えつつ柔軟に運用。

大企業・多ソース・統制重視

Fivetran + dbt + DataHub（カタログ）+ Airflow。商用サポートと統制を確保。

リアルタイム要件あり

Kafka + Kinesis / Pub/Sub + Flink / ksqlDB。ストリーミング基盤（次章参照）。

パイプライン鮮度・実行時間の数値Gate

※ 2026年4月時点の業界相場値です。テクノロジー・人材市場の変化で陳腐化するため、定期的にアップデートが必要です。

データパイプラインは「動いている」では不十分で、鮮度と所要時間を数値で追うのが現代の運用です。

指標	推奨値	理由
日次ジョブ所要時間	1時間以内	再実行の余裕を確保
時次ジョブ所要時間	15分以内	次の時刻までに終わらないと詰まる
dbt run実行時間	10分以内	開発サイクルを回すため
データ鮮度SLO	業務要件に応じ設定	日次で遅延監視
欠損率	< 0.01%（1万分の1）	それ以上は要原因調査
重複率	0件（unique制約）	dbt testsで毎回検証
外部キー整合性	0件エラー	relationshipsテスト
NULL率（必須列）	0%	not_nullテスト
失敗時リトライ	最大3回 + 指数バックオフ	一時障害の自動復旧
障害通知	5分以内	Slack + PagerDuty

「dbt testsはCIで必須化」し、品質違反でパイプラインを止める運用が現代の標準です。「月次レポートの数字がおかしい」→原因追跡に数週間、という古典的事故を防ぐ最大の投資です。

データ品質はCIで自動テスト。本番に問題データを流した後で気づいても遅いです。

筆者メモ — 「自作スクリプト軍団」が吸った1人月

ある中堅企業では、Salesforce・Stripe・Zendesk など「10数個のSaaS連携用Pythonスクリプトを1つずつ手作り」していたところ、ベンダー側のスキーマ変更のたびに1本壊れ、気がつけば若手エンジニア1人分の工数が「パイプライン保守」だけに消えていた、という話がよく聞かれます。SaaS課金を払いたくない、という動機で始めた自作が、人件費では課金の何倍もかかっていたという典型的なパターンです。

別の事例では、変換ロジックがSQLファイル・ストアドプロシージャ・Excelマクロに分散していた組織で、退職した担当者のPCにだけ重要な変換処理が残っていた、という話もあります。経営会議の数字が数ヶ月止まり、再構築に半年を要したと言います。dbtでGit管理していれば起きなかった工数です。

筆者も過去に、Pythonスクリプトで自作した連携処理が新人の担当になった瞬間、先方のAPI変更で毎週のように壊れて夜に慌ててパッチを当てる、という光景を見ました。これらの事例はコードの見える化と標準化の価値を教えてくれます。Fivetran + dbtの月額数万〜十数万円は、自作・属人化のリスクと比べれば圧倒的に安い投資、というのが現代の結論です。

自作スクリプトは時給換算で必ず負ける。Fivetran / Airbyte課金の元は人件費で取れます。

ETL/ELTの鬼門・禁じ手

データパイプラインで事故る典型を整理します。どれも数字の信頼性を壊す直接原因です。

禁じ手	なぜダメか
SaaS連携用Pythonスクリプトを10個自作	ベンダー側スキーマ変更で1本ずつ壊れ、若手1人分の工数が消える
変換ロジックをSQLファイル・ストアドプロシージャ・Excelマクロに分散	退職者のPCにだけ秘伝の処理が残る地獄
`TRUNCATE + INSERT` で毎回全データ再投入	ロード時間爆発、ダウンタイム発生。増分ロードに切り替える
テストなしでパイプライン運用	「この数字おかしい」が月末に発覚、原因追跡に数週間
GUI ETLツール（Informatica / Talend）を新規採用	AI時代に陳腐化。dbt / コードベースへ
エラー発生時に通知なし	3日後にダッシュボードで気づく。Slack + PagerDuty 必須
手動でパラメータ変更して本番実行	記録が残らず、再現不能。Airflow / Prefectで宣言的に
重複レコードをアプリ側で排除	パイプラインでユニーク制約を効かせるのが本筋
バッチが2時間遅延しても気づかない仕組み	監視を組み込み、SLO違反で即アラート
本番環境でdbtファイルを直接編集	Gitを経由しない変更で履歴が飛ぶ
リアルタイム要件を過大評価してストリーミング採用	バッチで済む要件に10倍の運用コスト

「2015年頃から主流化したdbt」（Claire Carroll らによる）は、SQL + Git + テストでデータ変換を革命した転換点です。dbt以前のETLはベンダー独自ツールとGUI設定でブラックボックス化しており、「誰がどう作ったか分からない数字」が経営会議に出る事故が頻発していました。

GUI ETLツールはAI時代に負債化。新規は dbt + Git 一択です。

AI時代の視点

AI駆動開発（バイブコーディング）とAI活用が前提になると、データパイプラインはAIが読める・書けることが選定基準になります。dbtはSQL + YAMLでパイプラインを記述するため、AIが最も生成しやすく、コードレビューもしやすい構造です。GUIベースのETLツールはAI時代に急速に不利になっています。

AI時代に有利	AI時代に不利
dbt（SQL + YAMLのコードベース）	Informatica・TalentのGUI設定
Airbyte（OSS・コード拡張可能）	ブラックボックス独自ETL
OpenLineage（標準リネージュ）	独自リネージュ形式
Gitでバージョン管理	本番環境で直接編集

特にdbtは「AIとの相性が抜群」で、自然言語から変換ロジックを生成させ、テストも自動生成できます。データモデルの70%をAIが書く時代がすでに始まっています。

ETL/ELTはコードベースに寄せる。GUI設定の資産はAI時代に陳腐化します。

よくある勘違い

ETLを自作すればコスト削減できる → 自作は初期は安いが、コネクタメンテ・障害対応・新ソース追加で数人月が吸われます。Fivetranの課金は時給換算で元が取れることが多いです
全部リアルタイムにしたい → リアルタイムはストリーミング基盤・監視・運用が「桁違いに複雑」業務要件の9割は日次で十分です
dbtはSQLなのでエンジニア不要 → SQLは書けても「テスト設計・モデル分割・ドキュメント整備」は別スキル。データエンジニアの仕事は残ります
Airflowを入れればオーケストレーションは解決 → Airflowは運用が重い。小規模では dbt Cloud や Prefect の方が楽です

決めるべきこと — あなたのプロジェクトでの答えは？

以下の項目について、あなたのプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。

抽出ツール（Fivetran / Airbyte / 自作）
変換ツール（dbtが第一候補）
オーケストレーター（Airflow / Prefect / 軽量なら不要）
データカタログ（DataHub / dbtのドキュメント / 不要）
データ品質テスト（dbt testsの必須項目）
スケジュール頻度（日次 / 時次 / リアルタイム）
障害時の通知先（Slack・PagerDuty）

最終的な判断の仕方

ETL/ELTの核心はデータ基盤の血管であり、ここが詰まると全社分析が止まります。クラウドDWHが爆速になった現代は、先にDWHへロードしてからSQLで変換するELTが合理的な標準解で、変換サーバーを別立てするETL時代の設計は陳腐化しています。抽出（EL）は Fivetran / Airbyte、変換（T）は dbt というレイヤー分けが事実上のデファクトで、小規模ならこの二つで完結します。「リアルタイムを安易に目指さず、業務要件の9割は日次バッチで足りる」という判断を持つことが、コスト破綻を避けるコツです。

決定的な軸はAIが読める・書けるコードベースであることです。dbtはSQL + YAMLで記述されGit管理できるため、AIがパイプライン変換ロジックを生成しやすく、テストまで自動生成できます。GUIベースのETLツール（Informatica / Talent）はAI時代にむしろ負債になり、ロジックがブラックボックス化します。

選定の優先順位

ELT + dbtを基本形 — クラウドDWHの計算能力をフル活用し、変換はSQLで完結
EL層はFivetran / Airbyte — 自作スクリプトは数人月を吸う、SaaS課金で元が取れる
データ品質テストを必須化 — dbt testsで NULL/unique/参照整合性を毎回検証
コードベース + Git管理 — GUI設定はAI時代に陳腐化、YAMLとSQLに寄せる

「ELT + dbtが現代の定石」リアルタイムは業務要件が本当に必要な時だけです。

まとめ

本記事はETL・ELTについて、ETLとELTの違い・典型構成・データ品質テスト・リネージュ・規模別の段階表・GUI ETLがAI時代に負債化する構造まで含めて解説しました。如何だったでしょうか。

ELT+dbtを基本形に、抽出はFivetran/Airbyte、品質テストを必須化し、コードベース+Git管理に寄せる。これが2026年のETL/ELT設計の現実解です。

次回はストリーミング処理（リアルタイムデータの取り扱い）について解説します。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

それでは次の記事も閲覧いただけると幸いです。