「自動返信が一度届いた。これで納品OK?」。Googleフォームの返信を外注するときは、回答者への返信と社内への通知を別々に確かめます。途中で止まった後に、届いた分まで送り直さないか。ここまで依頼時に決めると、完成の線を先にそろえられます。
見積前に「誰へ送るか」「何をもって送信済みとするか」「失敗時にどこから再開するか」を一枚にします。自動返信と担当者通知を分け、同じ受付の再実行と、新しい受付を試す。結果が分からない送信は、確認するまで自動再送しない。この条件を満たせるか、発注先と相談します。
回答内容の控えが届けば足りるなら、Googleフォーム標準の「回答のコピー」を先に試せます。独自の案内文、受付番号、担当別の通知が必要で、自分で作成・保守する担当を置けない場合は、Google Apps Script(GAS。Googleの作業を自動化するプログラム)の新規開発が比較候補です。
依頼票は「返信」と「担当者通知」を分けて書く
「問い合わせが来たらメールを送ってください」だけだと、送り先も、完成の見方も広すぎます。次の欄を埋めれば、見積を頼む前の話が具体的になります。
| 依頼票の欄 | 記入例・決めること |
|---|---|
| 対象とするフォーム | 問い合わせ受付1本。今のフォームを変更するか、新しいURLで作るか。過去回答を含めるか。 |
| 回答者への返信 | メール欄の本人へ1通。受付番号、案内文、返信先を決める。回答全文を載せる必要があるかも分ける。 |
| 社内への通知 | 誰に、何を知らせるか。回答者へ社内の連絡先や内部メモが出ないこと。 |
| 記録 | 受付ごとの番号、返信の状態、社内通知の状態、実行日時、確認が必要な理由。 |
| 設置と保守 | 動かすGoogleアカウント、承認する人、コードの納品、設定手順、停止方法、修正範囲。 |
ここでいう受付番号は、回答ごとに付ける識別番号です。同じ人が別件を相談することもあるので、メールアドレスだけを「処理済み」の印にすると、新しい依頼まで止めるかもしれません。同じ受付をもう一度処理する場合と、新たに回答した場合を分けます。
送信元の表示名と、実際に動かすアカウントも別です。Google公式では、インストール型トリガーは作成したユーザーの権限で実行されます。トリガーとは、フォーム回答などをきっかけに処理を始める設定のこと。完成ファイルが届くだけか、自分の環境への設置確認まで含むかを見積に入れます。
最初の相談は、質問名と架空の回答例で進められます。実際の顧客回答、個人のメールアドレス、パスワードや認証コードを添付する必要がある、という話ではありません。組織のアカウントを使う場合は、管理者が認める共有・承認方法で設置できる出品かを確かめます。
「同じ受付をもう一度」と「別の受付」を6ケースで試す
次は、説明用の架空例です。回答者への返信1通、担当者1人への通知1通を作る条件にしています。数字は、今回の操作で追加する送信処理の回数。受信箱への到着を確認した実績ではありません。
BとCの違いが大事です。「同じ番号だから繰り返さない」と「同じ人だから二度と送らない」は別物。逆に、同じ内容をフォームから再投稿して新しい番号が付いた場合に、それも重複扱いしたいなら、その判定は追加の依頼条件です。
D〜Fは、どの出品にも標準で付く機能ではありません。発注前に対応可否と費用を相談し、試験用の環境で状態を再現してもらいます。本番の問い合わせをわざと失敗させたり、実在の第三者へ試験メールを送ったりする方法は使いません。
特にEは、エラー表示を見ただけでは未送信と決められない場面です。送信処理と状態の保存は、途中で別々の結果になり得ます。「必ず一度だけ届く」という保証にせず、担当者がどの記録を見て、何を照合し、再送を判断するかまで納品手順にします。
実際の受信確認では、許可を得たテスト用の受信箱を使います。返信と社内通知の件名・本文・宛先を別々に見て、他の回答者の情報や内部メモが混ざっていないかも確かめます。ケースごとの期待値と実測値を並べ、未確認の欄は空欄のまま残してください。
Googleフォーム自動返信の依頼・検収packをダウンロードする(ZIP)
配布用の一式には、空欄の依頼票・検収票と、架空の報告を照合するHTMLを入れています。展開して「検収照合.html」を開くと、一致する見本と、B〜Eを取り違えた見本を試せます。報告用JSONの形式も見られるので、発注先との試験条件の相談に使えます。
照合器は、実装を動かしたり、メールを送ったりしません。報告値が期待値と同じかを見るだけです。発注先が書いた報告が一致したことと、実際のコード・受信箱で確認できたことは分けて扱います。
1日20件でも、送信先が4人なら80宛先になる
問い合わせ件数と、メールの宛先数も分けます。GASの公式の割り当て表では、MailAppなどの1日あたりのメール受信者数は、一般ユーザー向けアカウントで100、Google Workspaceで1,500です。試用アカウントなどには追加条件があり、上限は変更される場合があります。これはGAS側の宛先上限です。Gmail側や利用するアドオン側に別の制限がある場合は、その条件も確認します。
架空の計画として、回答者1人と社内3人の全員へ毎回送る場合を考えます。1受付につき4宛先です。同じアカウントの他のGAS処理で12宛先を使う前提なら、次の計算になります。
| 計画上の受付数 | 今回のフォーム分 | 他のGAS送信分を足した数 |
|---|---|---|
| 20件 | 20×4=80宛先 | 80+12=92宛先 |
| 22件 | 22×4=88宛先 | 88+12=100宛先 |
| 23件 | 23×4=92宛先 | 92+12=104宛先 |
22件は算数上の境界で、運用できる保証値ではありません。テストや再送、他の処理も枠を使います。Googleは割り当てをユーザー単位とし、最初のリクエストから24時間後にリセットすると案内しています。「毎晩0時に100へ戻る」と見積もらないことも必要です。
発注先には、MailAppの残り送信可能宛先数を確認する方法と、不足時に処理をどう残すかも相談できます。残り数の確認だけで後続の送信枠を確保できるわけではありません。件数が合わないなら、通知先や通知方法、別の受付サービスを含めて設計を変える判断になります。
発注前の一手は、完成条件を一つ書くこと
今日書くなら、「同じ受付を再処理しても、成功記録のあるメールは追加しない。ただし同じ人からの別受付は処理する」の一文から。これを依頼票に入れ、対応できる範囲、設置先、コード・手順書の納品、修正費用を同じ条件で比べます。
コードを受け取った時点と、自分の環境で試験を終えた時点は分けておきます。受付番号、返信、通知、要確認の記録がつながり、テスト用受信箱でも内容を確認できたら、その結果を検収票へ残す。「一通来たからヨシ!」と丸を付けたくなるところですが、もう一段だけ。止まった後の扱いまで分かると、使う側も引き継ぎやすくなります。
既存の自動化を別の担当へ渡す段階なら、GASのトリガーを誰の権限で動かすかを確認する記事へ進めます。

コメント