AIでフォーム受付から自動返信までつなぐ方法

フォームの自動返信は、受け付けたことを知らせる定型通知と、問い合わせ内容に応じた個別回答を分けます。まず回答を保存して受付通知を送り、AI分類や回答案はその後に処理します。個別生成が失敗しても受付記録を失わない構成にし、AIが作った文章を無人で送る範囲を限定してください。

受付と回答を分ける理由

送信者が必要とする最初の情報は「受付されたか」「いつ次の連絡があるか」です。これは問い合わせ内容を解釈しなくても、固定文で案内できます。一方、質問への回答には、製品仕様、価格、契約、個人事情など正確さが必要です。AIによる要約や分類の失敗が、受付通知まで止めないよう、両者を別状態で処理します。

表は横にスクロールできます

Workflow	内容	失敗時
Intake	response IDとtimestampを保存	受信記録とerror alert
Receipt	定型の受付確認を送信	再送状態を記録
Classification	categoryと不確実性を候補出力	human reviewへ
Draft	approved sourceに沿う返信案	送信せず保留
Approval	担当者が内容・宛先を確認	修正履歴を保存
Reply	承認後に送信	message ID / failure記録

Google Apps Scriptで受け取る

Apps ScriptのForm Submit event objectにはフォーム回答に関するevent dataが含まれます。Spreadsheetに紐づくtriggerとGoogle Formに紐づくtriggerでは、利用できるevent fieldsが異なるため、どちらのtriggerを使うか明確にします。Installable triggerは承認されたユーザー権限で動作するため、trigger作成者、アクセス権、必要scopeを管理者と確認してください。MailAppはメール送信APIですが、送信量や利用条件はaccountやquotaに依存し、実運用前に現行制限を確認します。

1. Form Submitを受け、response ID、timestamp、必要な回答だけ保存する。

2. 必須fieldと返信先emailをvalidationし、invalid addressを自動推測しない。

3. 受付完了を定型templateから送信する。

4. AI分類は資料請求、問い合わせ、要確認などの候補に使う。

5. 公式資料に基づく回答draftを作り、sourceと未確認点を付ける。

6. high-risk、曖昧、機微情報、契約判断を含む案件は人のqueueへ送る。

7. 承認・送信結果とmessage IDを記録する。

Form fieldと返信先

返信先を自由記述の本文や署名から取り出すのではなく、専用email fieldから読みます。本人確認が必要な問い合わせでは、送信者が入力したaddressだけで本人性が証明されたとは扱いません。CCや外部共有をAIに決めさせず、recipient ruleを明示してください。

フォームに機密情報、健康、雇用、支払い情報を含める場合、用途、保存先、通知メールへ含める範囲、閲覧権限、保持期間を確認します。受付通知へ回答本文を丸ごと含めない設計も検討します。AI分類へ送るdataは必要最小限にし、契約・workspaceのdata handlingを確認します。

表は横にスクロールできます

Field	用途	自動返信での扱い
response_id	重複防止・追跡	内部記録
email	返信先	format/confirmation rule
category	担当振り分け	AI案なら要確認
free text	相談内容	不要な場合は通知へ転記しない
consent / purpose	連絡の根拠	ruleで確認

Error Matrix

表は横にスクロールできます

状況	自動処理	残す記録
必須項目不足	個別回答を止める	response ID、不足field
返信先不正	受付記録は保持	address error、human follow-up
AI分類失敗	担当者へ振り分ける	error state
Mail送信失敗	未送信queueへ残す	attempt、error
同じresponse再実行	二重送信を抑止	response ID、message ID
source不足	返信draftを保留	不足する資料、owner

送信成功後にstateを書き戻す順番を決めます。送信前にsent扱いすると、失敗を見逃す可能性があります。メール送信と台帳更新の間で停止する場合に備え、再実行時は送信履歴を確認するか、idempotency keyが使える既存仕組みを検討します。

個別回答を自動送信しない条件

契約、請求、返金、セキュリティ、苦情、法的判断、本人確認など、誤回答の影響が大きい内容は、分類がconfidence高く見えても自動返信を止めます。AIが判断できない状態を「その他」へ押し込まず、担当者へ渡す基準を明記します。承認済みFAQを使う場合も、version、更新日、適用範囲を保ち、該当sourceがないときは回答を創作しません。

