生成AIとGAS(Google Apps Script)の力を借りて、問い合わせフォーム付きのサイトを自分で作れた。公開ボタンを押したときは、なかなかの達成感があります。ところが数日すると、身に覚えのない送信が届き始めたり、集まったデータの扱いに不安が出てきたり、そもそも通知が来ないと気づいたり。作れたことと、安心して運用できることの間には、意外と溝があります。

この記事は、フォームの作り方そのものではなく、公開したあとに確認しておきたい運用項目に絞って掘り下げます。作り方の全体像からおさらいしたい方は、お問い合わせフォームを自作する仕組みを先に読むと流れがつかめます。

ムチオ
ムチオ
公開したら、変な送信がいっぱい来るようになってさ。これ何なの？
ルミナ
ルミナ
意味の分からない文字列や、同じ内容がくり返し届くなら、人ではなく自動プログラムからの送信かもしれません。公開フォームでは珍しくない現象です。作った直後にやっておくと楽なことがいくつかあるので、順番に見ていきましょう。

公開直後に届く「人でない送信」

公開したフォームに、意味の分からない文字列や広告めいた内容が届き始めることがあります。同じような送信がくり返し来る場合、誰かが手で送っているのではなく、インターネット上を巡回して自動でフォームに送信するプログラムによるものが考えられます。

こうした自動送信は、公開されているフォームを見つけると、内容を問わず送りつけてきます。放っておくと、本当に対応すべき問い合わせが、大量の無意味な送信に埋もれてしまいます。これは自分のフォームの欠陥ということではなく、公開フォームでは珍しくない現象です。だからこそ、対策も公開後の運用の一部として組み込んでおきます。

まずはテスト送信と、bot対策(受信側の検証まで)

最初にやっておきたいのは、自分で一度テスト送信して、通知や保存がきちんと動くかを確かめることです。ここがずれていると、後述のトラブルの切り分けも難しくなります。

そのうえで、自動送信を減らす対策を入れます。よく知られるのが、送信の手前に人間かどうかを確かめる仕組みを足す方法です。ただし、ここには一つ大事な注意点があります。

ムチオ
ムチオ
「私はロボットではありません」みたいなチェックを置けばいいんでしょ？
ルミナ
ルミナ
画面にチェックを置くだけだと、実は不十分なんです。reCAPTCHAやCloudflare Turnstileなどは、送信されてきた確認結果が正しいかを、GASなどの受信側でも検証する必要があります。画面の表示を通り越して直接送られてくるリクエストは、受信側でチェックしないと止められないんですよ。

初心者向けに整理すると、スパム対策は次のような組み合わせで考えると、古くなりにくく正確です。

  • ハニーポット：人には見えない入力欄を用意し、そこに値が入っていたら自動送信とみなす。
  • bot判定：reCAPTCHAやCloudflare Turnstileなどで、人間らしい操作かを判定する。
  • 受信側での検証：判定の結果が本物かを、GASなどフォームを受け取る側でも確かめる。

なお、フォームの受付にNetlify Formsを使っている場合は、Netlify側にもハニーポットやreCAPTCHAを使った追加のスパム対策があります。どの仕組みを使うにせよ、「画面に置いただけ」で終わらせず、受け取る側でも確かめる、という形にしておくのが要点です。

集めた個人情報は、目的・範囲・保存期間まで決める

送信の量を整えたら、次は中身、つまり集まったデータの扱いです。問い合わせフォームには、名前や連絡先といった個人情報が入ってきます。問い合わせで個人情報を取得する事業者には、利用目的を示し、必要な範囲で収集し、適切に管理する責任があります。

公開前に、少なくとも次の点を決めておきます。

  • 何のために取得するのかを表示する(利用目的の明示)。
  • 必要以上の項目を集めない。
  • いつまで保存するかを決める。
  • 不要になったデータを削除する。
  • プライバシーポリシーへの導線を置く。

あわせて確認したいのが、集めた個人情報がどこに保存され、誰が見られる状態になっているかです。多くの場合、送信内容はGASを通じてスプレッドシートに記録されます。そのシートの共有設定がゆるいと、集めた個人情報が意図せず見えてしまう恐れがあります。会社の問い合わせや顧客データを複数人で扱うなら、なおさら保管先の権限を絞る設計が要ります。この保管・共有まわりの落とし穴は貯まっていくデータは誰が見られるかでくわしく掘り下げています。

