[2] Power BI Deep Dive [2026-03]

[2] Power BI Deep Dive [2026-03] の資料です。
セッションテーマ：Power BI ユーザーが直面する Fabric 容量の使いすぎ問題と、その賢い向き合い方

MDPJP (Japan Microsoft Data Platform User Group)

Transcript

1. #02 2026 – 03
2. 本日のアジェンダ 時間 内容 19:00 - 19:05 オープニング（ご案内、自己紹介など） 19:05 - 19:45 本題 19:45 - 20:00 質問コーナー、アフタートーク © 2026 Masatoshi Ohata
3. • 円滑な進行のため、ご質問時を除きマイクはオフしてください。 • 資料は後日、Connpass の本イベントページにアップロードします。 • 本セッションは 録画していますが、アーカイブ公開は行いません（運営の記録用です）。 内容に関する注意 • 本シリーズ「Power BI Deep Dive Power Series」では、Fabric × Power BI を中心に取り上げます。 • 一部、プレビュー版／提供前の機能を取り上げる場合があります。 • 内容については 正確性・有用性に配慮していますが、すべてを保証するものではありません。 • 本勉強会での説明や見解は、私個人のものであり、所属する組織・団体を代表するものではありません。 導入時のお願い • 自社環境へ導入する際は、テスト環境での事前検証を行い、最新の公式ドキュメントの確認に加えて、 Microsoft の営業・サポート窓口や担当ベンダーと相談しながら進めてください。 • 本内容を参考にしたことによって問題が生じた場合でも、責任は負いかねますのでご了承ください。 本勉強会ご参加にあたってのご案内 © 2026 Masatoshi Ohata
4. プロフィール 大畑 正利 (おおはた まさとし) 自社の Fabric 管理者として Power BI Free → Pro → Fabric 導入を主導 © 2026 Masatoshi Ohata • 小売企業のデータエンジニア／BI エンジニア • 国家資格データベーススペシャリスト保有 • データサイエンティスト検定合格 • 経済産業省「データサイエンティスト Reスキル講座」修了 Power BI Deep Dive 担当
5. Power BI ユーザーが直面する Fabric 容量の使いすぎ問題と、 その賢い向き合い方 © 2026 Masatoshi Ohata
6. © 2026 Masatoshi Ohata BI の民主化が進み、Power BI 利用者が急増している BI の民主化が組織で進行 • データ分析の専門家だけでなく • 営業・マーケ・人事・経理など、各部門が Power BI を利用 • “セルフサービス BI” が当たり前に しかし、利用者は必ずしも データ基盤の専門家ではない • モデリング・DAX・容量の仕組みは知ら ないことが多い • 「とりあえず作ってみる」文化が広がる • レポート・モデルが急増しやすい 結果として、容量負荷が自然に 増える構造が生まれる • 大きすぎるモデル • ビジュアル過多 • DirectQuery の誤用 • モデル乱立 → 容量問題は“民主化の副作用”として発生しやすい
7. Fabric 容量 データ基盤 Power BI Pro © 2026 Masatoshi Ohata 処理能力の分担 (Pro / Fabric)
8. © 2026 Masatoshi Ohata なぜ Fabric 容量は溶けるのか 容量を消費する主な要因 • セマンティックモデル （Import モデル）のリフレッシュ • 大きすぎるモデルのメモリ展開 • 複雑な DAX クエリの同時実行 • ビジュアル過多によるクエリ多発 • DirectQuery の誤用による負荷増大 複数の負荷が重なると容量ピークが発生 • リフレッシュ × 大型モデル × 多ビジュアル • リフレッシュ衝突でスロットリング • レポート閲覧にも影響が波及 セマンティックモデルのリフレッシュは容量を消費 データ再取得 モデル 再構築 圧縮処理 メモリ展開
9. © 2026 Masatoshi Ohata Power BI 担当者と Fabric 管理者は、見えている世界が違う 観点 Power BI 担当者 Fabric 管理者 利用者の規模 自分のレポートの 利用者・部門 見えていない （把握できていない） レポートの中身 ビジュアル構成、DAX、ページ設計 見ていない （表示は出来るはず） モデルの中身 Star Schema か、列数・行数、計算列 の有無 見ていない （モデルサイズ、リフレッシュログ、 モデルビューの表示は可） Fabric 容量消費 見えない 見える
10. • Power BI に起因する容量急増が発生しても、 Power BI 担当者が全員、ベストプラクティスに詳しいとは限らない • 「Power BI のことはよく分からないから、そっちで何とかして」 → これは Fabric 管理者側の“よくある誤解” • しかし、Power BI 担当者は、 容量メトリクスが見えない／容量の仕組みを知らない → 改善ポイントが分からず、対応が進まない • 結果として、容量消費の問題が長期化しやすい • Fabric 管理者も Power BI の改善方法を理解しておく必要がある 容量トラブルは Power BI 担当者だけでは解決できない © 2026 Masatoshi Ohata
11. Fabric管理者 Power BI 担当者 共同で 対応する内容 対応範囲
12. Fabric容量を溶かすアンチパターン アンチパターン一覧 • A1：大きすぎる Import モデル • A2：スター・スキーマではない • A3：1ページにビジュアルを詰め込みすぎる • A4：Semantic Model の乱立 • A5：DirectQuery の誤用
13. アンチパターン対応： • A1：大きすぎる Import モデル • A2：スタースキーマではない 対応策： • スタースキーマを徹底 • 不要列・不要行の削減 • カーディナリティを下げる • 計算列は Power Query へ移す →モデルサイズを小さくすることが容量節約の第一歩 A1/A2への対応策：モデル設計の最適化 © 2026 Masatoshi Ohata
14. Import モデルが大きいほど • VertiPaq の圧縮が重くなる • リフレッシュ時間が伸びる • メモリピークが跳ね上がる Fabric 容量を多く消費するのは、Import モデルのリフレッシュ 容量が溶ける最大要因のひとつ A1：大きすぎる Import モデル © 2026 Masatoshi Ohata
15. VertiPaq（ヴァーティパック）とは？ • Power BI の Import モデルで使われる 列指向のインメモリ・スト レージエンジン • データを列単位で圧縮し、高速な集計・フィルタリングを実現 • モデルサイズや圧縮率が、容量消費やパフォーマンスに直結する VertiPaq：Power BI の高速化と圧縮を支えるエンジン © 2026 Masatoshi Ohata 圧縮が効くとどうなる？ 圧縮が効きにくいケース モデルが軽くなる スタースキーマになっていないモデル構造 リフレッシュが速くなる 不要列・不要行が多い クエリ負荷が下がる 文字列キー（特に GUID など） 容量消費が抑えられる 高カーディナリティ列（値の種類が多い列）
16. • 事実（Fact）と次元（Dimension）が分離されていない • 正規化された OLTP 形式のまま持ち込んでいる • テーブル同士が複雑に結合され、関係が分かりにくい • 不要列・不要行が多く、モデルが肥大化 • 高カーディナリティ列がそのまま残っている A2：スタースキーマではない © 2026 Masatoshi Ohata 結果として、モデルサイズが大きくなり、DAX も複雑化 →リフレッシュ負荷・クエリ負荷が増大し、容量を圧迫
17. • Fact（事実）と Dimension（次元）を明確に分離する • 1対多（Dimension → Fact）の単純な関係に整理する • 不要列・不要行を削減し、モデルサイズを縮小 • カーディナリティを下げる（時刻を切る、GUID→整数キー） • 計算列は Power Query へ移し、モデルを軽量化 （クエリ フォールディング） 対応策：スター・スキーマを徹底 © 2026 Masatoshi Ohata 結果：リフレッシュ負荷・クエリ負荷が大幅に軽減
18. • VertiPaq が最も圧縮しやすいデー タ型が「整数」 • 値が短く、ビット幅が小さい • パターンが単純で辞書圧縮が効く • 文字列キーは圧縮率が悪く、モデル を重くする • 値が長い • 種類が多い（高カーディナリティ） • 辞書サイズが膨らむ • JOIN（Fact → Dimension）が整 数の方が高速 • CPU が整数比較を高速処理できる • 文字列比較はコストが高い • カーディナリティが下がり、モデルサ イズが小さくなる • 日付の時刻を切る • 例：GUID → 整数 surrogate key （サロゲート）などが有効 • → キー列は整数にするのがベストプ ラクティス 補足：ID を整数にする理由（VertiPaq 最適化） © 2026 Masatoshi Ohata
19. • 手順①：GUID を含む Dimension テーブルを Power Query に読み込む • 例：Customer、Product、Employee など • GUID はそのまま保持して OK（監査・追跡用） • 手順②：GUID を基準に並び替える（安定したキー生成 のため） • GUID 列で昇順ソート • 並び順が変わると surrogate key が変わるため重要 • 手順③：インデックス列を追加する（これが surrogate key） Power Query の操作： • [列の追加] → [インデックス列] → [1 から] • これが整数 surrogate key になる • 手順④：surrogate key を主キーとして利用する • Dimension テーブル：surrogate key を主キーに • Fact テーブル：GUID で JOIN → surrogate key を マージで付与 • 手順⑤：Fact テーブルから GUID を削除（JOIN 後） • Fact 側に GUID を残すとモデルが重くなる • surrogate key のみ残すのがベスト • GUID は保持してよいが、JOIN 用キーは整数 surrogate key にする 例：GUID → 整数 surrogate key （Power Query での作り方） © 2026 Masatoshi Ohata → GUID は保持してよいが、JOIN 用キーは整数 surrogate key にする
20. アンチパターン対応： • A3：1ページにビジュアルを詰め込みすぎる 対応策： • ビジュアル数を絞り、ページ分割で整理する • 高負荷ビジュアル（カード大量配置・複雑なマトリクス） を避ける A3への対応策：ビジュアル設計の最適化 © 2026 Masatoshi Ohata
21. ビジュアルが多いほど、描画コストが増える • 各ビジュアルが個別にクエリを発行 • レンダリング負荷が増大 • メモリ消費も増える スライサー・フィルターが多いほど再描画が頻発 • すべてのビジュアルが再計算 • ページ全体が重くなる カード大量配置・複雑なマトリクスは特に高負荷 • 計算量が多い • 描画処理が重い A3：アンチパターン – 1ページにビジュアルを詰め込みすぎる © 2026 Masatoshi Ohata
22. ビジュアル数を絞る（1ページ 6〜8個が目安） • ビジュアルが多いほど描画負荷が増える • クエリ数が増え、再描画が遅くなる • カード大量配置・複雑なマトリクスは特に高負荷 必要な情報は“ページ分割”で整理 • 情報を詰め込まず、目的別にページを分ける • ページ単位で負荷を分散できる • ユーザーが目的の情報にアクセスしやすくなる • 情報量を減らすのではなく、“ページごとに最適化”するのがポイント 対応策：ビジュアル数を絞り、ページ分割で整理する © 2026 Masatoshi Ohata
23. • カード大量配置は高負荷（1つ1つがクエリ） • 複雑なマトリクスは描画コストが高い • 必要最小限のビジュアルに絞る 高負荷ビジュアルを避ける © 2026 Masatoshi Ohata
24. アンチパターン対応： • A4：Semantic Model の乱立 対応策： • Semantic Model を共有化する • 重複モデルを作らない • “1レポート1モデル”から“1モデル多レポート”へ • OneLake でデータを共通化 • Fabric 管理者と連携してモデル棚卸しを行う A4への対応策：Semantic Model の統合と共有 © 2026 Masatoshi Ohata
25. • 各レポートが独自にモデルを作成 • 同じデータを複数のモデルで重複保持 • モデルサイズが増え、容量を圧迫 • 更新・管理コストが増大 • データ定義がバラバラになり、整合性が崩れる A4:アンチパターン - Semantic Model の乱立 © 2026 Masatoshi Ohata
26. • Semantic Model を共有化する • 重複モデルを作らない • “1レポート1モデル”から“1モデル多レポート”へ • OneLake でデータを共通化 • Fabric 管理者と連携してモデル棚卸しを行う 対応策：Semantic Model の統合と共有 © 2026 Masatoshi Ohata
27. マスターモデルを作るメリット： • データ定義の一貫性 → KPI・計算ロジック・ディメンションが統一される • 容量の節約 → 同じデータを複数モデルで重複保持しない • 更新コストの削減 → リフレッシュ対象が1つに集約される • レポート開発の効率化 → モデル作成の手間が不要になり、可視化に集中できる • ガバナンス強化 → データ品質・アクセス権限を一元管理できる 補足①：“マスターモデル”を推奨します © 2026 Masatoshi Ohata ☞ “共有データセット（Semantic Model）の再利用” を推奨
28. 再利用の手順： 1. マスターモデルを Workspace に配置 （推奨：専用の“モデル管理用 Workspace”を作る） 2. Power BI Desktop で、“ライブ接続（Get data → Power BI Semantic Models）” を選択 3. マスターモデルを選択して接続 4. レポートは可視化に専念（モデル編集は不 可） 5. 必要に応じて Calculation Group やフィー ルドパラメータで拡張 補足②：マスターモデルを再利用する手順と注意点 © 2026 Masatoshi Ohata 再利用時の注意点： • モデルは編集できない（読み取り専用） • 必要な列・メジャーは事前にマスターモデル 側で整備する • 命名規則・フォルダ構造を統一する → レポート作成者が迷わないように • アクセス権限（RLS/OLS）をモデル側で管 理 → レポート側では設定できない • モデル更新の影響範囲が大きい → 変更時は“影響を受けるレポート一覧”を 確認する • モデルの棚卸しを定期的に実施 → 不要なメジャー・列を増やさない
29. アンチパターン対応 • A5：DirectQuery の誤用 対応策（Best Practices） • Import を基本とする • DirectQuery は“最後の手段” • Hybrid Tables の活用 • 高カーディナリティ列を避ける • 複雑な DAX を避ける（特に FILTER / SUMX） A5への対応策：DirectQuery の正しい使い方 © 2026 Masatoshi Ohata
30. DirectQuery の誤用が引き起こす問題： • クエリが都度データソースへ飛び、遅延が発生しやすい • データソース側の負荷が増大し、全体のパフォーマンスが悪化 • 高カーディナリティ列があると、クエリが極端に重くなる • FILTER / SUMX などの行コンテキスト DAX が、SQL に変換され、 処理が爆発的に重くなる • レポート閲覧者が増えるほど、容量消費が増加 A5：DirectQuery の誤用 © 2026 Masatoshi Ohata
31. • Import を基本とする（最速・最安定） • DirectQuery は“最後の手段”として使う • リアルタイム性が本当に必要な場合のみ • Hybrid Tables を活用する • 大量データは DirectQuery • 直近データは Import → 高速性とリアルタイム性の両立 A5への対応策：DirectQuery の正しい使い方 © 2026 Masatoshi Ohata
32. • F1：容量メトリクスを見ていない • F2：管理者設定が適切でない • F3：放置された Semantic Model や BI レポートが容 量を圧迫する • F4：問題が生じやすいモデルやレポートが本番にデプロ イされる • F5：F1〜F4 の対策を継続的に運用していない 容量運用のアンチパターン F1〜F5 © 2026 Masatoshi Ohata
33. © 2026 Masatoshi Ohata F1 状況把握 F2 体制整備 F3 資産管理 F4 品質管理 F５ 継続運用
34. アンチパターン：容量メトリクスを見ていない • 容量逼迫に気づけない • 「なんとなく遅い」の原因が分からない 対応策：日頃から高負荷レポート・データセットを把握する • 容量メトリクスで高負荷ワークスペースを確認 • クエリ負荷・リフレッシュ負荷の大きいモデルを特定 • 問題が起きる前に“怪しい候補”をリスト化しておく F1 アンチパターン：容量メトリクスを見ていない © 2026 Masatoshi Ohata
35. アンチパターン：ワークスペース管理者・BI レポート管理者が 適切に設定されていない • 誰が何を管理しているか分からない • 非常時に「誰に連絡すればいいか」が不明 対応策：非常時に誰に修正を依頼するか、あらかじめ決めて おく • ワークスペースごとに“技術的な責任者”を明確化 • BI レポートのオーナーを設定し、連絡経路を共有 • 容量トラブル時のエスカレーションフローを決めておく F2 アンチパターン：管理者設定が適切でない © 2026 Masatoshi Ohata
36. アンチパターン：使われていない Semantic Model や BI レ ポートが残り続ける • - 誰も見ていないのにリフレッシュだけ続いている • - バックグラウンド容量を無駄に消費 対応策：利用状況を確認し、棚卸し・アーカイブを行う • - Usage Metrics で“使われていない”レポート・モデルを 特定 • - 削除・アーカイブ・別環境への移動などの方針を決める • - ワークスペース所有者に棚卸しの責任を持たせる F3 アンチパターン：放置された Semantic Model や BI レポートが容量を圧迫する © 2026 Masatoshi Ohata
37. • アンチパターン：容量を圧迫しやすい Semantic Model や BI レ ポートがそのまま本番へ • 不要に大きいモデル・複雑すぎる DAX・高負荷ビジュアル • デプロイ前にパフォーマンス観点のチェックが行われていない • 対応策：Fabric デザインレビューを行う • モデルサイズ・関係・集約・DAX の複雑さをレビュー • 高負荷ビジュアルを事前に指摘 • 本番デプロイ前に“容量・パフォーマンスの観点”でチェックする文 化を作る F4 アンチパターン：問題が生じやすいモデルや レポートがデプロイされる © 2026 Masatoshi Ohata
38. アンチパターン：改善が一度きりで終わり、継続的な見直しが行われ ない • 新しい問題が発生しても気づくのが遅れる • 古いモデル・設定・運用ルールがそのまま残る 対応策：F1〜F4 を定期的にレビューする仕組みを作る • 月次・四半期で容量メトリクス・利用状況・リフレッシュ履歴を確認 • 高負荷モデル・放置モデル・問題レポートを定期的に棚卸し • ワークスペース所有者・BI 担当者・データチームでレビュー会を行 う F5 アンチパターン：F1〜F4 の対策を継続的に運 用していない © 2026 Masatoshi Ohata
39. Power BI 担当者向け：大きすぎる Import モデルを見直す（A1） • モデルサイズを確認し、不要列・不要テーブルを削減 • 可能な箇所は集約テーブル・スター型スキーマへ整理 • モデルの“軽量化”だけでパフォーマンスは大きく改善 Fabric 管理者向け：容量メトリクスを毎日チェックする（F1） • 高負荷ワークスペース・データセットを把握 • スロットリングやリフレッシュ失敗の兆候を早期に発見 • “怪しいワークスペース”をリスト化しておく 共通アクション：放置された Semantic Model / BI レポートを棚卸しする（F3） • Usage Metrics で“使われていない”アーティファクトを特定 • リフレッシュ停止・アーカイブ・削除を判断 • 容量の無駄遣いを即日で削減できる 今日からできる 3 つのアクション © 2026 Masatoshi Ohata
40. #03 仮 2026-04-12 Japan Microsoft Data Platform User Group
41. 本日のアジェンダ 時間 内容 19:00 - 19:05 オープニング（MDPJPの紹介、お知らせなど） 19:05 - 19:45 Power BI ユーザーが Fabric 容量ライセンスで得られるメリット 19:45 - 20:00 質問コーナー、アフタートーク © 2026 Masatoshi Ohata