関数じゃダメなんですか？──スプレッドシートでGASを書く理由

これ、関数でできるんじゃないですか？

Googleスプレッドシートを使った社内業務の改善案を話していたとき、同僚からそう言われました。
その瞬間、私はちょっとだけ言葉に詰まりました。

確かに、QUERYやVLOOKUPを駆使すれば、ある程度のことはできます。
実際、私も以前はそうしていましたし、ちょっとした自動化なら、それで十分に回っていました。

でも──
行や列をうっかり追加した瞬間、数式が壊れ、どこが間違っているのか分からない。
スプレッドシートを開いた瞬間に、「あれ、この数式、誰が書いたの？」と首をかしげる。
複雑な業務処理を関数で無理やり組み立てるほど、全体はどんどん“見えなくなる”。

私はこう思うようになりました。
関数は、見えない魔法のようなもの。
でも、本当に「業務ツール」を作るなら──中身が見える方が安心じゃないですか？

この記事では、私自身が関数の限界を感じてApps Script（GAS）に移行したときの気づきと、実際の変化についてお話します。
スプレッドシートを“誰でも触れる業務ツール”に進化させたい方へ、少しでもヒントになれば嬉しいです。

「関数で全部できる」と思っていたころの話

私も最初は、Googleスプレッドシートだけでほとんどの業務が自動化できると思っていました。

VLOOKUPでマスタ情報を引っ張り、IFで条件分岐、QUERYやARRAYFORMULAを組み合わせて、かなり複雑な処理をセル関数だけで組み上げていました。

当時は「コードを書かずにここまでできるなんて、すごいじゃん」と思っていましたし、他の人にも「スプレッドシートで十分ですよ」と言っていました。

でも──
その“十分”は、ある日を境に一気に崩れます。

「セルを1行追加したら壊れたんですけど」

ある日、同僚からそんな相談を受けました。

シートの上部に説明文を入れるために1行追加しただけで、すべてのVLOOKUPがズレてしまい、表示されるデータがぐちゃぐちゃに。

それどころか、数式があちこちに貼り付けられていて、どこが正しくて、どこが壊れているのかすらわからない状態でした。

私はそのとき気づきました。

関数は“今の状態”に強く依存していて、ちょっとした構造変更にもろい。
そして、全体構造がまったく見えない。

誰が書いたかわからないスプレッドシート

さらに問題なのは、“可読性のなさ”です。

数式が=IF(AND(ISBLANK(A2), NOT(ISBLANK(B2))), "OK", IF(COUNTIF(D:D, A2) > 0, "NG", ""))みたいな状態で、何がどう判定されているのか、初見ではまったく理解できません。

セルのどこかに間違いがあっても、それを特定するのはまるで宝探し。
そのスプレッドシートを開いた人が「これ、どう動いてるの？」と聞いてきても、自分でも「うーん、たぶんこの辺の数式が…」と曖昧にしか答えられない。

私が「関数だけでは限界がある」と本気で思うようになったのは、こういう“壊れた後の混乱”と、
それを“誰も直せない状態”に何度も直面したからです。

次章では、そうした限界を超えるためにApps Scriptに切り替えたときの実体験と、そこで感じた変化についてお話しします。

GASに移行して感じた3つの変化

スプレッドシート関数だけでは対応しきれないと感じていた私は、思い切ってGoogle Apps Script（GAS）を使い始めました。

最初は「GASは書いたことない」という抵抗感もありましたが、実際に使い始めてみると、想像以上に“世界が見える”ようになったのです。

変化1：処理の流れが“見える化”された

関数では、どのセルがどこに依存しているのか把握するのが難しく、数式をたどるだけで一苦労でした。

でもGASなら、たとえば以下のように処理の流れをコードとして書き出せます。

function calculateProfit() {
  const sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName("シミュレーター");

  // 原価と売上を取得
  const cost = sheet.getRange("B2").getValue();
  const price = sheet.getRange("B3").getValue();

  // 利益を計算
  const profit = price - cost;

  // 利益をセルに出力
  sheet.getRange("B4").setValue(profit);
}

