スプレッドシートが重い原因7つ｜Google公式の軽くする方法と限界

2026年4月15日2026年8月18日

【元情シスが警告】スプレッドシートが重い原因は？全社フリーズの失敗から学ぶ根本解決策

SkillStack Lab運営者のスタックです。

Googleスプレッドシートを使っていて、「入力してから反映されるまで遅い」「処理していますと表示される」「スマホで開くと固まる」と困っていませんか。

スプレッドシートが重い場合、いきなり別のシステムへ移行する必要はありません。

まず確認したいのは、全列参照、TODAY・NOWなどの揮発性関数、IMPORTRANGE、複雑な数式、条件付き書式、参照チェーン、増えすぎたデータです。Google公式も、これらの見直しをパフォーマンス改善策として案内しています。

私自身、元社内SEとしてスプレッドシートを業務へ組み込み、複数部署のデータをIMPORTRANGEで集約した結果、月末にファイルを開くまで5分以上かかる状態にしてしまった経験があります。

この記事では、その失敗も踏まえながら、スプレッドシートが重い原因を切り分ける方法と、今すぐ試せる軽量化、そして表計算で管理し続ける限界の判断基準を順番に解説します。

先に試したい7つの対策

A:Aなどの全列参照をA2:A1000など必要範囲へ絞る
TODAY・NOWなどを何千セルにも直接書かない
VLOOKUPなどの中へ複雑な関数をネストしすぎない
IMPORTRANGEを減らし、参照の連鎖を短くする
不要な条件付き書式を削除する
確定済みの過去データは必要に応じて値へ変換する
古いデータを別ファイルへアーカイブし、現役データを絞る

スプレッドシートが重いとき最初に原因を切り分ける

いきなり数式を削除する前に、まず「そのスプレッドシートだけが重いのか」を確認しましょう。

別の新しいスプレッドシートは問題なく操作できるのに、特定のファイルだけ遅いのであれば、数式・データ量・条件付き書式・外部参照などファイル側に原因がある可能性があります。

反対に、新規ファイルまで遅い場合は、通信環境、ブラウザ、拡張機能、端末側の負荷なども切り分けてください。

まず別の軽いスプレッドシートを開き、同じ端末・ブラウザで正常に編集できるか確認すると、ファイル側と環境側を切り分けやすくなります。

「処理しています」は計算中にも表示される

Googleスプレッドシートでは、セルを編集すると、そのセルに関連する数式や依存先のセルがバックグラウンドで再計算されます。

そのため、1つの値を変更しただけでも、そこから多数の数式へ参照がつながっていると計算量が増えます。

共同編集、数式計算、自動スクリプトなどが動いているときには、画面上部にデータ読み込みの進行表示が出ることもあります。

つまり「入力した1セル」ではなく、その1セルを起点にどれだけの計算が発生しているかを見る必要があります。

Googleスプレッドシートで入力後に計算や同期処理が発生して表示が遅くなるイメージ図

スプレッドシートが重い主な原因7つと軽くする方法

ここからは、Google公式が案内しているパフォーマンス改善策も踏まえながら、業務で特に遭遇しやすい原因を順番に見ていきます。

原因1｜A:Aなど不要に広い範囲を参照している

最初に確認したいのが、数式で指定している範囲です。

たとえば、実際には1,000行程度しか使っていないのに、

=SUM(A:A)

のように列全体を指定していないでしょうか。

Googleは、このような非限定範囲では空白セルも確認対象になるため、必要なデータだけを指定した限定範囲を使うことを推奨しています。

たとえば、

=SUM(A2:A1000)

のように、実データに合わせて範囲を限定します。

VLOOKUP、SUMIF、COUNTIF、FILTERなどでも、必要がなければA:AやA:Zではなく、実際に使う行まで範囲を絞ってみてください。

原因2｜TODAY・NOWなどの揮発性関数を大量に使っている

TODAY()、NOW()、RAND()、RANDBETWEEN()などは、値が変化・更新される揮発性関数です。

こうした関数を各行へ大量に配置すると、参照関係が増えて計算負荷が大きくなる場合があります。

たとえば1,000行すべてへ、

=IF(A2<TODAY(),"期限切れ","")

のようにTODAYを直接書くより、どこか1セルだけに、

=TODAY()

を置き、各行からそのセルを絶対参照する設計を検討します。