導入前のテスト

test formとtest recipientで、正常受付、必須field不足、無効email、AI失敗、mail送信失敗、同一responseの再実行を試します。外部の実recipientにテスト送信しないよう、test環境を分離し、triggerの重複作成や誤ったowner権限も確認してください。

• 受付通知はAI生成に依存せず送られるか。

• response IDで同じ送信を防げるか。

• 送信結果がForm responseと対応付くか。

• 未承認の個別回答が外部へ出ないか。

• error queueを監視する担当と再処理期限が決まっているか。

• Apps Scriptのtrigger author、scope、quotaが運用条件に合うか。

AIものさしの判断

受付の確実性を優先するなら、受付通知と個別回答を別workflowにします。AIは分類や下書きに使い、送信先、送信可否、法務・契約等の回答を判断させないでください。AIが止まっても受信記録と受付連絡が残り、個別判断を人へ回せる構成を選びます。

Triggerの種類とevent data

Apps Scriptのイベントオブジェクトは、設定したtriggerによって持つpropertyが異なります。フォームに紐づけたsubmitと、回答先Spreadsheetに紐づけたsubmitでは、回答を読む形が同じとは限りません。たとえば回答データやnamed valuesを想定する実装を、別種類のtriggerへそのまま流用しないでください。設置先を決めたら公式資料の該当event shapeに合わせ、テスト送信から実データを確認します。単純triggerとinstallable triggerも権限や実行主体が異なるため、必要なサービスを使う場合はinstallable triggerの要件を確認してください。

受付処理の最小契約

表は横にスクロールできます

データ	受け取る場所	送信前の確認
response ID	eventまたは回答行の安定ID	重複処理の識別に使えるか
timestamp	eventまたは回答記録	timezoneと表示形式
reply address	専用入力field	空欄・書式・入力ミス
category	固定選択または分類候補	高risk案件を分岐できるか
message status	処理管理column	received / draft / sent / error

メールの受付通知は「フォームを受信した」という事実だけを伝える定型文にします。受付通知の成功を、個別相談に回答済みであるかのように見せないでください。個別の返信文には、問い合わせ内容に合った資料や担当者判断が必要になるため、分類結果やAI下書きを承認待ちにし、送信担当者が承認した場合だけ次へ進めます。

失敗を分けて記録する

表は横にスクロールできます

失敗点	受付記録	受付通知	個別回答
event data不足	保存してerror	可能なら定型通知	作成しない
reply address不正	回答は保存	返信先要確認	送信しない
AI分類失敗	受信済みを維持	通知済みならその状態を維持	担当者へ回す
MailApp error	attemptを記録	未送信error	勝手にsentへしない
再実行	response IDで照合	二重送信を防止	既存draftを再利用または確認

送信actionの成功を確認してからstatusを書き換えるだけでは、送信直後の停止で結果が不明になる可能性があります。response ID、試行時刻、送信種別、error情報を保持し、重複を避ける手順を決めます。Apps Scriptの実行時間やメール送信quotaはアカウント・サービス条件で変わるため、数値を固定値として記事に書かず、運用開始時に現在の公式制限と実行履歴を確認します。

人へ渡す判定表

表は横にスクロールできます

内容	自動化の扱い
資料を受け付けた事実	定型受付通知の候補
既知FAQと一致する質問	出典付きdraftを作り人が確認
返金、契約、法務、医療、金融	自動送信を停止し担当へ
個人情報や認証情報を含む	入力を最小化し、必要なら隔離
質問の意図が不明	追加確認を依頼するdraftに留める

この表は運用設計の例であり、業種の法的分類を確定するものではありません。問い合わせの内容をどの担当へ振り分けるか、緊急対応の期限をどうするかは、組織のpolicyと人員体制で定義します。

導入前の確認

テストアカウントでフォームを複数回送信し、各回答に一つの受付記録ができること、受付通知に誤った宛先が使われないことを確かめます。空欄、長文、改行、URL、絵文字、想定外の選択肢を試し、HTMLメールに未escapeの入力が入らないかを確認します。個人情報をAI serviceへ渡す場合は、そのserviceのdata handling、保存、学習利用の条件を確認してから対象fieldを絞ります。