このように、どのセルを使って、どんな処理をして、どこに結果を出すのかが、コードとして“見える化”されます。
コメントをつけることで、何をしているのかが明確になり、あとから見返しても理解しやすくなるのです。

変化2：壊れにくくなった

GASでは、セルの場所や範囲を明示的に指定するため、関数のように「1行追加したら全部ズレる」といった事故が起きにくくなります。

また、動作は「ボタンを押したとき」や「フォームを送信したとき」など、明確なタイミングで動くように設計できるため、
関数のように常に再計算される不安定さがありません。

結果として、意図しない変更に強く、安定した運用がしやすくなりました。

変化3：“属人化”から脱出できた

GASを使えば、処理の全体像をコードとコメントで残せるので、他の人が見ても理解できる業務ツールになります。

関数ベースのスプレッドシートは、どうしても“誰がどうやって作ったのか分からない”状態になりがちですが、GASでは仕様とロジックをセットで残せるため、引き継ぎや再利用がしやすくなるのが大きな利点です。

特に、私はCursorを使ってコードとドキュメントを一緒に管理しているのですが、「このツールは何を目的に、どういう設計で作られたのか」まで一目で分かるので、社内共有や引き継ぎ時に本当に助かっています。

この3つの変化だけでも、「もう関数だけには戻れない」と思うには十分でした。

GASを使うことで「見える・壊れない・引き継げる」環境が整うと、もう関数だけで頑張っていた頃には戻れなくなります。

それでも関数を使う場面とは？

ここまでApps Script（GAS）の良さを語ってきましたが、もちろん関数が優れている場面もたくさんあります。

たとえば、、、

こうした小さく完結する処理やリアルタイムに変化してほしい場面では、関数の方が手軽で、わざわざスクリプトを書く必要はありません。

また、関数はセル上に“結果がそのまま表示される”という強みもあります。
ダッシュボード的に値を見せたいだけのときは、関数でサッと組む方が早いケースもあります。

大切なのは、「どこからがGASか？」の見極め

私の経験上、次のような“兆候”が出てきたら、関数ではなくGASで管理すべきタイミングです。

関数とGASは“対立”じゃなく“共存”させるもの

大事なのは、「関数 vs GAS」ではなく、
「関数の得意領域」と「GASの得意領域」を見極めて、共存させていくことです。

たとえば、GASで集計処理を実行して、その結果をシートに書き出し、
表示用には関数で整える──そんな役割分担ができると、業務ツールとしての完成度がグッと上がります。

まとめ：関数の限界に気づいたら、それは進化のサイン

「これ、関数でできるんじゃないですか？」

そう聞かれたとき、私は少し戸惑いながらも、改めて関数とGASの違いを強く意識することになりました。

もともと私がGASに初めて触れたのは、Googleフォームの自動通知をSlackに送るためでした。
通知メールを見逃すことが多く、どうにかSlackでリアルタイムに確認できないか…と試行錯誤したのが始まりです。
そのときの記事はこちらです👇
👉 Googleフォーム送信時にSlack通知を送る方法｜スプレッドシートから自動で連携する

最初は「仕方なく」着手したのですが、意外とすんなり動いたことでGASへのハードルが下がりました。
そこからは、複雑な処理や壊れやすい数式は、どんどんGASに置き換えていくようになったんです。

だからこそ今回、「これ、関数でできるんじゃないですか？」と言われたときに、「でも、GASでやる意味がある」と改めて実感したんですよね。

関数はすばらしいツールです。
でも、スプレッドシートを“業務ツール”として育てていくには、構造が見える・壊れにくい・引き継げることが必要です。

それが実現できるのが、Apps Script（GAS）だと、私は実感しています。

もし今、あなたのシートが「壊れやすい」「読めない」「属人化してる」と感じるなら、それはGASにステップアップするタイミングかもしれません。

まずは一つ、関数からGASに置き換えてみてください。
その一歩が、スプレッドシートとの付き合い方を変えてくれるはずです。
この記事が、あなたにとってもその一歩になれば嬉しいです。