Power BI の容量計画: プレミアムとファブリックのサイジング

間違った Power BI 容量層の選択は、組織が犯し得る分析上の最も大きなミスの 1 つです。サイズを小さくすると、ピーク時にスロットリングが発生し、クエリが遅くなり、更新エラーが発生します。過剰なサイジングは、1 日のほとんどの時間アイドル状態にあるコンピューティングに代償をもたらします。適切な容量を確保するには、Power BI がコンピューティング リソースをどのように使用するか、ワークロードが実際に要求しているものは何か、SKU オプションがそれらの要求にどのように対応しているかを理解する必要があります。

このガイドでは、コンピューティング モデルの理解から現在の使用率の監視、新しい展開のサイジング、自動スケールによるコストの管理まで、Power BI Premium と Microsoft Fabric の容量計画について説明します。

重要なポイント

• Power BI Premium の容量は、メモリとコンピューティング スループットを制御する仮想コア (v-core) で測定されます。
• Microsoft Fabric は、基本的な請求単位としてキャパシティ ユニット (CU) を使用し、SKU 階層を置き換えます。
• バックグラウンド ワークロード (データセットの更新) と対話型ワークロード (クエリの実行) が容量リソースをめぐって競合する
• キャパシティ メトリック アプリは、リソースの使用状況を理解するために不可欠な監視ツールです
• 24 時間にわたる CPU の平滑化により、バーストが平均化される - 短いピーク期間がすぐにスロットリングを引き起こすことはありません
• 自動スケール (Premium Gen2) は、ピーク時にコンピューティングを自動的に追加し、需要が低下するとコンピューティングを削除します。
• データセットのメモリ消費は、容量のパフォーマンス低下の最も一般的な原因です
• 適切な容量計画には、サイジングの前にベースライン測定が必要です

---

Power BI プレミアム容量モデル

Power BI Premium は、Pro ワークスペースで使用される共有インフラストラクチャから分離された専用のコンピューティング リソースを提供します。この分離により、他の Power BI テナントが何を行っているかに関係なく、一貫したパフォーマンスが実現されます。

リソース モデル: プレミアム容量は、仮想コア (v-core) で測定されます。各仮想コアは、特定の量のメモリと CPU コンピューティングを提供します。仮想コアと機能の関係によって、その容量が同時に処理できるワークロードが決まります。

Microsoft Fabric は、P-SKU モデルをファブリック キャパシティ ユニット (CU) に置き換えます。ファブリック F64 は P1、F128 は P2 とほぼ同等です。ファブリック モデルでは、よりきめ細かいサイジングと従量課金制 (一時停止/再開) が可能になり、多くの場合、P-SKU の月次サブスクリプションよりもコスト効率が高くなります。

(価格はおおよその米ドルです。実際の価格は地域および交渉された協定によって異なります。)

---

ワークロード カテゴリ

Power BI の容量は 2 つのカテゴリのワークロードを処理し、同じコンピューティング リソースをめぐって競合します。

バックグラウンド ワークロードはユーザーの介入なしで実行されます。

• データセットの更新 (インポート モードの更新)
• データフローの更新
• AI ワークロード (モデル トレーニング、推論)
• サブスクリプションによってトリガーされるページ分割されたレポートのレンダリング
• エクスポート操作

対話型ワークロードはユーザーの対話に応答します。

• クエリの実行 (ユーザーがレポート ページを開く)
• DirectQuery/ライブ接続クエリ
• ダッシュボードタイルの更新
• ユーザーによってトリガーされたレポートのエクスポート
• 自然言語 Q&A

両方のタイプのワークロードが同じ仮想コアをめぐって競合する場合、キャパシティにはピークの重複を処理するのに十分なリソースが必要です。営業日中に 200 件の同時ユーザー クエリを処理しながら、夜間に 20 件のデータセット更新を同時に実行する容量は、両方のピークに合わせてサイジングする必要がある場合があります。

---

キャパシティ メトリクス アプリ

Microsoft Fabric Capacity Metrics アプリ (以前の Power BI Premium Capacity Metrics アプリ) は、容量の監視と計画に不可欠なツールです。 AppSource からインストールし、容量に接続します。

