Fivetranとは？ELTの仕組み・MAR課金・dbt統合後の構成を実装視点で解説【2026年版】

Fivetranは、SaaSやデータベースからデータウェアハウスへの取り込みを、コネクタの実装と保守ごと引き受けるマネージドELTサービスです。自前でAPIクライアントを書き、レート制限に対処し、ソース側のスキーマ変更に追従し続ける——その保守負債を外部化する点に価値があります。一方で課金単位がMonthly Active Rows（MAR）という独特の指標であるため、設計を誤ると想定外のコストが出ます。

この記事では、増分同期とスキーマ追従が内部でどう動くか、MARがどの操作で加算されるか、Hybrid Deploymentの分界点はどこか、2026年6月に完了したdbt Labsとの合併が構成にどう効くかを、実装者が判断できる粒度で整理します。数値と版番号は参照時点（2026年7月）のものです。

まとめ：Fivetranの要点と判断軸

• 正体はマネージドELT：700を超えるコネクタで抽出（E）と読み込み（L）を担い、変換（T）は宛先のDWH側でSQLとして行う分業モデル。
• 差分検知が中心：初期同期のあとは増分同期に移り、データベースソースではログベースのCDCで変更を拾う。
• MAR課金の骨格：課金対象は「その月に同期された主キーの異なり数」。同じ行が月に30回更新されても計上は1回。初期同期は無課金。
• コストが跳ねる条件：バッチが全行の更新日時を書き換える、更新が広く散る、不要な大テーブルを同期対象に残す——この3つが典型。
• データを外に出せない案件はHybrid Deployment：処理を自社ネットワーク内で完結させ、設定とオーケストレーションだけをFivetranのクラウドに置ける（上位プラン向け）。
• 2026年6月1日にdbt Labsとの合併が完了：取り込みと変換が同一ベンダーの下に入った。dbt Fusionを取り込んだdbt Core v2.0はalpha段階でApache 2.0のもとに公開。
• 採用が向く条件：標準的なSaaS・DBが対象で、コネクタ保守に人を割きたくない場合。独自プロトコル中心や超大量の高頻度更新では見送りが妥当。

Fivetranとは何か：データ連携で引き受ける範囲と利用企業の判断軸

Fivetranは、データソースからデータウェアハウスやデータレイクへの取り込みを専業とするSaaSです。担当範囲は抽出と読み込みに絞られ、ビジネスロジックを含む変換は宛先側で行います。この分業がELT型と呼ばれる構成で、抽出直後に変換を挟むETL型との違いはETLとは？仕組み・ELTとの違い・ツール選定から導入判断まで解説で整理しています。

宛先にはSnowflake、BigQuery、Amazon Redshift、Databricks、各種PostgreSQL互換DBが並び、Apache Icebergなどのオープンテーブルフォーマットで書き出すマネージド・データレイクの選択肢もあります。宛先をDWHにするかレイクハウスにするかという上位判断はデータレイクハウスとは？データレイク・DWHとの違いが対応します。

コネクタが実際に肩代わりするデータ取得とスキーマ管理の作業範囲

SaaSからのデータ取得を内製する場合、少なくとも次の作業が発生します。

• API仕様の読み込みと認証（OAuthのトークン更新を含む）
• ページネーション、レート制限、部分障害時のリトライ制御
• 取得したJSONのフラット化とリレーショナルなテーブル構造への正規化
• 前回同期位置（カーソル）の永続化と、途中失敗からの再開
• ソース側のフィールド追加・型変更への追従
• API仕様がバージョンアップしたときの改修

このうち最後の2つが継続的な負債になります。Fivetranが売っているのは成果物というより、この追従作業を代行し続ける契約だと捉えてください。

同期の仕組みを初期取り込みから増分更新まで工程別に詳しく分解する

初期同期と増分同期で異なるデータ取得範囲と更新行の判定方法を理解する

コネクタを作成すると、まず対象テーブルの全履歴を宛先へ流し込む初期同期が走ります。運用上の意味を持つのは、初期同期が課金対象外である点です。数億行の履歴を持つテーブルでも、最初の1回の転送そのものに費用は乗りません。費用が発生するのは、それ以降の増分同期で動いた行に対してです。

所要時間は大規模なテーブルで数日単位になることもあり、その間の宛先テーブルは部分的な状態です。下流のダッシュボードやモデルを繋ぐのは初期同期の完了後にしてください。

データベースソースでCDCを使うための前提条件と更新取得方式

PostgreSQLやMySQL、SQL Serverをソースにする場合、Fivetranはトランザクションログを読む方式（CDC）で変更を検知します。PostgreSQLなら論理レプリケーション、MySQLならbinlog、SQL ServerならCDC機能やトランザクションログが対象です。ソースのテーブルに更新日時列やトリガーを追加しなくても変更を捉えられ、かつ物理削除も検知できます。

