⚡ STEP 45: Power BIパフォーマンス最適化
レポートを高速化して、快適なユーザー体験を実現しよう!
📋 このステップで学ぶこと
- パフォーマンス問題の診断
- DAXクエリ最適化
- メジャー効率化
- ビジュアル軽量化
- データモデル最適化
- パフォーマンスアナライザーの使用
ゴール:レポートの読み込み時間を50%以上削減し、快適なユーザー体験を実現する
⚡ 1. パフォーマンス問題の診断
パフォーマンス問題とは
レポートの読み込みが遅い、フィルター操作に時間がかかる…これらはユーザーの離脱につながります。適切な最適化で、サクサク動くレポートを作りましょう。
レポートの読み込みが遅い、フィルター操作に時間がかかる…これらはユーザーの離脱につながります。適切な最適化で、サクサク動くレポートを作りましょう!
| カテゴリ | 症状 | 考えられる原因 |
|---|---|---|
| レポート読み込み | 初回表示に10秒以上、ページ切り替えが遅い | データ量過多、ビジュアル数過多 |
| フィルター操作 | スライサーの反応が遅い、変更に5秒以上 | 非効率なDAXメジャー |
| ビジュアル表示 | グラフが徐々に描画、スクロールがカクカク | データポイント過多 |
| データ更新 | 更新に30分以上、タイムアウトエラー | データモデル未最適化 |
【診断ツールの活用】 Power BI Desktop: ステップ1: パフォーマンスアナライザーを開く ├─ 「表示」タブ ├─ 「パフォーマンスアナライザー」にチェック └─ 右側にパネルが表示される ステップ2: 記録開始 ├─ 「記録の開始」をクリック ├─ レポートページを操作 │ ├─ ページを開く │ ├─ フィルターを変更 │ ├─ スライサーを操作 │ └─ ドリルダウン └─ 「記録の停止」 ステップ3: 結果の確認 表示内容: ┌────────────────────────────────┐ │ ビジュアル名 時間(ms) │ ├────────────────────────────────┤ │ 売上推移 1,245ms │ │ - DAXクエリ: 1,100ms │ │ - その他: 145ms │ │ │ │ 商品別売上 450ms │ │ - DAXクエリ: 380ms │ │ - その他: 70ms │ │ │ │ 顧客マトリックス 2,800ms ⚠️ │ │ - DAXクエリ: 2,650ms ⚠️ │ │ - その他: 150ms │ └────────────────────────────────┘ 分析ポイント: ✓ 合計時間が長いビジュアル ✓ DAXクエリ時間の割合 ✓ ビジュアル更新の時間 ✓ ボトルネックの特定 ステップ4: DAXクエリをコピー ├─ 遅いビジュアルを展開 ├─ 「クエリのコピー」 ├─ DAX Studioで分析(後述) └─ 最適化の実施
| 項目 | 目標 | 許容範囲 | 判定 |
|---|---|---|---|
| 初回読み込み | 3秒以内 | 5秒以内 | ✓ / ⚠️ / ❌ |
| ページ切り替え | 1秒以内 | 2秒以内 | ✓ / ⚠️ / ❌ |
| フィルター操作 | 1秒以内 | 3秒以内 | ✓ / ⚠️ / ❌ |
| ビジュアル更新 | 500ms以内 | 1秒以内 | ✓ / ⚠️ / ❌ |
| データ更新 | 5分以内 | 15分以内 | ✓ / ⚠️ / ❌ |
📊 2. DAXクエリ最適化
非効率なDAXパターン
DAXメジャーの書き方によって、パフォーマンスは大きく変わります。よくある非効率なパターンと、その改善方法を学びましょう。
| パターン | 問題点 | 改善策 |
|---|---|---|
| 行コンテキストの計算列 | すべての行で計算される、ファイルサイズ増加 | メジャーを使用(必要な時だけ計算) |
| FILTER内でALL使用 | テーブル全体をスキャン、非常に遅い | CALCULATEで直接フィルター |
| ネストしたCALCULATE | 読みにくく遅い | 1つのCALCULATEにまとめる |
| 不要なイテレーター | SUMXなど単純集計に不要 | SUM、AVERAGEなど直接集計関数 |
| IF文での除算 | 冗長で遅い | DIVIDE関数を使用 |
【改善例1: イテレーターの最適化】
❌ 非効率(SUMX使用):
売上合計 =
SUMX(
売上,
売上[数量] * 売上[単価]
)
→ 各行をイテレートして遅い
✅ 効率的(SUM使用):
// 金額列がある場合
売上合計 = SUM(売上[金額])
// または、計算列で金額を事前計算
売上[金額] = 売上[数量] * 売上[単価]
売上合計 = SUM(売上[金額])
─────────────────────────────
【改善例2: FILTER vs CALCULATE】
❌ 非効率:
売上合計(全期間) =
CALCULATE(
SUM(売上[金額]),
FILTER(
ALL(日付),
日付[年] >= 2020
)
)
→ テーブル全体をスキャン
✅ 効率的:
売上合計(全期間) =
CALCULATE(
SUM(売上[金額]),
日付[年] >= 2020,
ALL(日付)
)
→ 内部最適化が効く
─────────────────────────────
【改善例3: IF vs DIVIDE】
❌ 非効率:
成長率 =
IF(
[去年売上] <> 0,
([今年売上] / [去年売上]) - 1,
0
)
✅ 効率的:
成長率 =
DIVIDE([今年売上], [去年売上], 0) - 1
→ ゼロ除算を自動処理、高速
【ベストプラクティス】
✅ パターン1: 変数の活用
前年同期比 =
VAR 今期売上 = SUM(売上[金額])
VAR 前年売上 =
CALCULATE(
SUM(売上[金額]),
SAMEPERIODLASTYEAR(日付[日付])
)
VAR 比率 = DIVIDE(今期売上 - 前年売上, 前年売上)
RETURN
比率
メリット:
├─ 計算を再利用(重複計算なし)
├─ 読みやすい
└─ パフォーマンス向上
─────────────────────────────
✅ パターン2: テーブル変数
売上トップ10 =
VAR TopProducts =
TOPN(
10,
VALUES(商品[商品名]),
[売上合計],
DESC
)
RETURN
CALCULATE(
[売上合計],
TopProducts
)
メリット: 中間結果を保存して再利用
─────────────────────────────
✅ パターン3: KEEPFILTERS使用
特定地域売上 =
CALCULATE(
SUM(売上[金額]),
KEEPFILTERS(地域[地域名] = "東京")
)
メリット: 既存フィルターを尊重
| チェック項目 | 推奨 | 避けるべき |
|---|---|---|
| 計算列 vs メジャー | 集計結果 → メジャー使用 | 複雑な計算列 |
| 変数の活用 | 複数回使う計算は変数化 | 同じ計算の繰り返し |
| 集計関数 | SUM、AVERAGE優先 | 不要なSUMX、AVERAGEX |
| 除算処理 | DIVIDE関数使用 | IF文での除算 |
| フィルター | CALCULATE内で直接フィルター | FILTERのネスト |
| メジャーの再利用 | 基本メジャーを組み合わせ | コピペ多用 |
🎨 3. ビジュアル最適化
ビジュアル数の削減
ビジュアルが多すぎると、それぞれがDAXクエリを実行するため、レポート全体が遅くなります。適切な数に抑え、必要な情報を効率的に表示しましょう。
| ページタイプ | 推奨数 | 理由 |
|---|---|---|
| 概要ページ | 4〜6個 | KPIと主要グラフに絞る |
| 詳細ページ | 6〜10個 | 詳細分析に必要な情報 |
| 最大 | 15個まで | これ以上はパフォーマンス悪化 |
| 避けるべき | 20個以上 | 読み込みが非常に遅くなる |
【ビジュアル数を減らす方法】 1. ページ分割 ├─ サマリーページ(概要) ├─ 詳細ページ1(売上分析) ├─ 詳細ページ2(顧客分析) └─ ドリルスルーページ(個別詳細) 2. ブックマーク活用 ├─ ボタンで表示切替 ├─ 必要なビジュアルのみ表示 ├─ 初期は一部のみ表示 └─ 例: 「詳細を見る」ボタン 3. ツールヒントページ ├─ 詳細はツールヒントページで表示 ├─ メインページは簡潔に └─ マウスオーバーでオンデマンド表示 4. ドリルスルー ├─ サマリー → 詳細 ├─ 別ページで詳細表示 ├─ 右クリックで遷移 └─ 必要な時のみ読み込み 効果: ページ読み込み 20-30% 高速化
| 速度 | ビジュアルタイプ | 備考 |
|---|---|---|
| 🟢 高速 | カード、テーブル、棒グラフ、折れ線グラフ | シンプルな描画、推奨 |
| 🟡 中速 | 散布図、面グラフ、複合グラフ、ゲージ | 適度に使用 |
| 🔴 低速 | マップ(大量データ)、リボンチャート、複雑なカスタムビジュアル、R/Pythonビジュアル | データ点を絞るか代替手段 |
【データポイントを減らす方法】 問題: 1つのビジュアルに大量データ ❌ 1年分の日次データ(365点)をすべて表示 ❌ 全商品(5,000件)をリストに表示 ❌ 全顧客(10万件)を散布図に表示 解決策: 1. Top N フィルター 売上トップ20商品のみ表示: ├─ フィルター: Top N ├─ 値: 売上 ├─ 表示: 20 └─ 他は「その他」にまとめる 2. 集約 日次 → 週次 → 月次: ├─ 長期トレンド: 月次で十分 ├─ 最近1ヶ月: 日次 └─ ドリルダウンで詳細 3. サンプリング 10万顧客 → 1万顧客: ├─ ランダムサンプル ├─ 代表的な顧客 └─ 統計的に有意 4. データポイント上限 Power BI設定: ├─ 散布図: 最大3,500点 ├─ カラムチャート: 最大1,000カテゴリ ├─ テーブル: ページング推奨 └─ 警告が出たら対策必須 効果: 該当ビジュアル 60-80% 高速化
| ビジュアルタイプ | 推奨インタラクション設定 | 理由 |
|---|---|---|
| KPIカード | インタラクションなし | 総計は常に表示 |
| 会社ロゴ | インタラクションなし | 装飾要素 |
| 年選択スライサー | すべてに影響(フィルター) | グローバルフィルター |
| 詳細ビジュアル | 限定的インタラクション | 関連ビジュアルのみ |
設定方法:ビジュアル選択 →「書式」タブ →「インタラクションの編集」
🗄️ 4. データモデル最適化
データ型の最適化
データモデルの最適化は、パフォーマンス改善で最も効果が大きい領域です。適切なデータ型、不要な列の削除、効率的なリレーションシップ設計を行いましょう。
| カテゴリ | データ型 | サイズ | 推奨 |
|---|---|---|---|
| 整数 | 整数(Int64) | 8バイト | |
| 整数 | 整数(Int32) | 4バイト | ✓ 推奨 |
| 小数 | 浮動小数点数 | 8バイト | ✓ 推奨 |
| 日付 | 日付/時刻 | 8バイト | |
| 日付 | 日付のみ | 少ない | ✓ 推奨 |
| テキスト | テキスト | 可変(大) | 注意 |
| 列名 | Before | After | 効果 |
|---|---|---|---|
| 商品ID | テキスト型 | 整数型 | 大幅削減 |
| 年月 | テキスト(“2025年1月”) | 日付型(2025/01/01) | 計算可能に |
| フラグ | テキスト(“はい”/”いいえ”) | True/False型 | 大幅削減 |
| カテゴリ | テキスト(重複多数) | ディメンションテーブルに分離 | 正規化 |
【削除すべき列】 1. 使用していない列 ├─ レポートで参照されていない ├─ 計算で使われていない └─ リレーションシップに不要 2. 中間計算列 ├─ Power Queryで使用後不要 └─ 最終結果のみ残す 3. 重複列 ├─ 同じ情報の別表現 └─ 正規化で解決 4. 詳細すぎる列 ├─ タイムスタンプ → 日付で十分 ├─ 住所詳細 → 都道府県で十分 └─ 集約レベルを上げる 削除手順: Power Query Editor: ├─ 列を右クリック ├─ 「削除」 └─ 「閉じて適用」 または: モデルビュー: ├─ 列を右クリック ├─ 「列を非表示」(削除より安全) └─ レポートから見えなくなる メリット: ✓ ファイルサイズ削減 ✓ 更新時間短縮 ✓ メモリ使用量削減
【効率的なモデル設計】
1. スタースキーマ(推奨)
ファクトテーブル(中央):
└─ 売上トランザクション(多)
ディメンションテーブル(周囲):
├─ 商品マスター(少)
├─ 顧客マスター(少)
├─ 日付マスター(少)
└─ 店舗マスター(少)
リレーションシップ:
売上 → 商品(多対一)
売上 → 顧客(多対一)
売上 → 日付(多対一)
売上 → 店舗(多対一)
2. 多対多を避ける
❌ 多対多リレーションシップ
→ ✅ ブリッジテーブルで分解
例:
学生 ←→ 授業(多対多)
↓
学生 → 履修(多対一)
履修 → 授業(多対一)
3. 双方向フィルターの制限
原則: 単方向(ディメンション → ファクト)
例外: 限定的に双方向使用
4. 非アクティブリレーションシップ
複数の日付列がある場合:
売上[注文日] → 日付(アクティブ)
売上[出荷日] → 日付(非アクティブ)
売上[配達日] → 日付(非アクティブ)
メジャーで使い分け:
出荷ベース売上 =
CALCULATE(
SUM(売上[金額]),
USERELATIONSHIP(売上[出荷日], 日付[日付])
)
🔧 5. Power Queryの最適化
クエリフォールディング
Power Queryの操作をデータベース側で実行することで、大幅な高速化が可能です。すべてのデータを取得してからフィルターするのではなく、必要なデータだけを取得しましょう。
Power Queryの操作をデータベース側で実行することで、大幅な高速化が可能です。すべてのデータを取得してからフィルターするのではなく、必要なデータだけを取得しましょう!
| 対応 | 操作 | 備考 |
|---|---|---|
| ✓ 可能 | フィルター、列の選択、列の名前変更、並べ替え、グループ化、結合、追加 | データベース側で処理(高速) |
| ❌ 不可 | カスタム列追加(複雑な計算)、列の分割、ピボット/ピボット解除、カスタムM関数 | ローカルで処理(遅い) |
確認方法:ステップを右クリック →「ネイティブクエリの表示」(表示される = フォールディングOK)
【ベストプラクティス】
1. フィルターを早い段階で適用
✅ 良い順序:
データソース接続
→ フィルター(2020年以降) ← 早い!
→ 列選択
→ 型変更
→ カスタム列
❌ 悪い順序:
データソース接続
→ カスタム列 ← フォールディング中断
→ フィルター ← 遅い
→ 列選択
2. データベースビューの活用
✅ データベース側で:
├─ 複雑な結合
├─ 集約
└─ 計算
Power Query側で:
├─ ビューに接続
└─ 簡単な変換のみ
3. ネイティブクエリの使用
SQL:
= Sql.Database(
"サーバー名",
"DB名",
[Query="
SELECT
商品ID,
商品名,
SUM(売上金額) AS 売上
FROM 売上
WHERE 年 >= 2020
GROUP BY 商品ID, 商品名
"]
)
→ データベースで集約してから取得(高速)
| 問題 | 改善策 | 効果 |
|---|---|---|
| 複数の「削除された列」ステップ | 1つにまとめる | ステップ数削減 |
| 「変更された型」が複数回 | 最後の1回のみ | 重複排除 |
| 複数の「フィルター」ステップ | 統合可能なら統合 | 処理効率化 |
| 使わないステップが残っている | 削除 | クリーンアップ |
📈 6. 総合的な最適化戦略
最適化の優先順位
限られた時間で最大の効果を得るために、効果の大きい領域から着手しましょう。
| 優先度 | 領域 | 主な施策 | 効果 | 難易度 |
|---|---|---|---|---|
| 1(最高) | データモデル | 不要列削除、データ型最適化、リレーションシップ整理、集約テーブル | 大 | 中 |
| 2(高) | DAXメジャー | 非効率メジャー修正、計算列→メジャー、変数活用、イテレーター最適化 | 大 | 高 |
| 3(中) | ビジュアル | ビジュアル数削減、データポイント削減、インタラクション無効化 | 中 | 低 |
| 4(中) | Power Query | クエリフォールディング確認、ステップ整理、早期フィルター | 中 | 中 |
| 5(低) | その他 | ページ分割、ブックマーク活用、テーマ最適化 | 小 | 低 |
| 頻度 | チェック内容 |
|---|---|
| 週次 | パフォーマンスアナライザー実行、遅いビジュアル特定、明らかなボトルネック修正 |
| 月次 | データモデルサイズ確認、未使用列の削除、メジャーの見直し、クエリフォールディング確認 |
| 四半期 | 全体的なパフォーマンス測定、ユーザーフィードバック収集、アーカイブデータの分離、大規模リファクタリング検討 |
| 年次 | データモデル全面見直し、Premium移行検討、新機能の活用、ベストプラクティス適用 |
【Before/After比較テンプレート】 測定項目: 1. 読み込み時間 Before: __秒 After: __秒 改善: __%削減 2. フィルター応答 Before: __秒 After: __秒 改善: __%削減 3. ファイルサイズ Before: __MB After: __MB 改善: __%削減 4. 更新時間 Before: __分 After: __分 改善: __%削減 5. ユーザー満足度 Before: __/5 After: __/5 改善: 向上 / 変化なし 記録方法: ├─ Excelに測定結果を記録 ├─ パフォーマンスダッシュボード作成 ├─ 定期的にレポート └─ 継続的改善
📝 STEP 45 のまとめ
- 診断:パフォーマンスアナライザーで問題特定
- DAX最適化:効率的なメジャー設計(変数活用、DIVIDE使用)
- ビジュアル:適切な数と種類の選択、インタラクション最適化
- データモデル:型とリレーションシップの最適化、不要列削除
- Power Query:クエリフォールディング、早期フィルター
- 継続改善:定期的なメンテナンスと測定
| カテゴリ | チェック項目 |
|---|---|
| データモデル | □ 不要な列を削除 □ データ型を最適化 □ スタースキーマ設計 □ 多対多を解消 |
| DAX | □ 変数を活用 □ SUMXよりSUM □ DIVIDEを使用 □ 計算列をメジャーに |
| ビジュアル | □ 15個以下/ページ □ Top Nフィルター □ 不要なインタラクション無効 □ 高速なビジュアル選択 |
| Power Query | □ フォールディング確認 □ 早期フィルター □ ステップ統合 □ 不要ステップ削除 |
パフォーマンスは「機能」ではなく「品質」です!どんなに素晴らしい分析も、遅くて使えなければ意味がありません。最も効果が大きいのはデータモデルの最適化。不要な列の削除、適切なデータ型、効率的なリレーションシップから始めましょう。そして継続的な測定と改善を忘れずに!
📝 実践演習
既存のレポートでパフォーマンスアナライザーを実行し、最も時間がかかっているビジュアルを特定してください。DAXクエリ時間が1秒以上かかっているビジュアルをリストアップしてください。
ステップ1: パフォーマンスアナライザー起動
- Power BI Desktopでレポートを開く
- 「表示」タブをクリック
- 「パフォーマンスアナライザー」にチェック
- 右側にパネルが表示される
ステップ2: 記録開始
- パフォーマンスアナライザーパネルで「記録の開始」をクリック
- レポートの操作を実施:
- ページを開く(初回読み込み)
- スライサーを変更
- フィルターを適用
- ドリルダウン操作
- すべての操作が完了したら「停止」をクリック
ステップ3: 結果の分析
- 各ビジュアルの合計時間を確認
- ビジュアル名の横の▶をクリックして展開
- 内訳を確認:
- DAXクエリ: データ取得時間
- ビジュアル表示: 描画時間
- その他: その他の処理時間
ステップ4: 問題ビジュアルのリストアップ
Excelシートを作成:
| ビジュアル名 | 合計時間(ms) | DAXクエリ(ms) | 判定 |
|---|---|---|---|
| 売上推移グラフ | 450 | 380 | OK |
| 商品別売上 | 1,250 | 1,180 | ⚠️要改善 |
| 顧客マトリックス | 2,800 | 2,650 | ❌最優先 |
ステップ5: DAXクエリの確認
- 最も遅いビジュアル(顧客マトリックス)を展開
- 「DAXクエリのコピー」をクリック
- メモ帳等に貼り付けて保存
- クエリの内容を確認(複雑なCALCULATE?イテレーター関数?)
ポイント:
- ✓ 定期的に測定(週次推奨)
- ✓ 記録を保存して比較
- ✓ DAXクエリ時間が大半 → メジャー最適化
- ✓ ビジュアル表示時間が長い → データ点削減
非効率なDAXメジャーを最適化してください。イテレーター関数(SUMX, AVERAGEXなど)を使っているメジャーを見つけ、可能であれば直接集計関数(SUM, AVERAGEなど)に書き換えてください。書き換え前後でパフォーマンスを比較してください。
ステップ1: 現在のメジャーを確認
非効率な例を見つける:
メジャー1: 売上合計(非効率)
売上合計 =
SUMX(
売上,
売上[数量] * 売上[単価]
)
→ 問題: SUMXは各行をイテレート(遅い)
メジャー2: 平均単価(非効率)
平均単価 =
AVERAGEX(
売上,
売上[単価]
)
→ 問題: AVERAGEXは不要なイテレーション
メジャー3: 前年比(非効率)
前年比 =
IF(
[去年売上] <> 0,
([今年売上] / [去年売上]) - 1,
BLANK()
)
→ 問題: IF文での除算(DIVIDEのほうが効率的)
ステップ2: Before測定
- これらのメジャーを使ったビジュアル作成
- パフォーマンスアナライザーで測定
- 結果を記録
ステップ3: メジャー最適化
最適化1: 売上合計
// ✅ After(計算列がある場合) 売上合計 = SUM(売上[金額]) // または、計算列を追加 売上[金額] = 売上[数量] * 売上[単価] 売上合計 = SUM(売上[金額])
最適化2: 平均単価
// ✅ After 平均単価 = AVERAGE(売上[単価])
最適化3: 前年比
// ✅ After
前年比 =
VAR 今年 = [今年売上]
VAR 去年 = [去年売上]
RETURN
DIVIDE(今年 - 去年, 去年)
ステップ4: After測定と比較
| メジャー | Before | After | 改善率 |
|---|---|---|---|
| 売上合計 | 850ms | 180ms | 79%削減 |
| 平均単価 | 420ms | 85ms | 80%削減 |
| 前年比 | 680ms | 450ms | 34%削減 |
ポイント:
- ✓ イテレーター(SUMX, AVERAGEX)は必要最小限に
- ✓ 直接集計関数(SUM, AVERAGE)を優先
- ✓ DIVIDE関数を活用
- ✓ 変数で重複計算を削減
- ✓ 測定して改善を確認
大規模レポート(10ページ以上、30ビジュアル以上)を総合的に最適化してください。データモデル、DAX、ビジュアル、Power Queryすべての観点から改善し、初回読み込み時間を50%以上削減してください。最適化の過程と結果をドキュメント化してください。
フェーズ1: 現状分析
【最適化前の状態】 基本情報: - ページ数: 15ページ - ビジュアル総数: 45個 - ファイルサイズ: 850MB - データ行数: 500万行 パフォーマンス: - 初回読み込み: 25秒 - ページ切り替え: 8秒 - フィルター操作: 6秒 - データ更新: 45分 目標: - 初回読み込み: 12秒以下(50%削減) - ページ切り替え: 3秒以下 - フィルター操作: 2秒以下 - データ更新: 20分以下
フェーズ2: データモデル最適化
- 不要な列の削除:
- 売上テーブル: タイムスタンプ、詳細住所、備考欄、システムID、作成者・更新者(15列削除)
- 商品テーブル: 商品説明、仕入先詳細(5列削除)
- 結果: 850MB → 520MB(39%削減)
- データ型最適化:
- 商品ID: テキスト → 整数
- 店舗コード: テキスト → 整数
- 年月: テキスト → 日付
- フラグ類: テキスト → True/False
- 結果: 520MB → 380MB(27%追加削減)
- リレーションシップ整理:
- 多対多リレーションシップ2個をブリッジテーブルで再設計
- 双方向フィルター3個を単方向に変更
- 結果: クエリ実行時間10-15%改善
フェーズ3: DAX最適化
- 計算列をメジャーに変更: 8個
- 非効率メジャーの書き換え: 15個
- SUMX → SUM
- IF除算 → DIVIDE
- 変数の活用
- 結果: 各メジャー40-60%高速化
フェーズ4: ビジュアル最適化
- ビジュアル数削減: 45個 → 32個
- 類似ビジュアルを統合
- ブックマークで切り替え
- ドリルスルーページ活用
- データポイント削減:
- 全商品リスト(5,000件)→ Top 100
- 1年分の日次 → 週次集約
- インタラクション無効化:
- KPIカード8個
- ロゴ、タイトル
フェーズ5: Power Query最適化
- クエリフォールディング改善: 4クエリを修正
- ステップ整理: 平均15ステップ → 8ステップ
- 結果: データ更新28分 → 18分
フェーズ6: 最終測定
| 項目 | Before | After | 改善率 |
|---|---|---|---|
| 初回読み込み | 25秒 | 10秒 | 60%削減 ✓ |
| ページ切り替え | 8秒 | 2秒 | 75%削減 ✓ |
| フィルター操作 | 6秒 | 1.5秒 | 75%削減 ✓ |
| データ更新 | 45分 | 18分 | 60%削減 ✓ |
| ファイルサイズ | 850MB | 320MB | 62%削減 ✓ |
成功のポイント:
- ✓ 体系的なアプローチ(すべての層を最適化)
- ✓ 測定に基づく改善(感覚ではなくデータ)
- ✓ 優先順位付け(効果の大きいものから)
- ✓ ドキュメント化(ナレッジの蓄積)
- ✓ 継続的改善(一度で終わらない)
❓ よくある質問
原因:
– 1回目: データ取得とキャッシュ構築(遅い)
– 2回目以降: キャッシュから取得(速い)
– フィルター変更: 新しいクエリ(遅い)
正確な測定方法:
1. Power BI Desktopを再起動
2. ファイルを開く
3. 初回の操作を測定(キャッシュなし状態)
4. これを「実際のユーザー体験」として記録
または:
– 毎回「記録のクリア」してから測定
– 複数回測定して平均を取る
– 同じ条件で測定する(比較のため)
原因1: 計算列をメジャーに変更
– 計算列: 事前計算(ファイル大、更新遅、表示速)
– メジャー: 都度計算(ファイル小、更新速、表示遅)
– 対策: 使用頻度に応じて使い分け
原因2: 複雑な最適化
– 過度に複雑なDAXは逆効果
– シンプルが最速のこともある
– 対策: A/Bテストで比較
原因3: 環境の違い
– Desktop vs Service
– ローカル vs ゲートウェイ
– 対策: 本番環境で測定
Premium移行を検討すべき状況:
✓ ユーザー数: 100人以上
✓ データ量: 1GB以上
✓ 更新頻度: 1日8回以上必要
✓ パフォーマンス要件: 厳しい
✓ 増分更新が必要
Premiumのメリット:
– 更新回数: 48回/日(Pro: 8回/日)
– データ容量: 大幅増
– 増分更新: 可能
– 自動集約: 可能
– パフォーマンス: 向上
判断基準: まずProで最適化 → 限界ならPremium検討
Import(インポート):
✓ 高速(メモリ内で処理)
✓ オフライン可能
✓ すべてのDAX機能使用可
✗ データが古くなる
✗ サイズ制限あり
DirectQuery:
✓ 常に最新データ
✓ 大容量データ対応
✗ 遅い(DB性能依存)
✗ 一部DAX機能制限
推奨:
– バッチ処理: Import
– リアルタイム: DirectQuery
– 大規模: 複合モデル(両方)
モバイル固有の対策:
1. モバイルレイアウト作成
– 「表示」→「モバイルレイアウト」
– 必要最小限のビジュアル配置
– 3-5個に絞る
2. データ量削減
– モバイルはTop 10のみ表示
– デスクトップはTop 100
3. シンプルなビジュアル
– カード、棒グラフ中心
– 複雑なカスタムビジュアル避ける
4. テスト
– 実機でテスト必須
– 3G/4G環境でも確認
方法1: Power Queryで手動作成
1. Power Query Editorを開く
2. 元テーブルを参照
3. 「グループ化」で集約
4. 例: 日次 → 月次集約
方法2: Premium自動集約
1. Premium機能を有効化
2. モデルで集約を設定
3. 自動的に最適なテーブルを選択
使い分け:
– 長期トレンド: 月次集約テーブル(高速)
– 直近詳細: 元テーブル(必要時のみ)
主な機能:
– DAXクエリの実行と結果確認
– クエリプランの表示
– パフォーマンス詳細分析
– メモリ使用量の確認
インストール:
1. https://daxstudio.org/ からダウンロード
2. インストール実行
3. Power BI Desktopと連携
使い方:
1. パフォーマンスアナライザーでDAXクエリをコピー
2. DAX Studioに貼り付け
3. 実行して詳細分析
4. ボトルネックを特定
上級者向けツールですが、深い分析に有用です。
学習メモ
BIツール入門 - Step 45