gas でできること｜スプレッドシート業務をどこまで任せられるか

「うちもGASで自動化できると言われたんですが、結局、何ができるんですか」

業務の相談を受けているときに、よく出てくる質問です。取引先や知り合いの会社、あるいは社内の若い担当者から「それGASでできますよ」と言われた。言われたほうは、悪い話ではなさそうだと思いつつ、自分の会社の何がどう変わるのかが分からない。だから話が止まる—そういう場面を何度も見ています。

調べてみると、GAS（Google Apps Script）でできることを並べた記事はたくさん出てきます。メールを自動で送れる、フォームの回答を集計できる、ドライブのファイルを整理できる、外部のサービスとつなげられる。どれも間違っていません。ただ、業務を回している側から読むと、「で、自分の手元の作業のどれが減るのか」が分からないのです。機能の名前は、業務の名前ではないからです。

そこでこの記事では、できることの一覧を並べるのをやめます。代わりに、GASが向く業務の形を4つの型で整理します。あわせて、できるけれどやらないほうがいいこと、スプレッドシートとGASで足りる範囲と足りなくなる境目、書き始める前に決めておくことまでを扱います。プログラムの書き方ではなく、業務側で何を決めるかの話です。

GASが向くのは「同じ手順を人が繰り返している」ところだけ

最初に位置づけをはっきりさせておきます。GASは、スプレッドシート・Gmail・Googleフォーム・カレンダー・ドライブなど、Googleの中にあるものを、決めた手順どおりに触るための道具です。人が画面を開いてクリックしていた操作を、あらかじめ書いておいた手順として実行する。それだけのものだと考えると、判断を間違えにくくなります。

この位置づけから、向く業務の条件が出てきます。

• 手順が決まっている：誰がやっても同じ順番で同じ操作をしている。「人によってやり方が違う」なら、まだ決まっていません
• 入力の形が揃っている：どの列に何が入るかが固定されている。日付が「8/1」と「8月1日」と「令和8年8月1日」で混ざっていない
• 判断が要らない：条件に当てはまるかどうかを、その場の状況を見ずに機械的に決められる

逆に言えば、その場の判断が入る業務、入力の形が毎回違う業務は、GASを書いても止まります。厳密には「止まる」だけでなく、もっと悪い形になることもあります—止まらずに、間違った結果を出し続けるのです。例外の行を読み飛ばして集計が合わない、条件に当たらなかった行が通知されない。人がやっていれば「あれ、これ変だな」と気づいたところを、機械は素通りします。

なので、GASの検討は「何ができるか」から始めるより、いま人が繰り返している手順のうち、判断が入っていないものはどれかを洗い出すところから始めるほうが早いと考えています。手順を書き出してみると、自動化できる部分と、そもそも人が決めている部分が分かれて見えてきます。分かれていない状態で道具を選ぶと、どちらの側の問題なのかが最後まで分からなくなります。

業務側から見たGASの4つの型

実際の相談を振り返ると、GASに任せている内容はだいたい4つに分かれます。「集める」「知らせる」「形にする」「つなぐ」です。機能の名前ではなく、業務として何をしているかで分けています。自社の困りごとがどの型に近いかを見当づけるのに使ってください。

4つを並べて気づいてほしいのは、右の列がどれも「業務側で決めておくこと」だという点です。列の意味、異常の定義、正しい書式、受け渡しの口。これはプログラムの都合ではなく、業務の取り決めです。前提が揃っていないまま自動化すると、間違いが人の手より速く流れるようになります。手作業のうちは、月末に集計しながら誰かが違和感に気づいていた。自動化すると、その違和感を持つ人がいなくなります。

4つの型のうち、最初に手をつけるなら「集める」か「知らせる」が扱いやすいと考えています。「形にする」は書式の決着に社内調整が必要になりがちで、「つなぐ」は相手側の事情に左右されるためです。ただし、順番よりも大事なのは、選んだ型の前提が本当に揃っているかを先に確かめることです。

できるが、やらないほうがいいこと

技術的には書けるのに、業務としては任せないほうがいいものがあります。相談の中で「それはやめておきましょう」と伝えることが多いのは、次の4つです。

• 判断そのものを任せる：値引きを受けるかどうか、応募者を通すかどうか。GASは条件分岐を書けますが、条件を決めるのは人です。条件を決めずに書くと、書いた人がその場の感覚で決めた基準が、会社の基準として静かに固定されます
• 入力の形が毎回違うものを無理に読ませる：自由記述の備考欄から情報を抜き出す、メール本文から数字を拾う。動く例は作れますが、例外が出るたびに手当てが増え、いつまでも終わりません。読ませる工夫より、入力の形を直すほうが早く済みます
• 人が見て気づいていた異常を、通知だけに置き換える：通知は「来たこと」には気づけますが、「来なかったこと」には誰も気づきません。処理が止まっていても、静かなだけです。通知に寄せるなら、異常時の通知とは別に、動いたことを定期的に知らせる仕組みも合わせて考えます
• 会社の基幹の記録をスプレッドシートだけに置く：契約や取引の記録のように、あとから「いつ誰が何を変えたか」を説明する必要があるものです。スプレッドシートは編集履歴を持ちますが、業務の証跡として使う前提の作りではありません。権限の切り方にも限界があります

最後の項目に当たっている場合は、GASの範囲の話ではなくなります。どこまでを表計算で持ち、どこから仕組みとして作るかの判断は、表計算で回している業務をシステム化するかの判断で整理しているので、そちらを見てください。ここで無理にGASを積み上げると、あとで移すときの手戻りが大きくなります。

