Power Pivotの限界は何行？Excelが重い原因とPower BI移行の判断基準

こんにちは、SkillStack Lab運営者のスタックです。

Power Pivotで数百万行のデータを扱っていて、「更新に時間がかかる」「ファイルが重い」「メモリ不足で止まる」と悩んでいませんか。

そこで気になるのが、Power Pivotには何行まで入るのか、どこからPower BIやSQLへ移行すべきなのかという点ですよね。

最初に重要な結論をお伝えすると、「100万行を超えたからPower Pivotの限界」というわけではありません。

Excelのワークシートは1,048,576行までですが、Power Pivotが利用するExcel Data Modelでは、Microsoft公式仕様上、1つのテーブルに最大1,999,999,997行を保持できます。

つまり、Power Pivotが重くなる原因を「行数」だけで判断するのは危険です。

実務では、PCのメモリ、32bit・64bit版Excelの違い、不要な列、高カーディナリティの文字列、Power Queryの処理、DAX計算列、データモデルの設計などが組み合わさって限界が訪れます。

この記事では、元情シス・現役管理部門長の視点から、Power Pivotの本当の上限、ファイルが重くなる原因、移行前に試したい軽量化、Power BI・SQL・Pythonへ進む判断基準まで解説します。

Excel・Power BIの上限や利用できる機能は、Officeのバージョン、32bit・64bit、Microsoft 365の契約、Power BI/Fabricの容量などによって異なります。本記事は2026年8月時点のMicrosoft公式情報をもとに整理しています。

Power Pivotの限界は何行？公式仕様を確認

まず、「Power Pivotは何行まで使えるのか」を整理しましょう。

ここで混同しやすいのが、Excelワークシートの上限とExcel Data Modelの上限は別物だという点です。

対象	Microsoft公式上の主な上限
Excelワークシート	1,048,576行 × 16,384列
Excel Data Model	1テーブル最大1,999,999,997行
Data Modelの1列のユニーク値	最大1,999,999,997
Power Queryからワークシートへ出力	最大1,048,576行

参考：Microsoft「Data Model specification and limits」／Microsoft「Excel specifications and limits」

100万行はPower Pivotの限界ではない

「Excelは約104万行だから、Power Pivotも100万行程度まで」と考えてしまいがちですが、これは違います。

Power Pivotではデータをワークシートへ直接並べるのではなく、Excelブック内部のData Modelへ格納できます。

そのため、100万行を超えるデータでもモデルへ読み込み、ピボットテーブルで地域別・商品別・月別などに集計できます。

「保存できる行数」と「快適に処理できる行数」は別です。
約20億行という仕様上限まで実務で快適に使えるという意味ではありません。データの内容、列数、ユニーク値、PCメモリ、DAX、Power Queryなどによって実用上の限界は大きく変わります。

明細を100万行以上ワークシートへ並べることはできない

一方、分析結果ではなく数百万件の明細をそのままExcelシートへ展開したい場合は、ワークシートの1,048,576行という上限にぶつかります。

この場合はPower Pivotが悪いのではなく、出力先としてワークシートを選んでいることがボトルネックです。

大量明細を必要とする業務なら、次の方法を検討します。

• 必要な条件で絞り込んでからExcelへ出力する
• 月別・部門別などに明細ファイルを分ける
• CSVやデータベース側で保持する
• 集計・分析用にはPower PivotやPower BIを使う

Power Pivotは「数百万行を一覧表示するためのツール」というより、大量の明細をモデル内へ保持し、必要な切り口へ集計するための仕組みと考えると分かりやすくなります。

Power Pivotが重くなる本当の原因

Power PivotのData Modelには約20億行という仕様上限がありますが、実務ではそこへ到達するよりはるか前に、更新時間やメモリ不足が問題になることがあります。

32bit版Excelではメモリ制約を受けやすい

大きなData Modelを扱う場合、最初に確認したいのがExcelの32bit・64bitです。

Microsoftの現在の仕様では、32bit環境はExcel本体、ブック、同じプロセスで動くアドインなどが仮想アドレス空間を共有するため、大規模なData Modelではメモリ制約を受けやすくなります。

なお、「32bit Excelは必ず最大2GBまで」と単純に覚えるのも正確ではありません。

Excel 2016以降では、64bit Windows上の32bit ExcelにLarge Address Awareが適用され、利用できるメモリ領域が拡大します。

