Googleフォームの自動返信が届かない｜原因の切り分けかた

「google フォーム 自動返信 届かない」と検索してこのページを開いた人のほとんどは、応募者や申込者から「送信したのに何も返ってきません」と連絡を受けた直後です。受付をひとりで回していると、この一報は焦ります。相手の手元で何が起きているのかが見えないまま、フォームの設定画面と自分の受信箱を行ったり来たりすることになるからです。

先に結論を書きます。自動返信が届かない原因は1つではなく、少なくとも6つの層に分かれています。そして、その6つは確かめる手間の重さが全然違います。手間が軽くて発生頻度が高いものから順にあたれば、たいていは数分で当たりが付きます。この記事は、その順番を決めるための記事です。

「自動返信が届かない」の中身は、少なくとも6つに分かれている

窓口の担当者からしばしば出るのは「自動返信が届かない」という一言ですが、この一言は現象の名前であって原因の名前ではありません。同じ現象の裏側に、性質のまったく違う出来事がいくつも並んでいます。

1つ目は、そもそも自動返信が送られる設定になっていない場合です。Googleフォームで回答者に控えを送るには、メールアドレスを収集していることと、設定画面で控えの送信を有効にしていることの両方が要ります。片方だけでは送られません。

2つ目は、送られてはいるが宛先が本人のものになっていない場合です。回答者に手で入力してもらう方式だと、打ち間違いが一定の割合で混ざります。届いていないのではなく、別の誰かのところに届いています。

3つ目は、送られていて宛先も合っているのに、相手の受信箱に入っていない場合です。迷惑メールフォルダ、プロモーションタブ、会社のメールゲートウェイでの隔離が該当します。この可能性については、Googleの公式ヘルプ自身が明記しています。

4つ目は、標準機能ではなくApps Scriptで自作の自動返信を組んでいて、その送信が上限に当たっている場合です。この場合は「昨日までは届いていたのに、今日の夕方から急に届かなくなった」という、時間帯に偏った止まり方をします。

5つ目は、同じくApps Scriptで組んでいて、トリガーの認可が通っていない場合です。スクリプトが動いていない、あるいは動こうとして権限で止まっています。

6つ目は、フォームがそもそも回答を受け付けていない場合です。締切に達している、回答数の上限に達している、公開されていない、といった状態では、回答が成立していないので当然控えも届きません。

6つのうち、どれに当たっているかを推測で決めないことが大事です。推測で1つに賭けると、外れたときに最初からやり直しになります。順番に消していけば、最悪でも6回で終わります。

切り分けは、確かめる手間が軽い順に並べる

原因の切り分けで失敗するパターンはだいたい決まっています。いちばん複雑な原因、つまりスクリプトや権限の話から手を付けてしまうことです。技術的に難しそうな話ほど「これが原因だろう」と思い込みやすいのですが、実際に多いのは設定の抜けと宛先の取り違えです。

そこで、確かめる順番を次のように決めます。判断の基準は「原因である確率の高さ」ではなく「確かめるのにかかる手間の軽さ」です。手間が軽い項目は、外れてもほとんど損をしません。

第1に、フォームの設定画面を開いて、控えの送信が有効になっているかを見ます。これは1分もかかりません。

第2に、届かなかったと言われた回答のアドレスを、回答一覧で1文字ずつ確認します。これも数十秒です。

第3に、自分のアカウントでテスト送信して、自分の受信箱の迷惑メールフォルダまで見ます。ここまでで、標準機能を使っている場合の原因の大半は消えます。

第4に、Apps Scriptで組んでいる場合だけ、実行ログと送信数を見ます。ここから先は、スクリプトを触れる人でないと進めません。

第5に、トリガーの一覧を開いて、認可の状態と直近の失敗を見ます。

第6に、フォームの受付状態と、Google Workspaceを使っている場合は管理者側の設定を見ます。

この順番には副産物があります。上から4つは、あとで別の人に引き継ぐときの手順書としてそのまま使えます。受付をひとりで回していると、こういう切り分けの知識が個人の頭の中だけに溜まって、休んだ日に誰も対応できなくなります。順番として書き出しておくと、それが防げます。

最初に確かめること：控えを送る設定が有効になっているか

