Power BI DAX Studioで速度改善：重いメジャーを直す計測・チューニングの基本

Power BIでレポートを作り込んでいくと、ある日突然「特定のビジュアルだけ妙に遅い」「スライサーを動かすたびに固まる」「更新は速いのに操作が重い」といった壁に当たります。原因の多くは、モデル（列やリレーション、カーディナリティ）とDAX（メジャーの書き方、フィルターの掛け方）の組み合わせで発生する“クエリの重さ”です。そして厄介なのは、体感で当てに行くと遠回りになりやすいこと。そこで効くのが、power bi dax studio を使った「計測してから直す」手順です。

この記事では、重いメジャーを見つけるところから、DAX Studioで遅さの内訳を確認し、定番の改善パターンでチューニングするまでを、わかりやすく一連の流れでまとめます。

1. 速度改善は「当てずっぽう禁止」。まず測る

Power BIのパフォーマンス問題は、大きく分けると次の3つが絡みます。

  1. そのビジュアルが発行するクエリが重い

  2. 重いクエリを生むメジャー（または計算ロジック）がある

  3. そもそもデータモデルがスキャンしやすい形になっていない

ここで大事なのは、どれが支配的なのかを数字で切り分けることです。たとえば「メジャーを頑張って書き換えたのに改善しない」ケースは、実は列のカーディナリティが高すぎて圧縮が効いていない、あるいは双方向フィルターで無駄な伝播が増えている、という“モデル寄り”の原因だったりします。

逆に「モデルは綺麗なのに遅い」場合は、DAXの反復（X系関数）や複雑なフィルター構築で、計算エンジン側の負荷が跳ね上がっていることがあります。これを見分けるために、DAX Studioの出番です。

2. 基本の計測フロー：Performance Analyzer → DAX Studio

最短で効果が出る流れはこれです。

  1. Power BI Desktopの「パフォーマンスアナライザー」で遅いビジュアルを特定

  2. そのビジュアルのDAXクエリをコピー

  3. DAX Studioに貼り付けて実行

  4. Server Timings / Query Planで遅さの内訳を確認

  5. 改善案を適用して再計測（同じ条件で比較）

重要なのは「同じ条件で比較する」ことです。改善前後で、フィルター条件や表示粒度が違うと、結果がぶれます。まずは遅い場面を固定し、その場面のクエリで勝負します。

3. DAX Studioで最初に見るべき2つ：Server TimingsとQuery Plan

power bi dax studio を開いたら、まず有効化したいのは次の2つです。

  • Server Timings（サーバータイミング）

  • Query Plan（クエリプラン）

Server Timingsでわかること

ざっくり言うと「どこに時間を使っているか」です。特に見たいのは次の観点です。

  • Storage Engine（SE）寄りで時間が大きい
    → 列のスキャン、フィルター、集計など“データを読む側”が重いことが多い

  • Formula Engine（FE）寄りで時間が大きい
    → 反復、複雑な条件分岐、コンテキスト変換、テーブル式の多用など“計算側”が重いことが多い

感覚としては、SEが重いならモデル・列・フィルター設計の改善が効きやすく、FEが重いならメジャーの書き換えが効きやすい、という方向性が見えます。

Query Planでわかること

クエリが内部でどう処理されているかの“形跡”が見えます。最初は細部を完璧に読めなくても構いません。見るポイントは次のような「怪しいサイン」です。

  • 大きなスキャンが何度も走っている

  • 同じような処理が繰り返されている（同じテーブル式が多重評価される）

  • コールバック（SEとFEを行ったり来たり）が多い

  • 中間テーブルが巨大になっている気配がある

読めば読むほど精度が上がりますが、最初は「遅さのタイプ分け」だけでも十分に価値があります。

4. 計測のコツ：キャッシュと“1回目の遅さ”に注意

DAXの速度はキャッシュの影響を強く受けます。改善を評価するなら、次を意識します。

  • 1回目（コールド）と2回目以降（ウォーム）で時間が変わる

  • どちらを改善したいのかを決める（通常は操作感なのでウォームが重要になりがち）

  • 比較は「同じ条件」「同じ回数」「同じ粒度」で行う

DAX Studio側の実行でも、できれば同条件で複数回走らせて、ブレをならします。たとえば「3回走らせて2回目と3回目が安定しているか」を見るだけでも、判断がぶれにくくなります。

5. 重いメジャーを直す“基本戦術”5つ

ここからが実践です。DAX Studioで「どのタイプの遅さか」を掴んだら、次の基本戦術を上から順に当てていきます。

戦術1：反復（SUMXなど）を減らす／“列の集計”に寄せる

DAXで最も効きやすい改善の一つが「行ごとに計算する」のをやめることです。

悪い例（行ごとに計算）：

[Sales] :=
SUMX ( Sales, Sales[Quantity] * Sales[UnitPrice] )

