「google フォーム 自動返信」で調べている人が求めているものは、実のところ2つに分かれます。1つは、申し込んだ人に「受け付けました」という控えが自動で届くようにしたいというもの。もう1つは、届いた内容に応じて文面を変えた返信を、手で書かずに出したいというものです。前者はGoogleフォームの標準の設定でそのまま実現できます。後者は、公式ヘルプがアドオンやApps Scriptを案内している領域で、設定の話ではなく運用の設計の話になります。この記事では、まず標準機能で足りる場面をはっきりさせ、次にそこから先へ進むときの分かれ目、そして自動返信を整えても残ってしまう受付の仕事までを順に扱います。
「自動返信」という言葉が指しているものが、3つに分かれている
受付の担当者どうしで「自動返信を入れたい」と話していても、頭の中で見ているものが食い違っていることがよくあります。設定を調べ始める前に、自分がどれを求めているのかを言葉にしておくと、遠回りが減ります。
1つ目は、回答者に届く受信確認です。申し込みボタンを押した人の手元に、自分が何を書いて送ったのかが残る仕組みのことです。Googleフォームでは「送信済みの回答のコピーを回答者に送信」という設定がこれにあたります。届く内容は回答者が入力した項目そのものです。
2つ目は、受け付けた側に届く新着通知です。回答が入ったことを担当者が知るための仕組みで、これは回答者には見えません。フォーム側の「新しい回答についてのメール通知を受け取る」と、回答を保存しているスプレッドシート側の通知ルールという2つの経路があります。
3つ目が、内容に応じて文面を変える個別の返信です。応募区分によって案内する持ち物が違う、選んだ日程によって集合場所が違う、書類に不備があった人にだけ再提出の案内を送る。こうした返信は、宛先も本文も1件ごとに変わります。3つのうち手間がいちばん重いのはこれで、そしてこれだけが標準の設定では片付きません。
検索して出てくる情報が噛み合わないと感じるとき、原因はたいていこの3つの混線です。「Googleフォームで自動返信ができる」という記事は1つ目を指し、「Googleフォームでは自動返信ができないのでApps Scriptが要る」という記事は3つ目を指しています。どちらも間違ってはいません。自分の受付でいま止まっているのがどれなのかを決めてから読み進めてください。
判別の仕方は簡単です。回答者から「送りましたが届いていますか」という問い合わせが来るなら、詰まっているのは1つ目です。回答が入ったことに気づくのが遅れて対応が後手に回るなら、2つ目です。返信文を毎回コピーして書き換えて送っているなら、3つ目です。
標準機能の「回答のコピー」で足りる場面を先に決める
新しい仕組みを足す前に、いま持っているもので足りるかどうかを確かめる順番が確実です。Googleフォームには回答者へ控えを送る機能が最初から用意されていて、多くの受付はここで止めても問題なく回ります。
設定の手順は「設定」タブの中にある
公式ヘルプに書かれている手順は次の通りです。フォームを開き、上部の［設定］を選び、「回答」の横の下向き矢印を開いて、「送信済みの回答のコピーを回答者に送信」で「リクエストされた場合」または「常に」を選びます。前提として、そのフォームでメールアドレスを収集している必要があります。
メールアドレスの集め方には2通りあります。確認済みのアドレスを集める方法では、回答者が自分のGoogleアカウントのメールアドレスが回答と一緒に収集されることを確認する形になります。もう1つは回答者に入力してもらう方法で、公式ヘルプでは「Responder input」と呼ばれています。社外の不特定多数から申し込みを受けるなら、後者を選ばないと回答者にGoogleアカウントでのログインを求めることになります。
「リクエストされた場合」と「常に」をどう選ぶか
「リクエストされた場合」は、回答者が送信画面でコピーを希望したときだけ届きます。「常に」は、全員に届きます。受付の性質で選び方が変わります。
申し込みの控えが後々の証拠になる受付、たとえば助成金の公募や講座の受講申し込みでは「常に」が向いています。回答者が控えを持っていれば、「申し込んだはずだ」「記録がない」という食い違いが起きたときに、双方が同じものを見て話せます。一方、社内の簡単なアンケートや、匿名性を保ちたい意見募集では、コピーを送らない、あるいは希望した人だけに送る形のほうが素直です。
ここで1つ、公式ヘルプが明記している注意があります。
In certain circumstances, responders may not receive the expected response receipts due to spam filters or other counter-abuse measures. 出典: support.google.com
迷惑メール対策の都合で、期待した控えが届かないことがあると書かれています。控えが届かなかった人からの問い合わせは必ず来るものとして、案内文に「控えが届かない場合はご連絡ください」と一文を添えておくと、窓口の負担が下がります。
標準の控えで足りると判断してよい条件
次の3つを満たしているなら、アドオンもApps Scriptも要りません。1つ目は、返す内容が全員同じであること。2つ目は、回答者が自分の入力内容を確認できれば目的が済むこと。3つ目は、返信のタイミングが送信直後でよいことです。
イベントの申し込みで、当日の集合場所も持ち物も全員共通なら、この3つを満たします。フォームの確認画面や送信後のメッセージに案内を書いておけば、控えのメールと合わせて必要な情報は回答者の手元に残ります。受付の形ごとの必要項目についてはイベントの申し込みに、受け付けたあとに何を管理することになるのかを整理してあります。
逆に、この3つのどれかを外れた時点で、標準の控えだけでは足りなくなります。そのときに公式が案内している道が次の項目です。
本文を書き換えた自動返信が要るときに、公式が案内している道
本文をこちらで自由に書いた自動返信を標準機能として送れる、という記載は、公式ヘルプ、料金ページ、製品ページを確認した範囲では見当たりませんでした。機能が存在しないという意味ではなく、公開資料に記載を確認できなかったということです。公式ヘルプは代わりに2つの手段を案内しています。
Form Notificationsアドオン
Google Workspace Marketplaceに掲載されているアドオンで、提供元はGoogleです。価格は無料と表示されています。掲載内容によれば、回答者が送信したときに届くメールを設定できるほか、フォームのオーナーと共同編集者に対して、あらかじめ決めた回答数のしきい値に達したときに届くメールも設定できます。
しきい値での通知は、定員のある受付で効いてきます。定員が近づいたことを担当者が気づけるので、締切の判断を早く出せます。導入の判断としては、追加の開発をせずに済むぶん、次のApps Scriptより手前で試す価値があります。
Apps Scriptのフォーム送信トリガー
もう1つの道が、Apps Scriptで自分でスクリプトを書く方法です。公式ドキュメントには、インストール型トリガーとして「On form submit」があり、フォーム用と、回答がスプレッドシートに送られる場合のスプレッドシート用という2種類が用意されていると書かれています。インストール型トリガーの利点として「can call services that require authorization」と説明されており、認可が必要なサービスを呼べる点が挙げられています。メール送信もここに含まれます。
注意点として、公式ドキュメントにはトリガーが動かない条件も明記されています。
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. 出典: developers.google.com
スクリプトの実行やAPIのリクエストではトリガーが起動しないと書かれています。動作確認をスクリプト側からの送信で済ませようとすると、本番と違う条件で試すことになります。テストは実際にフォームの画面から送信して行ってください。
Apps Scriptで組む前に見ておく、1日の上限
Apps Scriptには公式の割り当て表があり、業務で使うなら組む前に必ず目を通しておくべき数字が並んでいます。メールの送信先の数は、消費者向けアカウントで1日100件、Google Workspaceで1日1,500件です。トリガーの総実行時間は消費者向けアカウントで1日90分、Google Workspaceで1日6時間。1回の実行時間はどちらも6分までです。外部への通信にあたるURL Fetchの回数は、消費者向けアカウントで1日20,000回、Google Workspaceで1日100,000回と記載されています。なお公式ドキュメントには、これらは予告なく変更されることがあると注記されています。
日常的な受付ではめったに当たらない数字ですが、当たるときは一気に当たります。募集の締切日、告知が広く拡散した日、公募の受付初日。こうした日に個人アカウントで運用していると、1日100件の壁に触れる可能性があります。上限に達したときにどう気づくか、届かなかった人にどう手当てするかを、組む段階で決めておいてください。
もう1つ、Apps Scriptで自動返信を組んだあとに残る負担があります。それは、書いた人しか直せないという状態です。文面を1行変えるためにスクリプトを開くことになり、その人が異動すると誰も触れなくなります。受付の担当が入れ替わる前提の組織では、この保守の重さが判断材料になります。仕組みを足すときは、作る手間だけでなく、来年も同じ人が面倒を見られるかを合わせて考えてください。
通知が誰に届くかで、受付の回り方が決まる
自動返信の設定と同じくらい、受け付けた側にどう届くかが受付の速さを決めます。ここは公式ヘルプの記載がはっきりしているので、確認しておく価値があります。
フォーム側の通知とスプレッドシート側の通知ルール
フォーム側の通知は、［回答］タブの［その他］アイコンから「新しい回答についてのメール通知を受け取る」でオンとオフを切り替えます。回答が入るたびにメールが届く形です。
スプレッドシート側にも通知ルールがあり、フォームが送信されたときに通知を受け取る設定ができます。頻度は1日1回のまとめ（Email - daily digest）か、変更のたび（Email - right away）から選べます。件数が多い受付ではまとめのほうが受信箱が荒れずに済みますが、その日のうちに返す約束をしている受付ではまとめだと遅すぎます。受付のお約束時間から逆算して選んでください。
通知を1人で受けている状態で起きること
スプレッドシートの通知ルールについて、公式ヘルプに次の記載があります。
You can only set up notifications for yourself. 出典: support.google.com
通知は自分にしか設定できないと明記されています。標準機能として複数人に通知を送る設定については、今回確認した公式資料では記載を見つけられませんでした。公式ヘルプが案内しているのは前述のForm Notificationsアドオンで、フォームのオーナーと共同編集者に回答数のしきい値で通知を送れると掲載されています。
現場でよく聞くのは、通知を受けている担当者が休んだ日に受付が止まる、という話です。転送設定で他の人にも回すという運用でしのいでいる窓口もありますが、この方法では「誰が見たか」が残らず、2人が同じ回答に返信してしまう事故につながります。問い合わせ窓口を複数人で回すときに何を決めておく必要があるかは、問い合わせの受付にまとめてあります。
通知の設計で押さえるべき点は1つです。通知は「気づくための仕組み」であって、「担当を決める仕組み」ではありません。全員に通知が飛ぶ状態は、誰も担当していない状態と同じ結果になりがちです。通知を増やす前に、誰が一次対応をするかの取り決めを先に作ってください。
自動返信を整えても残る仕事がある
自動返信を入れると受付が楽になった気がしますが、実際に減るのは最初の1通ぶんだけです。減らないもの、むしろ件数が増えると重くなるものが3つあります。
返信したかどうかが表に残らない
回答をスプレッドシートに保存すると、公式ヘルプの説明では、スプレッドシートによってデータが自動的にテーブル形式になり、形式と構造が設定されます。ただし、そこに入るのは回答者が書いた内容であって、こちら側が何をしたかではありません。「返した」「保留にした」「書類が足りないので催促した」といった対応の状態は、誰かが手で列を足して埋めない限りどこにも残りません。
自動返信は送信直後に1通出るだけなので、そのあとの往復は記録の対象外になります。控えのメールが届いていることと、担当者が中身を確認したことは別の話です。ここを同じものとして扱っていると、「返信が来ないのですが」という問い合わせを受けたときに、何が起きていたのかを再現できなくなります。
二重返信と返し忘れは仕組みの問題
返信したかどうかが表に残らない状態で複数人が対応すると、二重返信と返し忘れは必ず起きます。注意深さの問題ではなく、共有されている情報が足りていない状態の当然の帰結です。
とくに事故が起きやすいのが、メールの受信箱だけで対応を回しているときです。既読かどうかは各自の受信箱でしか分からず、他の人からは見えません。ある事務局では、返信済みのものにラベルを付ける運用を決めても、その付け外しが人によってばらつき、結局2週間で形骸化したという話が出ます。
もう1つ起きやすいのが、返信したのに相手に届いていない場合です。前述の通り、控えのメールは迷惑メール対策で届かないことがあると公式が明記しています。担当者の側に「送った」記録が残っていないと、届いていない申告があったときに再送すべきかどうかも判断できません。
状態を表す列を足すときの決め方
表計算で管理を続けるなら、最初に足すべきは対応状況の列です。ただし、状態の名前を増やしすぎると誰も正確に更新しなくなります。「未対応」「対応中」「完了」の3つから始めて、運用しながら足りないものだけ足すのが現実的です。
次に足すのが担当者の列です。誰が見るのかが1件ごとに決まっていれば、二重返信はほぼ止まります。最後に、最終連絡日の列があると、放置されている件が一目で分かります。この3列で回るうちは、表計算のままで問題ありません。回らなくなる境目は件数そのものより、担当者が2人以上になったときと、1件あたりのやり取りが2往復を超えたときです。表計算で回すやり方と、受付画面の中に状態を持つやり方の違いはGoogleフォームとの比較に整理してあり、どちらを選ぶかの判断材料になります。
回答が増えたときに効いてくる、公開されている上限
Googleフォームには、業務で使うなら知っておいたほうがよい上限が公開されています。いずれも公式ヘルプに記載があるもので、2026年9月1日時点の確認です。仕様は変わることがあるので、判断の前には最新の記載を見てください。
まず、1つのフォームに置けるコンテンツの数です。公式ヘルプには「After you've created a form, you can add and edit up to 300 pieces of content, like questions, descriptions, images, and videos.」と書かれています。設問だけでなく、説明文、画像、動画を含めた合計で300個までという意味です。同じページには、セクションは75個まで追加できるとも書かれています。設問数そのものの上限については、今回確認した公式ページには記載が見当たりませんでした。
次に、回答が増えたときに一部の機能が効かなくなる件数です。Google Workspaceのラーニングセンターに、次のように整理されています。
If certain features in your form don't work as expected, it might be because it has a large number of responses. These limits ensure Forms work reliably for all users. Your form continues to receive responses, which you can download in a CSV file. 出典: support.google.com
具体的な件数は3段階に分かれています。回答が10,000件を超えると、CSVでダウンロードした回答が送信日時順に並ばなくなること、質問別のビューと個別のビューが表示されなくなることが記載されています。50,000件を超えると回答の概要が表示されなくなり、100,000件を超えるとスプレッドシートとの同期が行われなくなります。ただし引用の通り、回答自体は受け付け続け、CSVでダウンロードできると明記されています。
この数字は、1回の募集ではまず届きません。効いてくるのは、同じフォームを何年も使い回している窓口です。問い合わせ受付のように終わりがない用途で、URLを変えたくないという理由から同一フォームを使い続けていると、数年で1万件に届くことがあります。年度ごとにフォームを分けるか、一定件数で新しいフォームに切り替えるかを、あらかじめ決めておいてください。
APIを使って外部の仕組みとつなぐ場合の上限も公開されています。Forms APIの1分あたりの読み取りリクエストはプロジェクトあたり975回、ユーザーあたり390回。書き込みリクエストはプロジェクトあたり375回、ユーザーあたり150回です。1日あたりのプロジェクト上限はいずれも無制限と記載されており、超過すると「429: Too many requests」が返ります。またAPIのリファレンスには、現時点でファイルのアップロード質問を作成できないこと、2026年6月30日以降にAPIで作成したフォームは既定で未公開の状態になることも書かれています。
書類を集めるときのアカウント要件と保存先
自動返信の話とセットで詰まりやすいのが、応募書類や見積書といったファイルを受け取る場面です。ここには公式ヘルプが明記している条件があり、受付の入口の設計を左右します。
ファイルのアップロード質問については、公式ヘルプに「To answer this question, responders need to sign in to a Google Account.」と書かれています。日本語のヘルプにも「質問に回答する際にアップロードを実行するには、Google アカウントにログインする必要があります。」と記載があります。つまり、書類を添付してもらう形にすると、回答者側にGoogleアカウントでのログインが発生します。
社内向けや、すでにアカウントを持っている前提の相手なら問題になりません。効いてくるのは、社外の不特定多数から書類を集めるときです。回答者にアカウント登録やログインを求めると、そこで手が止まる人が出ます。採用の応募受付では、この一手間が応募数に直接効きます。応募の入口をどこまで軽くするかという論点は採用の応募受付で扱っていて、受け取った書類をそのあとどう管理するかまで含めて整理してあります。
フォームの作成者側で設定できる項目もはっきり書かれています。公式ヘルプによれば、受け付けるファイルの種類、アップロードできるファイルの最大数、1つのファイルの最大サイズを指定できます。日本語のラーニングセンターにも「フォームのオーナーがファイルの数、種類、サイズの制限を設定できます。」とあります。フォーム全体で集めるファイルの合計容量を設定する項目の説明もありますが、選べる具体的な数値の一覧は、今回確認した公開資料では見当たりませんでした。
保存先については、「For the form owner, uploaded files are stored in a new folder on Google Drive.」と記載されています。アップロードされたファイルは、フォームのオーナーのGoogleドライブに作られる新しいフォルダに入ります。ドライブ側の上限として、各ユーザーが24時間以内にアップロードまたはコピーできる容量は750 GB、1ファイルは最大5 TBと公式に書かれています。ただしこのページにGoogleフォーム固有の記載は見当たりませんでした。
そのほか、公式ヘルプが明記している制約が2つあります。1つは「共有ドライブからファイルをアップロードすることはできません。」というもの。もう1つは、ファイルのアップロード質問を含むフォームはメールに埋め込めない、という記載です。案内メールの本文にフォームを埋め込んで回答率を上げたい場合、書類の添付とは両立しないことになります。
書類を受け取る受付では、自動返信の文面にも工夫が要ります。何を受け取ったかを控えに残せると、「送ったはずの書類が届いていない」という食い違いが減ります。修理やサポートのように写真を添えてもらう受付では特に効いてきます。この形の受付で必要になる項目は修理・サポートの受付に整理してあります。
締切と定員を標準機能で扱う
自動返信を整えたあと、次に問題になるのが受付の締め方です。ここは2026年1月に機能が追加されており、以前の情報と食い違うことがあるので確認しておいてください。
Googleの公式ブログには、フォームのオーナーと編集者が、フォームを閉じる日時を指定できること、あるいは一定の回答数に達したら自動的に閉じるように設定できることが書かれています。提供範囲は「Available to all Google Workspace customers, Workspace Individual subscribers, and users with personal Google accounts」と記載されており、個人のGoogleアカウントでも使えることが確認できます。提供開始はRapid Releaseドメインが2026年1月12日、Scheduled Releaseドメインが2026年1月29日です。
設定は「Accepting responses」の下にある「Set close date or response limit」から行います。日時で締め切る場合は「On a date」を選んで日時を指定し、件数で締め切る場合は「After a number of responses」を選んで上限の件数を入力します。締め切ったあとに回答者へ表示する文言も編集できます。手動で止めるなら「回答を受付中」をオフにすれば、「このフォームでは回答を受け付けていません」というメッセージが表示されます。
なお、この自動締切は既定でオフになっており、フォームを公開したあとに作成者が有効にする形だと公式ブログに明記されています。設定したつもりで有効になっていない、という取り違えが起きやすい箇所です。募集を始める前に、実際に自分でテスト送信して締切の挙動を確かめてください。
一方で、質問の選択肢ごとに定員を設ける機能、たとえば日程ごとの残席を自動で管理するような仕組みについては、今回確認した公式資料では記載を見つけられませんでした。複数の日程を1つのフォームで受け付けていて、日程ごとに定員がある場合は、この点をどう埋めるかを先に決めておく必要があります。講座の受講申し込みでこの形になることが多く、講座の受講申し込みに、日程と定員をどう持つかの考え方をまとめてあります。
締切まわりでもう1つ押さえておきたいのが、締め切ったあとに来る問い合わせです。締切直後は「間に合わなかったが受け付けてもらえないか」という連絡が必ず来ます。誰がその判断をするのか、例外を認めた場合にどこに記録するのかを決めておかないと、あとで公平性を説明できなくなります。助成金や公募のように公平性が問われる受付では、ここが最も重い論点になります。この観点は助成金・公募の受付で扱っています。
受付の道具を選び直すときに見る4つの軸
自動返信の設定を一通り確認したうえで、いまの道具のままでよいのか、それとも受付そのものの道具を見直すべきなのかを判断する材料を整理します。判断の軸は4つに絞れます。
返す文面が全員同じかどうか
これがいちばん大きな分かれ目です。全員に同じ内容を返すなら、標準の回答のコピーで完結します。区分や選択内容によって返す文面が変わるなら、アドオンかApps Scriptか、あるいは受付側で返信を書ける道具のどれかが要ります。
ここで検討を止めてしまいがちなのが、「毎回コピーして書き換えれば済む」と考えたときです。1日3件なら確かに済みます。ただし、その方法は件数が増えたときに線形に重くなり、宛先の取り違えという事故を必ず生みます。文面が2種類を超えたら、仕組みで分ける検討を始めてください。
対応の状態を残す場所があるかどうか
自動返信は「受け付けた」ところまでしか面倒を見ません。そのあと誰が担当し、どこまで進み、いつ終わったのかを残す場所が要ります。表計算に列を足して回るなら、それで足ります。回らなくなったら、状態を持つことを前提に作られた道具に移す判断になります。
判定の方法は単純です。いま未対応の件数を、開いてから5秒で言えるかどうか。言えないなら、状態が残っていません。送信されたあとを回す道具が同じ画面にそろっているかどうかが、この軸の答えになります。
複数人で受ける前提かどうか
1人で受けているうちは、どんな道具でも回ります。2人目が入った瞬間に、通知の届き先、担当の割り当て、対応履歴の共有という3つが同時に必要になります。前述の通り、スプレッドシートの通知ルールは自分にしか設定できないと公式に明記されており、複数人での受け取りは別の手段を考えることになります。
来年の担当が誰になるか分からない受付では、この軸の重みが上がります。仕組みを個人のアカウントとスクリプトに依存させると、引き継ぎの時に丸ごと止まります。会員の入会受付のように毎年続く業務では特に効いてきます。会員の入会申し込みに、続く業務で何を道具側に持たせるべきかを整理してあります。
回答者に何を求めるか
書類を受け取るならGoogleアカウントへのログインが要ること、回答を1回に制限する場合もログインが必要になることは、公式ヘルプに明記されています。回答者に何を求めるかは、集まる件数に直結します。社内の申請なら気にする必要はなく、社外からの応募や申し込みなら軽いほど有利です。施設利用の申請のように相手が決まっている受付では、むしろ本人確認ができることが利点になります。この使い分けは施設利用の申請で扱っています。
4つの軸をどう使うか
4つのうち1つでも外れているなら、まずその1つだけを埋める手を探してください。全部を一度に解決しようとして道具を入れ替えると、移行の手間が先に来て、受付が止まります。文面が変わるだけならアドオンで足りることがあり、状態が残らないだけなら列を3つ足せば済むことがあります。
そのうえで、4つのうち3つ以上が外れているなら、受付の道具そのものを見直したほうが早くなります。他の道具との違いを機能表で並べるより、この4つの軸で自分の受付を採点したほうが結論が出ます。似た検討をしている人が多いのが、社内でWordやExcelの帳票を使っている環境からの見直しで、その場合の比較はMicrosoft Formsとの比較にまとめてあります。自社サイトにフォームを埋め込んでいる場合はContact Form 7との比較が近い論点を扱っています。
判断の材料をもう少し集めたい場合は、受付側の画面で何ができると仕事が変わるのかを一覧にしたできることと、実際の画面の動きを確認できる動くところを見るが近道です。費用がどの規模から発生するのかは料金に、導入前によく出る疑問はよくある質問にまとめてあります。
最後に、個人情報の扱いについて1つ補足します。応募書類や問い合わせの内容には個人情報が含まれます。保存先がどこになるのか、誰がアクセスできるのか、いつ消すのかは、道具を選ぶ前に組織の規程と突き合わせておいてください。法律の解釈にあたる部分は、所管の窓口や専門家に確かめてください。制度の一次情報は個人情報保護委員会で確認できます。自動返信をどう組むかという技術の話より、この確認のほうが後戻りしにくい判断になります。
Q1. Googleフォームの標準機能だけで自動返信は送れますか？
メールアドレスを収集していれば送れます。［設定］の「回答」から「送信済みの回答のコピーを回答者に送信」を「リクエストされた場合」または「常に」にすると、回答者が入力した内容の控えが届きます。ただし本文をこちらで自由に書き換えられるという記載は公式ヘルプに見当たらず、公式は代わりにアドオンやApps Scriptを案内しています。
Q2. 自動返信のメールが回答者に届かないことはありますか？
公式ヘルプに、迷惑メール対策などの都合で期待した控えが届かないことがあると明記されています。届かない前提で、案内文に「控えが届かない場合はご連絡ください」と一文を添えておくのが確実です。窓口側にも送信の記録が残る形にしておくと、再送すべきかどうかの判断がすぐつきます。
Q3. Apps Scriptで自動返信を組むとき、送信数に上限はありますか？
公式の割り当て表によれば、1日に送れるメールの宛先数は消費者向けアカウントで100件、Google Workspaceで1,500件です。トリガーの総実行時間は個人で1日90分、Workspaceで1日6時間、1回の実行は6分までとされています。これらは予告なく変更されると注記されているため、運用前に最新の記載を確認してください。
Q4. 回答が増えるとGoogleフォームで使えなくなる機能はありますか？
公式ヘルプに件数ごとの記載があります。10,000件を超えるとCSVが送信日時順に並ばなくなり質問別と個別のビューが表示されなくなること、50,000件を超えると回答の概要が出なくなること、100,000件を超えるとスプレッドシートと同期されなくなることが書かれています。回答自体は受け付け続け、CSVでダウンロードできます。