「金曜の夜、来週月曜に出すはずの請求集計シートを開いたら、見慣れた合計欄が一面 #REF! に変わっていたんです。何も触っていないはずなのに、なぜ壊れたのか分からなくて、結局その晩は手作業で電卓を叩きました」——先日、ある会社の経理担当の方からこんな相談を受けました。よくよく聞くと、別の人が前日に不要になった列を一本削除しただけ。その列を参照していた数式が軒並み行き先を失い、連鎖して合計も小計も全部おかしくなっていた、という話でした。スプレッドシートを基幹業務に据えている会社では、この「誰かのちょっとした操作で、土台のシートが静かに壊れる」事故が、想像以上に頻繁に起きています。
そんな現場に効きそうな機能が、ちょうど 2026 年 6 月 22 日から Google Workspace で段階的に展開され始めました。スプレッドシート上の Gemini が、数式エラーをワンクリックで診断し、修正版の数式まで提示してくれる、というものです。エラーが出たセルから周辺のデータ構造を読み取り、何が原因でエラーになっているのかを平易な言葉で説明したうえで、直し方を出してくれる。#REF! の意味も #VALUE! の原因も分からないまま固まっていた人にとっては、たしかに福音です。ただ、受託でスプレッドシートの立て直しを何度も引き受けてきた立場から言うと、この機能は「使いどころを間違えなければ」非常に有用で、間違えると「壊れたまま走り続ける会社」を増やしかねない、という両面を持っています。
何ができるようになったのか
まず、機能の中身を正確に押さえます。これまで、スプレッドシートで #REF! や #VALUE! が出たとき、原因にたどり着くのは経験のある人にしかできない作業でした。エラーの種類はヒントにはなりますが、「具体的にどの参照が、なぜ壊れたのか」は、数式を一つずつ追って初めて分かる。関数を読めない人にとっては、ただ赤い文字が並んでいるだけの、お手上げの状態でした。
今回の Gemini の機能は、ここに踏み込みます。エラーの出ているセルに対して、Gemini が周辺のデータ構造——参照先の範囲、隣接する列の中身、データの型——を解析し、エラーの核心を日本語で説明します。「この数式は B 列を参照していますが、B 列が削除されたため参照先が失われています」「この計算はテキストが混じった列を数値として扱おうとしてエラーになっています」といった具合に、原因を言葉にしてくれる。そのうえで、修正版の数式を提示します。利用するかどうかはこちらが判断できるので、いきなりシートが書き換わるわけではありません。
この機能は段階的なロールアウトで、組織やドメインによっては表示まで最大 15 日ほどかかります。今日試して出てこなくても、もう少し待てば現れる可能性が高い。利用できるのは Gemini が組み込まれた Business / Enterprise 系のプランなどで、Gemini をどのプランで入れるかという話は Gemini をどのプランで入れるべきかの記事 で整理しているので、自社が対象かどうか分からない場合はそちらも参考にしてください。
注目すべきは、Gemini が「直し方」だけでなく「なぜ壊れたか」を説明する点です。これまでブラックボックスだったエラーの原因が言語化されること自体は、業務の透明性を上げる方向に働きます。問題は、その説明をちゃんと読むか、それとも提示された修正をワンクリックで適用して終わりにするか、という人間側の使い方にあります。
エラーの種類ごとに、何が起きているのか
Gemini に頼る前でも頼った後でも、自分のシートで何が起きているのかを大づかみに知っておくと、修正案を鵜呑みにせずに済みます。よく出る代表的なエラーを並べておきます。
| エラー表示 | 主な原因 | Gemini の応急処置だけで済むか |
|---|---|---|
#REF! | 参照していたセル・行・列が削除された | 多くは済むが、再発防止には構造の見直しが要る |
#VALUE! | 数値の計算に文字列や空白が混じった | 入力データそのものの汚れが原因なら、根が深い |
#DIV/0! | ゼロや空セルで割り算した | 締め前にデータが揃っていない設計上の問題のことも |
#NAME? | 関数名・名前付き範囲のスペルミスや未定義 | 単純なら済むが、壊れた名前付き範囲は注意 |
#N/A | VLOOKUP などで照合先が見つからない | マスタの不整合が背景なら、修正は対症療法 |
| 循環参照 | 数式が自分自身を参照する輪を作っている | 設計の問題なので、応急処置では再発する |
表を見て気づいてほしいのは、右の列がどれも歯切れの悪い書き方になっていることです。#REF! も #NAME? も、表面のエラーを消すだけなら Gemini で一瞬です。けれど、その下にある「なぜそうなったのか」——列が気軽に消せてしまう構造、文字列が混入する入力フロー、締め前にデータが揃わない運用——は、修正版の数式を当てても何も変わっていません。#VALUE! や #N/A のように、入力データやマスタの汚れが根っこにあるものは、特に要注意です。数式を直しても、汚れたデータが流れ込み続ける限り、別の場所でまた同じエラーが顔を出します。
数式そのものの読み解きや、VLOOKUP・QUERY・ARRAYFORMULA といった基礎の理解は、Gemini の説明を「正しく評価する」ための土台になります。このあたりは Google スプレッドシート自動化の記事 で関数と GAS の入門をまとめているので、社内で検証する人を育てたいなら一度目を通しておくと、Gemini の修正案を判断する目が養えます。
応急処置の便利さが、根本原因を覆い隠す
ここが本記事でいちばん伝えたいところです。Gemini の数式修正は、止血としては優秀です。金曜の夜に #REF! で固まったあの経理担当の方が、もしこの機能を使えていたら、その晩のうちにエラーは消えて、月曜の提出には間に合ったでしょう。それ自体は良いことです。
問題は、その「すぐ消える」便利さが、本来なら立ち止まって考えるべきサインを覆い隠してしまうことです。列を一本消しただけでシート全体が崩れるのは、そのシートが「特定の列が特定の位置にあること」に強く依存して組まれている、ということです。#VALUE! が頻発するのは、人が手で入力する欄にバリデーション（入力制限）がなく、数値であるべきところに全角文字や注釈が混ざり込んでいるからです。これらは数式のミスというより、シートの設計と運用が限界に近づいているサインです。エラーが出るたびに Gemini で消していると、サインを消費しているだけで、土台が傷んでいることに誰も気づけなくなります。
実際にあった話をします。ある従業員 30 名ほどのサービス業の会社（社名は伏せます）から、「受注から請求まで全部を 1 枚の大きなスプレッドシートで回しているのだが、最近やたらとエラーが出る。誰かが直すと別の場所が壊れる、を繰り返している」という相談を受けました。開いてみると、1 シートに数十列、数千行。マスタ的なデータと日々の入力と集計結果が全部同じシートに同居し、シート内のあちこちから縦横無尽に参照が飛び交っていました。一つのセルを直せば、それを参照する別の数式が壊れる。まさにモグラ叩きの状態です。担当者の方は「Gemini が出るようになったら、エラーが出てもすぐ直せて助かっている」とおっしゃっていましたが、私から見ると、それは出血を止め続けているだけで、出血そのものが増えていく構造には手が付いていませんでした。
このとき Gemini が悪いわけではありません。むしろ、この会社が「もうスプレッドシート 1 枚で回す段階を超えている」というサインを、誰よりも頻繁に出していたのが、その繰り返されるエラーでした。Gemini の即時修正がなかった時代なら、エラーで業務が止まるたびに「さすがにこれは作り直しだ」と気づけたかもしれません。便利になったぶん、限界のサインが見えにくくなる——これが、新しい落とし穴です。
「直す」から「作り直す」へ切り替えるサイン
では、どこで「Gemini で直す」をやめて「仕組みそのものを見直す」に切り替えるべきか。判断の手がかりをいくつか挙げます。
一つ目は、同じシートで月に何度もエラーが出ること。たまの #REF! なら応急処置で十分ですが、月に何度も別の場所が壊れるなら、それはシートが複雑すぎて壊れやすくなっている証拠です。二つ目は、作った本人しか全体を説明できないこと。エラーが出たとき、Gemini に頼る前に「この数式は何のためにあるのか」を社内の誰も答えられないなら、すでに属人化が進んでいます。Gemini で表面を直しても、中身を理解している人がいない状態は変わりません。三つ目は、人が手で入力する欄が多く、そこからエラーが生まれていること。#VALUE! や #N/A が手入力起因で頻発するなら、入力をフォームやアプリの形に変えて、そもそも汚れたデータが入らないようにするほうが筋が良い。四つ目は、1 枚のシートに入力・マスタ・集計が同居していること。先のサービス業の例がまさにこれで、役割の違うデータを 1 枚に詰め込むほど、参照は絡まり、エラーは連鎖します。
これらのサインが二つ三つ重なってきたら、Gemini での修正は「次の一手を打つまでの時間稼ぎ」と割り切るのが健全です。次の一手とは、たとえば、複数人が継続的に入力する台帳系の業務を GAS や AppSheet でアプリの形に切り出し、入力時点でデータの正しさを担保する、といった脱属人化・業務システム化の方向です。引き継いだ自動化が GAS で組まれていて誰も触れない、という別種の属人化に踏み込んだときの立て直しは 引き継いだ Google Apps Script の保守の記事 で扱っていますが、スプレッドシートのエラー多発も、根っこにあるのは同じ「便利だから作り続けて、誰も全体を把握していない」という構図です。
ここで強調しておきたいのは、Gemini そのものは敵ではない、ということです。Gemini が日本語でシートを丸ごと作れるようになった話は Gemini が日本語でスプレッドシートを作る記事 で書きましたが、「作れる」も「直せる」も、使う人が業務の構造を分かっていてこそ活きます。逆に、構造を理解しないまま「作れるから作る、壊れたら直す」を繰り返すと、巨大化・属人化したシートが手に負えなくなる速度が、むしろ上がってしまう。便利な道具ほど、立ち止まる判断をこちらが意識して持たないといけません。
まず何から手をつけるか
Gemini の数式修正機能は、ロールアウトされたらぜひ使ってください。エラーで業務が止まる時間が減るのは、それだけで価値があります。ただ、使い始めると同時に、自社のスプレッドシートで「同じシートが繰り返しエラーを出していないか」を意識して見る習慣をつけてほしいのです。Gemini で直した回数こそが、そのシートの傷み具合を測る、いちばん正直なメーターになります。
具体的な次の一歩としては、まず、業務の中心になっている大きなスプレッドシートを 1 枚だけ選び、「ここ半年でエラーが出て直した記憶があるか」「中身を全部説明できる人が社内にいるか」を棚卸ししてみてください。この二つに引っかかるシートがあれば、それは Gemini で直し続ける対象ではなく、作り直しや業務システム化を検討すべき候補です。Gemini で消えるエラーの裏で、土台が静かに傷んでいないか——そこに目が向くようになれば、この新機能は「便利な応急処置」から「自社の業務の限界を教えてくれるセンサー」へと、意味が変わります。