Googleフォームで回答者に控えを送る機能は、公式ヘルプでは「送信済みの回答のコピーを回答者に送信」と書かれています。これが自動返信にあたる標準の仕組みです。

メールアドレスを収集していないと、この設定は選べない

公式ヘルプによれば、この設定はメールアドレスを収集している場合に設定できると書かれています。つまり、アドレスを集めていないフォームでは、そもそも控えの送り先が存在しません。設定画面をいくら探しても見つからない、という状態になります。

見落としやすいのは、フォームの中に「メールアドレス」という名前の自由記述の設問を自分で作っている場合です。設問として作ったアドレスは、あくまで回答の1項目であって、フォームが控えの宛先として使う値ではありません。控えを送るには、設定側でメールアドレスの収集を有効にしておく必要があります。

メールアドレスの収集方法には2種類あります。ログイン中のGoogleアカウントのアドレスを収集する方式では、公式ヘルプに「Respondents must confirm that their Google Account email address gets collected with their response.」と書かれており、回答者は自分のアドレスが収集されることを確認したうえで送信します。もう1つは回答者に入力してもらう方式です。

「リクエストされた場合」と「常に」で挙動が変わる

設定手順は、フォームを開いて上部の設定を開き、「回答」の横の下向き矢印から「送信済みの回答のコピーを回答者に送信」を選びます。ここで選べるのは「リクエストされた場合」と「常に」の2つです。

「リクエストされた場合」を選んでいると、回答者が送信画面でコピーを希望するチェックを入れたときだけ控えが送られます。チェックを入れずに送信した人には届きません。この場合、担当者側から見ると「届いた人と届かなかった人が混ざっている」という状態になります。全員に必ず届けたいなら「常に」を選びます。

届かなかったと言われた件が1件だけで、他の人には届いているなら、ここを疑う価値が高いです。逆に、全員に届いていないなら設定そのものがオフになっている可能性が高く、確認の視点が変わります。「一部だけか、全員か」を最初に把握しておくと、以降の切り分けが速くなります。

なお、この標準機能で送られるのは回答内容の控えです。文面を自由に書き換えた案内文を標準機能として送れるという記載は、今回確認した公式ヘルプの範囲では見当たりませんでした。公式ヘルプは代わりに、Googleが提供する無料のForm Notificationsアドオンを案内しています。文面を整えた案内を返したい場合は、アドオンかApps Scriptを検討することになります。

次に確かめること：宛先が本人のものになっているか

設定が正しくても、宛先が違えば届きません。ここは技術の問題ではなく、入力の問題です。

手入力のアドレスには、必ず打ち間違いが混ざる

回答者にアドレスを入力してもらう方式を選んでいる場合、送信されたアドレスは回答者が打った文字そのものです。ドメインの綴り違い、全角文字の混入、末尾の余分な空白、といったものが一定の割合で混ざります。

現場でよく見るのは、gmail.comの綴り違い、携帯キャリアのドメインの打ち間違い、そして会社のアドレスの部署名部分の間違いです。届かなかった回答について、まず回答一覧のアドレス列を目で追ってください。1文字ずつ見るのが確実です。

打ち間違いを減らす方法として、フォーム側の回答の検証でメールアドレス形式を必須にする手はあります。ただしこれは形式が正しいかどうかしか見ません。形式として正しく、しかし存在しないアドレスは通過します。形式検証で防げるのは一部だけだと理解しておいてください。

確認済みのアドレスを集めると、取り違えは減る

ログイン中のGoogleアカウントのアドレスを収集する方式にすると、打ち間違いは構造的に起きなくなります。ただし引き換えに、回答者はGoogleアカウントにログインしている必要が出てきます。

ここは受付の性質で判断が分かれるところです。社内向けの申請や、すでにアカウントを持っている人が対象の受付なら、ログインを求めても脱落はほとんど起きません。一方で、社外の不特定多数から応募や問い合わせを受ける窓口では、ログインを求めた時点でそこをやめてしまう人が出ます。応募数を落としたくない受付では、この判断は慎重にしたほうがいいです。