前提条件は軽くなく、次の準備が要ります。

• ソースDBでログベースレプリケーションを有効化する（PostgreSQLならwal_level = logicalなど）
• レプリケーション権限を持つ専用ユーザーを用意する
• レプリケーションスロットの滞留によるディスク圧迫に備えて監視を置く
• 接続経路（VPNトンネル、SSHトンネル、プライベート接続、IP許可リスト）を確保する

3つ目は運用事故の定番です。コネクタの一時停止でスロットが消費されないままWALが溜まり、ソースDBのディスクを埋める事象が起こり得るため、遅延量にアラートを張っておいてください。

スキーマドリフトで列追加や型変更が生じた際の追従動作と確認方法

ソース側で列が追加されると、Fivetranは既定で宛先にも列を追加し、その列の過去データを埋め戻します。この埋め戻し分は無償MARとしてドキュメントに記載済みです。型変更はより広い型へ寄せる方向で調整される仕様です。

ただし自動追従の副作用として、SELECT *を前提にしたビューや列順に依存した処理は壊れます。スキーマ変更ポリシーはコネクタ単位で「新規テーブルと新規列を許可する／新規列のみ許可する／両方をブロックする」から選べるため、本番の下流を持つ経路では明示的に設定を選んでおくのが安全です。

宛先テーブルに付与されるシステム列の役割と下流処理での扱い方

削除が論理削除である点は下流の実装に直結します。_fivetran_deletedを条件に含めていないクエリは、削除済みの行を集計に含めたままになるためです。層構造の考え方はdbtの三層構造においてmarts層が最終データ整備を担う原則で扱っています。

FivetranのMAR課金ルールとデータ更新で費用が膨らむ条件

MARの定義と月内に同じ主キーを複数回更新した場合の数え方を整理する

MAR（Monthly Active Rows）は、暦月のあいだにソースから宛先へ同期された「異なる行」の数です。行の同一性は主キーで判定されます。ドキュメントの表現を借りれば、同じ行が月内に何度同期されても計上は1回で、月に30回更新された主キーもMARとしては1行分です。

ここが行単位で毎回課金するモデルとの分岐点になります。更新頻度が高くても、更新が同じ行に集中しているなら費用は増えません。逆に、更新が広い範囲の行へ薄く分散するワークロードでは費用が伸びます。

MARに加算される更新処理と加算されない同期処理の違いと具体例

Fivetranのプラン構成とMARボリューム別の単価の考え方

プランはFree、Standard、Enterprise、Business Criticalの4段です。参照時点の公開情報では、Freeは月間500,000 MAR、Activations向けに3,500 MAR、変換のモデル実行（MMR）が月5,000回までという枠組みでした。Standardはユーザー数無制限・15分間隔の同期・700を超えるコネクタ、Enterpriseで1分間隔の同期、カスタムロール、VPNトンネル、Hybrid Deploymentが加わります。Business Criticalは顧客管理鍵、PCI DSS Level 1準拠、プライベートネットワーク接続に応える層です。

単価はボリュームが増えるほど下がる階段状のカーブで、標準コネクションには$5のベースチャージが乗るという設定です。年間契約では最大22%程度の割引案内があります。年間の想定MARを先に購入して消費する形式のため、購入量の見積りを外すと過不足が損失になります。

MAR費用が急増する典型的な更新パターンと支出を抑える具体策

• 広く薄い更新：バッチ処理が毎晩全行のupdated_atを書き換えるソース。実質的な変更がなくても全行がアクティブ扱いになります。ソース側のバッチを、変更のあった行だけ更新する実装に直すのが根治策です。
• 不要な大テーブルの同期：初期構築時に「とりあえず全テーブル」を選んだまま放置される。分析で参照されていないログ系テーブルを外すだけで数割落ちることがあります。
• 不要な列の同期：列単位の除外を使わず、巨大なテキスト列やJSON列を運び続ける。同期時間と宛先のストレージに効きます。
• 削除の取り込み設定：Capture Deletesを有効にしたテーブルで大量削除が走ると、その削除がそのままMARになります。定期パージのあるテーブルほど影響が大きい部分です。

抑制の実務では、コネクタ単位のMARを月次で確認し、上位3コネクタに絞って同期対象テーブルを棚卸しするのが費用対効果に優れます。

デプロイモデル別にデータを社外へ出せる要件と出せない要件を比較する

Hybrid Deploymentでは、コンテナ化されたエージェントを自社側で稼働させ、実データの読み書きはその内部で完結します。金融や医療で「クラウドベンダーに生データを渡せない」制約に当たっても、ELTツールごと諦めずに済む選択肢です。ただしエージェントの稼働基盤の運用は自社の担当範囲に戻るため、マネージドの利点が一部薄れる点は織り込んでおいてください。

