Fivetranとは？責任分界とMAR課金から読む導入判断

Fivetranを語る記事の多くは、valuationや大型調達額、競合との価格差を追いかけますが、Fivetranに月額いくら払うかを決める判断材料はそこにはありません。実務で効くのは、データ移動のどの運用責任をFivetranに任せられて、何が契約後も自社に残るのかという1点です。この分界線がどこにあるかは、Fivetranのpricing FAQ、Hybrid Deployment docs、Connector SDK docsを読めば一次情報から特定できます。

私はFivetranを「コネクタを買うツール」ではなく、「データ移動のon-call責任を外部に移す契約」として評価すべきだと考えています。導入判断はほぼ2点に絞られます。connectionごとに独立したcost curveを持つMAR課金をどう読むか。そしてmanagedに移る責任（sync実行、retry、schema drift吸収）と、契約後も自社に残る責任（source選定、権限、変換ロジック、downstream設計）の分界線がどこにあるか、です。

この記事をいま書く動機にも触れておきます。ネクサフローはAI活用・実装支援の一環として、RAG（社内データ連携AI）基盤構築や、散在するデータを統合・可視化するダッシュボード構築を公開サービスとして提供しています。クライアント環境にデータを集約する統合層の選定は、この実装のたびに必ず隣接する論点として出てきます。Fivetranを自社サービスとして提供しているわけではありませんが、この記事はdbt Labs、Monte Carlo、AIデータ・アナリティクスの役割整理という同じ調査シリーズの一本として、公開情報の範囲でFivetranの分界線を先に押さえておく位置づけで書いています。

ただし、私自身がFivetranを本番運用した経験はまだありません。以下は2026-04-15時点で確認できたFivetranの公式site、pricing、docs、pressを読み込んだ範囲での判断軸であり、運用実感で覆る点が出れば書き直します。参照したのはAbout、Pricing、Getting Started、Activations docs、Connector SDK docs、Hybrid Deployment docs、dbt Labsとのpress release、Dropbox customer storyです。

---

前提：責任の分界線とMARを定義する

“

この記事の前提

• 数値・docsの内容は2026-04-15時点のFivetran公式pricing / docs / pressのスナップショットです。plan feature、connector coverage、sync frequency、deployment eligibility、pricing unitは変わりうるため、導入前に必ず最新の公式docsとestimatorを確認してください
• customer storyのKPIは1社固有の実績であり、再現保証ではありません

この先で使う2つの言葉を、反証可能な形で先に定義しておきます。

責任の分界線 — data movementのうち、Fivetranがmanagedに引き受ける運用責任と、契約後も自社に残る責任の境界です。sync実行、retry、schema drift吸収、connector保守はFivetran側。source選定、権限、データ契約、変換ロジック、downstream設計は自社側。この境界の引き方が違えば、公式docsの記述と食い違う形で反証できます。

MAR（Monthly Active Rows） — Fivetranの課金単位です。会社規模別の固定月額ではなく、使用量課金として動きます。pricing page FAQでは、connection pricingはeach connection follows a separate cost curveと説明されています。つまり見積もりは「会社全体でざっくりいくら」ではなく、connectorごとにしか出せません。

---

全体像：Fivetranを構成する5つの層

Fivetranは、現在の公式サイトではautomated data movement platformとして案内されています。SaaS、database、files、streamingなどからdata warehouseやdata lakeへデータを動かし、connectorの運用、governance、securityをmanagedで引き受けることが主な役割です。

公式サイトの導線を辿ると、この役割は次の5層に整理できます。

FivetranのAboutpageによれば、George FraserとTaylor Brownは2012年に創業し、2014年に顧客の要望を受けて最初のconnectorを作りました。それが今のproduct-market fitの起点になっています。分析ツールとして出発したのではなく、分析の前に詰まるdata movementを製品化したことが、いまも5層の中心にConnectionsが置かれている理由です。

この5層は、AIデータ・アナリティクスの全体像を役割別に整理した記事で「データ移動」役として位置づけたFivetranの内部構造そのものです。ハブ記事では他社との役割の違いを見ましたが、本記事はConnectionsからDeployment Modelsまでの内部で、責任がどう分かれるかを掘ります。

重要なのはconnectorの数ではありません。connectorの運用をmanagedに寄せつつ、activation、transformation、governanceまでひとつのpricingとcontrol planeで見せている点です。ただし、すべてのconnectorやdeployment modeが同じ条件で使えるわけではなく、確認すべきは見出しの数字より「自社のsource、destination、network制約で本当にその層が使えるか」です。

---

Connectionsで何が変わり、何が残るか

Getting Startedとpricing pageでは、700+ fully managed connectorsが前面に出ています。対象はSaaS replication、database replication、SAP replication、streaming replication、file replication、data lakes、data warehousesと幅広いです。

managedに移る責任は次の4つです。

• syncをscheduledで回すこと
• sourceからdestinationへのreplicationを安定運用すること
• connectorのcomputeを自前で持たずに済ませること
• dashboardやAPIで接続を管理できること