一方、64bit版Excelでは、Microsoftはファイルサイズに固定的なハード上限を設けておらず、利用可能なメモリとシステムリソースが実質的な制約になります。

大量データを本格的に扱うPCなら64bit Officeが候補ですが、既存アドイン、VBAのAPI宣言、社内システムとの互換性もあるため、勤務先では情シス担当者へ確認してから変更してください。

不要な列が多いほどモデルは肥大化する

Power Pivotでは「何行あるか」だけでなく、何列を読み込んでいるかが非常に重要です。

「後で使うかもしれないから」と元システムの列を全部読み込んでいないでしょうか。

MicrosoftもImportモデルの軽量化策として、レポートやモデル構造に必要ない列を削除することを推奨しています。

• 分析で使わない備考欄
• 一度も表示しない自由記述テキスト
• 意味なく重複している名称列
• 不要な内部管理ID
• 使っていないタイムスタンプ
• 元データ側で再取得できる不要列

特にユニーク値の多い文字列は圧縮効率が落ちやすいため、データモデルを肥大化させる原因になります。

高カーディナリティの列は圧縮効率が悪くなる

Power PivotやPower BIのImportモデルでは、VertiPaqという列指向のストレージエンジンがデータを圧縮します。

たとえば「都道府県」のように同じ値が何度も登場する列は圧縮しやすい一方、注文番号、UUID、秒単位の日時、自由記述など、ほぼすべて異なる値を持つ列は圧縮効率が落ちます。

そのため、同じ300万行でもデータの中身によってモデルサイズが大きく違います。

「300万行なら大丈夫」「500万行から危険」といった固定的な基準を作るより、自分のモデルのファイルサイズ、更新時間、メモリ使用量、列ごとのデータ内容を確認する方が実務的です。

必要以上の履歴を読み込んでいる

もう一つ多いのが、「念のため」という理由で創業以来すべての履歴をモデルへ入れているケースです。

分析で直近3年しか使用しないのであれば、10年分の詳細データを毎回読み込み直す必要があるのか検討しましょう。

Microsoftも大規模なImportモデルでは、必要な期間・対象だけを読み込み、不要な行を減らすことを推奨しています。

さらに明細粒度が不要なら、日別・顧客別・商品別などへ事前集約してから読み込む方法もあります。

事前集約するとモデルは軽くなりますが、その粒度より細かい明細分析はできなくなります。必要な分析粒度を決めてから集約してください。

DAX計算列を増やしすぎている

DAXの計算列は便利ですが、大量の行を持つテーブルへ計算列を次々追加するとモデルサイズや更新時間へ影響します。

MicrosoftのPower BI向け設計ガイダンスでも、DAXの計算列はPower Queryで作成した列より圧縮効率が低くなる場合があり、更新時間も長くなるため注意が必要とされています。

集計時だけ必要な計算なら、行ごとに値を保存する計算列ではなく、メジャーで表現できないか検討しましょう。

Power Queryが遅い場合は処理順を見直す

Power Pivotが重いように見えても、実際にはPower Queryによるデータ取得・変換に時間がかかっていることもあります。

不要な行と列を早い段階で減らす

Power Queryでは、必要なデータだけを早い段階で残すことが基本です。

• 不要な期間を最初に除外する
• 使わない列を早めに削除する
• 正しいデータ型を設定する
• 並べ替えなど重い処理を必要以上に行わない
• 大量データの結合前に対象を絞り込む

MicrosoftもPower Queryのベストプラクティスとして「Filter early」「Do expensive operations last」を案内しています。

Microsoft「Best practices when working with Power Query」

クエリフォールディングを確認する

SQL Serverなど対応するデータソースでは、Power Queryで指定した変換処理の一部をデータベース側へ処理させる「クエリフォールディング」が利用されることがあります。

ローカルPCへ大量データをすべて持ってきてから加工するより、データベース側で先に絞り込み・変換できれば効率的です。

ただし、「インデックス列を追加したら必ずフォールディングが完全に切れる」「マージは必ず遅い」のように一律には判断できません。

コネクタや処理内容によって異なるため、対応環境ではクエリフォールディングの状態やQuery Diagnosticsなどを利用してボトルネックを確認します。

Microsoft「Query folding examples」

複数ファイルの結合やPower Queryのエラーで困っている場合は、Power Queryで複数ファイルを結合する方法も参考にしてください。

リレーションシップとDAXの複雑化にも注意する