Fivetranとdbt Labsの合併後に変わる製品の位置づけと役割

2026年6月1日、Fivetranはdbt Labsとの合併完了を公表しました。全株式による統合で、George Fraser氏がCEO、Tristan Handy氏がPresidentという体制です。公表内容では合算のARRが6億ドル規模に接近し、dbtだけで8万を超えるデータチーム、両社合計で10万を超えるデータチームが利用しているとされています。

合併後にFivetranの実装者にとって変わる作業範囲と変わらない点

技術的な即時の変化より、構成判断への影響が大きい出来事です。従来は「取り込みはFivetran、変換はdbt」というベンダーをまたぐ組み合わせが定番でしたが、これが同一ベンダーの内側に入りました。取り込みと変換をまたぐオーケストレーションや列レベルの系統追跡は、統合が進むほど手当てが楽になる方向です。

一方で、単一ベンダーへの依存度が上がる構図でもあります。押さえておきたいのは、高速化されたdbt Fusionエンジンを取り込んだdbt Core v2.0がalpha段階でApache 2.0ライセンスのもとに公開された点です。変換ロジックの中核がオープンソースに留まる限り、変換層だけを別の実行基盤へ持ち出す退避経路は残ります。取り込み層のFivetranはSaaSであるため、こちらの切り替えコストのほうが高くつきます。

Fivetranとdbtの役割を踏まえて変換処理を配置する場所と基準

Fivetranは自身でもdbt Coreベースの変換実行機能を持ちます。小規模なら構成を1つにまとめる判断が成り立ちます。既にdbtの実行基盤とCI/CDが整っているなら、変換は既存の場所に残してFivetranを取り込み専用に使う構成でも問題ありません。再実行に耐える冪等性の考え方はデータパイプラインとは？種類・構成要素と冪等性から考える設計判断で整理しています。

Fivetranの導入手順を接続設定から宛先への反映まで順に確認する

1. Fivetranの接続前にデータの保存先となる宛先を用意する

Snowflakeなら専用のウェアハウス・データベース・ロール・ユーザーを切り、BigQueryならサービスアカウントとデータセットを用意します。取り込み専用のロールを分けると権限監査が単純です。ネットワーク制限を掛けている宛先では、FivetranのIP範囲を許可するかプライベート接続を設定してください。

2. コネクタを作成してOAuthまたはAPIキーによる認証を通す

管理画面でソースを選び、OAuthまたはAPIキーで認証します。データベースソースでは、この段階で前述のレプリケーション設定と接続経路の確保が済んでいる必要があります。接続テストが失敗した場合も、権限不足かネットワーク不通かはメッセージから判別可能です。

3. MAR費用を抑えるためテーブルや列単位で同期対象を絞る

ここを飛ばすと費用が読めなくなります。テーブル単位・列単位で同期対象を選び、分析で使わないものは外してください。一度同期を始めたテーブルを後から外しても、それまでに計上されたMARは戻りません。

4. データ鮮度とソース負荷を踏まえて同期スケジュールを決める

同期間隔は5分から24時間の範囲で設定します（1分間隔は上位プラン）。MARの性質上、間隔を詰めても費用は増えにくいため、鮮度要件から素直に決めて構いません。ただし同期のたびにソースのAPIを叩くので、レート制限を持つSaaSでは他システムへの影響を確認してください。

5. 宛先の生データに変換処理と鮮度テストを接続して検証する

宛先に生データが揃ったら、staging層で_fivetran_deletedの除外と型の整理を行い、その上に業務ロジックを積みます。鮮度のテストは_fivetran_syncedを使うと素直に書けます。基盤全体の層分けを確認する際は、データ分析基盤の構築とは？5層アーキテクチャとBigQuery実装手順が参考資料です。

6. コネクタ設定と同期スケジュールをコード化して変更を管理する

コネクタ設定は管理画面で作れてしまうため、手作業のまま増えがちです。Terraformプロバイダ、あるいはREST APIを使って、コネクタ定義・スキーマ設定・同期スケジュールをリポジトリ管理下に置いてください。検証環境と本番で同じ構成を再現でき、変更履歴も追えます。

Fivetranを採用すべき条件と導入を見送るべき場面の判断基準

採用が妥当となるデータソース構成と運用体制が満たすべき具体的な条件

• ソースが既存コネクタでカバーされ、月間の変更行数が概算できる：Salesforce、HubSpot、各種広告媒体、業務DBといった標準的な構成。ここでは内製する理由がありません。コネクタ保守の人件費がMARの費用を上回ります。
• データ基盤の担当が2名以下：少人数で基盤を持つ組織では、取り込み層の障害対応に割ける時間がありません。自分たちで直せない領域を外に出す判断は合理的です。
• 更新が特定の行に集中するワークロード：受注テーブルのステータス更新のように、同じ行が何度も更新される形。MARの月内1回計上と相性が良く、他のツールより安く付く場合があります。
• 立ち上げ速度が要件になっている：PoCや意思決定の期限が近く、まず数字を出すことが求められる局面。数日で分析可能な状態に届きます。

