Excel の PowerPivot（データモデル）で作ったレポートが、ある日を境に「Query optimizer generated too many subcubes in the query plan」エラーで更新できなくなった――。Microsoft 365 Apps Version 2508 以降で実際に報告されているこの事象について、原因となる仕組みと、現場で今すぐ試せる回避策・長期的な設計見直しのポイントを整理します。
現象の概要：Excel 更新後に突然出始める「サブキューブが多すぎます」エラー
Microsoft 365 Apps を Version 2508（Current Channel、たとえば Build 17928.20114 など）に更新した直後から、次のような症状が報告されています。
- Power Query で取得したデータを データモデル（PowerPivot）に読み込み、そのモデルに接続したピボットテーブルを更新すると失敗する
- 更新時に以下のような英語メッセージが表示される
The query did not run or the Data Model could not be accessed.Query optimizer generated too many subcubes in the query plan
- Version 2507 にロールバックすると、同じブック・同じモデルでも正常に更新できる
- モデルによっては、エラーにならずとも更新時間が極端に長くなる、Excel が固まったように見えるといったパフォーマンス劣化だけが起きる
まず押さえておきたいのは、これは「キャッシュが壊れた」という類の問題ではなく、Excel の内部で動いている Analysis Services エンジン（VertiPaq）側の制約に引っかかっている、という点です。
| 項目 | 内容 |
|---|---|
| 対象バージョンの例 | Microsoft 365 Apps Version 2508（Build 17928.20114 など／Current Channel） |
| 影響しやすい構成 | データモデル（PowerPivot）＋複雑なピボットテーブル（多階層・多メジャー・総計／小計 ON） |
| 典型的なエラーメッセージ | Query optimizer generated too many subcubes in the query plan |
| ロールバック時の挙動 | Version 2507 に戻すと同じブックが正常に更新できるケースが多い |
「Query optimizer generated too many subcubes」エラーの正体
Excel データモデルの裏側で何が起きているのか
PowerPivot や Excel データモデルの裏側では、SQL Server Analysis Services（SSAS）由来の VertiPaq / Analysis Services エンジンが動いています。ピボットテーブルを更新するとき、このエンジンは次のような流れで計算を行います。
- ピボットテーブルの 行・列・フィルター・スライサーで指定された条件を解析し、どのテーブルからどのようにデータを取るかを決める
- その過程でクエリを、より小さな単位の多次元データのかたまりに分割する。これが サブキューブ（subcube）
- サブキューブごとに集計や DAX 計算を行い、それらを合成して最終的なピボットのセル値を出す
つまり、ピボットテーブルの「見た目」が複雑になるほど、内部ではサブキューブの数が増えるイメージです。
SSAS 公式ドキュメントでの説明
SQL Server Analysis Services のトラブルシューティング記事では、MDX クエリ実行時に
Query optimizer generated too many subcubes in the query plan
というエラーが出るケースについて、次のように説明されています（要約）。
- クエリ最適化の過程で生成される「クエリサブキューブの数」には上限がある
- 次のような条件が重なると、上限に達してエラーになる
- 同じ階層に大量の計算メンバーが定義されている
- 行・列に多くのフィールド／属性メンバーが並んでいる
- 選択した階層のすべてのメンバーを軸に含めている
- グランドトータル（総計）や小計がオンになっている
- この制限は、サーバーリソースの使い過ぎを防ぐための設計仕様であり、「バグ」ではない
Excel データモデルもこの Analysis Services エンジンを使っているため、条件がそろうと同じエラーが表に出てきます。つまり、Excel Version 2508 で急に出るようになったとはいえ、根本は SSAS の古くからの仕様だと理解できます。
なぜ Version 2508 で一気に顕在化したのか
2025 年 8 月以降、Microsoft 365 Excel Version 2508 を適用した環境で、「以前は問題なかったブックが突然エラーになる」「Version 2507 に戻すと直る」という報告が、Microsoft Q&A や各種技術ブログで多数見られます。
公表されている情報や実際の事例から推測すると、Version 2508 では クエリプランを作るロジックやサブキューブ生成の挙動が変わり、同じモデルでも上限に達しやすくなったと考えられます。
- サブキューブの上限値そのものが厳しくなった、もしくは
- 同じピボット構成でも、より多くのサブキューブを生成するように最適化ロジックが変化した
いずれにせよ、「Version 2508 に更新すると症状が現れ、2507 に戻せば解消する」という点から、Excel 側の更新によって“仕様由来の制限”に当たりやすくなったレグレッションと整理できます。
これは不具合か？仕様か？
結論からいうと、
- エラーそのものは Analysis Services の仕様による制限（サブキューブ数の上限）
- Version 2508 で同じモデルが引っかかりやすくなったのは Excel 側のレグレッションと見てよい
したがって、「完全なバグだから放っておけばいつか直る」というスタンスより、
- 短期的にはモデル・レポートの複雑さを抑えて回避する
- 中長期的にはデータモデル・ピボット設計の見直しを進める
という方針で対処するのが現実的です。そのうえで、Microsoft へフィードバックを送ることで、将来的な緩和（閾値の調整など）がなされる可能性に期待します。
当面の回避策：効果が出やすい順に解説
ここからは、現場で「明日の定例レポートをとにかく動かしたい」状況を想定し、効果が出やすい順に回避策を紹介します。
| 優先度 | 対策 | 期待できる効果 | 難易度 |
|---|---|---|---|
| 高 | Excel を Version 2507 にロールバック | 環境全体で一気に解消する可能性大 | 組織ポリシー次第（管理者の作業が必要） |
| 高 | ピボットの総計・小計を無効化 | サブキューブ数を大きく削減できる | ユーザー自身で数分 |
| 中 | 行・列フィールドを減らしてピボットを分割 | ピボット単位の負荷軽減、見通しも良くなる | レポート構成の見直しが必要 |
| 中 | DAX メジャーを軽量化・共通化 | 計算の爆発を防ぎ、再利用性も向上 | DAX の理解が必要 |
| 中 | リレーションシップ（関係）の整理 | フィルターパスがシンプルになり、クエリも安定 | モデル設計の見直しが必要 |
| 低～中 | 前集計テーブル（集約テーブル）の導入 | 大規模データでも安定して集計可能に | Power Query／DAX 設計が必要 |
Excel／Office を Version 2507 にロールバックする
最も即効性が高いのは、Excel をVersion 2507 に戻すことです。すでに質問者環境でも、2507 へロールバックしたところ同じ PowerPivot レポートが正常に更新できることが確認されています。
一般的な Click-to-Run 版の Microsoft 365 Apps では、管理者権限があればコマンドラインや構成ポリシーでバージョン指定の更新が可能です。具体的な手順は組織の運用ルールに依存しますが、イメージとしては次のような流れになります。
- 現在の Excel バージョンを確認（[ファイル] → [アカウント] → [Excel のバージョン情報]）
- 管理者が Microsoft 365 管理センターやドキュメントから、2507 のビルド番号を確認
- クライアント側でバージョン指定の更新／ロールバックを実施
- 更新後、PowerPivot ピボットの更新テストを行う
組織として「最新の Current Channel を使う」ポリシーがある場合は、影響を受ける一部のユーザーだけを別チャネル（Monthly Enterprise / 半期チャネルなど）に分ける運用も検討に値します。
総計・小計をオフにしてサブキューブを一気に減らす
SSAS の公式ドキュメントでも、グランドトータル（総計）と小計をオフにすることが有効な回避策として挙げられています。
Excel ピボットテーブルでの具体的な操作例は次の通りです。
- 問題のピボットテーブル内をクリックする
- リボンの [デザイン] タブを開く
- [小計] → [小計を表示しない] を選択
- [総計] → [行と列の集計を表示しない] を選択
これにより、ピボットの各階層に対する総計・小計の計算が大幅に減り、内部で必要となるサブキューブ数も一気に削減されます。見た目として総計が必須でないレポートであれば、まず最初に試す価値のある対策です。
行・列に乗せすぎたフィールドを減らし、ピボットを分割する
「1つのピボットテーブルで全部を見たい」という要求から、つい次のような構成になりがちです。
- 行に「部門 → 課 → チーム → 担当者 → 製品 → 品目 → ・・・」と多段階層を並べる
- 列にも「年度 → 月」など複数のフィールドを置く
- さらに複数のメジャー（売上・原価・利益・利益率…）を表示
このような「全部入りピボット」は、行×列×メジャーの組み合わせ数が爆発的に増え、サブキューブ数の上限を超えやすい構成です。
おすすめのアプローチは、次のようにレポートの目的ごとにピボットを分割することです。
- 売上サマリ用ピボット（部門別・月別など、軸をシンプルに）
- 部門詳細用ピボット（部門 → 課 → 担当者レベルまで）
- 製品分析用ピボット（製品カテゴリ → 製品レベル中心）
必要であれば、これら複数のピボットを 1 枚のシートに配置し、同じスライサーで連動させれば、ユーザー体験を大きく損なわずにサブキューブ数を抑えられます。
重い DAX メジャーを軽量化・共通化する
複雑な DAX メジャーも、サブキューブ数増加の一因です。特に次のようなパターンは要注意です。
CALCULATEの多重入れ子、FILTER・SUMXの多用- 同じ条件式を各メジャーにコピペし、毎回フィルターコンテキストを組み立て直している
- ゼロ割りや NULL 判定を
/やIFで手作業している
代表的なリファクタリング例を示します。
| 改善前 | 改善後 |
|---|---|
売上利益率 := IF ( ISBLANK ( CALCULATE ( SUM ( 売上[売上金額] ) ) ), BLANK (), SUMX ( VALUES ( 日付[年月] ), CALCULATE ( SUM ( 売上[売上金額] ) ) / CALCULATE ( SUM ( 売上[原価] ) ) ) ) | 売上金額 := SUM ( 売上[売上金額] ) 原価金額 := SUM ( 売上[原価] ) 売上利益率 := VAR 売上 = [売上金額] VAR 原価 = [原価金額] RETURN DIVIDE ( 売上 - 原価, 売上 ) |
ポイントは次の通りです。
- 共通する集計は ベースメジャーとして切り出す（
売上金額・原価金額など） DIVIDEを使うことでゼロ割り処理をエンジンに任せ、不要なIFを減らすSUMXなどのイテレータは本当に必要な場合だけに限定する
DAX の書き方を工夫することで、クエリプランがシンプルになり、サブキューブ数の増加を抑えられるだけでなく、全体のパフォーマンス改善やメンテナンス性向上にもつながります。
リレーションシップ（関係）の見直し：双方向・多対多を極力排除
データモデルのリレーションシップ設計も、サブキューブ数に影響します。特に注意したいのが次のポイントです。
- 双方向フィルター（Both）の多用
- 多対多関係やブリッジテーブルが複雑に絡み合ったモデル
双方向フィルターは一見便利ですが、フィルターパスが増え、クエリプランの探索空間が広がります。その結果、同じピボット構成でも必要なサブキューブ数が増えやすくなるのです。
推奨されるのは、Power BI でもおなじみの スター・スキーマ（星型スキーマ）＋片方向フィルターです。
- 中心に ファクトテーブル（売上、仕入などの明細）
- 周囲に ディメンション（顧客、製品、日付、部門…） を配置
- リレーションシップは ディメンション → ファクト への片方向フィルターを基本とする
- どうしても双方向が必要な箇所は、本当に必要なテーブル間に限定する
不要なリレーションシップを削除し、双方向を単方向に戻すだけでも、クエリプランの複雑さがぐっと下がるケースがあります。
階層と高カーディナリティ列を整理する
次のような構成もサブキューブ数増加の温床です。
- 「年 → 四半期 → 月 → 日」などの日付階層を複数の軸に同時に配置
- 顧客コード・伝票番号・製品シリアルなど、種類（カーディナリティ）が非常に多い列を行・列に置く
- それらに対して総計／小計をさらに有効化している
これらの列や階層は、次のように整理するとよいでしょう。
- 「日付ディメンション」を用意し、日付関係の列はそこに集約する
- 分析の主単位（たとえば「年月」「四半期」）を決め、それ以外はスライサーや詳細レポートに逃がす
- 顧客コードなどの高カーディナリティ列は、ピボットの軸ではなく「ドリルスルー／明細参照」に回す
軸に乗せるメンバー数を減らすだけでも、サブキューブ数は大きく抑えられます。
前集計（集約テーブル）を導入する
データ量が大きい場合は、Power Query や DAX で前集計テーブル（サマリテーブル）を用意し、ピボットはその集約テーブルを参照させるのが有効です。
たとえば、売上明細テーブル（数百万行）から、次のような集約テーブルを作成します。
- 日付ディメンション単位（年・月）
- 部門・製品カテゴリ単位
Power Query でのイメージ：
Table.Group(
売上明細,
{"年", "月", "部門コード", "製品カテゴリ"},
{
{"売上金額", each List.Sum([売上金額]), type number},
{"原価金額", each List.Sum([原価金額]), type number}
}
)この集約テーブルをデータモデルにロードし、そのテーブルを基にピボットを組み立てれば、
- ピボットが扱う行数が大幅に減る
- 必要なサブキューブ数も少なくて済む
- 元の明細は「ドリルスルー専用」として別レポートに切り出せる
というメリットが得られます。
設計レベルでの恒久対策：再発させないモデルづくり
ここまでの対策は「目の前のエラーを消す」ことが主目的でしたが、中長期的には再発しにくいモデル設計に寄せていくことが重要です。
スター・スキーマを基本形とする
Analysis Services／PowerPivot／Power BI すべてに共通するベストプラクティスとして、スター・スキーマ（星型スキーマ）があります。
- ファクトテーブル（売上、在庫など）を中心に据える
- 顧客・製品・日付・組織などをディメンションとして周囲に置く
- リレーションシップは一対多（ディメンション → ファクト）を基本とし、多対多は最小限に抑える
この形を崩さないだけでも、クエリプランやサブキューブの構成がシンプルになり、今回のような制限に当たりにくくなります。
「1 レポート 1 目的」の原則を徹底する
忙しい現場ほど、「どうせなら 1 つのピボットで全部見たい」という要求が生まれがちです。しかしそれは、今回のようなエラーにつながる「巨大で複雑なピボット」の温床でもあります。
おすすめは、レポートごとに次の問いを立てることです。
- このレポートの主たる意思決定／確認ポイントは何か？
- そのために本当に必要な軸（行・列）はどれか？
- サマリで足りない情報は何か。別レポートやドリルスルーに切り出せないか？
「1 レポート 1 目的」を意識することで、自然とシンプルなピボット構成になり、サブキューブの増加を抑えられます。
日付ディメンションを整備し、自動日付に依存しない
Excel データモデルでは、自動日付グループ化機能に頼ると、裏側で隠し階層や列が増え、モデルが見えにくくなります。次のような専用の日付ディメンションテーブルを用意し、そこに年月・四半期・年度などの列を持たせるのが安全です。
- 日付（連番）
- 年、四半期、月、週番号、曜日など
- 会計年度・会計期など、業務に必要なカレンダー
これにより、
- DAX の時間知能関数（
TOTALYTDなど）を安定して使える - ピボットの軸として使う階層を明示的に管理できる
- 不要な階層を減らし、サブキューブ数の抑制にもつながる
集約テーブルと詳細テーブルの役割分担をはっきりさせる
大規模データでは、「1 つのモデルでサマリも明細も全部見たい」と思うほど負荷が重くなります。次のような役割分担がおすすめです。
- 集約テーブル：日次・月次・部門別など、意思決定に使う粒度で前集計したテーブル。ピボットの主要な集計はここから行う
- 明細テーブル：必要なときだけドリルスルーや詳細レポートで参照する
これにより、サマリビューではサブキューブ数を抑えつつ、高い視認性を確保できます。
補足の QA：現場でよく聞かれる疑問
テーブルや関係を減らせば本当に直る？
「テーブルを減らしても意味があるのか？」という質問はよくあります。実際には、
- 不要なテーブル・関係を削る
- 双方向フィルターや多対多を単純化する
といった作業は、クエリプランの分岐を減らし、サブキューブ数の増加を抑える効果が高いです。特に、用途があいまいなブリッジテーブルや、実は使っていないディメンションテーブルを整理するだけで改善するケースもあります。
キャッシュ削除（ファイルの削除）で直る？
一部では、「キャッシュを削除したら改善した」という声もありますが、今回の事象はクエリプラン生成時のサブキューブ数上限が直接の原因です。そのため、キャッシュ削除の効果は限定的で、「たまたまプランが変わって一時的に通った」程度にとどまることが多いと考えるべきです。
Power BI に移行すれば解決する？
Power BI も内部では同系統の Analysis Services エンジンを使用しているため、非常に複雑なモデル・レポートを作れば、同種の制限に当たる可能性があります。ただし、
- より強力なサーバーリソースを使える
- モニタリングやパフォーマンス分析機能が充実している
といった点で、根本的なモデリング改善やパフォーマンスチューニングを行う余地は広がります。どのみち、モデルの簡素化＋集約テーブルの導入といった設計改善は、どのプラットフォームでも必須と考えるべきです。
更新チャネル（Current / Monthly Enterprise / 半期）をどう運用する？
Version 2508 で影響を受けた組織では、次のような運用パターンが現実的です。
- レポート業務に直結する端末は、Monthly Enterprise や半期チャネルに固定し、検証済みのバージョン（例：2507 系）をしばらく維持する
- 新機能検証用の端末／ユーザーを Current Channel に残し、Excel の更新影響を先行検証する
- 重大な影響が判明した場合は、Microsoft へのフィードバックと同時に、組織内でロールバック手順・影響範囲をすばやく共有する
こうした「二段構えの更新運用」は、今回のようなバージョン起因のトラブルだけでなく、他の Office アップデートリスクを抑える意味でも有効です。
30 分でできる即効チェックリスト
最後に、「今すぐ何をすればよいか」を整理した 30 分チェックリストをまとめます。
- 問題のピボットで、総計・小計をすべてオフにして更新テスト
- 行・列に置いているフィールド数を半分に減らし、ピボットを分割できないか検討
- 特に重そうなメジャー（IF・FILTER・SUMX が多いもの）を一時的にシンプルな計算に差し替えて更新テスト
- モデルのリレーションシップを開き、双方向フィルターを単方向に戻す／不要な関係を削除して再テスト
- それでも改善しなければ、Version 2507 へのロールバックや更新チャネル変更を管理者と相談
まとめ：短期は回避策、長期はモデル改善とフィードバック
Microsoft 365 Apps Version 2508 以降で顕在化している PowerPivot の Query optimizer generated too many subcubes in the query plan エラーは、
- 根本には Analysis Services エンジンのサブキューブ数上限という仕様があり
- Version 2508 の変更により、同じモデルでもこの上限に届きやすくなった
という構図で整理できます。
そのうえで、現場としては
- Version 2507 へのロールバックや総計・小計のオフ、ピボットの分割などの短期回避策で「今のレポートを動かす」
- 並行して、スター・スキーマ準拠のモデル設計、集約テーブルの導入、「1 レポート 1 目的」の徹底といった中長期的なモデル改善を進める
- 影響が大きい場合は、Excel の「ヘルプ → フィードバック → 問題を報告」から Microsoft に状況を伝え、将来的な仕様緩和・修正を後押しする
という二段構えで臨むのが現実的です。
PowerPivot や Excel データモデルは、正しく設計すれば非常に強力なレポーティング基盤になります。今回の「サブキューブが多すぎます」エラーをきっかけに、モデルの整理・レポートの目的の再定義を行うことで、むしろ将来にわたって保守しやすい分析基盤づくりにつなげていきましょう。
コメント