「power bi 100万行」を扱うと聞くと、まず不安になるのが「そもそも動くのか」「更新が終わらないのでは」「レポートが重くなって使い物にならないのでは」という点です。結論から言うと、100万行そのものは珍しくありません。ただし、行数だけ見て設計すると失敗しやすいのも事実です。実際に遅くなる原因は、列の多さ、文字列の多さ、ユニーク値の多さ、変換の仕方、モデルの組み方、メジャー、ビジュアル数などが複合して起きます。
この記事では、100万行規模でつまずきやすいポイントを整理しつつ、Power BIで現実的に運用できる形に落とし込むためのコツを、わかりやすくまとめます。数値の上限暗記ではなく、考え方と手順に寄せて説明します。
1. 100万行で遅くなるのは「行数」より「形」と「使い方」
同じ100万行でも、軽いデータと重いデータがあります。違いは主にここです。
・列が多いほど重くなる
100万行でも列が10本なら軽く、列が200本だと更新もメモリも厳しくなります。使わない列を持ち込むほど、圧縮も効きにくくなります。
・文字列が多いほど重くなる
数値や日付は圧縮しやすい一方、長いテキストや自由入力の列、IDのようなユニークな文字列は圧縮しづらく、モデルサイズと速度に効いてきます。
・高カーディナリティ（ユニーク値が多い）列が多いほど重くなる
注文ID、取引ID、ログのタイムスタンプ、メールアドレスなど、ほぼ全部が別値の列が多いと、辞書圧縮が効きづらく、集計やスライサーも重くなります。
・明細を大量に表示するほど重くなる
100万行をテーブルでそのまま見せる、検索や並べ替えを多用する、列を大量表示する。これが一番体感を悪くしやすい使い方です。
まずは「100万行だから無理」ではなく、「100万行のどの列を、どんな粒度で、どう見せるか」を決めるところから始めるのが近道です。
2. まず決める：取り込み方式はImportか、DirectQueryか、併用か
power bi 100万行を扱うとき、最初の分岐が取り込み方式です。ざっくり考え方は次の通りです。
・Import（インポート）
データをPower BI側に取り込んで圧縮して持つ方式です。画面操作が軽くなりやすく、レポートの体感を作りやすいのがメリットです。一方で、更新時間とデータセットサイズ、更新の仕組みを考える必要があります。
・DirectQuery
画面操作のたびにデータソースへ問い合わせる方式です。最新性は取りやすいですが、DB側の性能、ネットワーク、モデル設計、DAX次第で急に遅くなります。閲覧者が増えるほどDB負荷も増えやすいので、運用設計が重要です。
・併用（複合モデル）
よく使う小さなテーブル（ディメンション）はImport、巨大な明細（ファクト）はDirectQuery、または「集計はImport・明細はDirectQuery」といった分け方です。100万行規模では、この発想が効きやすい場面があります。
迷ったら、まずはImportで体感を作り、更新が厳しい場合に「更新の工夫」や「集計の導入」で解決できないかを見て、それでも難しい部分だけDirectQueryに寄せる、という順番が失敗しにくいです。
3. 最初に効くのは「不要な列を捨てる」：100万行×列数が最重要
100万行対策で、最初にやる価値が高いのはこれです。
・レポートで使わない列は読み込まない
「いつか使うかも」で持ち込む列が増えるほど、更新が遅くなり、モデルも重くなります。必要になったら追加する、くらいの割り切りが現実的です。
・説明用の長文列、備考、自由入力は原則別扱い
自由入力テキストは圧縮しづらいです。検索用途や詳細用途なら、Power BIで常に持たず、別の参照手段に分ける設計も検討します。
・キーはできるだけ数値（サロゲートキー）に寄せる
文字列キーは結合や辞書圧縮の面で不利になりやすいです。データソース側で数値キーを用意できるなら、その方が扱いやすい場面が多いです。
「行数を減らす」より先に「列を削る」「型を整える」「テキストを減らす」。これだけで更新時間が目に見えて変わることがよくあります。
4. Power Queryでの変換は「早い段階で絞る」「折りたためる変換を優先」
100万行をPower Queryで加工するときは、変換の順序と内容が重要です。
・最初に行フィルター、次に列削除
不要な期間や不要な区分があるなら、できるだけ早くフィルターして行数を落とします。その次に列削除です。逆に、後段でフィルターすると、それまでの重い処理が100万行に対して走ってしまいます。
・ソース側へ処理を押し返せる形にする
データソースがDBなら、可能な限りDB側で処理が完結する変換に寄せます。Power Query側で行ごとのカスタム処理を増やすほど更新が重くなります。
・結合（マージ）やグループ化は慎重に
100万行の明細に対して複数回の結合やグループ化を行うと、更新時間が跳ねやすいです。結合が必要なら、結合先のキーが整っているか、結合回数を減らせないか、前処理で済ませられないかを確認します。
Power Queryは便利ですが、100万行規模では「便利な変換を積み重ねるほど遅くなる」ことが起きやすいので、変換は必要最小限に絞るのがコツです。
5. モデル設計はスター型が基本：100万行では特に差が出る
power bi 100万行を扱うとき、モデルが崩れていると、DAXもSQLもビジュアルも全部重くなります。基本はスター型です。
・真ん中にファクト（明細）
例：売上明細、勤怠ログ、アクセスログなど
・周りにディメンション（マスタ）
例：日付、商品、顧客、店舗、部署、担当者など
・関係は原則「1対多」「単方向」
多対多や双方向フィルターは便利ですが、クエリが複雑化しやすく、パフォーマンスが読みにくくなります。必要性がはっきりしている場合にだけ使うのが安全です。
また、ディメンションは「値の種類が多すぎない」状態が理想です。たとえば顧客IDのようなユニーク値はディメンションでも高カーディナリティになりますが、スライサーに置くのは避け、地域や業種など、絞り込みやすい属性を持たせて使うと体感が良くなります。
6. 更新が重いなら「インクリメンタル更新」を最優先で検討する
100万行クラスで運用がきつくなる代表が更新時間です。全件更新を毎回回すのは、データ量が増えるほど破綻しやすいです。
ここで効くのが、期間で分割して更新対象を絞る考え方です。例えば、過去分は固定として持ち、直近数日〜数か月だけ更新する。これができると、更新時間が安定します。
実務での設計例
・売上明細：過去3年保持、更新は直近14日だけ
・勤怠ログ：過去2年保持、更新は当月だけ
・アクセスログ：過去90日保持、更新は直近7日だけ
ポイントは、日付列が信頼できること、データの遡り更新がどの程度発生するか（遡って修正が入る業務か）を踏まえて「更新する範囲」を決めることです。
7. 体感を上げる最強手段：集計テーブルで「普段は集計、必要なときだけ明細」
100万行をそのまま触らせると、どうしても重くなります。そこで発想を変えて、普段は集計済みのテーブルを当てる設計にします。
例
・明細：日付×店舗×商品×取引ID（100万行）
・集計：日付×店舗×商品カテゴリ（数万行〜数十万行）
普段のグラフやKPIは集計テーブルで十分です。ユーザーが「この店舗のこの日が気になる」となったときだけ、ドリルスルーで明細へ落ちる。こうすると、普段の操作が軽くなり、必要なときだけ重い処理を許容する設計になります。
さらに、集計テーブルをうまく設定すると、ユーザーは意識せずに高速な集計が使われ、明細が必要な場面だけ詳細側にフォールバックする構成が作れます。
8. DAXは「反復を減らす」「DISTINCT系に注意」「同じ計算を繰り返さない」
100万行のファクト上で、重いDAXを回すと一気に遅くなります。特に注意したいのは次です。
・SUMXなどのイテレーターを安易に使わない
行をなめる計算は、100万行で効いてきます。可能なら、単純集計（SUMなど）に寄せたり、前計算で列を用意したり、粒度を上げてから計算する方向を検討します。
・DISTINCTCOUNTは高カーディナリティで重くなりやすい
ユニーク値が多い列でのDISTINCTCOUNTは負荷が上がりがちです。要件が許すなら、集計済みを用意する、粒度を上げる、別の指標で代替するなどが効きます。
・同じ式を何度も書かない
メジャー内で同じ計算を繰り返すと無駄が増えます。変数を使って一度だけ計算し、使い回すと安定しやすいです。
DAXは「正しい結果が出る」だけでなく、「何回どの粒度で計算しているか」を意識すると、急に速くなることがあります。
9. レポート（可視化）側で遅くなる典型：ビジュアル数、相互作用、明細テーブル
「データは問題ないのに重い」場合、可視化の作りが原因のことが多いです。特にpower bi 100万行でやりがちな落とし穴は次です。
・1ページにビジュアルを置きすぎる
ビジュアルが増えるほど、クリック1回で更新される対象が増え、体感が悪化します。概要ページは絞り、詳細は別ページに分けるのが定石です。
・相互作用を全部オンにしている
クロスフィルターやハイライトは便利ですが、クエリ連鎖を起こしやすいです。本当に必要な組み合わせだけ残すと軽くなります。
・明細テーブルを最初から大量表示する
明細は「条件が揃ったら表示」「上位N件だけ表示」「列を絞る」「ドリルスルーで別ページ表示」など、見せ方を工夫するだけで体感が改善します。
100万行を扱うレポートは、「普段は軽い操作で済む導線」を作るのが勝ちです。ユーザーが毎回重い画面を触らない設計にします。
10. 実務での進め方：最短で効かせるチェックリスト
最後に、100万行で詰まったときの進め方を手順にします。全部やる必要はなく、ボトルネックから当てていきます。
手順1：列を削る
使わない列、長文テキスト、高カーディナリティの不要列を最優先で削ります。
手順2：モデルをスター型に寄せる
多段結合や多対多、双方向を減らし、関係を単純化します。
手順3：更新を軽くする
期間で更新を絞る発想を入れ、全件更新を避けます。更新対象が減るだけで安定します。
手順4：集計テーブルを作る
普段の閲覧を集計で受けると、体感が大きく変わります。明細は必要時だけにします。
手順5：ビジュアルを整理する
1ページのビジュアル数、相互作用、明細の見せ方を見直します。
手順6：重いDAXを見直す
イテレーター、DISTINCT系、繰り返し計算を疑い、粒度を上げるか前計算を検討します。
まとめ
power bi 100万行は、行数だけなら珍しくない一方で、設計を誤ると更新が長くなり、レポートが重くなり、現場で使われなくなります。うまく扱うコツは、行数を恐れるより「列を削る」「モデルをスター型にする」「更新を絞る」「集計で普段を軽くする」「明細は必要時だけ」「可視化を絞る」という順番で整えることです。
まずは、不要な列の削除と、明細の見せ方の見直しから始めるのがおすすめです。ここはデータソースを大きく変えなくても改善しやすく、効果が出るまでが早いからです。そのうえで更新や集計の設計に踏み込むと、100万行でも“日常的に使える”Power BIに仕上げやすくなります。
コメント