Fivetran のスキーマ仕様により、ロードのたびに手動でデータ再加工を強いられていませんか？

コネクタごとの標準化されたスキーマは、マネージドパイプラインを最短で稼働させるための最大の利点です。しかし同時に、2 ヶ月目以降の運用を困難にする根本的な原因でもあります。データの構造はコネクタ側によって一方的に決定されるため、ビジネスが真に求めているもの（名寄せされた統一キー、独自カスタム項目、複数システムを横断するルール）はすべて、dbt や手作業の SQL を使って後から自前で構築しなければなりません。

固定スキーマが開発の足かせになる理由

• スキーマはベンダーのものであり、自社のものではない： コネクタのスキーマはソースシステムの API 仕様を反映したものであり、自社のビジネスで顧客、注文、勘定科目をどのように捉えているかを考慮したものではありません。
• ロード後の SQL が事実上のブラックボックスモデル化する： キーの統一、重複排除、履歴管理、ビジネスルールが、全体設計のない場当たり的なスクリプト群に散らばり、開発者ごとの流儀で記述されてしまいます。
• ソースの変更が本番障害として発覚する： 上流でのカラム名変更が下流の変換処理を破損させ、役員向けダッシュボードの表示エラーや数値の不整合として初めて顕在化します。
• 同一エンティティがサイロ化したまま蓄積される： CRM の顧客、ERP の顧客、EC サイトの顧客は、誰かが手作業で結合クエリを書くまで、3 つの別々のテーブルと 3 つの異なるキーとして存在し続けます。

これはコネクタ自体の欠陥ではありません。データを運ぶためのツールに、ビジネスがそのまま利用できるデータ構造まで期待すること自体に無理があるのです。

データ構造が本来属するべき場所

• データ構造はスクリプトではなく、モデリングの決定事項である： ビジネスキー、リレーションシップ、属性はモデルとして一度だけ宣言され、ロードコードはその定義から自動導出されるべきです。
• Raw レイヤーは変化を吸収できるように設計されるべき： Data Vault 2.0 は、キー、リレーション、コンテキストを明確に分離しているため、新しいソース属性の追加は新しい Satellite の追加として処理され、既存構造の書き直しは不要です。
• ビジネスルールは Raw レイヤーの上位に配置すべき： 統合ディメンションやビジネスロジックを Business Vault やマート層に配置することで、ソース側のスキーマ変更から完全に隔離できます。

Datavault Builder による変革

Datavault Builder は、固定的なターゲットスキーマの制約をモデル駆動型の Data Vault 2.0 レイヤーに置き換え、ロード用コードをモデルから自動生成します。

• ランディングテーブルはコネクタの出力そのまま： 手作業によるデータ加工は不要です。ランディングテーブルから Hub、Link、Satellite へのマッピングは画面上で視覚的に行えます。
• モデル内でビジネスキーを統一： 3 つのシステムからの顧客データは 1 つの Hub に統合され、各ソース固有のコンテキストはそれぞれの Satellite に格納されます。結合ルールは 1 箇所で宣言されます。
• ソース変更はマッピングの修正だけで完了： マッピングを更新して再生成するだけで、その上位にある Business Vault やマートには一切影響を与えません。
• 軽微なスキーマ変更への自己修復： カラムが消失した場合は警告付きで NULL としてロードし、文字長が拡張された場合は自動的にデータ型を拡張して処理を継続します。
• すべてのパイプラインが一貫した形状に統一： ロード処理はプラットフォームによって自動生成されるため、開発者ごとの癖がなく、作成者本人しか読めないスクリプトは撲滅されます。
• ドキュメントとデータリネージも自動生成： すべてのルールは Business Vault またはマート層に集約され、モデル上で可視化され、レポートからソースまで追跡可能です。
• 最終出力は扱いやすいスタースキーマ： 上位レイヤーとしてディメンショナルマートが自動生成されるため、BI ツール側には洗練されたコンフォームドディメンションが提示されます。

今すぐ判断すべきこと

コネクタの出力を加工するためだけに存在しているロード後スクリプト（キーの統合、重複排除、履歴管理、異種ソース間の結合）を棚卸ししてみてください。そのスクリプト群こそが、これまで手作業で保守してきた「見えないデータモデル」の実体であり、自動生成プラットフォームへ移行すべき最初の対象です。