2026-02 Microsoft Data Analytics Day

2026-02 Microsoft Data Analytics Day での大畑の投影資料です。

Transcript

1. Power BI
2. プロフィール 大畑 正利 (おおはた まさとし) 自社の Fabric 管理者として Power BI Free → Pro → Fabric 導入を主導 © 2026 Masatoshi Ohata • 小売企業のデータエンジニア／BI エンジニア • 国家資格データベーススペシャリスト保有 • データサイエンティスト検定合格 • 経済産業省「データサイエンティスト Reスキル講座」修了 Power BI Deep Dive 担当
3. Power BI レポートでFabric容量を 溶かさないために、やるべきこと 〜Power BI 担当者 × Fabric 管理者の両視点で考える〜 © 2026 Masatoshi Ohata
4. © 2026 Masatoshi Ohata BI の民主化が進み、Power BI 利用者が急増している BI の民主化が組織で進行 • データ分析の専門家だけでなく • 営業・マーケ・人事・経理など、各部門が Power BI を利用 • “セルフサービス BI” が当たり前に しかし、利用者は必ずしも データ基盤の専門家ではない • モデリング・DAX・容量の仕組みは知ら ないことが多い • 「とりあえず作ってみる」文化が広がる • レポート・モデルが急増しやすい 結果として、容量負荷が自然に 増える構造が生まれる • 大きすぎるモデル • ビジュアル過多 • DirectQuery の誤用 • モデル乱立 → 容量問題は“民主化の副作用”として発生しやすい
5. Fabric 容量 データ基盤 Power BI Pro © 2026 Masatoshi Ohata 処理能力の分担 (Pro / Fabric)
6. © 2026 Masatoshi Ohata なぜ Fabric 容量は溶けるのか 容量を消費する主な要因 • セマンティックモデル （Import モデル）のリフレッシュ • 大きすぎるモデルのメモリ展開 • 複雑な DAX クエリの同時実行 • ビジュアル過多によるクエリ多発 • DirectQuery の誤用による負荷増大 複数の負荷が重なると容量ピークが発生 • リフレッシュ × 大型モデル × 多ビジュアル • リフレッシュ衝突でスロットリング • レポート閲覧にも影響が波及 セマンティックモデルのリフレッシュは容量を消費 データ再取得 モデル 再構築 圧縮処理 メモリ展開
7. © 2026 Masatoshi Ohata Power BI 担当者と Fabric 管理者は、見えている世界が違う 観点 Power BI 担当者 Fabric 管理者 利用者の規模 自分のレポートの 利用者・部門 見えていない （把握できていない） レポートの中身 ビジュアル構成、DAX、ページ設計 見ていない （表示は出来るはず） モデルの中身 Star Schema か、列数・行数、計算列 の有無 見ていない （モデルサイズ、リフレッシュログ、 モデルビューの表示は可） Fabric 容量消費 見えない 見える
8. • Power BI に起因する容量急増が発生しても、 Power BI 担当者が全員、ベストプラクティスに詳しいとは限らない • 「Power BI のことはよく分からないから、そっちで何とかして」 → これは Fabric 管理者側の“よくある誤解” • しかし、Power BI 担当者は、 容量メトリクスが見えない／容量の仕組みを知らない → 改善ポイントが分からず、対応が進まない • 結果として、容量消費の問題が長期化しやすい • Fabric 管理者も Power BI の改善方法を理解しておく必要がある 容量トラブルは Power BI 担当者だけでは解決できない © 2026 Masatoshi Ohata
9. Fabric管理者 Power BI 担当者 共同で 対応する内容 対応範囲
10. • F1：容量メトリクスを見ていない • F2：管理者設定が適切でない • F3：放置された Semantic Model や BI レポートが容 量を圧迫する • F4：問題が生じやすいモデルやレポートが本番にデプロ イされる • F5：F1〜F4 の対策を継続的に運用していない 容量運用のアンチパターン F1〜F5 © 2026 Masatoshi Ohata
11. © 2026 Masatoshi Ohata F1 状況把握 F2 体制整備 F3 資産管理 F4 品質管理 F５ 継続運用
12. アンチパターン：容量メトリクスを見ていない • 容量逼迫に気づけない • 「なんとなく遅い」の原因が分からない 対応策：日頃から高負荷レポート・データセットを把握する • 容量メトリクスで高負荷ワークスペースを確認 • クエリ負荷・リフレッシュ負荷の大きいモデルを特定 • 問題が起きる前に“怪しい候補”をリスト化しておく F1 アンチパターン：容量メトリクスを見ていない © 2026 Masatoshi Ohata
13. アンチパターン：ワークスペース管理者・BI レポート管理者が 適切に設定されていない • 誰が何を管理しているか分からない • 非常時に「誰に連絡すればいいか」が不明 対応策：非常時に誰に修正を依頼するか、あらかじめ決めて おく • ワークスペースごとに“技術的な責任者”を明確化 • BI レポートのオーナーを設定し、連絡経路を共有 • 容量トラブル時のエスカレーションフローを決めておく F2 アンチパターン：管理者設定が適切でない © 2026 Masatoshi Ohata
14. アンチパターン：使われていない Semantic Model や BI レ ポートが残り続ける • - 誰も見ていないのにリフレッシュだけ続いている • - バックグラウンド容量を無駄に消費 対応策：利用状況を確認し、棚卸し・アーカイブを行う • - Usage Metrics で“使われていない”レポート・モデルを 特定 • - 削除・アーカイブ・別環境への移動などの方針を決める • - ワークスペース所有者に棚卸しの責任を持たせる F3 アンチパターン：放置された Semantic Model や BI レポートが容量を圧迫する © 2026 Masatoshi Ohata
15. • アンチパターン：容量を圧迫しやすい Semantic Model や BI レ ポートがそのまま本番へ • 不要に大きいモデル・複雑すぎる DAX・高負荷ビジュアル • デプロイ前にパフォーマンス観点のチェックが行われていない • 対応策：Fabric デザインレビューを行う • モデルサイズ・関係・集約・DAX の複雑さをレビュー • 高負荷ビジュアルを事前に指摘 • 本番デプロイ前に“容量・パフォーマンスの観点”でチェックする文 化を作る F4 アンチパターン：問題が生じやすいモデルや レポートがデプロイされる © 2026 Masatoshi Ohata
16. アンチパターン：改善が一度きりで終わり、継続的な見直しが行われ ない • 新しい問題が発生しても気づくのが遅れる • 古いモデル・設定・運用ルールがそのまま残る 対応策：F1〜F4 を定期的にレビューする仕組みを作る • 月次・四半期で容量メトリクス・利用状況・リフレッシュ履歴を確認 • 高負荷モデル・放置モデル・問題レポートを定期的に棚卸し • ワークスペース所有者・BI 担当者・データチームでレビュー会を行 う F5 アンチパターン：F1〜F4 の対策を継続的に運 用していない © 2026 Masatoshi Ohata
17. #02 2026-03-15 Japan Microsoft Data Platform User Group