Power Pivotの問題はファイルサイズだけではありません。

テーブルやDAXが増えるほど、作成者以外には構造が分からないモデルになりやすくなります。

リレーションシップは基本的に1列同士で作る

ExcelのData Modelでは、基本的に1つの列と別テーブルの1つの列を使ってリレーションシップを作ります。

そのため、「店舗コード＋商品コード」のような複数項目を組み合わせて結合したい場合は、元データ側やPower Query側で一意になるキーを用意する設計が必要になることがあります。

文字列を何でも連結すればよいのではなく、重複やNULL、区切り文字の衝突がないかまで確認してください。

同じ2テーブル間ではアクティブな関係は1つ

たとえば売上テーブルに「受注日」と「出荷日」があり、両方を日付マスタへつなぎたいケースがあります。

同じ2テーブル間では通常、アクティブなリレーションシップは1つとなり、もう一方は非アクティブとして扱います。

必要に応じてDAXのUSERELATIONSHIPなどを使用します。

これは単なる「Power Pivotの欠陥」というより、どの関係を通常のフィルターパスとして使用するか明確にするデータモデル設計上の考え方です。

スター型でモデルをシンプルにする

テーブル同士を複雑に結び続けるより、売上などの明細を持つ「ファクトテーブル」と、商品・顧客・日付などを持つ「ディメンションテーブル」に役割を分けるとモデルを理解しやすくなります。

Power BIへ移行する場合も、このスター型の考え方はそのまま活用できます。

Power BIへ移行する前に試したい6つの軽量化

Excelが重くなったからといって、すぐPower BIへ移行する必要はありません。

まず次の6点を確認してください。

1. 32bit・64bitを確認する
   大きなData Modelを扱うなら64bit版Officeを検討します。既存アドインや社内システムとの互換性は事前確認が必要です。
2. 不要な列を削除する
   レポート・リレーションシップ・計算に使わない列を読み込まないようにします。
3. 不要な履歴を減らす
   分析で使わない古い期間や対象外データを読み込み段階で除外します。
4. 高カーディナリティ列を見直す
   自由記述、長いID、秒単位日時など、本当に分析へ必要か確認します。
5. Power Queryの処理を見直す
   フィルター・列削除を早めに行い、重い処理は後ろへ回します。
6. モデルを単純化する
   スター型を意識し、不要な計算列・複雑なリレーションシップを減らします。

この6点を見直すだけで、Power BIへ移行せずExcelのまま実用的な速度へ戻るケースもあります。

ファイル共有だけが問題ならPower BI移行は早い場合もある

「どれが最新版か分からない」という理由だけでPower BIへ移行しようとしているなら、少し整理が必要です。

現在のExcelはOneDriveやSharePoint Online上へ保存して共同作業やバージョン履歴を利用できるため、ファイル管理の問題だけならMicrosoft 365側の運用変更で改善できる場合があります。

一方、Data Modelを含む巨大なExcelブックには、Excel for the webなど利用環境ごとのファイルサイズ制限もあります。

MicrosoftのData Model仕様では、Excel for the webにおけるData Modelを含むブックの総ファイルサイズ上限として250MBが案内されています。

そのため、単純な「最新版管理」だけではなく、次のような要件が増えてきたらPower BIを本格的に検討します。

• 多数の利用者へ同じレポートを配信したい
• 利用者ごとに閲覧できるデータを変えたい
• 定期的にデータを更新したい
• Excelファイルそのものを配布したくない
• 複数レポートから同じデータモデルを利用したい
• 部門をまたいで指標定義を統一したい

Excelを残す業務とクラウド側へ移す業務の考え方は、バックオフィス向け脱Excelツールの比較でも解説しています。

Power PivotからPower BIへ移行する判断基準

Power PivotとPower BIは「どちらが上か」で選ぶものではありません。

利用人数、更新方法、セキュリティ、データ量などから判断します。

状況	第一候補
自分や少人数で分析する	Excel＋Power Pivot
月次でデータを更新して分析する	Power Query＋Power Pivot
多数の人へ同じダッシュボードを配信する	Power BI
ユーザーごとに表示行を制御したい	Power BIのRLSなどを検討
データ取得元が巨大なDB	SQL＋Power BI / Excel
Import自体が容量上限へ近づく	Power BIの容量・DirectQuery等を含め再設計
非定型の大量ファイル処理・高度分析	Pythonも候補