見送りが妥当となるソース仕様や費用規模とセキュリティ要件の判断基準

• ソースの過半が独自仕様：社内の独自プロトコル、レガシーな固定長ファイル、特殊な業務パッケージが中心なら、コネクタSDKで自作する手間が増え、マネージドの利点が薄れます。汎用のワークフローエンジンで組んだほうが素直です。
• 月間の変更行数が数億規模：ボリューム割引を踏まえても、自前のCDC基盤と比べたときの費用差が開きます。取り込み専用チームを置ける規模なら、内製の検討余地があります。
• 取り込み時に厳密な変換が必須：法令やセキュリティ要件で、宛先に到達する前にマスキングや除外を完了させる必要がある構成。ELTは生データが宛先に載る前提なので、Hybrid Deploymentを選んでも要件と噛み合いません。
• 同期の内部挙動を細かく制御したい：リトライ条件、部分同期の順序、失敗時の分岐といった制御を自分で持ちたい要件では、マネージドの抽象が邪魔になります。

Fivetranの採用可否をコネクタ対応とMAR費用から判断する順序

迷う場合は、次の順で潰すと結論が早く出ます。第一に、ソース一覧を並べてコネクタの有無を確認する。ここで半分以上が非対応なら、その時点で候補から外れます。第二に、主要テーブルの月間更新行数を主キーの異なり数で数え、Freeプランの500,000 MARに対してどの桁かを見る。第三に、データの越境可否を法務・セキュリティ要件と突き合わせ、Hybrid Deploymentが要るならプラン要件に反映する。この3段で、見積り以前に採否の8割が決まります。

データ基盤の構成選定、既存ETLからの移行、Fivetranを含む取り込み層の設計と実装については、データ分析基盤構築・MLOps構築支援でご相談を承っています。宛先の選定を含む上流設計から運用引き渡しまで一貫して対応します。

よくある質問

Q1. Fivetranを無料で試せるプランと無償トライアルの適用条件

Freeプランが用意されており、参照時点の公開情報では月間500,000 MARまでが対象です。加えて、新規に作成したコネクションには14日間の無償トライアルが設定されます。この期間中は増分同期分もMARとして計上されません。PoCで実データを流し、月間MARを実測してから本契約に進むのが現実的です。

Q2. 同期間隔を短くした場合にMAR費用が増える条件と変わらない条件

MARの観点では、原則として上がりません。課金は同期回数ではなく月内に触れた行の異なり数で決まるため、15分間隔を5分間隔にしても、その月に変更される行の集合が同じなら計上も同じです。ただしレート制限を共有している他システムへの影響と、宛先DWH側の計算リソース消費は別途確認してください。

Q3. ソースで削除された行が宛先で保持される仕組みと参照時の注意

既定では物理的には消えず、_fivetran_deleted列がTRUEになる論理削除として表現されます。監査上は履歴が残る利点がある一方、下流のクエリでこのフラグを除外しないと削除済みの行まで集計してしまうため、staging層で一律に弾く実装が安全です。なお削除の取り込みを有効にしている場合、削除処理もMARに計上されます。

Q4. dbt Labsとの合併で既存の構成に影響はありますか

2026年6月1日の合併完了時点では、既存のコネクタやdbtプロジェクトの動作を変更する内容は公表されていません。ライセンス条件と製品ロードマップは変わり得るため、契約更新のタイミングで公式の告知を確認する運用にしておいてください。

Q5. データを社外に出せない要件でHybrid Deploymentを使う条件

Hybrid Deploymentであれば、自社ネットワーク内に置いたエージェントがデータ処理を担い、Fivetranのクラウドは設定とオーケストレーションのみを保持する、実データが社外に出ない構成です。ただしエージェントの実行基盤は自社で運用する必要があり、上位プランの機能である点も含めて、体制と費用の両面から可否を判断してください。

関連記事

• ETLとは？仕組み・ELTとの違い・ツール選定から導入判断まで解説
• データパイプラインとは？種類・構成要素と冪等性から考える設計判断を解説【2026年版】
• データ分析基盤の構築とは？5層アーキテクチャとBigQuery実装手順を技術視点で解説
• データレイクハウスとは？データレイク・DWHとの違いとアーキテクチャを実装視点で解説
• オープンテーブルフォーマットとは？Iceberg・Delta Lake・Hudiの違いと選び方を実装視点で解説【2026年版】
• dbtの三層構造においてmarts層が最終データ整備を担う原則
• データウェアハウス（DWH）とは？仕組み・製品比較・選び方をわかりやすく解説