EL vs ETLとデータ取り込みツール選定：Fivetran・Airbyte・自前ELの判断軸

dbtで変換は書ける、品質も担保した、オーケストレーターで動かす段取りも組んだ。残るは「ソースからデータを取り込む」入口の工程です。じつは多くのチームが、ここで最初に詰まります。基幹システムや業務SaaSからどう持ってくるか、APIのレートリミットにどう対処するか、差分取り込みをどう作るか。地味で目立たない領域ですが、止まると全部止まります。

取り込み（Extract & Load）の主な選択肢は、Fivetran・Airbyte・自前ELの3つに集約できます。それぞれの強みと、自社に合う選び方を整理します。

なぜ「EL」なのか

クラウドDWHが普及する前は、ETL（Extract→Transform→Load）が定石でした。ソースから抽出し、専用サーバーで変換してから、DWHに入れる流れです。クラウドDWHの登場でこの順序が逆転し、EL（Extract→Load）でまず生データをDWHに入れ、変換（Transform）はDWHの中でdbt等で行うパターンが主流になりました。

クラウドDWHは計算力を必要なだけ使えるので、変換をDWH側に任せられます。これにより、取り込み側は「生データをそのまま運ぶ」というシンプルな役割に集約され、Fivetranのようなマネージドサービスが成立する土壌ができました。クラウドDWHの基本はクラウドDWH入門を参照してください。

3つの選択肢の位置づけ

マネージドの安心を取るならFivetran、コストとカスタマイズを取るならAirbyte、独自要件で他に選択肢がない場合は自前、と覚えると整理しやすい。

それぞれの強みと弱み

Fivetran

マネージドELのカテゴリーを切り拓いた商用SaaSです。SalesforceやHubSpot、Stripe、Shopifyといったメジャーな業務SaaS、主要DB、各種クラウドへの500以上のコネクタを持ち、接続情報を入れるだけで取り込みが始まります。スキーマ変更の自動追従、差分取り込み、リカバリの自動化まで運用は完全に任せられます。

強みは、運用負荷の劇的な軽さと、対応コネクタの豊富さです。弱みは、MAR（Monthly Active Rows）従量課金で規模が増えると費用が大きく跳ねること、変換ロジックを含む柔軟なカスタマイズには向かないことです。詳細はFivetran とはで扱います。

Airbyte

OSSのデータ取り込み基盤で、急成長しているカテゴリーの代表です。400以上のコネクタが用意され、独自コネクタを作るためのCDK（Connector Development Kit）も提供されています。Airbyte Open SourceとAirbyte Cloud（マネージドSaaS）の2形態があり、両方で同じコネクタを使えます。

強みは、OSSで自社でホスティングでき、コストをコントロールしやすいこと、カスタムコネクタを作れることです。弱みは、自前運用時の管理負荷とコネクタ品質のばらつき、Fivetranほどの「完全自動運用」の安心感はまだ追いついていないことです。詳細はAirbyte とはで扱います。

自前EL

Pythonスクリプトや、AirflowのOperatorを使って自社で取り込みを書く選択肢です。FivetranやAirbyteで対応していない独自APIへのアクセス、特殊な認証フロー、複雑な前処理が必要な場面で選びます。dlt（data load tool）やMeltanoのようなOSSフレームワークも、自前ELを支援するために登場しています。

強みは、完全に自由に書けること、ライセンス費用がかからないことです。弱みは、運用負荷が圧倒的に高いこと、スキーマ変更・差分取り込み・リカバリのロジックを自前で作り込む必要があることです。詳細と判断軸は自前ELの判断軸で扱います。

選定の判断軸

dbt・オーケストレーターとの組み合わせ

取り込みツールは単独で運用するわけではなく、変換層や監視層と連携します。組み合わせの全体像は次のようになります。

Fivetran・Airbyteは独自のスケジューラを内蔵していますが、複雑な依存関係を組むときはオーケストレーターから呼び出すパターンになります。dbtのrunを取り込み完了後に走らせる、品質チェックを取り込みの直後に挟む、といった連携が、AirflowやDagsterで組まれます。

どこから始めるか

• ステップ1：取り込み対象を棚卸しし、ソースの種類とデータ量を見積もる
• ステップ2：メジャーなSaaS/DBが中心ならFivetranで始める（運用負荷の低さがいちばん効く）
• ステップ3：費用が想定を超えてきたら、AirbyteへMARの大きい接続だけ移す
• ステップ4：対応コネクタがない独自要件のみ、自前ELで補完する

最初から全部自前で書く必要はありません。Fivetranで「動く状態」を最短で作り、コストと柔軟性のバランスで段階的に最適化していくのが、結果として最短距離になります。

まとめ

• クラウドDWHの普及で、ETLは「ELして後で変換」の形に変わった。
• 主な選択肢はFivetran（マネージド）・Airbyte（OSS）・自前EL（独自要件）。
• 運用負荷の軽さ＝Fivetran、コスト・柔軟性＝Airbyte、独自要件＝自前。
• マネージドの安心と費用の天秤で、Airbyte Cloudが中間解として有力。
• dbt・オーケストレーターと組み合わせて「データパイプライン全体」を構成する。

各ツールの詳細はFivetran とは・Airbyte とは・自前ELの判断軸にまとめています。データ取り込みの設計や移行の壁打ちは、DE-STKの初回相談（30分・無料）もご利用ください。

よくある質問（FAQ）

Q. Fivetranは高いと言いますが、いくらくらいかかりますか？

A. 価格はMAR（Monthly Active Rows）で決まり、利用量によって大きく変動します。小規模で月数万円から、エンタープライズでは年数千万円規模もあり、見積もりが必要なタイプの料金体系です。「規模が小さい間は安く、伸びると一気に跳ねる」と言われるのはこのためです。利用前にMARの試算を取り、Airbyteとの費用比較をしてから契約するのが安全です。

Q. Airbyte Open Sourceを自社運用するのは現実的ですか？

A. 技術力があるチームなら現実的です。Kubernetes上に立てて、コネクタの管理・アップデート・モニタリングを自前で行います。データエンジニアが2〜3名以上いて、コンテナ基盤を運用できるなら、Fivetranより大幅にコストを抑えられます。逆に、運用人員が薄いチームは、Airbyte Cloudの方が結果として安く済むことが多いです。

Q. ETLツール（Talendなど）からの移行は必要ですか？

A. すぐに必要というわけではありません。既存のETLが安定稼働していれば、無理に移行する必要はありません。けれども、新規のデータソースを足すたびに開発工数が膨らんでいる、クラウドDWHへ移行したいけどETL側がボトルネック、というケースでは、ELへの段階的移行を検討する価値があります。一気に全部置き換えるのではなく、新規ソースだけFivetran/Airbyteで始める、という併走運用が安全です。

Q. dltやMeltanoは、Fivetran/Airbyteとどう違うのですか？

A. dlt（data load tool）とMeltanoは、自前ELを書きやすくするOSSフレームワークです。FivetranやAirbyteのような「接続済みのコネクタを使う」スタイルではなく、Pythonコードを書いて取り込みを構築するスタイルです。柔軟性は高いものの、コネクタ自体は自分で書きます。Fivetran/Airbyteで対応していない独自APIや、複雑な認証フローが必要な場面で、自前ELの「下地」として使う選択肢です。