BigQueryは入れた。dbtの導入も検討している。でもデータ連携だけは5年前に社内で組んだETLサーバーがそのまま動いていて、夜間に何時間もかかっている。データ基盤の刷新相談で、この構図は本当によく見ます。
見覚えがある方は少なくないと思います。「ELTという言葉は聞くけれど、ETLと何が違うのか社内で説明できない」というのも定番の悩みで、社内稟議で止まる理由の1つです。
正直に言うと、違いを一言でまとめると「変換をどこで・いつ行うか」だけなのですが、この一言の裏に処理性能・コスト構造・運用体制の差が積み重なっています。だからこそクラウド時代のデータ基盤では、ELTが主流の座を占めるようになりました。
まず両者の仕組みを短く押さえ、そのうえで次の順に見ていきます。
ETLとは、Extract（抽出）・Transform（変換）・Load（格納） の頭文字を取った言葉です。複数のシステムからデータを抜き出し、ETLツールや専用サーバーの上で分析に適した形へ変換してから、DWH（データウェアハウス。分析用にデータを集約しておくデータベース）に格納します。DWHそのものの仕組みやクラウドDWHの比較についてはDWH（データウェアハウス）とは？データレイク・データマートとの違いを解説で整理しています。
一方のELTは、同じ3つの工程を「Extract → Load → Transform」の順で行います。抽出したデータをまず生のままDWHに格納し、変換はDWHの内部でSQLを使って実行する方式です。
次の図のように、両者の差は工程の中身ではなく、TransformとLoadの順番、つまり変換を担う場所にあります。
ETLでは変換の主役がETLツールとその実行サーバーであるのに対し、ELTでは変換の主役がDWH自身に移ります。
後述する性能やコスト、柔軟性の差は、突き詰めるとこの一点によるものです。
なお、ETLそのものの仕組みや代表的なツールはETLの基礎解説記事で図解つきで詳しく扱っています。このページでは「両者の違いと使い分け」に絞って進めます。
両者の違いを、「変換のタイミングと場所」「処理性能とスケーラビリティ」「コスト構造」「柔軟性・再利用性」「セキュリティ・ガバナンス」という5つの軸で比較します。まず全体を表で俯瞰してから、各項目を掘り下げます。
| 比較軸 | ETL | ELT |
|---|---|---|
| 変換のタイミングと場所 | DWHに入れる前、ETLツール上で変換 | DWHに入れた後、DWH内部で変換 |
| 処理性能とスケーラビリティ | ETLサーバーの性能が上限 | クラウドDWHの並列処理で拡張しやすい |
| コスト構造 | ツールライセンス＋変換サーバーの維持費 | DWHのストレージ＋クエリの従量課金 |
| 柔軟性・再利用性 | 変換後のデータのみ保持、やり直しは再抽出 | 生データを保持し、何度でも変換し直せる |
| セキュリティ・ガバナンス | DWH投入前にマスキングなどの加工が可能 | 生データがDWHに入るため権限設計が必須 |
ETLでは、データはETLツールの中で加工が完了してからDWHに届きます。DWHに入る時点で「きれいなデータ」だけが存在する状態です。
ELTでは、データソースの内容がほぼそのままDWHにコピーされ、その後にSQLで加工されます。DWHの中に「生データ」と「加工済みデータ」が共存するため、設計の自由度が上がる反面、整理整頓の責任もDWH側に移ります。
ETLの処理性能は、変換を実行するETLサーバーのCPU・メモリが上限になります。データ量が増えるたびにサーバー増強が必要で、スケーラビリティ（データ量の増加に応じて処理能力を拡張できる性質）の面では分が悪い構造です。
ELTの変換はBigQueryやSnowflakeといったクラウドDWHが実行します。これらは数千台規模のマシンで処理を分散する設計のため、数億行のテーブル同士の結合・集計も数十秒〜数分で完了することが珍しくありません。
Evastの現場でも、日次5,000万行規模の広告ログ基盤をETLサーバーでの変換からBigQuery内での変換に切り替えた結果、夜間4時間かかっていたバッチが20分前後まで短縮された例があります。
ETLは、ツールのライセンス費用（エンタープライズ製品では年間数百万円規模のものもあります）と、変換サーバーの維持費という固定費が中心です。データ量が少なくても一定のコストがかかります。
ELTは、DWHのストレージ料金と計算リソースの従量課金が中心です。課金の単位はDWHごとに異なり、BigQueryのオンデマンド料金はクエリがスキャンしたデータ量に、Snowflakeは仮想ウェアハウス（クエリを処理する計算リソースの単位）の稼働時間に応じて課金されます。両者の課金モデルや特性の違いはSnowflakeとBigQueryの比較で詳しく整理しています。
ストレージはBigQueryで1GBあたり月数円程度と安いため、小さく始めて使った分だけ払う形にできます。ただし後述のとおり、計算側の課金は設計を誤ると膨らみやすい点に注意が必要です。
ETLでは変換後のデータしかDWHに残らないため、「集計の粒度を変えたい」「半年前のデータを別の切り口で見たい」となったとき、変換ロジックを直してデータソースから再抽出するしかありません。元システム側でログが消えていれば、復元は不可能です。
ELTは生データをDWHに保持しているので、SQLを書き直して再実行すれば、過去にさかのぼって何度でも変換をやり直せます。分析要件が頻繁に変わる組織ほど、この差が効いてきます。
ガバナンス（誰がどのデータにアクセスできるかを統制する管理ルール）の観点では、ETLに分があります。DWHに入れる前にマスキング（個人名などを伏せ字に置き換える処理）や不要列の除外ができるため、「個人情報をDWHに置かない」という方針を構造的に守れるからです。
ELTでは生データがそのままDWHに入るため、raw層へのアクセス権限の絞り込みや、カラム単位のマスキング設定など、DWH側での権限設計が必須になります。クラウドDWHにはこうした機能が標準で備わっていますが、「設定する人と運用ルール」を用意しないと機能しません。
Modern Data Stack（クラウドサービスを組み合わせて構成する現代型のデータ基盤パターン）では、ELTが事実上の標準になっています。FivetranやTROCCOでデータを運び、BigQueryやSnowflakeに貯め、dbtで変換する。この組み合わせはすべてELT前提の設計です。
ETLが劣っていたから置き換わったのではなく、2010年代に進んだ技術変化がELTの弱点を消し、強みを際立たせました。背景は大きく3つあります。
ELT普及の最大の推進力は、BigQuery（2011年に一般提供開始）、Amazon Redshift（2013年）、Snowflake（2015年）に代表されるクラウドDWHです。
従来のオンプレミス（自社内に機器を設置して運用する形態）のDWHは、ハードウェア導入に数千万円かかるうえ容量も固定で、「生データを全部入れる」という発想自体が非現実的でした。だからこそ、DWHに入れる前に変換して容量を節約するETLが合理的だったのです。
クラウドDWHはこの前提を覆しました。
鍵になったのが「ストレージとコンピュートの分離」、つまりデータの保管領域と計算リソースを別々に拡張・課金できる仕組みです。保管は安価に大量に、計算は必要なときだけ強力に使えるため、「先に全部入れて、あとからDWHの計算力で変換する」ELTが経済的にも性能的にも合理的になりました。
ELT最大の課題は、DWH内に書き散らかされるSQLが無法地帯になりやすいことでした。この課題を解決したのが、2016年に米Fishtown Analytics（現dbt Labs）がオープンソースとして公開した dbt です。
dbtを使うと、SQLの変換ロジックをGitでバージョン管理し、テストを自動実行し、テーブル間の依存関係を可視化できます。「SQLを書ける人なら誰でも、ソフトウェア開発と同じ品質管理のもとで変換処理を作れる」状態になり、ELTの実用性が一気に高まりました。dbtの詳細はdbtの解説記事で扱っています。
変換をDWHに任せられるなら、データ転送ツールは「抽出して運ぶ」ことに専念できます。この割り切りで成功したのがFivetranやAirbyteで、SalesforceやGoogle Analyticsなど数百種類のコネクタ（各サービスと接続するための部品）を使い、ノーコード（プログラムを書かずに画面操作だけで設定する方式）で数時間後にはDWHへのデータ連携が動き始めます。Fivetranは行数（MAR）で課金されるため、対象テーブルの選び方次第で費用が変わる点に注意が必要です。詳しくはFivetranの料金体系とコスト削減｜MAR課金の落とし穴で解説しています。
国内でも、TROCCOが広告媒体や国産SaaSへの対応と日本語サポートを強みに広く使われています。「転送はSaaSに任せ、変換はdbtで書く」という分業が確立したことで、ELTは少人数のデータチームでも運用できる現実的な選択肢になりました。Fivetran・trocco・Airbyte・ASTERIA Warpなど主要ツールを比較した詳細は、データ連携ツールの比較と選び方｜自動化・コスト・コネクタをご覧ください。
主流はELTとはいえ、すべての企業にELTが向くわけではありません。前章の5つの違いのうち、方式選定を実際に左右しやすいのは「セキュリティ・ガバナンス」「処理性能」「柔軟性」の3つです。これに連携先システムの事情を加えた、次の4つの質問に順に答えると、自社に合う方式が見えてきます。
質問1は違い5（セキュリティ・ガバナンス）、質問2は違い2（処理性能）、質問3は違い4（柔軟性）にそれぞれ対応します。質問4だけは5つの違いではなくツールの成熟度の話です。なお、コスト構造（違い3）は方式を決めた結果としてついてくる面が大きいため、質問で絞り込んだ後に試算する項目と考えてください。
それぞれの方式が向くケースをまとめると、次のようになります。
ETLが向くケース：
ELTが向くケース：
なお、実務では二者択一にしないケースも多くあります。Evastのプロジェクトでも、文字コード変換や個人情報の除外といった最低限の加工だけ転送ツール側で行い、ビジネスロジックを含む変換はdbtでDWH内に寄せる、というハイブリッド構成が定番です。
重要なのは「変換ロジックの本体をどこに集約するか」を最初に決めておくことです。
ETL／ELTを含むデータパイプライン全体の考え方や、バッチ／ストリーミングというもう1つの分類軸については、データパイプラインとは？ETLとの違いと仕組みを図解で解説で図解つきで整理しています。
ELTは「とりあえず全部DWHに入れられる」手軽さが魅力ですが、その手軽さが裏目に出る失敗も現場では頻繁に見かけます。導入時に押さえるべきポイントは3つです。
ELT導入企業でもっとも多い失敗が、テーブルの無秩序な増殖です。実際に、運用開始から半年でテーブルが300個を超え、「売上の正しい集計がどれなのか誰もわからない」状態に陥った基盤の立て直しを支援したこともあります。
予防策は、レイヤードアーキテクチャ（データを役割ごとの層に分けて管理する設計）の採用です。図のように、DWH内をraw・staging・martの3層に分け、テーブル名の接頭辞で層を明示します。
従来型の構成にあてはめると、raw層がデータレイク（生データを加工せず安価に貯めておく置き場）、mart層がデータマートに相当します。かつては別々のシステムとして組んでいたこの3層を、ELTではDWH内部のレイヤーとして実現するわけです。
なお、同じ3層をDWH内部の「データレイク層・データウェアハウス層・データマート層」と呼ぶ流派もあります（『実践的データ基盤への処方箋』など日本の書籍でよく使われる命名です）。名前は違っても、役割分担はraw・staging・martとほぼ同じと考えて差し支えありません。
「BIや業務部門が触ってよいのはmart層のみ」と決めるだけでも、数字の食い違いと重複テーブルの大半は防げます。
ELTでは変換や分析のクエリを実行するたびにDWHの計算コストが発生し、無対策だと月額費用が想定の数倍に膨らむことがあります。とくにBigQueryのオンデマンド料金はクエリがスキャンしたデータ量に応じた課金のため、生データへの全件クエリを毎日回すような使い方は禁物です。
mart層の集計テーブルを参照させる、テーブルを日付で分割するといった設計面の対策が有効です。具体的なテクニックはBigQueryの料金体系とコスト削減｜課金トラップと対策にまとめています。
生データを丸ごと取り込むELTでは、raw層に顧客の氏名・メールアドレスなどが含まれがちです。raw層へのアクセスをデータチームの数名に限定する、個人情報カラムにはDWHのマスキング機能を適用するといった権限設計を、運用開始前に済ませておきましょう。
「あとで整備しよう」と先送りした結果、全社員が生の顧客データを参照できる状態で監査の指摘を受ける、というのは、決して珍しくない失敗です。
ETLとELTの違いと、ELTが主流になった理由を整理しました。要点は次の5つです。
方式の選択はあくまで手段であり、出発点は「何のためにデータを使うのか」というビジネス要件です。要件を整理したうえで、自社のデータ量・体制・制約に合った方式を選んでください。この「何のためにデータを使うのか」を経営の視点から整理する考え方については、なぜ今データマネジメントが必要なのか？DX成功の本質を解説もあわせてご覧ください。
株式会社Evastでは、ETL／ELTの方式選定からDWH構築、dbtによる変換パイプライン整備、BIダッシュボード開発まで、一貫したデータ基盤構築を支援しています。
このようなお悩みがあれば、お気軽にご相談ください。方式選定の判断から現状診断、アーキテクチャ設計、移行計画の策定までを伴走します。
データ連携（ETL/ELT）ツールの料金相場と、費用を抑える方法を解説します。従量課金・定額・OSSという3つの課金モデルの違いと損益分岐、主要ツールの月額の目安、Fivetranの請求が跳ねる仕組み、同期頻度や増分同期などのコストダウン6手、そして「OSSは無料ではない」というTCOの考え方まで。予算組みや稟議で費用を見積もる担当者向けです。
データ連携・データ統合ツールの選び方と比較を現場目線で解説します。SaaSと社内DBを自動で統合するETL/ELTツールを「運用体制・コスト体系・コネクタ要件」の3軸で整理し、trocco・ASTERIA Warp・Fivetranなど主要ツールを一覧で比較。従量課金とライセンスの違いやコストを抑えるコツ、導入後の落とし穴までまとめました。
データパイプラインとは何か、ETLとの違い（包含関係）はどこにあるのか、そして2026年時点でどう設計するのが定石か。処理タイミング（バッチ／ストリーミング）・変換の場所（ETL／ELT）・責任分担（マネージド／自作）の3軸で設計判断を整理し、Airflowによるオーケストレーション、監視・リトライ・冪等性の運用要点、AI連携で変わる新常識、Evastの現場で見た落とし穴3つまでを図解でまとめます。手作業のデータ集計を自動化したい情シス・データ担当者向け。
dbtとは何かを、散らばった変換SQLの管理に悩むデータ担当者向けに解説します。ELTの「T」を担う役割、Modelファイル・ref関数・テスト・ドキュメント自動生成の4機能、BigQueryとの親和性、3ステップの導入プロセスまで整理します。
