月別・店舗別のシートを作って集計していると、「参照先のシート名だけ切り替えて同じ式を使い回したい」と感じる場面が増えてきます。そんなときに便利なのが、文字列で作った参照をそのままセル参照として扱えるINDIRECT関数です。うまく使えば、テンプレ化や連動プルダウンが一気に楽になり、運用の手間も減らせます。
一方で、INDIRECT関数は使い方を誤ると #REF! エラーが連鎖したり、ファイルが重くなったり、引き継ぎ時に「式が読めない」状態になったりしやすいのも事実です。「便利そうだから入れたのに、後から修正が地獄になる」――このパターンは珍しくありません。
本記事では、INDIRECT関数の基本から、別シート参照の切り替えや連動プルダウンの定番パターンを丁寧に解説しつつ、重くなる理由と避けたい設計も整理します。さらに、INDEX・XLOOKUP・テーブルなどの置き換えレシピまで含めて、「使うべき場面／避けるべき場面」を判断できるようになることを目標にまとめました。テンプレ運用や月次更新でシートを壊したくない方は、ぜひこのまま読み進めてください。
※本コンテンツは「記事制作ポリシー」に基づき、正確かつ信頼性の高い情報提供を心がけております。万が一、内容に誤りや誤解を招く表現がございましたら、お手数ですが「お問い合わせ」よりご一報ください。速やかに確認・修正いたします。
INDIRECT関数でできることと向いている場面
文字列を参照に変える仕組み
INDIRECT関数は、ひとことで言えば「セル参照を文字列で作り、その文字列を“本物の参照”として扱う」ための関数です。通常、ExcelやGoogleスプレッドシートでは =A1 のようにセル番地を直接書くことで参照します。一方、INDIRECT関数は "A1" のような文字列を受け取り、それを参照として解釈して値を返します。
たとえば次の2つは同じ結果になります。
=A1=INDIRECT("A1")
この仕組みが役立つのは、「参照先が固定ではなく、状況に応じて切り替えたい」場面です。参照先を式の中で直接固定してしまうと、シートの差し替えや月次の切り替え、店舗別の参照先切り替えなどが起きるたびに、式を作り直す必要が出てしまいます。INDIRECTを使えば、参照先をセルに入れた文字列や、文字列を連結して作った結果で切り替えられます。
ただし便利さの代償として、INDIRECTは「参照が見えにくくなる」「エラーが連鎖しやすい」「ブックが重くなりやすい」といった弱点も抱えます。したがって、闇雲に使うのではなく、向いている場面を見極めたうえで採用するのが重要です。
向いている代表例は次のとおりです。
月別・店舗別など、同じ構造のシートが複数あり、参照先シートだけを切り替えたい
入力フォームで、選択肢に応じて参照範囲（候補一覧）を切り替えたい（連動プルダウン）
「参照先セル番地」を別セルに管理しておき、テンプレ化・再利用したい
逆に、データ量が大きい集計や、引き継ぎ・監査が重視される仕組みでは、代替手段を優先したほうが安全なことが多いです。その判断材料は、後半の「重い理由」「代替案」で詳しく整理します。
ExcelとGoogleスプレッドシートで共通の考え方
INDIRECT関数はExcelにもGoogleスプレッドシートにも存在し、基本的な発想は共通です。「参照文字列を作って、それを参照として使う」という一点に集約されます。
共通する重要ポイントは次の3つです。
参照文字列が正しいかどうかがすべてを決める
INDIRECTが返す値は、参照文字列が参照できる形になっているかどうかで決まります。参照文字列が少しでも崩れると、値が取れず#REF!になったり、意図しないセルを参照したりします。参照文字列を“目で確認できる形”にするほどミスが減る
参照文字列を式の中で複雑に組み立てると、どこを参照しているか分からなくなりがちです。参照文字列を作る工程をヘルパーセルに分けるだけで、トラブルの切り分けが格段に簡単になります。INDIRECTは「動的参照」のための道具であり、万能ではない
可変範囲の集計、複雑な検索、外部ブック参照などに広げるほど、設計のリスクが上がりやすい傾向があります。動的参照が本当に必要か、他の関数やテーブル設計で置き換えられないかを必ず検討するべきです。
また、細部ではExcelとスプレッドシートで挙動や推奨パターンが異なる部分もあります。記事中では共通原理を軸にしつつ、「両者で迷いやすいポイント」を具体例で押さえていきます。
INDIRECT関数の書き方と基本例
構文と引数の意味
INDIRECT関数の基本形は以下です。
=INDIRECT(参照文字列, [参照形式])
ここで重要なのは、第一引数の「参照文字列」です。参照文字列とは、参照したいセル番地や範囲、または名前定義を「文字列」として指定したものを指します。
例：
"A1"例：
"B2:C10"例：
"'Sheet2'!B5"（シート名を含む参照）例：
"売上表"（名前定義を参照する場合）
第二引数の「参照形式」は、省略可能です。多くの場面では省略して問題ありません。一般的には次のイメージで理解すると良いです。
省略またはTRUE：A1形式で解釈（通常の
A1B2など）FALSE：R1C1形式で解釈（
R2C3のような表現）
A1形式に慣れているなら、まずは第二引数を使わずに運用し、R1C1が必要な局面が出たときだけ使うのが現実的です。
INDIRECTで失敗しやすいのは「参照文字列が完成していないのに、式全体としては成立してしまう」ケースです。たとえば、シート名セルが空白だったり、想定外のスペースが混ざったりすると、式は一見正しく見えても #REF! になります。したがって、INDIRECTを使う場合は「参照文字列が常に妥当になる入力制約」や「空白時のエラー回避」など、運用上のガードもセットで設計すると安全です。
セルに「B5」とあるときに値を取る
最も基本的な使い方は、「セルに入っている文字列を参照に変換する」パターンです。たとえば、A1セルに B5 と入力されているとします。このとき、B5セルの値を表示したいなら次のようにします。
=INDIRECT(A1)
この式は、「A1に入っている文字列（B5）を参照として使って、そのセルの値を返している」と理解できます。
ここから少し実務寄りにすると、「列」と「行」を別々に持って参照を組み立てたい場面が出てきます。たとえば、A1に列記号（Bなど）、A2に行番号（5など）を入れて参照するなら、次のように連結します。
=INDIRECT(A1 & A2)
このときの注意点は、「意図しない文字列になっていないか」を必ず確認することです。たとえばA1に B （末尾スペース付き）が入っていると "B 5" のようになり、参照として解釈できずエラーになります。入力規則で余計なスペースを防ぐ、TRIMで整形する、参照文字列を別セルに表示して確認できるようにする、といった工夫が有効です。
さらに、参照先を切り替える目的で「候補セル番地を一覧で管理する」運用もよくあります。たとえば、A列に参照先セル番地（B5、C10、D3…）を並べておき、選択した番号に応じて参照したいなら、INDEXなどで参照文字列を取り出してINDIRECTに渡す設計になります。こうした設計は便利ですが、参照文字列が増えるほど管理が難しくなるため、用途が明確な範囲に限定して使うのがおすすめです。
行番号・列番号から参照を組み立てる
業務で「行番号・列番号が数値として得られている」ケースは少なくありません。たとえば、検索結果として「何行目に見つかったか」が出る場合や、列番号が設定値として持たれている場合などです。このとき、行番号と列番号をA1形式のセル番地に変換するには、ADDRESS関数が便利です。
=ADDRESS(行番号, 列番号)
この結果は "B5" のような「文字列のセル番地」になります。したがって、INDIRECTと組み合わせると次のようになります。
=INDIRECT(ADDRESS(A1, B1))
ここでA1に行番号、B1に列番号が入っている想定です。ADDRESSが返すのは文字列なので、INDIRECTで参照に変換できる、という流れです。
ただし、この組み合わせは「動的参照」を簡単に作れる一方で、次の理由で乱用すると危険です。
参照先が増えるほど、どこを参照しているか追いにくくなる
大量セルに展開すると再計算が増え、ブックが重くなりやすい
行列の計算ミスがあると、意図しない参照（ずれたセル）を参照して気づきにくい
したがって、ADDRESS+INDIRECTは「どうしても参照を動的にする必要がある」「参照箇所が限定的」「参照ずれを検知できる仕組みがある」といった条件を満たすときに採用し、そうでない場合はINDEXなど別の設計に寄せたほうが安定します。
INDIRECT関数で別シート参照を切り替える
シート名をセルから参照する定番パターン
INDIRECTが最も活躍しやすいのが、「参照するシートを切り替える」場面です。月別に同じフォーマットのシートがあり、集計シートで参照先を切り替えて値を拾いたい、店舗別シートをプルダウンで切り替えたい、といった状況が典型です。
たとえば、A2セルに参照したいシート名（例：東京）が入っていて、そのシートのB2セルを参照したいなら、次のようにします。
=INDIRECT("'" & A2 & "'!B2")
ここで重要なのは、'（シングルクォート）でシート名を囲んでいる点です。シート名に空白や記号が含まれる場合でも壊れにくくなるため、「囲むのが必須」と考えておくと安全です。
このパターンの利点は明確です。参照先のシートを変更したい場合、式を直すのではなくA2セルのシート名を変更するだけで済みます。テンプレの使い回しや、月次の差し替えが非常に楽になります。
一方で、落とし穴もあります。A2セルが空白なら ''!B2 という参照になって #REF! になりますし、シート名が少しでもズレると参照できません。対策としては、次のような考え方が有効です。
シート名はプルダウン選択にして入力ミスを防ぐ
シート名セルが空なら空白を返すIFを挟む（例：
=IF(A2="","",INDIRECT(...))）参照文字列を別セルに表示し、見た目で確認できるようにする
「便利に切り替えられる」からこそ、入力の揺れに弱いという性質を理解してガードを作ることが、事故を防ぐコツです。
シート名に空白がある場合の書き方
シート名に空白が入るケースは現場ではよくあります。たとえば、2025 12月、売上 集計、店舗 A のように、見た目の分かりやすさを優先して空白を入れる運用は珍しくありません。このとき、シングルクォートで囲まない参照は壊れやすくなります。
安全な形は次のとおりです。
=INDIRECT("'" & A2 & "'!B2")
A2が 2025 12月 なら、参照文字列は "'2025 12月'!B2" となり、空白込みでも正しく参照できます。
さらに注意したいのは、「空白があるシート名」だけが危険なのではなく、「後から空白が入る」ことが危険だという点です。最初は空白なしで運用していても、途中で担当者がシート名を見やすく変えることは十分あり得ます。そのとき、クォートなしの参照が突然壊れます。したがって、最初からクォート込みの型で統一しておくのが安全策です。
また、シート名の末尾にスペースが混ざっている（見た目では分からない）ケースもあります。こうした“隠れスペース”は #REF! の原因になりやすいため、シート名の入力を手打ちにしない、プルダウンで選ばせる、といった対策が効果的です。
スプレッドシートのシート参照例
Googleスプレッドシートでも、シート参照を文字列で作ってINDIRECTに渡す発想は同じです。たとえば、シート名とセル番地を連結して参照します。
=INDIRECT("シート2!" & B10)
（B10にA1のようなセル番地が入っている想定）
Excelと同様に、参照文字列が正しいことが大前提です。スプレッドシートの場合もシート名に空白がある可能性があるため、参照文字列を組み立てるときは、シート名を引用符や適切な形で扱う意識が重要になります。
また、スプレッドシートではR1C1形式を使いたい場面があり、その場合は第2引数でA1形式かどうかを切り替えます。
=INDIRECT("R2C3", FALSE)
A1形式に慣れている場合、R1C1はとっつきにくいですが、行列で参照位置を扱うときに考え方が単純になる利点があります。とはいえ、慣れないうちはA1形式で統一し、複雑化してきた段階で検討するのが無理のない進め方です。
連動プルダウンと可変範囲で使うINDIRECT関数
名前定義とINDIRECTで連動リストを作る
INDIRECTの代表的な活用法として「連動プルダウン」があります。最も有名なのは「都道府県を選ぶと市区町村候補が切り替わる」形式です。Excelではデータの入力規則（プルダウン）と名前定義を組み合わせることで実現できます。
基本の考え方は次のとおりです。
都道府県ごとの候補一覧（市区町村リスト）を作る
その候補一覧範囲に「都道府県名」と同じ名前を付ける（名前定義）
2段目プルダウンの参照元に
=INDIRECT(都道府県セル)を指定する
たとえば、A2セルに都道府県が入るとします。A2が 東京 のときは「東京」という名前定義範囲を参照し、A2が 埼玉 のときは「埼玉」という名前定義範囲を参照する、という仕組みです。
この方式の強みは、「式が短く、挙動が直感的」な点です。一方で、実務では次のような罠があります。
都道府県の表記揺れ（例：
東京都と東京）があると名前定義が一致せず#REF!名前定義の管理が属人化しやすい（どこで定義されているか分からなくなる）
都道府県名にスペースや記号が入ると、名前定義に使いにくい（ルール調整が必要）
このため、連動プルダウンをINDIRECTで作る場合は、次のような運用ルールを最初に決めておくと安定します。
選択肢の文言（都道府県名など）と、名前定義名を完全一致させる
表記揺れが起きないよう、マスタ一覧を元にプルダウンを作る
名前定義の一覧（どの名前がどの範囲か）を別シートにまとめ、引き継ぎ可能にする
「できる」ことと「運用できる」ことは別です。連動プルダウンは便利な分、運用ルールが曖昧だと壊れやすいため、最初の整備が重要です。
可変範囲の集計で使うときの注意
可変範囲とは、データの行数が増減する表のことです。たとえば、毎日データが増える日報、受注履歴、ログなどが該当します。こうした表を集計する際に、INDIRECTで「範囲の終端を動的に作る」設計がしばしば登場します。
たとえば、最終行番号が別セルに入っているとして、"A2:A" & 最終行 のような文字列で集計範囲を作り、INDIRECTで参照に変換する方法です。小規模なら機能しますが、注意点が多いです。
主な注意点は次のとおりです。
INDIRECTの使用箇所が増えるほど、計算が重くなりやすい
可変範囲をあちこちで作り始めると、同じようなINDIRECTが大量に増殖します。参照が見えにくく、監査しにくい
集計範囲が文字列で隠れるため、範囲がズレても気づきにくくなります。最終行の算出ミスが致命的になりやすい
最終行を求める式が崩れると、集計範囲が欠けたり過剰になったりします。
可変範囲の集計は、INDIRECTよりも安定する選択肢が多く存在します。代表的なのは次です。
Excelなら、データ範囲をテーブル化し、列参照で集計する
条件集計（SUMIFS/COUNTIFS）で「必要な行だけ」を拾う設計に寄せる
データを統合して、ピボットや集計表で扱う（規模が大きいほど有効）
INDIRECTを使って可変範囲を作るのは、実装は簡単でも“保守の難しさ”が後から効いてきます。どうしても採用するなら、使用箇所を限定し、参照文字列をヘルパーセルで可視化し、最終行算出が壊れたときに検知できる仕組み（件数チェックなど）をセットにするのが望ましいです。
検索関数と組み合わせるときの設計ポイント
実務でよくある要望として、「参照するシートを切り替えながら検索したい」「店舗別シートから同じキーで値を取ってきたい」というものがあります。これをINDIRECTで実現する場合、検索範囲そのものを INDIRECT("'"&シート名&"'!A:D") のように文字列で作って渡す形になりやすいです。
この設計の難しさは、「参照が二重に動的になる」ことです。
シート名が動的
さらに検索範囲（列範囲）が動的
結果として、式が長くなり、どこが原因でエラーが出ているのか分からなくなりがちです。ここで有効な設計ポイントは次の3つです。
参照文字列をヘルパーセルに分離する
参照文字列を式の中で連結せず、別セルで完成形を作って表示し、そのセルをINDIRECTに渡します。これだけで原因切り分けが大幅に楽になります。検索対象のデータ構造を見直す
店舗別にシートを分けていると参照切り替えが必要になりますが、そもそもデータを1つに統合し、店舗列を持たせたほうが、検索や集計は圧倒的に簡単になります。後から困る構造になっていないか、一度見直す価値があります。代替関数で“参照切り替え”を避けられないか検討する
参照を動的にするのではなく、検索キーから必要な行を絞り込む設計にすると、INDIRECTの出番が減ります。環境によってはXLOOKUP、FILTER、QUERYなどの関数が有効です。
INDIRECTは「その場の問題を解決する」には強い反面、データ構造の問題を覆い隠してしまうことがあります。検索と組み合わせる場面ほど、式でねじ伏せる前に「データの持ち方」を整える意識が重要です。
INDIRECT関数が重い理由と避けたい設計
揮発性と再計算の考え方
INDIRECT関数の大きな弱点として、ブックが重くなりやすいことがよく挙げられます。原因の中心は「再計算が増えやすい」ことです。INDIRECTは参照先が文字列で隠れてしまうため、シート側が依存関係を最適化しにくく、結果として再計算の負荷が高くなりがちです。
体感としては次のような症状が出ます。
関係ないセルを編集しただけなのに、計算待ちが発生する
フィルタや並べ替え、シート切り替えの反応が遅くなる
ファイルを開くのに時間がかかるようになる
コピーや入力のたびに固まる感覚が増える
もちろん、INDIRECTを1～2箇所使った程度で直ちに深刻化するわけではありません。しかし、テンプレ運用で便利だからといって増殖させると、後から性能問題として表面化しやすいのが特徴です。
したがって、INDIRECTを使うときは次のような考え方が重要です。
“本当に動的参照が必要な核”だけに使う
参照を動的にしなくても済む構造（テーブル、統合データ）に寄せる
代替可能な部分はINDEXやXLOOKUPなどで置き換える
「便利だから使う」ではなく、「必要だから最小限使う」という姿勢が、長期運用の安定につながります。
大量データで事故る典型例
INDIRECTで問題が起きやすいのは、「式が多い」「参照が複雑」「データが大きい」の三拍子が揃ったときです。典型的な事故パターンを整理すると、対策の方向性が見えます。
参照文字列の連結が複雑化し、どこを参照しているか追えない
担当者しか分からない式になり、引き継ぎで破綻します。修正時に“直したつもりが別の参照が壊れる”ことも起きます。可変範囲をINDIRECTで作り、表全体で多用する
100行なら問題がなくても、1000行、10000行と増えたときに一気に重さが表面化しやすいです。別シート参照を全面的にINDIRECT化する
シートが増えるほど、参照先の管理が難しくなります。シート名変更が起きたときの影響範囲も大きくなります。エラーが連鎖する
シート名ミスや名前定義削除など、参照の前提が崩れると#REF!が広範囲に波及します。エラーが多いと、どこが起点か分からなくなります。
これらの事故は「INDIRECTを使ったこと自体」が原因というより、「INDIRECTでないと成り立たないほど複雑な設計にしてしまった」ことが原因になりやすいです。したがって、事故を避けるには、式の数を減らし、データ構造を整え、参照の前提（シート名や名前定義）をルール化することが効いてきます。
採用判断チェックリスト
INDIRECTを採用するかどうか迷ったときは、「便利さ」だけでなく、「運用と保守」を基準に判断するのが確実です。以下のチェックリストで、当てはまる項目が多いほど、INDIRECTは慎重に扱うべきです。
INDIRECTを使うセル数が、将来的に数十〜数百以上に増えそう
配布テンプレや引き継ぎ前提で、第三者が読む・直す可能性が高い
シート名や名前定義が、運用中に変更される可能性がある
すでにブックが重い、計算待ちがある、開くのが遅いなどの兆候がある
可変範囲の集計にINDIRECTを使おうとしている（増殖しやすい）
エラーが起きたときに、参照文字列を追跡できる仕組みがない
反対に、次のような条件ならINDIRECTは比較的安全に使いやすいです。
参照切り替えが業務要件の中核であり、他の方法だと設計がさらに複雑になる
使用箇所が限定的で、参照文字列も短く明確に保てる
シート名や名前定義の命名規則を固定し、変更しない運用ができる
参照文字列の可視化や、空白時のガード（IF）などを入れている
INDIRECTは「使ってはいけない関数」ではありません。正しくは「採用条件を満たすなら強力な武器、満たさないなら事故の種になりやすい関数」です。判断基準を持つだけで、トラブル率は大きく下がります。
INDIRECT関数の代替案と置き換えレシピ
INDEXやXLOOKUPで置き換える考え方
INDIRECTを使いたくなる理由の多くは「参照を動かしたい」からです。しかし実務では、参照そのものを動かすより、「固定した参照の中から必要な値を選び取る」設計に寄せたほうが安定します。その代表例がINDEXやXLOOKUPです。
たとえば、「行番号・列番号に応じて値を取りたい」なら、INDIRECTでセル番地を作るよりINDEXで直接取りに行くほうが安全です。INDEXは参照範囲を固定したまま、位置だけで値を返せます。参照が文字列に隠れないため、式の追跡も容易です。
また、「キーで値を取る」場面なら、XLOOKUP（環境によりVLOOKUPやINDEX/MATCH）を使うことで、参照先を動的にする必要がなくなります。データが統合されていれば、店舗列や月列を条件にして絞り込むだけで済み、INDIRECTでシートを切り替える必要が消えます。
置き換えの方向性は次のように整理できます。
位置で取る（行列が決まる）：INDEXで解決できることが多い
キーで取る（コードや名称で探す）：XLOOKUPやINDEX/MATCHが有効
条件集計したい：SUMIFS/COUNTIFSなどに寄せる
シート切り替えが本質：INDIRECTの出番。ただし最小化する
「INDIRECTをどう書くか」だけでなく、「INDIRECTを使わずに済む設計にできないか」を考えるだけで、保守性は段違いに上がります。
Excelテーブルの構造化参照でテンプレ化する
可変範囲の悩みが出るなら、Excelのテーブル（構造化参照）は非常に強力な選択肢です。テーブルにすると、行が増えたときに参照範囲が自動で拡張されます。これにより、INDIRECTで範囲終端を動的に作る必要が減ります。
テーブル化のメリットは次のとおりです。
参照が「列名」で書けるため読みやすい（例：
テーブル名[売上]）行数が増減しても参照が自動追従する
並べ替えやフィルタが強く、集計や可視化にも繋げやすい
参照の監査性が高い（どこを参照しているか明確）
テンプレ運用の観点でも、テーブルは相性が良いです。「毎月データが増える」「担当が変わっても壊れない」仕組みを作るなら、INDIRECTで式を複雑化させるより、テーブルで土台を整えるほうが成功率が高い傾向があります。
もし現状、INDIRECTで可変範囲を作っているなら、置き換えの第一候補としてテーブル化を検討すると良いでしょう。特に、集計・検索・グラフ化まで含めた運用を考えると、テーブル化のメリットは年々大きくなります。
どうしてもINDIRECTが必要なときの最小化
最後に、どうしてもINDIRECTを使わざるを得ない場面について整理します。たとえば、同一フォーマットの複数シートを参照し、参照先だけを切り替える要件が強い場合、INDIRECTは依然として有効です。その場合は「最小化」の設計が重要になります。
最小化のコツは次のとおりです。
INDIRECTは入口に寄せる
参照先を切り替える“核”にだけ使い、派生する計算は通常参照や別関数で行う。参照文字列をヘルパーセルに出す
参照文字列が何になっているか常に見える状態にし、トラブル時に追跡できるようにする。シート名・名前定義の命名規則を固定する
ルールが曖昧だと、参照の前提が崩れて事故が増える。空白時やエラー時のガードを用意する
IFで未選択時は空白にする、IFERRORでユーザーに分かりやすい表示にするなど。同じINDIRECTを何度も書かない
同じ参照文字列を使うなら、1箇所で作り、他はそれを参照するようにする（式の増殖を防ぐ）。
INDIRECTを“便利な魔法”として使うのではなく、“限定的な切り替え機構”として扱うことが、長期運用での安定に直結します。
INDIRECT関数のエラー対処とFAQ
#REF! が出る原因トップ5
INDIRECTを使って最も遭遇しやすいエラーが #REF! です。原因の大半は「参照文字列が参照として成立していない」ことにあります。頻出原因を上位から整理すると次のとおりです。
参照文字列が空になっている
シート名セルが未入力、プルダウンが未選択、参照先番地セルが空など。空文字列は参照にできません。参照文字列が存在しない参照になっている
例："A0"のように不正な番地、列記号のミス、行番号の計算ミスなど。シート名が一致していない
全角半角、末尾スペース、表記揺れ、改名後に未更新など。見た目が同じでも一致しないことがあります。シート名のクォート不足
空白や記号を含むシート名で'がないと参照が崩れます。最初からクォート込みを型にすると防げます。名前定義が存在しない／一致しない
連動プルダウンで多発します。名前定義が削除された、表記がズレた、範囲が壊れたなど。
対処の基本は、「参照文字列を可視化して、完成形を目で確認する」ことです。式の中で連結しているなら、まず参照文字列だけを別セルに出して、'東京'!B2 のような完成形になっているか確認してください。完成形が正しければ値は取れますし、崩れていればどこが崩れたかが分かります。
循環参照になったときの切り分け
INDIRECTは参照先が文字列のため、循環参照が起きた場合の切り分けが難しくなりやすい傾向があります。循環参照は「自分自身を参照している」「参照の輪ができている」状態です。INDIRECTが絡むと輪が見えにくくなり、原因特定が遅れがちです。
切り分けの現実的な手順は次の考え方です。
参照文字列を固定して検証する
参照文字列がセルに依存しているなら、一度固定文字列（例：”A1″）にして循環が解消するかを確認します。解消するなら、参照文字列の作り方（依存関係）が原因です。参照文字列の生成元を遡る
INDIRECT自体よりも、参照文字列を作っているセル（連結しているセル、シート名セル、行番号セル）がどこを参照しているかが起点になることが多いです。参照方向を一方通行に設計し直す
入力欄→計算欄→集計欄のように、参照が戻らない形にします。特に「集計結果を元に参照先を変える」ような設計は循環参照を招きやすいので要注意です。
循環参照はINDIRECTが原因というより、「参照が動的であるがゆえに輪ができた」ことが本質です。設計段階で参照の方向を固定するほど、循環参照のリスクは下がります。
よくある質問
Q1：INDIRECT関数は覚えるべきですか？
INDIRECTは、別シート参照の切り替えや連動プルダウンなど、用途が明確な場面では非常に有用です。ただし、何でもINDIRECTで解決しようとすると、重さや保守性の問題が出やすくなります。覚える価値はありますが、「使いどころ」と「代替案」もセットで理解しておくのが理想です。
Q2：別ブック参照にもINDIRECTは使えますか？
参照文字列に外部ブックの情報を含める形で表現上は可能な場合がありますが、運用上は壊れやすい傾向があります。ファイルの保存場所、ファイル名変更、開閉状態などの影響を受けやすく、引き継ぎや共有の場面でトラブルになりがちです。外部ブック参照が本格的に必要なら、データを統合する、取り込みで一本化するなど、別のアプローチを優先したほうが安定します。
Q3：INDIRECTで重くなったとき、最初にやるべきことは何ですか？
まずはINDIRECTが使われている箇所を棚卸しし、用途別に分類するのが第一歩です。特に、可変範囲集計に使っている箇所、検索範囲切り替えに使っている箇所は、置き換え可能性が高いことが多いです。テーブル化、INDEX/XLOOKUP、SUMIFSなどで置き換えられる部分から減らすと、体感の改善が出やすいです。
まとめ
INDIRECT関数は、文字列から参照を作れるという特性により、「参照先を切り替える」仕組みを簡潔に実装できる便利な関数です。別シート参照の切り替えや連動プルダウンなど、動的参照が本質となる場面では特に効果を発揮します。
一方で、参照が文字列に隠れるため、保守性が落ちやすく、エラーが追いづらくなり、規模が大きいと重さの問題も出やすくなります。したがって、使う際は次の方針が重要です。
参照文字列を正しく作り、見える形で確認できるようにする
シート名はクォート込みの型で統一し、表記揺れを防ぐ
可変範囲や大量利用は避け、テーブル化やINDEX/XLOOKUPなど代替案を優先する
どうしても必要な場面では、INDIRECTを核だけに絞って最小化する
テンプレや引き継ぎを前提にするほど、「動くかどうか」だけでなく「壊れにくいか」「直しやすいか」が重要になります。INDIRECTを適所で活かしつつ、代替できるところは置き換える設計にすると、長く安心して使えるシートに仕上がります。