契約後も自社に残る責任は次の4つです。

• どのsourceをどのdestinationに送るかという設計
• table選定、権限、秘匿情報、データ契約
• 変換ロジック、semantic layer、品質監視
• connectorが返すschemaをdownstreamでどう扱うか

700+という数字は魅力的ですが、導入時に確認すべき順序は数字とは別にあります。必要なsource connectorが存在するか。必要なdestinationで使えるか。必要なsync modeやnetwork optionに対応しているか。History modeやcustom behaviorが必要なら別手段が必要か。この順で見ないと、「導入できると思ったがedge caseだけ自前実装が必要だった」という形で戻ってきます。

---

分界線を動かす2つの手段：Hybrid DeploymentとConnector SDK

Connectionsの分界線は固定ではありません。Fivetranはこの線を動かす2つの手段を公式docsで示しています。

Hybrid Deployment：実行場所を動かす

古い紹介記事はHybrid Deploymentを「オンプレ対応」の一言で片づけがちです。しかしdocsを読むと、もう少し具体的です。agent containerをKubernetesかLinux環境のDocker / Podman上で動かし、data pipeline processingは顧客network内で行いながら、設定と監視はFivetran environment側に残ります。

docsで押さえたい点は次の5つです。

• agentは顧客network内で動作する
• metadata、sync metrics、MAR information、logsはFivetran cloudに送られる
• secure outbound connectionを使う
• 1 agentあたり最大10 connectionsが目安
• Hybrid Deploymentはsubset of connectors and destinationsのみ対応

Hybrid Deploymentが動かすのは「実行場所」だけです。control planeそのものはFivetran側に残ります。評価すべきは「public internetを避けられるか」だけでなく、どのmetadataがcloud側へ出るか、対象connectorがhybrid capableか、agent capacityをどう切るかです。pricing pageではHybrid Deployment optionがEnterprise側のfeatureとして案内されており、Connector SDK docsでもHybrid Deploymentはplan条件つきです。connector eligibilityとplan eligibilityは必ずセットで確認する必要があります。

Connector SDK：extract logicだけを自社に戻す

Fivetranを検討するチームがぶつかるのは、「主要SaaSは対応しているが、肝心の社内APIやniche sourceがない」という問題です。ここでdocsが示すのがConnector SDKです。

custom connectorは次の流れで作ります。Pythonでsource connectorを書き、ローカルでtestし、Fivetranにdeployする。sync時はFivetranがcustom codeを実行し、Fivetranがdataをdestinationにloadします。

Connector SDKが動かすのは「誰がextract logicを書くか」です。scheduled executionとconnector runtimeはFivetran側に残ったまま、コードの所有権だけ自社に戻ります。webhook前提や強いcustom runtimeが必要なチームには、この分界線の動かし方では足りません。

---

課金の読み方：MAR・MMRとconnectionごとのcost curve

現行pricing pageは、固定のcompany-size tableより「only pay for what you use」を中心に構成されており、Connections、Activations、Transformationsをusage-based pricingでまとめて見せています。

2026-04-15時点でpricing pageに出ているplanは次の通りです。

実務で効くポイントは3つです。見積もりはconnector単位で出すこと。pricing FAQはconnectionごとのcost curveを前提にしています。usage definitionを確認すること。pricing FAQではusageにinsertsとupdatesが含まれ、deletesを含む更新も対象です。base chargeとestimatorを確認すること。Standard connectionsでは1 MARから1M MARまで$5 base chargeがあるとFAQに書かれています。predictabilityが必要ならELAも見る価値があります。pricing pageにはfixed price per yearのEnterprise License Agreementsも案内されています。

---

分界線の拡張：Activations・Transformations・dbt買収

Fivetranは、Connectionsの分界線だけでなく、activationとtransformationの側にも分界線を広げようとしています。

Activations docsでは、Fivetran Activationsはcloud-basedのmanaged reverse ETL productと説明されています。warehouseのsource of truthをbusiness toolsに戻し、ELTと組み合わせてbidirectional, end-to-end data pipelineを作れるという見せ方です。pricing pageでもActivationsは独立したproductとして扱われ、Standard planには200+ activation destinationsが含まれています。

Transformationsにはpricing pageでMMRベースのpricingがあり、Free planでも5,000 MMRまで含まれます。Standard planにはdbt Core integrationも案内されています。実態に近い読み方は、Fivetranがdbtを完全に内包したというより、ingestionと隣接する軽量transformation surfaceをFivetranが持ち、自前dbt projectや他のtransformation layerとどう分けるかを選べる、というものです。

この延長線上にあるのが、dbt Labsとの統合です。press releaseは、data movement、transformation、metadata、activationを統合するopen data infrastructureとして説明し、dbt Coreはcurrent licenseのまま維持しcommunityとともに発展させる方針も明記しています。一方で、同じpress releaseにはtransactionが両社の取締役会と株主の承認を受けていること、finalizationはregulatory approvalsを含むcustomary closing conditionsの対象であること、closingまでFivetranとdbt Labsはseparate, independent companiesとして運営されることも書かれています。