改善の方向性：

  • 可能なら、Power Queryやデータソース側で行金額列を作り、列をSUMする

  • あるいは、同等の結果をより単純な集計で表現する

改善例（列で集計）：

[Sales] :=
SUM ( Sales[LineAmount] )

SUMXが必ず悪いわけではありません。ただ、重いレポートの中核にSUMXが多重に入っていると、ほぼ確実にボトルネックになります。「列で済むなら列で済ませる」が基本です。

戦術2：同じ計算を繰り返さない（VARでメジャー評価回数を減らす）

重いメジャーは「同じ式を何度も評価している」ことがよくあります。VARで結果を保持して再利用します。

悪い例：

[Margin Rate] :=
DIVIDE ( [Sales] - [Cost], [Sales] )

上は一見問題なさそうですが、[Sales]が重いメジャーだった場合、内部評価が増えると効いてきます。特にIF分岐の中で同じメジャーを何度も呼ぶのは危険です。

改善例：

[Margin Rate] :=
VAR s = [Sales] VAR c = [Cost] RETURN
DIVIDE ( s - c, s )

DAX StudioでQuery Planを見ると、同一メジャーが多重評価されている気配が見えることがあります。VARは“読みやすさ”だけでなく“速度”にも直結します。

戦術3：FILTER(テーブル, 条件)の多用を見直す

FILTERは強力ですが、中間テーブルを作って行単位に条件判定しやすく、状況によっては重くなります。特に次の形は要注意です。

  • FILTER(ALL(巨大テーブル), …)

  • FILTER(VALUES(高カーディナリティ列), …)

できるだけ、CALCULATEのフィルター引数（列 = 値、列 IN など）で表現できないかを考えます。

悪い例：

[Sales Selected] :=
CALCULATE (
[Sales],
FILTER ( ALL ( Product ), Product[Category] = "A" )
)

改善の方向性はケースによりますが、まずは「ALLを広げすぎていないか」を疑います。ALL(Product)はProduct全体のフィルターを剥がすので、関係するフィルター伝播が増えやすいです。「本当に剥がしたいのはどの列か」を絞るだけで改善することがあります。

例（剥がす対象を列に絞る）：

[Sales Selected] :=
CALCULATE (
[Sales],
ALL ( Product[Category] ),
Product[Category] = "A"
)

※このパターンも万能ではありませんが、発想として「テーブル全体」より「必要な列」へ縮めるのがコツです。

戦術4：コンテキスト変換（CALCULATEの入れ子）を減らす

SUMXの中でCALCULATEを呼ぶ、という形はよくあります。これが重い原因になりやすいです。

悪い例の典型：

[Something] :=
SUMX (
VALUES ( Customer[CustomerKey] ),
CALCULATE ( [Sales] )
)

この形は「顧客ごとにコンテキストを作り直して[Sales]を計算する」ので、顧客数が増えるほど重くなります。改善の方向性は複数あります。

  • そもそも顧客ごとに評価しなくて良い形に変える

  • ファクト側の列を使って直接集計する

  • 集計テーブル（顧客×日など）を別で用意して粒度を下げる

  • “ビジュアルの粒度”自体を見直す（必要以上に細かくしていないか）

DAXだけで殴るより、モデルと粒度で勝つ方が強いことが多いです。

戦術5：高カーディナリティ列と不要列を削る（モデル側の速度改善）

Server TimingsでSE寄りが重いなら、モデル改善が刺さります。ここでpower bi dax studio のVertiPaq Analyzerが役立ちます。

VertiPaq Analyzerで見たいもの：

  • 列サイズが異常に大きい列

  • 辞書（Dictionary）が膨れている列（文字列やユニーク値が多い列）

  • 不要な列（レポートで使っていない列）

  • IDが文字列になっている（本当は整数で持てる）

  • 1テーブルに属性が詰め込まれすぎている（スノーフレーク、重複）

よく効く改善例：

  • サロゲートキー（整数）に置き換える

  • 使っていない説明列、長いテキスト列を取り除く

  • 日付や分類はディメンションに寄せ、ファクトは細く保つ

  • 双方向フィルターをやめ、基本は単方向にする

  • 多対多や曖昧なリレーションを最小化する

モデルが軽くなると、同じメジャーでも「読むデータ量」自体が減って、体感速度が一気に改善することがあります。

6. ありがちな“重いメジャー”の直し方：実践パターン

ここでは、実務で頻出する重い書き方と、改善の考え方をまとめます。

パターンA：ランキングやTopNで全件を並べ替えている

ランキングは便利ですが、粒度が細かい状態で全件RANKXすると一気に重くなります。

対策：

  • 表示する粒度を上げる（必要なレベルまで集計してから順位付け）

  • TopNを先に絞る（可能なら視覚側のフィルターで点数を減らす）

  • “順位を見せたい対象”のテーブルを小さくする（集計テーブルの導入）

パターンB：前年同月、前年差の計算が重い

時間インテリジェンスは、日付テーブルが整っていないと遠回りなフィルターを組みがちです。

