Fivetran+dbt Labs統合完了、データ基盤ベンダー集約の判断どころ

Fivetranで基幹システムやSaaSのデータを取り込み、dbt（SQLでデータ変換処理を記述・管理するツール）で加工するデータ基盤を運用する、従業員数百人規模の企業のデータエンジニアリング担当が、次の契約更新までに向き合う判断がある。データの取り込み（EL）と変換（T）を別ベンダーの製品で組み合わせる従来構成を続けるか、統合後の単一ベンダーへ寄せるかという選択だ。両社の合併は2026年6月1日に完了しており、2026年9月16日のdbt Summitでは合併後初めてとなる大型の製品発表があった[1][2]。取り込みと変換をまたぐ一体型の機能が実際に動き出したことで、契約更新が近い企業ほどライセンス体系と移行コストを見極める必要が出てきた。本稿は発表内容と統合の実像を整理し、日本企業が更新前に確認すべき論点をまとめる。

予備知識

• ELT: データをまず読み込み（Extract-Load）、その後に変換（Transform）する処理方式。Fivetranが取り込みを、dbtが変換を担当する組み合わせが一般的。
• Apache Iceberg: 複数の処理エンジンから同じデータを読み書きできるオープンなテーブル形式。特定のウェアハウス製品に依存しないデータ保管を可能にする。
• レイクハウス: 安価なストレージ（データレイク）と、構造化されたクエリ機能（データウェアハウス）を組み合わせた基盤の呼び方。
• MAR（Monthly Active Rows）: Fivetranの主要な課金指標。月間で変更・追加された行数に応じて費用が決まる。

単一ベンダーへの集約が進む場面で、ロックインのリスクをどう見積もり交渉材料にするかを考えたい調達・IT企画担当向け

ベンダーロックイン DX時代のソフトウエア民主化革命 ～ The Punks From Andover ～

created by Rinker

• Amazon
• 楽天市場
• Yahooショッピング
• メルカリ

dbt Summit 2026で発表された内容——GAとベータの線引き

2026年9月16日、Fivetran + dbt Labsはラスベガスで開催したdbt Summitで、複数の新機能を発表した[1][3][4]。目玉は変換エンジンをRustで書き直した「dbt v2」で、正式提供（GA）に達している。1万モデル規模のプロジェクトの構文解析が、旧エンジン比で最大10倍速くなったとしている[1]。

新機能はGAとベータが混在する。ダッシュボード定義をYAMLで管理する「dbt Charts」はパブリックベータ、Icebergテーブルに直接クエリする「Lake Compute」はプライベートベータにとどまる[1][3]。

取り込み・変換・活用の各層をどう組み合わせるか、ベンダー選定以前の設計思想を整理したい担当者向け

実践的データ基盤への処方箋～ ビジネス価値創出のためのデータ・システム・ヒトのノウハウ

created by Rinker

• Amazon
• 楽天市場
• Yahooショッピング
• メルカリ

単一ベンダー集約とは何を選ぶことか——構成の比較

合併前は、取り込みと変換を別会社の製品で組み合わせ、契約・サポート窓口・価格体系がそれぞれ独立していた。合併後はこの境界が薄れ、一つの契約で連携から変換、BI連携まで扱える方向に進む。

個別最適な製品を組み合わせる柔軟性を取るか、運用の手間を減らす統合を取るかという判断だ。統合を選ぶほど、乗り換えの摩擦（ロックイン）は大きくなる。

dbt v2の10倍という数字は、旧エンジンとの相対比較であり、他社の変換ツールとの比較ではない点に注意がいる[1]。単一ベンダー化の是非は速度だけでなく、契約全体の柔軟性で判断する必要がある。

コスト／調達

Google Cloud Monitoringのアラート課金開始、契約更新前に点検を

Google Cloud上でマイクロサービス数十〜数百単位のアラートポリシーを運用している企業のSRE・クラウドコスト管理担当にとって、アラート自体は「無料で使える安全網」という位置づけだった。Google Cloudは今後、この前提を変[…]

既存のマルチベンダー構成への影響

FivetranとdbtをすでにセットでETL/ELT基盤として使う企業への影響は比較的小さい。契約更新のタイミングで新機能が使えるようになる形が中心だ。

一方、AirbyteやMatillionなど他社の連携ツールとdbtを組み合わせている企業や、dbtの代わりにウェアハウス標準の変換機能を使う企業は、選択肢が狭まる可能性がある。機能が一体で進化する分、他社ツールとの組み合わせでは同等の機能を個別に追いかける負担が増える。

Lake Computeはモデル単位でエンジンを選べる設計で、全面移行を迫るものではない[3]。既存のウェアハウス中心の構成を残し、一部のモデルだけIceberg処理に切り出す使い方が想定されている。

コスト

Snowflakeコスト異常検知が部門単位に、チャージバック運用刷新

事業部ごとにSnowflakeの利用料を配賦し、四半期ごとに経理へチャージバックの内訳を報告している企業のデータ基盤担当にとって、コストの異常検知は長年もどかしい機能だった。Snowflakeの異常検知はアカウント全体、あるいは組織全体で[…]

SIer運用のデータ基盤担当が契約更新前に見るべき論点

日本企業では、データ基盤の構築・保守をSIerに委託している例が多い。ベンダー統合の影響は、自社のIT部門だけでなくSIer経由の契約条件を通して現れる。

稟議・契約更新のサイクルは半年から1年単位が一般的で、数か月おきに機能追加が続くFivetran + dbt Labsとはペースが合いにくい。稟議には最新の価格体系や統合後のサポート範囲を反映させる必要がある。

金融・製造業など監査対応が厳しい業種では、データ系譜（どのデータがどう変換されたかの追跡）の証跡がベンダー統合でどう変わるかも確認事項になる。dbt Charts採用でBI定義まで同じリポジトリに入ると、監査証跡の範囲も広がる。

IT・データ基盤部門の次の一手は、次回契約更新前に統合後の価格体系とサポート範囲の見積もりをベンダーに求めることだ。決裁側の判断材料は、乗り換えコストと運用一本化によるコスト削減を並べ、更新時期をずらすかどうかを比較することになる。

まとめ

FivetranとdbtLabsの合併は2026年6月に完了済みで、9月のdbt Summitはその統合が製品レベルでどこまで進んだかを示す最初の発表だった。dbt v2とdbt StateはGAに達したが、Lake ComputeとFivetran Context Layerはまだプライベートベータで、全面移行を判断できる段階ではない。

読者が次に取るべき行動は二つある。IT・データ基盤部門は、現行契約の更新時期とベータ機能のGA予定を照らし合わせ、待つか動くかを整理すること。決裁側は、単一ベンダー化によるロックインの度合いと運用コスト削減額を比較し、更新のタイミングを判断材料にすることだ。機能の派手さより、自社の契約更新サイクルに合うかどうかで見るべき局面といえる。

よくある質問（FAQ）

Q. dbt v2への移行は必須ですか。
A. dbt Labsはv2をGAとして提供しているが、既存プロジェクトを強制的に移行させる発表内容ではない。移行時期は利用企業側の判断になる。

Q. Lake Computeを使うとウェアハウス契約が不要になりますか。
A. ならない。Lake Computeはモデル単位で使う設計で、既存のウェアハウスと併用する形が前提になっている[3]。

Q. 合併によってFivetranの課金体系（MAR）は変わりましたか。
A. 発表内容にMAR課金自体の変更は含まれていない。統合後の価格体系は個別の商談・見積もりで確認する必要がある。

出典