スプレッドシート＋GASで足りる範囲と、足りなくなる境目

ここがこの記事の核だと思っています。「それはシステム化しましょう」で終わらせるつもりはありません。逆に、「スプレッドシートで十分ですよ」と言って逃げるつもりもありません。線を引きます。

まず、スプレッドシートとGASで足りる範囲です。次の条件に収まっているなら、わざわざ別の仕組みを買う理由はほとんどありません。

• そのデータを触る人が数人にとどまっている
• 記録が壊れても、元の紙やメールから再入力できる
• 月次で締められれば足り、常に最新である必要がない
• 変更の履歴を厳密に追う必要がない

この範囲では、むしろスプレッドシートのほうが強いです。現場が自分で列を足せる、画面の作り込みが要らない、やめるのも簡単。業務がまだ固まっていない段階でシステムを作ると、固まる前の形が固定されてしまいます。

問題は、いつ足りなくなるかです。判定できる形にすると、境目は次の4つに絞れます。

1. 同時に触る人が増えて、「誰がいつ何を変えたか」を追う必要が出た：数字が変わっていることに気づいて、経緯を調べる会話が発生し始めたら、この境目に当たっています
2. 前の状態に戻せることが業務上の要件になった：承認のやり直し、監査への説明、取引先への訂正報告。「元はこうでした」を証明する必要が出た時点で、表計算の外の要件です
3. 見える範囲を人によって分ける必要が出た：スプレッドシートの権限はシートやファイルの単位が基本で、「同じ表の中で、自分の担当分の行だけ見せる」を安全にやるのは苦手です。分けるためにシートを増やし、増えたシートをGASでまとめ始めたら、設計として無理をしています
4. 実行時間や1日あたりの上限に当たり始めた：処理が途中で止まる、時刻を決めた実行が動かない日が出てくる。ここはGASの実行時間の制限と処理を分ける設計で扱っています

大事なのは、境目に当たったからといって全部を作り替える必要はないということです。現実的なのは、当たった1つの要件だけを外に出すという順序です。履歴が要るなら、履歴が要る部分だけを別の置き場に移す。権限を分ける必要があるなら、見せる画面だけを分ける。残りはスプレッドシートに置いたままにします。

一気に載せ替えたくなる気持ちは分かります。ただ、載せ替えは業務の停止を伴い、現場が新しい入力に慣れるまでの期間も要ります。4つの境目のうち1つに当たっているだけなのに全部を作り替えて、結果として前より不便になった—という話は珍しくありません。何をSaaSに寄せ、何を表計算に残すかの考え方は、SaaSとスプレッドシート＋自動化の選び方にまとめています。

書く前に決めておく3つ

ここまでで自社の業務がGASに向く形だと見当がついたら、書き始める前に3つだけ決めておくことをおすすめしています。順番に効きます。

1. その業務の入力は「誰が・いつ・どの形で」入れているか：ここを書き出すと、形が揃っていない箇所が先に見つかります。揃っていないなら、自動化の前にそこを直します。入力の形を直さずに読み取りを工夫するのは、ほぼ必ず遠回りになります
2. 例外はいくつあるか：「基本はこうだけど、この取引先だけは違う」「月末だけ手順が変わる」。数えてみて例外が3つ以上あるなら、自動化する前に例外そのものを減らす話をします。例外の数は、そのまま後々の手当ての量になります
3. 止まったとき誰が直すか：作った人が社内にいるか、いなくなる可能性があるか。設定値をシート側に出しておけば、書ける人でなくても変えられる範囲が広がります。この論点は作った人しか直せないツールのリスクで詳しく書いています。社内に書ける人がおらず外へ頼む場合も、この3つを先に決めておくと見積が読めるようになります（GAS開発を外注するときの見積の内訳）

3つとも、GASの話ではなく業務プロセスの話です。私たちが道具の選定より前にここへ時間をかけるのは、ここが決まっていないと、どの道具を選んでも同じところで止まるからです。逆に、ここが決まっていれば、GASで書くのか、既存のサービスで済ませるのか、そもそもやめるのかの判断もその場でつきます。

どの業務から見ればいいか分からない場合は、対象を絞る前に一度並べてみるのが早いです。並べ方は業務棚卸しの進め方で手順にしています。全部を洗い出す必要はなく、繰り返している作業とその頻度が分かれば、どこにGASが効くかは自然に見えてきます。

まとめ

GASは、決まった手順を、決まった形の入力に対して繰り返す道具です。業務側から見た向き先は「集める」「知らせる」「形にする」「つなぐ」の4つで、どれにも前提があります。列の意味が揃っているか、異常の定義があるか、書式が1つに決まっているか、相手側に受け渡しの口があるか。前提が揃っていなければ、自動化は間違いを速くするだけです。

できるけれど任せないほうがいいものもあります。判断そのもの、形の揃っていない入力、気づきを通知に置き換えること、基幹の記録を表計算だけに置くこと。そして、スプレッドシートとGASで足りるかどうかは、触る人の数・戻せることの要否・見える範囲の分け方・上限の4点で判定できます。当たったら、当たった1つだけを外に出します。

結局のところ、できることの一覧より、自社の業務がその形になっているかのほうが効きます。私たちがツールの導入より前に業務プロセスの構造化に時間をかけるのは、そこが整っていない状態で自動化を乗せると、整っていないことが見えなくなるからです。まずは、いま毎週繰り返している作業を1つ選んで、「誰が・いつ・どの形で入れているか」を書き出してみるところからで十分だと思います。