Googleスプレッドシートを日々の業務で活用する中で、他のスプレッドシートからデータを自動で引っ張ってくることができる「IMPORTRANGE（インポートレンジ）関数」は、誰もが一度は使ったことがある、あるいは目にしたことがある便利な機能ですよね。別の部署が更新している売上管理シートや、プロジェクトメンバーが入力している進捗確認シートなど、異なるファイルに分散している情報を1つのシートに集約してダッシュボード化するには欠かせない機能です。
しかし、この非常に強力なIMPORTRANGE関数ですが、インポートするデータの行数や列数が膨大になったり、シート内のいたるところでこの数式をコピーして多用したりすると、スプレッドシートの動作が急激に重くなる最大のボトルネックになってしまうのですよ。スプレッドシートを開くたびにセルが「Loading...」と表示されたまま一向に進まなくなってしまったり、最悪の場合はブラウザ全体がフリーズして動かなくなったりして、作業効率が下がって困った経験のある方も多いのではないでしょうか。今回は、IMPORTRANGE関数がなぜこれほどまでにシートを重くしてしまうのか、その裏側の仕組みやスプレッドシートの仕様について、詳しく掘り下げてお話ししていきますね。
- IMPORTRANGE関数は別ファイルからリアルタイムにデータを取得して同期する便利な機能
- データサイズが肥大化したり数式を多用したりするとシート全体の処理速度を著しく低下させる
- 通常のセル参照と異なりクラウド上のGoogleサーバーと直接API通信を行うため通信負荷が高い
- スプレッドシートが重くなる原因と仕様を理解することが効果的なパフォーマンス改善の第一歩
ジャンプできる目次📖
IMPORTRANGE関数が重くなる仕組みとスプレッドシートの仕様
スプレッドシートを共有で使っていて「なんだか最近、シート全体のスクロールや値の入力がカクつくようになったな…」と感じたことはありませんか？そのシートの数式を確認してみると、IMPORTRANGE関数がいくつも仕込まれている、というケースは本当に多いのです。ただ、なぜこの関数を使うとシートが重くなってしまうのか、その根本的な理由を知っている方は少ないかもしれません。
Googleスプレッドシートは、パソコンのデスクトップ上で単独で動作するExcelなどのオフラインソフトとは異なり、すべてGoogleのクラウドサーバー上で処理が行われるウェブアプリケーションです。そのため、シート内で計算処理が走る際には、私たちが普段目で見ている画面（ブラウザ）の裏側で、常にGoogleのネットワークを経由したデータのやり取りが行われているのですよ。特に外部のファイルと接続するIMPORTRANGE関数は、スプレッドシートが持つ仕様や計算エンジンの特性上、非常に負荷がかかりやすい仕組みになっています。この仕組みを知っておくことは、シートのパフォーマンス改善だけでなく、普段の業務でスプレッドシートを快適に使いこなす上でもとても大切ですので、まずはその基本的な仕組みから一つずつ紐解いていきましょうね。
IMPORTRANGE（インポートレンジ）関数の基本的な役割
改めて、IMPORTRANGE関数がどのような役割を持っているのか、その基本的な定義と挙動から確認しておきましょう。この関数は、現在開いているスプレッドシートとは完全に別のファイルとして保存されているスプレッドシートの、指定したシート名およびセル範囲のデータを動的に引っ張ってくる（インポートする）ための数式です。
具体的な使い方は以下の通りで、数式自体はとてもシンプルですよ。
【IMPORTRANGE関数の基本構文】
=IMPORTRANGE("スプレッドシートのURL", "シート名!セル範囲")
※第一引数には参照したい外部ファイルの「スプレッドシートのURL（またはURLの一部であるスプレッドシートID）」を記述し、第二引数には取得したい「シート名とセル範囲（例：シート1!A1:D100）」を、それぞれダブルクォーテーションで囲んで入力します。
この関数の素晴らしいところは、何と言っても「参照元のファイルでデータが変更されると、参照先のシートでもその変更が自動的かつリアルタイムに反映される」という連携力です。これにより、複数のチームメンバーが別々のシートで各自の作業を行いながら、管理者はそれらをまとめた総合シートを自動で最新状態に維持できるのですね。コピー＆ペーストの手間を完全に無くしてくれるため、私も業務フローを自動化する際にはよく提案しています。
しかし、セキュリティを担保するためのスプレッドシートの仕様として、この数式をセルに入力した直後は必ず「#REF!」というエラーが発生するようになっています。これはバグではなく、「外部の別ファイルと通信を行ってデータを取得しても良いですか？」という確認のステップなのですよ。エラーが出ているセルにマウスカーソルを合わせると、「アクセスを許可」という青いボタンが表示されます。このボタンをクリックして、双方のシートを紐づける権限認証を完了させて初めて、実際のデータ読み込みが開始される仕組みになっています。このアクセス許可は最初の1回だけ行えば、その後は毎回押す必要はありません。ただし、参照元のスプレッドシートに対して閲覧以上の権限を持っていないユーザーがこの数式を記述しても、アクセス許可を承認することはできませんので注意してくださいね。このように、データを安全に保護しながらリアルタイムに繋ぐという、クラウドならではのセキュリティ設計が施されているのです。
もしIMPORTRANGE関数の詳細な書き方やエラー時の対処法など、公式の正確な仕様を確認したい場合は、Googleが提供しているドキュメントを参考にすると良いですよ。公式の解説ページであるGoogle ドキュメント エディタ ヘルプ：IMPORTRANGEには、関数の詳細な使用例やよくあるトラブルシューティングが記載されていますので、一度目を通しておくと使い方の幅が広がるかなと思います。
スプレッドシートと外部ファイルを繋ぐ通信負荷の仕組み
それでは、ここからが本題となる「なぜIMPORTRANGE関数を使うとスプレッドシートが重くなるのか」という通信負荷の仕組みについて、より詳しくお話ししていきますね。結論から言うと、通常のファイル内でのセル参照と、IMPORTRANGE関数による参照とでは、データを読み込むためのアプローチと必要な通信プロセスが全く異なるからなのです。
同一ファイル内の別シートを参照する場合（例えば、=Sheet2!A1のような数式）、スプレッドシートはそのファイルがロードされているブラウザのメモリ領域、または同じファイルサーバー内のリソースを使って瞬時に処理を完了させることができます。通信を伴わないため、処理時間はミリ秒単位であり、動作が遅くなることはほとんどありません。一方、IMPORTRANGE関数の場合は、スプレッドシートがインターネットを経由してGoogleのサーバーにアクセスし、別の場所に保存されているファイルからデータを引っ張ってくる「APIリクエスト（Web通信）」を毎回裏側で送信しているのですよ。
私たちがセルにIMPORTRANGE関数を入力し、アクセスが許可されると、スプレッドシートの裏側では以下のような一連の通信プロセスが走っています。
【IMPORTRANGE関数のデータ読み込みプロセス】
1. 参照先のスプレッドシートから、Googleのシステムに対して「指定されたスプレッドシートIDのファイルを読み込んでください」という命令（APIリクエスト）が送信される
2. Googleのクラウドサーバーが該当のスプレッドシートを探し当て、ファイルを開く準備をする
3. ユーザーにそのファイルを閲覧する権限（アクセス許可）があるかをサーバーが検証する
4. 認証クリア後、サーバー上で参照元シートが展開され、指定された範囲のセルデータを抽出する
5. 抽出したデータ群をGoogleのクラウドネットワークを介して、参照先のスプレッドシートへ転送する
6. 参照先のスプレッドシートがデータを受信し、セルに値を流し込んで描画する
このように、たった1つのIMPORTRANGE関数を動かすだけでも、これだけのサーバーアクセスと通信処理が必要になるのですね。さらにスプレッドシートには、「参照元のファイルで値が書き換わると、自動的に参照先でも再計算を行ってデータを更新する」という自動更新仕様があります。そのため、参照元のスプレッドシートで多くの人が同時編集を行っていたり、数式によって値が頻繁に変更されたりすると、そのたびにこの一連のAPI通信が何度も繰り返し呼び出されることになるのです。これにより通信処理が渋滞を起こし、処理が追いつかなくなったセルは「Loading...」のまま固まってしまうわけですね。
特に危険なのが、同じシートの中で何十箇所、何百箇所もIMPORTRANGE関数を使っている状態です。例えば、別々のURLから少しずつデータを引っ張ろうとして、たくさんのセルに個別にIMPORTRANGE関数を書き込んでしまうと、シートを開いた瞬間に数百回ものAPIリクエストが同時にGoogleのサーバーへと送信されてしまいます。こうなると、Google側で設定されているクエリ制限（APIの同時通信量に対する制限）に引っかかり、読み込みエラーを起こすだけでなく、ブラウザのCPU使用率が100%近くまで跳ね上がり、パソコン全体の動作まで重くなってしまうのですよ。
また、IMPORTRANGE関数が処理するデータそのものが巨大である場合も同様に重くなります。何万行にも及ぶ巨大なテーブルを一度に引っ張ってこようとすると、ネットワークを通過するデータ量が大きくなり、転送とメモリへの格納に大きな遅延が発生します。これらが複合的に絡み合うことで、スプレッドシートが完全にフリーズしてしまうような深刻な事態が引き起こされるのです。
スプレッドシートの動きが重くなってしまう原因は、実はこのIMPORTRANGE関数だけではありません。全体の記述ルールやシートの管理方法を見直すだけで、驚くほどシートが軽くなることもありますよ。もし、スプレッドシート自体の動作を根本的にスピードアップさせたいと考えているなら、私が以前にまとめたこちらの記事もぜひ参考にしてみてくださいね。を紹介しているこの記事では、無駄な計算を省き、シート全体のレスポンスを向上させるための実用的なテクニックを多数紹介しています。IMPORTRANGEの最適化と組み合わせることで、さらにサクサクとした快適な環境を作ることができるはずですよ。
ここで、IMPORTRANGE関数による外部参照と、同一スプレッドシート内での内部参照の仕様の違いについて、分かりやすく表にまとめて比較してみましょう。これを頭に入れておくことで、どちらの方法を選ぶべきかの判断基準が明確になるかなと思います。
| 比較項目 | IMPORTRANGE関数（外部ファイル参照） | シート内参照（同一ファイル内参照） |
|---|---|---|
| データの取得元 | 外部に存在する全く別のスプレッドシートファイル | 同じスプレッドシートファイル内の別シート |
| 読み込み速度 | 比較的遅い（通信環境やAPIの応答に左右される） | 極めて高速（同一のメモリ空間で即時処理される） |
| 通信プロセスの有無 | あり（Googleサーバーを経由したAPIリクエストが発生） | なし（ブラウザおよび内部計算エンジンで完結） |
| データの更新頻度 | 参照元が更新された際に、数秒〜十数分の時間差を伴って自動更新 | 元データの入力と同時に、一瞬でリアルタイム同期 |
| オフラインでの動作 | 制限あり（通信が途切れると新しい値の取得は不可能） | 動作可能（ローカルに一時保存された状態で計算が維持） |
| 設定の難易度 | URL指定や初回接続時の権限許可（アクセス許可）が必要 | シート名とセル範囲を指定するだけで即時利用可能 |
表を見ると一目瞭然ですが、IMPORTRANGE関数はスプレッドシートの外側に通信の網を広げるため、その利便性と引き換えにどうしても相応のシステム負荷がかかってしまうのですね。この基本特性を理解しておくことが、今後のパフォーマンス改善作業において非常に重要なベースとなってきますよ。
次のパートでは、IMPORTRANGE関数が重くなってしまうより具体的な原因（データの件数やセルの参照方法、芋づる式の計算リンクなど）について、さらに一歩踏み込んで詳しく掘り下げてお伝えしますね。原因をピンポイントで特定することで、あなたのスプレッドシートを軽くするためのアプローチがより明確になるはずですよ。
IMPORTRANGE関数が重くなる5つの主な原因
Googleスプレッドシートを使っていて、「なんだか動作がカクつく」「セルの更新に時間がかかる」と感じたことはありませんか？特に、別ファイルからデータを引っ張ってくる「IMPORTRANGE（インポートレンジ）関数」を使っている場合、それがシート全体の動作を遅くしている主犯かもしれません。
IMPORTRANGE関数はとても便利で、社内のデータベースや別部署の売上シートから最新情報を自動で引っ張ってくるのに大活躍しますよね。私も初めてこの関数を知ったときは、「これは便利すぎる！」と感動して、あちこちのシートで使いまくっていました。ですが、使い方を誤るとスプレッドシートが急に重くなってしまい、作業効率がガクンと落ちてしまいます。
では、なぜIMPORTRANGE関数を使うとスプレッドシートが重くなってしまうのでしょうか？その具体的な理由は、スプレッドシートが裏で行っている「通信」と「再計算」の仕組みにあります。ここでは、IMPORTRANGE関数が重くなる5つの主な原因について、実体験を交えながら詳しく紐解いていきますね。原因をしっかりと把握することが、シートを劇的に軽くするための第一歩になりますよ。
原因1：参照元のスプレッドシートのデータ量が多すぎる
まず最初に疑うべき原因は、「参照元（インポート元）のスプレッドシートにあるデータ量そのものが多すぎる」という点です。これはスプレッドシート全体の動作速度にも直結する非常に基本的なポイントですね。
具体的には、参照元に数万行を超える巨大なデータが格納されていたり、使っていない無駄な行や列がそのまま放置されていたりすると、IMPORTRANGE関数はそれらすべてのデータをインターネット経由で読み込もうとします。スプレッドシートはWebブラウザ上で動作するアプリケーションなので、一度に読み込むデータ量が膨大になると、ブラウザのメモリを大量に消費して動作が重くなってしまうのです。
また、やってしまいがちなのが「列全体を曖昧に指定する」という書き方です。たとえば、必要な範囲が「A1からG100」までであるにもかかわらず、以下のように記述してはいないでしょうか？
注意したい範囲指定の例：
=IMPORTRANGE("スプレッドシートのURL", "シート1!A:Z")
このように「A:Z」のように行番号を指定しないオープンレンジ（開いた範囲）で書いてしまうと、Googleスプレッドシートは「A列からZ列までのすべての行（現在データがない空のセルも含めて数万行分すべて）」を読み込みの対象としてスキャンしようとします。スプレッドシートの行数上限は現在1000万セルまでに拡大されていますが、それだけの広い範囲を毎回チェックしにいくとなると、当然通信量も増えますし、データの更新処理に膨大な時間がかかってしまいますよね。
スプレッドシートの動作が全体的に重いと感じるときは、IMPORTRANGE関数だけでなく、シート全体の肥大化が影響していることも多いです。そんなときは、まず基本的なチューニング方法をまとめたこちらの解説記事「」を参考に、シート内の不要なデータを整理してみることをおすすめします。参照元が軽くなれば、自然とIMPORTRANGE関数の読み込み速度も改善されますよ。
データ量を抑えて効率よくインポートするためには、あらかじめ範囲を「A1:G100」のように明確に指定して、読み込むデータサイズを最小限に絞り込むことが何よりも大切です。
原因2：IMPORTRANGE関数をシート内に大量に並べている
次によくある原因が、「IMPORTRANGE関数をシート内に大量に並べている」というケースです。これもシートのパフォーマンスを急激に低下させる大きな原因になります。
例えば、日次の売上データや、複数の支店ごとのデータを別々のファイルから集計するために、1つのシート内に数十個、ときには数百個ものIMPORTRANGE関数を並べて書いてしまうことがありますよね。私も過去に、支店ごとのスプレッドシートから売上金額を1セルずつ引っ張ってこようとして、IMPORTRANGE関数を縦にずらりと50行以上並べたシートを作ったことがあります。その結果、シートを開くたびに「Loading...」の表示が延々と続き、最終的には「エラー」と表示されて動作が完全に停止してしまいました。
大量のIMPORTRANGEが重い理由：
IMPORTRANGE関数が1つ実行されるたびに、Googleのサーバー間で個別に通信（APIリクエスト）が発生します。つまり、50個のIMPORTRANGE関数があれば、同時に50回もの通信リクエストが飛び交うことになります。これにより、Googleのサーバー側で通信制限（クォータ制限）がかかったり、処理待ちが多発して全体の表示が極端に遅くなったりするのです。
さらに、IMPORTRANGE関数は互いに依存関係を持ちやすく、1つのインポート処理が遅延すると、それを参照している他の数式（SUMIFSやVLOOKUPなど）の計算もすべてストップしてしまいます。その結果、スプレッドシート全体の再計算ループが走り続け、PCのCPUファンが激しく回りだす事態に陥ることも珍しくありません。
この問題を避けるためには、細切れに何回もIMPORTRANGE関数を呼び出すのではなく、「大きめの範囲で一度にドカンとインポートして、必要なデータはスプレッドシートのローカル関数で切り出す」というアプローチが極めて有効です。1行ずつ小分けにして引っ張ってくるよりも、テーブル全体を1つのIMPORTRANGE関数で取得し、それを別シートに配置した上で、INDEXやMATCH、あるいはQUERY関数などを使って必要な情報を取り出すほうが、通信回数が1回で済むため圧倒的に動作が軽くなりますよ。
原因3：揮発性関数（TODAY, NOW, RAND, OFFSET）との組み合わせ
3つ目の原因は、数式の組み合わせによるものです。特に、「IMPORTRANGE関数と揮発性関数を組み合わせて使っている」場合、地獄のような再計算ループが発生してシートが使い物にならなくなることがあります。
「揮発性関数（Volatile Functions）」とは、スプレッドシート内で何か1つでも変更があったり、一定時間が経過したりするたびに、強制的に再計算を実行する関数のことです。代表的なものとして、以下の関数が挙げられます。
TODAY()（今日の日付を返す）NOW()（現在の日時を返す）RAND()/RANDBETWEEN()（ランダムな数値を返す）OFFSET()（指定したセル位置から範囲を返す）INDIRECT()（文字列で指定されたセル参照を返す）
これらの関数は非常に便利なのですが、IMPORTRANGE関数と組み合わせてしまうと、恐ろしい現象が起こります。通常、IMPORTRANGE関数は参照元のデータに変更がない限り、一定時間はキャッシュ（一時保存データ）を利用して素早く結果を表示しようとします。しかし、数式の中に揮発性関数が含まれていると、シート内のどこか1箇所を書き換えるたびに、あるいは数分おきに、スプレッドシート全体が「再計算が必要だ！」と判断してしまいます。
絶対に避けたい組み合わせの例：
=QUERY(IMPORTRANGE("スプレッドシートのURL", "データ!A:Z"), "SELECT * WHERE Col1 >= DATE '" & TEXT(TODAY(), "yyyy-mm-dd") & "'")
このようにQUERY関数の条件式にTODAY()を組み込み、その中でIMPORTRANGE関数をネスト（入れ子）にすると、シートを触るたびに毎回外部シートへのアクセスとデータ取得が最初から実行されてしまいます。
この再計算が走ると、IMPORTRANGE関数はキャッシュを破棄し、わざわざインターネットの向こう側にある参照元スプレッドシートへ再びデータを読み込みに行きます。これが何度も繰り返されることで、シート全体が常に「読み込み中（Loading...）」の状態から抜け出せなくなってしまうのです。
もし今日の日付に基づいてデータをフィルタリングしたい場合は、IMPORTRANGE関数の中に直接TODAY()を書き込むのは避けましょう。まずは別のシートやセルに一度IMPORTRANGEで生データをそのまま引っ張ってきて、その後にローカルのシート上でTODAY()を使ったフィルタリングを行うなど、「インポートする処理」と「日付で絞り込む処理」を完全に切り分けるのがスマートな解決策です。これだけでも、無駄な再計算が劇的に減り、驚くほどサクサク動くようになりますよ。
なお、Googleスプレッドシートの関数の仕様や詳細な技術情報については、Googleが提供する公式ドキュメントも非常に参考になります。関数の制限事項などが詳しく記載されていますので、より深く学びたい方は Google ドキュメント エディタ ヘルプ：IMPORTRANGE（外部サイト）も併せてチェックしてみてくださいね。
原因4：インポートしたデータに対する「条件付き書式」や「配列数式（ARRAYFORMULA）」の過剰な適用
4つ目の原因として挙げられるのが、「インポートしたデータに対して、条件付き書式や配列数式（ARRAYFORMULA）を過剰に適用している」というケースです。これも見落としがちですが、シートの描画速度や計算速度に大きな影響を与えます。
条件付き書式は、データの内容に応じてセルの色を自動で変えてくれるため、見た目を整理するのにとても便利ですよね。しかし、条件付き書式はブラウザのCPUに大きな負担をかける処理でもあります。IMPORTRANGE関数によって常に新しいデータがインターネット経由で流れ込んでくるシートにおいて、列全体（例えばA列からZ列の全体）に複雑な条件付き書式が設定されていると、データの更新が発生するたびにブラウザは「画面の再描画」と「スタイルの再計算」を数千〜数万セルに対して行うことになります。
これと同じことが、ARRAYFORMULA関数や、VLOOKUP関数などの検索関数を列全体に適用している場合にも起こります。インポート元のデータが更新されてIMPORTRANGEが新しい値を読み込むと、それを参照している数千行分のARRAYFORMULAが一斉に再計算を始め、結果としてブラウザのタブがフリーズしてしまうのです。
画面描画と再計算の仕組み：
スプレッドシートは見た目（スタイル）の処理と数式（計算）の処理を分けて実行していますが、IMPORTRANGEが走るとその両方がトリガーされます。特にスタイル変更（レンダリング）はシングルスレッドであるJavaScriptの処理を占有しやすいため、カクつきやフリーズの直接的な原因になります。
これを解決するためには、IMPORTRANGEでデータを取り込むだけの「データ専用シート」を作り、そこには余計な色分けや計算式を一切入れないようにするのがベストです。そして、実際に人が見るための「表示用シート」を別に作成し、そちらで必要なデータだけを参照して色付けや集計を行うように心がけてみてください。これだけでブラウザの負担は劇的に軽くなりますよ。
原因5：同一の参照元スプレッドシートに対する「同時アクセス（リクエスト）」の集中
最後の5つ目の原因は、「同一の参照元スプレッドシートに対する同時アクセスの集中」です。これは個人のPCやシートの書き方ではなく、Googleのシステム的な仕様に関わる原因になります。
社内で「マスター売上表」や「全社顧客リスト」のような、共通の親ファイルを用意している企業は多いと思います。この親ファイルから、各プロジェクトや各個人のスプレッドシート（子ファイル）へ、それぞれIMPORTRANGE関数を使ってデータを引っ張ってくるという運用ですね。この運用自体は非常に合理的なのですが、子ファイルが数十〜数百個に増えていくと、ある問題が発生します。
それは、複数の子ファイルが同時に親ファイルへとアクセス（読み込みリクエスト）を送信することによる、通信のボトルネックです。Googleスプレッドシートでは、1つのスプレッドシートに対する同時リクエスト数や処理量に一定の制限が設けられています。朝の始業直後や夕方の集計時間帯など、多くの人が同時にスプレッドシートを開いて作業するタイミングで、一斉にIMPORTRANGEによるリクエストが親ファイルに集中すると、Googleのサーバーが処理しきれずにエラー（#REF!や延々とLoadingが続く状態）を引き起こしてしまいます。
同時リクエスト制限の回避：
誰かがデータを書き換えるたびにすべての子ファイルにリアルタイムでデータが送信されるため、データが頻繁に更新される親ファイルほど、この同時アクセスによる負荷は高くなります。親ファイルへの直接的なアクセスを減らすための設計が必要です。
もしこの状況に心当たりがある場合は、IMPORTRANGEによる「リアルタイム同期」を見直し、Google Apps Script（GAS）を使った「定期的なバッチ同期」や「ミラーシートの作成」など、通信回数そのものを間引く方法を検討してみる時期かもしれませんね。
スプレッドシートを軽くする！IMPORTRANGE高速化の解決策
スプレッドシートでIMPORTRANGE関数を使い始めたものの、シートを開くたびに「読み込み中…」の表示が出たまま画面が固まってしまったり、セルの入力やスクロールがガクガクと重くなったりして困っていませんか？外部のファイルから自動で最新のデータを引っ張ってきてくれる非常に便利な関数ですが、設定の仕方を少し間違えるだけで、シート全体の動作を一気に激重にしてしまう原因になるのですよ。
特に業務で毎日使うスプレッドシートの場合、作業中に何度も待たされるのは本当に大きなストレスになりますし、仕事の生産性も下がってしまいますよね。実は、IMPORTRANGE関数の計算負荷を下げるためには、いくつかの定番のテクニックが存在します。ちょっとした書き方の工夫や運用の見直しを行うだけで、それまでの重さが嘘のように解消され、サクサクと快適に動くようになることも珍しくありません。
今回は、非IT職の方でも今すぐ実践できる具体的な解決策を3点紹介します。スプレッドシート全体の動作を軽くするためのアプローチとしても非常に効果的ですので、ぜひあなたのシートでも試してみてくださいね。
解決策1：データ専用の「マスターシート」を作成し参照を1箇所に集約する
まず最初に見直したいのが、「同じファイルを何度もIMPORTRANGE関数で呼び出していないか」という点です。実は、スプレッドシートが激重になってしまう最も多い原因がこれなのですよ。
例えば、売上データや顧客リストなどの外部ファイルを元に、自シート内でVLOOKUP関数やQUERY関数を使ってデータを探したい場面を想像してみてください。以下のように、VLOOKUP関数の引数の中に直接IMPORTRANGE関数を書き込んで、それを下方向のセルに何百行もコピーして使っていませんか？
=VLOOKUP(A2, IMPORTRANGE("スプレッドシートURL", "マスター!A:D"), 2, FALSE)
この書き方をしてしまうと、スプレッドシートは行の数だけ外部のファイルにアクセスし、データを読み込もうとします。データが1,000行あれば、なんと1,000回も通信を発生させることになるのです。実は、私も昔はこの罠に完全にはまってしまい、シート全体が「Loading...」のままフリーズしてしまって真っ青になった苦い経験があります。これでは動作が遅くなるのも当然ですし、Googleの通信制限やメモリの上限に達して「Loading...」エラーを吐いてしまう原因になります。
また、VLOOKUPの引数に入れていなくても、別々のシートや異なるセルで「全く同じスプレッドシートの同じ範囲」を何度もIMPORTRANGEで個別に呼び出すのも避けるべきです。重複した通信が何度も走り、無駄な計算負荷がかかり続けてしまいます。
この問題を一発で解決するのが、データ専用の「マスターシート（Rawタブ）」を作成し、参照を1箇所に集約するという方法です。やり方はとてつもなくシンプルで、以下の手順で進めていきますよ。
- 手順1：新しいタブの作成
あなたのスプレッドシート内に、新しく「データ読み込み用」の専用タブ（例：「マスターデータ」や「インポートraw」など）を1つ作成します。 - 手順2：IMPORTRANGEの記述
作成した専用タブのセルA1に、IMPORTRANGE関数を1つだけ記述します（例：=IMPORTRANGE("URL", "マスター!A:D")）。これで、外部のデータが一括でそのタブに展開されます。 - 手順3：ローカル参照への書き換え
VLOOKUP関数やQUERY関数を使う計算用シート側では、外部URLを参照するのではなく、先ほどデータを取り込んだローカルの専用タブを参照するように数式を書き換えます（例：=VLOOKUP(A2, マスターデータ!A:D, 2, FALSE)）。
このように工夫するだけで、外部との通信は専用タブにある「たった1つのIMPORTRANGE関数」だけで完結します。他のセルはすべてスプレッドシート内部のローカルな参照になるため、通信のオーバーヘッドが一切なくなり、動作速度が劇的に向上するのですよ。まさに「急がば回れ」の最適な設計図解と言えますね。
なぜこれほど動作が変わるのかというと、スプレッドシートが数式を再計算する仕組みに理由があります。スプレッドシートは、シート内のどこかのセルを編集するたびに、関連する数式を自動的に再計算しようとします。特にVLOOKUP関数の中にIMPORTRANGE関数を直接記述していると、セルのちょっとした編集や値の変更が行われるたびに、その全ての行で別スプレッドシートへのアクセスと再ダウンロードがトリガーされてしまうのです。これでは、ちょっとデータを打ち込むだけで数秒〜数十秒待たされることになりますし、複数人で共同編集しているシートであれば、全員のブラウザがフリーズしてしまうことすらあります。
マスターシートを挟む形にすれば、外部データの読み込みは「マスターシートのIMPORTRANGE」が自動で裏で行うだけで、自シート内での再計算は一瞬で終わるローカル参照の処理（マスターデータタブの参照）になります。この差はデータ量が多ければ多いほど、顕著に現れてきますよ。
【マスターシート集約のポイント】
- 「1つの外部データにつき、使うIMPORTRANGEはシート全体で1個だけ」を鉄則にする。
- 外部から一度だけローカルシートにデータを落とし込み、その後にVLOOKUPやQUERYなどで切り出す。
- スプレッドシート内の通信回数を最小限に抑えることで、フリーズのリスクを大幅に減らせる。
ちなみに、スプレッドシート全体の動作を軽くする解決策については、こちらの記事（）でもさまざまな角度から詳しく解説しています。IMPORTRANGE以外の原因（不要な空行の削除など）も気になる方は、ぜひこちらもチェックしてみてくださいね。
解決策2：範囲の指定を具体化して余分な空欄の読み込みを避ける
次に試したいのが、「IMPORTRANGEで取得する範囲の最適化」です。外部からデータを引っ張ってくる際、参照元のスプレッドシートの範囲をどのように指定していますか？
多くの場合、数式を以下のように書いているのではないでしょうか。
=IMPORTRANGE("スプレッドシートURL", "売上明細!A:Z")
「列全体を指定しておけば、後からデータが下に追加されても自動で読み込んでくれるから便利」と思うかもしれません。確かに便利なのですが、この「A:Z」という指定方法には大きな罠が潜んでいるのですよ。
スプレッドシートで「A:Z」のように行数を指定しない書き方をすると、「現在データが入っている範囲だけでなく、その下にある大量の『空欄（空っぽのセル）』まですべて読み込み対象」として扱ってしまいます。仮に、元シートにはデータが500行しか入っていなかったとしても、そのシートに1万行分の空行が存在していれば、IMPORTRANGEは1万行分のセルをスキャンし、データを同期しようとします。さらに列数がZまであるとなると、500行×26列＝13,000セルで済むはずの処理が、10,000行×26列＝260,000セル分もの膨大なデータを処理することになり、計算負荷が何十倍にも膨れ上がってしまうのです。
この無駄な読み込みを防ぐためには、範囲の行数や列数をできるだけ具体的に数値で指定するのが最も効果的です。例えば、データが直近で1,000行を超える見込みがないのであれば、以下のように記述範囲を絞ってみてください。
=IMPORTRANGE("スプレッドシートURL", "売上明細!A1:G1000")
このように列を「A:Z」から「A:G」に必要な部分だけに絞り、行も「1000行目まで」と明確に上限を区切ることで、読み込むセル数を最小限に抑えることができます。これだけで、読み込み中のぐるぐるが消えるスピードが見違えるほど早くなりますよ。
スプレッドシートの1シートあたりのセル数上限は、現在1,000万セルとなっています。これは一見とても大きな数字に見えますが、複数のIMPORTRANGE関数で「列全体（A:Zなど）」を広範囲に読み込んでいると、あっという間にセル制限に近づいてしまいます。特に読み込み先のシート側で条件付き書式や別の関数が組み合わさっていると、動作の重さは加速度的に増していきます。そのため、「本当にZ列まで必要なのか？」「実際はA列からG列までの7列で十分ではないか？」といった視点で、必要な範囲をギリギリまで切り詰めることが大切です。
【範囲指定に関する注意点】
- 「A:Z」のような曖昧な指定は、不要な空欄セルを大量にスキャンするため、メモリ不足や速度低下の最大の原因になります。
- データの追加を考慮して少し余裕を持たせる場合でも、「A1:G2000」のように上限の行数を設定しておくのがおすすめです。
- 参照元シートでデータが増えて指定範囲（例：1,000行）を超えそうな場合は、必要に応じて数式の指定範囲を書き換えるか、少し多めのバッファを設けるように設計しておきましょう。
少しの手間ですが、この「範囲の制限」を徹底するだけで、スプレッドシートのメモリ使用量は驚くほど削減されます。特に共有ドライブにある重いマスターデータから一部分だけを引っ張ってくるような運用をしている方は、今すぐ数式の範囲指定を見直してみてくださいね。
解決策3：データのコピー＆ペースト（値のみ貼り付け）で数式を固定化する
3つ目の解決策は、運用のルールを少し工夫する方法です。それは、「過去のデータや、もう更新されることのないデータは、数式を削除して『値』として固定してしまう」というテクニックです。
IMPORTRANGE関数はリアルタイム同期が魅力ですが、これは裏を返せば、「スプレッドシートを開いている間、常に外部のファイルを監視し、再計算の待機状態にある」ということです。例えば、「先月の売上実績データ」や「昨年の顧客アンケート結果」など、すでに確定していて今後内容が書き換わることがないデータであれば、リアルタイムで同期し続ける必要は全くありませんよね。
しかし、確定したデータであるにもかかわらず、IMPORTRANGE関数をそのまま放置しておくと、そのシートを開くたびに無駄な通信と再計算が発生し続けます。こうした「過去の遺物」となった数式がシート内に何個も残っていると、シートはどんどん肥大化し、最終的には開くことすら困難な激重シートになってしまいます。
そこで、データが確定したタイミングで、以下の手順で数式を「値」に貼り替えて固定化しましょう。
- 手順1：範囲の選択
IMPORTRANGE関数が入っているセル（またはデータが表示されている範囲全体）を選択します。 - 手順2：コピーの実行
選択した範囲をコピーします（WindowsならCtrl + C、MacならCmd + C）。 - 手順3：値のみ貼り付け
そのままコピーした範囲の左上（または選択中の範囲内）で右クリックし、メニューから「特殊貼り付け」＞「値のみ貼り付け」を選択します（WindowsのショートカットキーはCtrl + Shift + V、MacはCmd + Shift + V）。
この操作を行うと、セルの見た目はデータが残ったまま、裏側の数式（IMPORTRANGE）だけが消去されます。これでスプレッドシートの再計算対象から完全に外れるため、それ以降そのデータがシートの動作を重くすることは一切なくなりますよ。データ量が多いシートほど、この値貼り付けによる効果は劇的です。
【値貼り付けでシートの寿命を延ばそう】
毎月データが追加されるような運用であれば、「今月の最新データだけはIMPORTRANGEでリアルタイム同期しておき、月が変わって確定した先月分のデータは値貼り付けで固定する」という運用ルールを作るのがおすすめです。これを行うだけで、何ヶ月、何年と使い続けても重くならない、長寿命でスリムなスプレッドシートを維持することができますよ。
この値貼り付けのショートカットキー Ctrl + Shift + V は、スプレッドシートを使いこなす上で最も重要と言っても過言ではないほど便利な機能ですので、ぜひ指に覚え込ませておいてくださいね。
なお、IMPORTRANGE関数の仕様や再計算のトリガーなどについてさらに詳しく調べたい場合は、Googleが提供している公式ドキュメントも非常に参考になりますよ。英語や日本語の細かな挙動の仕様について正確な情報が記載されているため、技術的な裏付けが欲しい方はぜひ一読してみてください。
（参考外部リンク：Google ドキュメント エディタ ヘルプ：IMPORTRANGE）
IMPORTRANGEエラー・速度低下に関するよくある質問（FAQ）
Googleスプレッドシートで別ファイルからデータを取得するIMPORTRANGE（インポートレンジ）関数。便利な一方、「エラーが出る」「動作が重い」といったトラブルも多いのですよ。ここでは、実務でよくある疑問と解決策を分かりやすく解説しますね。イライラを解消して、快適な環境を整えましょう！
Q1：IMPORTRANGEが「#REF!」エラーを表示してデータが表示されなくなった時は？
データが消えて「#REF!」エラーになると焦りますよね。このエラーは、主に参照元への接続やアクセス権限に問題があることを示しています。次の3点を確認しましょう。
1つ目は「アクセス許可」の確認です。初めて使う際や所有者が変わった際は、セルをクリックして「アクセスを許可」という青いボタンを押す必要があります。セルにカーソルを合わせ、ボタンが出たらクリックしてくださいね。これは双方の編集権限を持つユーザーのみ可能です。
2つ目は参照先URLの変更です。ファイルの移動や削除があるとURLが無効になります。URLが正しいか確認し、必要なら最新のものに書き換えましょう。
3つ目は「閲覧権限」の有無です。あなたのアカウントが参照元シートの閲覧権限を失うと、データを取得できなくなります。直接ファイルを開けるか確認してみるのがおすすめですよ。
注意：一時的なエラーもあります！
Googleサーバーの負荷や回線の不安定さで一時的にエラーが出ることもあります。直らない場合は、数分待って再読み込みするか、数式の末尾にスペースを一度入れて再計算を促してみましょう。
Q2：IMPORTRANGEを自動ではなく特定のタイミングで更新させることはできますか？
「元データが更新されるたびに再計算されて重くなるのを防ぎたい」と思うこともありますよね。しかし、スプレッドシートの標準機能では、IMPORTRANGEの自動計算を停止して手動更新にすることはできません。
特定のタイミングで更新したい場合は、Google Apps Script（GAS）を活用するのが非常におすすめですよ。
GASを使えば、「ボタンを押したとき」や「毎日深夜」などのトリガーで、参照元のデータをコピーして『値のみ』貼り付けるプログラムを簡単に作れます。手元には数式ではなくテキストデータだけが残るため、作業中に何度も再計算が走ってフリーズするストレスが完全にゼロになりますよ。
GASでの手動更新コード例
シート上のボタンに以下のスクリプトを登録すれば、ワンクリックで更新できるようになりますよ。
function importValues() {
var srcSS = SpreadsheetApp.openById("スプレッドシートID");
var values = srcSS.getSheetByName("シート名").getRange("A1:D100").getValues();
SpreadsheetApp.getActiveSpreadsheet().getSheetByName("貼付先").getRange("A1:D100").setValues(values);
}
大量のデータを扱う場合、数式を「値化」してGASで制御するのが、シートを軽くするための最も効果的なテクニックです。
Q3：QUERY関数とIMPORTRANGEを組み合わせるとさらに遅くなりますか？
特定のデータを抽出するのに便利なQUERY関数ですが、`=QUERY(IMPORTRANGE("URL", "範囲"), "select...")` のようにネストして記述すると、動作を劇的に遅くさせる最大の原因になりますよ。
ネストすると、QUERYの処理が走るたびに、裏側でIMPORTRANGEによる外部接続と読み込みが何度も繰り返されてしまいます。同じシート内にこの数式が複数あると、通信負荷が何倍にもなり、シートがフリーズしてしまいます。
解決策は、「インポート専用のシートを作成し、そこにIMPORTRANGEを単独で記述してデータを引き込んでおくこと」です。
サクサク動かす設定手順
- 「インポート用」という空シートを1枚作成します。
- セルA1に `=IMPORTRANGE("URL", "範囲")` を書き、データを一度だけ読み込ませます。
- メインのシートで、そのインポート用シートを参照してQUERY関数を書きます（例：`=QUERY('インポート用'!A:Z, "select ...")`）。
こうしてインポート通信と集計処理を「分離」すれば、IMPORTRANGEの通信は1回だけで済み、QUERYはローカルデータから高速抽出するだけになるため、再計算の待ち時間はほぼゼロになりますよ。
まとめ：IMPORTRANGEの負荷を抑えてスプレッドシートを高速化し、今日も早く帰りましょう！
今回は、スプレッドシートを重くする「IMPORTRANGE関数」のエラー対策と高速化のFAQを解説しました。
便利なデータ連携機能ですが、通信負荷を考えずに使いすぎると、シートが固まって業務時間を奪う「時間泥棒」になってしまいます。Q3の「インポートシートの分離」やQ2の「GASによる値化」などを取り入れるだけで、表示スピードは劇的に向上するのですよ。
効率化で大切なのは、「ツールが無駄な計算や通信を繰り返さないように整えてあげること」かなと思います。シートがサクサク動けば、待ち時間のイライラもなくなり、エラー対応で残業することもなくなりますよ。無駄をなくして定時でサクッと退勤し、プライベートや大切な人と過ごす時間を増やしましょう。設定を見直して仕事をスマートに終わらせ、今日も早く帰りましょうね！
今回の重要ポイントまとめ
- 「#REF!」エラーは、まず「アクセスを許可」ボタンの有無やURL、閲覧権限を確認する。
- 更新タイミングを制御したいなら、GASを使って「値のみコピー」する仕組みを作る。
- QUERYとIMPORTRANGEはネストせず、インポート専用シートを1枚挟んでローカル参照させる。
- シートが重くて困ったときは、以前紹介したもあわせてチェック！
正確な情報は公式サイトをご確認ください。最終的な判断は専門家にご相談ください。
関連リンク：Google ドキュメント エディタ ヘルプ：IMPORTRANGE
関連リンク：Google ドキュメント エディタ ヘルプ：QUERY
日々のデータ管理で「スプレッドシートのIMPORTRANGE関数が重い原因と高速化のコツ」の操作に悩まないようになるだけでなく、知っておくと作業スピードが劇的にアップする「Googleスプレッドシートで重複をCOUNTIF関数で判定・抽出する方法」の基本や、「Googleスプレッドシートでセル内改行をする方法と一括置換・削除のコツ」のエラー対策については、以下の関連記事もぜひチェックしてみてくださいね。