関連して知っておきたいのは、ファイルのアップロード設問を使う場合の条件です。公式ヘルプには「To answer this question, responders need to sign in to a Google Account.」と書かれており、アップロードに答えるには回答者のログインが必要です。また「回答を1回に制限する」をオンにした場合も、フォームにアクセスして入力するにはGoogleアカウントへのログインが必要になると書かれています。書類を集める受付では、この条件が応募のしやすさに直結します。

三番目に確かめること：迷惑メール判定に引っかかっていないか

設定も宛先も合っている。それでも届かない。この段階でいちばん多いのが、受信側での振り分けです。

Googleの公式ヘルプは、控えが届かない可能性そのものについて明記しています。

In certain circumstances, responders may not receive the expected response receipts due to spam filters or other counter-abuse measures. 出典: support.google.com

つまり、迷惑メールフィルタや不正利用対策によって、期待した控えが回答者に届かない場合があると、提供元自身が書いています。これは不具合ではなく、そういうことが起こりうる仕組みだということです。ここを知らないと「設定を何度見直しても原因が見つからない」という時間の使い方をしてしまいます。

確かめ方はこうです。まず自分のアドレスでフォームに回答して、控えが自分に届くかを見ます。届いたなら送信そのものは動いています。次に、届かないと言われた回答者に、迷惑メールフォルダとプロモーションタブを見てもらいます。会社のアドレス宛なら、情報システムの担当者に隔離ログを確認してもらう手もあります。

確認を依頼するときは、いつ送信されたものか、差出人がどう見えるか、件名がどういう文字列かを添えてください。これが無いと相手は探しようがありません。受付の担当者としては、テスト回答を1件自分宛に送って、その控えの件名と差出人表示を控えておくと、以降の問い合わせに即答できます。

もう1つ、受付側で決めておくべきことがあります。控えが届かない可能性がある以上、控えの到達を受付完了の証拠にしないという運用です。回答一覧に記録が残っていれば受付は成立しています。回答者から「届いていないので受け付けられていないのでは」と問い合わせが来たとき、記録を見て「受け付けています」と即答できる状態にしておけば、この種の問い合わせは1往復で終わります。

四番目に確かめること：自作の自動返信が送信の上限に当たっていないか

文面を整えた自動返信を返したくて、Apps Scriptで組んでいる受付は少なくありません。この構成の場合、標準機能とはまったく別の理由で止まります。

Apps Scriptには公式に公開された割り当てがあり、メールの送信先の数には1日あたりの上限があります。消費者向けアカウントは1日100件、Google Workspaceは1日1,500件です。この数字は公式の割り当て表に載っているもので、表には「subject to change without notice」という注記が添えられています。

上限に当たると、止まり方に特徴が出る

上限による停止には、見分けやすい特徴があります。1日の途中まで届いていて、ある時点から先が一斉に届かなくなるという止まり方です。募集の締切日、告知メールを出した直後、イベントの申し込みが集中した日に起きやすくなります。

とくに個人のGoogleアカウントで運用している受付は、1日100件という上限に思ったより早く届きます。回答者への控えだけでなく、担当者への通知メールもスクリプトから送っている場合、1件の回答で2通を消費します。50件の申し込みで上限に達する計算です。告知を出した日の午後に止まる、という現象はこれで説明が付くことがあります。

トリガーの実行時間にも上限がある

見落とされやすいのが、送信数ではなく実行時間の上限です。公式の割り当て表には、トリガーの総実行時間として消費者向けアカウントは1日90分、Google Workspaceは1日6時間と書かれています。また、1回の実行時間はどちらのアカウントでも6分です。

スクリプトの中で外部サービスを呼んだり、大きなスプレッドシートを読み書きしていると、1回の実行が長くなります。1回6分を超えた時点でその実行は打ち切られるので、メールを送る処理がその後ろに書かれていれば、その回の自動返信は送られません。同じ理由で、1日の総実行時間の枠を使い切ると、それ以降のトリガーが動きません。

ちなみにURL Fetchの呼び出しにも上限があり、消費者向けアカウントは1日20,000件、Google Workspaceは1日100,000件と公開されています。外部と連携している受付では、ここも見ておく価値があります。

確認するときは、Apps Scriptの実行数のログを開いて、失敗している実行があるかどうか、失敗のタイミングが集中しているかどうかを見てください。集中していれば上限、散らばっていれば別の原因という見当が付きます。

