Power BI の計算列がレポートのパフォーマンスを損ない、モデルのメモリを膨らませる理由

By Mirko Peters · 2026-10-29

Power BI の計算列を多用するとデータモデルのメモリが膨らみ、レポートのパフォーマンスが低下する理由を解説します。データモデルのアーキテクチャを最適化する方法も紹介します。

Automatically translated with AI from the original post. Read the English original

Power BI で計算列を誤って使うと、気づかないうちにデータモデルのメモリが膨らみ、レポートの描画時間が遅くなることがあります。動的なメジャーと異なり、計算列はデータの更新時にすべての行を評価して保存するため、貴重な RAM を消費し、ワークスペースのアーキテクチャ全体で処理負荷を増やします。

重要なポイント

• 計算列は、データの更新時に行ごとに値を計算し、その値をメモリに永続的に保存します。
• 計算列を多用すると VertiPaq の圧縮率が大きく低下し、ファイルサイズが大幅に膨らみます。
• 行コンテキストによって計算は静的に実行されるため、ビジュアル上のユーザーのフィルター選択はまったく反映されません。
• 列が多いデータモデルはスケールしにくくなります。特に大規模なエンタープライズの Microsoft Fabric 環境に組み込まれている場合にその傾向が顕著です。
• ストレージ負荷の大きい列からクエリ時に計算されるメジャーにロジックを移すと、システムの RAM を節約でき、レポートのパフォーマンスが向上します。

行レベル評価に隠れたメモリコスト

Power BI で新しいレポートを作成するとき、表示したいデータ項目ごとに計算列を作ってしまいがちです。利益率、氏名の連結、売上の区分などが必要になると、テーブルに列を追加するのが直感的に感じられます。Excel のスプレッドシートと同じように、データ ビューですぐに結果を確認できるからです。

しかし、Power BI は表計算ソフトではなく分析エンジンです。計算列を作成するたびに、データの更新処理中に VertiPaq データベース エンジンがテーブル内のすべての行についてその値を計算します。売上テーブルが 500 万行ある場合、新しい計算列はセマンティック モデルに 500 万件の個別の値を追加することになります。

さらに悪いことに、計算列はエンジンの圧縮アルゴリズムの働きを妨げます。VertiPaq は、カーディナリティが低い列、つまり同じ値が繰り返し現れる列に依存してデータを効率よく圧縮します。一意の値を持つ計算列はこの圧縮効率を損なうことが多く、モデルをメモリに常駐させるために必要な RAM が増大します。モデルが大きくなるにつれて、このメモリの肥大化は Microsoft クラウド上のワークスペースの容量制限を簡単に超えてしまいます。

静的なコンテキストがレポートの柔軟性を制限する仕組み

メモリ消費以外にも、計算列は評価コンテキストの扱い方によって大きな機能上の制約を生みます。計算列は厳密に行コンテキスト内で動作します。レポート キャンバス上のユーザー操作、スライサー、相互フィルターによる選択とは独立に、現在の行の値だけを評価します。

静的なしきい値に基づいて優良顧客にフラグを付ける計算列を作成すると、その分類はストレージ層に組み込まれてしまいます。後からユーザーがスライサーを変更して地域別にデータを表示したり、日付範囲を変更したりしても、計算列はそれらのフィルターを認識しません。値は前回の更新時に数時間前に計算・保存されているため、変化する集計の状態に動的に対応することはできません。

この厳格さは、ユーザーが現在適用しているフィルター コンテキストに基づいて、その瞬間に結果をその場で計算するメジャーとは対照的です。ユーザーがビジュアルを操作すると、メジャーは再計算され、文脈に応じた正確なインサイトを提供します。一方、計算列は RAM に格納された静的なデータをそのまま繰り返し示すだけです。

Microsoft Fabric と Azure 向けに、よりスリムなモデルを設計する

エンタープライズ クラウドのレポートでは高い効率性が求められます。特に Microsoft Fabric、Azure、そして複雑な Microsoft 365 のデータ環境全体に拡張する場合はなおさらです。肥大化したセマンティック モデルはインフラストラクチャのリソースを消費し、クエリの応答時間を遅くし、ダッシュボードの読み込みを待つビジネス ユーザーをいらだたせます。

レポートを最高の速度で動作させ続けるには、計算列の使用を、行レベルの値が本当に必須となる場面に厳密に限定してください。たとえば、複数のパラメーターに基づいてテーブル間のリレーションシップ キーを作成する必要がある場合や、メジャーが使えないスライサーや行レベルセキュリティ (RLS) のルールで値を使用しなければならない場合には、計算列を使う価値があります。

それ以外のすべての分析計算、たとえば合計、平均、比率、条件付き集計などは、ロジックをメジャーに移してください。メジャーはモデル内に値を保持しないため、ストレージ領域を一切消費しません。メジャーはコードとしてメモリに存在し、ビジュアルがデータを要求したときだけ実行されます。このアプローチにより RAM が節約され、圧縮率が最大化され、クラウド インフラストラクチャを円滑に稼働させ続けられます。

まとめ

行レベルのストレージと動的なクエリ実行の根本的な違いを理解することは、スケーラブルな分析ソリューションを構築するすべての人にとって重要です。不要な計算列を減らし、動的なメジャーを積極的に活用することで、レポートの速度を大幅に向上させ、メモリ消費を削減できます。

このテーマをさらに深く掘り下げ、エンジンが数式をどのように処理するかを専門用語を使わずに一通り解説した内容を知りたい方は、エピソード全編をお聴きください。M365 FM Podcast では、クラウド分析戦略に役立つ専門的な知見を今後も配信していきますので、ぜひご期待ください。

よくある質問

Power BI で計算列がメモリを大量に消費するのはなぜですか？

計算列は、データ更新のたびにすべての行を評価し、その値をモデルの RAM に恒久的に格納します。そのため VertiPaq エンジンがデータを効率よく圧縮できず、モデルが急速に肥大化します。

Power BI のセマンティック モデルでは、メジャーもストレージ領域を消費しますか？

いいえ、メジャーはストレージ領域を消費しません。メジャーはメタデータ内の数式定義として保存されるだけで、ビジュアルやユーザー操作によって計算が要求されたときにのみ動的に計算されます。

計算列を使うのが適切なのはどのような場合ですか？

計算列は、複合キーの作成によるリレーションシップの定義、行レベルセキュリティ (RLS) ルールの適用、静的なスライサー値として表示する必要がある項目の提供など、行コンテキストが必須となる特定の場面に限定して使用してください。

計算列はレポートの表示パフォーマンスにどのように影響しますか？

計算列が過剰に増えるとセマンティック モデル全体のサイズが大きくなり、データの圧縮効率が低下します。モデルが大きくなるほど多くのメモリと処理能力が必要になり、最終的にワークスペース全体でクエリの実行時間とレポートの読み込み時間が遅くなります。