はじめに
以前、【データエンジニア入門】Fivetranとは？何ができるのか調べてみたという記事で、Fivetranの基本的な役割について調べてみました。
前回の記事では、
- Fivetranは「さまざまなシステムからデータを取得し、Snowflakeなどのデータ基盤へ自動的に連携するためのサービス」であること
- ETLではなくELT寄りの考え方で設計されていること（Source→Destinationへ複製し、加工はDestination側で行う）
- Initial Sync後は新規・変更データを増分同期できること
- スキーマ変更を検知してDestination側へ反映する仕組みがあること
- Fivetran（運ぶ）・Snowflake（貯める）・dbt（加工する）という役割分担
について、初心者なりに整理しました。
ただ、実際に導入を検討する立場で考えると、
「Fivetranの料金って結局いくらかかるの？」
「対応していないシステムからデータを取り込みたい場合はどうするの？」
「スキーマ変更って具体的にどこまで自動で対応してくれるの？」
といった、もう一段実務寄りの疑問が出てきました。そこで今回は、前回の記事からもう一歩踏み込んで、「MAR課金モデル」「Connector SDK」「スキーマ変更への対応」について調べてみました。
この記事はこんな方におすすめ
- 前回の記事でFivetranの基本的な役割（ELT・Sync）は理解した方
- Fivetranの料金体系が分かりにくいと感じている方
- 対応コネクタにない独自システムのデータを取り込みたい方
- スキーマ変更が起きたときの挙動を具体的に知りたい方
- Snowflakeを中心としたデータ基盤の導入・コスト管理を担当する方
まず前回のおさらい
前回の記事のポイントを簡単に振り返ります。
Salesforce / NetSuite / MySQL / PostgreSQLなど（Source）
↓
Fivetran
↓
Snowflake（Destination）
↓
dbt（Transform）
↓
分析用テーブル
- FivetranはSourceのデータをDestinationへできるだけ忠実に複製し、加工はDestination側（dbtなど）で行う「ELT型」の思想
- Connectorを設定するだけで、差分同期・スキーマ変更検知などが自動化される
- Fivetran自身にもTransformationsという簡易的な加工機能があるが、本格的な変換はdbtと組み合わせるのが基本
ここまでが前回のおさらいです。今回はここからさらに、実際に導入・運用する際に気になるポイントを深掘りしていきます。
課金モデル（MAR：Monthly Active Rows）を深掘りする
Fivetranを導入するうえで、最初につまずきやすいのが料金体系です。調べてみると、Fivetranの料金は基本的に**MAR（Monthly Active Rows）**という指標をベースにした従量課金であることが分かりました。MARとは、その月にFivetranがDestination側で更新・挿入・削除したユニークな行数のことです。(Usage-Based Pricing | Fivetran)
その月にFivetranが同期したデータのうち
↓
新規挿入された行 ＋ 更新された行 ＋ 削除された行（※重複IDは1回とカウント）
↓
= その月のMonthly Active Rows（MAR）
ここでのポイントは、「レコード数」ではなく「ユニークな行数」でカウントされる点です。同じ行が月内に何度更新されても、MARとしては1行分としてカウントされます。また、初回の大量データ取り込み（Initial Sync）で読み込んだ既存データは、通常この課金対象には含まれないとされています。
料金プランは、2026年時点では大きく4段階に整理されています。
| プラン | 特徴 |
|---|---|
| Free | 月50万MARまで無料（別途アクティベーションやモデル実行の無料枠あり） |
| Standard | 有料プランの入り口。100万MARあたり500ドル程度から |
| Enterprise | Standardより高機能・高価格帯（100万MARあたり667ドル程度） |
| Business Critical | CMEKやPCI DSS Level 1、プライベートネットワーキングなど、セキュリティ・ガバナンス要件が厳しい企業向け（100万MARあたり1,067ドル程度） |
（料金は変更される可能性があるため、契約前に必ず公式サイトの最新情報を確認してください）(Fivetran Pricing)
さらに2026年からは、1〜100万MARを生成する各Connectionに対して5ドルのベース課金が追加されている点や、これまで課金対象外だった「削除（DELETE）」もMARの計算に含まれるようになった点など、料金体系そのものが年々アップデートされていることも分かりました。
コスト管理のポイント
↓
・不要なConnectorは停止する（Pause）
・同期頻度（Sync Frequency）を必要以上に高くしない
・大量に更新が走るテーブルは、本当に高頻度同期が必要か見直す
前回は「Fivetranを使えばデータ連携が楽になる」という理解で止まっていましたが、実際には「何がMARとしてカウントされるか」を理解していないと、想定外にコストが膨らむリスクがある、という点が今回の大きな発見でした。
同期の仕組みをさらに深掘りする
前回、「Initial Sync後は増分同期される」と書きましたが、その内部の仕組みをもう少し具体的に調べてみました。
① Initial Sync
↓
対象テーブルの全データを取得し、Destinationへ初期投入する
② Incremental Sync
↓
Source側の更新ログやタイムスタンプ、
場合によってはCDC（変更データキャプチャ）の仕組みを使って
新規・変更・削除された行だけを検出し、Destinationへ反映する
データベース系のConnector（PostgreSQLやMySQLなど）では、更新ログ（WALやbinlogなど）を利用したログベースの同期方式がサポートされているケースがあり、これによりSource側のテーブルに大きな負荷をかけずに変更を検知できる、とされています。一方でAPI型のSource（SalesforceやNetSuiteなど）では、各APIが提供する差分取得の仕組み（更新日時によるフィルタなど）を使って同期する方式が中心になります。
スキーマ変更（Schema Drift）への対応を深掘りする
前回、「スキーマ変更を検知して反映する仕組みがある」とだけ書きましたが、具体的にどこまで自動化されているのかを調べてみました。
Source側で列が追加された場合
↓
Fivetranが変更を検知
↓
Destination側のテーブルにも自動で列を追加
Source側で列が削除された場合
↓
Fivetranが変更を検知
↓
設定に応じてDestination側の列を残す／削除するなどを選べる
例えば、Salesforceでカスタム項目が追加された場合、次回の同期タイミングでFivetranがその項目を自動検知し、Snowflake側のテーブルにも対応するカラムを追加してくれます。これにより、Source側の仕様変更に合わせて自分たちでALTER TABLEを書く、という運用負荷を減らせる、という前回書いた内容の裏付けが取れました。
一方で、列の型が大きく変わるようなケース（数値型から文字列型への変更など）では、Destination側の型変換ルールに従って自動的に丸められることもあるため、「スキーマ変更＝完全にノーメンテナンス」というわけではなく、重要なテーブルについては変更通知を監視しておく運用が推奨されています。
Connector SDKで自作コネクタを作る
前回は触れませんでしたが、Fivetranが標準で提供していないシステムからデータを取り込みたい場合の選択肢として、Connector SDKという仕組みがあることが分かりました。これはPythonでカスタムコネクタを開発し、Fivetranの実行基盤にデプロイできる仕組みです。(Fivetran Connector SDK)
from fivetran_connector_sdk import Connector
def update(configuration, state):
cursor = state.get("cursor", 0)
rows = fetch_from_my_api(cursor)
for row in rows:
yield op.upsert(table="my_table", data=row)
yield op.checkpoint(state={"cursor": rows[-1]["id"]})
connector = Connector(update=update)
（上記は概念を示す簡略化した例です）
Connector SDKを使う最大のメリットは、実行スケジュールや計算リソースの管理をFivetran側に任せられる点です。自前でAWS LambdaやECSタスクを使って同期処理を実装する場合に発生しがちな「実行時間の上限」や「データサイズの制限」を気にせずに済む、とされています。
自前で実装する場合
↓
Lambdaのタイムアウト・メモリ制限を考慮しながら実装
Connector SDKを使う場合
↓
同期ロジック（Pythonコード）だけを書けば、
実行スケジュールやスケーリングはFivetranが管理してくれる
前回は「Fivetranは対応済みのSourceからデータを取ってくるサービス」というイメージでしたが、Connector SDKを使えば「対応していないSourceでも、自分でコネクタを作ってFivetranの仕組みに乗せられる」という点は、前回の理解より一段柔軟性のある話でした。
Transformationsとdbtとの連携をさらに深掘りする
前回、「Fivetranにもdbt Coreと連携する機能がある」と書きましたが、具体的にどう連携するのかを調べてみました。Fivetranの管理画面からdbtプロジェクト（dbt Core）を接続すると、Fivetranの同期完了をトリガーにして、dbtのモデル実行までを1つのパイプラインとして管理できます。(Transformations for dbt Core | Fivetran)
Fivetranの同期が完了
↓
（トリガー）
↓
dbt run が自動実行される
↓
Snowflake上の分析用テーブルが更新される
さらに、FivetranにはQuickstart Data Modelsと呼ばれる、代表的なSource（SalesforceやGoogle Analyticsなど）向けにあらかじめ用意されたdbtパッケージ相当の変換モデルもあります。ゼロからdbtモデルを書かなくても、よく使われる指標（顧客あたりの売上集計など）をある程度自動生成できる、という位置づけです。
前回は「Fivetran＝運ぶ、dbt＝加工する」ときれいに役割分担している図を紹介しましたが、実際には「Fivetranの同期完了をトリガーにdbtを動かす」「Fivetranが用意したテンプレートモデルをベースにdbtを書き始める」といった形で、両者がパイプラインの中でより密に連携できるようになっている、という点が今回の発見でした。
コネクタの種類と信頼性（SLA）を整理する
前回、コネクタを「Salesforceなどのシステムからデータを取ってくる仕組み」と一括りに紹介しましたが、調べてみるとコネクタにもいくつかの分類があることが分かりました。
Database Connector
↓
PostgreSQL / MySQL / SQL Serverなど
ログや差分取得の仕組みでSourceのDBから直接同期する
Application Connector
↓
Salesforce / NetSuite / HubSpotなど
各SaaSのAPIを通じてデータを取得する
Event / File Connector
↓
S3上のファイルや、Webhookで送られてくるイベントデータなどを取り込む
Connector SDK（カスタム）
↓
標準コネクタが存在しないSourceに対して、自前でPythonロジックを書いて対応する
また、コネクタごとに「どれくらい安定して同期できるか」を示す一種の信頼性の指標（Connector SLA）も公開されており、コネクタによって同期の安定性や更新頻度の目安が異なる、という点も導入時に確認しておきたいポイントだと感じました。特に業務上重要なテーブルを同期する場合は、そのコネクタが「Standard」「Enterprise向けの高信頼性」など、どの位置づけにあるかを事前に確認しておくと安心です。
他のELTツールとの比較
Fivetranについて調べていると、比較対象としてよく名前が挙がるのがAirbyteというOSSのELTツールです。役割としては近く、どちらもSourceからDestinationへのデータ同期を担いますが、大きな違いはライセンスと運用形態にあります。
| Fivetran | Airbyte | |
|---|---|---|
| 提供形態 | フルマネージドSaaS | OSS版はセルフホスト可能、Cloud版も提供 |
| 課金 | MAR（行数）ベースの従量課金 | セルフホストなら無料（インフラ費用は別途）、Cloud版はクレジット制など |
| コネクタ開発 | Connector SDK（Python） | OSSとしてコミュニティがコネクタを追加可能 |
| 運用負荷 | 低い（Fivetranが基盤を管理） | セルフホストの場合はインフラ運用が必要 |
「運用の手間を減らしたいのでFivetranに任せる」か「コストを抑えるためにAirbyteを自前で運用する」かは、チームのインフラ運用リソースやデータ量によって判断が分かれる、という整理ができました。
セキュリティ・ガバナンス面での注意点
Business Criticalプランの存在からも分かるように、Fivetranはセキュリティ・コンプライアンス要件にもかなり力を入れているようです。調べた範囲では、次のような機能・認証が挙げられていました。
- CMEK（Customer-Managed Encryption Keys）：暗号鍵を自社で管理できるオプション
- PCI DSS Level 1：クレジットカード情報を扱う事業者向けの厳格なセキュリティ基準への準拠
- プライベートネットワーキング：VPCピアリングやPrivateLinkなどを使い、インターネットを経由しない接続経路を構成できる
- カラムのマスキング・ブロック：機密性の高いカラムを同期対象から除外したり、ハッシュ化したりする設定
金融・医療など規制の厳しい業界でFivetranを使う場合は、これらのプランやオプションが必要になるケースがある、という点も今回調べて分かったことの一つです。
実務での注意点
最後に、導入・運用にあたって気をつけたいポイントを整理します。
- MARの見積もり：導入前に、対象テーブルの更新頻度・行数を見積もり、想定コストを事前にシミュレーションしておく
- 同期頻度の見直し：デフォルトの同期頻度が業務要件に対して過剰になっていないか、定期的に見直す
- スキーマ変更の監視：自動追従してくれるとはいえ、重要なテーブルは変更通知を受け取れるようにしておく
- Connector SDKの保守：自作コネクタは自分たちでメンテナンスする必要があるため、標準コネクタが将来対応される可能性も踏まえて選定する
- 他ツールとの比較：Airbyte（OSSのELTツール）のような選択肢もあり、コストやOSS運用の手間を踏まえて比較検討されることが多い
個人的に調べてみて思ったこと
前回の記事を書いた時点では、「Fivetran＝データを自動で運んでくれる便利なサービス」というシンプルな理解でいました。しかし今回さらに調べてみると、
- 料金がMAR（ユニークな行の増分）ベースであり、更新頻度やテーブル設計次第でコストが大きく変わること
- ログベースのCDCやAPI差分取得など、Source種別によって同期の仕組みが異なること
- スキーマ変更への追従は便利だが、型変換などで完全に無停止・無考慮というわけではないこと
- Connector SDKを使えば、標準コネクタにないSourceにも対応できること
- FivetranとdbtはTransformationsやQuickstart Data Modelsを通じて、想像していたよりも密に連携できること
- Business Criticalプランのように、セキュリティ・コンプライアンス要件に応じたプラン設計がされていること
が分かりました。特にMAR課金の仕組みは、「導入すれば自動でデータ連携が楽になる」というメリットだけでなく、「テーブル設計や同期頻度次第でコストが変わる」というコスト管理の視点も持っておく必要がある、と感じさせられました。
まとめ
今回は、Fivetranについて前回の記事からさらに一歩深掘りして、次の内容を調べてみました。
- Fivetranの料金はMAR（Monthly Active Rows）という、その月に更新・挿入・削除されたユニークな行数をベースにした従量課金であること
- プランはFree・Standard・Enterprise・Business Criticalの4段階に整理されており、セキュリティ要件によって選択肢が変わること
- 同期の仕組みには、ログベースのCDCやAPI差分取得など、Source種別に応じた方式があること
- スキーマ変更への対応は自動化されているが、型変換など完全にお任せにできない部分もあること
- Connector SDKを使えば、標準コネクタが存在しないSourceにも自前でコネクタを開発して対応できること
- Fivetran Connectorとdbtプロジェクトをトリガーでつなげたり、Quickstart Data Modelsを使ったりすることで、より密に連携できること
前回は「Fivetranとは何か」という全体像が中心でしたが、今回は「実際に導入・運用するときにコストやセキュリティ、拡張性としてどこを見ておくべきか」まで踏み込むことができました。同じようにSnowflake×Fivetran×dbtでのデータ基盤構築を検討している方の参考になれば幸いです。最後まで読んでいただき、ありがとうございました！