STEP 45:Power BIパフォーマンス最適化

⚡ 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メジャーの書き方によって、パフォーマンスは大きく変わります。よくある非効率なパターンと、その改善方法を学びましょう。

❌ 避けるべき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
→ ゼロ除算を自動処理、高速
✅ 効率的なDAXパターン
【ベストプラクティス】

✅ パターン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(地域[地域名] = "東京")
)

メリット: 既存フィルターを尊重
💡 DAXメジャー最適化チェックリスト
チェック項目 推奨 避けるべき
計算列 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 □ フォールディング確認 □ 早期フィルター □ ステップ統合 □ 不要ステップ削除
🎯 最重要ポイント

パフォーマンスは「機能」ではなく「品質」です!どんなに素晴らしい分析も、遅くて使えなければ意味がありません。最も効果が大きいのはデータモデルの最適化。不要な列の削除、適切なデータ型、効率的なリレーションシップから始めましょう。そして継続的な測定と改善を忘れずに!

📝 実践演習

演習 1 基礎

既存のレポートでパフォーマンスアナライザーを実行し、最も時間がかかっているビジュアルを特定してください。DAXクエリ時間が1秒以上かかっているビジュアルをリストアップしてください。

【パフォーマンス診断の実践】

ステップ1: パフォーマンスアナライザー起動

  1. Power BI Desktopでレポートを開く
  2. 「表示」タブをクリック
  3. 「パフォーマンスアナライザー」にチェック
  4. 右側にパネルが表示される

ステップ2: 記録開始

  1. パフォーマンスアナライザーパネルで「記録の開始」をクリック
  2. レポートの操作を実施:
    • ページを開く(初回読み込み)
    • スライサーを変更
    • フィルターを適用
    • ドリルダウン操作
  3. すべての操作が完了したら「停止」をクリック

ステップ3: 結果の分析

  1. 各ビジュアルの合計時間を確認
  2. ビジュアル名の横の▶をクリックして展開
  3. 内訳を確認:
    • DAXクエリ: データ取得時間
    • ビジュアル表示: 描画時間
    • その他: その他の処理時間

ステップ4: 問題ビジュアルのリストアップ

Excelシートを作成:

ビジュアル名 合計時間(ms) DAXクエリ(ms) 判定
売上推移グラフ 450 380 OK
商品別売上 1,250 1,180 ⚠️要改善
顧客マトリックス 2,800 2,650 ❌最優先

ステップ5: DAXクエリの確認

  1. 最も遅いビジュアル(顧客マトリックス)を展開
  2. 「DAXクエリのコピー」をクリック
  3. メモ帳等に貼り付けて保存
  4. クエリの内容を確認(複雑なCALCULATE?イテレーター関数?)

ポイント:

  • ✓ 定期的に測定(週次推奨)
  • ✓ 記録を保存して比較
  • ✓ DAXクエリ時間が大半 → メジャー最適化
  • ✓ ビジュアル表示時間が長い → データ点削減
演習 2 応用

非効率なDAXメジャーを最適化してください。イテレーター関数(SUMX, AVERAGEXなど)を使っているメジャーを見つけ、可能であれば直接集計関数(SUM, AVERAGEなど)に書き換えてください。書き換え前後でパフォーマンスを比較してください。

【DAXメジャー最適化の実践】

ステップ1: 現在のメジャーを確認

非効率な例を見つける:

メジャー1: 売上合計(非効率)

売上合計 = 
SUMX(
    売上,
    売上[数量] * 売上[単価]
)
→ 問題: SUMXは各行をイテレート(遅い)

メジャー2: 平均単価(非効率)

平均単価 = 
AVERAGEX(
    売上,
    売上[単価]
)
→ 問題: AVERAGEXは不要なイテレーション

メジャー3: 前年比(非効率)

前年比 = 
IF(
    [去年売上] <> 0,
    ([今年売上] / [去年売上]) - 1,
    BLANK()
)
→ 問題: IF文での除算(DIVIDEのほうが効率的)

ステップ2: Before測定

  1. これらのメジャーを使ったビジュアル作成
  2. パフォーマンスアナライザーで測定
  3. 結果を記録

ステップ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: データモデル最適化

  1. 不要な列の削除:
    • 売上テーブル: タイムスタンプ、詳細住所、備考欄、システムID、作成者・更新者(15列削除)
    • 商品テーブル: 商品説明、仕入先詳細(5列削除)
    • 結果: 850MB → 520MB(39%削減)
  2. データ型最適化:
    • 商品ID: テキスト → 整数
    • 店舗コード: テキスト → 整数
    • 年月: テキスト → 日付
    • フラグ類: テキスト → True/False
    • 結果: 520MB → 380MB(27%追加削減)
  3. リレーションシップ整理:
    • 多対多リレーションシップ2個をブリッジテーブルで再設計
    • 双方向フィルター3個を単方向に変更
    • 結果: クエリ実行時間10-15%改善

フェーズ3: DAX最適化

  1. 計算列をメジャーに変更: 8個
  2. 非効率メジャーの書き換え: 15個
    • SUMX → SUM
    • IF除算 → DIVIDE
    • 変数の活用
  3. 結果: 各メジャー40-60%高速化

