お問い合わせフォームやアンケートの内容を、GAS(Google Apps Script)でGoogleスプレッドシートに1行ずつ自動で保存していく。生成AIに相談しながらなら、こうした業務自動化の仕組みも、以前よりずっと手軽に作れるようになりました。送信ボタンを押すと、シートに記録がきちんと増えていく。動いた瞬間は、なかなか気持ちのいいものです。
ただ、そこで「動いたから完成」にしていないでしょうか。脆弱な作りのまま公開すると、フォームに打ち込まれた内容が、ただの文字ではなく数式として処理されてしまうことがあります。この記事では、その数式インジェクションと呼ばれる落とし穴について、なぜ起きるのか、どんなリスクがあるのか、どう防ぐのかを、画面を見ていない前提でやさしく整理します。
結論：入力が「文字」でなく「数式」として実行されてしまう
先に答えを言います。脆弱な実装だと、フォームから受け取った入力が、シート上で「ただの文字(テキスト)」ではなく「計算する数式」として処理されてしまうことがあります。これが数式インジェクションと呼ばれる問題です。
インジェクションとは「注入」という意味で、本来はデータであるはずの場所に、命令や式を紛れ込ませてしまうことを指します。名前や住所を書くつもりの欄が、いつのまにか計算式の入力欄として振る舞ってしまう。そう考えると、少しイメージがつかめるかもしれません。
具体例で見る：名前欄に入れた文字が、計算結果に化ける
言葉だけだと分かりにくいので、簡単な例で見てみます。フォームの名前欄に、名前ではなく =1+1 という文字列を送ったとします。
本来なら、シートの名前の列には =1+1 という文字がそのまま記録されるはずです。ところが脆弱な作りだと、そこには 2 と表示されます。=1+1 という入力が計算されて、その答えだけがセルに残ってしまうのです。つまり、文字として保存したかった内容が、数式として実行された結果に化けています。
なぜ起きるのか：フォーム入力が「手入力」と区別されないから
= で始まれば数式、というのは表計算ではおなじみの挙動です。問題はそこではなく、フォームから受け取った値を、何のチェックもせずそのままセルに書き込んでいる点にあります。
シートから見れば、フォーム経由で届いた =1+1 も、人が手で = を打ち込んだのも区別がつきません。だから律儀に計算してしまう。GAS側が「これは文字として扱う」と指示していない限り、シートの親切な機能が、外部から来た入力に対しては裏目に出る、というわけです。
先頭が = のほかにも、+ や - や @ で始まる値が数式として扱われることがあります。ここが、この問題を考えるうえでの起点になります。
どんなリスクがあるのか：表示のすり替えから情報漏洩まで
「計算されるくらい、別にいいのでは」と感じるかもしれません。ですが、放っておくといくつかの困りごとにつながる可能性があります。
- 表示が別の値にすり替わる：本来記録したかった内容が、まったく違う数字や記号に置き換わってしまいます。名前や問い合わせ内容が正しく残らず、後から見返しても何が送られてきたのか分からなくなることがあります。
- 集計やその後の処理が壊れる：スプレッドシートの記録を、別の集計シートやGASの後続処理で使っている場合、想定外の値が混ざることで計算結果がおかしくなったり、自動処理が途中で止まったりすることがあります。
- 情報漏洩につながる可能性：さらに踏み込むと、シートに仕込まれた数式や、その値を使ったAI・自動処理の動きによって、本来外に出すつもりのなかったデータが意図せず外部へ送られてしまう、という事態も考えられます。
自動化はデータを増やす方向に働きます。だからこそ、入り口で受け取る値をどう扱うかが、あとから効いてきます。
どう防ぐのか：受け取った値を「文字列として扱う」
対策の考え方は一貫しています。外部から受け取った値は、そのまま保存せず、数式として解釈させない、つまり「ただの文字列として扱う」ことです。これは、SQLインジェクションとは何かで紹介した「入力を命令でなく、ただの値として扱う」という発想とまったく同じ族の対策です。
具体的な守り方としては、保存する前のひと手間がポイントになります。
- 保存前に値を点検する(サニタイズ)。フォームから届いた値を、そのままシートに書き込む前に一度チェックします。サニタイズとは、受け取ったデータから危ないふるまいを取り除いて、無害な状態に整えることです。
- 先頭が = + - @ などの値を無害化する。数式として解釈されうる記号で始まる値を見つけたら、数式として動かないように整えてから保存します。こうしておけば、=1+1 は 2 に化けず、=1+1 という文字のまま記録されます。
- 文字列として書き込むことを明示する。GAS側で、その値は数式ではなく文字だとシートに伝える書き方をしておくと、シートが勝手に計算してしまうのを防ぎやすくなります。
同じ落とし穴は、スプレッドシートに限りません。集めたデータをCSVという形式で書き出し、それを表計算ソフトで開いたときに数式が実行されてしまう「CSVインジェクション」も、まったく同じ仕組みで起きます。データを外に出す・別のソフトで開く場面でも、この視点は持っておきたいところです。
AIに任せるほど、動くかどうかで満足しがち
こうした仕組みを生成AIに作ってもらうと、たいていはあっさり動くものが出てきます。フォームを送れば、ちゃんとシートに記録が増える。その手軽さは、AI開発の大きな魅力です。
ただ、AIが書いてくれるのは多くの場合「動く」コードであって、「安全に動く」ことまで保証してくれるわけではありません。受け取った値を文字列として扱っているか、危ない記号を無害化しているか。そうした確認は、いまのところ作る人自身の目で見る必要があります。動けばOKで止めず、自分の自動化を自分で守る、という一歩を足すだけで、公開後の安心感は変わってきます。この考え方の全体像は、個人開発を「動けばいい」で終わらせないためににまとめています。
次の一歩
- そもそもこの仕組みをどう作るのか知りたい人へ:お問い合わせフォームを自作する仕組み(生成AI×GAS)
- 落とし穴の全体像をつかみたい人へ:個人開発を「動けばいい」で終わらせないために
- 同じ「入力を命令として実行される」族を知りたい人へ:SQLインジェクションとは何か
まとめ
- 脆弱な実装だと、フォームの入力が文字ではなく数式として実行されることがある。これが数式インジェクション。
- 起きる理由は、先頭が = などで始まる値を、スプレッドシートが数式とみなして計算するから。
- リスクは、表示のすり替え・集計や自動処理の破壊、さらに情報漏洩につながる可能性まで及ぶ。外に出た情報は取り戻せない。
- 防ぎ方は、受け取った値をそのまま保存せず、数式として解釈させない=文字列として扱うこと。保存前のサニタイズが基本で、CSVで開く場合の同種の問題にも同じ視点が効く。
セキュリティの穴は、名前を知っていても「自分の作った自動化のどこに当てはまるか」まで結びつかないと、なかなか防ぎきれません。独学でつまずきやすいのは、知識そのものよりも「何を、どの順番で学ぶか」です。安全に動く仕組みの作り方も、あなたの目標から逆算した学ぶ順番の一部として、1対1で一緒に整理できます。