それが示す内容:

ワークロード タイプ別の CPU とメモリの使用率。使用率グラフは、時間の経過に伴う CPU 消費量を、対話型ワークロードとバックグラウンド ワークロードに分けて表示します。平滑化された線は、24 時間の平滑化された平均 (Power BI が調整の決定に使用するもの) を示します。

スロットル イベント: 24 時間平滑化された CPU が容量リソースの 100% を超えると、Power BI はバックグラウンド ワークロードのスロットルを開始します (更新の遅延)。平滑化のしきい値を大幅に超えると、対話型のワークロードも調整されます。メトリクス アプリには、スロットル イベントが期間と重大度とともに表示されます。

データセット メモリ: メモリ ウォーターフォールには、どのデータセットがメモリに読み込まれているか、データセットが消費するメモリ量、およびいつ削除されるかが表示されます。常にエビクションとリロードが行われるデータセット (「エビクション」数が多い) は、利用可能なメモリに対して大きすぎるため、ユーザーがクエリごとにデータセットがリロードされるのを待つため、遅延が発生します。

リソース消費量別の上位のデータセットとレポート: メトリクス アプリは、最も多くのリソースを消費しているデータセットとレポートを特定します。これらは、スケールアップする前の最適化の候補です。

監視すべき主要な指標:

---

新しいデプロイメントのサイジング

初めて Power BI Premium デプロイのサイズを設定するとき (既存のメトリック データなし)、見積もりプロセスでは次の入力が使用されます。

ステップ 1: ユーザーと使用パターンを数える

• Power BI レポートにアクセスするユーザーは合計何名ですか?
• ピーク時の同時ユーザー数はどれくらいですか? (通常、全ユーザーの 10 ～ 20%)
• 使用のピーク時間は何時ですか? (通常は午前 9 時から 11 時までと午後 2 時から 4 時までの営業時間)

ステップ 2: データセットのメモリ要件を見積もる

• 同時にアクティブになるすべてのデータセットの非圧縮サイズを合計します。
• 平均 VertiPaq 圧縮率 5:1 を適用してメモリ内サイズを推定します
• クエリ操作に 20% のオーバーヘッドを追加
• データセットの総メモリ要件 = ほとんどの実装における主要なサイズ制限

ステップ 3: 更新ワークロードを見積もる

• ピーク時に同時に更新する必要があるデータセットはいくつですか?
• それぞれの予想される更新時間はどれくらいですか?
• ピーク リフレッシュ リソース消費量 = (同時リフレッシュ数 × データセット リフレッシュごとの平均メモリ)

ステップ 4: DirectQuery/ライブ接続のスループットを追加する

• DirectQuery でレポートを使用するユーザーは何人いますか?
• 1 秒あたりの予想ピーククエリ数はどれくらいですか?
• SKU スループット制限と比較します (P1 は 30 DQ クエリ/秒を処理します)

サイズ計算の例:

500 人の Power BI ユーザーがいる組織:

• ピーク時の同時ユーザー数は 50 (全体の 10%)
• 15 個のアクティブなデータセット、非圧縮で平均 4 GB → メモリ内にそれぞれ ~0.8 GB = 合計データセット メモリ 12 GB
• 10 個のデータセットが夜間に同時に更新され、それぞれのデータセットが更新中に 2 GB を消費します = 20 GB の更新メモリ
• ピーク時の DirectQuery レポート ページ数 20 = ~5 クエリ/秒

分析: 32 GB ピーク メモリ (12 GB データセット + 20 GB リフレッシュ) + オーバーヘッド = P1 (25 GB) が必要となるため、厳しい可能性があります → P2 (50 GB) を検討してください。 DirectQuery のスループットは P1 の 30 qps 制限内にあるため、サイズの決定はメモリによって決まります。

P1 から開始し、メトリクス アプリで 30 日間監視すると、P2 が必要かどうかがわかります。

---

自動スケール構成

Power BI Premium Gen2 (およびファブリック) は自動スケールをサポートしています。つまり、需要がプロビジョニングされた容量を超えるとコンピューティング リソースが自動的に追加され、需要が低下するとそれらのリソースが削除されます。

