「データパイプラインをクラウドに移行するとき、既存のETL処理をそのまま持ち込むべきか、ELT方式に切り替えるべきか」。オンプレのDWHを使ってきたエンジニアが必ずぶつかる問いだ。設計を誤ると、後でパイプライン全体を作り直す事態になりかねない。
この記事では、ETLとELTの仕組みの根本的な違いから、AWS・Azureの主要サービス対応表、現場での選定判断フローまでを体系的に解説する。
オンプレ時代のETLとクラウド時代のELT — 何が変わったのか
オンプレ環境でのデータ統合は、長らくETL（Extract / Transform / Load）が主流だった。Oracle Data Integrator・Informatica PowerCenter・IBM DataStageといったツールを使い、「抽出したデータを専用サーバー上で変換・クレンジングしてからDWHに投入する」という流れが定番だった。
この方式がクラウド時代に見直されるようになったのは、BigQuery・Amazon Redshift・Azure Synapse Analyticsといったクラウドネイティブなデータウェアハウスの演算能力が飛躍的に上がったからだ。「変換はDWHが得意な領域でやれ」という発想がELT（Extract / Load / Transform）の背景にある。
両者の根本的な違いはシンプルで、変換（Transform）をどこでやるかの一点に集約される。
| 比較軸 | ETL | ELT |
|---|---|---|
| 変換のタイミング | ロード前（中間ステージで変換） | ロード後（DWH内で変換） |
| 変換の場所 | ETL専用エンジン | クラウドDWH（Redshift・Synapse等） |
| 原データの保持 | 変換後のデータのみ保持 | 原データをDWH上に保存 |
| スキーマ設計 | スキーマ先行設計が必須 | スキーマオンリード（後から定義可） |
| 向いているデータ量 | 中規模まで（GB～TB前半） | 大規模向け（TB～PBレンジ） |
ETLの仕組みと向いているケース
1. ETLの処理フロー
ETLは3ステップで進む。
・Extract（抽出）: 基幹系DB・ERP・SFTPサーバー等から生データを取り出す
・Transform（変換）: ETLエンジン上で型変換・クレンジング・集計・テーブル結合を実施
・Load（ロード）: 変換済みの整形データをDWHや分析DBに投入する
変換が完了した「きれいなデータ」だけをDWHに入れるため、DWH側のストレージ使用量を抑えられる。一方、変換ロジックの変更があるたびにETLパイプライン側を修正しなければならず、遡及処理（バックフィル）が煩雑になりやすいのが難点だ。
2. ETLが向いているケース
・個人情報や機密データを含むため、生データをクラウドDWHに置けないコンプライアンス要件がある場合
・変換ルールが安定していて、スキーマが頻繁に変わらない基幹業務データ
・オンプレのDWHを維持しながらクラウドと並行運用するハイブリッド構成
・PII（個人識別情報）の段階的マスク処理が必要で、変換前後の検証が義務付けられている場合
ELTの仕組みと向いているケース
1. ELTの処理フロー
ELTでは、変換前の生データをまずDWHに格納し、DWH内のSQLやdbt等で変換する。
・Extract（抽出）: データソースからローデータを取り出す（ETLと同じ）
・Load（ロード）: 変換せず生データをそのままDWHのステージングエリアに格納
・Transform（変換）: DWH内のSQL・dbt（data build tool）等で変換・集計を実行
「先に入れてしまう」ことで、後からどんな形に変換したくなっても原データから再処理できる。これがELTの最大のメリットであり、分析要件が事前に確定しにくいクラウドネイティブな環境との相性が良い理由でもある。
2. ELTが向いているケース
・BigQuery・Amazon Redshift・Azure Synapse等のクラウドDWHの演算能力を最大限活かしたい場合
・分析要件が後から変わる可能性があり、原データを保持してリプロセスしたい場合
・データサイエンティストやアナリストがSQLで直接変換ロジックを書けるチーム構成
・dbt（data build tool）を使ったモダンデータスタックを採用している、または採用を検討している場合
AWS・Azureの主要サービス対応表
ETLとELTそれぞれのアプローチに対応するマネージドサービスを整理しておこう。
| 役割 | AWSサービス | Azureサービス | 特徴 |
|---|---|---|---|
| ETLオーケストレーション | AWS Glue | Azure Data Factory | サーバーレスでジョブ定義・スケジュール管理 |
| クラウドDWH | Amazon Redshift | Azure Synapse Analytics | 大量データのSQLクエリを高速処理。ELTのT部分を担う |
| ELT変換層 | dbt Core / dbt Cloud | dbt Core / dbt Cloud | SQLテンプレートで変換ロジックをバージョン管理 |
| データカタログ | AWS Glue Data Catalog | Microsoft Purview | スキーマ・メタデータの一元管理 |
| ストリーミング取り込み | Amazon Kinesis Data Firehose | Azure Event Hubs | リアルタイムデータをDWHへ継続投入 |
AWSではAWS GlueがPySparkベースのETLジョブ管理に使われるが、近年は「生データをAmazon S3に格納してAmazon Redshiftで変換する」ELT的な構成も一般的だ。AzureではAzure Data Factoryがオーケストレーターとして機能し、変換処理はSynapse Analytics内のSQLプールやApache Spark Poolで行うパターンが主流になっている。
料金の目安（2026年6月時点）
料金は構成によって大きく変わるが、代表的な目安を示しておく（東京リージョン基準）。
| サービス | 課金モデル | 目安 |
|---|---|---|
| AWS Glue（ETLジョブ） | DPU時間単位 | $0.44/DPU-時（ap-northeast-1） |
| Amazon Redshift Serverless | RPU時間単位 | $0.375/RPU-時（ap-northeast-1） |
| Azure Data Factory（パイプライン実行） | アクティビティ実行回数＋データ移動量 | 月数千円～数万円（実行頻度次第） |
| Azure Synapse Analytics（Serverless SQL） | クエリ処理データ量 | $5/TB（スキャン量次第で変動） |
ETL方式ではジョブ実行時間に比例してコストが積み上がるため、大量データの複雑な変換には不向きな場合がある。ELT方式ではDWHの処理コストが主体になるため、Redshift Serverlessのような「使った分だけ支払う」料金モデルとの相性が良い。
どちらを選ぶか — 現場での判断フロー
実務では「ETLかELTか」の二択より、両方を組み合わせたハイブリッド構成を採用するケースも多い。たとえば、生データをDWHに格納する前段階でPIIのマスク処理だけをETLで行い、その後の変換はELTで実施するパターンだ。
判断の出発点として、以下のフローを参考にしてほしい。
・生データをクラウドDWHに置けないコンプライアンス要件がある → ETL（または事前マスクETL）
・分析要件が頻繁に変わる・事前に確定していない → ELT
・チームにPySparkの知見がある → ETL（AWS Glue / Azure Data Factory）
・チームのSQLスキルが高く、dbtを運用できるメンバーがいる → ELT + dbt
・データ量がTB～PBレンジに達する大規模DWH → ELT（クラウドDWHの演算能力を活かす）
よくあるトラブルと対処法
1. ELTでストレージコストが予想外に膨らんだ
「生データをそのまま入れる」ELTの宿命として、ステージングエリアのデータが削除されずに溜まり続けるケースがある。Amazon S3のライフサイクルポリシーやAzure Blob Storageのライフサイクル管理で、一定期間経過後のステージングデータを自動削除するルールを最初から設定しておくことを強く勧める。
2. ETLジョブの変換処理がボトルネックになった
AWS Glueでワーカー数（DPU数）が不足してジョブが数時間かかるケースでは、パーティション数を増やすか、DWH側への変換オフロード（ELTへの移行）を検討する。「今の変換処理をそのままETLでやり続けるべきか」を再評価するタイミングでもある。
3. dbtのSQLモデルが複雑になりすぎた
ELT + dbtの構成では、変換ロジックをSQLで管理できる反面、モデルの依存関係が深くなりすぎてフルビルドに30分以上かかるケースが出てくる。dbt の incremental model（増分更新）を活用し、全件再計算から差分更新に切り替えることでビルド時間を大幅に短縮できる。
本記事のまとめ
ETLとELTの違いは「変換をどこでやるか」の一点に集約される。
・ETL: 変換してからDWHに投入する。機密データの事前処理や安定した変換ルールに向く
・ELT: 生データをDWHに格納してから変換する。大規模データ・柔軟な分析要件に向く
・クラウドDWHの演算能力が上がった現在、ELTがモダンデータスタックの主流になっている
・機密データへの対処やチームスキルを踏まえ、ETLとELTを組み合わせたハイブリッド構成も有効
オンプレ時代のETLツールをそのままクラウドに持ち込むのではなく、「データ量・チームスキル・分析要件の変化速度」という3軸で設計を見直すことが、クラウドデータ基盤の移行を成功させるカギになる。
ETLからELTへの移行、どう進めればいい？
クラウド実務に役立つ「Glossary Comparison」カテゴリの記事を他にもまとめています。あわせて読みたい関連記事はこちらからどうぞ。
