DAX評価コンテキストを極める：Power BIはExcelとは違う

By Mirko Peters · 2026-08-13

従来の表計算ソフトからビジネスインテリジェンスツールへ移行する際、多くのアナリストが安易な落とし穴にはまります。データ分析式が標準的な表計算の数式と同じように動作すると思い込んでしまうのです。しかし、Power BIを巨大なブックのように扱うと、レポートが壊れたり、想定外の数値が表示されたり、大きなストレスにつながりがちです。現代の分析の可能性を本当に引き出すには、評価コンテキストの仕組みを習得する必要があります。本ガイドでは、セマンティックモデルで考え方の転換が必要な理由を探り、行コンテキストとフィルターコンテキストを解説し、データモデリングのスキルを高める方法を紹介します。

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

従来の表計算ソフトからビジネスインテリジェンスツールへ移行する際、多くのアナリストが安易な落とし穴にはまります。データ分析式が標準的な表計算の数式と同じように動作すると思い込んでしまうのです。しかし、Power BIを巨大なブックのように扱うと、レポートが壊れたり、想定外の数値が表示されたり、大きなストレスにつながりがちです。現代の分析の可能性を本当に引き出すには、評価コンテキストの仕組みを習得する必要があります。本ガイドでは、セマンティックモデルで考え方の転換が必要な理由を探り、行コンテキストとフィルターコンテキストを解説し、データモデリングのスキルを高める方法を紹介します。

Power BIにおける評価コンテキストの紹介

基本的に、Power BIは従来のセルベースのソフトウェアとは異なる方法でデータを扱う、強力なリレーショナルエンジンの上に構築されています。Data Analysis Expressionsで式を記述しても、数式が固定のセルや、上下の固定行を参照するわけではありません。代わりに、評価コンテキストと呼ばれる目に見えない環境の中で動作します。この環境を理解することは、レポート開発者にとって最も重要な節目の一つです。理解していないと、ビジュアルにフィールドを追加したときに数値がなぜ変わるのかを推測するしかなくなります。評価コンテキストを習得することで、基本的なレポート作成と、エンタープライズ向けの高度なビジネスインテリジェンスとの間のギャップを埋めることができます。

DAXを Excelのように扱うとレポートが壊れる理由

新しい開発者に最もよくある誤解は、数式が表計算のグリッドと同じく、上から下へ順番に計算されるというものです。表計算では、セルC2に数式を書くと、そのセルで行2を指定しているため、行2の値が評価されます。表計算の計算は静的で明示的です。

一方、Power BIの計算は動的で、文脈に依存します。メジャーは、参照先を指定されるか、周囲のビジュアルがそう決めない限り、自分がどの行にあるかを本来知っているわけではありません。メジャーをマトリックス、カード、または棒グラフに配置すると、ソフトウェアはその数式を目に見えない境界で囲みます。この境界の仕組みを無視すると、行の合計と一致しない総計や、計算結果を完全に消してしまうスライサーなど、典型的な落とし穴に遭遇します。セル参照中心の考え方から脱却することが、堅牢なセマンティックモデルを書くための第一歩です。

行コンテキストを読み解く：レコードごとの計算

評価コンテキストを習得するには、まずその二つの主要な構成要素、行コンテキストとフィルターコンテキストを理解する必要があります。まずは行コンテキストから見ていきましょう。簡単に言えば、行コンテキストは、一度に一つの特定のレコードに対して式を評価しているときに常に有効になります。

行コンテキストはどのような場合に現れるでしょうか。主に二つの場面があります。計算列を作成するときと、反復処理関数（一般に「X関数」と呼ばれ、SUMX、AVERAGEX、FILTERなど）を使用するときです。たとえば、数量と単価を掛けて「合計明細金額」という計算列を作成すると、Power BIはそのテーブルのレコードごとに行コンテキストを作成します。テーブルを一行ずつ順にたどり、その行に対して掛け算を評価し、結果を実際にモデル内に格納します。

