🎯 Power BIを本格的に学びたい方へ
初心者から上級者まで、あなたのレベルに合わせたソリューションをご用意
ハンズオンセミナー
基礎編
Power BIの基礎を1日でマスター。データ取り込みから可視化まで実践形式で学べます。
- データ取り込みの基本
- レポート作成の流れ
- 基本的なビジュアル作成
Power BI 導入支援・構築
コンサルティング
経験豊富なコンサルタントが、御社の課題に合わせたPower BI導入を全面サポート。
- 大手から中小まで30社以上の導入実績
- 延べ3,000名以上のセミナー開催実績
- 課題ヒアリングから運用定着まで伴走
Power BI を使い始めると、早い段階で「計算式を追加したい」という場面が出てきます。売上から粗利を出す、達成率を出す、前年比を出す、ランキングを作る、条件に応じてフラグを付ける、会計年度で累計を出す。こうした “あと一歩” の計算ができるようになると、レポートは一気に実務で使える形になります。
ただし、power bi 計算式 追加には選択肢が多いのが落とし穴です。Power Query のカスタム列で作るのか、DAX の計算列にするのか、メジャーにするのか。ここを間違えると、数字が合わない、合計行だけおかしい、更新が遅い、レポートが重い、同じ計算が乱立する、といった形で後から効いてきます。
この記事では、計算式を追加する場所の選び方から、よく使う計算の型、つまずきポイント、運用で壊れない作り方までを、できるだけ分かりやすくまとめます。
まず結論：計算式を追加する場所は3つある
Power BI で計算式を追加する場所は、実務では次の3択だと思って差し支えありません。
-
Power Query（取り込み・変換の段階）
データを取り込む前処理として、列を追加したり、型を整えたり、置換や結合、グループ化をしたりします。ここで作った列は、データモデルに取り込まれる “実データの一部” になります。 -
DAX の計算列（モデルの列として追加）
テーブルに列を追加し、各行ごとに計算結果を保持します。更新時に全行計算され、モデルサイズや更新時間に影響します。 -
DAX のメジャー（集計値として追加）
行ごとではなく、フィルターやスライサー、行列の粒度に応じて “その場で集計して返す” 計算です。レポートでの数値は基本的にメジャーで作るのが王道です。
迷ったら、まずはメジャーで作れないかを考えるのが失敗しにくいです。列を増やすほどモデルが重くなりやすく、運用で後悔しがちだからです。
選び方の早見表：どれで作るべきか
よくある要望を、どこで作ると安定しやすいかで整理します。
Power Query が向くもの
・取り込み時に確定する整形（前後スペース削除、全角半角統一、型変換）
・複数列の結合、分割、置換などの前処理
・カテゴリの付与（例：商品コードの先頭2文字で大分類）
・明細の行を減らすための事前集計（必要なときだけ）
・参照用マスタの作成（重複排除してディメンションを作る）
計算列が向くもの
・行ごとに一意に決まるフラグ（例：金額が0なら除外、ステータス判定）
・スライサーや軸で使う分類列（例：年齢帯、金額帯、ABC分類の区分）
・リレーションや並び替えに必要なキー（ただし “インデックスでキー” は慎重に）
メジャーが向くもの
・合計、平均、比率、達成率、構成比
・前年比、前年差、累計、移動平均
・ランキング、上位N、選択条件に応じた動的計算
・同じ列でもフィルターによって変わる集計（ほとんど全部これ）
「集計して見せたい」ならメジャー、「分類として使いたい」なら計算列、「データを整える」なら Power Query と覚えると判断が速くなります。
power bi 計算式 追加の手順（実務で迷わない流れ）
計算式を追加するときに、手戻りが減る順番があります。
-
目的を一文で言う
例：月次売上の前年比を出したい
例：案件のステータス順に並べたい
例：社員を年齢帯に分けたい -
その値は “行ごとに固定” か “集計で変わる” かを決める
固定なら計算列や Power Query、変わるならメジャー -
基準となるテーブルと粒度を確認する
売上明細に足すのか、日付テーブルでやるのか、商品マスタでやるのか
粒度がズレると、合計が合わない原因になります -
まずはシンプルに作って検算する
最初から複雑にしないで、まずは SUM や COUNT のメジャーで合うか確認します
合ったら比率や前年差に進みます -
表示に載せて、合計行と空白の挙動を確認する
合計行がおかしい問題は、ここで潰します
DAX メジャーでよく使う計算の型
ここからは、実務で出番が多い “型” をまとめます。計算式 追加の依頼の多くは、結局このあたりに収束します。
合計と件数の基本
売上金額の合計（列名は環境に合わせて読み替えてください）
件数（明細行数）
取引IDがある場合の件数
割り算は DIVIDE を使う
ゼロ除算や空白でエラーにしないための定石です。
条件分岐はまず IF、複雑なら SWITCH
たとえば「目標達成なら1、未達なら0」
区分が増えるなら SWITCH を使うと読みやすいです。
前年比・前年差（まず日付テーブルを前提にする）
前年比系は、日付テーブルがあること、日付テーブルが日付列でモデルの中心になっていることが前提です。
月次で前年比を出すだけならこれで十分なことが多いです。
累計（年度末を指定できる）
会計年度が4月始まりなら、年度末は 3/31 です。
構成比（全体に対する割合）
カテゴリ別売上の構成比など。
ALL の対象をどこまで外すかで意味が変わります。ここがずれると「思っていた構成比と違う」になります。
ランキング（上位Nや順位）
商品別の売上順位を作る例です。
上位Nだけ見せたい場合は、ビジュアルフィルターで順位 <= 10 のように使うと運用しやすいです。
計算列でよくある追加パターン（分類と並び替え）
計算列は “見せ方” のために必要になることが多いです。特に分類と並び替えは、列があると圧倒的に楽になります。
例：金額帯（ビン分け）
売上明細の金額を帯に分ける例です。
この列をスライサーに置くと、ユーザーが直感的に絞り込めます。
例：月名を正しい順に並べたい
月名 “1月, 2月…” は文字列だと並びが崩れるので、並び替え用の数値列が必要です。これは日付テーブルで持つのが定石です。
・MonthName（表示用：1月）
・MonthNo（並び替え用：1〜12）
表示用列を並び替え用列でソートします。
例：ステータスの順番を固定したい
案件ステータスを任意順で並べたい場合は、ステータス列と順序列を用意します。
・Status（例：新規、提案、見積、受注）
・StatusOrder（例：1,2,3,4）
Status を StatusOrder で並び替えます。こういう順序は DAX で無理に作るより、マスタとして持つ方が運用が安定します。
Power Query のカスタム列でやると強い場面
計算式 追加というと DAX に寄りがちですが、データの整形や品質改善は Power Query の方が得意です。ここを DAX でやろうとすると、列が増えてモデルが重くなりがちです。
よく効く例は次の通りです。
・キー列の正規化（前後スペース削除、ゼロ埋め、文字種統一）
・列の型を整える（日付を日付型、数値を数値型へ）
・不要列の削除（モデルの軽量化に直結）
・マスタの重複排除（1対多の1側を作る）
・簡単な派生列（コードの一部からカテゴリ抽出）
Power Query は更新時に実行されるので、変換が重すぎると更新時間が増えます。だからこそ、変換は必要最小限、早い段階で行数や列数を減らすのがコツです。
つまずきやすいポイント：合計が合わない、合計行だけ変
計算式 追加で最も多い相談が、合計が合わない問題です。原因の多くは、計算列とメジャーの混同、または “粒度” のズレです。
よくあるパターン
・明細行では合っているが、合計行が合わない
・率の平均を取ってしまっている
・行ごとの率を足し上げてしまっている
対策の基本
・率は、基本的に合計÷合計で計算する
・行ごとの率を作って平均するのは、要件が明確な場合だけにする
・合計行がおかしいときは、まずメジャーを疑うのではなく、意味として正しい集計になっているかを確認する
たとえば粗利率は、行ごとの粗利率を平均するのではなく、粗利合計÷売上合計が一般的です。
これなら合計行でも自然に合います。
メジャーを増やしすぎない運用のコツ
power bi 計算式 追加を繰り返すと、メジャーが増えて管理が辛くなることがあります。運用で効くコツをまとめます。
・命名規則を揃える
例：売上、売上前年、売上前年差、売上前年比、売上FYTD など
同じ系統が並ぶと探しやすいです。
・メジャー用のテーブルを作って整理する
実務では “Measures” のような空のテーブルを作り、メジャーはそこに集約すると見通しが良くなります。
・変数を使って読みやすくする
同じ計算を繰り返さず、意図が明確になります。
・似たメジャーは共通部品化する
たとえば “基礎売上” をひとつ作り、その上に前年比や累計を積み上げると、修正が楽になります。
性能面での注意（計算式を追加すると重くなる理由）
計算式を追加すると重くなる理由は、追加した場所で違います。
Power Query が重い
・更新時に変換が再実行される
・結合やグループ化、行単位の複雑処理が多いと更新が遅い
計算列が重い
・更新時に全行計算される
・列が増えるほどモデルが大きくなる
・高カーディナリティ列（ユニーク値が多い列）が増えるほど圧縮が効きにくい
メジャーが重い
・ユーザー操作のたびに再計算される
・複雑な反復計算（SUMX など）や DISTINCTCOUNT の多用で遅くなりやすい
・ビジュアル数が多いと計算回数が増える
性能を守る基本方針
・列は増やしすぎない（特に明細テーブル）
・集計して見せるならメジャー中心
・重いメジャーはページから隔離し、必要なときだけ見せる
・DirectQuery の場合は、複雑な DAX を増やすほど DB に重いクエリが飛びやすい
実務でよくある “追加したい計算式” の例と作り方の方針
最後に、現場でよく言われる要望を、どこで作るのが無難かの方針でまとめます。
・売上から粗利、粗利率を出したい
メジャー推奨（合計行が自然に合う）
・前年比、前年差、累計を出したい
メジャー推奨（日付テーブル前提）
・顧客を地域や業種で絞りたい
ディメンションの列として持つ（Power Query で整備が多い）
・ステータスを任意順で並べたい
順序列を持つ（マスタか計算列）、並び替え設定を使う
・IDの表記ゆれを直したい
Power Query 推奨（モデルに入れる前に正規化）
・上位Nを出したい
メジャーの順位＋ビジュアルフィルター推奨（運用が楽）
・フラグ列を作りたい（0円、未完了、期限超過など）
列として使うなら計算列、集計だけならメジャーでも可
データ量が大きいなら Power Query で前処理も検討
まとめ
power bi 計算式 追加は、レポートを実務仕様にするための中心作業です。ただし、どこで追加するかを間違えると、数字が合わない、合計行が変、更新が遅い、モデルが重い、といった形で後から効いてきます。
迷ったら次の順で判断すると失敗しにくいです。
・集計して見せたいならメジャー
・分類として使いたいなら計算列
・データの整形や品質改善は Power Query
さらに、最初はシンプルに作って検算し、合計行と空白の挙動まで確認してから育てていく。これを徹底すると、計算式を追加しても壊れにくい Power BI に育ちます。
もし困り事があるなら、まずは無料相談を
「DAX 関数が多すぎてどれを使えばいいか分からない」「複雑なロジックを組みたいけれど、エラーが出て解決できない」「会社全体で DAX を学習したい」など、Power BI やデータ活用でお悩みの方はぜひお気軽にご相談ください。
もし困り事があるなら、まずは無料相談はこちら
コンサルサービスの詳細や成功事例なども合わせてご紹介いたします。
社内にデータ活用のノウハウや専門人材が十分いない場合でも、弊社が伴走しながら最短ルートで成果を出せるようサポートいたします。
セミナーで学ぶ！DAX 関数の実践スキル
📊 Power BIでより効率的なレポート作成を！
Power BIハンズオンセミナー初級編では、短時間でデータモデリングのノウハウを学び、ビジネスに活かせるレポート作成を実践形式で習得できます。
- 少人数制のため、定員になり次第締切！
👉 セミナー詳細を今すぐチェック
📈 Power BIスキルを次のレベルへ！
DAX 関数 × データモデル設計 で、複雑なデータ分析やレポート作成もスムーズに！
Power BIハンズオンセミナー中級編 なら、実践形式で学べるから即戦力に。
業務効率をアップし、社内での評価を高めるチャンス！
- 今こそスキルアップのタイミング！
👉 詳細はこちら
DAX を使いこなすことで、Power BI の真価を最大限に引き出し、より高度な分析をスムーズに進めることができます。実践的な知識を身につけて、組織のデータドリブンな文化をリードしましょう。
コメント