五番目に確かめること：トリガーの認可が通っているか

Apps Scriptで自動返信を組む場合、フォームの送信をきっかけに動かすにはトリガーが要ります。ここには2つ、つまずきやすい点があります。

1つ目は、トリガーの種類です。公式のドキュメントには、インストール型トリガーに「On form submit」があり、フォーム用と、回答がスプレッドシートに送られる場合のスプレッドシート用の2種類が用意されていると書かれています。フォーム側に付けるつもりでスプレッドシート側に付けている、あるいはその逆になっている構成では、期待した場面で動きません。フォームとスプレッドシートは独立したファイルなので、どちらに付けたのかを取り違えると発見が遅れます。

2つ目は認可です。公式ドキュメントは、インストール型トリガーの利点として「can call services that require authorization」と書いています。裏を返すと、認可が要る処理を含むスクリプトは、認可が通っていない状態では動きません。メールの送信は認可が要る処理です。トリガーを作ったアカウントと、実際に運用しているアカウントが違う、あるいは認可の同意を一度も通していない場合、フォームは正常に回答を受け取っているのにメールだけが出ない、という状態になります。

もう1つ、公式ドキュメントには重要な注記があります。「Script executions and API requests don't cause triggers to run. For example, calling FormResponse.submit() to submit a new form response doesn't cause the form's submit trigger to run.」と書かれています。スクリプトやAPIから回答を送信しても、フォームの送信トリガーは動きません。テストのつもりでスクリプトから回答を作って「動かないぞ」と悩むのは、この仕様に当たっている可能性があります。動作確認は、実際にフォームの画面から人が送信する形で行ってください。

なお、Forms APIそのものにも使用量の制限があります。読み取りリクエストはプロジェクトあたり1分に975回、書き込みリクエストはプロジェクトあたり1分に375回で、超えると「429: Too many requests」が返ると公開されています。APIを絡めた仕組みを組んでいるなら、ここも切り分けの候補に入ります。

六番目に確かめること：通知と自動返信を取り違えていないか

受付の相談でしばしば起きているのが、担当者向けの通知と回答者向けの控えを、同じものだと思っている状態です。この2つはGoogleフォームでは別の機能で、設定する場所も違います。

担当者向けの通知は、フォームの回答タブからその他のアイコンを開いて「新しい回答についてのメール通知を受け取る」で切り替えます。これは自分の受信箱に「回答が来た」と知らせる機能で、回答者には何も送りません。ここをオンにして「自動返信を設定した」と考えていると、回答者に何も届かないのは当たり前です。

スプレッドシート側にも通知ルールがあり、フォームが送信されたときに通知を受け取れます。頻度は1日1回のまとめ（Email - daily digest）と、変更のたび（Email - right away）から選べます。ここで押さえておきたいのは、公式ヘルプに「You can only set up notifications for yourself.」と明記されている点です。通知を設定できるのは自分に対してだけだと書かれています。

この一文が効いてくるのは、受付を2人以上で回している場合です。担当者Aが自分のスプレッドシートで通知を設定しても、担当者Bには何も届きません。Bが受け取りたければB自身が設定します。標準機能として複数人に通知を送る設定は、今回確認した公開資料では確認できませんでした。公式ヘルプが案内しているのは、Googleが提供する無料のForm Notificationsアドオンで、こちらはフォームのオーナーと共同編集者に対して、あらかじめ決めた回答数のしきい値に達したときに届くメールを設定できると掲載されています。

引き継ぎのときにここが問題になります。担当者が変わったのに通知の設定が前任者のままで、新しい担当者の受信箱には何も来ない。回答一覧にはちゃんと記録が積み上がっているのに、誰も気づかない。受付の担当を変えるときは、フォームの共同編集者の入れ替えだけでなく、通知の設定を新しい担当者が自分で入れ直したかどうかを確認してください。

七番目に確かめること：フォームがまだ回答を受け付けているか

控えが届かないと言われた回答について、回答一覧にその回答が入っているかを見てください。入っていなければ、控え以前に回答が成立していません。

