Fivetran・Airbyteとは|ELTツールの違いと選び方
最終更新日:2026/10/15
Fivetran・Airbyteとは、SaaSやデータベースの情報をDWHへ取り込む「EL」を担うELTツールです。変換はdbtなど別のツールに任せる設計のため、選定を誤ると運用コストが跳ね上がります。データ基盤に関わるエンジニア向けに、両者の違いと選び方の判断軸を整理します。
先に結論
Fivetran・Airbyteが担うのは「EL(取り込みとロード)」まで。SQLによる変換(T)はdbtなど別ツールの役割で、役割分担を前提に選ぶ
運用を外注したいならFivetran、データの所在と費用を自前で握りたいならAirbyte。多くのケースではこの軸が出発点になります
Fivetranの課金はMAR(月間アクティブ行数。月内に追加・更新・削除された行の数)。行の更新頻度が高いテーブルほど費用が膨らみやすいため、見積もりは接続前のサンプル同期で確かめる
Airbyteはセルフホスト版(Airbyte Core)が無料。ただしインフラ費と障害対応の工数は自分持ちになる
2026年6月にFivetranとdbt Labsの統合が完了し、EL層とT層が同一ベンダーに集約された。中立性を重視するならAirbyteの相対的な価値が上がっている
対象読者は、データ基盤の構築・移行に関わるエンジニア(SQLとクラウドDWHの基礎知識がある方)を想定しています
この記事でわかること
FivetranとAirbyteがデータ基盤のどの範囲を担当し、dbtやAirflowとどう分担するのか
両者の課金モデルの違いと、費用が想定外に膨らむ条件
コスト・コネクタ・運用体制・データ所在の4軸で選ぶ判断フロー
スタートアップ/事業会社/受託/規制業界のケース別パターン
ELT導入案件にフリーランスがどう関わるか、単価の傾向はどう見るか
目次
Fivetran・Airbyteとは|ELTツールが担う範囲
Fivetranの特徴とMAR課金の仕組み
Airbyteの特徴とOSS版・Cloud版の違い
Fivetran・Airbyteの違いを比較表で整理
失敗しない選び方|4つの判断軸と導入チェックリスト
2026年の最新動向|Fivetranとdbt Labsの統合
ケース別の選択パターン
導入でよくある失敗と対策
ELTツール案件の単価傾向とフリーランスの関わり方
まとめ
よくある質問
Fivetran・Airbyteとは|ELTツールが担う範囲
Fivetranとは、SaaS・データベース・広告ツールなどのデータを、BigQueryやSnowflakeといったDWHへ自動で同期するフルマネージド型のデータ連携サービスです。Airbyteは同じ領域をオープンソースで提供するツールで、自社サーバーへのセルフホストにも対応します。
いずれも「データをどこからか持ってきて、DWHにそのまま置くまで」を自動化する役割です。SQLで整形・集計する工程は含みません。
なお本記事に記載した料金・プラン・コネクタ数・同期頻度などの数値は、2026年10月時点で各社の公式ページを確認した内容です。これらは変動しやすい情報のため、実際の検討時は公式ページで最新の条件を確認してください。
ETLとELTの違い
従来のETLは、取り込みの途中でデータを変換してからDWHに入れる方式でした。ELTは順番が変わります。まず生データをDWHへロードし、変換はDWHの計算資源で後から行う。BigQueryやSnowflakeのように安価で強力なDWHが普及したことで、この順番が実務的に成立するようになりました。
ELTの利点は、生データが手元に残ることです。変換ロジックを間違えても、ロードし直さずにSQLを書き直すだけで復旧できます。
方式 | 変換の場所 | 生データの保持 | 主な担い手 |
|---|---|---|---|
ETL | 取り込み処理の途中 | 残らないことが多い | 専用ETL製品、自前バッチ |
ELT | DWHの中(ロード後) | DWHに残る | Fivetran・Airbyte+dbt |
「EL」と「T」は別のツールが担当する
FivetranとAirbyteが面倒を見るのは、コネクタでソースに接続し、差分を検知してDWHの生データ層(Raw層。加工前のデータをそのまま置いておく領域)へ書き込むところまでです。そこから先のモデリングは別の話になります。
変換層の設計やテスト・系譜管理については、dbtとは|データ変換(ELT)の仕組み・使い方・案件単価で詳しく扱っています。本記事では変換そのものには踏み込まず、取り込みツールの選定に絞ります。
また、「いつ・どの順番で動かすか」を制御するオーケストレーションも別レイヤーです。こちらはApache Airflowとは|DAGの仕組み・dbt/Dagsterとの違い・案件単価を参照してください。
なぜ取り込みだけを専用ツールに任せるのか
自前でAPI連携を書くと、最初の実装よりも保守が重くなります。SaaS側のAPI仕様変更、レート制限、ページネーション、スキーマ変更への追従。接続先が10個を超えたあたりから、この保守だけで人が一人張り付く状態になりがちです。
コネクタ型のELTツールは、この保守をベンダーまたはOSSコミュニティに寄せる仕組みです。
このセクションのミニFAQ
Q. ELTツールを入れればdbtは不要になりますか。
いいえ。役割が重なりません。FivetranもAirbyteも簡易な変換機能は持ちますが、依存関係の管理やテストを伴う本格的なモデリングはdbt側で組むのが一般的です。
Q. 生データ層(Raw層)はそのまま分析に使ってよいですか。
推奨されません。ソースのスキーマ変更がそのまま分析クエリを壊すためです。Raw層は保管用と位置づけ、分析は変換後のモデルに向ける構成が安全です。
Fivetranの特徴とMAR課金の仕組み
結論から言えば、Fivetranは「運用工数をお金で買う」タイプのツールです。フルマネージドのSaaSで、コネクタの保守はベンダー側が担います。
コネクタと自動スキーマ管理
Fivetran公式サイトによれば、Salesforce・HubSpot・NetSuiteをはじめとする多数のSaaSやデータベースに対応した事前構築済みコネクタが提供されています。公式の料金ページでは、Standardプラン以上で700以上のコネクタに対応すると案内されています(執筆時点の公式表記)。
実務で効くのは自動スキーマ管理です。ソース側で列が追加されたり型が変わったりした場合、その変更を下流のDWHへ自動的に反映します。手作業でのスキーマ追従が減るぶん、データエンジニアの定常作業は軽くなります。
MAR課金の仕組みと見積もりの注意点
Fivetranの課金単位はMAR(Monthly Active Rows=月間アクティブ行数)です。Fivetranの料金ページでは、MARはカレンダー月内にFivetranが処理した行数を指し、新規追加行と既存行の更新・削除が対象、変更のない行と初期同期分は対象外と説明されています。
ここが見積もりの難所になります。テーブルの行数ではなく、月あたりに動いた行数で課金されるためです。
行数は少ないが更新が頻繁なマスタ系テーブル → MARが膨らみやすい
行数は多いが追記のみのログ系テーブル → 新規行ぶんのMARで読みやすい
「最終更新日時」列が全行更新されるような設計のソース → 想定外に跳ねる典型
公式の無料枠は、接続で月間50万MAR、アクティベーションで月間3,500MAR、変換で月間5,000モデル実行までと案内されています。また各新規接続には14日間の無料トライアルが用意されています。本番契約の前に、この枠でサンプル同期を回してMARの実測値を取っておくと、見積もりのズレを抑えられます。
同期頻度はプランで変わり、公式ページではStandardが15分間隔、Enterpriseが1分間隔と案内されています。
Fivetranが向いているケース
データエンジニアの人数が限られていて、コネクタ保守に工数を割きたくない組織です。SaaSの数が多く、かつ接続先が主要なメジャーSaaSで占められている場合は、事前構築済みコネクタの恩恵が大きくなります。
Airbyteの特徴とOSS版・Cloud版の違い
結論として、Airbyteは「自前で握る」選択肢です。OSSとして公開されており、セルフホストすればライセンス費用はかかりません。
Airbyte CoreとCloudプランの違い
Airbyte公式サイトでは、セルフホスト版がAirbyte Coreとして案内されています。DockerやKubernetes上に自分で立てる構成で、ライセンス費用は無料です。
一方、マネージドで使いたい場合はCloudプランがあります。Airbyteの料金ページでは、執筆時点で次のような区分が案内されています。
プラン | 形態 | 課金単位 |
|---|---|---|
Core | セルフホスト(OSS) | ライセンス費用なし |
Standard | クラウド | データ量ベースの従量課金 |
Plus | クラウド | クレジットパッケージ制 |
Pro / Enterprise Flex | クラウド・ハイブリッド | 容量ベース(Data Workers)、個別見積もり |
注意したいのは、Coreが「無料」でもコストがゼロにはならない点です。EKSなどのマネージドKubernetes上で動かせば、その分のインフラ費用が毎月発生します。加えて、同期失敗時の調査やバージョンアップの検証も自分たちの工数になります。
コネクタとカスタム開発
Airbyteのコネクタ数は、公開情報では400以上とするものと600以上とするものがあり、集計の時点や数え方で幅があります。正確な対応状況はAirbyte公式ドキュメントのコネクタ一覧で確認するのが確実です。
Airbyteの強みは、コネクタがない場合に自分で作れることです。Connector Development Kitを使えば独自コネクタを実装できます。社内の独自システムや、国内SaaSのようにメジャーなマネージドELTが対応していないソースを扱う場面では、この自由度が効きます。
逆に言えば、カスタムコネクタを作った時点で、その保守は自社の持ち物になります。
Airbyteが向いているケース
データを自社の管理下に置く必要がある組織、接続先に独自システムや非メジャーなSaaSが多い組織、そして月額課金よりエンジニア工数のほうが確保しやすい組織です。
Fivetran・Airbyteの違いを比較表で整理
両者の違いを、選定で実際に争点になる観点だけに絞って並べます。
観点 | Fivetran | Airbyte |
|---|---|---|
提供形態 | フルマネージドSaaS | OSS(セルフホスト)+クラウド版 |
課金の考え方 | MAR(月間アクティブ行数)ベース | Core無料/クラウドは従量・クレジット・容量制 |
コスト構造 | 利用量に連動して変動 | インフラ費+運用工数が主(Core) |
コネクタ保守 | ベンダーが担当 | コミュニティ+自社(独自分は自社) |
独自コネクタ | 対応範囲は提供コネクタ中心 | CDKで自作可能 |
データの所在 | ベンダー経由の処理 | セルフホストなら自社管理下 |
向く体制 | データ基盤の専任が少ない組織 | インフラを見られる人がいる組織 |
主な懸念 | 利用量増加に伴う費用の読みにくさ | 障害対応・アップグレードの自走 |
この表の要点は、費用のかかり方が「変動費か固定費か」で性質的に違うことです。Fivetranは処理行数が増えるほど費用も増える構造ですが、実際の増え方は契約プラン・年間割引・同期対象テーブルの除外設定によって変わります。Airbyte Coreはインフラを増強するまで費用が階段状にしか動かない一方、人の時間を継続的に消費します。
向いていないケースも押さえておくと判断が早くなります。Fivetranは、更新頻度の極端に高いテーブルを大量に同期する用途ではコストが読みにくくなります。Airbyte Coreは、インフラ運用を担当できる人を確保できないチームには向きません。
このセクションのミニFAQ
Q. 両方を併用する構成はありますか。
あります。主要SaaSはFivetranに任せ、独自システムや対応コネクタのないソースだけAirbyteで取り込む分担です。ただし監視と運用手順が二重になるため、接続先が少ない段階では避けたほうが無難です。
失敗しない選び方|4つの判断軸と導入チェックリスト
選定は次の4軸を順に潰すと決まります。上から順に、後戻りのコストが大きい順です。
軸1:データの所在に制約があるか
結論として、ここが最初の分岐です。個人情報や機微情報を外部のマネージドサービスに通せない規約・業界ルールがあるなら、セルフホスト可能なAirbyteが候補になります。制約がなければ次の軸へ進みます。
軸2:接続したいソースがコネクタで埋まるか
接続先を実際にリストアップし、各ツールのコネクタ一覧と突き合わせます。ここで埋まらないソースが残る場合、その数が判断を分けます。1〜2本なら自前実装やAirbyteのCDKで補える範囲です。半分近く埋まらないなら、ツール選定以前に連携方式から設計し直したほうが早いこともあります。
軸3:運用を見られる人がいるか
Airbyte Coreは、Kubernetesの運用、バージョンアップ検証、同期失敗時の切り分けを自走できる前提のツールです。この役割を担える人が確保できないなら、マネージドを選んだほうが総コストは下がります。
軸4:コストの試算が成り立つか
Fivetranは接続前にMARの実測を取ります。Airbyte Coreはインフラ費と運用工数を人月換算で乗せて比較します。ライセンス費だけを並べると判断を誤ります。
導入前チェックリスト
接続したいソースを全件リストアップし、コネクタ対応の有無を1件ずつ確認した
更新頻度が高いテーブルを特定し、MARが跳ねる候補を洗い出した
無料枠またはトライアルでサンプル同期を実行し、実測値を取得した
データの所在・暗号化・監査ログについて、社内規約との整合を確認した
Raw層のスキーマ設計と、スキーマ変更時の下流への影響範囲を整理した
変換層(dbt等)とオーケストレーション(Airflow等)の担当範囲を決めた
同期失敗時のアラート先と一次対応の手順を決めた
セルフホストの場合、バージョンアップの検証環境と頻度を決めた
2026年の最新動向|Fivetranとdbt Labsの統合
本セクションは、ここまでの4軸による選定判断を補足する材料です。ツール選びの結論そのものを左右するというより、中長期の前提が動いている点を押さえておくためのものと考えてください。
選定に影響しうる構造変化として、Fivetranとdbt Labsの統合があります。2025年10月13日に発表され、2026年6月1日に統合が完了したことが公式に発表されています(2026年10月時点で確認)。
発表によれば、全株式交換による統合で、合算すると10万を超えるデータチームが利用する規模になります。経営体制はFivetran出身のGeorge Fraser氏がCEO、dbt Labs出身のTristan Handy氏がPresidentという構成です。
技術面では、dbt FusionエンジンのランタイムをApache 2.0ライセンスで公開するdbt Core v2.0のアルファ版などが発表されています。
選定にどう影響するか
ここは評価が分かれるところなので、断定せず論点として整理します。
統合を前向きに捉えるなら、EL(Fivetran)とT(dbt)が同じベンダーの下で設計されることで、両者をまたぐ運用体験が改善される可能性があります。取り込みから変換までの系譜が一貫して追えるなら、データ基盤の運用負荷は下がる方向に働きます。
一方で、懸念として挙がるのはベンダー集約です。EL層とT層を同一ベンダーに預けると、将来の価格改定や方針転換の影響を一度に受けます。この観点では、OSSとして独立した立ち位置にあるAirbyteの中立性が、相対的に評価されやすい状況になっています。
どちらの見方を取るにせよ、統合は進行中の動きである点には留意が必要です。製品ラインの再編やライセンス条件は今後変わる可能性があるため、選定時には各社の公式発表で最新の状態を確認してください。
ケース別の選択パターン
組織の状況別に、実務でよく取られる型を挙げます。あくまで出発点としての整理で、個別の要件で変わります。
スタートアップ・小規模チーム
接続先が主要SaaS中心で、データ量もまだ小さい段階です。このフェーズではFivetranの無料枠やトライアルで始め、MARの伸び方を見ながら判断を先送りする型が取りやすくなります。インフラ運用に人を割く余裕がないことが多いためです。
事業会社のデータ基盤刷新
既存の自前バッチをELTツールへ移行するケースです。ここで効くのは移行の段階設計です。全接続を一度に切り替えず、影響の小さいソースから移して並行稼働させます。移行期間は接続数によりますが、数本の接続なら短期間で済む一方、数十本規模なら検証を含めて数か月単位の計画を見込むのが現実的です。
DWH側の構成がまだ固まっていない場合は、BigQueryとは?特徴・できること・データ分析案件の単価をフリーランス視点で解説やSnowflakeとは?データクラウドの特徴・BigQueryとの違い・案件動向をフリーランス視点で解説もあわせて検討材料にしてください。
受託開発・SIer
クライアントの環境と規約に従うため、選択の自由度は低くなります。クライアント側にすでに契約済みのツールがあればそれを使い、ない場合はデータの所在要件から逆算する流れです。この領域では、特定ツールの習熟より「どちらも触れる」ことのほうが案件の幅につながります。
金融・医療など規制の強い業界
データの外部送信や保管場所に制約がかかりやすい領域です。セルフホスト可能なAirbyte、またはFivetranの上位プランで提供される顧客管理暗号化キーなどの機能が検討対象になります。いずれにせよ、技術選定の前に法務・セキュリティ部門の要件定義が先に立ちます。
導入でよくある失敗と対策
失敗1:MARを行数で見積もってしまう
テーブルの総行数から費用を試算し、実際の請求が想定を超える典型的なパターンです。課金対象は月内に動いた行なので、更新の多いテーブルほど膨らみます。対策は、トライアル枠で主要テーブルを実際に同期し、MARの実測を取ってから本番設計に入ることです。
失敗2:セルフホストの運用コストを数えない
Airbyte Coreのライセンス費がゼロであることと、総コストがゼロであることは別です。インフラ費に加え、同期失敗の調査、バージョンアップの検証、コネクタの不具合対応が工数として乗ります。対策は、ライセンス費ではなく「インフラ費+想定工数の人月換算」でマネージドと比較することです。
失敗3:スキーマ変更の影響範囲を設計していない
ソース側の列追加や型変更は、ELTツールがDWHへ伝播させます。そこまでは期待どおりですが、その先の変換クエリやBIダッシュボードが壊れることがあります。対策は、Raw層を直接参照させず変換層を挟むこと、そして変換層にテストを置いて異常を早期に検知することです。
失敗4:取り込み対象を広げすぎる
「とりあえず全部入れる」と、使われないテーブルの同期にコストを払い続けることになります。対策は、分析要件から逆算して対象テーブルを絞り、必要になった時点で追加する運用です。
ELTツール案件の単価傾向とフリーランスの関わり方
先に断っておくと、Fivetran・Airbyteの単独スキルで募集される公開案件は、本記事の執筆時点では多く見かけません。実務では「データ基盤構築・移行案件の構成要素の一つ」として現れるのが通常です。
以下の傾向は、首都圏中心の主要フリーランスエージェント数社の公開案件ページを執筆時点で確認し、データ基盤・データエンジニア領域の募集を観測ベースで整理したものです。公開案件のうちELTツール名が明記されているものはまだ限られるため、参考値として読んでください。非公開案件は個別条件で変わるため、ここには含めていません。
観測した範囲では、ELTツールは単独要件ではなく、DWH(BigQuery・Snowflake等)、dbt、Airflowといった周辺スキルとセットで記載されるケースが目立ちます。つまり、評価されるのはツールの操作経験そのものより、取り込みから変換・オーケストレーションまでを含む基盤全体の設計経験です。
レイヤー別の単価目安については、データ基盤案件の単価相場|ETL・DWH・BIレイヤー別の目安とスキルで整理しているため、そちらを参照してください。データエンジニアという職種全体の市場観はデータエンジニアとは?仕事内容・年収・将来性をわかりやすく解説が入口になります。
自分の経験でどのくらいの単価を狙えるか確認したい方は、無料のフリーランスエンジニア単価診断で市場単価の目安を把握できます。データ基盤関連の募集状況はフリコンの案件一覧でも確認できます。
このセクションのミニFAQ
Q. Fivetran・Airbyteの経験は、未経験の状態からどう積めばよいですか。
Airbyte Coreはセルフホストで無料のため、手元のKubernetesやDocker環境に立てて、公開APIを持つSaaSから自分のBigQueryへ取り込む構成を一通り作るのが現実的です。Fivetranは無料枠とトライアルの範囲で挙動を確認できます。
まとめ
FivetranとAirbyteの選定は、「運用を外注するか自前で握るか」で大半が決まります。データの所在に制約がなく専任の運用担当を置けないならFivetran、自社管理下に置く必要があるか独自ソースが多いならAirbyteが出発点です。
FivetranとAirbyteが担うのはEL(取り込み・ロード)まで。変換はdbt、実行制御はAirflowなどと役割分担する
Fivetranの課金はMAR。行数ではなく月内に動いた行が対象で、更新頻度の高いテーブルほど膨らむ
Airbyte Coreはライセンス費なし。ただしインフラ費と運用工数が実質コストとして乗る
選定は「データの所在 → コネクタ充足 → 運用体制 → コスト試算」の順に潰すと迷いにくい
2026年6月にFivetranとdbt Labsの統合が完了。EL層とT層のベンダー集約をどう評価するかが新しい論点になっている
案件としては単独スキルより、DWH・dbt・Airflowを含む基盤全体の設計経験が評価されやすい
次のステップとしては、接続したいソースを全件書き出し、各ツールのコネクタ一覧と突き合わせるところから始めてください。そのうえで無料枠かトライアルでサンプル同期を回せば、カタログだけでは見えない運用の手触りとコストの実測値が得られます。
参照した一次情報は次のとおりです。
よくある質問
FivetranとAirbyte、結局どちらが安いですか。
接続先の構成と更新頻度で逆転します。更新の多いテーブルを大量に同期するならMAR課金のFivetranが不利になりやすく、インフラを運用できる人がいないならAirbyte Coreの実質コストが跳ね上がります。ライセンス費だけでなく、工数を人月換算して比較してください。
Airbyte Coreの運用には、どの程度のスキルが必要ですか。
DockerまたはKubernetesでの運用経験が前提になります。具体的には、コンテナのログ調査、リソース割り当ての調整、バージョンアップ時の互換性確認ができるレベルです。この経験がないチームが本番運用に乗せると、障害時に止まります。
既存の自前バッチから移行する価値はありますか。
接続先の数で判断が変わります。接続が数本で安定稼働しているなら、移行コストに見合わないこともあります。接続先が増え続けていて保守が追いつかない状態なら、移行の価値が出ます。
Stitchなど、ほかのELTツールと比べてどうですか。
選定の軸自体は同じです。マネージドか自前か、コネクタが埋まるか、課金モデルが自社のデータ特性と合うか。ツール名が変わっても、本記事の4軸をそのまま当てはめて比較できます。
ELTツールを使うとデータエンジニアの仕事は減りますか。
取り込みの実装と保守は減ります。一方で、モデリング、データ品質の担保、コスト最適化、ガバナンス設計の比重が上がります。仕事の総量が減るというより、担当領域が上流に移る変化です。
リアルタイム連携には使えますか。
準リアルタイムまでが現実的な範囲です。Fivetranの同期頻度は公式ページでStandardが15分間隔、Enterpriseが1分間隔と案内されています。秒単位の反映が要件なら、CDC(Change Data Capture。データベースの変更差分を随時検知して連携する方式)やストリーミング基盤など別の方式を検討してください。
Fivetranとdbt Labsの統合で、既存のdbt利用者に影響はありますか。
統合は2026年6月に完了したばかりで、製品ラインの再編は進行中です。dbt Core自体はOSSとして公開が継続されており、v2.0のアルファではFusionエンジンがApache 2.0で公開されています。現時点で既存構成を慌てて変える必要性は高くありませんが、ライセンス条件の変更は公式発表で追ってください。
取り込んだデータのコストはDWH側でも発生しますか。
します。ELTはDWHの計算資源で変換する方式のため、ストレージ費に加えてクエリ・計算の費用が乗ります。ELTツールの費用だけを見て試算すると、総額を読み違えます。
日本国内のSaaSにはどの程度対応していますか。
国内特有のSaaSは、海外発のELTツールの事前構築済みコネクタでカバーされていないことがあります。この場合はAirbyteのCDKで自作するか、APIを自前で叩く構成になります。選定前に、接続したい国内SaaSが一覧にあるかを必ず確認してください。
小規模な検証から始める場合、最短でどのくらいで動きますか。
主要SaaSからDWHへの単純な取り込みであれば、Fivetranのトライアルを使って当日中に初回同期まで到達できるケースもあります。Airbyte Coreはインフラ構築が先に入るため、環境準備を含めると数日から1〜2週間程度を見込むのが現実的です。いずれも本番運用の設計はこれとは別に必要です。
コネクタが対応していないソースはどうすればよいですか。
選択肢は3つです。AirbyteのCDKで独自コネクタを実装する、APIを叩く自前スクリプトを書いてDWHへロードする、あるいはそのソースの連携自体を見送る。保守コストが自社に乗る点はどの選択肢も共通なので、分析要件に対する重要度から判断してください。
学習の優先順位としては、ELTツールとdbtのどちらを先に触るべきですか。
データ基盤の案件で問われる頻度を考えると、変換層の設計力のほうが汎用性があります。dbtで変換とテストの考え方を押さえたうえで、ELTツールは「どのツールでも同じ4軸で選べる」状態にしておくと、特定製品に依存しないスキルになります。
