⚡ STEP 47: パフォーマンス最適化のベストプラクティス
ダッシュボードを高速化して、最高のユーザー体験を提供しよう!
📋 このステップで学ぶこと
- データ抽出 vs 接続の選択基準
- フィルター最適化テクニック
- 計算効率化の実践
- キャッシュ活用戦略
- パフォーマンス診断方法
- 両ツール共通のベストプラクティス
ゴール:TableauとPower BI両方で、3秒以内に表示される高速ダッシュボードを設計できるようになる
🎯 1. パフォーマンスの重要性
なぜパフォーマンスが重要なのか
ダッシュボードの表示速度は、ユーザー体験に直結します。遅いダッシュボードは、せっかく作っても使われなくなってしまいます。
| 表示時間 | ユーザーの反応 | 利用継続率 | 評価 |
|---|---|---|---|
| 1秒以内 | 即座に反応、ストレスなし | 95%以上 | 🟢 理想 |
| 1〜3秒 | 待機を認識、許容範囲 | 85%程度 | 🟢 良好 |
| 3〜8秒 | 待ち時間を感じる、不満 | 60%程度 | 🟡 要改善 |
| 8秒以上 | 離脱を検討、強い不満 | 30%以下 | 🔴 危険 |
| 要素 | 説明 | 影響度 |
|---|---|---|
| 1. データ量 | 行数 × 列数 | ★★★★★(最大) |
| 2. データソース | ライブ接続 vs 抽出 | ★★★★★(最大) |
| 3. 計算の複雑さ | LOD/DAXの使い方 | ★★★★☆(大) |
| 4. ビジュアルの数 | 1ページの表示要素 | ★★★☆☆(中) |
| 5. フィルターの数 | 処理されるフィルター数 | ★★★☆☆(中) |
| 6. ネットワーク | インターネット速度 | ★★☆☆☆(小) |
💾 2. データ抽出 vs ライブ接続の選択
それぞれの特徴
データソースへの接続方法は、パフォーマンスに最も大きな影響を与える要素の一つです。用途に応じて適切に選択しましょう。
| 項目 | ライブ接続 | データ抽出 |
|---|---|---|
| データ鮮度 | リアルタイム | 更新タイミング依存 |
| パフォーマンス | データソース依存(通常遅い) | 高速(メモリ内処理) |
| データ量 | 制限なし | 容量制限あり |
| オフライン利用 | 不可 | 可能 |
| 複雑な計算 | 遅い可能性 | 高速 |
| セキュリティ | データがローカルに残らない | データがローカルにコピー |
【ライブ接続を選ぶ場合】 ✓ リアルタイムデータが必須 ✓ データベースが高速(専用DWH等) ✓ データ量が巨大(数億行以上) ✓ セキュリティ要件が厳しい ✓ 常に最新データが必要 適用例: ├─ リアルタイム監視ダッシュボード ├─ トランザクション分析 ├─ センサーデータ分析 └─ 金融取引モニタリング 【データ抽出を選ぶ場合】 ✓ パフォーマンス最優先 ✓ オフライン使用が必要 ✓ 複雑な計算が多い ✓ データベースが遅い ✓ 更新頻度が低い(日次/週次) 適用例: ├─ 月次レポート ├─ 経営ダッシュボード ├─ 分析用ダッシュボード └─ モバイルアクセス用
開発時:ライブ接続で柔軟に開発
本番環境:抽出に切り替えてパフォーマンス確保
これにより、開発の柔軟性と本番のパフォーマンスの両立が可能になります。
🔍 3. フィルター最適化
フィルターがパフォーマンスに与える影響
フィルターは便利な機能ですが、使い方によってはパフォーマンスを大きく低下させます。特に複数のフィルターを組み合わせると、処理時間が指数関数的に増加します。
【フィルター処理の順序(速い順)】 1. 抽出フィルター(Extract Filter) └─ 最も早い、データ自体を削減 └─ 抽出作成時に適用 2. データソースフィルター(Data Source Filter) └─ 全シートに適用 └─ 接続時に適用 3. コンテキストフィルター(Context Filter) └─ 他のフィルターより先に処理 └─ 一時テーブルを作成 4. ディメンションフィルター └─ 通常のフィルター └─ カテゴリ・名前等 5. メジャーフィルター └─ 集計後にフィルター └─ SUM > 1000 等 【最適化テクニック】 ✓ 不要なデータは抽出時に除外 ✓ 共通フィルターをコンテキストに設定 ✓ フィルター数を最小限に(5個以下推奨) ✓ 日付フィルターを連続値に設定 ✓ Top Nフィルターは条件付きに ✓ ワイルドカードフィルターを避ける
【フィルター処理の順序(速い順)】 1. 行レベルセキュリティ(RLS) └─ 最も早い └─ データアクセス前に適用 2. レポートレベルフィルター └─ 全ページに適用 └─ 一度だけ処理 3. ページレベルフィルター └─ 特定ページに適用 └─ ページ読み込み時に処理 4. ビジュアルレベルフィルター └─ 個別ビジュアルに適用 └─ 各ビジュアルで処理 【最適化テクニック】 ✓ スライサーを使いすぎない(3-5個まで) ✓ リレーションシップで自動フィルター活用 ✓ DAXフィルターはVARで変数化 ✓ KEEPFILTERS関数の活用 ✓ 不要なビジュアルインタラクション無効化 ✓ ALLを慎重に使用
10個のフィルターがあり、それぞれ10の選択肢がある場合、理論上10の10乗(100億)の組み合わせが発生します。
対策:フィルターは必要最小限に抑え、共通フィルターは上位レベルで処理しましょう。
🧮 4. 計算の効率化
計算最適化の基本原則
計算の書き方によって、パフォーマンスは大きく変わります。両ツール共通の原則と、それぞれの最適化テクニックを学びましょう。
| 原則 | 説明 | 効果 |
|---|---|---|
| 事前計算 | 頻繁に使う計算は計算列で事前に | 表示時の計算を削減 |
| 重複計算の排除 | 変数(VAR)で一度だけ計算 | 処理時間を50%以上削減 |
| シンプルな関数 | 複雑なネストを避ける | エンジン最適化が効く |
| フィルター最小化 | 計算内のフィルターを減らす | スキャン回数を削減 |
【遅い計算の例】
❌ 悪い例: 毎回計算
IF [売上] > 100000 THEN "大口"
ELSEIF [売上] > 50000 THEN "中口"
ELSE "小口"
END
問題点:
├─ 各行で毎回IF文を評価
├─ ビューごとに再計算
└─ キャッシュが効かない
✅ 良い例: 計算列で事前計算
データソースに計算列を追加:
売上区分 = IF([売上] > 100000, "大口",
IF([売上] > 50000, "中口", "小口"))
メリット:
├─ 一度だけ計算
├─ キャッシュ可能
└─ 高速
─────────────────────────────
【LOD表現のパフォーマンス(速い順)】
1. FIXED(最速)
└─ フィルターの影響を受けない
例: { FIXED [地域] : SUM([売上]) }
2. INCLUDE
└─ 詳細度を上げる
例: { INCLUDE [商品] : AVG([売上]) }
3. EXCLUDE(最遅)
└─ 詳細度を下げる
例: { EXCLUDE [月] : SUM([売上]) }
最適化のコツ:
✓ できるだけFIXEDを使う
✓ 必要最小限のフィールドのみ指定
✓ 計算結果をデータソースに保存
✓ ネストを避ける
【遅いDAXの例】
❌ 悪い例: 複雑なネスト
売上合計 =
CALCULATE(
SUM(売上[金額]),
FILTER(
ALL(商品),
商品[カテゴリ] = "A"
)
)
問題点:
├─ FILTERで全行スキャン
├─ 計算コンテキストが複雑
└─ キャッシュが効きにくい
✅ 良い例: シンプルなフィルター
売上合計 =
CALCULATE(
SUM(売上[金額]),
商品[カテゴリ] = "A"
)
メリット:
├─ 直接フィルター適用
├─ エンジンが最適化
└─ 高速実行
─────────────────────────────
【変数(VAR)で最適化】
❌ 悪い例: 同じ計算を繰り返す
前年比 =
DIVIDE(
SUM(売上[金額]),
CALCULATE(
SUM(売上[金額]),
SAMEPERIODLASTYEAR(日付[Date])
)
) - 1
問題点: SUM(売上[金額])を2回計算
✅ 良い例: 変数で一度だけ計算
前年比 =
VAR 今年売上 = SUM(売上[金額])
VAR 前年売上 = CALCULATE(
SUM(売上[金額]),
SAMEPERIODLASTYEAR(日付[Date])
)
RETURN
DIVIDE(今年売上, 前年売上) - 1
メリット:
├─ 計算を1回に削減
├─ 可読性向上
└─ メンテナンス容易
| 項目 | 計算列 | メジャー |
|---|---|---|
| 計算タイミング | データ更新時に一度だけ | ビジュアル表示時に毎回 |
| パフォーマンス | 表示時は高速 | 表示時は低速 |
| モデルサイズ | 増加する | 増加しない |
| 適した用途 | 頻繁に使う固定計算 | 集計、動的計算 |
🎨 5. ビジュアルの最適化
ビジュアル数の制限
各ビジュアルは個別にクエリを実行するため、数が多いほど負荷が増大します。適切な数に抑えることが重要です。
| ビジュアル数 | 評価 | 備考 |
|---|---|---|
| 5〜7個 | 🟢 理想 | 快適な表示速度、見やすいレイアウト |
| 8〜10個 | 🟡 許容 | やや遅くなる可能性、レイアウトに工夫必要 |
| 11〜15個 | 🟠 要注意 | パフォーマンス低下、ページ分割を検討 |
| 16個以上 | 🔴 避けるべき | ユーザー体験悪化、必ずページ分割 |
| 速度 | ビジュアルタイプ | 備考 |
|---|---|---|
| 🟢 高速 | 棒グラフ、折れ線グラフ、カード、テーブル(小規模) | シンプルな描画、推奨 |
| 🟡 普通 | 散布図、ヒートマップ、地図(中規模) | データ点に注意 |
| 🔴 低速 | 地図(大規模)、複雑なカスタムビジュアル、大量データのテーブル | データを絞るか代替手段 |
【データポイント制限】 Tableau: ├─ 1ビューあたり10万ポイント以下推奨 ├─ それ以上は集計やフィルター └─ 警告が出たら対策必須 Power BI: ├─ 1ビジュアルあたり3.5万ポイント制限 ├─ 自動的に集計される └─ 高カーディナリティに注意 【データポイント削減の対策】 1. 適切な粒度で集計 ├─ 日次 → 週次/月次 └─ 詳細 → サマリー 2. Top N表示 ├─ 全商品 → Top 20 └─ 全顧客 → Top 100 3. 階層ドリルダウン ├─ 最初は概要のみ └─ クリックで詳細表示 4. 詳細は別ページへ ├─ サマリーページ └─ 詳細ページ(ドリルスルー)
🗄️ 6. キャッシュ活用戦略
キャッシュの重要性
キャッシュを効果的に活用することで、同じクエリの再実行を避け、パフォーマンスを大幅に向上させることができます。
| キャッシュ種類 | Tableau | Power BI |
|---|---|---|
| クエリキャッシュ | 同じクエリ結果を保存(デフォルト有効) | Power BI Serviceで同一クエリを再利用 |
| データキャッシュ | 抽出データをメモリに保持 | インポートモードで最大限活用 |
| 計算キャッシュ | 計算結果の再利用 | DAXキャッシュ(自動管理) |
| 共有キャッシュ | 同じデータソースを共有 | Premiumで共有可能 |
| Tableau | Power BI |
|---|---|
| ✓ 抽出を使う | ✓ インポートモードを優先 |
| ✓ 同じデータソースを共有 | ✓ 集計テーブル作成(Premium) |
| ✓ パラメータを活用(フィルターより高速) | ✓ メジャーを共有 |
| ✓ キャッシュウォーミング(事前アクセス) | ✓ 定期的なアクセスでキャッシュ維持 |
🔧 7. パフォーマンス診断ツール
診断ツールの活用
パフォーマンス問題を解決するには、まずボトルネックを特定することが重要です。両ツールには強力な診断機能があります。
【使い方】 ステップ1: 記録開始 ├─ ヘルプ > 設定とパフォーマンス ├─ パフォーマンスの記録を開始 └─ ダッシュボードを操作 ステップ2: 操作を実行 ├─ フィルター変更 ├─ ページ切り替え ├─ ドリルダウン └─ 様々な操作を記録 ステップ3: 記録停止 ├─ パフォーマンスの記録を停止 └─ 結果ダッシュボードが開く ステップ4: 結果分析 ┌────────────────────────────────┐ │ イベント 時間(秒) │ ├────────────────────────────────┤ │ クエリ実行 3.2s ⚠️ │ │ ジオコーディング 1.5s │ │ レイアウト計算 0.8s │ │ レンダリング 0.5s │ │ 合計 6.0s ❌ │ └────────────────────────────────┘ 【チェックポイント】 ✓ クエリ実行時間: 3秒以上は要改善 ✓ レイアウト計算: 1秒以上は複雑すぎ ✓ ジオコーディング: 地図の最適化必要 ✓ レンダリング: ビジュアル数削減を検討
【使い方】 ステップ1: パネルを開く ├─ 表示 > パフォーマンスアナライザー └─ 右側にパネルが表示 ステップ2: 記録開始 ├─ 「記録の開始」をクリック ├─ ダッシュボードを操作 │ ├─ ビジュアル更新 │ ├─ フィルター適用 │ └─ ページ切り替え └─ 「記録の停止」 ステップ3: 結果分析 ┌────────────────────────────────┐ │ ビジュアル名 時間(ms) │ ├────────────────────────────────┤ │ 売上推移グラフ 1,245ms ⚠️ │ │ - DAXクエリ: 1,100ms │ │ - その他: 145ms │ │ │ │ KPIカード 120ms ✓ │ │ - DAXクエリ: 80ms │ │ - その他: 40ms │ └────────────────────────────────┘ 【チェックポイント】 ✓ DAXクエリ: 1秒以上は最適化必要 ✓ ビジュアル表示: 500ms以上は要確認 ✓ その他: ネットワークやブラウザの問題 ✓ 「クエリのコピー」でDAX詳細分析
✅ 8. パフォーマンス最適化チェックリスト
層別チェックリスト
パフォーマンス最適化は複数の層で行う必要があります。以下のチェックリストを活用して、漏れなく最適化を進めましょう。
| 層 | チェック項目 | 効果 |
|---|---|---|
| データ層 | □ 不要なデータを除外 | データ量削減 |
| □ 抽出を活用 | クエリ高速化 | |
| □ データ型を最適化 | メモリ効率化 | |
| □ インデックスを確認(DB) | クエリ高速化 | |
| □ 集計テーブルを作成 | 集計高速化 | |
| □ 増分更新を設定 | 更新時間短縮 | |
| 計算層 | □ LOD/DAXを最小限に | 計算時間削減 |
| □ 計算列を活用 | 表示時間削減 | |
| □ 変数(VAR)で重複回避 | 処理時間50%削減 | |
| □ ネストを避ける | エンジン最適化 | |
| □ シンプルな関数を優先 | キャッシュ効率化 | |
| □ キャッシュ可能な設計 | 再利用性向上 | |
| ビジュアル層 | □ ビジュアル数を制限(5-10個) | クエリ数削減 |
| □ データポイントを削減 | 描画高速化 | |
| □ 軽量なビジュアルを選択 | レンダリング高速化 | |
| □ 不要なインタラクション無効化 | フィルター処理削減 | |
| □ 画像を最適化 | 読み込み高速化 | |
| □ 適切な粒度で表示 | データ量削減 | |
| フィルター層 | □ フィルター数を最小限に | 組み合わせ爆発防止 |
| □ コンテキストフィルター活用 | 処理順序最適化 | |
| □ 抽出フィルターで事前削減 | データ量削減 | |
| □ リレーションシップで自動フィルター | 効率的なフィルター | |
| □ パラメータ活用 | 柔軟性と速度両立 | |
| □ Top Nフィルター最適化 | 表示データ削減 |
📝 STEP 47 のまとめ
- データ接続:抽出 vs ライブの選択基準(パフォーマンス重視なら抽出)
- フィルター:処理順序と最適化テクニック(5個以下推奨)
- 計算:LOD/DAXの効率的な使い方(変数活用、シンプル化)
- ビジュアル:数と種類の最適化(5-10個/ページ)
- キャッシュ:メモリの有効活用(事前アクセス)
- 診断:ボトルネック特定方法(パフォーマンスレコーダー/アナライザー)
| 優先度 | 領域 | 主な施策 | 期待効果 |
|---|---|---|---|
| 1 | データ層 | 抽出化、不要データ削除 | 50%以上改善 |
| 2 | 計算層 | 変数化、シンプル化 | 30%改善 |
| 3 | ビジュアル層 | 数削減、ページ分割 | 20%改善 |
| 4 | フィルター層 | 数削減、順序最適化 | 10%改善 |
パフォーマンス最適化は設計段階から考えることが重要です。後から最適化するのは困難で、3倍の工数がかかります。
データ量、計算の複雑さ、ビジュアル数の3つをバランスよく設計し、定期的にパフォーマンスレコーダー/アナライザーで診断して継続的に改善していきましょう!
📝 実践演習
売上ダッシュボード(10万行データ)の表示に8秒かかっています。パフォーマンスレコーダーを使って、どこがボトルネックか特定してください。
Step 1: パフォーマンスレコーダー起動
Tableau: ヘルプ > 設定とパフォーマンス > パフォーマンスの記録を開始 Power BI: 表示 > パフォーマンスアナライザー > 記録の開始
Step 2: ダッシュボード読み込み
- ページを開く
- フィルターを適用
- ビジュアルを更新
Step 3: 結果分析
| 処理 | 時間 | 評価 |
|---|---|---|
| クエリ実行 | 5.2秒 | ❌ 遅い |
| レンダリング | 1.8秒 | ⚠️ やや遅い |
| その他 | 1.0秒 | ✓ 正常 |
Step 4: 改善策
ボトルネック: クエリ実行(5.2秒) 対策: 1. ライブ接続 → 抽出に変更 └─ 期待効果: 3秒短縮 2. 不要な列を削除 └─ 50列 → 20列に削減 3. フィルターで期間限定 └─ 直近1年のみ表示 4. 計算フィールドを事前計算 └─ データソースに追加 期待結果: 8秒 → 2秒(75%改善)
以下のDAXメジャーを最適化してください。現在3秒かかっている計算を1秒以内にしてください。
売上YoY成長率 =
DIVIDE(
SUM(売上[金額]) - CALCULATE(
SUM(売上[金額]),
SAMEPERIODLASTYEAR(日付[Date])
),
CALCULATE(
SUM(売上[金額]),
SAMEPERIODLASTYEAR(日付[Date])
)
)
問題点の分析:
- SUM(売上[金額])を3回計算
- CALCULATE(SAMEPERIODLASTYEAR)を2回実行
- 変数を使っていない
最適化後のコード:
売上YoY成長率 =
VAR 今年売上 = SUM(売上[金額])
VAR 前年売上 =
CALCULATE(
SUM(売上[金額]),
SAMEPERIODLASTYEAR(日付[Date])
)
RETURN
DIVIDE(今年売上 - 前年売上, 前年売上)
改善ポイント:
- 変数化: 計算を1回に削減
- シンプル化: DIVIDEの引数を簡略化
- 可読性: 意図が明確に
さらなる最適化(可能なら):
# 計算列として事前計算(データ更新時に1回だけ)
前年売上列 =
CALCULATE(
SUM(売上[金額]),
DATEADD(日付[Date], -1, YEAR)
)
# メジャーはシンプルに
売上YoY成長率 =
DIVIDE(
SUM(売上[金額]) - SUM(売上[前年売上列]),
SUM(売上[前年売上列])
)
期待結果: 3秒 → 0.5秒(83%改善)
500万行のデータで、15個のビジュアルがある経営ダッシュボードを最適化してください。現在20秒かかっています。目標は3秒以内です。
Phase 1: 現状分析
問題点: ✗ データ量: 500万行(大規模) ✗ ビジュアル数: 15個(多すぎ) ✗ 表示時間: 20秒(遅すぎ) 目標: ✓ 3秒以内 ✓ ユーザー満足度向上
Phase 2: データ層最適化(50%改善見込み)
- 抽出への切り替え: 8秒短縮
- データ削減: 500万行→200万行(直近2年)、50列→30列 → 3秒短縮
- 集計テーブル作成: 月次集計テーブル追加 → 2秒短縮
小計: 20秒 → 7秒
Phase 3: ビジュアル再設計(30%改善見込み)
- ページ分割:
- メインページ: 6個(概要)
- 詳細ページ1: 5個(売上)
- 詳細ページ2: 4個(顧客)
- ビジュアル最適化:
- 複雑な地図 → 棒グラフに変更
- 大量行テーブル → Top 10のみ表示
小計: 7秒 → 3秒
Phase 4: 計算・フィルター最適化(10%改善見込み)
- 複雑なDAX → シンプル化、変数化
- フィルター数削減: 8個 → 4個
最終結果: 3秒 → 2.5秒
最終成果:
| 指標 | 改善前 | 改善後 | 改善率 |
|---|---|---|---|
| 表示時間 | 20秒 | 2.5秒 | 87.5% |
| データ量 | 500万行 | 200万行 | 60%削減 |
| ビジュアル数 | 15個/ページ | 6個/ページ | 60%削減 |
| ユーザー満足度 | 40% | 95% | 137%向上 |
❓ よくある質問
設計段階:
– データモデル設計
– 抽出 vs 接続の決定
– 必要データの見極め
開発段階:
– シンプルな計算
– ビジュアル数の制限
– 定期的なパフォーマンステスト
運用段階:
– 継続的な監視
– ユーザーフィードバック
– 定期的な最適化
後から最適化するのは3倍の工数がかかります!
抽出を選ぶ場合:
✓ パフォーマンス最優先
✓ 更新頻度が低い(日次以下)
✓ 複雑な計算が多い
✓ オフライン使用
✓ モバイルアクセス
ライブ接続を選ぶ場合:
✓ リアルタイムデータ必須
✓ データが巨大(数億行)
✓ データベースが高速
✓ セキュリティ要件が厳しい
迷ったら抽出から始めるのが安全です。
5-7個(理想):
– 快適な表示速度
– 見やすいレイアウト
– メンテナンス容易
8-10個(許容):
– やや遅くなる可能性
– レイアウトに工夫必要
– 定期的な最適化必要
11個以上(避けるべき):
– パフォーマンス低下
– ユーザー体験悪化
– ページ分割を検討
多くの情報を見せたい場合は、ページを分割したり、ドリルスルー機能を活用しましょう。
Step 1: 診断
– パフォーマンスレコーダー/アナライザー実行
– ボトルネック特定
Step 2: 優先順位付け
1. データ層(影響大)
2. 計算層(影響中)
3. ビジュアル層(影響小)
Step 3: クイックウィン
すぐに効果が出る改善:
✓ 不要なビジュアル削除
✓ フィルター数削減
✓ ライブ→抽出変更
✓ 不要なデータ列削除
Step 4: 本格的な最適化
– データモデル見直し
– 計算ロジック改善
– アーキテクチャ再設計
20%の努力で80%の改善が可能です!
共通の原則:
– データ量を削減
– ビジュアル数を制限
– 計算をシンプルに
– フィルターを最適化
Tableau固有:
– 抽出(.hyper)が強力
– コンテキストフィルターを活用
– LOD表現はFIXED優先
– パフォーマンスレコーダーで診断
Power BI固有:
– インポートモード推奨
– DAXは変数(VAR)活用
– 集計テーブル(Premium)
– パフォーマンスアナライザーで診断
目的:
– ユーザーアクセス時にキャッシュヒット
– 初回表示を高速化
方法:
– 定期的な自動アクセス(毎朝7時など)
– スケジュールタスクで実行
– API経由でプログラム実行
効果:
– 初回アクセス時間を50%以上短縮
– ユーザー体験の大幅向上
特に朝の会議前など、アクセスが集中する時間帯に効果的です。
学習メモ
BIツール入門 - Step 47