「日本語で『先月の売上を地域別に集計して表にして』とお願いしたら、Gemini が本当に表を作ってくれたんです。これ、もう外注も社内のエクセル得意な人もいらなくなるんじゃないですか」——先日、ある顧問先の経営者からこう言われました。気持ちはよく分かります。これまでスプレッドシートの集計表は、VLOOKUP や QUERY、ときにはマクロを書ける一部の担当者にしか触れない「聖域」でした。それが、自然な日本語の指示で表もピボットもグラフも組み上がるようになった。確かに敷居は劇的に下がりました。ただ私は、その場で「作れること」と「業務で信頼して使えること」は別の話です、とお伝えしました。むしろ、これから新しい種類の属人化が始まる、というのが現場を預かる側の率直な実感です。
2026 年 6 月 18 日、Google スプレッドシートの Gemini が、日本語を含む 27 言語で「スプレッドシート全体の作成・編集」に対応しました（既存の英語と合わせて計 28 言語）。今年 4 月の時点で、表やピボットテーブルの作成、グラフ生成、数式の挿入といった構築・編集機能はすでに英語で使えていましたが、今回それらが日本語の自然文指示で動くようになった、というのがこのアップデートの中身です（詳細は gihyo.jp の記事 が分かりやすい）。つまり、これまで関数を書ける人だけのものだった「表を組む」という工程が、言葉で頼める作業に変わったわけです。だからこそ、受託の役割は「代わりに表を作ること」から、別のところへ移っていきます。本記事では、その変化と、Gemini が作った表を業務で安心して使うために何が要るのかを整理します。
何が変わったのか、そして何は変わらないのか
まず、今回できるようになったことを正確に押さえておきます。サイドパネルの Gemini に日本語で指示を出すと、Gemini はいきなり作り始めるのではなく、まず指示内容への改善提案を返してきます。「この集計なら、月別に分けたほうが見やすいですが、どうしますか」といった具合です。こちらが応答すると、次に作業計画を提示し、承認して初めて、その計画に沿ってシートを作成・編集する——という段取りになっています。いきなりシートを書き換えられるわけではなく、計画を挟む設計になっているのは良心的です。
利用にはいくつか前提があります。Workspace 側で「スマート機能（smart features）」を有効化しておく必要があり、これがオンになって初めてサイドパネルに Gemini のアイコンが現れます。また、2026 年 7 月 15 日まではお試し期間として通常より高い利用上限が設定されており、それ以降はユーザーごとの利用上限が適用されます。なお Gemini 自体は、2025 年 1 月以降 Google Workspace の各プランに標準で組み込まれており、かつてのようにアドオンを別途購入する必要はなくなっています。
では何が変わらないのか。スプレッドシートの「中身が正しいかどうか」を誰かが保証しなければならない、という事実は何も変わっていません。むしろここからが本題です。これまでは「関数を書ける人が作り、その人が中身を理解している」という形で、作る人と分かる人が一致していました。Gemini が表を作れるようになると、この一致が崩れます。表は出来上がっているのに、その数式が何を計算しているのか、どういう前提で集計しているのかを、誰も把握していない——という状態が、いとも簡単に生まれます。
「Gemini が作った表」が抱える、新しい属人化
長年、スプレッドシート業務の問題は「VLOOKUP や QUERY が分かる担当者しか触れない属人化した集計表」でした。その担当者が異動・退職した瞬間、誰も中身を直せなくなる。多くの中小企業が一度は経験した痛みです。
Gemini で表が作れるようになって、この属人化は解消したかに見えます。ところが実際には、属人化の形が変わっただけです。今度は「Gemini が出した表の中身を、誰も検証していない」という属人化が生まれる。作った人すら数式を読めていないのですから、ある意味で前より厄介です。前の属人化は「分かる人が一人いた」のに対し、新しい属人化は「分かる人が一人もいない」状態になりかねないからです。
具体的に、どこで事故が起きるのか。私が現場で警戒しているのは次のような場面です。
Gemini が出した数式が、一見すると正しく見えるのに境界条件で誤るケース。たとえば「税抜と税込が混在した列」をうまく扱えていなかったり、空セルや想定外の文字列が混ざった行で集計から漏れたりする。サンプルの十数行では正しく見えても、本番の数千行で初めて破綻が表に出ます。あるいは、承認フローを飛ばす、もしくはよく確認せずに承認して、本番の集計シートを Gemini に直接書き換えさせてしまい、元の数式が壊れるケース。さらに地味に効くのが、利用上限の超過です。月末の締め作業で頼り切っていた自動化が、お試し期間後の利用上限に当たって急に止まり、業務が回らなくなる。便利さに依存したぶん、止まったときの影響は大きくなります。
そして見落とされがちなのが、データの取り扱いです。スマート機能をオンにして社外秘の取引データや個人情報を含むシートを Gemini に扱わせてよいのか、何が参照・処理されるのかを、現場が判断しないまま使い始めてしまう。便利だから、で踏み込むと、後から取引先の監査で説明できずに困ることになります。
受託の役割は「作ること」から「検証と切り分け」へ
ここで、受託の出番が変わります。表そのものは現場が Gemini に作らせればいい。私たちが価値を出すのは、その手前と後ろ、つまり「作る」を挟む両側です。
一つは、Gemini が出した数式・集計の精度検証です。出力された表を鵜呑みにせず、境界条件（空セル、想定外の値、桁あふれ、税の扱い）で意図どおりに動くかを確認し、本番データ量でも破綻しないかを検証する。これは、関数を読めて、かつ「どこで壊れるか」を経験的に知っている人にしかできない仕事です。数式そのものの読み解きや、Gemini で足りない部分を GAS で補う判断については、Google スプレッドシート自動化の記事 で扱った関数・スクリプトの基礎が、そのまま検証眼の土台になります。
もう一つは、スマート機能のオン・オフとデータの取り扱いの線引きです。どのシート（どのデータ）なら Gemini に扱わせてよく、どれは扱わせてはいけないか。社外秘や個人情報を含むシートの方針を、現場が迷わないルールとして先に決めておく。Gemini を含む Workspace の AI をどう安全に使うかという全体像は、Workspace の Gemini 活用ガイド で整理した考え方とつながります。
さらに踏み込むと、属人化した既存シートの棚卸しと標準化も受託の領域です。「誰も中身を説明できない集計表」が社内に何枚もある状態で Gemini を入れても、検証の対象が増えるだけです。まず既存シートを棚卸しし、何のための表で、どの数式が何を計算しているかを整理してから、Gemini で再現・置き換えられるものとそうでないものを仕分ける。この地道な作業こそ、外から入る価値があります。
Gemini で十分な領域と、作り込むべき領域を見極める
受託でいちばん効くのは、実は「何を Gemini に任せ、何は別の手段で作るか」の切り分けかもしれません。Gemini が表を作れるからといって、すべての業務をスプレッドシート上で完結させるのが正解とは限らないからです。
ある製造系の中堅企業（社名は伏せます）から、こんな相談を受けました。「現場の担当者が Gemini で在庫の集計表をどんどん作るようになったが、表が増えすぎて、どれが正しい最新版か分からなくなった。同じ在庫数を示すはずの表が、シートによって数字が違う」という症状です。Gemini で表を作る敷居が下がったぶん、似て非なる集計表が乱立し、かえって混乱していたわけです。
私たちが行ったのは、Gemini を取り上げることではありませんでした。まず、乱立した在庫表を棚卸しして、何が正しいデータ源なのかを一本化しました。そのうえで、日々の在庫の入出庫記録のように「複数人が入力し、状態が更新されていく」台帳系の業務は、スプレッドシート＋Gemini ではなく AppSheet で業務アプリ化する記事 で扱ったようなアプリの形に寄せました。一方で、月次の売上を地域別・商品別に集計して経営会議の資料を作る、といった「一度きりの集計・可視化」は、まさに Gemini が得意な領域なので、現場が日本語で作れるよう手順を整えました。
この切り分けがなぜ効くか。Gemini は「都度の集計と可視化」には強いが、「複数人が継続的に入力し、データの正しさを保ち続ける業務」には向かないからです。後者を無理にスプレッドシート上で Gemini に作らせ続けると、まさに先の在庫表のように、表が増えるほど混乱が深まります。台帳系はアプリへ、集計・可視化は Gemini へ。この線引きを最初に引いておくと、Gemini の便利さを活かしつつ、データの正しさも守れます。なお、引き継いだ自動化が GAS で組まれている場合の保守については 引き継いだ Google Apps Script の保守の記事 も合わせて参考にしてください。
導入を考える前に、確かめておきたいこと
これから Gemini でスプレッドシート業務を効率化するなら、作り始める前に二つだけ確かめておくと、後で痛い目を見ずに済みます。
一つは、Gemini が作った表の中身を、誰が検証して保証するのかを決めておくこと。「作れる」だけで運用に乗せると、誰も中身を読めない集計表が増え、結局は新しい属人化に逆戻りします。境界条件と本番データ量での検証を、運用フローの一部として組み込んでおくことが肝心です。もう一つは、スマート機能をオンにして扱ってよいデータの範囲を、現場が迷わない形で先に線引きしておくこと。社外秘や個人情報を含むシートの方針は、便利さに流される前に決めておくべきです。
Gemini で表は作れるようになったが中身を検証できる人が社内にいない、Gemini で作った集計表が乱立して最新版が分からなくなった、台帳系の業務とその場の集計をどう切り分ければよいか相談したい——そうしたお悩みがあれば、グリームハブのお問い合わせからお声がけください。いまお使いのスプレッドシートと業務の流れを拝見し、Gemini に任せてよい部分・人が検証すべき部分・別の手段に寄せたほうがよい部分を一緒に仕分けたうえで、現場が安心して使い続けられる形へご一緒に整えます。
