ETLとELTの違いと選び方｜データ連携基盤のツール選びと設計の考え方
販売管理、会計、CRM、広告、Webアクセス解析など、複数のシステムのデータを組み合わせて分析しようとすると、必ず必要になるのが「データを取り出し、整え、分析用の場所へ運ぶ」仕組みです。この仕組みの作り方として、ETLとELTという2つの考え方があります。
両者の違いは、データを整える処理（変換）を、分析用の場所に入れる前に行うか、入れた後に行うかにあります。言葉の違いはわずかですが、どちらを選ぶかによって、使うツール、必要なスキル、費用のかかり方、トラブルが起きたときの直しやすさが変わります。
クラウドのデータウェアハウスが普及してからはELTが主流になりつつありますが、すべての場面でELTが正解というわけではありません。個人情報を基盤に入れる前に取り除きたい場合や、取り込み先の処理能力が限られている場合など、ETLのほうが適した場面もあります。
この記事では、ETLとELTの違い、それぞれが向いている場面、データ連携ツールの種類と選び方、設計で押さえるべきポイント、失敗しやすいパターンと対策を、発注側が判断に使える形で解説します。
ETLとELTの違いは変換を行う場所にある
ETLとELTは、どちらもExtract（抽出）、Transform（変換）、Load（読み込み）の3つの処理の頭文字です。違いは処理の順番にあります。
| 項目 | ETL | ELT |
|---|---|---|
| 処理の順番 | 抽出したデータを専用の処理環境で変換し、整えた結果を分析用の場所に読み込む | 抽出したデータをそのまま分析用の場所に読み込み、その中で変換する |
| 変換を行う場所 | ETLツールや専用のサーバー | データウェアハウス（主にSQLで変換） |
| 分析用の場所に入るデータ | 整えた後のデータだけ | 加工前の元データと、整えた後のデータの両方 |
| 変換ルールを変えたとき | 元データの抽出からやり直すことが多い | 基盤内の元データから変換し直せる |
| 必要なスキル | ETLツールの操作や、処理を書くプログラミング | SQLと、データウェアハウスの料金・性能の理解 |
ELTの最大の利点は、元データが基盤の中に残ることです。後から「この指標の定義を変えたい」「過去にさかのぼって別の切り口で集計したい」となったときに、元のシステムからデータを取り直さずに済みます。一方で、元データをすべて基盤に入れるため、ストレージの費用や、変換処理にかかるデータウェアハウスの費用は増えます。また、個人情報などを含む元データが基盤に入ることになるため、アクセス権限の管理がより重要になります。
売上データを例にした違い
たとえば、販売管理システムの売上明細と、CRMの顧客情報を組み合わせて、顧客の業種別に月次の売上を見たいとします。ETLで組む場合は、両方のシステムからデータを取り出した後、専用の処理環境で顧客コードを突き合わせ、業種別・月別に集計した結果だけをデータウェアハウスに入れます。ELTで組む場合は、売上明細と顧客情報をそれぞれそのままデータウェアハウスに入れ、その中でSQLを使って突き合わせと集計を行います。
後日、「業種別ではなく地域別でも見たい」という要望が出たとき、ETLでは処理環境の集計処理を作り直し、元のシステムからデータを取り直す必要があります。ELTでは、基盤内に残っている明細と顧客情報から、地域別の集計を追加で作るだけで済みます。集計の切り口が今後も増えそうなら、ELTの利点が大きく効いてきます。
ELTが広がった背景と、ETLが向いている場面
かつてのデータウェアハウスは自社で運用するサーバー上にあり、処理能力にもストレージにも限りがありました。そのため、データを入れる前に必要な形に整え、量を減らしておくETLが合理的でした。
BigQueryやSnowflake、Amazon Redshiftなどのクラウドのデータウェアハウスが普及すると、大量のデータを保管し、SQLで高速に変換することが容易になりました。あわせて、SQLで書いた変換処理をバージョン管理しながら運用するツールも広がり、元データをまず入れてから基盤内で整えるELTが現実的な選択肢になりました。
それでも、次のような場面ではETL、またはETLとELTの組み合わせが向いています。
- 個人情報や機密情報を、基盤に入れる前に削除・マスキングしなければならない
- 取り込み先がクラウドのデータウェアハウスではなく、処理能力の限られた業務システムのデータベースである
- 画像や音声、複雑な形式のファイルなど、SQLでは変換しにくいデータを扱う
- 元データの量が非常に多く、必要な部分だけを取り込まないと費用が見合わない
実務では、個人情報の除去や形式の変換だけを取り込み前に行い（ETL的な処理）、集計や指標の計算は基盤内で行う（ELT的な処理）という組み合わせが多く見られます。ETLかELTかを二択で考えるより、「どの変換を、どこで行うか」を変換ごとに決めるほうが実態に合っています。
データ連携ツールの種類と選び方
データ連携の仕組みを作る方法は、大きく次の4つに分けられます。
| 種類 | 概要 | 向いている場合 |
|---|---|---|
| SaaS型のデータ連携ツール | Fivetranなど。多数のSaaSやデータベースへの接続部品（コネクタ）が用意されており、設定だけで定期的な取り込みができる | 接続先が一般的なSaaSで、社内に開発者が少ない |
| クラウド事業者の連携サービス | BigQuery Data Transfer Service、AWS Glueなど。各クラウドのデータウェアハウスとの組み合わせを前提とする | 使うクラウドが決まっていて、そのサービスが接続先に対応している |
| オープンソースのツール | 自社の環境で動かせるデータ連携ツールや、SQLの変換処理を管理するツール | ライセンス費を抑えたいが、運用を担える技術者がいる |
| 個別開発 | APIやファイルからデータを取り出す処理を、プログラムで作る | 既製ツールが対応していない社内システムや、特殊な形式のデータを扱う |
料金の考え方もツールによって異なります。たとえばFivetranは、1か月の間に追加・更新された行数（Monthly Active Rows、MAR）を基準に課金する方式で、無料プランでは月50万MARまで無料で使えます。ただし、この無料枠は無料プランだけのもので、有料プランに切り替えると実際のMARに応じて課金されます（2026年10月時点）。BigQuery Data Transfer Serviceは、公式の料金ページによると、Google広告やGoogleアナリティクス4、Cloud Storageなどの接続先は転送の管理にかかる部分が無料で、SalesforceやMySQLなどの接続先は処理に使ったスロット時間に応じて課金される区分になっています。取り込んだデータの保管料金は別にかかります。いずれも料金体系は改定されることがあるため、契約前に公式ページで確認してください。
ツールを選ぶときは、まず接続したいシステムの一覧を作り、それぞれに既製のコネクタがあるかを確認します。すべてに既製のコネクタがあればSaaS型やクラウド事業者のサービスで十分です。対応していない社内システムが残る場合は、その部分だけ個別開発し、他は既製のツールを使うという組み合わせが現実的です。費用を比較するときは、ツールの利用料だけでなく、データ量の増加に伴う課金の伸び方と、運用にかかる人の手間も含めて見積もります。
ツール選定で確認したい項目
候補のツールを比較するときは、機能の多さよりも、自社の運用に合うかどうかを確認します。最低限、次の項目は試用期間中や商談の場で確かめておくと安心です。
- 接続したいシステムのコネクタが、試験的な提供ではなく正式な機能として提供されているか
- 取り込みの頻度をどこまで細かくでき、頻度を上げたときに料金がどう変わるか
- 元のシステムで項目が追加・変更されたとき、自動で追従するのか、手作業の設定が必要か
- 連携が失敗したときに、どのような形で通知され、どこから再実行できるか
- データが国内外どこを経由・保管されるか（個人情報を扱う場合）
特に、項目の変更への追従と失敗時の通知は、導入後の手間を大きく左右します。デモの画面では分かりにくい部分なので、実際に自社のデータで小さく試してから判断することをおすすめします。
設計で押さえるべきポイント
どのツールを使う場合でも、設計の段階で決めておきたい点は共通しています。
更新頻度と鮮度
データを日に1回取り込めば足りるのか、1時間ごとに必要なのか、リアルタイムに近い鮮度が必要なのかを、利用者の判断のタイミングから決めます。鮮度を上げるほど費用と運用の負担は増えます。毎朝の会議で前日の数字を見るだけなら、日次の取り込みで十分です。
全件取り込みか差分取り込みか
データ量が少ないうちは毎回全件を取り込む方式でも問題ありませんが、量が増えると処理時間と費用が膨らみます。更新日時などで変更分だけを取り込む差分方式にするには、元のシステムに更新日時の列があるか、削除されたデータをどう検知するかを確認する必要があります。
層の分け方
ELTでは、取り込んだままの元データの層、表記揺れや型を整えた層、指標を計算した集計の層というように、データを段階的に整える構成が一般的です。層を分けておくと、問題が起きたときにどの段階でおかしくなったのかを特定しやすくなります。
失敗時の検知と再実行
データ連携は、元のシステムの仕様変更や認証の期限切れ、ネットワークの障害などで必ずどこかで失敗します。失敗を自動で検知して通知する仕組みと、同じ処理を再実行しても重複や欠落が起きない設計（冪等性）を用意しておくことが、安定運用の前提です。
データ品質のチェック
連携の処理が正常に終わっていても、中身のデータがおかしいことがあります。前日と比べて件数が極端に少ない、必須のはずの項目が空になっている、金額がマイナスになっているといった異常は、処理の成否だけでは検知できません。取り込みのたびに件数や主要な項目の値を自動で確認し、普段と大きく違う場合に通知する仕組みを入れておくと、誤った数字が会議資料に載る前に気づけます。最初から細かなチェックを網羅する必要はなく、件数の急減と主要項目の欠損の2つから始めるだけでも効果があります。
失敗しやすいパターンと対策
データ連携の仕組みは、作った直後よりも、運用を続ける中で問題が表面化します。よくある失敗と対策は次のとおりです。
| 失敗のパターン | 起きること | 対策 |
|---|---|---|
| 変換処理が担当者の頭の中にしかない | 担当者が異動・退職すると、数字の根拠を誰も説明できなくなる | 変換処理をSQLやコードとして管理し、指標の定義を文書に残す |
| 連携の失敗に気づかない | 数日前からデータが更新されていないダッシュボードで判断してしまう | 失敗時の通知と、データの最終更新日時の表示を必ず用意する |
| BIツールの中で変換している | ツールごとに計算式が異なり、部署間で数字が合わない | 指標の計算はデータウェアハウス側にまとめ、BIツールは表示に専念させる |
| 元のシステムの変更が知らされない | 項目の追加や名称変更で、連携が止まったり値がずれたりする | 元のシステムの改修予定をデータ担当者に共有する運用ルールを作る |
| 費用の伸びを見ていない | データ量の増加に比例して、連携ツールやデータウェアハウスの費用が膨らむ | 月次で費用とデータ量の推移を確認し、差分取り込みや保存期間を見直す |
開発会社に構築を依頼する場合は、これらの対策が提案や納品物に含まれているかを確認してください。特に、変換処理の管理方法、失敗時の通知先、再実行の手順は、納品後に自社で運用するうえで欠かせない情報です。
まとめ
ETLは変換してから読み込む方式、ELTは読み込んでから基盤内で変換する方式です。クラウドのデータウェアハウスを使い、元データを残して後から集計方法を変えたいならELTが向いています。個人情報を基盤に入れる前に取り除く必要がある場合や、SQLでは変換しにくいデータを扱う場合はETLが向いており、実務では両者を組み合わせて「どの変換をどこで行うか」を決めるのが現実的です。
ツールは、接続したいシステムに既製のコネクタがあるかどうかで選び、対応していない部分だけを個別開発します。明日からできることとしては、連携したいシステムの一覧を作り、それぞれについて必要な更新頻度、更新日時の列の有無、個人情報を含むかどうかを書き出してみてください。この一覧があれば、ETLとELTのどちらで組むべきか、どのツールを試すべきかを具体的に判断でき、開発会社への相談もスムーズに進められます。