dbt 導入後もデータ取り込み（インジェスチョン）に悩まされていませんか？

dbt（現在は Fivetran と同一企業）は、明確に「データ変換（Transform）」に特化したツールです。外部ソースからのデータ抽出（Extract）やロード（Load）は行いません。これは設計思想としては明快ですが、結果としてすべてのデータチームは、最初の dbt モデルを実行する前に、別のデータ取り込み製品を選定・調達・設定し、追加の利用料を支払わなければならないという構造的な課題を抱えることになります。

このギャップが見た目以上に高コストな理由

• 2 つの製品、2 つの請求書： 取り込みツールは行数（MAR）やコネクタ数で課金され、変換ツールはアカウント数や実行量で課金されます。互いの課金体系や処理負荷を考慮しないまま別々にコストが膨らみます。
• 2 重のスキーマ構造： 取り込みツールは自身が扱いやすい独自の形状でデータをランディングさせます。その結果、dbt のステージング層は、その取り込みツール特有のスキーマ構造を自社プロジェクトで使える形へ加工し直すためだけに最初の何層ものモデルを費やすことになります。
• システム境界でのインシデント頻発： 取り込み側でのスキーマ変更が、翌朝の dbt 実行エラーとして突然発覚します。「取り込み側の問題か、変換側の問題か」という責任のなすり合いが、問題解決の初動を遅らせます。
• 企業の合併はアーキテクチャの分断を即座には解決しない： 2026 年 6 月 1 日に Fivetran と dbt Labs は 1 つの会社になりましたが、依然として別々の製品であり別々の料金体系です。ランディングされた生データがそのまま分析用モデルにならないという本質的な課題はそのまま残っています。

データ取り込みが本来属するべき場所

• データモデルのすぐ隣： ビジネスキーや履歴管理のルールを熟知しているツールこそが、モデルが要求する最適な形式でソースデータをロードするのに最も適しています。
• 行単位ではなく、ウェアハウス全体のインフラとして課金： プラットフォームを介した直接ロードは自社の既存コンピュート上で動作するため、取り込み行数に応じた法外な追加課金は発生しません。
• 単一の責任範囲： システム間の受け渡しポイントが存在しなければ、どちら側がパイプラインを破壊したのかという不毛な議論自体が消滅します。

Datavault Builder による変革

Datavault Builder は、同一プラットフォーム上でデータの取り込みとモデリングを一体化して実行します。データベース、ファイル、REST API、NoSQL、Python ソースからのバッチ、差分、CDC ロード、さらには Kafka などのストリーム（Trino 経由のマイクロバッチ）を直接取り込み、Hub、Link、Satellite へマッピングします。

• ランディングのための別製品が不要： ウェアハウスを自動生成する単一プラットフォームにデータソースを直接接続。契約もツールも 1 つにまとまり、障害時の調査箇所も 1 箇所で完結します。
• 余計な中間スキーマの排除： ランディングテーブルは到着と同時に直接モデルへマッピングされます。ステージング層で取り込みツールの独自仕様を元に戻すような不毛な作業は一切発生しません。
• スキーマ変更への堅牢な対応： 新しいカラムの追加はマッピング定義の更新だけで対応でき、翌朝のパイプライン障害を引き起こしません。
• 同一ツール内で配信層までスムーズに構築： セマンティック層上でのドラッグ＆ドロップにより、バージョン管理されたビジネスルールを持つマートを直感的に作成可能。dbt での運用を継続したい場合も、同一モデルから dbt モデルを自動生成できます。
• 既存コネクタとの共存も可能： 小規模なロングテール SaaS ソースは既存のマネージドコネクタをそのまま使い続け、基幹系や大容量ソースをプラットフォームで取り込むといった柔軟な運用が可能です。

今すぐ判断すべきこと

取り込みツールの出力スキーマと、それを dbt で修正・加工しているステージングモデルを、別々の担当者が管理しているデータソースをリストアップしてみてください。それらのソースこそが、プラットフォームを通じて直接ランディング・統合すべき最優先の対象です。