Googleフォームを複数人で使う｜誰が返信したか分からなくなる前に

「google フォーム 共同編集」で調べる人の多くは、フォームを一緒に作りたいところで詰まっているわけではありません。共同編集そのものは共有ボタンから数十秒で終わります。詰まるのはその先、届いた回答を複数人で受けて返すところです。二人目が入った瞬間に、誰がどれに返信したのかが誰にも見えなくなる。この記事では、共同編集で渡る権限の範囲を公式資料で確認できる線まで整理したうえで、受付を複数人で回すときに先に決めておくべきこと（担当の決め方、返信済みの印、記録の置き場）を具体的に置いていきます。

先に結論を置きます。編集を分担するだけなら、共同編集の機能で足ります。乗り換える理由はありません。困るのは、編集ではなく対応を分担しはじめたときです。この境目がどこにあるのかを見極めることが、次に何を変えるかを決める材料になります。

共同編集でできることと、それで足りる場面

共同編集の追加手順は公式ヘルプに明記されています。フォームの共有をクリックし、相手の名前やグループを入力し、下向き矢印から編集者を選ぶ。これだけです。追加された人は、フォームの設問を足したり、文言を直したり、締切を設定したりできます。

権限の範囲についても公式の記載があります。Google Workspace ラーニング センターには「招待したユーザーは、回答、回答の保存場所など、フォームのどの部分でも編集できます」と書かれています。つまり共同編集者は、設問だけを触れる限定的な立場ではなく、回答そのものと保存先まで含めてフォーム全体に手が届く立場です。ここは共有する前に理解しておく必要があります。

共同編集者に渡るのは「フォームのどの部分でも」

編集者として招いた相手は、設問の追加や修正だけでなく、回答の保存場所の変更にも手が届きます。応募書類や問い合わせの内容が入っているフォームで、部分的な権限を渡すつもりで編集者にすると、意図した以上の範囲を渡していることになります。

これは欠陥ではなく設計です。フォームは本来、作る道具として作られています。作る側が全員同じ権限を持つのは、資料を共同で作るときの自然な形です。受付の窓口として使うときに、この前提が実務と少しずれる、というだけの話です。

対策としては、招く相手を「フォームの中身に責任を持つ人」に限る、という線引きが現実的です。回答を見て返信するだけの人まで編集者にする必要はありません。回答用のスプレッドシートを閲覧できるようにすれば足りる場面は多くあります。

回答用スプレッドシートの権限は別に動く

ここが実務で最も引っかかるところです。公式ヘルプには次の二つが並べて書かれています。

When you create a new response spreadsheet, form collaborators automatically get access to it. Further changes to the permissions of the form won't synchronize automatically. 出典: support.google.com

新しく回答用スプレッドシートを作ったときは、そのときの共同編集者に自動でアクセス権が渡ります。ただし、そのあとフォーム側の権限を変えても、スプレッドシート側には自動では反映されません。

この一文が意味することは、運用上けっこう重いものです。あとから加わった担当者は、フォームの共同編集者にしただけでは回答のスプレッドシートを開けない可能性があります。逆に、担当を外れた人をフォームの共同編集者から外しても、スプレッドシート側の権限は残ったままになり得ます。人の入れ替わりがある窓口では、この二重管理を誰かが覚えておかなければなりません。

引き継ぎのときに確認する項目としては、次の二つを並べて書いておくのが確実です。フォームの共有設定と、回答用スプレッドシートの共有設定。片方だけ直して終わりにすると、見えるはずの人が見えない、見えないはずの人が見える、という状態が静かに続きます。

編集を分担するだけなら、これで足りる

ここまで書いたうえで、はっきりさせておきます。設問を一緒に作る、文言を直し合う、締切を設定する。この範囲であれば、共同編集の機能で十分に回ります。ファイルはドライブに保存され、複数人が同時に開いても編集が競合しません。追加費用もかかりません。

「google フォーム 共同編集」で調べて、目的が「二人で設問を作りたい」であれば、この記事の残りは読まなくても大丈夫です。共有から編集者を追加してください。それで終わります。

問題が出るのは、共同編集を「対応の分担」にそのまま延長したときです。次の章から、その構造を分解します。

受付を複数人で回すと、なぜ誰が返信したか分からなくなるのか

一人で回しているうちは、返信済みかどうかは自分の頭とメールの送信済みフォルダの中にあります。それでも回ります。二人目が入った瞬間に、この二つが共有されていないことが表面化します。

