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

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

この記事では、増分同期とスキーマ追従が内部でどう動くか、MARがどの操作で加算されるか、同期モードを3種のどれにすると宛先の行がどう残るか、Hybrid Deploymentの分界点はどこか、2026年6月に完了したdbt Labsとの合併が構成にどう効くかを、実装者が判断できる粒度で整理します。設定値・SQL・APIリクエストは公式ドキュメントの記載に沿った形で載せているので、そのまま検証環境で試せます。数値と版番号は参照時点（2026年9月）のものです。

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

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

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

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

宛先にはSnowflake、BigQuery、Amazon Redshift、Databricks、各種PostgreSQL互換DBが並び、Apache Icebergなどのオープンテーブルフォーマットで書き出すマネージド・データレイクの選択肢もあります。宛先をDWHにするかレイクハウスにするかという上位判断はデータレイクハウスとは？データレイク・DWHとの違いが対応します。DWHという受け皿そのものの前提を確認したい場合はデータウェアハウス（DWH）とは？仕組み・製品比較・選び方から辿ってください。

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

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

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

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

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

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

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

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

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

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

PostgreSQLコネクタのセットアップガイドを読むと、選べる更新取得方式が2つに整理されています。WALを読むLogical Replicationと、システム列xmin・ctidをSQLで走査するQuery-Basedです。かつて存在したFivetran Teleport Syncはサンセット済みで、新規接続では選べません。物理削除まで拾いたいならLogical Replicationの一択になります。

前提条件は軽くありません。次の準備が要ります。

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

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

PostgreSQLソースでWALの論理レプリケーションを有効化する設定値

セットアップガイドが要求するサーバーパラメータは、名前を眺めるだけでは要否が判断できません。実際に投入する値まで書き下すと次の形です。wal_sender_timeoutとstatement_timeoutを0にするのは、大きなテーブルの初期同期がタイムアウトで切れるのを防ぐためです。

-- postgresql.conf（論理レプリケーション用）
wal_level = logical
max_replication_slots = 5          -- コネクション数以上
max_wal_senders = 10               -- スロット数の2倍以上
wal_sender_timeout = 0             -- タイムアウト無効
statement_timeout = 0              -- 0 か 5分以上
idle_replication_slot_timeout = 0  -- PostgreSQL 18系以降で必要

-- Fivetran 用ロールにレプリケーション権限を付与
CREATE ROLE fivetran WITH LOGIN PASSWORD 'CHANGE_ME';
ALTER ROLE fivetran WITH REPLICATION;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO fivetran;

スロット名の付け方にも制約があり、数字始まりは弾かれ、コネクションごとに一意である必要があります。もうひとつ、運用中に踏みやすい落とし穴を挙げておきます。レプリケーションスロットを削除して作り直すとLSNがリセットされ、Fivetranは前の位置から再開できません。結果として履歴の再同期が走ります。スロットの掃除は、宛先の再構築を伴う作業だと考えてください。

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

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

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

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

システム列のドキュメントが定義しているのは次の4列です。データ型まで公式に決まっているため、下流のモデルで型変換を挟む必要はありません。

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

Fivetranの同期モード選択で宛先に行が残る条件と消える条件の違い

ここは既存の解説記事が触れないまま済ませがちな設定でありながら、宛先テーブルの見え方を根本から変えます。同期モードのドキュメントで定義されているのは、この3種です。テーブル単位で選べるため、監査対象のマスタだけHistoryにする、といった混在も組めます。

Soft Delete・Live・Historyの3モードで削除行の残り方が変わる基準

判断は「宛先を何の証拠に使うか」で決まります。BIの現況ダッシュボードだけならLiveが素直で、ストレージも膨らみません。逆に、月次で締めた数字を後から再計算して説明する必要がある基幹データはHistory以外に手がありません。Soft Deleteは既定値であるがゆえに無自覚に使われがちですが、削除フラグを下流で必ず弾く運用とセットで初めて機能します。

History Modeで追加される3列から過去の断面を取り出すクエリ

History Modeを有効にすると、前掲のシステム列に加えて_fivetran_active（BOOLEAN）、_fivetran_start、_fivetran_end（いずれもUTC DATETIME）が付きます。startはソースでその版が作られた時刻、endは非アクティブになった時刻です。任意時点の断面はこの3列で切り出せます。