Power BIなら共有と権限管理を設計しやすい

Power BIでは、Power BI Desktopでモデルやレポートを作成し、Power BI Serviceへ発行して共有する構成を取れます。

また、行レベルセキュリティ（RLS）を設定すれば、たとえば営業担当者ごとに自分の担当地域だけを表示するといった制御も可能です。

Microsoft「Power BIでの行レベルセキュリティ」

Power BIも容量無制限ではない

ここは非常に重要です。

Power BIへ移せば、どんな大きさのデータでも無制限に読み込めるわけではありません。

Power BI ServiceのImportモデルには、ライセンスや割り当てられた容量によってセマンティックモデルのサイズ上限があります。

Microsoft公式では標準の上限を1GBとし、Fabricなど対応する容量とLarge semantic model storage formatを利用することで、より大きなモデルを扱える仕組みが案内されています。

そのため、Power Pivotと同様にPower BIでも、不要列・不要行の削減やスター型モデルなどの設計は重要です。

Microsoft「Large semantic models in Power BI」

Power QueryとDAXの知識はPower BIでも活かせる

Power Pivotを使ってきた人にとって、Power BIへの移行は完全なゼロスタートではありません。

• Power Queryによるデータ取得・変換
• テーブル間のリレーションシップ
• DAXメジャー
• 日付テーブル
• スター型モデル

といった考え方はPower BIでも重要です。

これまでPower Pivotで身につけたデータモデリングの知識を捨てるのではなく、共有・配信・ガバナンスまで扱える環境へ広げると考えると移行しやすくなります。

大量データはExcelへ入れる前にSQLで減らす

元データがSQL Serverなどのデータベースにある場合は、「全部Excelへ持ってきてから減らす」という発想を見直します。

本当に必要なのが直近2年の売上だけなら、データベースへ問い合わせる段階で期間を絞る方が効率的です。

SELECT
    SaleDate,
    StoreID,
    ProductID,
    SalesAmount
FROM Sales
WHERE SaleDate >= '2024-01-01';

この例では必要な列と期間だけを取得しています。

実際の業務データベースへ直接SQLを実行する場合は、権限、負荷、個人情報、社内のデータ利用ルールを確認してください。

大規模データでは「Excelを速くする」より「Excelへ渡すデータ量を減らす」方が効く場合があります。
上流で不要な列・行・明細粒度を減らせるかを最初に確認しましょう。

PythonはPower Pivotの直接的な代替とは限らない

大量データの話になると、「ExcelをやめてPythonにすればよい」と考える方もいるでしょう。

Pythonは非常に強力ですが、Power Pivotの直接的な置き換えと考える必要はありません。

たとえば次のような処理ならPythonが候補になります。

• 大量のCSV・Excelファイルをまとめて加工する
• APIからデータを収集する
• 複雑な文字列処理を行う
• 統計解析・機械学習へ進む
• Excel外で定期バッチを実行する

一方、「経営者がブラウザから同じ売上ダッシュボードを見る」という用途ならPythonを自作するよりPower BIの方が導入しやすい場合があります。

VBA、Power Query、Pythonなどの使い分けは、Excel自動化の例7選と手段の選び方でも整理しています。

Power Pivotから移行する3段階ロードマップ

「Excelが重いから明日から全部Power BIへ変更する」という進め方はおすすめしません。

業務を止めないためにも段階的に進めます。

STEP1｜現在のPower Pivotを軽量化する

• 不要列を削除
• 不要期間を削除
• 高カーディナリティ列を確認
• DAX計算列を見直す
• Power Queryの処理順を見直す
• 32bit・64bitを確認

これで十分な速度になるなら、無理に移行する必要はありません。

STEP2｜Power BI Desktopで同じモデルを試す

次に、既存の集計の一部をPower BI Desktopで再現します。

いきなり全社レポートを移すのではなく、売上分析など影響範囲が限定されたレポートを1つ選びます。

• Power Queryの処理を再現できるか
• DAXメジャーの結果が一致するか
• Excelより操作しやすいか
• 更新時間が許容範囲か
• 利用者が必要な情報を確認できるか

STEP3｜共有・更新・権限まで含めて移行する

Power BI Desktopで作れることを確認したら、Power BI Serviceへの発行、更新方法、権限、RLS、ライセンス、運用担当者まで設計します。

