エクセルで「リソース不足」「メモリ不足」と出る原因は、ほぼ2つに絞れます。32ビット版 Excel が使えるメモリが 2GB で止まっていることと、使用セル範囲・条件付き書式・揮発性関数がファイルの中で膨らんでいることです。Microsoft は公式のトラブルシューティング記事で、このメッセージを「一般的なもので、問題の実際の原因を常に特定するとは限らない」と断っており、32ビットアプリには 2GB の制限があるとも明記しています(Excel で使用可能なリソース エラーのトラブルシューティングを行う方法 - Microsoft Learn)。
つまり「パソコンのメモリを増やす」より先に、自分の Excel が何ビットかを確認し、ファイルの中の無駄を測るのが最短ルートです。この記事では公式に確認できるエラー文言を整理し、原因7系統を「どう確認して、どう減らすか」まで落とし、最後にこのファイルを軽量化で延命できるか、作り替えに回すかを年数で判断する算式を置きました。
公式に確認できるエラー文言は4種類(症状×場面×最短の対処)
Microsoft Learn のトラブルシューティング記事には、症状として次の4つのメッセージが並んでいます。日本語ページの表記をそのまま引くと、こうなります。
- Excel では、使用可能なリソースを使用してこのタスクを完了できません。 少ないデータを選択するか、他のアプリケーションを閉じます。
- メモリ不足
- 完全に表示するのに十分なシステム リソースがない
- このアクションを完了するのに十分なメモリがありません。 使用するデータを減らすか、他のアプリケーションを閉じてみます。
英語版の同じページでは、順に Excel cannot complete this task with available resources. Choose less data or close other applications. / Out of Memory / Not enough System Resources to Display Completely / There isn't enough memory to complete this action. です。4つ目には対処として「64 ビット バージョンの Microsoft Excel を使用する」「デバイスへのメモリの追加」が併記されています。
検索でよく見かける「リソース不足のため、このタスクを完了することができません」「いくつかの数式の計算中にリソース不足になりました」といった言い回しは、公式ドキュメントの文面としては確認できませんでした(後者は Microsoft Q&A への利用者の投稿で見られる表現です)。環境やバージョンで語尾が違うので、文言が一字一句合わなくても、下の表で「どの操作で出たか」から当てに行くのが確実です。
出たときの操作 | いちばん疑う原因 | 最短の対処 |
|---|---|---|
行・列の挿入/並べ替え/コピー貼り付け | 再計算対象の数式が多すぎる | 計算方法を「手動」にしてから操作し、終わってから F9 で再計算する |
ファイルを開く/閉じる/保存する | 使用セル範囲の膨張、他ブックへのリンク | Ctrl+End で使用範囲を確認し、余白の行列を削除して保存し直す |
スクロールや画面の描画だけで出る | 条件付き書式、図形・画像、既定プリンター | 条件付き書式のルールを統合し、オブジェクトの数を数える |
どのファイルでもランダムに出る | 32ビット版の 2GB 上限、アドイン、常駐ソフト | ビット版を確認し、アドインを全部切って再現するか見る |
VBA の実行中に出る | セル単位のループ、画面更新の都度描画 | 配列でまとめて読み書きし、ScreenUpdating を切る |
まず自分の Excel が32ビットか64ビットかを確認する
これを飛ばして軽量化に進むと、だいたい遠回りになります。32ビット版のアプリが使えるのは 2GB(Excel 2013/2016 のラージ アドレス アウェア版なら最大 4GB)で、64ビット版にはその制限がありません。Microsoft は VBA 向けのパフォーマンス記事で「32ビット コンピューターでの Excel のパフォーマンスを最適化するには、コンピューターに少なくとも 3GB の RAM を搭載することをお勧めします」とも書いています(Excel のパフォーマンス - パフォーマンスの障害を最適化するためのヒント)。
確認は3クリックです。Excel を開いて[ファイル]→[アカウント]→[Excel のバージョン情報]を選ぶと、ダイアログに完全なバージョン番号と「32 ビット」「64 ビット」が表示されます。
「32 ビット」と出たなら、ここが天井です。Microsoft の仕様ページでも、32ビット環境の仮想アドレス空間は 2GB、そのうちデータモデルが使えるのは最大 500〜700MB と明記されています。64ビット環境ではファイルサイズのハード制限がなく、「利用可能メモリとシステム リソースでのみ制限されます」とされています(Excel の仕様と制限)。
ただし64ビットに入れ替えれば解決、とは限りません。32ビット版のアドインしか無い業務が止まることがあり、実務では「入れ替えたら月次の集計マクロが動かなくなった」という詰まり方をよく見ます。入れ替えは、使っているアドインの64ビット対応を先に確認してからにしてください。なお64ビット版を選ぶ目安として、Microsoft は「複雑な計算を含むエンタープライズ規模の Excel ブック、多数のピボットテーブル」を挙げています(64 ビット版または 32 ビット版の Office を選択する)。
原因1|使用セル範囲(Ctrl+End)が実データより遥か先まで伸びている
いちばん多く、いちばん効くのがこれです。Excel はメモリとファイルサイズを節約するため「使用範囲」の情報だけを保存しますが、実データの外側で書式設定や編集をしていると、使用範囲がそこまで広がります。Microsoft も「こうしたことが原因で、パフォーマンスやファイルサイズ上の障害となることがあります」として、Ctrl+End での確認を案内しています。
どう確認するか:シートを開いて Ctrl+End を押します。実データの最終セルが F2000 なのにカーソルが XFD1048576 付近へ飛ぶなら、無駄が確定です。シートごとに押して、どのシートが犯人かを特定します。
どう減らすか:バックアップを取ってから、最終データの下の全行と右の全列を行列ごと選択して削除し、保存して閉じ、開き直します。Delete キーで中身を消すだけでは使用範囲は縮みません。行列の削除が必要です。削除する範囲が数式の参照に含まれていると、その範囲が縮むか #N/A に変わる点も公式に注記されているので、バックアップは必ず先に取ります。
行数そのものの上限は 1,048,576 行・16,384 列ですが、上限に当たる前にメモリが尽きるのが普通です。使用範囲の整理と合わせて、エクセルの動作が遅い原因を3大要因から切り分ける手順も見ておくと、重さの出どころが先に分かります。
エラーを消しても、翌月また同じ場所で止まる──という繰り返しになっているなら、ファイルの直し方ではなく置き場所の問題かもしれません。Mihata では、使い慣れたスプレッドシートの形を保ったまま、入力と集計だけを軽いアプリ側に移す「スプシ de 社内アプリ」という進め方もご用意しています。記事の途中で恐縮ですが、同じ悩みから生まれたサービスなので、よろしければ合わせてご覧いただけたら嬉しいです。
原因2|条件付き書式のルールが重複して増殖している
Microsoft は「条件付き書式とデータの入力規則は便利ですが、多用すると、計算速度が大きく低下する原因となります。セルが表示されている場合は、各計算で、条件付き書式を含むセルの表示が更新されるときに、すべての条件付き書式の数式が評価されます」と書いています。描画のたびに全ルールが走るので、スクロールだけでメモリエラーが出るときの第一容疑者です。
増殖の正体は、ほぼ行のコピー貼り付けです。「A2:A100 に1本」だったルールが、行を挿入・コピーするたびに「A2:A50 に1本」「A51:A70 に1本」と分裂し、同じ条件のルールが数十〜数百本になります。
どう確認するか:[ホーム]→[条件付き書式]→[ルールの管理]で、適用対象を「このワークシート」に切り替えます。ここに並ぶ行数がルール数です。同じ数式・同じ書式のものが縦に並んでいたら、それが重複ぶんです。
どう減らすか:同条件のルールを1本に統合し、適用範囲を列全体ではなく実データの範囲(できればテーブルの構造化参照)に絞ります。使っていない色分けは消します。VBA から制御する場合は Worksheet.EnableFormatConditionsCalculation で条件付き書式の計算を一時的に止められる、というプロパティも公式に用意されています。
ルールを削るのと同時に、「セルの書式設定/セルのスタイル」の固有数の上限が 65,490 であることも覚えておくと役立ちます。別ファイルからの貼り付けを繰り返したブックは、ここに近づいていることがあります。
原因3|名前の定義と外部リンクの残骸が残っている
Microsoft は「定義名を使用すると、計算時間が長くなります。他のワークシートを参照する名前を使用すると、計算プロセスはより複雑になります。また、入れ子になった名前(他の名前を参照する名前)の使用も避ける必要があります」と明記しています。ブック間リンクについても「それらは遅く、簡単に壊れ、常に簡単に見つけて修正できるわけではありません」と、かなり強い言い方です。
どう確認するか:[数式]→[名前の管理]を開き、参照範囲の列に #REF! や他ファイルのパスが入っているものを探します。外部リンクは[データ]→[リンクの編集](または[クエリと接続])で一覧になります。名前の定義の数は公式には「使用可能メモリに依存」とされており、固定の上限はありません=メモリが尽きるまで増えてしまうということです。
どう減らすか:壊れた名前(#REF! を含むもの)は削除します。他部署のファイルを参照しているリンクは、必要な値だけを別シートに貼り付けて切ります。どうしても残すなら、公式の助言どおり「リンク先のブックを先に開いてから、リンク元を開く」順を守ります。
原因4|配列数式・揮発性関数が列全体に当たっている
これは原因というより「設計のクセ」です。公式ドキュメントは「配列数式では、空白セルや使用されていないセルも含め、すべてのセル参照が強制的に計算されます。Excel 2007 以降では 100 万行まで使用できるので、全列を参照する配列数式は計算速度が著しく低下します」と書いています。=SUMPRODUCT(--($A:$A="済"),$C:$C) のような書き方は、空白を含む104万行を毎回計算させます。
揮発性関数(OFFSET・INDIRECT・NOW・TODAY・RAND など)も、計算のたびに再計算対象を増やします。公式の推奨は「OFFSET の代わりに INDEX を、INDIRECT の代わりに CHOOSE を使用する」です。INDIRECT はシングルスレッドでしか計算されないことも明記されています。
どう確認するか:Ctrl+F の[検索と置換]で「検索場所:ブック」「検索対象:数式」にして、OFFSET( INDIRECT( SUMPRODUCT( :$A$1048576 をそれぞれ検索し、[すべて検索]の件数を数えます。この件数が、後述の算式で使う「揮発性関数の数」の代わりになります。
どう減らすか:列全体参照をテーブルの構造化参照に置き換え、配列数式は SUMIFS・COUNTIFS・AVERAGEIFS(Excel 2016 以降は MAXIFS・MINIFS)に寄せます。公式も「可能であれば、配列数式ではなく、SUMIFS、COUNTIFS、および AVERAGEIFS 関数を常に使用する必要があります」としています。累積合計の書き方ひとつでも差が出て、1,000 行のシートで =SUM($A$1:$A2) 方式は約 500,000 回、=$B1+$A2 方式は約 2,000 回の計算になる、という比較が公式に載っています。
原因5|図形・画像オブジェクトが見えないところに溜まっている
公式は「メモリの問題を引き起こす可能性があるその他の領域には、余分な図形、複雑なピボットテーブル、マクロ、および多くのデータ ポイントを含む複雑なグラフがあります」と挙げています。チェックボックスやハイパーリンクのようなコントロールが多いと、一時ファイルの使用数が増えてブックを開くのが遅くなる、という記述もあります。
どう確認するか:[ホーム]→[検索と選択]→[オブジェクトの選択と表示]で、シート上のオブジェクトが一覧になります。想定より桁が多いなら、貼り付けの繰り返しで透明な図形や重なった画像が溜まっています。F5([ジャンプ])→[セル選択]→[オブジェクト]で一括選択してから件数を見るのも早いです。
どう減らすか:不要なオブジェクトを選択して削除し、残す画像は貼り付け前に縮小しておきます。ファイル形式を XLSB にするのも効きます。公式の計測では、10 個のブックで XLS 形式からのサイズ削減係数が 2〜8、平均 4 だったとされています。
原因6|ピボットテーブルのキャッシュが重複している
ピボットテーブルは、元データのコピー(ピボットキャッシュ)をファイルの中に持ちます。同じ元データから作ったピボットを別々に作ると、キャッシュも別々に持つので、見た目は小さいのにファイルだけ膨らみます。
どう確認するか:ファイルサイズを元データの行数で割って、違和感がないか見ます。10万行・20列で 40MB を超えるようなら、キャッシュの重複かオブジェクトの蓄積を疑う段階です(厳密な基準ではなく、現場での当たりの付け方です)。
どう減らすか:同じ元データのピボットは、1つ作ってからコピーして作り直すと(既存のピボットを複製する形にすると)キャッシュを共有します。ピボットの結果を計算チェーンの途中で参照するのも避けます。公式は「ピボットテーブルを使用すると、概要レポートを効果的に作成できますが、計算チェーンで、ピボットテーブルの結果を中間合計として使用する数式は作成しないでください」として、どうしても使う場合は GETPIVOTDATA 関数を使うよう案内しています。
原因7|アドインと常駐ソフトがメモリを削っている
ファイル側に何も問題が無いのに、どのブックでもランダムに出る場合はこちらです。公式の切り分けでは、アドインを無効化する(方法3)、ウイルス対策を一時的に止める(方法6)、既定プリンターを「Microsoft XPS Document Writer」に変えて試す(方法5)、他のアプリを落としてクリーン ブートで確認する(方法8)が、この順で並んでいます。
どう確認するか:[ファイル]→[オプション]→[アドイン]で、COM アドインと Excel アドインを全部外して再現するかを見ます。再現しなくなったら1つずつ戻して犯人を特定します。公式も「アドインを削除した後に Excel でエラーが発生しなくなった場合は、アドインの製造元に問い合わせてサポートを受ける」ことを推奨しています。
どう減らすか:使っていないアドインは外したままにします。Excel の描画は既定プリンターを使うため、ネットワークプリンターの応答が悪い環境では既定プリンターの変更だけで直ることがあります。
このファイルは軽量化で延命できるか、作り替えか(算式と3ケース試算)
原因を潰していくと、必ず「で、このファイルはいつまで使えるのか」という話になります。相場や単価で決めるものではないので、手元で測れる3つの数だけで年数を出す算式を置きます。
使う数は、①使用セル範囲の行数(Ctrl+End で分かる)②条件付き書式のルール数(ルールの管理で数える)③揮発性関数・全列配列数式の数(検索と置換で数える)、そして④年間のデータ増加率です。
- いまの重さ W =(行数 ÷ 10,000)+(ルール数 ÷ 10)+(揮発性関数の数 ÷ 100)
- 軽量化で落とせる量 ΔW =(行の無駄ぶん × 0.9)+(ルールの重複ぶん × 0.7)+(置換できる揮発性関数ぶん × 0.8)
- 年間の増加量 G =(行数 ÷ 10,000)× 年間データ増加率 × 相互参照倍率(単一シート 1/複数シート相互参照 2)
- 延命できる年数 = ΔW ÷ G
ここに出てくる 10,000・10・100・0.9・0.7・0.8・倍率 2 は、算式の動きを見せるための仮の係数です。公式の制限値から導いた定数ではありません。自社の実測(削除前後のファイルサイズ、再計算にかかる秒数)が取れたら、そちらで置き換えてください。大事なのは絶対値ではなく、3つの数のどれが年数を食っているかが見えることです。
架空の3ケースで動かすと、こうなります。
項目 | ケース① | ケース② | ケース③ |
|---|---|---|---|
使用セル範囲の行数 | 20,000 | 150,000 | 400,000 |
条件付き書式のルール数 | 40 | 300 | 800 |
揮発性関数・全列配列数式の数 | 50 | 500 | 2,000 |
構成 | 単一シート | 単一シート | 複数シート相互参照 |
年間データ増加率 | 20% | 50% | 80% |
いまの重さ W | 2.0+4.0+0.5=6.5 | 15+30+5=50 | 40+80+20=140 |
落とせる量 ΔW | 0.9+1.96+0.32=3.18 | 4.05+14.7+3.2=21.95 | 7.2+39.2+12.8=59.2 |
年間の増加量 G | 2.0×0.2×1=0.40 | 15×0.5×1=7.5 | 40×0.8×2=64 |
延命できる年数 | 約 8.0 年 | 約 2.9 年 | 約 0.9 年 |
判断 | 軽量化で足りる | 軽量化しつつ移行準備 | 作り替えに回す |
ΔW の内訳は、ケース①が「無駄行 50%・ルール重複 70%・揮発性関数の 80% を置換可能」、ケース②が「無駄行 30%・ルール重複 70%・80% 置換可能」、ケース③が「無駄行 20%・ルール重複 70%・80% 置換可能」としたときの値です。行数が増えるほど無駄行の比率は下がる一方、ルールと相互参照が効いてきて、年数は一気に短くなります。
線の引き方は3段です。3年以上なら軽量化で足ります(今期は手を入れて使い切る)。1〜3年なら軽量化しながら移行先を決める期間に充てます。1年未満なら、軽量化に使う工数が1年で溶けるので作り替えに回したほうが安い、という読みです。ケース③のように「複数シート相互参照」が付くと倍率で年数が半分になるのは、公式が「循環参照が複数のワークシートにまたがっていると、通常は計算が遅くなります」「ワークシート間のリンクを最小化する」と繰り返している部分を、判断に反映させたものです。
1年未満と出たときの進め方は、エクセル管理をやめるときの4週間の移行段取りに時間軸で書いてあります。移行先を Notion などのツールに決め切る前に選択肢を広げたい場合は、スプレッドシート管理の限界をアプリ化で越える考え方も比べてみてください。
それでも直らないときの切り分け順
ここまでやって直らない場合は、公式の方法1〜8をそのままの順で踏むのが結局いちばん早いです。整理すると、①ファイル固有かどうかを確かめる→②Office と Windows を更新する→③アドインを全部切る→④プレビュー ウィンドウを切る→⑤既定プリンターを変える→⑥ウイルス対策を一時停止する→⑦64ビット版で試す→⑧他のアプリを落としてクリーン ブートの順です。
この順番には意味があります。①で「このファイルだけ」と分かれば②〜⑧は全部不要になり、逆に「どのファイルでも出る」なら①の軽量化に何時間かけても報われません。最初に分けるところを飛ばさないのがコツです。
なお、並べ替えのときだけエラーになる場合は、メモリではなく結合セルが原因のこともあります。症状が「できません」系のメッセージなら、結合セルのせいで並べ替えができないときの直し方も当たってみてください。
原因の切り分けまではご自身でできても、「誰が直し続けるのか」が決まらないまま止まっている会社が少なくありません。測った数字(行数・ルール数・揮発性関数の数)をお持ちいただければ、軽量化で足りるのか作り替えが要るのかを一緒に見立てます。
よくある質問
「リソース不足」と出ますが、パソコンのメモリを増やせば直りますか?
32ビット版のExcelを使っている場合は、ほとんど効きません。32ビットのアプリが使えるのは2GB(Excel 2013/2016のラージアドレスアウェア版で最大4GB)までなので、パソコン全体のメモリを増やしてもExcel側の天井は変わりません。まず[ファイル]→[アカウント]→[Excel のバージョン情報]でビット版を確認してください。64ビット版であれば、メモリの増設やほかのアプリを閉じることに意味があります。
エラーメッセージの文言が記事と少し違います。別の問題でしょうか?
同じ問題である可能性が高いです。Microsoftの公式ドキュメントも、これらのメッセージは一般的で問題の実際の原因を常に特定するとは限らないと断っています。バージョンや環境で語尾が変わるため、文言の一致より「どの操作をしたときに出たか」で当てに行くほうが確実です。行や列の挿入・並べ替え・コピー貼り付けで出るなら再計算、開閉や保存で出るなら使用セル範囲、スクロールだけで出るなら条件付き書式や図形から疑ってください。
使用セル範囲を小さくするのに、セルの内容をDeleteで消すだけでは足りませんか?
足りません。中身を消しても使用範囲は縮まないため、実データの下の全行と右の全列を行・列ごと選択して削除し、保存して閉じ、開き直す必要があります。削除する範囲が数式から参照されているとその範囲が縮むか #N/A に変わるので、必ずバックアップを取ってから行ってください。
記事にある「延命できる年数」の算式の係数は、そのまま使って大丈夫ですか?
そのままの精度を期待しないでください。10,000・10・100や0.9・0.7・0.8、相互参照倍率2は、算式の動きを見せるための仮の係数で、Microsoftの公式制限値から導いた定数ではありません。使い方としては、自社のファイルで行数・条件付き書式のルール数・揮発性関数の数を測り、削除前後のファイルサイズや再計算の秒数で係数を置き換えるのが本来です。3つの数のどれが年数を食っているかを見るための道具として使ってください。