本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「データアーキテクチャ」カテゴリ第5弾として、ETL・ELTについて解説する記事です。
AI時代はコードで書かれていない変換ロジックがAIに読めず負債化します。本記事ではETL／ELTの違い、現代の典型構成（Fivetran+dbt+BigQuery等）、データ品質テスト、そしてGUI ETLツールはAI時代に負債化する構造を解説します。
本記事のテーマについてさらに詳しく知りたい方は『データ視覚化のデザイン』も参考にしてみてください。
この記事の結論
- ELT+dbtを基本形にする
- 抽出はFivetran / Airbyteに任せ、自前バッチを書かない（自作は人件費で必ず負ける）
- データ品質テスト（dbt tests）を必須化する
- 変換ロジックはコードベース+Git管理に寄せる（GUI ETLは負債化）
この記事を読む前に
本記事はデータベース周りの用語が多めに登場します。IT用語にあまり馴染みがない方は、基礎編の「データベースの基本」を先に読んでおくと格段に分かりやすくなると思います。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそもETL/ELTとは何か
ETL/ELTとは、ざっくり言えば「散らばったデータを1か所に集めて、分析しやすい形に整える仕組み」です。
料理の仕込みを想像してください。八百屋・魚屋・肉屋（業務DB・SaaS・ログ）から食材を仕入れ（Extract＝抽出）、洗って切って下味をつけ（Transform＝変換）、冷蔵庫に整理して収める（Load＝投入）。この仕込みがないと、注文が来てから食材を買いに走ることになります。
なぜETL/ELTが必要なのか
理由は3つです。業務DB（OLTP）で集計クエリを回すと業務処理の邪魔になるため分析用に別DBへコピーする必要があること。業務DB・SaaS（Salesforce・Stripe等）・ログを1箇所に集めないと全社分析ができないこと。そして生データは表記ゆれ・重複・欠損が多く、クレンジングしないと意味ある結果が出ないことです。データパイプラインはデータ基盤の血管で、ここが詰まると全社分析が止まります。
ETLとELTの違い
| ETL（従来型） | ELT（クラウド型） | |
|---|---|---|
| 順序 | Extract → Transform → Load | Extract → Load → Transform |
| 変換場所 | 専用サーバー（ETLツール） | DWH内のSQL |
| 変換言語 | GUI・独自DSL | SQL中心（dbt等） |
| 代表ツール | Informatica・Talend | dbt・Fivetran |
クラウドDWH（BigQuery・Snowflake）が爆速になったため、先にDWHへ突っ込んでからSQLで変換するELTが現代の標準です。変換サーバーを別に用意するETLの時代は終わりつつあります。
現代の典型構成
[業務DB / SaaS]
│
▼ Fivetran / Airbyte（抽出＋投入 = EL）
[DWH: BigQuery / Snowflake]
│
▼ dbt（変換 = T）
[整ったデータマート]
│
▼ Looker / Tableau / Metabase
[ダッシュボード・BI]EL層 ― Fivetran / Airbyteに任せる
Fivetranは業界標準のマネージドELで、300以上のコネクタを提供し、接続設定だけでSalesforce・Stripe・PostgreSQL等からDWHへ自動同期されます。差分同期・スキーマ変更追従・リトライまで全自動ですが、データ量課金で月数十万円になり得ます。コストを抑えたいなら、OSS版のAirbyte（セルフホスト無料）が中小企業の第一候補です。特殊ソース以外での自作スクリプトは推奨しません。
T層 ― dbtが事実上の標準
dbt（data build tool）は、SQLで書いた変換ロジックをバージョン管理+テスト+ドキュメント化する仕組みです。dbt以前は変換ロジックがSQLファイル・ストアドプロシージャ・Excelマクロに散在し、「誰がどう作ったかわからない数字」が経営会議に出る事故が頻発していました。dbtはこれを「SQL+Git+テスト」で解決した革命的ツールで、使わない理由を探す方が難しいほど普及しています。
さらにdbtの tests 機能で、not_null・unique・relationships（外部キー実在）・値の範囲をコードとして書き、不正データが入った瞬間にパイプラインを止められます。テストなしのデータパイプラインは信用できません。またdbtはモデル同士の依存関係（データリネージュ）をDAGとして自動可視化するため、「このテーブルを削除するとどこが壊れるか」が事前にわかります。
オーケストレーション ― 必要になってから
「毎日午前2時に実行」「前段が成功したら次を実行」といったスケジューリングは、業界標準のAirflow、モダンなPrefect / Dagsterが担いますが、dbt CloudやFivetranのスケジュール機能で完結する規模なら専用オーケストレーターは不要です。
どう選べばいいのか ― 規模と鮮度で決める
鮮度要求が構成を決めます。「毎朝のレポート」で十分なら夜間バッチ、数分遅れOKならマイクロバッチ（15分サイクル）、秒単位ならストリーミング（次章）です。多くの業務要件は日次で十分で、リアルタイムを安易に目指すとコストと複雑性が一気に増えます。
パイプライン品質の数値Gate
※ 2026年4月時点の業界相場値です。
| 指標 | 推奨値 |
|---|---|
| 日次ジョブ所要時間 | 1時間以内（再実行の余裕を確保） |
| dbt run実行時間 | 10分以内 |
| 重複・外部キー整合性エラー | 0件（dbt testsで毎回検証） |
| NULL率（必須列） | 0% |
| 障害通知 | 5分以内（Slack+PagerDuty） |
「dbt testsはCIで必須化」し、品質違反でパイプラインを止める運用が現代の標準です。「月次レポートの数字がおかしい→原因追跡に数週間」という古典的事故を防ぐ最大の投資です。
3つのシナリオで考える
個人開発・スタートアップの場合
データエンジニアが0人であれば、Fivetranとdbt CloudにBigQueryを組み合わせた、SQLだけで回る最小構成（月10万円程度から）が本命だと思います。コネクタの保守は全てSaaSに委譲してしまい、自作スクリプトは書かないのがポイントです。そもそも分析要件が軽いうちは、ETL自体を持たないという選択も十分に正解と言えます。
中小SaaSの場合
SRE人材がいるのであれば、OSSのAirbyteとdbt CoreにAirflowという構成で、コストを抑えつつ柔軟に組むことができます。この段階でぜひやっておきたいのが、dbt testsをCIで必須化して、品質違反でパイプラインを止める運用の確立です。ここをサボると「月次レポートの数字がおかしい」という古典的事故に必ず遭遇します。
大企業の場合
統制を重視するなら、Fivetranとdbtに加えてDataHubのようなカタログを整備し、商用サポートを確保する形になります。パイプラインの本数が増えてくると、リネージ（データの来歴追跡）とオーナー管理をカタログで一元化していない限り、障害時の影響範囲が誰にも分からなくなってしまうためです。
AI判断軸 ― コードで書かれていない変換はAIに読めない
dbtのSQL+YAMLはAIの最適な入出力形式
dbtでは変換ロジックをSQLで、メタデータをYAMLで定義します。どちらもAIが正確に生成・修正できるフォーマットで、「注文テーブルから月次売上サマリを作るdbtモデルを書いて」のような指示に対し、AIは models/ 配下のSQLと schema.yml を正確に出力できます。対照的に、GUI ETLツール（Informatica等）の設定はAIが読むことも書くこともできず、AI時代に確実に負債化します。
リネージュの可視化がAI生成コードの信頼性を担保する
OpenLineageやdbt docsでデータの変換経路が可視化されていると、AIが生成したdbtモデルが「どのソーステーブルに依存し、下流のどのダッシュボードに影響するか」を追跡できます。リネージュなしでは、AI生成モデルの不具合が下流に静かに伝播するリスクがあります。
やってはいけないこと
数字の信頼性を壊す直接原因を、特に危険な6つに絞ります。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
| SaaS連携スクリプトを10個自作 | ベンダーのスキーマ変更で壊れ続け、若手1人分の工数が消える → Fivetran / Airbyteに任せる |
| 変換ロジックをSQLファイル・Excelマクロに分散 | 退職者のPCにだけ秘伝の処理が残る → dbtでGit管理する |
| テストなしでパイプライン運用 | 「数字がおかしい」が月末に発覚し追跡に数週間 → dbt testsを必須化する |
| GUI ETLツールを新規採用 | AI時代に陳腐化する → dbt / コードベースへ |
| エラー発生時に通知なし | 3日後にダッシュボードで気づく → Slack+PagerDuty通知を入れる |
| 毎回TRUNCATE+INSERTで全データ再投入 | ロード時間爆発・ダウンタイム発生 → 増分ロードに切り替える |
筆者メモ ― 「自作スクリプト軍団」が吸った1人月
ある中堅企業では、Salesforce・Stripe・Zendeskなど10数個のSaaS連携用Pythonスクリプトを1つずつ手作りしていたところ、ベンダー側のスキーマ変更のたびに1本壊れ、気がつけば若手エンジニア1人分の工数が「パイプライン保守」だけに消えていた、という話がよく聞かれます。SaaS課金を払いたくないという動機で始めた自作が、人件費では課金の何倍もかかっていたという典型パターンです。
Fivetran+dbtの月額数万〜十数万円は、自作・属人化のリスクと比べれば圧倒的に安い投資、というのが現代の結論です。自作スクリプトは時給換算で必ず負けます。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- 抽出ツール（Fivetran / Airbyte / 自作）
- 変換ツール（dbtが第一候補）
- オーケストレーター（Airflow / Prefect / 軽量なら不要）
- データ品質テスト（dbt testsの必須項目）
- スケジュール頻度（日次 / 時次 / リアルタイム）
- 障害時の通知先（Slack・PagerDuty）
この記事に関連する記事
まとめ
本記事はETL・ELTについて、ETLとELTの違い・典型構成・データ品質テスト・リネージュ・GUI ETLがAI時代に負債化する構造まで含めて解説しました。如何だったでしょうか。
ELT+dbtを基本形に、抽出はFivetran/Airbyte、品質テストを必須化し、コードベース+Git管理に寄せる。これが2026年のETL/ELT設計の現実解です。
次回はストリーミング処理（リアルタイムデータの取り扱い）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は AWS Glue も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（49/95）