Fivetran の請求額がソーステーブルの更新頻度によって急上昇していませんか？

Monthly Active Rows（MAR：月間アクティブ行数）は、マネージドコネクタの課金指標としては一見合理的に思えます。しかし、変更されるデータ行の数を決定するのが「他者」である場合、これは深刻な予算リスクに化けます。ERP での全品目価格の一括改定、全レコードのカラム仕様を変更するスキーマ移行、顧客マスターの半数に及ぶデータクレンジングなど、これらは影響を受けたすべての行を「アクティブな行」として再カウントし、事後的に莫大な請求書をもたらします。

請求額を自社でコントロールできない理由

• MAR は「ビジネス価値のある行」ではなく「触られた行」を数える： 1,000 万件のレコードのうち 1 つのカラムを一括更新するマイグレーションは、下流のレポートに何の影響も与えない場合であっても、きっちり 1,000 万アクティブ行として請求されます。
• 引き金は常に上流で引かれる： ソースシステム側の運用チームは、一括更新処理を実行する前にデータチームの取り込み予算を確認したりはしませんし、確認すべきでもありません。
• 同じデータ行に対して二重にコストを支払っている： データの受け入れ時（インジェスチョン時）に行単位の利用料を支払い、さらに下流でどの行が変更されたかを把握できないために全件再計算を行い、ウェアハウスのコンピュート費用を二重に支払っています。
• 正確な予算予測が不可能： コネクタはシステムのアクティビティを計測しますが、そのアクティビティは自社データチームではなく他部門のプロジェクト進行によって決まります。

Fivetran は自社の料金体系に沿って忠実に動作しているに過ぎません。真に問うべきは、「最もデータ量が多く、最も頻繁に更新される基幹テーブルに対して、行単位の従量課金モデルを適用することが経済的に正しいのか」という点です。

コストが本来属するべき場所

• 大容量テーブルの取り込みはウェアハウス自身の仕事： モデル駆動型プラットフォームは、ウェアハウスを自動生成する一環としてそれらのデータを直接ロードし、自社がすでに保有しているコンピュート上で稼働させます。
• 下流へは差分（デルタ）のみを移動させる： 自動化された Data Vault アーキテクチャは、変更があったデータのみを Hub、Link、Satellite へ反映します。ステージングでの全件リロードが、上位レイヤーすべての全件再処理に波及することはありません。
• ロングテール SaaS はコネクタに残す： マネージドコネクタは、データ量が少なく MAR が小さく安定している低ボリュームの SaaS ソースにおいて真価を発揮します。

Datavault Builder による変革

Datavault Builder は、データベース、ファイル、REST API、NoSQL、Python ソース、Kafka ストリームからのバッチ、差分、CDC ロードを直接実行できる取り込み機能を内蔵しており、ウェアハウスの生成と同一のプラットフォームで完結します。

• 高頻度テーブルを行単位課金のループから除外： プラットフォームを介してステージングへ直接ランディングさせることで、コネクタの請求額が ERP チームの作業カレンダーに連動する悪夢を断ち切ります。
• リロードの影響をステージング内に封じ込める： 自動生成された Vault ロードは、すでに履歴保持されているデータと照合して差分のみを移動させるため、上流でのリロードがシステム全体の再計算に波及しません。
• コネクタを使い続けるテーブルとも安全に共存： 生データのランディングテーブルと履歴管理レイヤーが明確に分離されているため、テーブルごとにコネクタを使うか直接取り込むかを自由に選択・変更できます。
• コストを明確なキャパシティ計画として管理： ウェアハウスのコンピュート費用は、事前に測定・予約・予測が可能です。他社システムの予測不能な行数変動に振り回されることはありません。

今すぐ判断すべきこと

直近 6 ヶ月間の MAR レポートを確認し、テーブルごとに降順で並び替えてみてください。もし上位 5〜10 個のテーブルが請求額の大部分を占めているなら、それらこそが自社プラットフォームによる直接取り込みへ移行すべき対象です。その境界線より下のロングテールなテーブル群は、今のままコネクタに任せておいて問題ありません。