Googleも、同じ結果を返す揮発性関数については、一度計算したセルを参照して不要な依存関係を減らす方法を案内しています。

TODAYやNOWなどの揮発性関数や複雑な参照が再計算を増やす仕組みを示した図解

原因3｜VLOOKUPの中へSORTやIMPORTRANGEをネストしている

「VLOOKUPを使うと重くなる」と説明されることがありますが、VLOOKUPそのものを避ければよいわけではありません。

Google公式では、VLOOKUPやMATCHはシンプルな範囲を指定して使うよう最適化されています。

問題になりやすいのは、次のように検索範囲そのものを毎回作り直す構成です。

=VLOOKUP(A2,SORT(B2:D10000,1,TRUE),3,FALSE)

あるいは、

=VLOOKUP(A2,IMPORTRANGE("URL","データ!A:D"),4,FALSE)

のように、LOOKUP関数の内部で別の重い処理を毎回実行する設計です。

こうした場合は、SORTやIMPORTRANGEの結果を別のシート・補助列へ一度だけ取得し、VLOOKUP側ではその結果だけを参照する方法を検討します。

「複雑な1本の数式」にまとめれば必ず速いわけではありません。途中結果を補助列へ分けた方が、再計算を減らし、後から原因も追いやすくなる場合があります。

原因4｜IMPORTRANGEで複数ファイルをつなぎすぎている

私が特に注意しているのがIMPORTRANGEです。

IMPORTRANGEは別のスプレッドシートからデータを取り込める便利な関数ですが、Google公式によると、同じ所有者、同じブラウザ、同じGoogleドライブ内のファイルであっても、スプレッドシート間のデータ取得にはインターネットを経由します。

そのため、参照元が増えたり、

シートA → シートB → シートC → 集計シート

のような長い連鎖を作ったりすると、更新待ちやネットワーク遅延の影響を受けやすくなります。

同じデータを何度もIMPORTRANGEするのではなく、一度だけ取り込み、その結果を同一ファイル内で再利用できないか確認してください。

Google公式の高速化策は、データの参照を最適化してスプレッドシートのパフォーマンスを上げるでも確認できます。

原因5｜条件付き書式を広範囲へ大量に設定している

見落としやすいのが条件付き書式です。

色分けは非常に便利ですが、ルールが増え、対象範囲も広がるほど計算量が増えます。

特に、過去に作ったルールが重複したまま残っていたり、データが1,000行しかないのに数万行へ条件付き書式を設定していたりする場合は見直しましょう。

「表示形式」→「条件付き書式」を開き、使われていないルールや重複ルールがないか確認します。

原因6｜参照チェーンが長くなっている

たとえば、

A1 → B1 → C1 → D1 → E1

のように前の計算結果を次のセルが参照し、その結果をさらに次のセルが参照する設計では、前段の計算が終了するまで後段の結果を確定できません。

Googleも長い参照チェーンを避け、計算済みの元データを直接参照できないか検討するよう案内しています。

複雑な管理表ほど、「このセルはどこを参照しているか」を追ってみると、何段もの依存関係が見つかることがあります。

原因7｜データ量と数式量が業務に対して大きくなりすぎた

Googleスプレッドシートには、1ファイルあたり最大1,000万セル、最大18,278列という仕様上の上限があります。

1,000万セルは「そこまで快適に使える」という推奨値ではありません。実際の動作速度は、数式、条件付き書式、外部参照、同時編集、データ構造などによって大きく変わります。

Googleスプレッドシートのセル数上限と不要なデータ範囲を見直すポイントを示した図解

項目	現在の上限	注意点
1ファイルのセル数	最大1,000万セル	快適動作を保証する目安ではない
最大列数	18,278列（ZZZ）	通常業務で上限まで使う必要はほぼない

最新の上限は、Google公式「Googleドライブに保存できるファイル」で確認できます。

空白行・空白列を削除すれば軽くなるのか

「空白行を削除すれば軽くなる」と紹介されることがあります。

不要な行や列を整理すること自体は悪くありませんが、真っ白なセルが存在するだけで大量のメモリを消費し続けると考えるのは正確ではありません。

より重要なのは、数式や条件付き書式がその空白領域まで参照していないかです。

たとえば、実データが1,000行までなのに、

=SUMIF(A:A,"東京",B:B)

のように列全体を対象にしているなら、

=SUMIF(A2:A1000,"東京",B2:B1000)