窓口の担当者からしばしば出るのは、「同じ応募者に二人から返信が飛んだ」「逆に、相手が返信したと思って誰も返していなかった」という話です。どちらも個人の不注意ではなく、道具の構造から必ず出てくる事象です。理由は三つあり、それぞれ独立しています。

通知は自分にしか設定できない

スプレッドシート側の通知ルールについて、公式ヘルプは明確に書いています。

You can only set up notifications for yourself. 出典: support.google.com

通知ルールは自分にしか設定できません。頻度は1日1回のまとめか、変更のたびに届くかの二択です。フォーム側にも「新しい回答についてのメール通知を受け取る」という設定がありますが、これも設定した本人が受け取るものです。

複数人に通知を送る標準の設定は、今回確認した公式資料の範囲では確認できませんでした。機能が無いという意味ではなく、公式ページに記載が見当たらなかった、という意味です。公式ヘルプが案内しているのは Form Notifications というアドオンで、こちらは後述します。

通知が各自の設定になっているということは、誰が新着に気づいたかがチーム側から見えないということです。気づいた人が動くという運用は、全員が気づいたときに二重対応になり、全員が「他の誰かが気づいただろう」と思ったときに放置になります。

表に「返信したか」の列が最初から無い

回答をスプレッドシートに保存すると、データは自動的にテーブル形式になります。ここに入るのは、回答者が入力した内容です。対応状況の列は、当然ながら最初から用意されていません。

なお、回答が1件につき1行ずつ追加されるのか、タイムスタンプの列がどう入るのかといった具体的な挙動については、今回確認した公式資料の範囲では確認できませんでした。実際の画面で確かめてから、運用の前提にしてください。

対応状況を管理したいなら、列を自分で足すことになります。ここで気をつけるべきなのは、フォーム側で設問を追加・削除・並べ替えしたときに、連携済みスプレッドシートの列がどうなるかも、公開資料では確認できなかった点です。手で足した列がどう扱われるかを、本番の受付が始まる前に小さく試しておく価値があります。

返信は各自のメールソフトから出ていく

三つ目が一番効きます。フォームは受け取る道具であって、返す道具ではありません。返信は各担当者が自分のメールソフトを開いて、自分のアドレスから送ります。

つまり、送信の記録は各自の送信済みフォルダの中にあります。表にも、フォームにも残りません。「返信したかどうか」を確かめるには、誰かのメールボックスを開くしかない。この時点で、チームで共有できる事実が存在しない状態になっています。

現場では、この構造を「返信の履歴が人に紐づいてしまう」と表現することがあります。担当者が休んだ日、退職した日に、その人が何を返したのかを追えなくなるのは、この紐づき方が原因です。

複数人で受ける前に決めておく3つのこと

道具を変えるかどうかとは別に、決めておけば今日から効くことがあります。逆に言えば、これを決めずに人を増やすと、どんな道具を使っても同じ混乱が起きます。

担当の決め方

最初に決めるのは、届いた1件を誰が持つかのルールです。よくある決め方は次の三つです。

・当番制：曜日や時間帯で担当を割り当てる。件数が読める窓口に向く ・内容で分ける：応募か問い合わせか、地域か案件かで振り分ける。設問に振り分け用の項目を入れておくと機械的に決まる ・先着で取る：気づいた人が取り、取ったことを表に書く。少人数で反応が速いチームに向く

どれを選んでも構いませんが、決めていない状態を続けないことだけが重要です。担当の決め方が無いチームでは、忙しい人ほど「誰かがやるだろう」と判断し、真面目な人ほど二重に返信します。

振り分け用の項目をフォームに足す場合、1つのフォームに置けるコンテンツは合計300個まで、セクションは75個までという上限が公式ヘルプに書かれています。コンテンツには設問だけでなく説明文・画像・動画も含まれるため、長いフォームでは意外と早く効いてきます。

返信済みの印

次に決めるのが、対応が終わったことをどこに記録するかです。スプレッドシートを使うなら、最低限このあたりの列を足すことになります。

列を足すこと自体は5分で終わります。難しいのは、全員が必ず書く状態を作ることです。表に書くのを忘れると、その1件は「誰も返していない件」と区別がつかなくなります。返信した直後に書く、というタイミングまで含めて決めておかないと、書く人と書かない人に分かれます。

