誰でもGASは書ける。でも“ちゃんと動く”は別の話｜AI時代に求められるテスト視点とは？

最近、Google Apps Script（GAS）を書ける人が一気に増えたと感じています。

とくに、CursorのようなAI支援エディタが登場してからというもの、「フォームからスプレッドシートに転記して、Slack通知まで出す」といった処理なら、ほとんど誰でもそれっぽいコードが一瞬で書けるようになりました。

実際、私も最初は驚きました。
「あ、思ったよりGASって簡単かも」と感じたのは事実です。

でも、それはあくまで“動くように見える”だけだったのです。

CursorでGASを書くことは簡単になった

Cursorでは、たとえばこんなふうに自然文で指示できます。

「Googleフォームの回答をSlackに通知して、内容をシートに保存して」

すると、スクリプトが一通り生成されて、しかもちゃんと動く。

Slackの通知も届くし、シートにも書き込まれる。
「これだけできれば、もうコード書ける人って言えるんじゃない？」
そう感じたことすらあります。

でも、実務で使っていると、そこには思わぬ落とし穴がたくさんあることに気づきます。

👀 実際にあった「想定外」な入力例

• フリガナを全角で入力してくれると思っていたら、半角カナで入力された
• 必須と思っていた項目が、NULL（空欄）で届いた
• 日付をyyyy/mm/ddで処理していたのに、和暦（R5/5/1）で入力された
• 数字だと思っていた値が、「1,000円」とカンマ＋単位付きで入力されていてエラーに
• チェックボックスがON前提で処理されていたが、未選択（false）だった
• セレクト項目に「未選択」「その他」が混じっていて処理が落ちた

Cursorは、こうした“人間らしい不規則性”を想定してはくれません。
書いてくれるのは「正常系」だけ。
でも、実際に壊れるのは「例外系」なのです。

動くコードと“ちゃんと動く”コードは違う

Cursorが書いてくれるコードは、たしかに「動く」ように見えます。
エラーも出ないし、指定した通りに通知や出力もされます。
でもそれは、“入力が想定通りだったときだけ”の話です。

📦 「正常系」は完璧、でも「例外系」は見ていない

たとえば、

• Slack通知は届いたけど、内容が空っぽ（入力がNULL）
• 日付フィールドに「2024年5月」が入っていて、文字列処理が失敗
• セルに書き出す処理が、値の型違いでクラッシュ
• そもそも、フォームに「未入力」が許されていた

コード上では何のエラーも出ずに処理が進んだように見えても、実際にはデータが壊れているとか、記録されていないというケースは少なくありません。

⚠️ 「動いたように見えて、壊れていた」

私が過去に遭遇したケースで、こんなことがありました。

フォームからの申込みをスプレッドシートに記録し、条件を満たした人にだけメールを送信するというGASでした。

一見、動作は正常。テストでも通知は送られ、処理も完了。

ところが数日後、ある顧客から「メールなんて届いていないよ」という連絡が入りました。

原因は、対象条件だった「申込理由」が未入力だったこと。
想定外の空欄データに対して処理が分岐せず、メール処理がスキップされていたのです。

Cursorが生成してくれたコードは、「申込理由がある前提」で書かれていた。
でも、それはあくまで人間の入力を信用した場合の話だったんですよね。

こうした事例から学んだのは、

という、ごく当たり前だけど見落としがちな事実でした。

テスト視点とは何か

「テスト視点」と聞くと、エンジニアがやる単体テストやユニットテストを思い浮かべるかもしれません。でもここで言うテスト視点はもっとシンプルです。

「これ、変な入力が来てもちゃんと動くかな？」という想像力のことです。

✅ 私がチェックするテスト観点リスト（一部）

🧠 「書く前に、壊れそうな未来を想像する」

コードを書くことよりも、壊れないように考えることの方がずっと大切です。

こうした問いを1つ1つコードに組み込んでいくことで、「なんか動いてるっぽい」から「安心して使える」ツールに変わっていきます。