のように範囲を限定する方を優先してください。

そのうえで、誤って数万行・数百列を追加してしまっている場合は、不要な行や列そのものを削除して管理しやすい状態へ戻しておくとよいでしょう。

確定済みの過去データは値に変える方法もある

過去月の集計など、今後再計算する必要がない数式を何年分も残している場合は、結果だけを値として保存する方法があります。

たとえば、締め処理が完了し、今後変更しない月次データなら、バックアップを確保したうえで数式結果をコピーし、「特殊貼り付け」→「値のみ貼り付け」で固定する方法です。

GoogleもIMPORTRANGEと揮発性関数の組み合わせなどでは、確定した結果を値として貼り付け、静的なデータを参照する方法を案内しています。

値へ変換すると元の数式は失われます。必ずバックアップを取り、「本当に今後再計算しないデータ」だけを対象にしてください。

私がIMPORTRANGEで巨大なマスターシートを作って失敗した話

ここからは、私自身が社内SE時代にやってしまった失敗です。

当時、専用の業務システムへ費用をかける前に、既存のGoogleスプレッドシートで何とかできないかと考えました。

そこで、各部署で管理していたデータをIMPORTRANGEで1つのマスターシートへ集約しました。

営業部の売上データ、人事関連のデータ、管理部門のデータなどを外部参照で取り込み、その上からQUERYやピボットテーブルを使って集計する構成です。

最初は問題なく動いていました。しかし私の環境では、データが2万行を超えたあたりから読み込み待ちやエラーが目立つようになり、月末にはファイルを開くだけで5分以上かかる状態になりました。

複数部署のスプレッドシートをIMPORTRANGEで集約した結果、読み込み時間と再計算が増えた失敗例

特に月末は複数部署の更新が重なり、データの反映待ちやフリーズで管理部門の処理にも影響が出ました。

ここで大切なのは、「2万行を超えるとGoogleスプレッドシートが使えなくなる」という意味ではありません。

私のケースでは、行数だけでなく、複数ファイルからのIMPORTRANGE、QUERY、ピボット、複数人の更新を1つのファイルへ集中させた設計が問題でした。

スタック

「まだセル上限には余裕があるから大丈夫」と考えていたのが失敗でした。上限値より、毎日の運用で待ち時間やエラーが発生していないかを見る方が重要です。

IMPORTRANGEを使うなら連鎖を短くする

IMPORTRANGE自体を使ってはいけないわけではありません。

少量のデータを別ファイルから参照する用途なら便利です。

ただし、業務で使うなら次のような構成を避けることをおすすめします。

同じ元データを何度もIMPORTRANGEする
IMPORTRANGEの中へ複雑な関数を重ねる
IMPORTRANGEされたファイルをさらに別ファイルから参照する
過去データまで毎回リアルタイム参照する

反対に、

IMPORTRANGEする回数を減らす
必要な列・行だけ取得する
一度取得したデータを同一ファイル内で再利用する
確定した過去データはリアルタイム参照から外す

といった設計を検討します。

スマホだけ重い場合はシートの用途も見直す

PCでは許容できるのに、スマートフォンでは操作がつらいというケースもあります。

巨大な表、複雑な集計表、多数の列を持つ管理表をスマートフォンで編集すること自体が、現場の用途に合っていない場合もあります。

たとえば外出先の社員に必要なのが「今日の訪問結果を入力する」だけなら、巨大なマスターシートそのものを開かせる必要はありません。

Googleフォームなど入力専用の画面を用意し、集計用スプレッドシートと分離する方が、誤操作防止や入力のしやすさにつながる場合があります。

「スマホで巨大な管理表を快適に動かす方法」だけを考えるのではなく、「スマホ利用者にその管理表全体を触らせる必要があるか」から見直してみてください。

軽量化しても重いならデータ構造を見直す

ここまでの対策を行っても頻繁に重くなる場合は、数式の調整ではなくファイル構成そのものを見直す段階です。

ただし、「重い＝すぐSaaSへ移行」と判断する必要もありません。

私は次の3段階で考えます。

段階	対策	向いている状況
1	数式・範囲を最適化	構造はシンプルで計算だけが重い
2	ファイル・データを分割	過去データや用途の違うデータが混在
3	専用システムを比較	権限・承認・履歴・業務ルールまで表計算に詰め込んでいる