現場では、状態の選択肢を増やしすぎると誰も更新しなくなると言われています。最初は未対応と完了の2つだけにして、足りなくなってから増やすほうが定着します。

記録の置き場

三つ目が、やり取りそのものをどこに残すかです。返信の本文、添付、電話で話した内容。これらが各自のメールボックスに散っている限り、引き継ぎのたびに転記が発生します。

置き場の候補は現実的には次のとおりです。共有のメールアドレス（info@ など）を作って全員がそこから返す、スプレッドシートのメモ欄に要点だけ書く、あるいは送信されたあとを回す道具がそろっている受付システムに移す。どれを選ぶかは件数と人数で決まります。

ここで判断材料になるのが、その1件を開いたときに、これまでのやり取りが全部見えるかという一点です。見えないなら、誰かが記憶で補っています。記憶で補える件数には限りがあり、その限界が来たときに取りこぼしが起きます。

標準機能とアドオンで、どこまで埋められるか

道具を変える前に、いま使っているもので埋められる範囲を確認しておきます。ここを飛ばして乗り換えを検討すると、実は要らなかった、ということが起こります。

回答のコピーとメール通知

回答者に「送信済みの回答のコピー」を送る設定は標準で用意されています。メールアドレスを収集している場合に、設定から回答の横の下向き矢印を開き、リクエストされた場合か常にかを選びます。

ただし、公式ヘルプはこの機能について注意書きを添えています。

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

迷惑メール対策によって、期待どおりに届かないことがあると公式が明記しています。受付完了の連絡が届いたかどうかを前提にした運用（届かなければ再送する、など）を組む場合は、この前提を頭に入れておく必要があります。

本文を自由に書き換えた自動返信を標準機能で送れるという記載は、公開資料では確認できませんでした。公式ヘルプは代わりにアドオンを案内しています。

Form Notifications アドオン

公式ヘルプが案内しているのは Form Notifications というアドオンです。Google Workspace Marketplace の掲載によれば、提供元は Google、価格は無料です。回答者が送信したときに届くメールを設定でき、フォームのオーナーと共同編集者に対して、あらかじめ決めた回答数のしきい値に達したときに届くメールも設定できると書かれています。

複数人で受けるという文脈では、共同編集者にも通知が届く点が効きます。ただし届くのは通知であって、誰が対応したかの記録ではありません。全員に同じ通知が届くということは、全員が同時に動ける状態になるということでもあります。担当の決め方を先に決めておかないと、通知を増やしたぶんだけ二重対応が起きやすくなります。

Apps Script で組む場合の上限

もう一段踏み込んで、Apps Script で自動返信や振り分けを組む選択肢もあります。インストール型トリガーには「On form submit」があり、フォーム用と、回答がスプレッドシートに送られる場合のスプレッドシート用の2種類が用意されています。認証が必要なサービスを呼べるのがインストール型トリガーの利点として書かれています。

ここで先に確認しておくべきなのが、割り当ての上限です。公式の割り当て表には次の数値が載っています。

個人アカウントで組むと、自動返信のメールは1日100件で止まります。Google Workspace でも1日1,500件です。募集の締切前に応募が集中する採用や公募では、この数字が現実的な制約になります。なお、これらの数値は「subject to change without notice」と注記されており、予告なく変わり得るものとして扱う必要があります。

もう一つ注意しておきたいのが、スクリプトからの操作ではトリガーが動かない点です。公式には「Script executions and API requests don't cause triggers to run.」と書かれています。テストのためにスクリプトから回答を投げても、送信トリガーは走りません。動作確認は実際のフォームから送信して行う必要があります。

自動化を組む場合、作った人が異動したあとに誰が保守するのかも、先に決めておくべき項目です。スクリプトは動いているうちは見えませんが、止まったときに中身を読める人がいないと、原因を追うところから始まります。

件数が増えたときに何が起きるか

受付の道具を選ぶとき、件数の見通しは重要な判断材料です。公式は、回答が増えたときに一部の機能が効かなくなる件数を明記しています。

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

具体的な件数は次のとおりです。

重要なのは、上の引用が明言しているとおり、回答の受け付け自体は止まらないことです。100,000件を超えても回答は入り続け、CSV でダウンロードできます。止まるのは画面上の集計や同期です。