ただし、計算列はメモリを消費し、ファイルサイズを増やします。そのため、上級の開発者はメジャーを好む傾向があります。SUMXのような反復処理関数を使用すると、プログラム的に一時的な行コンテキストを作成します。SUMXはテーブルを行ごとに処理し、各行で式を評価してから、その中間結果を合計します。行コンテキストを理解することで、計算を適切なタイミングで適用できます。つまり、静的な行単位の属性には列を、動的な集計にはメジャーを使うという使い分けです。

フィルターコンテキストを読み解く：ビジュアルとスライサーが結果を形づくる仕組み

行コンテキストが一度に1つのレコードだけを見るのに対し、フィルターコンテキストはより広い全体像を見ます。フィルターコンテキストとは、数式が評価される時点でデータモデルに適用されているすべてのアクティブなフィルターの集まりです。これらのフィルターは、レポートのスライサー、ページレベルのフィルター、ビジュアルの相互作用、行ヘッダー、そしてメジャー内で明示的に指定されたフィルター関数から生じます。

売上合計を計算する単純なメジャーを考えてみてください。このメジャーを空白のカードビジュアルに表示すると、フィルターコンテキストはデータモデル全体を含み、全期間の総売上が返されます。しかし、このメジャーと一緒に「地域」列を横棒グラフにドラッグしたとたん、フィルターコンテキストは大きく変わります。グラフの各バーについて、Power BI は特定の地域に対する非表示のフィルターを自動的に適用します。エンジンは、まず北米に属する行だけで売上メジャーを評価し、次にヨーロッパの行だけで評価する、という具合に処理を進めます。

フィルターコンテキストは、ダッシュボードに対話性と動的な変化をもたらす仕組みです。スライサーを使えば、ユーザーはこのコンテキストを即座に変更し、日付範囲、製品カテゴリ、顧客セグメントごとにデータを絞り込めます。CALCULATE のような強力な関数を使ってフィルターコンテキストを操作できるかどうかが、初心者のレポート作成者とセマンティックモデルの真のエキスパートを分ける要素です。

両者の橋渡し：高度な分析のための評価コンテキストの習得

行コンテキストとフィルターコンテキストの相互作用を理解できたら、より高度なビジネスロジックを構築できます。代表的な高度なパターンがコンテキスト遷移です。コンテキスト遷移は、行コンテキスト（計算列やイテレーター内など）の中で CALCULATE 関数を呼び出したときに発生します。CALCULATE が実行されると、現在の行コンテキストが、それと同等のフィルターコンテキストに自動的に変換されます。

これにより、「このテーブルの製品カテゴリごとに、特定の価格しきい値を超える製品の売上合計はいくらか」といった複雑な問いに答えられるようになります。KEEPFILTERS、ALLEXCEPT、変数などの関数を使ってフィルターの伝播を制御することで、計算の正確さと速度の両方を最適化できます。

さらに、クリーンなスタースキーマでモデルを適切に構造化すると、ディメンションテーブルからファクトテーブルへとフィルターコンテキストがスムーズに流れます。リレーションシップと評価コンテキストが調和して機能すると、レポートは速く読み込まれ、保守も容易になり、信頼できるビジネスインサイトを一貫して提供できるようになります。

Power BI 開発者のためのまとめと次のステップ

評価コンテキストを習得するには、時間と練習、そして表計算ソフトの習慣を捨てる意欲が必要です。行コンテキストが個々のレコードをどのように評価するか、フィルターコンテキストがビジュアルをどのように形作るかを理解すれば、セマンティックモデルを完全に制御できるようになります。このトピックをさらに深め、ビジネスインテリジェンスのアーキテクチャに関する専門家の見解を聞くには、関連するポッドキャストのエピソード Power BI DAX and Semantic Models with Bernat Agulló Roselló [MVP] をぜひチェックしてください。練習を続け、DAX Studio などのツールで数式をテストし、世界中のコミュニティと交流して、分析への道のりを加速させてください！