ETLとELTは文字を並べ替えただけに見えますが、データを『どこで、いつ変換するか』が異なります。流行している方式を選べばよいと思うと、個人情報を生のまま置いたり、逆に変更のたびに連携処理を作り直したりします。
結論として、変換してから保存するのがETL、まず保存して保存先で変換するのがELTです。クラウドDWHではELTが使いやすい場面が増えましたが、機密情報の除去や形式の厳格な検査は取り込み前に必要な場合があります。実務では目的ごとに組み合わせるのが自然です。
最初に結論
ETLはExtract（抽出）→Transform（変換）→Load（格納）、ELTはExtract→Load→Transformの順です。再加工や履歴保持を重視するならELT、保存前に必ずマスキング・除外・標準化すべきデータがあるならETLまたは前処理付きELTを検討します。
この記事のポイント
- ・違いは変換処理を保存前に行うか、保存先で行うかという順番と実行場所
- ・ELTは元データを保持して変換をやり直しやすい一方、権限と費用の管理が必要
- ・ETLは保存前の統制に向く一方、要件変更時にパイプライン改修が増えやすい
- ・機密除去だけ前段で行い、事業ロジックはDWHで変換するハイブリッドも一般的
対象：クラウドDWHやデータ連携を初めて検討する事業担当者、エンジニア、分析担当者
1. ETLとELTは変換の順番が違う
ExtractはShopify、広告媒体、基幹システムなどからデータを取得する工程です。Transformは型、時刻、重複、税、返品などを分析ルールに沿って整える工程、LoadはDWHなどの保存先へ格納する工程です。ETLは変換済みだけを格納し、ELTは取得した形に近いデータを先に格納してからDWHの計算能力で変換します。
AWS、IBM、Google Cloudの解説はいずれも、この処理順を中心に両者を区別しています。ただし製品名だけで方式は決まりません。取得ツール内で列を削除してからBigQueryへ保存し、その後dbtで売上を計算するなら、前処理とELTを組み合わせた構成です。現実のパイプラインは境界が混ざることがあります。
| 観点 | ETL | ELT |
|---|---|---|
| 処理順 | 抽出→変換→格納 | 抽出→格納→変換 |
| 主な変換場所 | 連携サーバー・専用処理 | DWH・データ基盤 |
| 元データ保持 | 変換後だけの場合がある | 原形に近い層を残しやすい |
| 要件変更 | 前段処理の改修が必要 | 保存済みデータから再計算しやすい |
| 主な注意 | 処理時間と変更の硬直化 | 権限、機密情報、保存・計算費用 |
2. ETLが向く場面と注意点
保存先へ入れてはいけない個人情報を削除・マスキングする、規定の形式に合わないレコードを拒否する、容量や計算資源が限られた保存先へ必要な項目だけ渡す、といった要件ではETLが分かりやすい選択です。データが格納される前に品質とセキュリティの関門を置けます。
一方で、変換仕様が連携処理へ強く組み込まれると、売上定義や項目追加のたびにパイプラインを修正し、過去分を取り直す必要が出ます。変換前データを捨てていれば、新しい定義で再計算できません。ETLを選ぶ場合も、監査に必要な原本をどこへ安全に保持するか、失敗データをどう再処理するかを決めます。
- 保存前に必ず機密列を除去・匿名化する必要がある
- 受け入れ可能な形式や品質が契約・規制で厳密に決まっている
- 保存先の容量や処理能力が限定され、必要データだけを渡したい
- 変換ルールが安定し、上流で一元管理するほうが運用しやすい
3. ELTがクラウドDWHで使われる理由
ELTでは、取得したデータを先にDWHへ置き、SQLなどで分析用テーブルへ変換します。元に近いデータを保持できれば、返品の定義が変わったときも過去分を再計算できます。取り込みと事業ロジックを分離できるため、分析担当者がSQLで素早く改善し、同じ処理をレビューしやすいことも利点です。
ただし『生データを何でも保存すればよい』という意味ではありません。閲覧権限が広い領域へ個人情報を置かない、不要な列を取得しない、保持期間を決める、パーティションや差分処理で計算量を抑える、といった統制が必要です。DWHの計算能力を使えることと、無制限に使ってよいことは別です。
- 変換ルールが頻繁に変わり、履歴を新しい定義で再計算したい
- 複数チームが同じ取得データから異なる分析モデルを作る
- SQL、テスト、バージョン管理で変換を共同管理したい
- クラウドDWHの伸縮する計算能力を利用できる
4. ShopifyからBigQueryへ送るD2Cの例
注文、注文明細、顧客、返金をShopifyから日次で取得し、BigQueryの取り込み層へ格納します。この時点では元サービスのID、時刻、金額を保ち、取得日時も追加します。メールアドレスなど分析に不要な個人情報は、取得しないか、格納前にトークン化する設計を選びます。これがセキュリティ上の前処理です。
次にdbtなどを使い、タイムゾーン、通貨、税、キャンセル、返品を統一し、注文単位や顧客単位の分析モデルを作ります。BIはそのモデルから売上、購入率、LTVを読みます。指標定義を直したら、元に近いデータから変換を再実行できます。ただしAPI側で取得できなかった履歴はDWHだけでは復元できないため、初回取得範囲を確認します。
- 抽出：APIから必要な注文・返金データと更新時刻を取得する。
- 安全な前処理：不要な個人情報を除き、格納可能な権限・形式か確認する。
- 格納：元IDと取得日時を保ってBigQueryの制限付き領域へ保存する。
- 変換：SQLで時刻・税・返品を統一し、分析用の注文・顧客モデルを作る。
- 検証・公開：件数と金額を元サービスと照合し、権限を分けてBIへ提供する。
5. ETLかELTかを選ぶ5つの質問
方式を選ぶときは、まず保存前に除去すべき情報があるかを確認します。次に、変換ルールの変更頻度、過去の再計算、処理量、利用者のスキル、費用と運用責任を評価します。『クラウドなら必ずELT』『機密データなら必ずETL』のような一律の答えではなく、工程ごとに要件を置くことが重要です。
少人数でデータ量も少なく、目的が一つなら、管理された連携サービスとSQL数本から始められます。大規模でも、すべてを一つの方式へ統一する必要はありません。カード情報は上流で除外し、一般的な注文項目は先に格納し、事業ロジックはDWHで変換するという分担ができます。
- 保存前に削除・匿名化・検査しなければならない列はあるか
- 変換ルールはどの程度変わり、過去分を再計算する必要があるか
- データ量と必要な更新速度に対して、どこで計算するのが合理的か
- SQL・パイプライン・権限を誰が継続して管理するか
- 障害時の再実行、照合、費用監視をどう行うか
6. よくある失敗と運用チェック
よくある失敗は、全量を毎回取り直して費用と時間が膨らむ、削除や更新を反映できず数字が二重になる、タイムゾーンの違いで日次売上が合わない、変換失敗を通知せず古いデータを見せることです。更新キー、削除の扱い、再実行時の重複防止、遅延許容時間を設計時に決めます。
パイプラインごとに最終成功時刻、取得件数、変換後件数、主要金額、失敗理由を記録します。運用開始後は、速さだけでなく、同じ入力から同じ結果を再現できるか、権限のない人が生データへ到達できないかを定期確認します。方式の名前より、この地道な運用が信頼できる分析を支えます。
次に読む記事
参考文献
本記事は以下の公式文書、標準、論文、公開記事・投稿を確認し、初心者向けに論点を再構成しています。 仕様や制度は更新されるため、導入時はリンク先の最新版も確認してください。
- ETL vs ELT — Amazon Web Services（最終確認：2026-08-07）：処理順、利用場面、特徴の比較を参照。
- ELT vs ETL: What's the difference? — IBM（最終確認：2026-08-07）：変換場所とアーキテクチャ上の違いを参照。
- What is ELT? — Google Cloud（最終確認：2026-08-07）：クラウド環境におけるELTの仕組みと注意点を参照。
- What is ELT? — dbt Labs（最終確認：2026-08-07）：分析変換をDWH内で管理する考え方を参照。
よくある質問
クラウドDWHなら必ずELTを選ぶべきですか？
必ずではありません。DWH内の再計算にはELTが便利ですが、保存禁止データの除去や厳格な受入検査は前段で行う必要があります。工程ごとにETLとELTを組み合わせてください。
ELTでは生データをそのまま全員が見られますか？
見られる状態にすべきではありません。取り込み領域の権限を絞り、不要な機密列は取得・保存せず、利用者には変換済みの必要最小限のデータを公開します。
ETLからELTへ一度に移行する必要がありますか？
ありません。変更頻度が高い分析ロジックからDWH側へ移し、機密除去など安定した前処理は残す段階移行が可能です。件数・金額の照合を保ちながら進めてください。
まとめと次の一歩
ETLとELTは二者択一ではなく、変換をやり直したい範囲と保存前に統制すべき範囲を分ける設計判断です。機密情報の除去は前段、変更の多い事業ロジックはDWH側というように責任を配置すると、安全性と開発速度を両立できます。