-- 2026-08-31 23:59:59 時点の受注テーブルの断面
SELECT order_id, status, amount
FROM   raw_sales.orders
WHERE  TIMESTAMP '2026-08-31 23:59:59'
       BETWEEN _fivetran_start
           AND COALESCE(_fivetran_end, TIMESTAMP '9999-12-31 00:00:00')

アクティブな最新版は_fivetran_endが空になるため、COALESCEで遠い未来の値に寄せて範囲比較へ畳んでいます。注意したいのは行数の増え方です。ステータスが5回遷移する受注テーブルなら、宛先の行数はおおむね5倍になります。History Modeを全テーブルに掛けるとストレージと同期時間の両方が効いてくるため、監査要件のあるテーブルに限定するのが実務的な落としどころです。

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

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

MAR（Monthly Active Rows）は、暦月のあいだにソースから宛先へ同期された「異なる行」の数です。行の同一性は主キーで判定されます。従量課金のドキュメントは「MARは、月間を通じてソースシステムから宛先へ同期された異なる行の数」と定義し、同一月内では何度同期されても1回のみ数えると書いています。月に30回更新された主キーもMARとしては1行分です。

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

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

実務で効くのは4行目です。同期の失敗や設定変更でロールバック同期が走ると、過去レコードの再取得分がそのままMARになります。コネクタを頻繁に張り直す運用は、見えないところで請求を押し上げます。

契約前に月間MARをソースDBのクエリで概算して桁を確かめる手順

見積りの精度を上げる方法は単純で、MARの定義をそのままSQLに翻訳すれば足ります。主キーの異なり数を月単位で数えるだけです。更新日時列を持つテーブルなら、契約前にソース側で実行できます。

-- 月間MARの概算：主キーの異なり数を月ごとに数える
SELECT date_trunc('month', updated_at) AS ym,
       count(DISTINCT id)              AS approx_mar
FROM   public.orders
WHERE  updated_at BETWEEN now() - interval '6 months' AND now()
GROUP  BY 1
ORDER  BY 1;

同期対象に入れる予定のテーブルすべてで走らせ、合計した数字を持って商談に入ってください。Freeプランの枠は接続で月間500,000 MAR、Activationsで3,500 MAR、変換のモデル実行（MMR）が月5,000回です。合計が数万で収まるならFreeで足り、数百万なら有償プランの階段のどこに乗るかを詰める段階に進みます。桁が2つ違えば、そもそも比較すべき製品が変わります。

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

プランはFree、Standard、Enterprise、Business Criticalの4段です。公式の料金ページによれば、Standardはユーザー数無制限・15分間隔の同期・700を超えるコネクタ・REST APIアクセス・dbt Core統合を含みます。Enterpriseで1分間隔の同期、カスタムロール、SCIM、VPNトンネル（年間契約のみ）、Hybrid Deploymentが加わります。Business Criticalは顧客管理鍵、PCI DSS Level 1準拠、プライベートネットワーク接続に応える層です。

単価はボリュームが増えるほど下がる階段状のカーブで、月間使用量が1〜100万MARの標準コネクションには$5のベースチャージが乗ります。年間契約では最大22%の割引が案内されています。年間の想定MARを先に購入して消費する形式であり、購入量の見積りを外した場合の過不足は損失につながる要因です。前のh3で出した概算値が、ここでそのまま交渉材料になります。

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

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

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

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

Hybrid Deploymentでは、コンテナ化されたエージェントを自社側で稼働させ、実データの読み書きはその内部で完結します。Fivetranへ送られるのはメタデータとログだけです。金融や医療で「クラウドベンダーに生データを渡せない」制約に当たっても、ELTツールごと諦めずに済む選択肢になります。

Hybrid Deploymentのエージェントを動かすために要る実行基盤の条件

マネージドの利点が一部戻ってくる代わりに、エージェントの稼働基盤は自社の担当範囲です。Hybrid Deploymentのドキュメントが挙げる前提を、見積り時にそのまま拾える形で並べます。

• 対象プラン：EnterpriseまたはBusiness Critical
• 実行環境：Kubernetes、Linux上のDocker、Podmanのいずれか
• エージェント本体：最低2 vCPU・2 GB RAM
• コネクション1本ごと：最低2 vCPU・4 GB RAM（HVAコネクタは4 vCPU・8 GB RAM推奨）
• ディスク：DockerまたはPodman構成でベースディレクトリに50 GB以上を推奨