古いデータをアーカイブする

たとえば5年分の履歴を毎日更新する必要がないなら、過去年度を別ファイルへアーカイブし、現在年度だけを日常業務用ファイルへ残す方法があります。

ただし、アーカイブしたデータを再び大量のIMPORTRANGEで常時読み込めば軽量化の意味が薄れます。

「普段使う現役データ」と「必要なときだけ参照する履歴」を分けることがポイントです。

GASを追加する前に構造を確認する

シートが重くなると、「GASで自動処理すれば解決できるのでは」と考えることもあります。

しかし、重いシートの上へさらに複雑なGASを追加すると、今度は実行時間や属人化の問題が増える可能性があります。

GASを使った自動化を検討している場合は、GASでスプレッドシートを自動化するときの注意点も確認してください。

スプレッドシートから専用SaaSへ移した方がよいケース

Googleスプレッドシートは柔軟で、集計・分析・簡易台帳には非常に便利です。

問題なのは、表計算の役割を超えて業務システムそのものになっているケースです。

私なら、次の条件が複数当てはまる場合は、軽量化だけでなく専用システムとの比較を始めます。

複数人が毎日継続してデータを更新する
担当者ごとに細かな権限管理が必要
申請・承認・差し戻しがある
誰がいつ変更したかを業務上管理したい
制度変更のたびに数式やGASを改修している
ファイルが止まると給与・請求・顧客対応に影響する
作成者しか数式やスクリプトを修正できない

この状態になると、スプレッドシートの速度だけではなく、業務継続や属人化まで含めて考える必要があります。

勤怠・会計・問い合わせなど業務システム向きのデータを専用クラウドサービスへ分離する考え方を示した図解

勤怠・会計・問い合わせ管理は専用SaaSも比較する

特に、勤怠・会計・問い合わせ管理などは、単に表へ入力できればよい業務ではありません。

承認、権限、履歴、通知、ステータス、外部システム連携などが必要になれば、それらを数式やGASで自作し続けるコストも考慮する必要があります。

一方で、個人の集計、分析、試算、短期間だけ使う簡易台帳なら、無理にスプレッドシートを捨てる必要はありません。

スタック

私は「表計算だからダメ」ではなく、業務の役割に合っているかで判断します。速度だけ直しても、承認や権限まで無理やり作り込んでいるなら別の問題が残ります。

Excelやスプレッドシートを残す業務と、専用システムへ移した方がよい業務の違いは、以下の記事で整理しています。

脱Excelツール3選を見る

スプレッドシートを最適化し、必要に応じて専用システムへ移行する業務改善の流れを示した図解

スプレッドシートが重いときのよくある質問

スプレッドシートが急に重くなったら何を確認すればよいですか？: 最近追加した数式、IMPORTRANGE、条件付き書式、GAS、データ量の増加を確認してください。別の軽いスプレッドシートが正常に動くか試すと、ファイル側と端末・ブラウザ側の問題を切り分けやすくなります。
空白行を削除するとスプレッドシートは軽くなりますか？: 不要な行列を整理することはできますが、まず確認したいのは数式や条件付き書式が不要な空白範囲まで参照していないかです。A:Aのような全列参照を必要な範囲へ限定する方を優先してください。
VLOOKUPを使うと重くなりますか？: VLOOKUPそのものが必ず重いわけではありません。Googleはシンプルな範囲を使う方法を案内しています。全列参照や、VLOOKUP内部にSORT・IMPORTRANGEなどをネストしている場合は見直してください。
IMPORTRANGEはなぜ遅くなることがありますか？: 別スプレッドシートからのデータ取得にはネットワーク経由の処理が必要だからです。参照元や参照チェーンが増えるほど待ち時間や接続状況の影響を受けやすくなるため、取得回数と対象範囲を減らしてください。
何行を超えたらスプレッドシートをやめるべきですか？: 「何万行」という一律の基準では判断できません。同じ行数でも数式や外部参照、条件付き書式、同時編集などで負荷は変わります。日常的な待ち時間やエラー、属人化、権限・承認などの業務要件を含めて判断してください。
重くなったらSaaSへ移行した方がよいですか？: 必ずしも必要ありません。まず数式・参照・条件付き書式を最適化し、必要なら過去データを分離します。それでも権限、承認、履歴、制度対応などを表計算へ作り込み続けている場合は、専用SaaSを比較する段階です。