🎯 Power BIを本格的に学びたい方へ
初心者から上級者まで、あなたのレベルに合わせたソリューションをご用意
ハンズオンセミナー
基礎編
Power BIの基礎を1日でマスター。データ取り込みから可視化まで実践形式で学べます。
- データ取り込みの基本
- レポート作成の流れ
- 基本的なビジュアル作成
Power BI 導入支援・構築
コンサルティング
経験豊富なコンサルタントが、御社の課題に合わせたPower BI導入を全面サポート。
- 大手から中小まで30社以上の導入実績
- 延べ3,000名以上のセミナー開催実績
- 課題ヒアリングから運用定着まで伴走
Power BIでレポートを作っていると、ある時点で「行に番号を振りたい」「表示順を固定したい」「同じグループの中で1番目、2番目を作りたい」「前の行と比較したい」といった要望が必ず出てきます。こういう場面で登場するのがインデックス列です。
ただし、Power BIのインデックス列には複数の作り方があり、目的に合わない方法を選ぶと、数字が合わない、並びが安定しない、更新が遅い、リレーションが壊れる、といったトラブルにつながります。特に「DAXでインデックス列を作る」場合は、Power BIが基本的に“行の順番を持たない”世界で動いていることを理解しておく必要があります。
この記事では、power bi インデックス列 daxを中心に、Power Queryで作る場合との使い分け、よくある用途、よくある失敗、安定させるコツを、できるだけ分かりやすく整理します。
インデックス列が必要になる代表的な場面
インデックス列が欲しくなるのは、だいたい次のパターンです。
-
並び順を固定したい
月名を4月始まりで並べたい、ステータスを「新規→提案→見積→受注」の順にしたい、カテゴリを任意の順で出したい、など。 -
同じグループの中で順番を付けたい
顧客ごとの購入履歴に1番目、2番目を付ける。社員ごとの異動履歴に時系列の番号を付ける。チケットごとのステータス遷移に順番を付ける、など。 -
直前の行と比較したい
前回購入から何日空いたか、前回のスコアとの差分、直前イベントからの経過時間、など。 -
上位N件や最新1件を取りたい
顧客ごとの最新購入1件だけ、設備ごとの直近点検1件だけ、案件ごとの最終ステータスだけ、など。 -
テーブルやマトリクスで「行番号」を表示したい
見た目の要望として「1行目から番号を振ってほしい」というケース。
この中で、どれに当てたいかで、Power Queryで作るべきか、DAXで作るべきかが変わります。
まず押さえるポイント：DAXには“行の順番”がない
DAXは基本的に「表の集合に対して計算する」仕組みで、Excelのように「上から下へ順番に処理する」世界とは違います。つまり、テーブルに見えている並び順は、あくまで表示上の並びであって、DAXがそれを前提に“次の行”“前の行”を認識しているわけではありません。
そのため、DAXでインデックス列を作るときは必ず、
どの列を基準に順番を決めるのか
同じ値（同点）が出たらどうするのか
を明示する必要があります。
ここが曖昧なまま「なんとなく連番っぽいもの」を作ると、並びが変わったり、更新のたびに番号が入れ替わったり、想定外の重複が出たりします。
Power Queryで作るインデックス列と、DAXで作るインデックス列の違い
インデックス列は大きく2つの作り方があります。どちらが正しいというより、向き不向きがはっきりしています。
Power Queryで作るインデックス列が向くケース
・取り込み時に確定する連番が欲しい
・更新後もなるべく安定した番号が欲しい
・結合や参照で使う“固定のキー”が欲しい（ただし注意あり）
・大量データで、DAX計算を重くしたくない
・DirectQueryで無理にDAXを複雑化したくない
Power Queryのインデックスは、データの並び（ソート）を確定させてから付与すると、同じ入力に対しては比較的安定します。ただし、元データの並びや抽出条件が変われば当然変わります。インデックスはあくまで派生列なので、「将来も永久に同じ値であり続ける保証」を期待しないのが安全です。
DAXで作るインデックス列が向くケース
・特定の並び基準で順位や順番を付けたい
・グループごとに連番を付けたい（顧客ごと、案件ごとなど）
・同じデータでも、集計の切り口に応じて順序や比較を変えたい
・最新1件や上位N件を取りたいロジックを作りたい
DAXで作る“インデックスっぽい列”の正体は、多くの場合「順位（Rank）」です。順位は基準列が変わると変動するのが自然で、そこを理解して使うと非常に強力です。
DAXでインデックス列を作る基本パターン
ここからは、実務でよく使うDAXパターンを用途別に紹介します。どれも「基準列を明確にする」ことがポイントです。
パターン1：全体で連番っぽい順位を付ける（基準列が1つ）
例：日付が古い順に1,2,3…を付けたい
考え方はシンプルで、Factテーブル全体（ALL）に対してDateで順位を付けています。Denseを使うと、同じ日付が複数あった場合に同じ順位になり、その次は飛び番になりません。
注意点として、同じDateが複数行あると順位が重複します。重複が困る（完全な一意連番が欲しい）場合は、次のパターンが必要です。
パターン2：同点回避して一意の順番を作る（2段ソート）
例：Dateが同じ行があるので、IDで同点を崩したい
これは「自分より前に来る行が何行あるか」を数えて+1する方法です。Dateが同じ場合はRecordIDで順序を決めます。こうすると、Dateが同じでもRecordIDで一意に順番が決まるため、連番が安定します。
ただし、この書き方はデータ量が大きいと重くなりやすいです。100万行級で多用するより、必要なテーブルだけに絞る、あるいはPower Query側で整備する方が現実的なこともあります。
パターン3：グループ内のインデックス（顧客ごとの購入順など）
例：顧客ごとに購入日順の1,2,3…を付けたい
これで「同じCustomerIDの中だけ」で順位が付きます。顧客別の購入回数やリピート分析などでよく使います。
注意点は、OrderDateが同じ場合に順位が重複することです。重複が困るなら、OrderDateに加えてOrderIDなどの同点回避キーを使う設計にします。
パターン4：グループ内で一意の順番（同点回避付き）
例：顧客内で購入日が同じ行も含めて一意にしたい
これで顧客ごとに完全な連番になります。イベントログや履歴テーブルで「順番が重複すると困る」場合に効きます。
インデックス列を使った実務テクニック
DAXでインデックス列を作れるようになると、次のような分析が作りやすくなります。
最新1件だけを抽出する（グループごと）
顧客ごとの最新購入、案件ごとの最終ステータス、設備ごとの最新点検など。
考え方は、グループ内の順位を降順で付けて、1だけ残す、です。
この列が1の行が最新です。同点があるなら同点回避キーを入れます。
前回との差分を作る（前回購入日、前回スコアなど）
「直前の行」を参照したい場合は、インデックスがあると考えやすくなります。たとえば、顧客ごとの購入順インデックスがあるなら、インデックスが1つ小さい行の値を探します。
ただし、DAXで“前の行”を取るのは簡単そうで難しく、テーブルが大きいと重くなりがちです。実務では次の方針が安全です。
・差分が頻繁に必要なら、可能ならデータソース側で前回値を持たせる
・Power Queryでグループ化や並べ替えをして前回値列を作る
・DAXでやるなら、対象を限定し、同点回避キーまで含めて一意にする
DAXで前回を取る典型は「自分のインデックス-1の行をフィルターして参照する」考え方ですが、実装はデータ量によって工夫が必要です。
並び順を固定する（カスタム順）
ステータスやカテゴリを任意の順に並べたいときに、インデックス列（順序列）を作って「列で並び替え」を使います。
例：ステータステーブルに
・Status（表示用）
・StatusOrder（順序）
を用意し、StatusをStatusOrderで並べ替えます。
この順序列はDAXで作るより、素直にマスタとして持つ方が安定しやすいです。DAXで無理に順序を作ると、条件が増えたときに壊れやすくなります。
よくある落とし穴と対策
power bi インデックス列 daxでつまずきやすいポイントを、原因と対策でまとめます。
落とし穴1：インデックスが毎回変わる
原因はだいたい次のどれかです。
・順番の基準列が曖昧（同点が多いのに同点回避がない）
・ALLやFILTERの範囲が意図と違う（想定より広い、狭い）
・キー列が安定していない（更新のたびにIDが変わるなど）
対策は、必ず並びの基準を決め、同点回避キーまで含めて一意にすることです。もし安定性が最重要なら、DAXではなくデータソース側でキーを付与する方が安全です。
落とし穴2：順位が重複して困る
RANKXのDenseは重複を許します。日付だけ、金額だけなどで順位付けすると、同点が発生するのは自然です。
重複が困る場合は、
・同点回避キーを追加して順位付けする
・COUNTROWS方式で一意連番を作る
のどちらかにします。
落とし穴3：インデックス列が重くて更新が遅い
DAXの計算列は、更新時に全行分を計算します。大きなテーブルで、ALLを使ったFILTERやCOUNTROWSを多用すると、更新が重くなります。
対策は次の順です。
・まずPower Queryで作れるならそっちに寄せる
・DAXで必要なら、テーブルを分ける（必要な粒度の表を作る）
・同点回避が必要な場合でも、IDや日時を工夫してRANKXで済む形にできないか考える
・どうしても重いなら、そもそも分析要件を見直し、集計済みテーブルで代替する
落とし穴4：DirectQueryでインデックス列をDAXで作ってしまう
DirectQueryは裏側でクエリに変換されるため、複雑なDAX計算列や順位計算が想定以上に重くなったり、そもそも制約で作りにくかったりします。
DirectQueryでインデックスが必要なら、基本はデータソース側（SQLなど）でROW_NUMBERのような形で作る方が安定します。どうしてもPower BI側でやるなら、用途を限定し、集計側で吸収できないかを検討するのが安全です。
落とし穴5：インデックスをリレーションのキーにしてしまう
インデックスは派生列で、データの追加・削除・並び基準の変化で値が変わり得ます。これをキーにすると、関係が壊れたり、昨日まで合っていた数字がズレたりします。
リレーションのキーが必要なら、業務的に意味のあるID、またはデータソース側で保証されたサロゲートキーを使う方が安全です。どうしてもPower BI内で作るなら、値が変わらない条件を明確にしてからにします。
インデックス列を作る前に決めておくと失敗しないこと
最後に、インデックス列づくりで迷ったときの判断軸をまとめます。
-
何のためのインデックスか
並び替えか、グループ内の順番か、前回比較か、最新抽出か。目的で最適解が変わります。 -
何を基準に順序を決めるか
日付なのか、更新時刻なのか、IDなのか、金額なのか。基準列を先に決めます。 -
同点が起きたらどうするか
同点を許容するか、一意にするか。一意にしたいなら同点回避キーまで設計に含めます。 -
どこで作るか
安定性と性能を重視するならPower Queryやデータソース側。分析ロジックとして順位が欲しいならDAX。 -
データが増えたときの負荷を許容できるか
DAX計算列は更新時に全行計算です。将来200万行、500万行になったときも回るかを想像しておくと手戻りが減ります。
まとめ
power bi インデックス列 daxは、うまく使うと「履歴の順番」「最新抽出」「前回比較」「並び替え」などが一気に作りやすくなり、分析の幅が広がります。一方で、DAXは行の順番を前提にしないため、基準列と同点回避を決めないまま作ると、番号が変わる、重複する、重い、といった問題が起きやすいです。
安定した連番が欲しいならPower Query側で作る
グループ内の順番やランキングが欲しいならDAXで作る
同点があるなら同点回避キーを必ず用意する
インデックスをキーにしてリレーションを組むのは慎重にする
この4点を押さえておけば、インデックス列はトラブルの元ではなく、現場で使えるレポートを作るための強力な部品になります。
こんな課題がある場合はご相談を
- 「既存のデータ構造が複雑すぎて、うまくモデル化できない」
- 「DAX の高度な使い方がわからない」
こういったお悩みをお持ちの方も多いのではないでしょうか。
Power BI の導入・活用でお困りの際は、ぜひ無料相談をご利用ください。
もし困り事があるなら、まずは無料相談はこちら
コンサルサービスの詳細や成功事例なども合わせてご紹介いたします。
社内にデータ活用のノウハウや専門人材が十分いない場合でも、弊社が伴走しながら最短ルートで成果を出せるようサポートいたします。
セマンティックモデルを活かすためのスキルアップ
📊 Power BIでより効率的なレポート作成を！
DAX 関数をマスターして、実務で使えるスキルを身につけませんか？
Power BIハンズオンセミナー中級編では、短時間でデータモデリングのノウハウを学び、ビジネスに活かせるレポート作成を実践形式で習得できます。
- 少人数制のため、定員になり次第締切！
👉 セミナー詳細を今すぐチェック
📈 Power BIスキルを次のレベルへ！
DAX関数 × データモデル設計 で、複雑なデータ分析やレポート作成もスムーズに！
Power BIハンズオンセミナー中級編 なら、実践形式で学べるから即戦力に。
業務効率をアップし、社内での評価を高めるチャンス！
- 今こそスキルアップのタイミング！
👉 詳細はこちら
セマンティックモデルを最大限に活用するためには、DAX やデータモデル設計の知識が欠かせません。レポートの正確性やパフォーマンスを大幅に改善できるため、学んでおいて損はない分野です。
コメント