最近の Microsoft 365 Excel 更新後から、これまで普通に更新できていた「データモデル接続のピボットテーブル」が、突然エラーで止まるケースが相次いでいます。本記事では、英語メッセージ「too many subcubes」に悩まされている方向けに、原因の正体と再現性の高い対処法、そして再発防止のためのモデル設計・運用のポイントを整理して解説します。
発生するエラーと典型的な症状
問題のエラーは、多くの場合以下のような英語メッセージとして表示されます。
the query optimizer has encountered a complexity that it can't handle, typically due to too many subcubes in the data model
このエラーが出る典型パターンを整理すると、次のようになります。
- Microsoft 365 の Excel（クリック トゥ ラン版）を使用
- Power Query で取り込んだデータを 「データモデルに読み込み」、Power Pivot（VertiPaq）エンジンに載せている
- そのデータモデルに接続したピボットテーブルを 更新 しようとすると上記エラーで失敗
- しかし Power Query の更新（取り込み自体）は成功 している
- 最近の Office 更新（とくに Excel Version 2508 周辺）を適用した直後から発生し始めた
Microsoft Q&A でも、2025 年 8 月以降の更新を適用した直後に同じメッセージでピボット更新だけが失敗するという報告が複数上がっており、Excel Version 2508（Build 17928.20114 付近）の更新が一つのトリガーになっていることが確認されています。
よくある構成パターン
実際にエラーが出ている事例を眺めると、次のような「重い」ピボット構成になっていることが多いです。
- 行ラベル・列ラベルに 多段の階層（部門 > 課 > チーム > 担当者…） を配置
- スライサーやレポートフィルターを多用している
- 複雑な DAX メジャー（IF + FILTER + CALCULATE など）を多く定義している
- 多対多関係や双方向フィルターを含む複雑なデータモデル
- 行・列の 総計・小計（Grand Total / Subtotal）をすべて有効 にしている
つまり、ピボットテーブルの「見た目上の複雑さ」が、そのまま内部エンジンの負荷増大に直結し、今回の “too many subcubes” エラーを誘発していると考えられます。
原因の正体：Power Pivot / VertiPaq エンジンの「サブキューブ」制限
サブキューブとは何か
Excel のデータモデルや Power Pivot の裏側では、SQL Server Analysis Services（SSAS）由来の VertiPaq / Analysis Services エンジン が動いています。このエンジンは、ピボットテーブルの集計を実行する際に、クエリを複数の「サブキューブ（subcube）」に分割して評価します。
Microsoft の SSAS 向けドキュメントでは、「Query optimizer generated too many subcubes in the query plan」 というエラーについて、以下のような説明がなされています（要約）。
- クエリ最適化の過程で、生成できるサブキューブの数に上限 がある
- 階層に非常に多くの計算メンバーがある、行・列に大量のフィールドやメンバーを並べる、総計や小計が多い…といった条件で上限に到達しやすい
- この制限は「設計上の仕様」であり、過度に重いクエリでサーバーリソースを使い果たすことを防ぐためのもの
Excel のピボットテーブル + データモデルの場合も同じ Analysis Services エンジンが使われているため、複雑なピボット構成・DAX・リレーションの組み合わせによって、内部のサブキューブ数が爆発すると同様のエラーが表に出てくる、という構図です。
Excel Version 2508 以降で報告が急増している理由
2025 年 8 月頃にリリースされた Microsoft 365 Excel Version 2508（Build 16.0.19127.20192 など）を境に、Power Query からデータモデルへ読み込み、さらにピボットテーブルで集計しているワークブックで、
- 「Query optimizer generated too many subcubes in the query plan」
- 「The PivotTable report is invalid. Try refreshing the data…」
といったエラーや、極端なパフォーマンス低下が多く報告されています。これらは Version 2507 にロールバックすると解消するケースが多く、2508 系ビルドでのレグレッション（後退バグ） と分析されています。
一部のビルドでは徐々に修正が進み、たとえば 16.0.19127.20240 以降では「多くの環境で改善した」との報告もありますが、構成によってはまだ影響を受けるケースもあるため、Excel のビルド確認と更新／ロールバックの検討 は今も重要な対処ポイントです。
サブキューブを増やしてしまう典型要因
| 要因 | サブキューブが増える理由 | 代表的な例 |
|---|---|---|
| 行・列のフィールド数が多い | 行×列×階層の組み合わせが指数的に増加する | 行に 8 フィールド以上を連ねたワイドなピボット |
| 総計・小計の多用 | 各階層・フィールドごとに追加集計が必要になる | 行・列とも Grand Total と Subtotal をすべて ON |
| 高カーディナリティ列 | ユニーク値が多い列でグループ化すると内部セットが巨大になる | 数百万行規模の明細を明細粒度のまま日付＋顧客＋商品でグループ |
| 複雑な DAX メジャーや計算列 | FILTER / IF / CALCULATE などで追加の評価コンテキストが多数生成される | 複数のネストした IF＋FILTER＋ALL などを多用したメジャー |
| 多対多・双方向フィルター | フィルター伝播のパターンが増え、計算すべき組み合わせが膨れ上がる | 事実テーブルどうしを直接多対多で結合しているモデル |
| 不要に複雑なスライサー・フィルター | フィルター条件の組み合わせごとに別のサブキューブが発生する | 複数年・複数カテゴリを同時に指定するスライサーの多重構成 |
最初に試したい対処：Office の修復と Excel ビルドの確認
根本原因は「モデルが複雑すぎる」ことですが、最近の更新でクライアント側が不安定になっている／ローカル環境が壊れている 可能性もあります。まずは Office 側の健康状態 をチェックしましょう。
Office の修復（クイック修復 → オンライン修復）
クリック トゥ ラン版 Microsoft 365 の場合、次の手順で修復を試します。
- Windows の「設定」または「コントロール パネル」から アプリと機能（またはプログラムと機能） を開く
- 一覧から Microsoft 365 Apps を選択し、変更 をクリック
- 最初は 「クイック修復」 を実行し、Excel を再起動して症状を確認
- 改善しない場合は、同じ手順で 「オンライン修復」 を実行（時間はかかるが効果が高い）
Microsoft Q&A の事例では、アンインストール → 再起動 → 再インストールという「フル再インストール」で現象が解消した例も報告されています。
- 修復の前には必ずブックのバックアップを作成
- 組織管理下の PC の場合は、自分で再インストールせず IT 部門に依頼
Excel のバージョン／ビルドを確認する
次に、現在利用している Excel のバージョンとビルド番号を確認します。
- Excel を開き、ファイル > アカウント をクリック
- 右側の「Excel のバージョン情報」をクリック
- 「バージョン 2508（ビルド 16.0.19127.xxxxx）」のような情報を控える
先述の通り、Version 2508（特に 16.0.19127.20192 周辺）はデータモデル＋ピボットで問題が出やすいことで知られており、Version 2507 へロールバックすると正常動作に戻るケースが多く報告されています。
| Excel バージョン／ビルド | リスクの目安 | 推奨アクション（例） |
|---|---|---|
| 2507（16.0.19029.x） | 低 | 問題がなければ継続利用。2508 以降に上げる前に検証端末でテスト。 |
| 2508（16.0.19127.20192） | 高 | 更新直後からエラーが出る場合は、新しいビルドへの更新 または 2507 へのロールバック を検討。 |
| 2508（16.0.19127.20222） | 中 | 一部改善だが、まだ問題が残るケースあり。重要ブックは検証のうえ、必要ならロールバック。 |
| 2508（16.0.19127.20240 以降） | 低〜中 | 多くの環境で改善報告あり。最新ビルドへ更新し、再度ピボット更新をテスト。 |
企業利用で「半期エンタープライズ チャネル」などの安定チャネルを利用している場合は、Current Channel の最新ビルドにすぐ乗り換えない という運用も有効です。更新チャネルの見直しやロールバック手順については、社内の IT 管理者と相談してください。
構造的な回避策：ピボット構成・データモデルの“簡素化”
Office やバージョンの問題を切り分けたうえで、なおエラーが続く場合は、ピボットとデータモデルの構造が根本原因 と考えて良いでしょう。ここから先は、モデルをシンプルにしてサブキューブの爆発を防ぐ アプローチです。
1. ピボットレイアウトを軽量化する
まずは、ピボットテーブルそのものの構成を見直します。
- 総計・小計をオフ にする
- デザイン > 総計 > 行と列の集計を行わない
- デザイン > 小計 > 小計を表示しない
- 行・列に並べるフィールドを 本当に必要なものだけに削る
- 1 つの巨大なピボットではなく、用途別に 2〜3 個のピボットに分割 する
- 「すべてのメンバー」を一度に並べるのではなく、上位レベル → 詳細レベル とシートを分ける
| レイアウトパターン | リスク | 推奨変更 |
|---|---|---|
| 行に 8 フィールド以上＋総計・小計すべて ON | 非常に高い | 行フィールドを 3〜4 個に削減し、総計・小計をオフ。必要ならピボットを複数に分割。 |
| 行 3〜5 フィールド、総計オフ、小計なし | 中程度 | 多くのモデルで実用範囲。パフォーマンスを監視し、問題があれば行フィールドをさらに削減。 |
| 行 1〜2 フィールド、総計・小計なし | 低い | サブキューブエラーは起きにくい構成。詳細分析は別ピボットで補完。 |
2. スライサー／フィルター／ページフィールドを一度外して“犯人”を特定
ピボットが複雑になりすぎている場合、どの要素がサブキューブを増やしているのか を見極めることが重要です。次のように段階的に確認すると効率的です。
- 問題のピボットシートをコピーして「検証用」シートを作る
- 検証用ピボットから、全てのスライサー・レポートフィルターを一旦削除
- 行・列のフィールドを最小構成（例：日付、売上金額のみ）にまで減らして更新
- エラーが出なければ、フィールドを 1 つずつ戻しながら更新 し、どの段階でエラーが再発するかを確認
- 特定のスライサーや階層を追加した途端にエラーになる場合、そのフィールドまわりを重点的に見直す
この「段階的な戻し」は手間はかかりますが、構造を変えずに原因フィールドを特定できる ため、根本対策を立てるうえで非常に有効です。
3. DAX 計算項目・計算列を整理する
サブキューブ数を増やしがちな DAX のパターンとして、次のようなものがあります。
- ネストが深い IF / SWITCH を多用しているメジャー
- FILTER ＋ ALL / ALLEXCEPT を組み合わせた複雑な条件式
- 行コンテキストを多用する EARLIER ベースの計算列
- RELATEDTABLE を使った「暗黙のループ」になっているような計算
可能であれば、次の方針で整理します。
- 暗黙の集計（ピボットの「値」欄にフィールドを直接ドラッグ）ではなく、DAX メジャーで明示的に集計 する
- 条件分岐や派生項目を、Power Query 側で前処理 してしまう
- どうしても複雑なメジャーが必要な場合は、中間メジャー を作ってロジックを分割する
4. リレーションシップ設計の見直し（多対多・双方向フィルターを避ける）
VertiPaq エンジンは、いわゆる スター・スキーマ（事実テーブル＋ディメンションテーブル） で最も性能を発揮します。
- 中心に 売上・仕入などの事実テーブル
- 周囲に顧客・商品・日付・店舗などの ディメンションテーブル
- リレーションは原則 1 対多（ディメンション → 事実）で一方向
次のような構成は、サブキューブ・性能の両面で要注意です。
- 事実テーブルどうしを直接結ぶ多対多リレーション
- リレーションの方向を安易に「双方向」にしている
- ユニーク値が数百万以上ある列でリレーションを張っている
多対多がどうしても必要な場合は、ブリッジテーブルの導入や、粒度を上げた事前集約を検討しましょう。
5. Power Query での前処理を強化する
Power Query は「フォーム化された ETL ツール」として非常に優秀で、次のような前処理を行うことで、データモデル側の負荷を確実に減らせます。
- 不要な列を読み込まない（「列の削除」 で早い段階に削る）
- 必要な期間だけに絞る（例：直近 3 年のみ）
- 日単位 → 月単位など、粒度を上げて事前集約する
- フラグ・ランク・カテゴリ分けなどの派生列は Power Query 側で生成する
- 巨大なテーブルを用途別のクエリに分割し、それぞれを別ピボットで利用する
| Power Query 前処理 | 主な効果 |
|---|---|
| 列削減（不要列を削る） | メモリ削減＋関係や計算で扱う情報が減り、クエリ計画がシンプルに |
| 期間フィルター（直近 n 年のみ） | ディメンションのメンバー数を減らし、高カーディナリティ問題を緩和 |
| 事前集約（明細 → 月単位など） | 行数が大幅に減り、集計・フィルター時のサブキューブ数も抑えられる |
| 派生列の作成（フラグ・ランクなど） | DAX メジャーの複雑さを軽減し、式評価の負担を減らす |
追加のトラブルシュート：切り分けのためのテクニック
新規ブックで「最小構成」から再現させてみる
既存ブックは歴史的経緯で「何がどこに効いているのか分からない」状態になりがちです。次の手順で、別ブックに 最小構成の再現モデル を作ると、原因切り分けがしやすくなります。
- Power Query のクエリを、必要なものだけ コピーして新規ブックに貼り付け る
- データモデルに読み込み、最小限のリレーションだけを設定
- 行 1〜2 フィールド、値 1 メジャー程度のシンプルなピボットを作成
- ここでエラーが出るか／出ないかを確認
- 問題がなければ、元ブックに近づける形でフィールドやメジャーを追加し、どこで再現するか追う
この方法で「モデルそのものが限界なのか」「特定のフィールドやメジャーがトリガーなのか」が見えやすくなります。
Excel セーフモードでアドインの影響を切り分ける
まれに、COM アドインやサードパーティ製アドインがピボット動作に悪影響を与えているケースもあります。次の手順でセーフモード起動を試してみましょう。
- Win + R キーで「ファイル名を指定して実行」を開く
excel /safeと入力して Enter- セーフモードでブックを開き、同じピボットを更新してみる
セーフモードでエラーが出ない場合は、アドインの無効化や更新も検討ポイントになります。
キャッシュのクリアとデータモデル再計算
分析エンジン自体のレグレッションが根本原因であっても、ローカルキャッシュや一時データの破損が症状を悪化させていることがあります。以下も併せて試してみてください。
- Power Query キャッシュのクリア
- データ > データの取得 > クエリ オプション
- 「グローバル > データ読み込み」から「すべてのキャッシュをクリア」
- ブックの再計算
- Ctrl + Alt + F9 で全ブック強制再計算
- Power Pivot ウィンドウでの再計算
- Power Pivot ウィンドウを開き、「計算の再実行」や「テーブルの更新」を実行
再発防止のための運用・設計のコツ
検証用チャネル・検証用端末を用意する
今回のように、更新によってデータモデル関連の挙動が変わることは珍しくありません。業務ブックへの影響を抑えるには、次のような運用が有効です。
- 本番用 PC とは別に、検証用 PC / 仮想環境 を用意する
- 検証用には Current Channel など新しめのチャネル、本番には Semi-Annual Channel を割り当てる
- 重要なブックは、新バージョンで必ず動作確認 をしてから本番環境を更新する
データモデル設計のガイドラインを決める
大規模な Excel データモデルを運用するのであれば、チーム内で次のような「モデル設計指針」を共有しておくと安全です。
- スター・スキーマを基本 とし、事実テーブル＋ディメンションテーブルで構成
- 多対多・双方向フィルターは避け、1 対多・単方向 を原則とする
- 高カーディナリティ列でのリレーションやグループ化は極力避ける
- 暗黙の集計ではなく、メジャー中心の設計 を徹底
- 細かすぎる粒度のデータは、必要に応じて事前集約する
- 1 つのブックにすべて詰め込まず、「用途別にブック／モデルを分割」する
「1 レポート = 1 目的」を徹底する
どうしても「なんでもできる超リッチなピボット」を作りたくなりますが、それが今回のようなエラーやパフォーマンス問題を招きます。運用上は、
- 「売上ダッシュボード」「仕入分析」「在庫分析」など、目的ごとにピボットとモデルを分割
- 共通ディメンション（カレンダー・顧客マスタなど）は別クエリとして再利用
- それぞれのレポートでは、必要最低限の軸とメジャーに絞る
といった方針に切り替えることで、サブキューブエラーを避けつつ、メンテナンス性も上げる ことができます。
クイックチェックリスト
実際に “too many subcubes” エラーが出たときに、上から順番に確認したい項目をチェックリストとしてまとめます。
- Office の クイック修復／オンライン修復 を実施した
- Excel のバージョン／ビルドを確認し、2508 問題のあるビルドではないか をチェックした
- 必要に応じて 最新ビルドへの更新、または 2507 へのロールバック を検討した
- 問題のピボットをコピーし、スライサー・フィルター・行列フィールドを一旦すべて外してから、1 つずつ戻して トリガーとなるフィールド を特定した
- 総計・小計をオフにし、行・列フィールドを最小限に削減した
- 多対多・双方向フィルターを解消し、スター・スキーマ＋単方向リレーション に近づけた
- Power Query で不要列の削除・期間フィルター・事前集約などの前処理を行った
- 暗黙の集計をやめ、DAX メジャー中心の構成に整理した
- 新規ブック＋最小モデルで再現実験を行い、構造的な限界かどうかを見極めた
- 検証用環境で新ビルドを試し、本番環境へのロールアウト前に動作確認する運用に切り替えた
まとめ：修復＋簡素化の二本柱で切り分け、そのうえで更新戦略を決める
“the query optimizer has encountered a complexity that it can’t handle, typically due to too many subcubes in the data model” というメッセージは、「Excel の不具合」だけでなく、内部エンジンの設計上のリミットに近づいているサイン でもあります。Version 2508 周辺の更新でこのリミットに触れやすくなったことは事実ですが、構造的に重すぎるモデルであれば、いずれどこかのタイミングで同様の問題に直面する可能性が高いと言えます。
実務的には、
- Office の修復／再インストール と Excel ビルドの確認・更新／ロールバック で環境要因を切り分ける
- 並行して、ピボットレイアウト・データモデル・DAX・Power Query 前処理を見直し、サブキューブを増やす要因を一つずつ潰していく
- 原因と対策が見えたところで、更新チャネルとモデル設計の運用ルール を整える
という「二本柱」アプローチが現場では現実的です。
一見すると難解なエラーですが、一度「どこまでやると壊れるか」「どこまで簡素化すると安定して動くか」が分かると、以後のモデル設計の方針も見えてきます。本記事を参考に、ご自身の環境で「ちょうどよい複雑さ」を探りつつ、安定した Excel データモデル運用を実現していただければ幸いです。
コメント