プレミアム向け自動スケール (P-SKU): Power BI 管理ポータル → 容量設定 → プレミアム容量 → 自動スケールで構成します。追加できる仮想コアの最大数を設定します (P1 の場合は 1 ～ 71)。容量使用率が制限に近づくと、自動スケールによって仮想コアが段階的に追加されます。

自動スケール課金: 追加の v コアは、v コアごとのレートで 1 時間ごとに課金されます。ピーク時に 2 時間、8 個の仮想コアを追加する P1 では、16 仮想コア時間の料金が発生します。

ファブリックの自動スケール: ファブリックの容量は一時停止および再開が可能であり (開発/テストにとってコスト効率が高く)、購入した CU 制限内で拡張可能なバースト可能なコンピューティングを備えています。 Fabric は、従量課金制の価格設定とともに、予約 (大幅な割引のための確約された支出) もサポートしています。

自動スケールを使用する場合:

• 日々のピークが予測可能である (例: 月末の財務報告では通常の 3 倍の負荷が発生する)
• たまにしか必要としないピーク容量を永続的にプロビジョニングしたくない
• 予期せぬ需要の急増に備え、安全弁を使用してコストを予測できるようにしたい

自動スケールを使用しない場合:

• 継続的な高い使用率 (常に処理能力に達している) - 代わりに基本層をアップグレードします
• 非常に大きな 1 回限りのレポート レンダリングの負荷 - 自動スケールが十分に速く反応しない可能性があります
• 変動請求が受け入れられない厳しい予算制約

---

スケーリング前の容量の最適化

より大きな容量にアップグレードする前に、既存のワークロードを最適化してください。パフォーマンスの問題のほとんどは、お金をかけずに解決できます。

データセットの最適化:

• DAX Studio の VertiPaq Analyzer を実行して、削除または要約できる大きなテーブルと列を特定します。
• 未使用の列をチェックし、レポートで参照されずにメモリを消費しているかを測定します。
• データ型を最適化します (日付キーにはテキストの代わりに整数を使用し、フラグには文字列の代わりにブール値を使用します)
• 増分リフレッシュを適用して、リフレッシュ期間とリフレッシュ サイクル中のメモリ消費量を削減します。

レポートの最適化:

• レポート ページごとのビジュアルの数を減らす — 各ビジュアルは読み込み時に少なくとも 1 つの DAX クエリを生成します
• 価値の低いビジュアルを、より単純なクエリを生成するカードまたは KPI に置き換えます。
• 双方向のリレーションシップと、複数のストレージ エンジン クエリを生成する複雑な DAX を回避します。
• 多くの同様の計算列の代わりにフィールド パラメーターを使用する

更新スケジュールの最適化:

• 複数の大規模なデータセットが同時に更新されるのを避けるために、更新時間をずらします
• 優先度の低いデータセットをオフピーク時間にスケジュールする
• 増分更新を使用して、大規模なデータセットの更新ウィンドウを短縮します
• めったに使用されないデータセットの更新を一時停止または無効にします

---

マルチキャパシティ アーキテクチャ

大規模な組織では、ワークロードを分離したり、コストセンターを分離したり、地理的な冗長性を提供したりするために、複数の容量を使用することがあります。

一般的な複数容量パターン:

• 階層分離: P2 で実稼働、F8 で開発/テスト。開発の更新によって実稼働容量が消費されるのを防ぎます。
• ワークロードの分離: 財務部門は 1 つの P1、人事部門は別の P1 にあります。部門のワークロードが相互に影響を及ぼさないようにします。
• 地理的分布: 米国ユーザーは米国東部の容量、EU ユーザーは西ヨーロッパの容量。地域のユーザー集団の待ち時間を短縮します。
• コスト センターの分離: 各ビジネス ユニットには独自のキャパシティがあるため、正確なコスト チャージバックが可能になります。

クロスキャパシティに関する考慮事項: データセットとレポートは、特定のキャパシティに割り当てられたワークスペースに公開する必要があります。レポートでは、同じ容量内のデータセットのみを使用できます (または、パフォーマンスに影響する別の容量からインポートできます)。クロスキャパシティのデータ アクセス パターンを避けるために、公開する前にワークスペースとキャパシティーの割り当てを計画します。