2026年1月に、フォームを自動で締め切る機能が追加されています。公式ブログには「Form owners and editors will be able to set a specific date and time to close the form, or set a certain number of responses that will trigger the form to close automatically.」と書かれており、日時での締切と、回答数での自動締切が設定できます。この機能は既定ではオフで、フォームを公開したあとに作成者が有効にする、とも書かれています。提供範囲はGoogle Workspaceの利用者、Workspace Individualの契約者、そして個人のGoogleアカウントの利用者です。

つまり、以前に誰かが定員での自動締切を設定していれば、その件数に達した瞬間からフォームは閉じます。閉じたあとにアクセスした人には、締切のメッセージが表示されます。設定手順は「Accepting responses」の下にある「Set close date or response limit」からで、日時で締め切る場合は「On a date」、件数で締め切る場合は「After a number of responses」を選びます。締め切ったあとに表示する文言も編集できます。

手で止めている場合もあります。「回答を受付中」をオフにすると「このフォームでは回答を受け付けていません」というメッセージが表示されます。テストのために一時的にオフにして、戻し忘れているケースは実際にあります。

もう1つ、APIでフォームを作っている場合の注意があります。公式のリファレンスには「Forms created with the API after June 30, 2026 will have an unpublished state by default」と書かれています。APIで作ったフォームは既定で未公開になり、公開しないと回答を受け付けません。公開範囲についても、公式ヘルプは「When you publish a form, responders can access it. If the form is unpublished, responders with the link can't access it.」と書いています。リンクを配ったのに誰も回答できない、という状態はここで起きます。

八番目に確かめること：Google Workspaceの管理者側の設定

会社や団体のGoogle Workspaceでフォームを運用している場合、自分の設定画面の外側に原因があることがあります。

公式の管理者向けドキュメントには「Google フォームを有効にするには、Google ドライブも有効にする必要があります」と書かれています。ドライブが止まっている状態ではフォームも使えません。また、設定を変えたときの反映について「変更が反映されるまでに最長で 24 時間ほどかかることがありますが、通常はこれより短い時間で完了します。」と書かれています。管理者に設定を直してもらった直後に確認して「変わっていない」と判断するのは早すぎることがある、ということです。

外部共有の設定も関係します。公式ドキュメントには、共有設定でフォームの回答について、ドメイン内のユーザーが外部で作成されたフォームに回答できるかどうか、または回答のためにフォームを外部と共有できるかどうかを選択できると書かれています。社外の人に回答してもらう受付では、ここが閉じていると回答そのものが成立しません。

回答者側の公開範囲も同じ層の話です。公式ヘルプによれば、一般的なアクセスの項目で、リンクを知っている全員に公開するか、対象のオーディエンスに限定するかを選べます。ドメイン、信頼できるオーディエンス、ユーザーのグループに限定でき、回答者ごとにアクセスレベルを選ぶことも、有効期限を設定することもできると書かれています。限定を掛けたまま社外に配ってしまうと、社外の人はフォームを開けません。

自分の権限で見えている画面と、社外の回答者に見えている画面は違います。可能なら、業務のアカウントとは別のブラウザプロファイルやシークレットウィンドウで、配布したリンクをそのまま開いて確認してください。これは1分で終わる確認で、切り分けの精度が大きく上がります。

回答が積み上がってきた受付で出る、別種の不具合

自動返信とは直接つながりませんが、切り分けの途中で回答一覧を見にいったときに戸惑わないよう、回答件数に関する公式の記載も押さえておきます。Google Workspaceのラーニングセンターは、回答が多いフォームで一部の機能が期待どおりに動かなくなることを明記しており、これは信頼性を保つための制限だと説明しています。

回答が10,000件を超えると、CSVでダウンロードした回答が送信日時順に並ばなくなり、質問別のビューと個別のビューが表示されなくなります。回答が50,000件を超えると、回答の概要が表示されなくなります。回答が100,000件を超えると、スプレッドシートと同期されなくなります。ただし公式は、回答自体は受け付け続け、CSVでダウンロードできると書いています。

長く使っている問い合わせ窓口では、この件数に届くことがあります。とくに100,000件を超えたときの同期停止は、切り分けの現場を混乱させます。スプレッドシートに新しい行が増えないので「フォームが壊れた」と見えますが、回答自体は入っています。同期を止めた場合の挙動として、公式ヘルプにはリンクを解除したときの説明もあり、「新しい回答はスプレッドシートに送信されませんが、現在のデータはそのまま残ります。」「後でスプレッドシートに再接続できます。」と書かれています。

