2025年8月以降の更新で、Microsoft 365版 Excel のデータモデル（Power Pivot）に接続したピボットテーブルが、突然「極端に遅い」「更新に失敗する」といった現象を起こしています。Version 2508 以降で再現性が高く、従来は問題なかった業務ブックが止まってしまうケースも少なくありません。本記事では、具体的な症状と原因の背景、そして今すぐ使える現実的な回避策・設計指針をまとめます。
Excel 2508 以降で発生している問題の概要
まず、今回の問題の前提条件を整理します。
- 対象製品：Excel for Microsoft 365（デスクトップ版・64bit）
- OS：Windows 10 / Windows 11
- データ接続：データモデル（Power Pivot）に接続したピボットテーブル
- 発生するバージョン：
- Version 2508（Build 19127.20154 / 19127.20192 以降）
- Version 2509（Build 19231.20044）でも継続報告あり
- 正常と確認されているバージョン：Version 2507（Build 19029.20208）
Microsoft Q&A では、Version 2508 へ更新した直後から、データモデルに接続したピボットテーブルの操作が指数関数的に遅くなる、もしくは更新に失敗するという報告が複数上がっています。
| Excel バージョン | ビルド番号 | リリース日 | 状態（本件との関係） |
|---|---|---|---|
| 2507 | 19029.20208 | 2025/08/19 | データモデル接続ピボットは正常と報告多数 |
| 2508 | 19127.20154 | 2025/08/26 | 更新直後からパフォーマンス急悪化・エラー多発 |
| 2508 | 19127.20192 | 2025/09/03 | 同様の遅延・エラーが継続 |
| 2508 | 19127.20222 / .20240 / .20264 | 2025/09/09 以降 | 「各種パフォーマンス改善」とあるが、ピボット退行を明示した修正記載はなし |
| 2509 | 19231.20044 | 2025/09/上旬 | 同様の遅さやメモリ不足が続くとのユーザー報告あり |
具体的な症状：行フィールド数に比例して「倍々ゲーム」で遅くなる
Microsoft Q&A の代表的な事例では、次のような 極端なパフォーマンス退行 が報告されています。
| バージョン | 行フィールド数 | メジャー数 | スライサー操作時の更新時間 |
|---|---|---|---|
| 2507 | 20 | 10 | 約 7 秒 |
| 2508 | 10 | 0 | 約 15 秒 |
| 2508 | 11 | 0 | 約 31 秒 |
| 2508 | 12 | 0 | 約 70 秒 |
行フィールドを 1 つ増やすたびに、ほぼ前回の 2 倍の時間がかかるという「倍々ゲーム」のような増え方をしており、従来の挙動とは明らかに異なります。
さらに、以下のような報告も共通しています。
- 単一のフラットテーブル（リレーションなし／計算列なし／メジャーなし）でも再現する
- Excel を再起動しても、別 PC でも同じブックで同じ症状が出る
- 行フィールドを一定数以上にすると、更新に失敗してエラーになる
エラー例：「Query optimizer generated too many subcubes…」
遅くなるだけでなく、次のようなエラーが出て更新に失敗するケースも多く報告されています。
The query did not run or the Data Model could not be accessed.Query optimizer generated too many subcubes in the query plan.- 「メモリが不足しているためピボットテーブルを更新できません」等のメモリ不足メッセージ
特に Query optimizer generated too many subcubes in the query plan は、Analysis Services／データモデルが内部で生成する「サブキューブ」の数が上限を超えたときに発生するもので、SSAS の公式ドキュメントでも説明されている既知の制限です。
データ量が小さくても発生する
「数十万行以上の巨大データだから遅い」のではなく、次のような ごく小さなモデルでも問題が起きる ことが確認されています。
- 行数 1,000 行未満、ファイルサイズ 7〜8MB 程度の Power Pivot モデル
- 関係を持たない単一テーブルのみのデータモデル
- DAX メジャーが少ない、もしくはメジャーなしのピボット
つまり、今回の現象は「データが大きすぎる」ことよりも、ピボットの構造（行フィールドの数・小計・空アイテム表示など）とバージョンによるクエリ最適化の違いに起因していると考えられます。
現時点での公式見解と位置づけ
Microsoft Q&A において、モデレーターからは次のような説明がなされています。
- 2025年8月の更新で配布された Microsoft 365 Apps Version 2508 適用以降、同様のエラーが複数ユーザーから報告されている。
- 根本は Analysis Services エンジンの仕様によるもので、サブキューブ数の上限に達するとエラーになるのは「設計通り」の動作。
- ただし Version 2508 でその閾値（制限）が以前よりも厳しくなった可能性があり、以前は問題なかったモデルにもエラーが出るようになった。
Office のリリースノート（Current Channel）には、Version 2508 以降で「さまざまな機能とパフォーマンスの修正」といった記述はあるものの、このピボットテーブル退行を直接言及した項目は現時点で確認できません。
また、Current Channel (Preview) の 2509 ではデータモデリングエンジンのメンテナンスアップデートに関する記述がありますが、「Excel データモデルの挙動は目に見えて変わらない」と明記されており、劇的な修正は期待しにくい表現になっています。
即効性の高い回避策：優先度順
ここからは、「業務を止めない」ことを最優先にした現実的な対処法を、優先度順に整理します。
1. 最優先は安定版へのロールバック（Version 2507 へ戻す）
すでに業務に支障が出ている場合、もっとも確実なのは Excel を Version 2507（Build 19029.20208）へ戻す ことです。
クリック トゥ ラン（C2R）版での代表的な手順
- すべての Office アプリを終了する。
- 「スタートメニュー」で cmd と検索し、「管理者として実行」でコマンドプロンプトを開く。
- 次のコマンドを順に実行する（パスは環境に応じて調整）。
cd "C:\Program Files\Common Files\Microsoft Shared\ClickToRun"
OfficeC2RClient.exe /update user updatetoversion=16.0.19029.20208
実行後、Office のセットアップ画面が表示され、いったん現在のバージョンがアンインストールされたのち、指定したバージョンがインストールされます。これは Microsoft が案内している「以前のバージョンに戻す」標準的な方法です。
ロールバック完了後は、Excel のメニューから [ファイル] > [アカウント] > [更新オプション] を開き、「更新を無効にする」（または「更新を有効にする」のチェックを外す）を選んでおきましょう。自動更新が再度 2508 以降を適用してしまうのを防ぐためです。
組織配布の場合（IT 管理者向け）
- Office Deployment Tool（ODT） の構成ファイルで
TargetVersionを 16.0.19029.20208 に固定し、一時的にそのバージョンを展開する。 - 更新チャネル（Current Channel / Monthly Enterprise など）を統一し、テスト用リング → パイロット → 全社展開 の 3 段階で更新を管理する。
- グループポリシーや Intune で「自動更新の一時停止」ポリシーを設定し、修正ビルドが安定するまで不用意に 2508 以降へ上がらないよう制御する。
2. 行フィールドを減らし、ピボット構造をシンプルにする
ロールバックがすぐに実施できない場合は、ピボットテーブルの構造を見直して「サブキューブ爆発」を抑える 手が最も効果的です。
行フィールドを「10 個以下」を目安に抑える
Version 2508 では、行フィールド数が 10 を超えたあたりから、更新時間が倍々に増えていく事例が多数報告されています。
- レポート設計の標準として、1 つのピボットで行フィールドは 10 個以内に収める。
- それ以上の軸が必要な場合は、複数のピボットに分割する（後述）。
小計・総計をオフにする
SSAS のドキュメントでも、グランドトータルや小計のオンがサブキューブ数を増やし、エラーを誘発しやすい と明記されています。
Excel 側では次の設定を見直します。
- [ピボットテーブル デザイン] > [小計] > 「小計を表示しない」
- [ピボットテーブル デザイン] > [総計] > 「行と列の集計を表示しない」
レポートとして総計が必須なら、すべてを 1 つのピボットでやろうとせず、「明細用ピボット」と「総計・指標サマリー用ピボット」を分ける ことで負荷を分散できます。
「データのないアイテムを表示」をオフにする
「データのないアイテムを表示」がオンになっていると、実際には存在しない組み合わせまで事前に展開しようとするため、サブキューブ数が一気に増えます。
各行フィールドで、以下のように設定を見直します。
- 行フィールド名の右側のドロップダウンをクリック
- [フィールドの設定] を選択
- [レイアウトと印刷] タブで 「データのない項目を表示する」 のチェックを外す
レイアウトを「表形式」にし、多段階ネストを避ける
コンパクト形式で多段階ネストをしていると、内部的にはより複雑な MDX が生成され、サブキューブ数が増えがちです。
- [デザイン] > [レポートのレイアウト] から 「表形式で表示」 を選ぶ
- 「レポートのレイアウト」で「アイテムをラベルとして繰り返す」を多用しない
1 つの巨大ピボットを、テーマ別に分割する
よくある「ダメな例」は、次のようなピボットです。
- 行：事業部 > 部門 > 拠点 > 担当者 > 製品 > 日付 …
- 列：指標カテゴリ
- 小計・総計すべてオン、スライサーも多数
この場合は、思い切って次のように分割する方が安全です。
- 売上サマリー用ピボット（年度 × 部門レベル）
- 商品別詳細用ピボット（製品 × 月）
- 地域トレンド用ピボット（地域 × 四半期）
それぞれのピボットは 行 2〜3 階層程度 に抑え、必要ならスライサーを共有して連動させる構成にすると、「1 つのピボットでサブキューブ上限をたたく」危険が大きく減ります。
Power Query で「事前集計」してからデータモデルに載せる
明細レベルのトランザクションをそのままデータモデルに載せていると、ピボット側の集計と合わせて負荷が二重にかかります。
具体的には、Power Query で以下を行います。
- [グループ化] で、日次 → 月次、部門別などにあらかじめ集約したテーブルを用意する
- ピボットで使わない列は Power Query 側で削除し、データモデルには最低限の列だけを載せる
- 高カーディナリティ（値の種類が非常に多い）列は、ピボットの行/列に出さず、別テーブルや明細シートで表示する
| ボトルネック | 対処 | 期待される効果 |
|---|---|---|
| 行・列の階層が深すぎる | 行/列を 2〜3 階層に削減 | サブキューブの組み合わせを大幅に削減 |
| フリーテキスト列を行に出している | 備考などは別シートに分離 | 辞書サイズとクエリ複雑度の低減 |
| 明細のままモデルに載せている | Power Query で月次・部門単位に事前集計 | データモデル側の計算負荷を軽減 |
3. 更新チャネルを切り替え／固定して「リング運用」する
今回のように、Current Channel に突然重いバグ・仕様変更相当が流れ込むリスクを減らすには、組織側で更新チャネルを使い分けるのが有効です。
- テストリング：IT 部門・Excel 上級ユーザーのみ Current Channel
- パイロット：一部の代表部門を Monthly Enterprise に
- 本番：安定重視の部門は Semi-Annual / Monthly Enterprise 固定
このようにチャネルと展開タイミングを分けることで、代表的な業務ブックで事前に動作確認を行い、安全を確認したうえで全社展開するという流れを作れます。
4. 更新エラーやメモリ不足が出るブックの「局所化」
すでにエラーが出てしまっているブックは、次のような手順で「どこが限界なのか」を特定し、被害を局所化します。
- 問題のブックをコピーし、検証用に使う
- ピボットテーブルを 1 つずつ無効化（行フィールドを減らす／ピボット自体を削除）し、どのピボットが閾値を超えているかを確認
- 直近使っていないメジャーや不要なシートを削除し、モデルの複雑度を下げる
- ピボットテーブルのオプションから、[データ] > 「詳細データの表示を許可する」 のチェックを外し、ダブルクリックでの明細展開を無効化してクエリを軽くする
なぜ起きているのか：MDX とサブキューブの仕組み
ここからは少し踏み込んで、今回の現象の背景にある技術的な仕組みを簡単に整理します。
Excel データモデルと MDX クエリ
Excel のデータモデル（Power Pivot）は内部的に SQL Server Analysis Services（SSAS）Tabular とほぼ同等のエンジン（VertiPaq）で動いており、ピボットテーブルはこのエンジンに対して MDX（Multidimensional Expressions） で問い合わせを投げています。
行・列・フィルター・スライサーに配置されたフィールドの組み合わせに応じて、MDX クエリは内部で多くの「サブキューブ」を生成しながら最適な実行計画（クエリプラン）を探します。
「too many subcubes」エラーの正体
Microsoft の SSAS 向けドキュメントでは、次のような条件で Query optimizer generated too many subcubes in the query plan エラーが発生すると説明されています。
- 同じ階層レベルに多数の計算メンバーが定義されている
- 行や列に多くのフィールド・属性メンバーが配置されている
- 選択された階層のすべてのメンバーが軸に含まれている
- グランドトータルや小計がオンになっている
つまり、軸やメジャーの組み合わせが増えれば増えるほど、クエリ最適化のために必要なサブキューブが爆発的に増え、ある上限に達したところでエラーになる、という挙動です。
| 要因 | サブキューブ増加の理由 | 緩和策の例 |
|---|---|---|
| 行・列のフィールドが多い | 軸の組み合わせが指数関数的に増える | 行フィールド 10 個以下に制限、複数ピボットへ分割 |
| グランドトータル／小計オン | 各レベルで追加の集計セットが必要になる | 不要な総計・小計はオフにする |
| 「データのない項目を表示」オン | 実データが無い組み合わせまで事前展開される | 必要な帳票以外ではオフにする |
| 多数の計算メンバー／メジャー | 評価パターンが増え、クエリプランが複雑化 | 使っていないメジャーを整理し、定義をシンプルにする |
Version 2508 で何が変わったのか（推測）
Microsoft から「サブキューブ上限を具体的に変更した」という公式発表は出ていませんが、Q&A モデレーターの説明やコミュニティ報告を総合すると、以下のような変化が推測されます。
- Analysis Services エンジンの内部メンテナンスにより、サブキューブの生成ロジックや上限値が見直された。
- その結果、以前は「ギリギリ許容されていた」ような複雑なピボットクエリが、2508 以降では上限に達してエラーになりやすくなった。
- 同時に、上限手前で踏みとどまっているクエリは、極端な時間をかけて完了する（今回のような倍々に増える遅延）状態になっている。
特に 64bit 版 Excel 2508 を使っているユーザーが影響を受けやすく、同じブックでも 32bit の旧バージョンでは問題ないという報告もあります。
影響範囲の整理：どの環境が危険か？
コミュニティ報告や技術ブログの内容を踏まえると、本件の影響を受けやすい条件は次の通りです。
- Microsoft 365 Excel Version 2508（Build 19127.20192 以降）
- Power Query の読み込み先で 「このデータをデータモデルに追加」 をオンにしている
- データモデルを参照するピボットテーブルに、多数の行フィールド・小計・総計・計算メンバーを含んでいる
- スライサーやフィルターが多く、組み合わせが爆発的に増えるレポート
- Excel 64bit 版（特に Current Channel）
逆に言うと、次のような構成では影響が小さくなる傾向があります。
- Power Query からワークシートへ直接読み込み（データモデルを使わない通常ピボット）
- 行・列フィールドが少なく、小計・総計もオフにしている単純なピボット
- データモデルは使うが、CUBE 関数で必要なセルだけを読み出している構成
推奨ワークフロー：短期・中期・長期の対策
短期：業務継続を最優先に 2507 へロールバック
- 重要な生産管理・財務レポートなど、業務影響の大きいブックは Version 2507 で動かす環境 を優先的に確保する。
- ユーザーが自力で戻せない場合は、IT 部門が一括でロールバック＋自動更新の停止を実施する。
並行して：検証用端末で新ビルドの挙動を測定
修正ビルド（2508 の後続ビルドや 2509 以降）が出たら、いきなり本番に適用するのではなく、必ずテスト用端末で次のような検証を行います。
- 同じブックを 2507 と 2508/2509 で開き、行フィールド 8 → 9 → 10 → 11 → 12… と増やしながら更新時間を測定する
- 小計・総計・空アイテム表示のオン／オフで、どの程度パフォーマンスが変わるかを見る
- 通常ピボット（データモデルなし）に置き換えた場合の挙動を比較する
恒久対策：「設計標準」としてルール化する
一度落ち着いたとしても、今後も同種の変更が入る可能性はゼロではありません。そこで、次のような「レポート設計標準」を社内ルールとして明文化しておくことをおすすめします。
- データモデルを使うピボットは「行フィールド 10 個以下」を目安にする
- 小計・総計は原則オフ。必要な場合は別ピボットで表現する
- 「データのない項目を表示」は原則オフ。例外が必要な帳票は個別に設計
- 明細・集計・ダッシュボードを 1 ブックに詰め込まず、用途別にブックやシートを分割する
- Power Query 側でできるだけ前処理・集約を行い、データモデルの役割を「最終集計」に絞る
Microsoft へのフィードバックとサポートケース起票
製品側の改善を促すためには、ユーザー側からのフィードバックも重要です。
- Excel から [ファイル] > [フィードバック] > [問題を報告] を開き、
- Excel のバージョン（例：Version 2508 Build 19127.20192）
- エラーメッセージ全文（スクリーンショット付きが望ましい）
- どのようなブックで、どの操作をしたときに再現するか
- 管理者は Microsoft 365 管理センター > サポート からケースを起票し、業務影響の大きさを明示します。
最小チェックリスト：まずここから確認する
最後に、「とりあえず何から見ればよいか」のミニチェックリストを載せておきます。
| チェック項目 | 目的 | 目安・判断基準 |
|---|---|---|
| Excel の Version / Build を確認 | 問題のバージョンかどうかを把握 | 2507 なら正常、2508 / 2509 なら要注意 |
| 行フィールド数を 1 つずつ増減して挙動を見る | 閾値となる行フィールド数を特定 | 10 → 11 → 12… と増やして指数的な遅延が出るか確認 |
| 小計・総計・空アイテム表示のオン／オフを試す | サブキューブ数に効く設定を見極める | オフにしただけで劇的に改善するケースも多い |
| 通常ピボットに置き換えて比較 | データモデル固有の問題かどうかを切り分け | 通常ピボットが速く、データモデルだけ遅いなら本件の影響濃厚 |
| Power Query で事前集計した場合を検証 | データの粒度と列数を減らしたときの改善度を把握 | 更新時間が大幅に縮むなら、恒久的な設計変更候補 |
まとめ：いま取るべき現実的なアクション
ここまで見てきたように、Version 2508 以降の Excel では、データモデル（Power Pivot）経由のピボットテーブルに対するクエリ最適化の挙動が変わり、「サブキューブ上限」に引っかかりやすくなったと考えられます。
現時点での現実的な指針をあらためて整理すると、次の通りです。
- 業務継続が最優先なら、まずは Version 2507 にロールバックし、自動更新を一時停止する。
- すぐに戻せない環境では、行フィールド削減＋小計／総計オフ＋「データのない項目を表示」オフ＋事前集計 を組み合わせて、サブキューブ数を減らす。
- テストリングを設け、2508 の後続ビルドや 2509 以降の挙動を、代表的な業務ブックで継続的に検証する。
- レポート設計標準を整備し、「巨大な 1 枚のピボットにすべて詰め込む」スタイルからの卒業を図る。
- Excel からのフィードバックと管理センターからのサポートケース起票で、製品側への改善要望を継続的に伝える。
データモデルや Power Pivot 自体は非常に強力な機能であり、「今回の件があったからもう使わない」と決めてしまうのはもったいない側面もあります。短期的には 2507 へのロールバックで業務を守りつつ、中長期的には「行フィールドを絞る」「小計・総計を慎重に使う」「事前集計とモデル設計を工夫する」といったアプローチで、より堅牢な Excel 分析基盤に育てていくのが現実的な落としどころと言えるでしょう。
コメント