Power BIのレポートが「重い」「表示に時間がかかる」「スライサーを触るたびに固まる」。この状態が続くと、利用者はすぐに離れてしまいます。最初は我慢してくれても、会議前に待たされる、現場でサクッと見たいのに開かない、そうした体験が積み重なるほど「結局Excelでいい」という空気に戻りがちです。
一方で、レポートの性能改善は、感覚で直そうとすると遠回りになりやすい領域です。DAXが悪いのか、モデルが悪いのか、ビジュアルが重いのか、そもそもページに要素を載せすぎているのか。原因が混ざったまま当てずっぽうで手を入れると、直したつもりが別の場所が遅くなったり、改善幅が小さくて疲弊したりします。
そこで役に立つのが、Power BI DesktopにあるPerformance Analyzerです。どのビジュアルが、どの処理に、どれだけ時間を使っているかを計測できるため、遅さの原因を「見える化」して、改善の優先順位を正しくつけられます。この記事では、現場でそのまま使える手順として、計測の仕方、読み方、よくある原因別の打ち手、改善の進め方までを丁寧にまとめます。
────────────────────────────
-
まず決める：何が遅いのかを“利用シーン”で定義する
────────────────────────────
性能改善は、最初に測り方を決めないとブレます。次のように「誰が、いつ、どう操作して、どこが遅いのか」を先に定義します。
・どのページが遅いか（例：売上サマリ、店舗別、商品別など）
・どんな操作で遅いか（初回表示、スライサー変更、ドリルダウン、ページ移動）
・想定するフィルター状態（例：期間＝当月、部門＝全体、地域＝関東など）
・“許容時間”の目標（例：ページ表示は2秒以内、スライサー反応は1秒以内）
ここを決める理由はシンプルです。レポートは使い方によって重さが変わるからです。初回表示が遅いのか、スライサー変更が遅いのかで、手を入れる場所が変わります。
────────────────────────────
2. 計測の前準備：結果がブレない条件を作る
────────────────────────────
Performance Analyzerで計測しても、環境が揺れると数字が安定しません。完璧でなくていいので、次のポイントを押さえると判断がしやすくなります。
・Power BI Desktopを再起動してから測る（メモリ状態の影響を減らす）
・重いアプリや大量ブラウザタブを閉じる（CPU/メモリ競合を減らす）
・同じ操作手順で複数回測る（1回の結果で決めない）
・比較するときは同じフィルター状態に揃える
・改善前後で同条件の測定を取って差分を見る
特に大切なのは、改善前と改善後を同じ条件で比較することです。数字が少し揺れるのは普通なので、1回の計測で一喜一憂せず、平均的に改善しているかで判断します。
────────────────────────────
3. Performance Analyzerの基本操作：記録して、更新して、遅い順に見る
────────────────────────────
実務の流れは次の通りです。
手順1：Performance Analyzerを開く
Power BI Desktopの表示メニューからPerformance Analyzerを開きます。右側にパネルが表示されます。
手順2：記録を開始する
Start recording（記録開始）を押します。これで、この後に実行されるビジュアルごとの処理時間が記録されます。
手順3：対象ページでRefresh visuals（ビジュアルの更新）を実行する
記録を開始したら、Refresh visualsを押してページ内のビジュアルを一斉に再描画させます。初回表示の遅さを測るときに便利です。
手順4：遅い操作を再現する
スライサーを動かす、ページを切り替える、ドリルダウンするなど、遅いと感じる操作を実際に行います。その操作に紐づくビジュアルの処理が記録されます。
手順5：結果を時間の大きい順で確認する
一覧に、ビジュアルごとの処理時間が出ます。まずは合計時間が大きいものから見ます。改善の効率が一気に上がります。
ここまでが、最短で「どれが犯人か」を特定する作業です。次からが読み解きです。
────────────────────────────
4. 結果の見方：DAX query / Visual display / Other を切り分ける
────────────────────────────
Performance Analyzerの結果は、主に次の内訳で時間が出ます。
・DAX query：データを計算・取得する時間（多くの場合、モデルとDAXが関係）
・Visual display：ビジュアルを描画する時間（点が多い、表が大きい、カスタムビジュアルなど）
・Other：準備処理や周辺処理（相互作用、フィルター処理、内部処理などが混ざる）
ここが最重要ポイントです。合計が遅いとき、どの内訳が支配的かで、やるべき改善が変わります。
・DAX queryが長い → まずDAXかモデルの改善を疑う
・Visual displayが長い → 表示する点数や表現の見直しを疑う
・Otherが長い → 相互作用やページ構成、フィルター設計、過剰な要素を疑う
原因を当てずっぽうでいじるのではなく、この分類に沿って打ち手を選ぶだけで、改善が速くなります。
────────────────────────────
5. 実務手順：遅い原因を特定して直すまでの流れ
────────────────────────────
ここからは現場向けの手順です。おすすめは、次の順に進めることです。
ステップA：ページ全体の“上位3つの遅いビジュアル”を特定する
ページにビジュアルが多いほど、上位少数が全体の遅さを作っていることが多いです。まずは上位3つだけに集中します。
ステップB：上位ビジュアルの内訳を見て、原因のタイプを決める
DAXが遅いのか、表示が遅いのか、Otherが大きいのかを判断します。
ステップC：原因タイプ別の改善を入れる
改善は小さく入れて、再計測して効果を確認します。いきなり大改造すると、どれが効いたのか分からなくなります。
ステップD：改善が効いたら、次の遅いビジュアルへ移る
性能改善は、上位から順に潰すのが最短です。
この流れを回すと、無駄な修正が減り、短時間で体感が変わります。
────────────────────────────
6. DAX query が遅いときの打ち手：測って、絞って、軽くする
────────────────────────────
DAX queryが支配的なときは、計算そのものが重いか、モデルがその計算に不向きな状態です。ここでは実務で効く手順に絞って解説します。
6-1. まずやる：遅いビジュアルのクエリをコピーして“再現できる形”にする
Performance Analyzerには、ビジュアルのクエリをコピーできる機能があります。これを使うと、どの計算が重いのかを外部ツールで深掘りできます。深掘りをしない場合でも、コピーした内容が残るだけで原因追跡が楽になります。
6-2. よくある重さの原因と改善パターン
原因1：不要に大きいテーブルをスキャンしている
・ファクトが巨大なのに、複雑なFILTERで全行を舐める
・日付やカテゴリで絞れるのに、絞り込みが弱い
改善の方向性
・フィルターが効く形にDAXを整える
・日付テーブルを正しく使い、期間で絞る
・関係の向きやキーの設計を見直して、無駄な探索を減らす
原因2：反復処理（X系）が必要以上に重い
SUMX、AVERAGEX、RANKXなどは便利ですが、対象行が多いと重くなります。
改善の方向性
・可能ならSUMなどの集計関数に寄せる
・前処理で計算済みの列を作る（Power Query側で計算して取り込む）
・変数（VAR）で同じ計算の繰り返しを減らす
・計算対象のテーブルを絞ったうえで反復する
原因3：フィルターを増やしすぎて複雑化している
CALCULATEの中で複雑なFILTERを重ねるほど、意図しない負荷が出やすいです。
改善の方向性
・フィルター条件を整理して、必要なものだけにする
・条件を前処理やディメンション側に寄せる
・列の粒度を揃え、キーで繋がる形にする（スター型に寄せる）
原因4：モデルが複雑で、計算が回り道している
多対多、双方向フィルター、関係のループ、巨大なディメンション、高カーディナリティ列が多い。これらはDAXを重くしやすい要因です。
改善の方向性
・スター型に寄せる（ファクト中心＋ディメンション）
・双方向フィルターは必要最小限にする
・高カーディナリティ列（ID、詳細文字列）の露出を減らす
・使っていない列はモデルから削除する（列削除は圧縮効率にも効く）
6-3. DAXを直す前に効く“モデル側の軽量化”
DAXの改善より先に、モデルの軽量化で一気に効くことがあります。
・不要列の削除（特に文字列、長いテキスト、ユニークIDの乱立）
・データ型の最適化（整数で持てるものを文字列で持たない）
・日付は日付テーブルを中心に（自動日付テーブル任せにしない）
・キー列の統一（関係が素直に貼れるようにする）
モデルが軽くなると、同じDAXでも体感が変わることがよくあります。
────────────────────────────
7. Visual display が遅いときの打ち手：描画量を減らし、表現を変える
────────────────────────────
Visual displayが長い場合、計算は速いのに「描くのが大変」な状態です。特に次のビジュアルは重くなりがちです。
・テーブル、マトリックス（行数や列数が多いほど重い）
・散布図（点が多いほど重い）
・地図系（描画コストが高い）
・カスタムビジュアル（内部処理が読みにくい）
・細かいラベル表示、条件付き書式が多い表
改善の基本方針は、描画する点やセルを減らすことです。
7-1. 表やマトリックスが重いときの現実解
・初期表示は集計値に寄せ、明細はドリルスルーや別ページに分離する
・列数を減らす（特に文字列列を並べすぎない）
・ページングや検索を使い、全件を一度に見せない設計にする
・上位Nに絞る（TopNで最初は軽く見せ、必要なら掘る）
7-2. 点が多いグラフが重いとき
・粒度を上げる（例：日次を週次や月次にする）
・カテゴリ数を絞る（上位だけ表示、その他はまとめる）
・スライサーで範囲を絞ってから表示する導線にする
・細かいデータは別ページの詳細で見る設計にする
7-3. カスタムビジュアルの扱い
カスタムビジュアルは便利ですが、性能面ではボトルネックになりやすいです。次の考え方が安全です。
・標準ビジュアルで代替できないかを先に検討する
・同じデータ量で標準ビジュアルと比較して、差が大きいなら見直す
・重要ページでは極力標準ビジュアル中心にする
“格好良いが重い”は、運用で必ず嫌われます。重要レポートほど堅実な選択が強いです。
────────────────────────────
8. Other が長いときの打ち手：ページ設計と相互作用を疑う
────────────────────────────
Otherが大きい場合、計算や描画だけではなく、フィルター処理や相互作用、ページ構成が足を引っ張っている可能性があります。ここは見落とされやすいのですが、効くときは大きく効きます。
8-1. ページにビジュアルを載せすぎていないか
1ページに要素を詰め込みすぎると、スライサーを触った瞬間に大量のビジュアルが再計算・再描画されます。
改善の方向性
・ページを目的別に分割する（概要、詳細、例外の3ページなど）
・最初に見るべきKPIだけに絞った軽いトップページを作る
・詳細はドリルスルーや別ページへ逃がす
8-2. 相互作用が過剰になっていないか
ビジュアル間の相互作用（クロスフィルター/ハイライト）が多いと、操作のたびに処理が増えます。
改善の方向性
・必要な相互作用だけ残し、不要な相互作用を切る
・スライサーの対象を絞る（全部のビジュアルに効かせない）
・同期スライサーも必要最小限にする
8-3. DirectQueryや複合モデルの場合は“問い合わせ回数”を意識する
DirectQueryは、操作のたびにデータソースへ問い合わせが飛ぶため、ページが重くなりやすいです。
改善の方向性
・必要なときだけ絞り込みを適用する導線にする（適用ボタン運用など）
・集計テーブルや集約を使い、普段は軽い問い合わせで済ませる
・1操作で複数クエリが飛んでいないかを確認し、ビジュアル数を減らす
────────────────────────────
9. 改善の進め方：性能改善は“予算”と“基準”を作ると定着する
────────────────────────────
性能改善を一度やって終わりにすると、数か月後にまた遅くなります。レポートは育つほど要素が増えるからです。そこでおすすめなのが、性能の基準を作ることです。
例としての性能基準
・主要ページの初回表示は2〜3秒以内
・スライサー操作の反応は1秒前後
・更新時間は許容枠内（例：15分以内）
・Sランクのページはビジュアル数上限を決める（例：12個まで）
そして運用として、次をルール化します。
・新しいページや重要ビジュアルは、Performance Analyzerで計測してから公開する
・遅い上位3つを必ず記録し、改善ログを残す
・月次で更新時間とページ反応を棚卸しする
これをやると、性能が“個人の頑張り”から“チームの品質”になります。
────────────────────────────
10. まとめ：計測してから直すだけで、改善の成功率は上がる
────────────────────────────
レポート高速化は、勘ではなく計測が出発点です。Performance Analyzerを使うと、遅い原因を次のように整理できます。
・DAX queryが遅い → DAXとモデルを見直す
・Visual displayが遅い → 表現と描画量を見直す
・Otherが遅い → ページ構成と相互作用を見直す
そして、上位から順に、小さく改善して再計測する。これを回すだけで、体感速度は着実に上がります。結果として、利用者の信頼が戻り、Power BIが現場で使われ続ける土台になります。
────────────────────────────
レポートが遅いを根本から解消したい企業様へ
────────────────────────────
レポートの性能問題は、DAXだけ直しても改善しないことがあります。モデル設計、更新設計、ゲートウェイ、権限、ページ構成、相互作用、そして運用ルールまで、複数要因が絡むからです。逆に言えば、原因を整理して優先順位を付ければ、短期間でも大きく改善できる余地があるケースが少なくありません。
当社では、Performance Analyzerによる診断を起点に、遅いページ・遅いビジュアルの特定、DAX最適化、モデルの軽量化、ページ設計の見直し、更新安定化（ゲートウェイや資格情報運用の整理）まで、現場で回る形で支援しています。内製化したい企業様向けに、改善の型とチェックリストを含めた研修・伴走も可能です。
レポートが重くて定着しない、改善してもすぐ戻る、何から手を付けるべきか分からない、という状況なら、会社としてぜひお申し込み・ご相談ください。現状に合わせて最短で効く改善手順をご提案します。
もし困り事があるなら、まずは無料相談を
「DAX 関数が多すぎてどれを使えばいいか分からない」「複雑なロジックを組みたいけれど、エラーが出て解決できない」「会社全体で DAX を学習したい」など、Power BI やデータ活用でお悩みの方はぜひお気軽にご相談ください。
もし困り事があるなら、まずは無料相談はこちら
コンサルサービスの詳細や成功事例なども合わせてご紹介いたします。
社内にデータ活用のノウハウや専門人材が十分いない場合でも、弊社が伴走しながら最短ルートで成果を出せるようサポートいたします。
セミナーで学ぶ！DAX 関数の実践スキル
📊 Power BIでより効率的なレポート作成を！
Power BIハンズオンセミナー初級編では、短時間でデータモデリングのノウハウを学び、ビジネスに活かせるレポート作成を実践形式で習得できます。
少人数制のため、定員になり次第締切！
👉 セミナー詳細を今すぐチェック
📈 Power BIスキルを次のレベルへ！
DAX 関数 × データモデル設計 で、複雑なデータ分析やレポート作成もスムーズに！
Power BIハンズオンセミナー中級編 なら、実践形式で学べるから即戦力に。
業務効率をアップし、社内での評価を高めるチャンス！
今こそスキルアップのタイミング！
👉 詳細はこちら
DAX を使いこなすことで、Power BI の真価を最大限に引き出し、より高度な分析をスムーズに進められます。実践的な知識を身につけて、組織のデータドリブンな文化をリードしましょう。
コメント