コネクション数に比例してリソースが積み上がる設計なので、20本のコネクションを載せるなら40 vCPU・80 GB RAMが目安になります。この計算をしないままHybridを前提に稟議を通すと、インフラ費で二度手間になります。SaaS版との比較は、ライセンス費だけでなくこの基盤運用の人件費まで含めて行ってください。

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

2026年6月1日、Fivetranはdbt Labsとの合併完了を公表しました。全株式による統合で、George Fraser氏がCEO、Tristan Handy氏がPresidentという体制です。プレスリリースは両社合計で10万を超えるデータチームが利用していると記載しています。2025年10月13日の統合発表時点では、合算のARRが6億ドルに接近し、dbt単独で8万を超えるデータチームが使っているとされていました。

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

技術的な即時の変化より、構成判断への影響が大きい出来事です。従来は「取り込みはFivetran、変換はdbt」というベンダーをまたぐ組み合わせが定番でしたが、これが同一ベンダーの内側に入りました。取り込みと変換をまたぐオーケストレーションや列レベルの系統追跡は、統合が進むほど手当てが楽になる方向です。2025年5月に合意が公表されたCensusの買収により書き戻し側もActivationsとして同じ基盤に入っており、その仕様はリバースETLの実装解説で扱っています。

合併完了と同時に公表された製品は、dbt Core v2.0（alpha）、dbt State（preview）、dbt Wizard（beta）、そしてオープンソース標準としてのAgents Schemaです。押さえておきたいのは、高速化されたdbt Fusionエンジンを取り込んだdbt Core v2.0がalpha段階で公開された点でしょう。変換ロジックの中核がオープンソースに留まる限り、変換層だけを別の実行基盤へ持ち出す退避経路は残ります。取り込み層の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. データ鮮度とソース負荷を踏まえて同期スケジュールを決める

同期の概要ドキュメントが挙げる選択肢は、1分・5分・15分・30分・1時間・2時間・3時間・6時間・8時間・12時間・24時間の11段です。既定は6時間で、24時間より長い間隔は選べません。1分間隔にはEnterpriseまたはBusiness Criticalの契約が要り、Liteコネクタと一部のコネクタは対象外です。MARの性質上、間隔を詰めても費用は増えにくいため、鮮度要件から素直に決めて構いません。ただし同期のたびにソースのAPIを叩くので、レート制限を持つSaaSでは他システムへの影響を確認してください。

5. staging層で論理削除を除外して鮮度を検査するdbtモデル

宛先に生データが揃ったら、staging層で_fivetran_deletedの除外と型の整理を行い、その上に業務ロジックを積みます。この1本を最初に置いておくと、削除済み行の混入という定番の事故を構造的に潰せます。

-- models/staging/stg_orders.sql
with src as (
    select * from {{ source('sales_pg', 'orders') }}
)
select
    id            as order_id,
    status,
    amount,
    _fivetran_synced as synced_at
from src
where coalesce(_fivetran_deleted, false) = false

鮮度のテストは_fivetran_syncedを使うと素直に書けます。dbtのsource定義にloaded_at_fieldとして指定し、warnとerrorのしきい値を置けば、同期が止まったことをモデル実行時に検知できます。基盤全体の層分けを確認する際は、データ分析基盤の構築とは？5層アーキテクチャとBigQuery実装手順が参考資料です。

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

コネクタ設定は管理画面で作れてしまうため、手作業のまま増えがちです。誰が何をいつ変えたかが追えないと、MARの急増を設定変更まで遡って説明できません。手段はREST APIとTerraformプロバイダの2つで、次の2つのh3にそれぞれの書き方を置きます。

REST APIでコネクションを作成して宛先スキーマ名を指定する手順

Create a connectionのAPIリファレンスによれば、エンドポイントはAPIホスト配下のv1・connections、メソッドはPOST、認証はHTTP Basicです。必須項目はgroup_id・service・config.schemaの3つで、AcceptヘッダにAPIバージョン2を指定します。

curl --request POST \
  --url https://api.fivetran.com/v1/connections \
  --user "$FIVETRAN_API_KEY:$FIVETRAN_API_SECRET" \
  --header "Content-Type: application/json" \
  --header "Accept: application/json;version=2" \
  --data '{
    "group_id": "YOUR_GROUP_ID",
    "service": "postgres",
    "destination_schema_names": "FIVETRAN_NAMING",
    "run_setup_tests": true,
    "config": { "schema": "sales_pg" }
  }'

