Googleフォームの通知を調べている時点で、フォーム自体はもう動いています。回答は集まっている、スプレッドシートにも溜まっている、それなのに気づくのが遅れる回答がある。だから通知の設定を探しにきた、という順番のはずです。
ここで先に押さえておきたいことがあります。Googleフォームの通知の設定は難しくありません。切り替えはどちらも数クリックで終わります。それでも見落としが減らない場合、原因は設定の場所ではなく、通知が担当している範囲の外にあります。通知は「届いた」ことを知らせるところまでを担当し、「誰が対応するか」「対応したかどうか」までは担当していません。
この記事では、Googleフォームの通知でできることを公式ヘルプに書かれている範囲で整理したうえで、受付の規模が変わったときに見落としが起きる仕組みを3つに分けて説明します。受付をひとりで回している読者が、いまの手作業のどこが詰まっているのかを見極めて、次に何を変えればよいか決められる形にしています。
Googleフォームの通知は、受付の規模が変わると意味が変わる
問い合わせも応募も申し込みも、いまはほとんどがフォームから届きます。電話や紙が主だった時代と違い、届いたものは自動的に一箇所に溜まります。その意味では、受付の入口はすでに整っています。
問題は入口の先です。溜まった回答を誰かが開き、内容を読み、必要なら返信し、返信したことをどこかに記録する。この一連の作業は自動化されておらず、多くの職場で人の記憶と受信箱の並びに任されています。通知はその起点にあたる仕組みで、「いま1件届きました」と知らせる役割を持っています。
受け口が増えた分だけ、通知の宛先も増えている
ひとつの組織がフォームを使う場面は、以前より確実に増えました。採用の応募、イベントの申し込み、講座の受講、施設の利用申請、修理の受付、会員の入会。それぞれ別のフォームを作り、それぞれに通知を設定していきます。フォームが5個あれば通知の経路も5本になり、全部が同じ受信箱に流れ込みます。
この状態になると、通知そのものが受信箱を埋める側に回ります。1日に届く件数が少ないうちは目印として機能していたメールが、件数が増えると背景になります。通知を切りたくなる担当者が出てくるのはこの段階です。切ってしまえば見落としは増えますが、切らなければ他のメールが埋もれます。どちらを選んでも困る形になっているなら、通知の設定ではなく受け口の設計を見直す時期に来ています。
通知が担当しているのは「届いたこと」までである
通知メールが伝えるのは、新しい回答が来たという事実です。伝えていないのは、その回答を誰が見るのか、すでに誰かが見たのか、返信したのかどうかです。受付をひとりで回しているうちは、この3つが全部同じ人の頭の中にあるので問題になりません。人が増えた瞬間、あるいは休みが入った瞬間に、頭の中にしかなかった情報が消えます。
見落としを減らしたい人が最初に検討するのは、たいてい通知の頻度と宛先です。頻度を上げれば気づきやすくなり、宛先を増やせば誰かが気づく確率が上がる。この発想は間違っていませんが、上限があります。届いたことを何度知らせても、対応の状態は記録されないからです。誰が担当していて、いまどこまで進んでいるかが一覧に残る形にして初めて、見落としは構造として減ります。
Googleフォームの通知でできること
まず、公式ヘルプに書かれている範囲で通知の機能を整理します。ここで扱うのは、フォーム側のメール通知、スプレッドシート側の通知ルール、回答者への回答のコピー、そして公式が案内しているアドオンの4つです。すべて2026年9月1日時点でGoogle公式のヘルプに記載されている内容です。
フォーム側のメール通知
いちばん基本の設定です。フォームを開いて［回答］タブに移り、［その他］のアイコンから「新しい回答についてのメール通知を受け取る」を選ぶと、オンとオフを切り替えられます。オンにしておけば、回答が送信されたときにメールが届きます。
設定はこれだけです。項目の絞り込みも、条件の指定も、送信先の追加も、この画面には出てきません。受付をひとりで回していて、届いたら自分が開くという運用なら、これで足ります。切り替えの場所を覚えておくだけで済むという意味では、むしろ扱いやすい設計です。
参照したのは Googleドキュメント エディタ ヘルプの 回答の設定に関するページ です。
スプレッドシート側の通知ルール
回答をスプレッドシートに保存している場合、スプレッドシート側にも通知の仕組みがあります。フォームが送信されたときに通知を受け取る設定があり、頻度は「Email - daily digest」（1日1回のまとめ）と「Email - right away」（変更のたび）から選べます。
まとめて受け取る形は、件数が多い受付で受信箱が埋まるのを防げます。逆に、その日のうちに返す約束をしている窓口では、まとめでは間に合いません。ここは受付の性質で決める部分です。
この通知ルールには、受け取る相手について公式ヘルプに明確な記述があります。
You can only set up notifications for yourself. 出典: support.google.com
自分にしか設定できない、と書かれています。つまり同じスプレッドシートを共有している別の担当者に、こちらの操作で通知を届けることはできません。相手が自分でその設定を開いて、自分向けに通知をオンにする必要があります。ここが後の章で扱う「宛先がひとりに寄る」の出発点になっています。
回答者に回答のコピーを送る
受付側に届く通知とは別に、回答した人へ控えを送る機能もあります。メールアドレスを収集している場合に設定でき、手順はフォームを開いて上部の［設定］に入り、「回答」の横の下向き矢印を開いて「送信済みの回答のコピーを回答者に送信」から「リクエストされた場合」または「常に」を選ぶ形です。
送るかどうかは受付の性質で決まります。応募や申請のように、送った側が「ちゃんと届いたか」を気にする受付では、控えがあるだけで問い合わせが減ります。一方で、控えの送信については公式ヘルプに次の注記があります。
In certain circumstances, responders may not receive the expected response receipts due to spam filters or other counter-abuse measures. 出典: support.google.com
迷惑メールの対策によって、控えが届かないことがあると明記されています。控えを送る設定にしていても、届かなかった人からの「送信できているか分かりません」という連絡は起こりうる、と見込んでおくのが現実的です。
なお、本文を自由に書き換えた自動返信メールを標準機能で送れるという記載は、今回確認した公式ページの範囲では確認できませんでした。公式ヘルプはこの用途について、後述のアドオンを案内しています。
複数人に通知したい場合に公式が案内しているもの
複数の担当者に通知を送りたい、という要望は受付が2人以上になった時点で必ず出ます。標準機能として複数人に通知を送る設定は、今回確認した公式資料の範囲では確認できませんでした。公式ヘルプが案内しているのは Form Notifications というアドオンです。
Google Workspace Marketplace の掲載内容によると、提供元はGoogle、価格は無料です。内容は、回答者が送信したときに届くメールを設定できること、そしてフォームのオーナーと共同編集者に対して、あらかじめ決めた回答数のしきい値に達したときに届くメールも設定できること、と書かれています。
ここで押さえておきたいのは、しきい値による通知は「10件溜まりました」を知らせる仕組みであって、1件ごとに担当を割り振る仕組みとは役割が違うという点です。募集の集まり具合を把握したい場面には合いますが、1件ずつ確実に処理したい受付では、届いた事実の共有までで止まります。
ひとりで受けているうちは、標準の通知で足りる
先に結論を書いておきます。受付をひとりで担当していて、1日に届く件数が数件で、返信の期限が緩やかであれば、Googleフォームの標準の通知で足ります。無理に仕組みを足す理由はありません。
理由は3つあります。ひとつめは、宛先がひとりに寄っても困らないことです。自分にしか通知が設定できないという制約は、受ける人が自分ひとりなら制約になりません。ふたつめは、対応の記録が受信箱で足りることです。返信済みかどうかは、自分の送信済みフォルダを見れば分かります。3つめは、引き継ぎが発生しないことです。誰がどこまでやったかを他人に伝える必要がないので、記録の形式を決めなくても回ります。
この状態でツールを増やすと、かえって手間が増えます。管理画面が2つになり、確認する場所が2箇所になり、設定の維持に時間が取られます。受付の道具は、詰まっている場所が見えてから足すほうが失敗しません。
では、いつ足りなくなるのか。境目になるのは件数そのものより、次の3つのどれかが起きたときです。受ける人が2人以上になった。返信の期限が決まった。担当を交代する予定が入った。このどれかに当てはまったら、以降の章で書く3つの仕組みが順に効いてきます。当てはまらないうちは、いまの設定のままで問題ありません。
Googleフォームで受ける形と、届いたあとの管理まで含めた形の違いはGoogleフォームとの比較にまとめています。この記事も、まずGoogleフォームで足りる場合を先に書いた構成にしています。
見落としが起きる仕組み1：通知の宛先がひとりに寄る
受ける人が2人以上になった瞬間に効いてくるのが、この仕組みです。
スプレッドシート側の通知ルールは、公式ヘルプに「自分にしか設定できない」と明記されています。フォーム側のメール通知も、オンにするとその操作をした人に届く形です。つまり通知は、設定した人のところに集まります。
現場で起きるのは次のような流れです。最初にフォームを作った人が通知をオンにする。その人の受信箱に全部届く。もうひとり担当が増えたとき、その人にも通知を届けたくなる。しかしこちらの操作では届けられないので、相手に「スプレッドシートを開いて、自分で通知の設定をしてください」と伝えることになります。伝え忘れる、あるいは相手が設定の場所を見つけられずそのままになる、という止まり方をします。
結果として、通知はフォームを作った人のところにだけ届き続けます。その人が休んだ日、あるいは別の業務で受信箱を開けなかった日に、届いた回答は誰の目にも触れません。転送設定を作って回避する方法もありますが、転送された側は「これは自分が対応すべきものか」を判断する材料を持っていないので、両方が相手を待つ状態が生まれます。
共同編集者を増やせば解決するかというと、通知については別の話になります。共同編集者に招待した人は、公式ヘルプによれば「回答、回答の保存場所など、フォームのどの部分でも編集できます」とされています。編集の権限は共有されますが、通知の宛先が自動で共有されるという記載は、今回確認した範囲では確認できませんでした。編集できることと、届いたことを知らされることは、別に設計されていると考えたほうが実態に合います。
複数人で受けるなら、通知の宛先を増やすより先に決めるべきことがあります。届いたものを最初に見る人を決めることです。宛先を全員に増やすと、全員が「誰かが見ているだろう」と考えて誰も見ない状態になります。1件ごとに担当者が入っている状態を作れるかどうかが、宛先の数より効きます。
見落としが起きる仕組み2：通知が受信箱の中で流れる
宛先の問題を解決しても、次に受信箱の問題が来ます。
通知メールは、他のメールと同じ受信箱に届きます。取引先からの連絡、社内の共有、広告、システムの自動送信。それらと同じ列に並び、時系列で下に流れていきます。1日に届くメールが30通なら通知は目立ちますが、200通になると背景に沈みます。
ここで起きる見落としには、いくつか決まったパターンがあります。
ひとつは、朝にまとめて処理する運用で起きます。夜のうちに届いた通知を朝に開き、上から順に対応していく。途中で電話が入って中断し、戻ってきたときに「どこまで対応したか」を思い出せない。既読になっているメールが、読んだだけなのか対応済みなのか区別できません。
ふたつめは、まとめ通知を選んでいる場合に起きます。1日1回のまとめは受信箱が埋まらない利点がありますが、まとめメールを1通見落とすと、その中に入っていた複数件が丸ごと落ちます。1件ずつ届く形なら1件の見落としで済むところが、まとめでは被害が広がります。
3つめは、フィルタで整理している場合に起きます。受信箱が荒れるのを避けるため、通知に自動でラベルを付けて別のフォルダへ振り分ける。整理はされますが、振り分け先を開く習慣がないと、そのフォルダごと見なくなります。振り分けは見た目を整える効果はありますが、見る習慣を作る効果はありません。
4つめは、迷惑メール判定です。控えの送信について公式が迷惑メール対策で届かないことがあると明記しているのと同じで、受付側に届く通知も経路の途中で振り分けられる可能性はゼロではありません。届いていないことに気づくきっかけが通知だけしかない設計は、この点で弱くなります。
共通しているのは、受信箱が「未処理の一覧」として設計されていないことです。メールは届いた順に並ぶ入れ物であって、対応の状態を持つ入れ物ではありません。未読と既読の2状態しかないので、「見たが返していない」「返したが返事待ち」「対応不要と判断した」を区別できません。この区別が必要になった時点で、受信箱では足りなくなります。
見落としが起きる仕組み3：通知が届いても担当が決まらない
3つめが、いちばん見つけにくい仕組みです。
通知が全員に届いていて、全員が受信箱を開いていても、見落としは起きます。誰が対応するかが決まっていないからです。
窓口の担当者からしばしば出るのは、次のような話です。応募が1件届き、通知が3人に届く。3人とも内容を読む。3人とも「これは自分の担当ではないかもしれない」と考える。判断がつかないまま数日が過ぎ、応募者から「返信をいただけていないのですが」と連絡が来て初めて気づく。全員が見ているのに、全員が動いていない状態です。
逆のパターンも起きます。3人のうち2人が同時に対応を始め、同じ応募者に別々の内容で返信してしまう。二重返信は、返し忘れより印象が悪くなります。受け取った側からは、社内で情報が共有されていないことがはっきり見えるからです。
この2つは、どちらも同じ原因から出ています。1件ごとの担当が、届いた時点で決まっていないことです。通知は届いたことを知らせますが、誰の仕事かは知らせません。返信したかどうかも記録しません。だから返信したかどうかが表に残らないと、二重返信と返し忘れは必ず起きます。
対処として現場でよく使われるのが、スプレッドシートに列を足す方法です。回答が並んでいる表の右端に「担当」「対応状況」「返信日」といった列を作り、手で埋めていきます。これは有効な一手で、しばらくは回ります。ただし、いくつか気をつける点があります。
まず、フォーム側の設問を追加・削除・並べ替えしたときに、連携済みスプレッドシートの列がどうなるかは、今回確認した公式資料の範囲では確認できませんでした。手で足した列と、フォームが自動で書き込む列が同じシートに同居している構造なので、フォームの構成を変えるときは慎重に進める必要があります。
次に、共同編集者の権限の広さです。公式ヘルプによれば、共同編集者は回答や回答の保存場所を含めてフォームのどの部分でも編集できます。回答用のスプレッドシートについても、新しく作られたときは共同編集者が自動でアクセスできる一方、「その後のフォームの権限の変更は自動では同期されない」と書かれています。人の入れ替わりがある職場では、誰がどこまで触れる状態なのかを定期的に確かめておいたほうが安全です。
そして最大の弱点は、手で埋める列は埋め忘れるということです。忙しい日ほど、返信を先にして記録を後回しにします。後回しにした記録は、その日のうちには埋まりません。記録が実態からずれ始めた表は、次第に誰も見なくなります。
通知を厚くする前に、公開されている上限を見ておく
通知の設計を変える前に、Googleフォーム側で公開されている上限を確認しておくと判断が早くなります。ここに挙げるのはすべて公式ページに書かれている数字で、確認日は2026年9月1日です。仕様は変わりうるので、実際に運用へ入れる前には最新の記載を確かめてください。
回答の件数で効かなくなる機能
Google Workspace ラーニング センターに、回答数が増えたときの挙動が明記されています。
回答が10,000件を超えると、CSVでダウンロードした回答が送信日時順に並ばなくなり、質問別のビューと個別のビューが表示されなくなります。50,000件を超えると、回答の概要が表示されなくなります。100,000件を超えると、スプレッドシートとの同期が行われなくなります。
同じページには「これらの制限は、すべてのユーザーがフォームを確実に使えるようにするためのもの」という趣旨の説明と、上限を超えても回答自体は受け付け続け、CSVでダウンロードできる、という補足があります。詳細はGoogle Workspace ラーニング センターの該当ページで確認できます。
通知の話に引き寄せると、効いてくるのは同期の停止です。スプレッドシート側の通知ルールは、スプレッドシートに変更があったことを起点にしています。同期が止まればその起点が消えます。単年の受付で到達する数字ではありませんが、複数年にわたって同じフォームを使い続ける窓口では、いつか届く可能性のある数字です。
なお、1つのフォームに置けるコンテンツは合計300個まで（設問、説明文、画像、動画の合計）、セクションは75個までと公式ヘルプに書かれています。設問だけの上限は、今回確認した範囲では確認できませんでした。
ファイルのアップロードを含む受付の場合
書類を受け取る受付では、通知より先に効いてくる条件があります。公式ヘルプによれば、ファイルのアップロード質問に答えるには、回答者がGoogleアカウントにログインする必要があります。社外の不特定多数から書類を集める用途では、ここで応募をやめる人が出ます。
あわせて押さえておく点として、共有ドライブからのファイルアップロードはできないこと、ファイルのアップロード質問を含むフォームはメールに埋め込めないことが公式に書かれています。アップロードされたファイルは、フォームのオーナーのGoogleドライブに新しく作られるフォルダへ保存されます。ドライブ側の上限としては、1ユーザーが24時間にアップロードまたはコピーできるのは750GB、1ファイルは最大5TBと記載されています。
フォームの作成者側で設定できるのは、受け付けるファイルの種類、1回の回答でアップロードできるファイルの数、1ファイルの最大サイズです。フォーム全体で集める合計容量を設定する項目の説明もありますが、選べる具体的な数値は今回確認した公開資料では確認できませんでした。
Apps Script で自動返信や転送を組む場合
標準の通知で足りないとき、次に検討されるのが Apps Script です。インストール型トリガーに「On form submit」があり、フォーム用と、回答がスプレッドシートに送られる場合のスプレッドシート用の2種類が用意されています。インストール型トリガーの利点として、認可が必要なサービスを呼び出せる点が公式ドキュメントに挙げられています。
ここで先に見ておきたいのが、1日の割り当てです。公式の割り当て表には次の数字が載っています。1日に送れるメールの宛先数は、消費者向けアカウントで100件、Google Workspace で1,500件。トリガーの総実行時間は、消費者向けアカウントで1日90分、Google Workspace で1日6時間。1回の実行時間はどちらも6分です。これらの数字には「予告なく変更されることがある」という注記が付いています。
もうひとつ、運用で引っかかりやすい仕様があります。スクリプトの実行やAPIのリクエストではトリガーが動かない、と公式ドキュメントに明記されています。例として、FormResponse.submit() で新しい回答を送信してもフォームの送信トリガーは動かない、と書かれています。テストのためにプログラムから回答を投入しても、本番と同じ流れを再現できない場合があるということです。
Forms API 側の制限も参考までに挙げておくと、読み取りリクエストはプロジェクトあたり1分間に975回、書き込みは375回で、超過すると429が返ります。1日あたりのプロジェクト上限は無制限と記載されています。またAPIでは現時点でファイルのアップロード質問を作成できないこと、2026年6月30日以降にAPIで作成したフォームは既定で未公開の状態になることも公式に書かれています。
Apps Script は自由度が高く、宛先を複数にすることも、条件で振り分けることも、本文を書き換えることもできます。その代わり、書いた人しか直せない仕組みが職場に1つ増えます。書いた人が異動したときに誰も触れなくなる、という止まり方は、現場でよく聞く話です。作る前に、誰が保守するのかを決めておいてください。
通知の設計で先に決めておく5つのこと
通知を足すか、道具を変えるかを判断する前に、次の5つを決めておくと迷いが減ります。どれもツールに依存しない項目で、決めた内容がそのまま選ぶ基準になります。
1つめは、届いたものを最初に見る人です。全員ではなく、ひとりに決めます。全員が見る設計は、全員が見ない設計とほぼ同じ結果になります。最初に見る人を決めたうえで、その人が休む日の代理も一緒に決めておきます。
2つめは、返信までの期限です。当日中なのか、翌営業日なのか、3営業日以内なのか。期限が決まっていない受付では、遅れているかどうかを誰も判断できません。期限が決まると、通知をまとめて受けてよいのか、その都度受けるべきなのかも自動的に決まります。
3つめは、対応の状態をどこに残すかです。受信箱の未読と既読では足りない、と判断したなら、その次の置き場所を決めます。表計算ソフトの列で足りるのか、それとも受付から対応の完了までが同じ画面で追える形が必要なのか。ここは受付の件数と関わる人数で変わります。
4つめは、返信の記録を残すかどうかです。誰が、いつ、どういう内容で返したのかが残らないと、引き継ぎのたびに同じ質問を繰り返すことになります。応募者や申請者から「前にお伝えした件ですが」と言われたときに、こちらが把握していない状態を作らないための項目です。
5つめは、個人情報の扱いです。フォームで集めた氏名や連絡先を、どの範囲の人が見られる状態にするか、いつまで保管して、いつ消すか。Googleフォームでは共同編集者がフォームのどの部分でも編集できると公式に書かれているので、権限を渡す範囲は慎重に決める必要があります。個別の取り扱いが法令上どう評価されるかについては、個人情報保護委員会の情報を確認したうえで、所管の窓口や専門家に確かめてください。
この5つを決めると、通知に何を期待していたのかがはっきりします。多くの場合、期待していたのは「気づけること」ではなく「落ちないこと」です。その2つは別の仕組みで支えられています。
通知を増やすより、受け口の形を変えたほうが効く場面
ここまでを踏まえて、Googleフォームの通知で足りる場面と、受け口の形そのものを変えたほうが早い場面を整理します。
足りるのは、受ける人がひとりで、返信の期限が緩やかで、担当の交代が当面ない受付です。この条件なら、フォーム側のメール通知をオンにするだけで運用できます。設定が単純である分、壊れる場所も少なくなります。
足りなくなるのは、受ける人が2人以上になったとき、返信の期限が決まっているとき、そして担当を交代する予定があるときです。この3つのどれかが入ると、通知の宛先を増やしても、頻度を上げても、見落としの原因は残ります。原因が通知の外にあるからです。
受け口の形を変えるとは、届いた1件ごとに担当と状態が付く形にするという意味です。誰が担当なのかが一覧で分かり、返信済みかどうかが記録として残り、期限が近いものが分かる。この3つがそろうと、通知は「気づくための手段」から「確認のための補助」に役割が変わります。通知を見落としても、一覧を開けば未対応が残っていることが分かるからです。送信されたあとに使う道具がそろっているかどうかが、実際の作業量を決めます。
受付の形ごとに、どこで詰まりやすいかは変わります。採用の応募受付では、書類の確認と選考の進み具合を追う必要があるので、通知だけでは早い段階で足りなくなります。想定される流れは採用の応募受付にまとめています。助成金や公募の受付では、締切と不備の差し戻しが加わります。要件の確認から連絡までの流れは助成金・公募の受付にあります。
問い合わせの受付は、二重返信と返し忘れが最も起きやすい入口です。担当の決め方と返信の記録の残し方を問い合わせの受付で整理しています。イベントや講座は定員という要素が加わるので、締切の管理と当日までの連絡が中心になります。それぞれイベントの申し込みと講座の受講申し込みにまとめました。施設の利用申請は日程の調整まで含むため施設利用の申請、修理やサポートの受付は対応の完了まで追う形なので修理・サポートの受付、会費の案内まで続く入会の受付は会員の入会申し込みがそれぞれ近い形です。
独自データ考察：通知の設定は入口、詰まるのはその先
受付の相談を整理していくと、通知の設定そのものが原因だった例はそれほど多くありません。設定は正しく、通知も届いていて、それでも落ちる。落ちている場所は、通知が届いたあとの数分間から数日間にあります。
この区間で起きていることを分解すると、判断が3回あります。1回目は「これは自分が対応するものか」。2回目は「いま対応するのか、後にするのか」。3回目は「対応が終わったことをどこに残すか」。通知はこの3つのどれにも答えません。答えを人の記憶に置いている限り、忙しい日には必ず抜けます。
だからこそ、通知を厚くする前に、いまの受付でこの3つの判断がどこで行われているかを書き出してみることをすすめます。書き出せない項目があれば、そこが詰まっている場所です。書き出せるなら、いまの仕組みで回っているということなので、無理に変える必要はありません。
現在の道具と比べて何が変わるのかを見たい場合は、Googleフォームとの比較に、フォームで集めるところまでと、集めたあとを回すところの違いを整理してあります。サイトにプラグインを入れて受けている形からの検討ならContact Form 7との比較、社内のアカウントで運用している形からの検討ならMicrosoft Formsとの比較がそれぞれ近い比較になります。どの記事も、いまの道具で足りる場合を先に書く構成にしています。
届いたあとに何ができるのかを具体的に確かめたい場合はできることに一覧があり、実際の画面の動きは動くところを見るで確認できます。費用の考え方は料金に、導入前に多い疑問はよくある質問にまとめています。
最後にもう一度、順番だけ確認しておきます。通知の設定を見直すのは、受ける人がひとりのうちだけで済みます。2人以上になったら、通知の宛先を増やす前に、最初に見る人と対応の記録の置き場所を決めてください。その2つが決まっていれば、通知はどの形でも機能します。決まっていなければ、通知をいくら増やしても見落としは減りません。
Q1. Googleフォームの通知はどこで設定しますか？
フォームを開いて［回答］タブに移り、［その他］のアイコンから「新しい回答についてのメール通知を受け取る」でオンとオフを切り替えます。回答をスプレッドシートに保存している場合は、スプレッドシート側にも通知ルールがあり、1日1回のまとめか変更のたびかを選べます。どちらも数クリックで切り替えられます。
Q2. 複数の担当者に通知を届けることはできますか？
スプレッドシートの通知ルールについて、公式ヘルプには自分にしか設定できないと明記されています。複数人に通知を送る標準機能は、今回確認した公開資料では確認できませんでした。公式ヘルプが案内しているのはGoogle提供の無料アドオン Form Notifications で、オーナーと共同編集者に回答数のしきい値で通知を送れると掲載されています。
Q3. 通知をオンにしているのに見落としが起きるのはなぜですか？
通知が担当しているのは、届いたことを知らせるところまでだからです。誰が対応するか、すでに対応したかどうかは通知に含まれません。受信箱は未読と既読の2状態しか持たないため、見たが返していない状態を区別できません。1件ごとに担当と対応状況が残る形にしないと、原因は残り続けます。
Q4. 回答が増えると通知や集計に影響しますか？
公式ヘルプによると、回答が10,000件を超えるとCSVが送信日時順に並ばなくなり質問別ビューが表示されなくなります。50,000件で回答の概要が、100,000件でスプレッドシートとの同期が行われなくなります。同期が止まるとスプレッドシート側の通知ルールも起点を失います。回答自体は受け付け続け、CSVで取得できます。