---

よくある質問

エンタープライズで使用する場合の Power BI の最小容量レベルはどれくらいですか?

Power BI Premium P1 (または Fabric F64) は、ページ分割されたレポート、展開パイプライン、XMLA エンドポイント アクセス、AI 洞察、データフロー計算エンティティ、最大 400 GB のモデル サイズなど、エンタープライズ機能セットをすべてサポートする最小レベルです。小規模な組織または部門の実装の場合、ユーザーあたり月額 20 ドルの Power BI Premium Per User (PPU) により、容量のコミットメントを必要とせずにほとんどの機能が提供されます。開発とテストには、ファブリック F2 または F4 で十分です。

24 時間 CPU スムージングは容量計画にどのような影響を与えますか?

Power BI は、24 時間 CPU スムージング アルゴリズムを使用して、容量が過負荷になっているかどうかを判断します。高 CPU 消費量の短期間のバースト (大規模な更新は 30 分で完了) が発生しても、すぐにスロットルが発生するわけではありません。バーストは 24 時間枠で平均化されます。これは、ピークに合わせてサイジングする必要がなく、中程度のバースト ワークロードを処理できることを意味します。ただし、CPU の使用率が高い状態が続くと (3 時間以上の集中的なワークロード)、平滑化された平均がスロットルしきい値を超えます。瞬間的な最大値ではなく、持続的なピークのサイズです。

新しい展開には Microsoft Fabric が Power BI Premium よりも優れていますか?

2026 年の新しいエンタープライズ展開では、通常、ファブリックが推奨されるパスです。 Premium と同じ Power BI 機能に加え、追加のワークロード (データ エンジニアリング、データ サイエンス、データ ウェアハウス、リアルタイム分析)、より柔軟な課金 (一時停止/再開、予約)、および統合ガバナンス モデルを提供します。すでに長期契約で Premium P-SKU を利用している組織は、更新が経済的に合理的になるまで Premium を継続することが考えられます。すべての Power BI Premium コンテンツは Fabric と互換性があります。

ユーザー エクスペリエンスを低下させることなく容量コストを削減するにはどうすればよいですか?

最も効果の高いコスト削減手段は次のとおりです。(1) サイズアップする前にデータセットを最適化してメモリ フットプリントを削減する、(2) リソースの同時競合を防ぐために更新スケジュールをずらす、(3) 開発容量に対して一時停止/再開を伴うファブリックを使用する (営業時間内のみ料金が発生する)、(4) ピークに向けて永続的にプロビジョニングするのではなく、実稼働容量での自動スケールを有効にする、(5) アクティブ ユーザーなしで更新リソースを消費している未使用のレポートとデータセットのワークスペースを監査する。

Microsoft は容量の健全性のためにどのような監視ツールを提供していますか?

主要なツールは、Microsoft Fabric Capacity Metrics アプリ (AppSource で入手可能) です。 CPU 使用率、メモリ使用率、スロットリング イベント、データセット アクティビティ、クエリ パフォーマンス メトリックを提供します。さらに詳細な診断を行うには、XMLA エンドポイント (SSMS または表形式エディター経由でアクセス可能) を使用して、DMV (動的管理ビュー) にクエリを実行してリアルタイムのクエリ パフォーマンス データを取得できます。 Power BI REST API は、カスタム監視ダッシュボードの容量メトリックへのプログラムによるアクセスを提供します。

---

次のステップ

キャパシティ プランニングは、一度限りの決定ではなく、継続的なアクティビティです。適切な層から開始し、Capacity Metrics アプリを使用してアクティブに監視し、スケーリングする前にワークロードを最適化し、拡張を計画します。 Power BI Premium から最大限の価値を得ている組織は、容量管理をパフォーマンス エンジニアリングの規律として扱います。

ECOSIRE の Power BI パフォーマンス最適化サービス には、容量評価、ワークロード分析、サイジングの推奨事項が含まれます。現在の容量使用率を監査し、パフォーマンスを向上させるための最もコスト効率の高い方法を特定するには、お問い合わせください。