年に一度の応募受付や、数百件規模の問い合わせであれば、この数字に到達することはまずありません。ここに引っかかるのは、フォームを長期間使い続けている場合か、キャンペーンのような一時的な大量受付です。1つのフォームを何年も使い回している窓口では、いつのまにか10,000件を超えていて、個別ビューが出ないことに気づく、という順序で発覚します。

対処としては、年度やイベントごとにフォームを分ける運用が現実的です。ただしフォームを分けると、担当の決め方と返信済みの印も、フォームの数だけ分かれます。件数の上限を避けるために分けた結果、管理する表が増えて余計に追えなくなる、という逆転が起きないよう、分ける前に記録の置き場を決めておく必要があります。

ファイルを集めるときに効いてくる条件

応募書類、見積書、写真。受付でファイルを集める場面は多くあります。ここには権限と関係する条件が二つあります。

回答者に Google アカウントが要る

ファイルのアップロード質問について、公式ヘルプは明記しています。

To answer this question, responders need to sign in to a Google Account. 出典: support.google.com

日本語版のヘルプにも「質問に回答する際にアップロードを実行するには、Google アカウントにログインする必要があります」と書かれています。

社内で使うぶんには問題になりません。全員が Google アカウントを持っているからです。効いてくるのは、社外の不特定多数から書類を集めるときです。回答者にログインを求めると、そこで応募をやめる人が一定数出ます。アカウントを持っていない人、持っていても仕事用と分けたい人、単に手間を嫌う人。どれも珍しくありません。

同じ理由で、「回答を1回に制限する」をオンにした場合も、フォームにアクセスして入力するには Google アカウントへのログインが必要になると公式に書かれています。重複を防ぐ設定と、応募のしやすさは、ここでトレードオフの関係になります。

このあたりの条件をどう扱うかを含めて整理したものがGoogleフォームとの比較にまとまっています。回答者側にログインを求めるかどうかを含めて、受付の入口をどう設計するかの判断材料として使えます。

保存先とドライブ側の上限

アップロードされたファイルは、フォームのオーナーの Google ドライブに新しいフォルダが作られ、そこに保存されます。フォームのオーナーが、受け取れるファイルの種類、数、サイズの上限を設定できることも公式ヘルプに書かれています。

ここで一つ注意したいのが、保存先がオーナーのドライブだという点です。共同編集者が受け付けたファイルであっても、置き場所はオーナーの側にあります。オーナーが異動や退職でアカウントを失うと、ファイルの所在に影響が出ます。共同編集者にした上で、共有画面から対象者を選んで所有権を移す手順が公式に用意されているので、窓口を引き継ぐときはここまで含めて実施する必要があります。

ドライブ側の上限としては、1ユーザーが24時間にアップロードまたはコピーできるのは750GB、1ファイルは最大5TBと公式に書かれています。通常の書類受付でこの数字に届くことはまずありませんが、動画を集める用途では意識しておいて損はありません。

そのほかに、共有ドライブからのファイルアップロードはできないこと、ファイルのアップロード質問を含むフォームはメールに埋め込めないことも、それぞれ公式ヘルプに記載があります。案内メールにフォームを埋め込んで送りたい場合は、この制約に当たります。

なお、ファイルアップロードの最大ファイルサイズで選べる具体的な数値の一覧や、フォーム全体に設定できる合計容量の具体的な数値は、今回確認した公開資料では確認できませんでした。実際の設定画面で選択肢を確認してください。

締切と定員を標準機能で扱う

複数人で受けるとき、締切の管理も担当者ごとにばらけがちです。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.」と書かれています。日時を指定して締め切るか、回答数の上限に達したら自動で締め切るかを選べます。

設定は「Accepting responses」の下にある「Set close date or response limit」から行います。日時で締め切る場合は日付と時刻を選び、件数で締め切る場合は上限の件数を入力します。締め切ったあとに回答者へ表示する文言も編集できます。手動で止めたい場合は、回答を受付中をオフにすれば「このフォームでは回答を受け付けていません」というメッセージが表示されます。

一つ注意点があります。この機能は既定でオフで、フォームを公開したあとに作成者が有効にする必要があると公式ブログに書かれています。締切を設定したつもりで有効化を忘れると、締切後も回答が入り続けます。提供範囲は Google Workspace の顧客、Workspace Individual の契約者、個人の Google アカウントの利用者すべてと記載されています。

