Power BI の計算列とメジャーの違い:平均単価で、合計が合わなくなる例

確認日2026年10月27日。Power BI Desktop 2.159.883.0(日本語、Windows)、ダミーのデータ6行で確かめました。確認できていないことは、末尾にまとめました。

「計算列」と「メジャー」は、どちらも DAX で作ります。どちらで作ればいいのか迷って、同じ計算を両方で作ってみたところ、合計の値が食い違いました。実機で確かめた結果と、公式の説明を、分けて書きます。

結論(30秒版)

「平均単価」を、計算列(行ごとに売上÷数量)と、メジャー(売上の合計÷数量の合計)で作ると、店舗ごとの値も、合計行の値も、食い違いました。合計行は、計算列の平均で 1,500.00、メジャーで 1,217.65 でした。

公式の説明では、計算列は行ごとに計算され、データの更新のときに計算されて、モデルに保存されるもの、メジャーは必要になったときに、集計の対象に合わせて計算されるものです。

比率や平均のように、「合計してから割る」計算は、メジャーで作るほうが、集計の結果と合いました。

公式の説明

Microsoft Learn の「Use calculation options in Power BI Desktop」では、次のように整理されています。

	計算列(DAX)	メジャー
計算されるとき	データの更新のとき	必要になったとき(on demand)
結果の保存	モデルに保存される	保存されない
評価の単位	行(行コンテキスト)	フィルター(フィルターコンテキスト)
レポートの操作で変わるか	変わらない	変わる
使える場所	スライサー、フィルター、行、列、軸	ビジュアルの値、ビジュアルレベルのフィルター

また、計算列は、更新のときの計算に時間がかかり、モデルのサイズが増える、とも書かれています。

使ったデータ

6行の CSV(練習問題で配っている sales_agg.csv)です。店舗(渋谷・新宿・京都)、商品コード、単価、数量、売上が入っています。

店舗	商品コード	単価	数量	売上
渋谷	1001	1,200	3	3,600
渋谷	1002	800	5	4,000
新宿	1001	1,200	2	2,400
新宿	1003	2,500	1	2,500
京都	1002	800	4	3,200
京都	1003	2,500	2	5,000

同じ「平均単価」を、2通りで作る

平均単価の列 = DIVIDE(sales_agg[売上], sales_agg[数量])

テーブルに「新しい列」で作ったものです(計算列)。行ごとに、売上÷数量を計算します。

平均単価の測り方 = DIVIDE(SUM(sales_agg[売上]), SUM(sales_agg[数量]))

「新しいメジャー」で作ったものです(メジャー)。売上の合計を、数量の合計で割ります。

実機で確かめた結果

同じ表で、計算列を「合計」で集計した場合(合計 9,000.00)と「平均」で集計した場合(合計 1,500.00)。メジャーはどちらも店舗ごとに 1,366.67・950.00・1,633.33、合計 1,217.65

店舗ごとの表に、2つを並べました。

① 計算列は、既定で「合計」になる

計算列を表に入れると、既定の集計は合計でした。店舗ごとの値は、その店舗の行の、平均単価の足し算です。

店舗	計算列(合計)	メジャー
京都	3,300.00	1,366.67
渋谷	2,000.00	950.00
新宿	3,700.00	1,633.33
合計	9,000.00	1,217.65

平均単価を、足し算しても意味がありません。計算列は、このままでは使えない値でした。

② 計算列を「平均」に変えても、メジャーとは合わない

値のウェルで、計算列の集計を「平均」に変えました。

店舗	計算列(平均)	メジャー
京都	1,650.00	1,366.67
渋谷	1,000.00	950.00
新宿	1,850.00	1,633.33
合計	1,500.00	1,217.65

「平均」にしても、食い違いました。計算列の平均は、行ごとの平均単価を、さらに平均したものです(渋谷の例: (1,200 + 800) ÷ 2 = 1,000)。メジャーは、売上の合計 7,600 を、数量の合計 8 で割ったものです(7,600 ÷ 8 = 950)。数量が多い行の重みが、メジャーでは効いて、計算列の平均では、効きません。

手計算でも、どちらも、この値になりました。

どちらを使うか

やりたいこと	向いているもの	理由(今回の結果から)
平均単価、比率、達成率のように、「合計してから割る」値	メジャー	集計の対象に合わせて、合計から計算し直すので、合計行も合う
行ごとの値を、スライサーや軸に使いたい(例: 金額帯の区分)	計算列	公式では、スライサー・フィルター・行・列に使えるのは、計算列(メジャーは値のみ)
「単価 × 数量」を行ごとに計算して、合計したい	計算列、または SUMX を使ったメジャー	別の記事で確かめました

この記事で確認できたこと・できていないこと

確認日: 2026年10月27日。Power BI Desktop 2.159.883.0(日本語、Windows、未サインイン、個人の環境)。

確認できたこと

同じ「平均単価」を、計算列とメジャーで作ると、店舗ごとも合計行も、値が食い違ったこと(上の表のとおり)。
計算列を表に入れると、既定の集計が「合計」になったこと。値のウェルで「平均」に変えられたこと。
手計算の値と、実機の値が、一致したこと。

確認できていないこと

公式の説明にある「計算列は、更新のときに時間がかかり、モデルのサイズが増える」ことの、実測(6行では測れません)。
スライサーで絞り込んだときの、計算列とメジャーの動きの違い。
DirectQuery や Power BI サービスでの動き。
Power Query のカスタム列(M 言語)との違いの実測。公式の表では、「更新のときに計算され、保存される」点で、計算列に近いと書かれています。

参考

Microsoft Learn: Use calculation options in Power BI Desktop — https://learn.microsoft.com/power-bi/transform-model/desktop-calculations-options
Microsoft Learn: Create calculated columns in Power BI Desktop — https://learn.microsoft.com/power-bi/transform-model/desktop-calculated-columns