Cursorはこういった“繊細な気配り”まではやってくれません。
だからこそ、人間の経験と想像力が必要なんですよね。

私の経験｜動いたけどバグだった話

あるとき、私はGoogleフォームの回答を受け取って、Slackに通知を送る処理をGASで書いていました。
処理は単純で、Cursorにお願いすれば一瞬でコードができあがります。

function notifySlack(e) {
  const name = e.namedValues["名前"][0];
  const reason = e.namedValues["理由"][0];
  const message = `新しい申込がありました：\n氏名：${name}\n理由：${reason}`;
  postToSlack(message);
}

Slackにちゃんと通知が飛ぶし、フォームの内容も反映されてるし、動いた。完璧。…のはずでした。

📩 数日後に届いたメッセージ

「Slackに通知されてないんですけど…」
「送信したはずなのに名前が空欄なんですけど…」
「なんか文字化けしてる気がします」

恐る恐るスプレッドシートを見ると：

• 名前の欄が空欄（未入力）
• 理由の欄に絵文字が混じっていて通知が崩れてる
• 文字列が全角スペースだけで見た目は“何かある”けど中身は空

どれも、Cursorが生成したコードでは何もエラーが出ない（※）。
でも実際には、通知が抜けていたり、壊れていたり、「使えない結果」になっていたのです。

※ここで「何のエラーも出なかった」というのは、処理が正しく行われたという意味ではありません。
JavaScript（とくにGAS）は、undefined や空欄などの入力でもエラーを出さずに処理を進めてしまうことが多く、“壊れていたけど気づかなかった”という状態が普通に起こり得ます。
エラー処理（try-catch）やログ出力（Logger.log()）を入れていないと、問題が表面化しないまま「なんか変だな」で済まされてしまうのが怖いところです。

🧠 修正してようやく気づいた

• if (!name || name.trim() === "") ← 空欄やスペース対策
• Utilities.formatString() ← フォーマット統一
• try { ... } catch (e) { Logger.log(e) } ← エラーをつぶさない
• Logger.log() ← デバッグログの出力

こういうコードを入れて初めて、「本当に安心して使える処理」になったと実感しました。

Cursorは書いてくれる。でも“気づいてくれる”わけじゃない

GASが書けるようになることと、業務に使えるコードが書けることは違う。
そしてその差を埋めるのが、テスト視点と、ちょっとした実務経験なんだと思います。

AIでコードを書く時代に、人間が担うべき役割

昔は「コードが書けるかどうか」が、スキルの境界線でした。
でも今は違います。
CursorのようなAIエディタを使えば、コードは誰でも“書ける”時代になりました。

💡 コードを書くのはAIでいい。でも…

AIは指示された通りにコードを生成します。
けれど、以下のようなことはAIにはできません。

• 現場の使い方を想像すること
• 過去の失敗から、事前に手を打つこと
• 処理が壊れたときに誰が困るかを想像すること

つまり、コードを書くのはAIでいい。
でも設計と検証は、やっぱり人間の仕事なんです。

🧩 人間の役割は「想定する力」

• こういう入力が来るかもしれない
• あの人は説明読まずに送ってくるだろうな
• 急に仕様が変わったとき、壊れにくくしておきたい

こうした“ちょっと先を読む視点”が、AIではカバーできない部分。

むしろ、AIに任せて「書くこと」から自由になった今こそ、人間の「考える力」こそが武器になると私は思っています。

まとめ：GASを書く人が増えた今、テスト視点が武器になる

Cursorのおかげで、誰でもGASが書けるようになりました。
これは本当にすごいことです。

でも、「動いたからOK」ではなく、
「どんなときでも壊れず、安心して使えるツール」を目指すなら、
そこにはやっぱりテスト視点とちょっとした経験の積み重ねが必要です。

もしあなたが、Cursorで書いたコードが「動いた！」と感じたなら、次は「もしこの処理が壊れたら、誰が困る？」と想像してみてください。
その一歩が、ちゃんと動く業務ツールづくりの第一歩になるはずです。