Power BI の DAX メジャーが長すぎて保守不能になっていませんか？

長大で複雑な DAX 式は、DAX そのものの問題であることは滅多にありません。上流のデータウェアハウスで欠落していたデータ構造を、ダッシュボード上でユーザーがクリックするたびにクエリ実行時に力技で再構築していることが原因です。

長大な DAX メジャーが実際に行っていること

• 履歴データの無理な復元： ウェアハウス側で履歴（SCD）が保持されていないため、日付フィルターを何重にも重ねた CALCULATE で過去のステータスを無理やり再現している。
• 多対多リレーションの無理な解消： 中間ブリッジテーブルが存在しないため、イテレーター関数を使って関係性を動的に解決している。
• 疑似キーの生成： 結合のための適切なサロゲートキーがないため、LOOKUPVALUE や文字列結合したテキスト列でテーブル同士を結びつけている。
• 集計粒度の不整合の修正： ファクトテーブルが複数の粒度（例：日次と月次、注文と明細）を混在して保持しているため、フィルター処理したテーブルに対して SUMX を回している。

これら 4 つの重い処理が、ビジュアルごと、フィルターごと、ユーザーの操作ごとに毎回再実行されます。それが「15〜45 秒の描画待ち」の正体です。

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

• 最初から好んで複雑な式を書いた人はいません。その週の報告締め切りに間に合わせるために、動くビジュアルを作る最短ルートがそれだったからです。
• DAX のロジックは .pbix ファイルの内部に閉じ込められているため、上流のチームからはレビューも再利用もできません。
• あなたにはメジャーを書き直すことはできても、必要なディメンションを DWH に追加することはできません。

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

• 履歴管理、サロゲートキー、ブリッジテーブル、粒度設計は「DWH」の仕事： DAX 式の中でユーザーのクリックごとに再計算させるべきではありません。
• 1 箇所の中央基盤に集約すべき： データウェアハウスやデータハブ側で 1 度だけ構造化し、すべてのレポートがそれを参照すべきです。
• 「DWH の改修は高額で時間がかかる」と思われるかもしれませんが： 自動化プラットフォームを導入すれば、モデルから構造とパイプラインが自動生成されるため、数ヶ月も待たされることはありません。

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

Datavault Builder は、SQL Server、Azure SQL、Synapse、Fabric、Snowflake、Databricks、BigQuery 上で、キー、履歴、粒度が整ったクリーンなスタースキーマを自動生成します。

• 明確なサロゲートキー： リレーションシップが自然に成立し、重い LOOKUPVALUE は完全に不要になります。
• Point-in-Time（PIT）テーブル： 「3 月時点の状況」はメジャーの計算ではなく、テーブルの単純な結合（JOIN）としてミリ秒で回答されます。
• ブリッジテーブルの標準整備： 多対多リレーションは Power BI に届く前に解決されます。
• ファクトテーブルの単一粒度： 粒度が揃っているため、SUM は本来の単純な合計として機能します。
• メジャーはシンプルな SUM、AVERAGE、COUNT だけになり、チームメンバーの誰もが瞬時にコードレビューできるようになります。

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

「ディメンションの履歴が管理されていないため、メジャー側でクエリ実行時に無理やり過去のデータを復元しており、ダッシュボードの表示が遅くなっています。DWH 側に Point-in-Time テーブルと適切なサロゲートキーを用意して、メジャーを単純な SUM に簡素化できませんか？」

単に「レポートを高速化してほしい」と頼むのではなく、何が構造として欠落しているのかを具体的に伝えることが解決への近道です。