対策：

  • 連続した日付の専用日付テーブルを用意する

  • 日付列を「日付テーブルの列」に統一して使う

  • 不要な複数日付（自動日付テーブル）を増やさない

パターンC：条件付きのユニーク数が遅い

DISTINCTCOUNTに複雑な条件を足して遅くなるケースは多いです。ポイントは「条件をファクト側で表現できるか」です。

対策：

  • 条件をファクトの列フィルターで表す

  • どうしても複雑なら、事前にフラグ列を作っておく（Power Queryやデータソース側）

  • “誰を数えるか”の粒度を見直す（顧客を数えるならSales[CustomerKey]側で数えるなど）

7. チューニングの手順書：迷わないためのチェックリスト

最後に、重いメジャーを直すときの手順を、そのまま使える形でまとめます。これを守ると、改善が再現しやすくなります。

  1. 遅いビジュアルを1つ決める（体感で一番困っている場所）

  2. Performance Analyzerで該当ビジュアルのクエリを取得

  3. DAX Studioに貼って、Server TimingsとQuery PlanをONにして実行

  4. 遅さがSE寄りかFE寄りかを判断する

  5. FE寄りなら、次を順に試す

    • VARで重複評価を潰す

    • 不要な反復（X系）を列集計に置き換える

    • FILTERで巨大な中間テーブルを作っていないか減らす

    • CALCULATE入れ子やコンテキスト変換を減らす

  6. SE寄りなら、次を順に試す

    • 不要列を削除、データ型を適正化（IDは整数へ）

    • 高カーディナリティ列の見直し（文字列、ユニーク値）

    • リレーションを単方向中心にし、星型に寄せる

    • VertiPaq Analyzerで“太い列”を特定して削る・分離する

  7. 改善したら同じクエリ・同じ条件で再計測し、数字で比較する

  8. 正しさ（結果一致）を確認してから採用する

8. まとめ：DAX Studioは「診断器」。最短で速くするなら計測が先

power bi dax studio を使う最大の価値は、「どこが遅いのか」を勘ではなく根拠で見られることです。重いメジャーは、派手なテクニックよりも、基本に沿った“整理”で速くなることが多いです。

  • まず遅いビジュアルのクエリを固定する

  • Server TimingsでSE/FEのどちらが支配的かを見る

  • Query Planで無駄な繰り返しや巨大な中間テーブルの気配を掴む

  • 反復を減らし、列集計に寄せ、モデルを軽くする

  • 同条件で再計測して改善を確定させる

この流れが身につくと、レポートが大きくなっても「遅くなったら直せる」状態になります。最初は読み方が難しく感じても、まずは“遅さのタイプ分け”だけで十分です。計測→仮説→修正→再計測を回して、重いメジャーを確実に軽くしていきましょう。

もし困り事があるなら、まずは無料相談を

「Power BI で箱ひげ図を使って詳細分析をしたいが、データモデルやDAX設計が複雑でわからない…」「Power Automate を併用してデータ更新フローを自動化したいが、どこから手を付ければいいのかわからない」といったお悩みをお持ちの方も多いのではないでしょうか。

私たちは、Power BIやPower AutomateなどのMicrosoft製品の導入・運用支援、およびデータ活用コンサルティングを行っています。

  • 具体的な設定や開発代行

  • 社内教育のための伴走型支援

  • 有料プランへの移行タイミングやROIの判断支援

など、さまざまなニーズに合わせたサービスをご用意しています。まずはお気軽に「無料相談」へお申し込みください。下記のリンクからお問い合わせいただけます。

👉 無料相談はこちらから

7. セミナーで学ぶ！DAX 関数の実践スキル

箱ひげ図をはじめ、Power BIを使いこなすうえで欠かせないのがDAX関数の知識です。DAXをしっかり学ぶことで、データの前処理から複雑な指標の算出までスムーズにこなせるようになります。そんなDAXとデータモデル設計を効率よく学習できるハンズオンセミナーを開催しています。

🔰 Power BIハンズオンセミナー初級編

  • 短時間でデータモデリングの基礎を身につける

  • 実務にすぐ活かせるレポート作成を実践形式で学ぶ

  • 少人数制なので、つまずきポイントを都度フォロー

👉 セミナー詳細を今すぐチェック

🚀 Power BIハンズオンセミナー中級編

  • DAX関数 × データモデル設計 の実践的なノウハウを習得

  • 複雑な分析要件にも対応できる応用力を身につける

  • 即戦力として業務効率アップや社内評価向上に直結

👉 詳細はこちら

DAXをしっかりマスターすると、箱ひげ図のような高度な可視化においても、必要なデータを柔軟に加工・集計できるようになります。結果的に、組織全体のデータドリブン化をリードできる存在となり、キャリアアップにも大いに役立ちます。


▶ 無料で Power BI 導入相談をする

関連記事

この記事へのコメントはありません。

カテゴリー

アーカイブ

検索