一方で、質問の選択肢ごとに定員を設ける標準機能（第1希望が埋まったら選べなくなる、といった残席管理）については、公開資料では確認できませんでした。定員のある講座やイベントで枠ごとの残席を扱いたい場合は、この点を先に確認しておく必要があります。定員のある申し込みをどう受けるかはイベントの申し込みや講座の受講申し込みの整理が参考になります。どちらも、申し込みを受けたあとに枠と参加者をどう突き合わせるかまでを扱っています。

権限の設計を、受付の運用に合わせる

ここまでの内容を、権限という視点でまとめ直します。共同編集は「作る権限」を配る仕組みです。受付の運用で必要なのは「対応する権限」で、この二つは重なっていません。

回答者側の公開範囲は別の設定

回答者から見えるかどうかは、共同編集とは別の設定です。公式ヘルプには「When you publish a form, responders can access it. If the form is unpublished, responders with the link can't access it.」と書かれています。公開していないフォームは、リンクを持っていても開けません。

一般的なアクセスの設定では、リンクを知っている全員に渡すか、特定の対象に絞るかを選べます。ドメイン、信頼できるオーディエンス、ユーザーのグループに制限できると記載されています。回答者ごとにアクセスレベルを選ぶこともでき、有効期限も設定できます。

社内向けの申請と社外向けの受付では、ここの設定が変わります。社内向けなら組織のドメインに絞る、社外向けならリンクを知っている全員に開く。どちらの設定にしているかを、フォームを共有された側が知らないまま案内文を出すと、届かない人が出ます。

Google Workspace を使っている場合は、管理者側の設定も影響します。フォームを使うにはドライブが有効である必要があること、管理者が外部で作られたフォームへの回答や外部へのフォーム共有を制限できることが、管理者向けのページに書かれています。設定の反映には最長で24時間ほどかかることがあるとも記載されているので、締切直前に管理者へ変更を依頼するのは避けたほうが安全です。

オーナーが誰かを、はじめに決める

窓口として使うフォームでは、オーナーが誰かが後々効いてきます。回答のスプレッドシート、アップロードされたファイル、通知の設定。どれもオーナーの側に紐づきます。

個人のアカウントで作ったフォームをそのまま窓口に使い続けると、その人が抜けたときに全部が止まります。共同編集者にした上で所有権を移す手順は公式にあるので、担当が変わるタイミングで確実に移す運用にしておく必要があります。移すときには、フォーム側の共有設定と回答用スプレッドシート側の共有設定を、別々に確認してください。前述のとおり、フォームの権限変更はスプレッドシートに自動では反映されません。

個人情報を含む回答を扱う場合、誰がアクセスできる状態にあるかの管理は、社内規程や法令にも関わります。具体的な取り扱いの可否については、所管の窓口や専門家に確かめてください。制度の考え方については個人情報保護委員会の情報が出発点になります。

受付の道具を選ぶときに見るべき順番

最後に、いま何を変えるべきかを決めるための順番を整理します。道具を比べる前に、自分たちの受付がどの段階にあるかを見極めるほうが先です。

判断の分かれ目は「作る」か「回す」か

分かれ目は一つです。分担しているのが、フォームを作る作業なのか、届いた1件への対応なのか。

作る作業の分担であれば、共同編集で足ります。設問を一緒に直せて、締切を設定できて、追加費用もかからない。この用途で不便を感じているなら、原因は道具ではなく、誰がどの設問に責任を持つかを決めていないことのほうです。

対応の分担であれば、必要なものが増えます。担当が誰かが表に残ること、返信したかどうかが全員から見えること、やり取りが1件ごとにまとまっていること。この三つは、フォームが受け取る道具として設計されている以上、その外側で用意することになります。表に列を足して運用でカバーするか、受付から返信までを同じ画面で扱える道具に移すか。どちらを選ぶかは、件数と人数と、記録が消えたときの痛みの大きさで決まります。

場面ごとに、決めるべきことは違う

同じ「受付」でも、決めるべき順番は用途によって変わります。

採用の応募では、書類を受け取るときのログインの条件と、応募者ごとの選考状況をどこに残すかが先に来ます。この整理は採用の応募受付にまとまっています。書類の受け取りから、その後のやり取りをどう追うかまでを扱っています。

助成金や公募では、締切の厳密さと、要件を満たしているかの確認手順が中心になります。助成金・公募の受付では、締切の扱いと審査の流れをどう分けるかを整理しています。

日常的な問い合わせでは、件数が読めないぶん、担当の決め方と返信済みの印が最も効きます。問い合わせの受付には、届いた問い合わせをどう振り分けて追うかがまとまっています。

