Power BI の深夜のスケジュール更新が失敗し続けていませんか？

定期更新の失敗は、メモリが足りないから起きているのではありません。本来更新バッチのタイミングで実行すべきではない重いデータ加工処理を、Power BI に肩代わりさせていることが原因です。

何が壊れているのか：クエリの折りたたみ（Query Folding）の破綻

• M コードが正常に折りたたまれている場合： Power Query は 1 つの最適化された SQL 文を生成し、実際の結合や集計処理はデータベース側で行われます。Power BI は集計済みの結果を受け取るだけです。
• 折りたたみが破綻した場合： Power Query 自身がデータ変換エンジンとして動作せざるを得なくなります。膨大な生データテーブルをネットワーク越しにメモリ上へ吸い上げ、PC やサービスのリソースを消費して自前で処理を行います。
• 警告なしで静かに破綻する： テーブルのマージ、カスタム列の追加、あいまい一致（ファジーマッチ）、インデックス列の挿入などを行った瞬間、クエリの折りたたみは静かに解除されます。警告画面は出ません。
• 手元のテストをすり抜ける： 開発者のノート PC でテストする際はテスト用テーブルのデータ量が少ないため高速にパスします。しかし、本番環境でデータが蓄積されるにつれて破綻します。

なぜその負担がアナリストに押し付けられるのか

• その場しのぎの加工ステップが必要になったのは、レポートを納期通りに公開しなければならなかったからです。必要なディメンションがウェアハウスに存在せず、カラム追加を依頼しても数ヶ月待ちと言われたためです。
• データ変換ロジックが .pbix ファイルの内部に隠蔽されており、上流のデータエンジニアからは一切見えません。
• あなたにはレポートを変更する権限はありますが、ウェアハウス側を変更する権限が与えられていません。

本来その処理が行われるべき場所

• マージ、カスタム列、あいまい一致は「データ統合」の仕事： Power Query 内でこれらを実行すると、毎回の定期更新のたびにゼロから再計算されます。
• 1 箇所の中央基盤に集約すべき： データウェアハウスやデータハブ側で 1 度だけ統合処理を行い、すべてのレポートが完成したディメンションを参照すべきです。
• 「DWH の改修は高額で時間がかかる」と思われるかもしれませんが： その見積もりは手作業でパイプラインを構築することを前提としています。専用の自動化プラットフォームを活用すれば、モデルからパイプラインが自動生成されるため、必要なコストと期間は劇的に圧縮されます。

完成したモデルが届いたときに変わること

Datavault Builder は、SQL Server、Azure SQL、Synapse、Fabric、Snowflake、Databricks、BigQuery など、既存のデータベース上でネイティブに動作するスタースキーマを自動生成します。

• Power Query の M コードは単なる SELECT * FROM dim_customer となり、クエリの折りたたみが 100% 確実に機能します。
• レポート側でのマージ、パース、あいまい一致は一切不要になり、レポート定義から完全に消え去ります。
• 定期更新がわずか数秒で、かつ極めて安定的・予測可能に完了するようになります。
• 緩やかに変化するディメンション（SCD）は、レポート側での近似計算ではなく、上流の Vault サテライトとして正確に管理されます。
• すべての計算ロジックにデータリネージが付与され、「この数値の出所はどこか」という疑問にいつでも明確に回答できます。

上流チームに何を要求すべきか

単に「更新が失敗し続けている」と伝えるのではなく、以下のように依頼してください：

「Power Query のステップでクエリの折りたたみが効かなくなっており、更新のたびに生データ全体をメモリに読み込んでタイムアウトしています。レポート側で個別加工しなくて済むよう、ウェアハウス側でコンフォームドディメンションとファクトテーブルを整備してもらえませんか？」

もし上流から「適切なモデリングには 3 ヶ月かかる」と返答されたなら、まさにその構築障壁を取り除くために設計されたのが Datavault Builder です。