Excelが遅い本当の原因 ― メモリスワップと数式設計の関係
本稿の信頼性について
本稿は、低スペック環境での実務経験、Microsoft公式ドキュメント、Excel MVPの検証記事、コミュニティの議論を基に構成しています。ある程度の実機テストを行ったうえで作成していますが、すべてのパターンを網羅的に検証したわけではありません。本稿の内容は「なぜ遅くなるのか」「どう設計すれば改善できるのか」の考え方を説明するものであり、環境やバージョン、データ構成によって結果が異なる場合があります。
読者ご自身の環境で実際に計測し、結果を確かめたうえで適用されることを推奨します。もし本稿と異なる結果が得られた場合は、そちらが正しい可能性があります。
1. 「関数を変えても遅いまま」の正体
Excelの高速化というと、「VLOOKUPをINDEX+MATCHに変えろ」「SUMPRODUCTをCOUNTIFSに変えろ」といったアドバイスをよく見かけます。しかし、これらの関数を置き換えても体感速度がまったく変わらないケースが少なくありません。
原因はシンプルです。Excelが遅い最大の理由は、関数の処理速度ではなく、メモリ不足によるスワップ（ページング）にあるからです。メモリに乗り切らないデータがディスクに退避され、再計算のたびにディスクから読み直す処理が発生すると、関数の速度差など誤差に埋もれるほどの遅延が起きます。
本稿では、この「スワップ」を軸に、Excelが遅くなるメカニズムと、数式設計レベルでの対策の考え方を解説します。
2. RAM・SSD・HDDの速度差 ― 200倍の壁
まず、Excelの計算がどこで行われるかを理解する必要があります。通常、セルのデータや数式はRAM（メインメモリ）に展開され、CPUが処理します。RAMは極めて高速ですが、容量に限りがあります。
物理メモリが不足すると、Windowsは使用頻度の低いデータをディスク上の「ページファイル」に退避します。これがスワップです。再びそのデータが必要になると、ディスクからRAMに読み戻す「ページイン」が発生します。この読み戻しの速度がボトルネックになります。
| 媒体 | 読み書き速度 | RAMとの速度比 |
|---|---|---|
| RAM（DDR4） | 20,000〜60,000 MB/s | 1倍（基準） |
| NVMe SSD | 3,000〜7,000 MB/s | 約 1/10 |
| SATA SSD | 400〜550 MB/s | 約 1/50〜1/100 |
| HDD（7200rpm） | 80〜160 MB/s | 約 1/200〜1/500 |
HDDにスワップが発生した場合、RAMと比べて200倍以上遅くなります。0.1秒で終わるはずの再計算が20秒以上かかり、実質フリーズに見えることになります。SSDであればスワップ時の影響は大幅に軽減されますが、それでもRAMの10分の1〜100分の1の速度であり、根本的な解決にはなりません。
3. 32ビットExcelのメモリ制限と「4GBのPC」の現実
32ビット版Excelは、Excel 2013以降のLAA（Large Address Aware）対応により、64ビットWindows上で最大4GBの仮想メモリを使用できます。それ以前のバージョンでは上限は2GBでした。
しかし、「使用できる」と「実際に使える」は異なります。物理メモリが4GBのPCでは、Windows 10自体が約1.5〜2GBを消費し、ウイルス対策ソフト・常駐サービス・社内管理ツールなどが0.5〜1GB使います。合計で約2.5〜3GBが占有され、Excelに残るのは1〜1.5GB程度。最悪の場合、1GB未満になることもあります。
32ビットExcelが4GBまでアドレス可能であっても、物理メモリが1GBしか空いていなければ、残り3GBはすべてディスクへのスワップになります。数万行のブックに複数の検索関数が入っていれば、1セル変更するたびにスワップが走り、数秒〜数十秒の遅延が発生します。
つまり「4GBのPCで32ビットExcelを使う」という構成は、構造的にスワップが避けられないのです。
4. VLOOKUP vs INDEX+MATCH ― 速度ではなくメモリ消費の差
「VLOOKUPよりINDEX+MATCHが速い」という話はよく見かけますが、通常のメモリ環境ではその差はごくわずかです。しかし、スワップが発生する環境では話が変わります。両者はメモリに展開するセル数が大きく異なる可能性があるからです。
4-1. メモリ展開セル数の比較
VLOOKUPは検索列から結果列まで、指定した範囲の全列をメモリに展開する必要があります。一方、INDEX+MATCHは検索列と結果列の2列だけで済みます。
例：B列で検索し、F列の値を返す場合（5,000行）
→ B〜F列の5列 × 5,000行 = 25,000セルを参照範囲に含む
→ B列 + F列の2列 × 5,000行 = 10,000セルのみ参照
| テーブル列数 | VLOOKUP 参照セル数 | INDEX+MATCH 参照セル数 | 比率 |
|---|---|---|---|
| 5列 | 25,000 | 10,000 | 2.5倍 |
| 10列 | 50,000 | 10,000 | 5倍 |
| 20列 | 100,000 | 10,000 | 10倍 |
| 関数 | 参照セル数 | 概算メモリ（1セル16バイト想定） |
|---|---|---|
| VLOOKUP | 600,000 | 約9.2 MB |
| INDEX+MATCH | 60,000 | 約0.9 MB |
メモリに余裕がある環境（64ビットExcel・16GB RAM）では、この差は体感に影響しません。しかし、4GBメモリの32ビットExcelでExcelに残るRAMが1GB以下の状態では、VLOOKUPの広い参照範囲がメモリ消費を増大させ、スワップの引き金になりやすいと考えられます。
⚠ 注意：Excelが参照範囲内の全セルを同時にメモリに展開するか、必要な列だけを読むかは内部実装に依存し、Microsoftは詳細を公開していません。上記は「参照範囲が広いほどメモリ消費が増える傾向がある」という考え方として理解してください。
4-2. XLOOKUPのメモリ消費
Microsoft 365 / Excel 2021以降で使用できるXLOOKUPは、検索列と結果列を個別に指定するため、INDEX+MATCHと同様に2列分の参照で済みます。メモリ効率の観点ではVLOOKUPよりXLOOKUPが優れていると考えられます。
→ B列 + F列の2列 × 5,000行 = 10,000セル（INDEX+MATCHと同等）
5. Excelの内部キャッシュ ― 同一範囲の使い回し
5-1. キャッシュの仕組み
Excel 2016以降（Office更新プログラムが適用されている環境、具体的にはOffice 365〔現Microsoft 365〕version 1809 / 2018年9月以降のビルド）では、VLOOKUP / HLOOKUP / MATCHが同一テーブル範囲を完全一致検索する際、最初の検索で内部キャッシュインデックスを構築し、以降の数式で再利用します。Excel 2021 / 2024 および Microsoft 365 では基本的にこの機能が含まれています。
Microsoftの公式テストでは、5列の同一テーブルに対するVLOOKUP 100行がExcel 2010で37秒 → Excel 2016で12秒に短縮されたと報告されています。
同様に、SUMIFS / COUNTIFS / AVERAGEIFS等も、Office 365（現Microsoft 365）version 2005（2020年6月）以降で内部キャッシュが導入され、100万セルからの1,200件のSUMIFS集計がExcel 2010の20秒 → 8秒に改善されています。
出典：Excel performance and limit improvements - Microsoft Learn
このキャッシュは名前の定義の有無に関係なく、セルに直接記述した参照でも機能します。条件は「すべての数式が完全に同一の範囲を参照していること」です。
5-2. キャッシュが効かなくなるケース
相対参照で数式をコピーすると、行がずれた時点で参照範囲が変わり、キャッシュが効かなくなります。
絶対参照で固定すれば、すべてのセルが同一の範囲を参照し、キャッシュが有効になります。
→ どのセルにコピーしても参照先は常に D1:H5000 → キャッシュ有効
なお、$D$1:$H$5000 と D1:H5000 は「ドルマーク自体」が違うのではなく、コピー先で実際に指すアドレスが一致するかどうかが判定基準です。すべてのセルが結果的に同じ範囲を指していればキャッシュは効きます。ただし、実務上は絶対参照で統一するのが確実です。
💡 名前の定義のメリットは保守性
名前の定義を使っても、計算速度やメモリ効率が向上するわけではありません。名前の定義の利点は可読性と保守性にあります。範囲の変更が一箇所で済み、数式の参照範囲不一致（＝キャッシュ無効化）を防止できるため、間接的にパフォーマンス維持に寄与します。ただし、名前の定義にOFFSETなどの揮発性関数を含めると毎回再評価されるため、逆効果になる場合があります。
6. スワップ環境で効く数式設計の考え方
ハードウェアの増強が最も効果的な対策ですが、企業のPCは情報システム部門が一括管理し、簡単にはメモリ増設やSSD換装ができないのが現実です。ここでは、数式設計レベルでスワップの影響を軽減するための考え方を整理します。
6-1. 参照範囲の最小化 ― 列全体参照の実態
列全体参照（例：B:B）について、「104万行をメモリに展開するから遅い」という説明をよく見かけますが、これは正確ではありません。
Excel MVP の Charles Williams 氏（FastExcel）による実測テストでは、SUM、VLOOKUP、MATCH、COUNTIFなどの主要関数は、列全体参照であってもUsedRange（使用範囲）の最終行までしか評価しないことが確認されています。つまり、データが5,000行ならSUM(A:A)は5,000行分しか計算しません。
ただし、以下のケースでは列全体参照が問題になります。
出典：Excel Full Column References and Used Range: Good Idea or Bad Idea? - FastExcel
したがって、列全体参照が直ちに遅くなるわけではありませんが、以下の理由から実データ範囲に絞る方が安全です。
6-2. IF空白判定による処理スキップ
作業列にコピーした数式で、データが空白の行では重い計算を実行しないようIF文で制御できます。
Excelのセルコピー数式では、IF関数は条件を満たした時点で残りの引数を評価しません（短絡評価）。A1が空白なら、VLOOKUPはまったく実行されず、空文字が即座に返されます。
1万行のうちデータが5,000行しかなければ、VLOOKUPの実行回数は5,000回に半減します。スワップ環境では、各VLOOKUPがページインを引き起こす可能性があるため、呼び出し回数の削減が直接的な速度改善になると考えられます。
6-3. 作業列の配置と参照パターン
コンピュータサイエンスの一般的な考え方として、メモリ上で近接するデータへのアクセスはキャッシュヒット率が高く、遠く離れたデータへのアクセスはキャッシュミスが増えるとされています（「参照の局所性」）。この原理に基づけば、作業列を元データの近くに配置し、参照が列方向に大きく飛ばない設計の方がメモリアクセス効率が良い可能性があります。
⚠ 注意：ただし、Excelの内部メモリ構造はスパース格納（必要なセルのみ保持する方式）を使用しており、C言語のような連続メモリ配列とは異なります。隣接列が必ず同じメモリページに載るかどうかはMicrosoftが公開しておらず、実証されたものではありません。上記は「一般的にはこのように考えられる」という参考情報です。
確実に言えるのは、Microsoft公式ドキュメントに記載がある「同じシート内の参照は他シートへの参照より高速」という点です。作業列はできる限り同じシート内に配置し、別シートへの参照を最小限にすることが推奨されています。
6-4. 参照範囲の統一（キャッシュ最大活用）
セクション5で述べた通り、Excel 2016以降は同一範囲参照でキャッシュが効きます。すべての検索式で参照範囲を完全一致させることで、キャッシュインデックスが再利用され、検索効率が向上します。
7. 揮発性関数がスワップを誘発する理由
INDIRECT、OFFSET、NOW、TODAY、RANDなどの揮発性関数は、セルの依存関係に関係なく、ブック全体の再計算を毎回トリガーします。通常の数式は変更があったセルとその依存セルだけ再計算する「スマート再計算」が働きますが、揮発性関数が1つでもあると、この最適化が無効になります。
メモリに余裕がある環境では全体再計算のコストは許容範囲ですが、スワップ環境では致命的です。再計算のたびにブック全体のセルを読み込むため、ページイン回数が増大すると考えられます。
8. スピル数式とセルコピー ― スワップ環境での違い
8-1. フル再計算時の速度比較
Microsoft 365 / Excel 2021以降で利用できるスピル（動的配列）数式は、1つのセルに入力した数式が自動的に複数行に展開されます。計算エンジンは数式を1回だけ解析し、全行の結果を一括で生成します。
| 項目 | スピル | セルコピー |
|---|---|---|
| 数式解析回数 | 1回 | 10,000回 |
| アドレス解決回数 | 1回 | 10,000回 |
| 関数呼び出しオーバーヘッド | 1回分 | 10,000回分 |
| ファイルサイズ（数式XML） | 1セル分 | 10,000セル分 |
| フル再計算速度 | 速い | 遅い |
ブックを開いた直後や Ctrl+Alt+F9 による強制再計算では、スピルが圧倒的に速くなります。
8-2. セル単位変更時の再計算
しかし、1セルを変更した場合の挙動は異なります。セルコピーでは、Excelのスマート再計算により、変更があったセルとその依存セルだけが再計算されます。一方、スピルは配列全体を再生成するため、1万行すべてが再計算されます。
さらに、スピルは計算結果をセルに「展開」する際に、配列サイズの確定・メモリ確保・セルへの書き込みというステップが毎回発生します。この展開コスト自体がオーバーヘッドとなります。
8-3. IF空白判定の効き方の違い
セルコピーのIF文は短絡評価が効き、空白行では重い処理がスキップされます。1万行中5,000行が空白なら、重い計算は5,000回だけです。
スピルの場合、配列全体を一括で処理するため、IF文の中であっても全行分の配列処理が内部で発生する可能性があります。空白行のスキップ効率はセルコピーより劣る場合があります。
8-4. スピルの範囲制御による最適化（理屈上の最速構成）
スピルのデメリット（全行展開・全行再計算）を解消する方法として、最終行を1セルで算出し、INDEX:INDEX構文でスピルの入力範囲を実データ行数に限定する手法があります。
ステップ①：最終行の算出（1セルだけ）
→ Z1セルに配置。ヘッダーを除いたデータ行数を返す（例：5,000）
ステップ②：INDEX:INDEX構文で実データ範囲だけを参照してスピル
→ B2セルに配置。INDEX:INDEX構文により参照範囲がA2:A5001（5,000行分）に動的に限定される。この範囲がそのままスピルの展開行数になるため、5,000行分だけ処理・展開される。
→ C2セルに配置。同じINDEX:INDEX範囲で別の列番号を返す。
→ INDEX+MATCH版。検索列と結果列の2列のみ参照。
INDEX:INDEX構文のポイント
💡 なぜINDIRECTやOFFSETではなくINDEX:INDEXか
INDIRECT("A2:A" & Z1+1) や OFFSET(A2,0,0,Z1,1) でも同じ動的範囲を作れますが、どちらも揮発性関数です。揮発性関数はブック内のどのセルが変更されても毎回ブック全体の再計算をトリガーするため、スワップ環境では本末転倒になります。INDEX:INDEX構文は非揮発性で、Z1の値（＝データ行数）が変わった時だけ再計算されます。
なぜこの構成が理屈上の最速か
パターンCの核心は3つあります。
第一に、Z1の最終行算出が1回で済み、それを全スピル列で使い回せる点です。B列・C列・E列と10列のスピルがあっても、最終行の判定はZ1の1セルだけです。セルコピーのIF空白判定が10列 × 10,000行 = 100,000回必要なのに対し、パターンCではCOUNTA 1回 + INDEX:INDEX 10回で済みます。
第二に、INDEX:INDEX構文は非揮発性であるため、Z1の値が変わらない限り再計算が発生しません。INDIRECTやOFFSETで同じことをすると、1セル変更のたびにブック全体が再計算されます。
第三に、参照範囲が最初から5,000行に限定されるため、メモリ展開も5,000セル分で済みます。スワップ環境ではこの差がページイン回数の削減に直結すると考えられます。
唯一のデメリットは、1セルの変更時にスピル配列全体（5,000行）が再計算される点です。セルコピーのスマート再計算（変更セルとその依存だけ再計算）と比べると、編集中の応答はセルコピーが有利になるケースがあります。しかしフル再計算（ブックを開いた直後・Ctrl+Alt+F9）ではパターンCが最速になると考えられます。
⚠ 注意：INDEX:INDEX構文でExcelが内部的に範囲をどの段階で確定しているか（参照解決時かセル読み込み時か）はMicrosoftが公開していません。「最初から5,000行分だけ読む」は動作から推測される挙動であり、ある程度のテストに基づいていますが、全てが正確とは限りません。実機テストを推奨します。
補足：TAKE関数を使う書き方（Microsoft 365 / Excel 2024以降）
→ TAKE関数は配列の先頭からZ1行分を切り出す。書き方は簡潔だが、内部でA2:A10000を全行読み込んでから切り出している可能性があり、INDEX:INDEX構文よりメモリ効率が劣る場合がある。TAKE関数が使える環境でも、INDEX:INDEX構文を推奨します。
9. Excelバージョンによる計算エンジンの改善
同じPCでもExcelのバージョンが新しくなると、計算速度が劇的に向上する場合があります。これは関数単体の改善だけでなく、メモリ管理やキャッシュ機構の改善によるものです。
| 改善項目 | 旧バージョン | 新バージョン | 改善率 |
|---|---|---|---|
| VLOOKUPキャッシュ | 37秒（Excel 2010） | 12秒（Excel 2016以降） | 約3倍 |
| SUMIFS / COUNTIFS高速化 | 20秒（Excel 2010） | 8秒（Microsoft 365 2020年6月以降） | 約2.5倍 |
| 構造化参照最適化 | 1.9秒（Excel 2013） | 約2ミリ秒（Excel 2016） | 約1,000倍 |
| 行の並べ替え（22,000行） | 39秒（Excel 2013） | 2秒（Excel 2016） | 約20倍 |
| LAA対応（32ビット仮想メモリ上限） | 2 GB（Excel 2010以前） | 4 GB（Excel 2013以降） | 2倍 |
出典：Excel performance and limit improvements - Microsoft Learn
特に注目すべきは、32ビットExcelのLAA対応（Excel 2013以降）です。仮想メモリ上限が2GBから4GBに拡大されたことで、スワップの発生頻度が大幅に低下した可能性があります。古いExcelで「フリーズするほど遅い」状態が、バージョン更新だけで改善されるケースの相当部分は、このメモリ上限の変更で説明がつきます。
正確な対応ビルドはOfficeの更新チャネルにより異なる場合があります。上表のバージョンは目安としてお読みください。
10. 高速化の優先順位 ― 何から手をつけるべきか
Excelの高速化は、効果の大きい順に取り組むべきです。関数の置き換えは最も効果が小さく、ハードウェア環境の改善が最も効果的です。
| 優先度 | 対策 | 効果 | 実施難易度 |
|---|---|---|---|
| 1 | 物理メモリ増設（4GB → 8GB以上） | ★★★★★ | 中（情シスの承認が必要） |
| 2 | HDD → SSD換装 | ★★★★ | 中 |
| 3 | 64ビットExcelへの移行 | ★★★★ | 高（互換性検証が必要） |
| 4 | Excelバージョン更新 | ★★★ | 高（ライセンス・検証） |
| 5 | 揮発性関数の排除 | ★★★ | 低（数式変更のみ） |
| 6 | 参照範囲の明示化・絶対参照統一 | ★★ | 低 |
| 7 | IF空白判定・作業列を同シートに配置 | ★★ | 低 |
| 8 | 関数選択の変更（VLOOKUP → INDEX+MATCH等） | ★ | 低 |
優先度1〜4はハードウェア・環境の問題であり、実施できればExcelの遅さは根本的に解消されます。しかし、多くの現場ではこれらを実施する権限がありません。その場合は優先度5〜8の数式設計で対処することになりますが、効果の上限はハードウェア改善に遠く及びません。
逆に言えば、数式の工夫だけで体感できるほど速くなったなら、それはスワップが発生するほどメモリが逼迫した環境にいる証拠です。
11. Excelで数万行を扱うためのPC選定ガイド
IT部門がなくPC選定を自分で行う中小企業の担当者、あるいはIT部門に要望を出す際の根拠として、以下の目安を示します。
| 項目 | 最低ライン | 推奨 | 理由 |
|---|---|---|---|
| RAM | 8 GB | 16 GB | Windows + Excel + 常駐ソフトで4〜6GB消費。残りでExcelがスワップなく動作するために必要。 |
| ストレージ | SATA SSD | NVMe SSD | 万が一スワップが発生してもHDDの20〜30倍の速度で被害を最小化。 |
| Excel | 32ビット LAA対応 | 64ビット | 64ビットはメモリ制限が実質なくなり、大規模ブックも安定。 |
| CPU | Core i3 / Ryzen 3 | Core i5 / Ryzen 5 以上 | Excelの再計算はマルチスレッド対応。コア数が多いほど再計算が速い。 |
Excelで数万行×数十列の重い数式を扱う場合、最も費用対効果が高い投資はメモリの増設です。4GB → 8GBの増設は数千円で可能な場合が多く、体感速度が劇的に改善します。
12. 補足：32ビットと64ビットで数式の設計思想が逆転する
32ビットExcel（メモリ制約あり）と64ビットExcel（メモリ制約なし）では、高速化のための数式設計方針が異なります。
32ビット環境では、メモリが限られるためスワップ回避が最優先です。参照範囲を絞り、作業列を最小限にし、不要な列を削除してメモリ使用量を抑える設計が有効です。
64ビット環境では、メモリに余裕があるため、作業列を増やして計算を中間ステップに分割し、各ステップの計算負荷を軽減する設計が有効です。スピル処理で一括計算したり、広めの参照範囲を取ってもスワップが発生しないため、メモリを「贅沢に使う」設計が速くなります。
この「設計思想の逆転」は、32ビットと64ビットの両環境で数万行を扱った経験がなければ気づきにくい視点です。日本語ではほぼ扱われていない情報であることを付記しておきます。
⚠ 注意：32ビットと64ビットの設計差については、考え方としての説明であり、両環境での網羅的なベンチマークテストは実施していません。実際の効果はデータの規模・数式の複雑さ・PC構成により異なります。
13. まとめ
Excelの遅さは、多くの場合、関数の選択ではなくメモリスワップが原因です。高スペックPCでは見えにくいこの問題は、4GBメモリ・HDD・32ビットExcelという事務用PCの典型的な構成で顕在化します。
対策の優先順位は、ハードウェア改善（メモリ増設 → SSD → 64ビット移行）が最も効果的であり、それが難しい場合に限り、数式設計の工夫（参照範囲の明示化、IF空白判定、作業列を同シートに配置、揮発性関数の排除、参照範囲の統一）で軽減を図ります。
スピル数式を使う場合は、INDEX:INDEX構文で参照範囲を実データ行数に限定することで、スピルの利点（数式解析1回）を最大化しつつ、展開コストを最小化できます。最終行の算出は1セルで済み、複数のスピル列で使い回せるため、列数が増えるほど効率が高まります。
VLOOKUPをINDEX+MATCHに変える前に、まずタスクマネージャーでメモリ使用率を確認してください。90%を超えていたら、数式の変更よりメモリの増設が先です。
本稿の信頼性について（再掲）
本稿は実務経験とMicrosoft公式ドキュメントを基に、考え方と対策の方向性を示したものです。ある程度のテストを実施したうえで作成していますが、全てのパターンを網羅的に検証したわけではなく、すべてが正しいとは限りません。特にExcelの内部計算エンジンの動作はMicrosoftが詳細を公開していないため、推測に基づく部分があります。読者ご自身の環境で結果を確認し、本稿と異なる結果が得られた場合は、そちらを優先してください。