フォーム自体の作りにも上限があります。公式ヘルプには「After you've created a form, you can add and edit up to 300 pieces of content, like questions, descriptions, images, and videos.」と書かれており、設問だけでなく説明文・画像・動画を含めて合計300個までです。セクションは「To organize your form by topic, you can add up to 75 sections.」とあり75個までです。設問を増やし続けている受付では、ここに当たることがあります。

切り分けの順番を1枚にしておく

ここまでの内容を、確かめる順番として並べ直します。上から順に見ていけば、原因の層は消えていきます。

この表の価値は、原因を当てることよりも、当たらなかったときに次にどこを見ればいいかが決まっていることにあります。受付をひとりで回していると、調べる順番が毎回変わって同じところを何度も見ることになりがちです。順番が固定されていれば、途中で電話が入って中断しても、どこまで消したかを覚えていられます。

届かなかった1件を、あとから拾えるようにしておく

原因の切り分けと同じくらい大事なのが、届かなかった1件をどう扱うかです。ここは仕組みの話ではなく運用の話になります。

まず決めておきたいのは、控えが届かないことを前提に受付を設計することです。公式ヘルプが迷惑メール対策で届かない場合があると明記している以上、控えの到達を100%にはできません。だとすれば、控えが届かなくても受付が成立していると回答者に伝わる作りにしておくのが筋です。具体的には、送信直後の完了画面に「控えのメールが届かない場合でも受付は完了しています」と書いておく、問い合わせ先を書いておく、といったことです。この一文があるだけで、届かなかったという問い合わせは目に見えて減ります。

次に決めるのは、届かなかったと連絡が来たときに誰がどう返すかです。ここで効いてくるのが、返信したかどうかが記録に残っているかどうかです。回答一覧のスプレッドシートに「対応済み」の列を作って手で更新している受付は多いですが、この方式は人数が増えると必ず破綻します。現場では、同じ回答に2人が別々に返信してしまう二重返信と、誰かが返すだろうと思って全員が返さない返し忘れの両方が起きます。返信したかどうかが表に残らないと、二重返信と返し忘れは必ず起きます。

3つ目に、再送の手順を決めておきます。宛先の打ち間違いだった場合、正しいアドレスを聞き直して手で送り直すことになります。このとき、送った内容が記録に残らない方法で送ると、あとから「送ったはずだが内容が分からない」という状態になります。送り直した記録も、最初の回答と同じ場所に残るようにしておいてください。

4つ目に、確認の依頼文をテンプレートにしておきます。回答者に迷惑メールフォルダを見てもらうときの文面、送信日時と件名と差出人表示を伝える文面を、あらかじめ用意しておけば、その場で考える時間がなくなります。受付の担当者の負担は、判断の回数で決まります。判断を減らす仕組みが、そのまま処理速度になります。

受付の道具を選び直すときに、どこを見ればいいか

ここまで書いてきた切り分けは、フォームの作り手側の話です。しかし「自動返信が届かない」で困っている人の多くは、作る側ではなく、届いたものを受けて返す側にいます。この立場から見ると、問題の本質は「メールが1通届かなかったこと」ではなく、送信されたあとの処理が道具として揃っていないことにあります。

自動返信は、受付という仕事のごく一部です。回答が届いたあと、誰が担当するかを決めて、返信して、返信したことを記録して、進み具合を全員が同じ画面で見る。この一連の流れのうち、自動返信が担っているのは最初の1歩だけです。残りをスプレッドシートと手作業で埋めていると、返信の記録も、担当の割り当ても、対応の期限も、全部が列の手入力になります。

受付の道具を選び直すかどうかを決めるとき、判断の材料はだいたい次の4つに集まります。1つ目は、回答者にアカウント登録を求めずに受け付けられるか。求めると、そこで応募をやめる人が出ます。2つ目は、返信したかどうかが自動で記録に残るか。3つ目は、担当者を割り当てて、複数人が同じ状態を見られるか。4つ目は、書類の受け取りと、その書類がどこに保存されるかを追えるか。