受付・保存・通知、どこで止まったかを切り分ける

「送信されたはずなのに通知が来ない」も、公開後によくあるつまずきです。あわてる前に、フォームの流れを受付・保存・通知の3段階に分けて、どこで止まったかを切り分けると、原因にたどり着きやすくなります。

  • 記録先のスプレッドシート：通知は来なくても、データはシートに残っていることがあります。まずここを開いて、送信自体が届いているかを確かめます。シートに記録があれば、フォームの受付と保存までは動いています。次に、通知処理の設定・実行エラー・送信上限を確認します。
  • GAS側の実行の記録：Apps Scriptエディタの「実行数」、またはApps Scriptダッシュボードの「マイ実行」で、処理が動いたか、途中で失敗したかを確認できます。通知の処理がそもそも動いたのか、動いてエラーになったのかが分かります。
  • 通知先の設定と迷惑メール：通知先のアドレスやチャットの設定が正しいか、メール通知なら迷惑メールフォルダに紛れていないかを確認します。届いていないのではなく、見えていないだけのこともあります。

受付・保存・通知、それぞれの上限を確認する

NetlifyやGASは無料で始められますが、無料で使える範囲には上限があります。問い合わせが増えると、知らないうちに上限へ近づいていることがあります。厄介なのは、上限に達したとき、どのサービスの、どの部分が止まるのかが分かりにくい点です。担当ごとに見る場所を分けておきます。

  • Netlify Formsの送信数：フォームの受付にNetlify Formsを使っているなら、Netlifyの管理画面で送信数や容量を確認します。
  • GASの実行失敗：GASにはサービスごとの日次の割り当てがあり、超えると処理が止まります。実行状況や失敗はApps Scriptのダッシュボードで確認できます。
  • GASからのメール送信数：メール通知を使っているなら、残りの送信可能数にも上限があります。ここを超えると通知だけが止まることがあります。

確認するときは、規約全体を読むより、各サービスの料金・使用量・割り当てのページを見るのが実際的です。月に一度のぞく習慣をつけておくと、いざというとき慌てずに済みます。

保存した値が「化ける」のを防ぐ

もうひとつ、保存まわりの落とし穴があります。フォームの入力値をそのままスプレッドシートへ書き込むと、先頭が「=」で始まる値などが、文字ではなく数式として扱われることがあります。保存時には、入力値を文字列として扱う対策も必要です。詳しくは数式インジェクションで解説しています。

ムチオ
ムチオ
作って終わりだと思ってたけど、公開したあとに気にすることって結構あるんだね。
ルミナ
ルミナ
一つひとつは難しくありません。順に潰していけば大丈夫です。公開前に軽く点検しておくだけで、あとの困りごとがぐっと減りますよ。

今日やれる、公開前後の点検リスト

公開する前、あるいは公開した直後にでも確認しておきたい6項目です。

  1. 公開前に自分でテスト送信し、通知が届くか確かめたか。
  2. bot対策(ハニーポットやreCAPTCHA/Turnstile)を入れ、受信側でも検証しているか。
  3. 取得目的・保存先・閲覧できる人・保存期間を決めたか。
  4. 受付・保存・通知のどこで止まったか、切り分けられるようにしているか。
  5. 利用しているサービスごとの上限(送信数・実行・メール枠)を確認できるか。
  6. 保存する値が化けないよう、文字列として扱う対策をしているか。

まとめ

  • 公開直後に届くくり返しの送信は、多くが自動プログラムによるもの。公開フォームでは珍しくない。
  • スパム対策は、画面のチェックだけでなく、ハニーポット・bot判定・受信側での検証を組み合わせる。
  • 個人情報は、利用目的の明示・必要な範囲での収集・保存期間・削除・保管先の権限まで決める。
  • 通知が来ない時は、受付・保存・通知の3段階でどこが止まったかを切り分ける。
  • 上限は受付(Netlify)・実行(GAS)・メール送信で分けて確認し、保存値が化ける対策も入れる。

問い合わせフォームは、作って公開したあとも、迷惑送信への対策、個人情報の管理、通知エラーや利用上限の確認まで含めて運用する必要があります。ZELKでは、フォームをはじめとする業務自動化の点検から、安全に社内で使い続けられる形への改善まで支援しています。