Power BIが重い、動きが遅い場合にチェックすべきポイント、対応方法まとめ
目次
- 1. 対応①:データ量を最適化する
- 1.1 分析期間の制限と不要列の除外
- 1.2 データ取得前の前処理で軽量化する(例:Access、SQL)
- 2. 対応②:クエリ折りたたみを活用する
- 2.1 折りたたみが「無効」になるケース
- 2.2 折りたたみが有効か確認する方法
- 3. 対応③:ステップの並び順を最適化する
- 4. 対応④:インクメンタル更新を設定する
- 4.1 大量データを毎回全件読み込む必要はない
- 4.2 日次・月次更新を高速化できる仕組みとは?
- 5. 対応⑤:データモデルを見直す
- 5.1 テーブルの正規化と不要な関係の削除
- 5.2 複雑なDAXの多用や双方向フィルターを避ける
- 6. 対応⑥:Access連携による軽量化(補足)
- 6.1 Accessでの絞り込み処理とPower BI連携の活用例
- 7. 対応⑦:ビジュアルやレポート設計を見直す
- 7.1 複雑なグラフやカードの使いすぎに注意
- 7.2 表示ページ数やフィルター数も処理に影響
- 8. まとめ|目的とデータ量に応じた対応を選ぼう
- 8.1 長期的には設計の見直しも視野に入れる
- 9. どのようにPowerBIを軽くできるか
Power BIは、手軽にデータを可視化できる便利なツールですが、「動作が重い」「レポートの読み込みが遅い」といった悩みを抱える方も多いのではないでしょうか。
特に、データ量や複雑なDAX計算が増えてくると、パフォーマンス低下が顕著になります。
この記事では、Power BIが重くなる主な原因を整理し、対応策を7つの視点からご紹介します。
設計の段階から意識することで、より快適なレポート作成・運用が可能になります。
【よくある「重い」現象】
- レポートの表示に数十秒以上かかる
- ビジュアルがなかなか更新されない
- フィルターやスライサー操作がもたつく
- データ更新に時間がかかりすぎる
【分析データの肥大化が招くパフォーマンス低下】
データ件数が数十万〜数百万件を超えると、読み込みや計算処理が遅くなります。
不要な列や複雑な関係が含まれている場合、Power BI全体が「重い」状態になります。
対応①:データ量を最適化する
Power BIの動作が遅くなる原因の一つは、扱うデータ量が多すぎることです。
特に明細レベルのデータをそのまま取り込んでしまうと、パフォーマンスが大きく低下します。
この章では、行・列・分析期間を整理し、無駄なデータを減らすことでパフォーマンス改善を図る方法を紹介します。分析に不要な行や列が含まれていないか、まずは確認してみましょう。
たとえば以下のような方法で、不要な情報を削減できます。
- 行の絞り込み: 過去数年分のデータすべてではなく、「直近2年」「特定の部門のみ」などに限定する。
- 列の絞り込み: 使用していない列(ID、備考、空白の列など)を読み込み前に削除する。
これらの対応だけでも、Power BIファイルの容量が大きく変わる場合があります。
分析期間の制限と不要列の除外
分析で必要なのは「全データ」ではなく、「意味のある期間・項目」です。たとえば月次レポートなら、10年以上前のデータは不要かもしれません。また、列に関しても、たとえば「登録日時」と「更新日時」の両方がある場合、
どちらか一方しか使っていないならもう一方は除外できます。
データの取り込み段階で、意識的に「使う・使わない」を仕分けておくことが重要です。
データ取得前の前処理で軽量化する(例:Access、SQL)
データベースやAccessなどで事前に前処理を行っておくと、Power BIで扱うデータ量を大幅に減らせます。
例:
- SQLでWHERE句を使って対象期間を絞る
- 必要な列だけをSELECTする
- Accessでクエリを使って事前に集計・フィルタを実施する
対応②:クエリ折りたたみを活用する
Power Queryでの処理はできるだけ「早めに、簡潔に」
Power Queryエディター上での変換操作は、SQL文としてバックエンドに送信される「クエリ折りたたみ」が有効になります。ただし、クエリ折りたたみが無効になる操作(例:一部の変換関数や複雑なカスタム列)は、Power BI側で処理されるため、パフォーマンスが悪化します。
折りたたみが「無効」になるケース
Power Query の折りたたみ(Query Folding)は強力ですが、以下の操作を行うと自動的にオフになります。
これらの操作を後段に回すことで、パフォーマンスを最大化しましょう。
- インデックス列の追加
- カスタム列の作成で M 言語の高度な式を使用
- テーブルを分割した後の操作
- 行の並べ替えを複数ステップに分けた場合
- Merge/Append を行った直後のステップ
- 複雑な条件付き列
- データ型の変更を繰り返し行った場合
これらを行うと、Power BIは以降のステップをネイティブクエリに変換できず、自前のエンジンで処理するため重くなります。
→ 対策:折りたたみ可能なシンプル操作(フィルター、列選択、集計など)
を先に行い、複雑変換はその後に回す。
折りたたみが有効か確認する方法
「本当にネイティブクエリとしてサーバー側に押し戻されているか?」は、以下の手順でチェックできます。
- Power Queryエディターを開く
- 対象クエリのステップ一覧から折りたたみさせたいステップを右クリック
- コンテキストメニューの「ネイティブ クエリの表示」を選択
- SQL文が表示されれば、そのステップまで折りたたみが有効に動作中。
Tip: もし↑のように「ネイティブ クエリの表示」がグレーアウトして選択できない場合は、直前のステップで折りたたみが解除されています。上記の「無効化ケース」を参考に、シンプルなステップのみを先に適用しましょう。
表示されない場合は「ネイティブ クエリを表示できません」とメッセージが出ており、それ以降のステップで折りたたみが失われています。
Tip: もし「ネイティブ クエリの表示」がグレーアウトして選択できない場合は、直前のステップで折りたたみが解除されています。上記の「無効化ケース」を参考に、シンプルなステップのみを先に適用しましょう。
対応③:ステップの並び順を最適化する
Power Queryでは、データ取得から出力まで一連の「ステップ」として処理を記録します。これらのステップは上から順に実行されるため、重要なのは「データ量をいかに早い段階で絞り込むか」という点です。
不要なデータを下流のステップで処理すると、その分だけ余計な行・列にも計算が走り、パフォーマンスが悪化してしまいます。
フィルターや削除のステップは、↑のようにできるだけ早い段階(上流)に設定することで、後続の処理が軽くなります。
不要な処理が残っていないか、ステップの順番に無駄がないか確認しましょう。
このように「上流でできる限りデータを絞り、下流で複雑処理を行う」という順序設計を徹底することで、Power Query全体の実行時間を短縮でき、結果としてレポート表示や更新時のパフォーマンスも大きく改善されます。
ぜひ一度ご自身のクエリステップを見直し、最適な順序で処理を組み立ててみてください。
対応④:インクメンタル更新を設定する
大量データを毎回全件読み込む必要はない
すべてのデータを毎回フル更新していては、更新に時間がかかって当然です。
Power BIの「インクリメンタル更新」機能を使えば、新しいデータだけを追加・更新できるため、更新時間を短縮できます。
→機能詳細はコチラをチェック:Power BIのセマンティック モデルの増分更新 – Power BI | Microsoft Learn
日次・月次更新を高速化できる仕組みとは?
「過去○日分のみ再読み込み」などの設定が可能です。
例えば「最新60日間を毎日更新」とすれば、過去データは再読み込みせずに済み、効率的な運用が可能になります。
対応⑤:データモデルを見直す
テーブルの正規化と不要な関係の削除
必要以上に多くの関係(リレーション)が設定されていたり、データが非正規化されていたりすると、モデルが複雑化し、計算速度が遅くなります。
ファクトテーブルとディメンションテーブルの関係を整理し、必要最小限の構成に保ちましょう。
複雑なDAXの多用や双方向フィルターを避ける
ALL、FILTER、CALCULATEなどの複雑なDAX関数は、便利ですが処理コストが高い場合があります。
また、双方向フィルターは便利な一方で、パフォーマンスに悪影響を及ぼす可能性があるため、慎重に使いましょう。
対応⑥:Access連携による軽量化(補足)
Accessでの絞り込み処理とPower BI連携の活用例
AccessなどのローカルDBで事前に「分析期間」や「使用カラム」によるデータ抽出処理を行い、それをPower BIに接続して活用する方法です。
データ量を事前に抑えられるため、DirectQueryよりも高速かつ安定した動作が可能になります。
対応⑦:ビジュアルやレポート設計を見直す
複雑なグラフやカードの使いすぎに注意
同一ページ内にビジュアルが多すぎると、それぞれの計算が走るため処理負荷が高まります。
特にカード、マップ、カスタムビジュアルなどはパフォーマンスに影響を与えやすいです。
表示ページ数やフィルター数も処理に影響
ページの数が多すぎたり、フィルターの条件が複雑すぎたりすると、レンダリングやインタラクション時の処理負荷が増大します。設計段階でのスリム化を意識しましょう。
まとめ|目的とデータ量に応じた対応を選ぼう
重くなる要因 × 対応マトリクス表
長期的には設計の見直しも視野に入れる
一時的な改善ではなく、将来の拡張性・運用性を見据えて、データ取得からモデル設計、レポート構成までをトータルで見直すことが、パフォーマンス改善の近道です。
<Power BIハンズオンセミナー>
弊社ではPower BIをはじめとするさまざまな無料オンラインセミナーを実施しています!
>>セミナー一覧はこちら
<Power BIの導入支援>
弊社ではPower BIの導入支援を行っています。ぜひお気軽にお問い合わせください。
>>Power BIの導入支援の詳細はこちら
<PowerBIの入門書を発売中!>
弊社ではPower BIの導入から基本的な使い方・活用方法の基礎などをわかりやすく解説した書籍も販売しています。
>>目次も公開中!書籍の詳細はこちら
しかし、即時性を求めてPowerBIにOracleなどのデータベースデータを直接組み込んだ場合、データベースに保存されたトランザクションデータを全て取り込みます。
分析に必要な期間に関係なく、保存データ(ファイル)『保存された全ての行』を読み込んで取り込んでしまいます。
さらに、データベースの分析に必要ない項目『データ列(カラム)』まで取り込んでしまいます。
どのようにPowerBIを軽くできるか
データ数の削減のため、保存されたトランザクションデータの行・列の範囲の絞り込みをする方法をとることで、トランザクションデータの量を減らす処理を組み込むとデータが減り、処理が軽くなります。
- Accessに一度データベースのデータ(ファイル)をODBC接続で取り込み、分析期間・分析に必要なカラムを絞る処理を組み込んでデータを少なくする。
- 絞り込んだトランザクションデータを元に、PowerBIが取り込むデータはAccessで絞り込んだデータを取り込む。
これらの手法を使用して、データそのものを少なくする処理と即時性を両立させて分析用に使用していくと多少は軽いPowerBIでの分析方法となります。
また、分析に必要な部署のマスターデータも、データベースには正規化されて保存されているので、必要に応じて複合キーを結合した分析用のキーを作成する必要があります。
複合キーは必要に応じてドリルダウンなどの為に、作らざるを得ないと考えられます。
通常、データベースのトランザクションデータで行方向のデータ量を決めるのは取引日などの期間がメインとなります。
そこで、分析したい期間を決める必要が発生します。当年度だけで良いのか?昨年対比も分析したいのか?それ以前も見たいのか?
分析期間を決めることで、データ量の行方向の削減が行われます。
列データも同様に分析に必要な項目のみに絞り込むことになります。
評価期間・複合キー(分析用のキー)は取り込みにあたって必要になりますので、注意が必要です。
- 分析したい項目は金額ベースなのか?
- 製造数量ベースなのか?
- 不良発生率なのか?
- それ以外にも加工条件に基づく項目を分析対象としているのか?
など、評価項目になるものを絞り込んで作成する必要があります。
これらのデータ絞り込みを行・列データで行った上で、複合キーの結合(分析用のキーの作成)を行っていかないと、計算が増え、更に重くなります。
また、PowerBIでの部署マスター・calendarテーブルとの結合はデータを絞り込んだ後のものと結合させないと、やはりデータ処理が多くなり、重くなります。
<Power BIハンズオンセミナー>
弊社ではPower BIをはじめとするさまざまな無料オンラインセミナーを実施しています!
>>セミナー一覧はこちら
<Power BIの導入支援>
弊社ではPower BIの導入支援を行っています。ぜひお気軽にお問い合わせください。
>>Power BIの導入支援の詳細はこちら
<PowerBIの入門書を発売中!>
弊社ではPower BIの導入から基本的な使い方・活用方法の基礎などをわかりやすく解説した書籍も販売しています。
>>目次も公開中!書籍の詳細はこちら