同じ統合発表は、dbt Labsの製品像を整理した記事でも取り上げており、そちらでは「オープン性」「責任分界」「メタデータ」「既存運用への影響」の4観点に分けて読んでいます。そこでの責任分界は「Fivetran側の抽出・ロードとdbt側の変換で、失敗時の責任がどう分かれるか」という、dbt側から見た問いでした。Fivetran側から同じ発表を読むと、問いの向きは逆になると考えています。ここまで見てきたActivationsとTransformationsの分界線拡張と合わせると、この統合は、Connectionsで確立した「managedに移る責任／自社に残る責任」という分界線を、activation・transformation側までどこまで押し広げようとしているか、という動きとして読めます。press releaseがdbt Coreのライセンスと開発体制の維持を明記しているのも、拡張の対象がtransformationの実行責任であって、dbt Coreのオープン性そのものではないことを示していると読んでいます。

dbt transactionはfuture visionを読むための一次情報です。いま確認できるのは、Transformationsとdbt Core integrationの案内、open data infrastructureという方向性、dbt Coreをopenに保つという明記の3点まで。unified contractやroadmapの一体化、SQLMeshとの棲み分けは、closingを待たないと確定しません。

---

再ソート：どの責任から移すと楽になるか

ここまでの論点を、時系列でも機能別でもなく、「どの責任を最初に移すと楽になるか」という軸で並べ直します。

Dropbox customer storyでは、Fivetran導入によりequivalent of three full-time engineersがsavedされ、data ingestion and reporting timeが8 weeksから30 minutesへ短縮され、marketingとcustomer experienceでreal-time insightが広がったという結果が示されています。この数字を自社のbenchmarkにするのは危険です。source数やteam構成、backlogの重さが違えば効果は変わります。価値があるのはKPIの大きさではなく、どこで最初の勝ち筋が出たかという構造です。

ここで私自身の境界付き意見を述べておきます。私は、custom pipelineのbacklogが最も重く積み上がっているsourceから移行を始めるのが筋がよいと考えています。ただし根拠はDropbox事例1件のみで、一般化はできません。Dropboxのcustomer storyで効果が出たのは、data ingestionとreportingという、それまで8週間かかっていた最も重い工程でした。AIデータ・アナリティクスの役割別整理でもFivetranの役割は一貫して「SaaSやDBからの取り込み、同期、移送」に置かれており、この役割が最も効くのは、取り込みの手前で最も詰まっている場所だろうと考えています。

この読み方を踏まえると、Fivetranが向くかどうかも「機能があるかないか」ではなく「どの責任を先に手放したいか」で並べ直せます。

pricing predictabilityを強く求めusage-based spendを嫌う場合、source connectorの挙動を細かく自前制御したい場合、webhookや特殊runtimeが中心でConnector SDKの制約に引っかかる場合、self-hosted中心でcontrol planeも含めて自社管理したい場合。これらは表のどの状況にも当てはまらない、分界線を引く前提そのものが変わるケースです。

---

持ち帰りと次の問い

最後に、自社の支援業務でこの2軸をどう使うつもりかを書いておきます。ネクサフローはRAG基盤構築やデータ統合を伴うダッシュボード構築をAI活用・実装支援の一部として提供しており、クライアント環境のデータ統合層を評価する場面は今後も出てくるはずです。そのときは、コネクタ数や価格表を先に見るのではなく、責任分界（何がmanagedに移り、何が自社に残るか）とMARという課金単位が、クライアントの運用体制とどこまで噛み合うかを軸に見ていくつもりです。この記事で立てた2軸を、Fivetran単体の評価にとどめず、今後の統合層選定でも共通のチェックリストとして使っていきたいと考えています。

Fivetranは、data engineerを不要にするproductではありません。connector maintenanceとdata movementの負荷をmanagedに寄せる代わりに、warehouse設計やdownstreamモデルの責任は自社に残ります。この記事で立てた責任分界とMARという2つの軸は、Fivetran単体の評価だけでなく、監視層をどこに置くかという判断にもそのまま使えます。分界線の外側、つまりFivetranが引き受けないdownstreamの品質監視は、Monte Carloのdata + AI observabilityが担う領域です。

開いたままの問いもあります。dbt Labsとの統合がclosingを迎えたとき、いま自社に残ると整理した責任のうち、どこまでがFivetran側に飲み込まれるのか。closingの発表が出たら、この記事の分界線は引き直しが必要になります。

---

参考リソース

Fivetran 公式

• Fivetran About
• Fivetran Pricing
• Getting Started
• Activations Docs
• Connector SDK Docs
• Hybrid Deployment Docs
• Fivetran and dbt Labs press release
• Dropbox customer story

---

本記事はネクサフローのAI研究シリーズの一部です。