さらに元データが巨大になれば、SQL、データウェアハウス、Microsoft Fabricなど上流側も含めて構成を見直します。

ツールを変えるだけでなく、誰がデータを作り、誰がモデルを管理し、誰が閲覧するのかまで決めて初めて移行完了です。

Power Pivotの限界に関するよくある質問

Power Pivotは何行まで扱えますか？

MicrosoftのExcel Data Model仕様では、1テーブル最大1,999,999,997行です。ただし、これは仕様上限であり、実用上の限界はPCメモリ、列数、ユニーク値、データ型、DAX、Power Queryなどによって大きく変わります。

Excelの104万行制限はPower Pivotにもありますか？

Data Model自体には同じ104万行制限はありません。1,048,576行はExcelワークシートの上限です。Data Modelへ100万行を超えるデータを保持し、ピボットテーブルで集計することは可能です。

32bit版Excelは2GBまでですか？

単純に「常に2GBまで」とは言い切れません。32bit環境は仮想アドレス空間の制約を受けますが、Excel 2016以降では64bit Windows上でLarge Address Awareにより利用可能なメモリ領域が拡大します。大規模Data Modelでは64bit版Officeも検討してください。

64bit Excelへ変えれば重いファイルは必ず速くなりますか？

必ず速くなるわけではありません。メモリ不足には有効な場合がありますが、不要列、高カーディナリティ、重いPower Query処理、複雑なDAXなどが原因ならモデル自体の改善が必要です。

Power BIへ移行すれば容量制限はなくなりますか？

なくなりません。Power BI ServiceのImportモデルにはライセンスや容量ごとのサイズ上限があります。より大きなモデルには対応するFabric容量やLarge semantic model storage formatなどを検討します。

Power PivotとPower BIはどちらを使うべきですか？

個人や少人数でアドホック分析するならExcel＋Power Pivotが便利です。多数の利用者への配信、定期更新、RLSなどの権限管理、共通のデータモデルを組織で使う必要があるならPower BIを検討します。

Power Pivotの次はPythonを学ぶべきですか？

必須ではありません。データベースから必要な情報を抽出するならSQL、組織でダッシュボードを共有するならPower BI、大量ファイル処理や高度な分析ならPythonというように、現在の課題から選びましょう。

Power PivotやPower BIを体系的に学ぶ方法

Power Pivotが重くなったとき、最初からPythonなど別の技術へ飛びつく必要はありません。

まず、Excelテーブル、ピボットテーブル、Power Query、Data Model、リレーションシップ、DAXという順番で、自分のモデルのどこがボトルネックなのか理解できるようになることが重要です。

画面操作を見ながらExcelやPower Queryを体系的に学びたい方は、UdemyのExcelおすすめ講座を目的別に比較した記事を参考にしてください。

Excelだけでなくデータ分析、Python、Power Automateなど仕事に必要なスキル全体から選びたい場合は、社会人向けUdemyおすすめ講座・ジャンル15選で整理しています。

まとめ｜Power Pivotの限界は行数だけで判断しない

Power Pivotの「限界」を考えるときは、100万行・500万行といった行数だけで判断しないことが重要です。

• ワークシートは1,048,576行まで
• Data Modelは1テーブル最大1,999,999,997行
• 実務上はメモリ・列数・カーディナリティの影響が大きい
• 不要な列・履歴は読み込まない
• Power Queryではフィルター・列削除を早めに行う
• 複雑なモデルはスター型を意識して単純化する
• 共有・RLS・定期更新が必要ならPower BIを検討する
• 巨大な元データはSQLなど上流側で減らす
• Pythonは必要な用途がある場合に追加する

Power Pivotが重くなったことは、すぐExcelを捨てるサインではありません。「現在のモデルを軽くできるのか」「Excelの役割を超えているのか」を切り分けるサインです。

まず現在のPower Pivotモデルから不要な列を1つ減らし、不要な履歴を絞り、更新時間がどう変わるか確認してみてください。

それでもExcelの範囲を超えているなら、Power BIやSQLへ段階的に広げていきましょう。

＼ 業務に合う自動化方法を選ぶ ／

本記事で記載した上限や機能は2026年8月時点のMicrosoft公式情報をもとにしています。Excel、Power BI、Microsoft Fabricの仕様・ライセンス・容量制限は変更される可能性があります。実際の移行やシステム構成変更では、最新のMicrosoft公式情報と勤務先のIT管理者の方針を確認してください。