いま使っている道具でこの4つが足りているなら、乗り換える理由はありません。Googleフォームは回答を集める道具として素直で、無理なく使える範囲が広いです。設問を並べてリンクを配れば、その日のうちに受付が始められます。判断が必要になるのは、集めたあとの処理が手作業のまま増えていったときです。何が違うのかを具体的に見比べたい場合は、Googleフォームとの比較に、集めるところと集めたあとを分けて整理してあります。

WordPressでフォームを作っている受付なら、事情がまた少し変わります。サイト側で完結する代わりに、送信されたメールが届いたかどうかを追いにくいという困りごとが出ます。この構成での詰まりどころはContact Form 7との比較にまとめてあります。Microsoft 365を使っている組織でフォームを回している場合の違いはMicrosoft Formsとの比較で扱っています。

受付の性質によって、効いてくる条件は変わります。応募者から履歴書を受け取る採用の受付では、アカウント登録を求めるかどうかと、書類の保存先の管理が最大の論点になります。この場面の整理は採用の応募受付にあります。公募の受付のように締切と定員がはっきりしている場合は、締切後の扱いと不備の差し戻しが論点になり、助成金・公募の受付にまとめてあります。日々の問い合わせのように件数が読めず担当が分かれる場合の考え方は問い合わせの受付にあります。

参加者数の管理が中心になるイベントはイベントの申し込み、受講者と回ごとの管理が要る講座は講座の受講申し込み、利用日と設備の重複を見る必要がある施設は施設利用の申請、継続的な関係が始まる入会は会員の入会申し込み、機器や製品の不具合を受ける窓口は修理・サポートの受付に、それぞれ受付の型を分けて書いています。自分の受付がどの型に近いかを先に決めると、必要な機能の一覧が短くなります。

機能を横断して見たい場合はできることに一覧があり、画面の動きを先に見たい場合は動くところを見るから確認できます。費用の考え方は料金に、判断の前によく出る疑問はよくある質問にまとめてあります。

最後に、道具を替えるかどうかとは別に、いますぐできることを1つ挙げておきます。控えが届かなかった件について、送信日時、回答者のアドレス、こちらが確認した内容、送り直したかどうかを、回答の記録と同じ場所に残す習慣を作ることです。これは道具に関係なく、今日から始められます。原因の切り分けが速くなるのは、知識があるからではなく、前に同じことが起きたときの記録が残っているからです。受付を長く回すというのは、そういう記録が積み上がっていくことでもあります。

Q1. 回答者に控えのメールが届かないとき、最初に見るべき場所はどこですか？

フォームの設定を開いて「送信済みの回答のコピーを回答者に送信」が有効かどうかを見てください。この設定はメールアドレスを収集している場合に選べます。「リクエストされた場合」だと、回答者がチェックを入れたときだけ送られます。全員に届けたい場合は「常に」を選びます。ここが1分で確認できて、原因として最も多い層です。

Q2. 設定も宛先も正しいのに届きません。考えられる原因は何ですか？

受信側での迷惑メール判定が有力です。公式ヘルプは「In certain circumstances, responders may not receive the expected response receipts due to spam filters or other counter-abuse measures.」と明記しており、控えが届かない場合があることを提供元自身が書いています。回答者に迷惑メールフォルダとプロモーションタブを確認してもらってください。

Q3. Apps Scriptで自動返信を組んでいますが、途中から届かなくなりました。

1日の送信上限に当たっている可能性があります。公式の割り当て表では、メールの送信先は消費者向けアカウントで1日100件、Google Workspaceで1日1,500件です。トリガーの総実行時間は個人が1日90分、Workspaceが1日6時間、1回の実行は6分です。実行ログで失敗のタイミングが集中していれば上限が疑わしくなります。

Q4. 担当者への通知を設定したのに、他のメンバーに届きません。

スプレッドシートの通知ルールは、公式ヘルプに「You can only set up notifications for yourself.」と書かれており、自分に対してしか設定できません。他のメンバーが受け取るには各自で設定する必要があります。標準機能として複数人に通知を送る設定は公開資料では確認できませんでした。公式ヘルプはGoogle提供の無料アドオンForm Notificationsを案内しています。