2025年9月の Windows／Microsoft 365 更新（Version 2508）以降、これまで問題なく動いていた Excel の Power Pivot／データモデルの更新が突然エラーで止まり、業務が止まってしまった――そんな状況に直面している方も多いと思います。本記事では、実際の現象・原因・対処法を整理しつつ、「今すぐできる応急処置」と「中長期的な設計見直し」の両面から、Power Query／Power Pivot 利用者向けに詳しく解説します。
Excel Power Pivot／データモデル更新エラーの概要
発生している具体的な現象
2025年9月10日前後の Windows／Microsoft 365 更新（Microsoft 365 Apps Version 2508）適用後、一部の環境で次のような現象が発生します。
- Power Query で取得したデータを データモデル（Power Pivot）に読み込み、そのテーブルを Excel 上で 更新（Refresh） すると失敗する
- 更新時に次のようなエラーメッセージが表示される
The query did not run or the Data Model could not be accessed.
Query optimizer generated too many subcubes in the query plan.
さらに、次のような特徴があります。
- CUBE 関数（
CUBEVALUE/CUBEMEMBERなど）での取得は成功し、最新データを返す - しかし、既存のピボットテーブルは 更新しようとすると同じエラー で失敗する
- データモデルを元に 新しいピボットテーブルを作成 しようとしても、やはり同じエラーになる
つまり「データモデルそのものにはアクセスできているが、ピボットテーブルとして集計しようとした瞬間にクエリ最適化が破綻する」という状態になっています。
症状の整理（何ができて何ができないのか）
| 操作内容 | 結果 | 補足 |
|---|---|---|
| Power Query → データモデルに読み込み済みテーブルを更新 | エラーで失敗 | 「too many subcubes」エラー |
| 既存のピボットテーブルの更新 | エラーで失敗 | データモデルは存在するが、クエリプラン生成に失敗 |
| データモデルから新規ピボットテーブル作成 | 作成できない | ウィザードの途中または更新時に同エラー |
| CUBE 関数（CUBEVALUE / CUBEMEMBER など） | 正常に最新データを取得 | 個別のクエリ単位のため負荷が比較的軽い |
発生タイミングと環境の条件
今回のエラーは、次のような条件で報告されています。
- 2025年8月リリースの Microsoft 365 Apps Version 2508 を適用した直後から発生
- Windows Update 経由で Office 更新プログラムが展開された環境
- ライセンス例：
- Microsoft 365 E3（業務アカウント）
- Excel for Microsoft 365（クリック ツー ラン版）
- 更新前の数か月間はまったく問題なく Power Pivot／データモデルを利用できていた
つまり、ファイル側の構成は変えていないのに、更新（ビルド）をまたいだタイミングで突然動かなくなった、というのがポイントです。
影響を受けやすいデータモデルの特徴
すべてのブックで発生するわけではなく、特に次のような「複雑な」データモデル／ピボットテーブルで顕在化しやすい傾向があります。
- 計算列・メジャー（DAX）が多数定義されている
- 複数のテーブルが星型スキーマやスノーフレーク構造で連結されている
- 階層（年 → 四半期 → 月 → 日など）を多用している
- グランドトータル・小計・明細行など、集計レベルが多段になっている
- 1つの巨大なピボットテーブルで「全部入りダッシュボード」を実現している
こうした複雑なモデルは、Analysis Services エンジンがクエリを最適化する際に「多くのサブキューブ」を生成する必要があり、今回の仕様変更による上限値に引っかかりやすくなります。
原因：Analysis Services エンジンの仕様変更
エラーメッセージの意味
エラーメッセージに含まれる
Query optimizer generated too many subcubes in the query plan.
は、Excel というより Analysis Services（データモデルを動かしているエンジン側） の制約によるものです。
簡単にいうと、ピボットテーブルを更新する際、エンジンは内部で
- どのテーブルをどう結合するか
- どの順番でフィルター・集計を行うか
- どの計算をどのタイミングで評価するか
といった「クエリプラン」を作ります。このとき、必要に応じて部分的な多次元キューブ＝サブキューブ を多数生成して試行錯誤します。
Version 2508 では、この「サブキューブの最大数」の上限が従来よりも低く設定されました。その結果、次のような状況になります。
- 複雑なピボットテーブル → クエリ最適化の途中で上限に達する
- すると、エンジン側で「これ以上サブキューブを作れない」と判断
- 結果として クエリ自体の実行が拒否され、エラー終了
仕様変更の背景（推測）
この変更は「不具合」ではなく、エンジンの設計上の制限強化として扱われています。主な狙いとして考えられるのは次のような点です。
- 極端に複雑なクエリによる CPU／メモリ消費を抑える
- 1ユーザーの重いクエリが他ユーザーの処理を巻き込んで遅くなるのを防ぐ
- クラウド環境（Microsoft 365）全体の安定性を優先する
つまり、エンジン側としては「危険なレベルに達する前にクエリを止めている」つもりなのですが、現場の利用者からすると「昨日まで動いていたダッシュボードが突然死んだ」状態になってしまっている、というわけです。
CUBE 関数が動く理由
同じデータモデルを使っていても、CUBE 関数は動作していることが多く報告されています。これは、次のような違いによるものと考えられます。
| 機能 | クエリの性質 | サブキューブ数 |
|---|---|---|
| ピボットテーブル | 1回の更新で多くの軸・フィールド・集計レベルを同時に処理 | 非常に多くなりがち |
| CUBE 関数 | セル単位・行単位で必要なメンバー／値だけを取得 | ピボットに比べると少ない |
特に、巨大なピボットテーブルを1枚置いている場合は、CUBE 関数＋通常の表で「必要な指標だけをピンポイントに取得する」構成に比べて、クエリの複雑度が一気に高くなります。
今すぐできる対処法・回避策の全体像
この問題に直面したときの選択肢は、ざっくり次の3レイヤーに分けられます。
- レイヤー1：Office バージョンを変える（ロールバック／後続ビルド待ち）
- レイヤー2：データモデル・ピボットの複雑度を下げる
- レイヤー3：設計そのものを変えて負荷を分散する
どれが最適かは「どれだけビジネスが止まっているか」「IT 部門の権限がどこまであるか」によって変わるため、自社の状況に合わせて組み合わせることが重要です。
レイヤー1：Office バージョンを戻す／後続ビルドを待つ
管理者権限がある場合のロールバック例
もっとも手っ取り早いのは、問題が発生する前のバージョン（Version 2507 など）に戻してしまう方法です。クリック ツー ラン（C2R）版の Office であれば、管理者権限の PowerShell から次のように実行できます。
cd "C:\Program Files\Common Files\Microsoft Shared\ClickToRun"
OfficeC2RClient.exe /update user updatetoversion=16.0.****.****
実務上のポイント：
16.0.****.****の部分は、実際に戻したいビルド番号に置き換える必要があります- 組織で利用している更新チャネル（Current Channel / Monthly Enterprise など）に対応したビルドを選びます
- ロールバック後は 自動更新により再び Version 2508 へ上書きされないよう、一時的な更新停止ポリシーを検討します
この方法は「すぐに業務を再開したい」「ほかのアプリの不具合は出ていない」といったケースで特に有効です。
すぐ戻せない場合：後続ビルドでの修正を待つ
企業環境では、ユーザー自身がバージョンを戻せないケースも多いです。その場合は、次のような流れが現実的です。
- IT 部門に「Version 2508 以降で Power Pivot 更新時に
too many subcubesエラーが出る」旨を共有 - Monthly Enterprise／Current Channel の 後続ビルド で修正が入らないかを確認してもらう
- 修正版が出たら、まずはテスト用端末／代表的な帳票で再現性を確認
- 問題が解消されていることを確認したうえで全社展開する
ただし、「修正を待っている間も現場は動かない」ため、後述するレイヤー2・3（複雑度削減／設計変更）と並行して検討しておくことをおすすめします。
レイヤー2：データモデル／ピボットの複雑度を下げる
不要なメジャー・階層・フィールドの整理
まず着手しやすいのは、「本当に使っているのか怪しい要素」を削ることです。次のような観点で棚卸しを行います。
- 1年以上使われていないメジャー（DAX）の削除
- 一度もレポートに載っていない列・フィールドの非表示化／削除
- 使われていない階層（Year-Quarter-Month など）の削除
- ピボットテーブル上でオフにできる小計・グランドトータルの無効化
これだけでも、クエリ最適化時のサブキューブ数をある程度減らせることがあります。
| 見直し項目 | 例 | 期待される効果 |
|---|---|---|
| メジャーの整理 | [売上(旧定義)] など旧バージョンの計算 | DAX 評価パターンが減り、クエリプランが単純化 |
| 列・フィールドの削除／非表示 | 「デバッグ用」や「一時的に追加した」列 | 分析軸候補が減ることでサブキューブ数が抑制される |
| 階層の削減 | 年→四半期→月→週→日 のような深い階層 | 集計パターンが減少し、クエリが軽くなる |
| トータル／サブトータルの見直し | ピボットの「総計」「小計」表示 | 不要な集計レベルを削減できる |
1つの巨大ピボットを分割する
「すべての指標・軸を1つのピボットで表現している」ケースでは、次のように分割することで改善が期待できます。
- 売上サマリ（年度×部門）用のピボット
- 商品別詳細（商品×月）用のピボット
- 地域別トレンド（地域×四半期）用のピボット
それぞれを別シート、または1シート内の別ブロックに配置し、必要に応じて スライサーやタイムラインを共有 する構成にします。ピボット1つあたりの負荷を分散できるため、「巨大な1枚のピボット」で上限に引っかかっていたケースでは特に有効です。
CUBE 関数中心の構成に切り替える
どうしても複雑なビューが必要な場合は、ピボットテーブルで頑張るのではなく、次のような方針に切り替えるのも一案です。
- データモデル上に必要なメジャー・メンバーを定義する
- Excel シート側で
CUBEVALUE/CUBEMEMBERなどの CUBE 関数を使って、 - 「本当に必要なセル」だけをピンポイントで読み出す
- 読み出した値を普通のテーブル／グラフで組み合わせる
ピボットテーブルは「汎用集計マシン」として非常に便利ですが、その分、クエリ最適化の負荷も高くなります。CUBE 関数を使うと、「必要なセルだけ問い合わせる」形になるため、内部的なサブキューブ数を抑えられる可能性が高くなります。
レイヤー3：負荷分散のための設計変更
Power Query で前集計しておく
Analysis Services に渡す前の段階、つまり Power Query での処理を工夫することで、データモデル側の負荷を下げられることがあります。
- 明細レベル（トランザクション単位）のままデータモデルに載せている場合：
- Power Query 側であらかじめ「日次」「月次」「部門別」などに集約したテーブルを用意する
- その集計済みテーブルをデータモデルに読み込む
- 本当に必要な列だけを選択し、使っていない列は Power Query 側で削除してしまう
- 結合（Merge）も「必要なものだけ」に絞る
これにより、データモデル内で行う必要のある DAX 計算や集計処理を減らし、サブキューブ数の増大を抑制できます。
ブックを分割し、目的別にモデルを分ける
1つの Excel ファイルで「売上」「在庫」「経費」「予算」など多くの領域を一括管理していると、その分モデルが巨大化し、クエリも複雑になります。次のような分割も検討できます。
- 売上分析用ブック（売上と関連ディメンションだけを載せる）
- 在庫分析用ブック
- 経費分析用ブック
必要に応じて、リンクテーブルや、Power Query で別ブックのテーブルを参照する方法で連携させれば、ユーザー体験を維持しつつ内部の複雑度を抑えられます。
Power BI など別プラットフォームの活用も検討する
もし組織内で Power BI を利用できるのであれば、以下のような構成も選択肢になります。
- 重い処理や巨大なモデルは Power BI に集約する
- Excel からは Power BI データセットに接続し、軽量なピボットや CUBE 関数で参照する
- Excel 側のデータモデルは簡易用途に絞る
これにより、Analysis Services の制限にひっかかるような巨大クエリを Excel 単体で抱え込む必要がなくなります。
Microsoft へのフィードバックと組織的な対応
Excel から直接フィードバックを送信する
同様の現象を経験しているユーザーが多ければ多いほど、製品側での優先度が上がります。Excel には次のようなフィードバック機能が用意されています。
- Excel を開く
- メニューから [ファイル] > [フィードバック] を選択
- 「問題を報告」等を選び、次のポイントをなるべく詳しく記載する
- 使用している Excel／Microsoft 365 のバージョン（Version 2508 など）
- 表示されたエラーメッセージ全文
- どのようなファイルで、どんな操作をしたときに問題が発生したか
同様の不具合に遭遇しているユーザーが多いほど、修正の優先度が上がる傾向があります。可能であれば、組織内の利用者にもフィードバック送信を呼びかけるとよいでしょう。
IT 部門レベルでのポリシー対応
組織で多数のユーザーが影響を受けている場合、IT 部門として次のような対策も検討できます。
- 更新の一時停止ポリシー の設定
- グループポリシーや Intune を用いて、対象バージョンへの自動更新を一時停止
- 更新チャネルの見直し
- Current Channel から Monthly Enterprise への切り替えなど、更新頻度と安定性のバランスを調整
- 代表ユーザーによる先行テスト
- 本番展開前に、Power Pivot／Power Query を多用する代表的な帳票で動作検証を行う
「更新を遅らせる」ことにはセキュリティの観点でデメリットもありますが、「基幹レポートが毎月止まる」ほうがビジネスインパクトが大きい場合も多く、バランスが重要です。
Power Query 自体のパフォーマンス低下の可能性
同じ Version 2508 適用後、Power Pivot だけでなく Power Query 自体のパフォーマンス低下 を感じるケースもあります。
- 従来よりクエリの読み込みに時間がかかる
- 同じ処理内容でも CPU 使用率が高く張り付きやすい
- バッチ的に複数クエリを更新するとタイムアウトしやすくなった
これは、Analysis Services 側の最適化強化や、クエリエンジンの内部仕様変更が影響している可能性があります。Power Pivot のエラーと合わせて、「Power Query 側でできるだけ前処理を完結させる」「更新回数を減らす」といった設計も検討してみてください。
トラブルシューティングのチェックリスト
最後に、現場で原因切り分けを行う際に役立つチェックリストをまとめます。
| 確認項目 | 具体的な確認方法 | ポイント |
|---|---|---|
| Office バージョン | Excel の [アカウント] 画面でバージョン／ビルド番号を確認 | Version 2508 以降かどうかを把握 |
| 単純なピボットの挙動 | 同じデータモデルから「行：1項目」「列：なし」「値：1つ」の簡単なピボットを作成 | 単純なピボットでもエラーならモデル全体に影響している可能性が高い |
| CUBE 関数の挙動 | 簡単な CUBEVALUE で値を取得してみる | CUBE 関数は動くがピボットがダメならサブキューブ上限に起因しやすい |
| 別 PC／別ユーザーでの再現 | 同じファイルを他端末で開き、同じ操作を試す | Office バージョンによる再現性の違いを確認 |
| 簡略版モデルでの再現 | オリジナルのモデルからコピーし、メジャーやテーブル数を間引いた版を作る | どの程度の複雑さからエラーが出るかの目安になる |
よくある質問（FAQ）
Q. メモリを増設すればこのエラーは解消しますか？
A. 今回のエラーは「サブキューブ数の上限」という エンジンの仕様上の制限 に起因しているため、PC のメモリ増設だけで解決する可能性は低いと考えられます。むしろ、データモデルやピボットテーブルの構造を見直し、クエリの複雑度を下げることが重要です。
Q. データモデルが壊れている可能性はありますか？
A. CUBE 関数で最新データが取得できるのであれば、モデル自体は正常に読み込めていると考えられます。問題は「ピボット更新時のクエリプラン生成」にあり、データが消失しているわけではありません。ただし、設計変更やバージョンロールバックを行う前には、必ずバックアップを取っておくことをおすすめします。
Q. すべてのファイルで同じエラーが出るわけではないのはなぜ？
A. サブキューブ数の上限に達するかどうかは、「データ量」だけでなく「テーブル間の関係」「メジャーの数」「階層の深さ」「小計・総計の有無」など、多くの要因に左右されます。そのため、同じ Version 2508 を使っていても、単純なモデルは問題なく、複雑なモデルだけがエラーになる、という状況が発生します。
Q. これから新しくモデルを作る場合、どう設計すれば安全ですか？
A. 完全にリスクゼロにすることは難しいですが、次のような方針が有効です。
- 1つのモデルで抱え込むテーブル数・関係数を必要十分な範囲に絞る
- Power Query 側でできる前処理はできるだけそちらで行う（前集計・列削除など）
- 巨大な1枚ピボットではなく、用途別に小さめのピボットを複数配置する
- どうしても複雑なビューが必要な箇所は CUBE 関数＋通常の表で構成する
これらを意識しておくことで、将来の仕様変更にも強いモデル設計になります。
まとめ：短期の応急処置＋中長期の設計見直しをセットで考える
2025年9月前後の Microsoft 365 Apps Version 2508 適用後に発生している、Excel Power Pivot／データモデル更新時の「Query optimizer generated too many subcubes」エラーは、Analysis Services エンジン側の仕様変更による サブキューブ数の上限強化 が背景にあると考えられます。
現場で取れる対策は、大きく次の3つです。
- Office バージョンのロールバックまたは後続ビルドへの更新
→ もっとも即効性が高いが、IT ポリシーやセキュリティとのバランスが必要 - データモデル／ピボットテーブルの複雑度削減
→ 不要なメジャー・階層・トータルの削除、巨大ピボットの分割、CUBE 関数の活用など - 設計レベルでの負荷分散
→ Power Query での前集計、ファイル分割、Power BI との役割分担など
まずは、ビジネスが止まっている箇所について「短期的な応急処置」を講じつつ、同時に「なぜこのモデルはサブキューブ上限に達したのか？」を逆算しながら、中長期的な設計見直しを進めていくのが望ましいアプローチです。
Excel／Power Query／Power Pivot は依然として非常に強力な分析プラットフォームですが、クラウド時代の仕様変更やリソース制限の影響を受けやすくなっています。本記事の内容を参考に、自身のモデルを一度棚卸しし、「壊れにくく・保守しやすいデータモデル設計」にアップデートしていきましょう。
コメント