ドキュメントはdestination_schema_namesが将来的に必須になる予定だと注記しています。今のうちから明示しておくことは、仕様変更で作成が落ちる事態を避けるための対策です。run_setup_testsは既定でtrueなので、作成と同時に接続テストが走ります。

Terraformでコネクション定義をリポジトリ管理下に置く記述例

公式のTerraformプロバイダを使うと、コネクション定義そのものをコードで持てます。fivetran_connectionリソースの必須引数はgroup_idとservice、それにdestination_schemaブロック（name・prefix・table・table_group_nameのいずれか）です。

resource "fivetran_connection" "sales_pg" {
  group_id = fivetran_destination.warehouse.id
  service  = "postgres"

  destination_schema {
    prefix = "sales_pg"
  }

  config {
    host     = "db.example.internal"
    port     = 5432
    database = "sales"
    user     = "fivetran"
  }

  run_setup_tests = false
}

検証環境と本番で同じ構成を再現でき、変更履歴も追えます。ネットワーク経路をProxy Agent経由にする場合はnetworking_methodとproxy_agent_idを足す形です。パスワードはconfigへ直書きせず、変数か秘密管理サービスから渡してください。

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

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

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

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

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

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

迷う場合は、次の順で潰すと結論が早く出ます。第一に、ソース一覧を並べてコネクタの有無を確認する。ここで半分以上が非対応なら、その時点で候補から外れます。第二に、前掲のSQLで主要テーブルの月間MARを概算し、Freeプランの500,000 MARに対してどの桁かを見る。第三に、データの越境可否を法務・セキュリティ要件と突き合わせ、Hybrid Deploymentが要るならプラン要件とインフラ見積りに反映する。この3段は、価格交渉に入る前に採否の8割が決まる判断手順です。自社インフラで運用するOSSの選択肢と並べて比べる場合は、Airbyteとは？OSS版ELTの仕組み・セルフホスト構成とFivetranとの違いで費用構造と運用工数の比較軸を整理しています。秒単位の反映が要件に入るなら、CDCとストリーミングを束ねたEstuaryも同じ土俵に並べておくと判断が早くなります。

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

よくある質問

Fivetranの検討時に問い合わせの多い5点を、公式ドキュメントの記載に沿って整理します。

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

Freeプランが用意されており、参照時点の公開情報では接続で月間500,000 MAR、Activationsで3,500 MAR、変換のモデル実行が月5,000回までが対象です。加えて、新規に作成したすべての接続には14日間の無償利用が設定されます。この期間中は増分同期分もMARとして計上されません。PoCで実データを流し、月間MARを実測してから本契約に進むのが現実的な進め方になります。なおFreeで枠を超えると通知が飛び、2度目の超過でアカウントが凍結される仕様です。

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

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

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

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

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

2026年6月1日の合併完了時点では、既存のコネクタやdbtプロジェクトの動作を変更する内容は公表されていません。同時に発表されたdbt Core v2.0はalpha、dbt Stateはpreview、dbt Wizardはbetaという段階なので、本番構成へ入れるかどうかはGA後の判断で足ります。ライセンス条件と製品ロードマップは変わり得るため、契約更新のタイミングで公式の告知を確認する運用にしておいてください。

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

Hybrid Deploymentであれば、自社ネットワーク内に置いたエージェントがデータ処理を担い、Fivetranのクラウドへ渡るのはメタデータとログだけという構成が組めます。前提はEnterpriseまたはBusiness Criticalのプラン契約と、Kubernetes／Docker／Podmanのいずれかで動く実行基盤です。エージェント本体に2 vCPU・2 GB RAM、コネクション1本ごとに2 vCPU・4 GB RAMが最低要件になるため、体制と費用の両面から可否を判断してください。

関連記事

• ETLとは？仕組み・ELTとの違い・ツール選定から導入判断まで解説：ELT型を選ぶ前提となるETLとの分業の違いを扱っています。
• データパイプラインとは？種類・構成要素と冪等性から考える設計判断を解説【2026年版】：再同期に耐える設計の考え方を補完します。
• データ分析基盤の構築とは？5層アーキテクチャとBigQuery実装手順を技術視点で解説：Fivetranが担う取り込み層の前後を含めた全体像です。
• Airbyteとは？OSS版ELTの仕組み・セルフホスト構成とFivetranとの違い：OSS版ELTと費用構造を比較する際の対になる記事です。
• データレイクハウスとは？データレイク・DWHとの違いとアーキテクチャを実装視点で解説：宛先をどう置くかの上位判断に対応します。