このほか、施設の予約や修理の受付のように、受付のあとに現場の予定と突き合わせる必要がある用途もあります。施設利用の申請と修理・サポートの受付では、申請を受けたあとの調整をどこで扱うかを整理しています。会員制の運営であれば、入会後の情報をどう持ち続けるかまで含めて考える必要があり、会員の入会申し込みがその範囲を扱っています。

他の道具を見るときの比較軸

いま使っているものから移すかどうかを検討する場合、比べる軸は「作りやすさ」ではなく「届いたあとに回せるか」に置いてください。作りやすさで比べると、どの道具も似た結論になります。差が出るのは受け取ったあとです。

具体的には次の項目を並べて見ると判断しやすくなります。担当を割り当てられるか、対応状況が全員から見えるか、返信の履歴が1件ごとに残るか、回答者にログインを求めずにファイルを受け取れるか、通知を複数人に配れるか。

WordPress でサイトを運用している場合の選択肢についてはContact Form 7との比較に整理があります。プラグインで受け付けたあとの管理をどう組むかという観点でまとまっています。Microsoft 365 を使っている環境であればMicrosoft Formsとの比較が近い比較になり、既存のアカウント基盤との関係を含めて扱っています。

道具そのものが何を持っているかを確認したい場合はできることに機能の一覧があり、実際の画面の動きは動くところを見るで確認できます。費用の見通しを立てるなら料金に条件がまとまっています。導入の前によく出る疑問についてはよくある質問に回答が並んでいます。

変える前に、いまの状態を数えておく

最後に一つだけ。道具を変えるかどうかを決める前に、いまの受付を数字で押さえておくことを勧めます。

月あたりの受付件数、対応にあたる人数、1件あたりの往復回数、返信までの目標時間。この四つが分かると、何が足りていないのかが具体的になります。件数が月30件で担当が1人なら、表に列を2つ足すだけで足りることが多くあります。件数が月300件で担当が4人なら、表の運用では追いつかなくなる時期が近いと考えたほうが現実的です。

現場では、100件を超えたあたりから表が回らなくなると言われています。回らなくなる理由は件数そのものではなく、書き込む人と書き込まない人が分かれ始めることです。全員が必ず更新する仕組みを人の意識に頼っている限り、件数が増えれば必ず穴が空きます。

数えたうえで、まだ表で足りるなら、無理に変える必要はありません。足りなくなる時期の見当がついたなら、その前に記録の置き場だけでも先に決めておく。この順番で進めれば、切り替えのときに過去のやり取りを失わずに済みます。

Q1. Googleフォームの共同編集者は何人まで追加できますか？

共同編集者の人数上限は、今回確認した公式資料の範囲では確認できませんでした。上限が無いという意味ではなく、公開されているヘルプに記載が見当たらなかったという意味です。大人数で共有する予定がある場合は、実際の共有画面で追加を試して確認するのが確実です。なお共同編集者は回答や保存場所を含めフォーム全体を編集できるため、人数より権限の範囲を先に確認してください。

Q2. 共同編集者にも新しい回答の通知を届けられますか？

スプレッドシートの通知ルールは「You can only set up notifications for yourself.」と公式に明記されており、自分にしか設定できません。複数人に通知を送る標準の設定は公開資料では確認できませんでした。公式ヘルプが案内しているのは Form Notifications アドオン（提供元 Google、無料）で、オーナーと共同編集者に回答数のしきい値で通知を送れると掲載されています。

Q3. 返信済みかどうかをスプレッドシートで管理するとき、最初に足す列は何ですか？

担当、状態、返信日の3列から始めるのが現実的です。状態は最初から細かく分けず、未対応と完了の2つだけにすると定着しやすくなります。列を足す前に、フォーム側で設問を追加・並べ替えしたときに列がどうなるかを小さく試しておいてください。この挙動は公開資料では確認できませんでした。

Q4. 回答が増えるとGoogleフォームは使えなくなりますか？

回答の受け付け自体は止まりません。公式には、10,000件を超えるとCSVが送信日時順に並ばず質問別ビューと個別ビューが出なくなること、50,000件超で回答の概要が出なくなること、100,000件超でスプレッドシートと同期されなくなることが書かれています。ただし回答は入り続け、CSVでダウンロードできます。年度やイベント単位でフォームを分けると回避しやすくなります。