フェーズ4: ビジュアル最適化

  1. ビジュアル数削減: 45個 → 32個
    • 類似ビジュアルを統合
    • ブックマークで切り替え
    • ドリルスルーページ活用
  2. データポイント削減:
    • 全商品リスト(5,000件)→ Top 100
    • 1年分の日次 → 週次集約
  3. インタラクション無効化:
    • KPIカード8個
    • ロゴ、タイトル

フェーズ5: Power Query最適化

  1. クエリフォールディング改善: 4クエリを修正
  2. ステップ整理: 平均15ステップ → 8ステップ
  3. 結果: データ更新28分 → 18分

フェーズ6: 最終測定

項目 Before After 改善率
初回読み込み 25秒 10秒 60%削減 ✓
ページ切り替え 8秒 2秒 75%削減 ✓
フィルター操作 6秒 1.5秒 75%削減 ✓
データ更新 45分 18分 60%削減 ✓
ファイルサイズ 850MB 320MB 62%削減 ✓

成功のポイント:

  • ✓ 体系的なアプローチ(すべての層を最適化)
  • ✓ 測定に基づく改善(感覚ではなくデータ)
  • ✓ 優先順位付け(効果の大きいものから)
  • ✓ ドキュメント化(ナレッジの蓄積)
  • ✓ 継続的改善(一度で終わらない)

❓ よくある質問

Q1: パフォーマンスアナライザーの結果が毎回違います。なぜですか?
キャッシュの影響です。

原因:
– 1回目: データ取得とキャッシュ構築(遅い)
– 2回目以降: キャッシュから取得(速い)
– フィルター変更: 新しいクエリ(遅い)

正確な測定方法:
1. Power BI Desktopを再起動
2. ファイルを開く
3. 初回の操作を測定(キャッシュなし状態)
4. これを「実際のユーザー体験」として記録

または:
– 毎回「記録のクリア」してから測定
– 複数回測定して平均を取る
– 同じ条件で測定する(比較のため)
Q2: 最適化したのに遅くなりました。原因は?
いくつかの原因が考えられます。

原因1: 計算列をメジャーに変更
– 計算列: 事前計算(ファイル大、更新遅、表示速)
– メジャー: 都度計算(ファイル小、更新速、表示遅)
– 対策: 使用頻度に応じて使い分け

原因2: 複雑な最適化
– 過度に複雑なDAXは逆効果
– シンプルが最速のこともある
– 対策: A/Bテストで比較

原因3: 環境の違い
– Desktop vs Service
– ローカル vs ゲートウェイ
– 対策: 本番環境で測定
Q3: Premiumに移行すべきでしょうか?
以下の条件に当てはまれば検討価値あり:

Premium移行を検討すべき状況:
✓ ユーザー数: 100人以上
✓ データ量: 1GB以上
✓ 更新頻度: 1日8回以上必要
✓ パフォーマンス要件: 厳しい
✓ 増分更新が必要

Premiumのメリット:
– 更新回数: 48回/日(Pro: 8回/日)
– データ容量: 大幅増
– 増分更新: 可能
– 自動集約: 可能
– パフォーマンス: 向上

判断基準: まずProで最適化 → 限界ならPremium検討
Q4: DirectQueryとImportどちらが速いですか?
一般的にはImportが速いですが、用途によります。

Import(インポート):
✓ 高速(メモリ内で処理)
✓ オフライン可能
✓ すべてのDAX機能使用可
✗ データが古くなる
✗ サイズ制限あり

DirectQuery:
✓ 常に最新データ
✓ 大容量データ対応
✗ 遅い(DB性能依存)
✗ 一部DAX機能制限

推奨:
– バッチ処理: Import
– リアルタイム: DirectQuery
– 大規模: 複合モデル(両方)
Q5: モバイルでの表示が遅いです。対策は?
モバイル専用の最適化が必要です。

モバイル固有の対策:

1. モバイルレイアウト作成
– 「表示」→「モバイルレイアウト」
– 必要最小限のビジュアル配置
– 3-5個に絞る

2. データ量削減
– モバイルはTop 10のみ表示
– デスクトップはTop 100

3. シンプルなビジュアル
– カード、棒グラフ中心
– 複雑なカスタムビジュアル避ける

4. テスト
– 実機でテスト必須
– 3G/4G環境でも確認
Q6: 集約テーブルはどのように作成しますか?
Power Queryで事前集約するか、Premium機能を使用します。

方法1: Power Queryで手動作成
1. Power Query Editorを開く
2. 元テーブルを参照
3. 「グループ化」で集約
4. 例: 日次 → 月次集約

方法2: Premium自動集約
1. Premium機能を有効化
2. モデルで集約を設定
3. 自動的に最適なテーブルを選択

使い分け:
– 長期トレンド: 月次集約テーブル(高速)
– 直近詳細: 元テーブル(必要時のみ)
Q7: DAX Studioとは何ですか?
DAXクエリを分析・最適化するための無料ツールです。

主な機能:
– DAXクエリの実行と結果確認
– クエリプランの表示
– パフォーマンス詳細分析
– メモリ使用量の確認

インストール:
1. https://daxstudio.org/ からダウンロード
2. インストール実行
3. Power BI Desktopと連携

使い方:
1. パフォーマンスアナライザーでDAXクエリをコピー
2. DAX Studioに貼り付け
3. 実行して詳細分析
4. ボトルネックを特定

上級者向けツールですが、深い分析に有用です。
📝

学習メモ

BIツール入門 - Step 45

📋 過去のメモ一覧
#artnasekai #学習メモ
LINE