※本記事にはPRを含みます。

こんにちは。「脱会社員」脱サラを応援し続けるブログ、運営者の「なかびー」です。

小さな講座や体験会をGoogleフォームで受け付けると、「同じ人の申込みが二つある」「家族二人が同じ連絡先を使っている」「ログインできない人が申し込めなかった」といった状況が起きます。Googleフォームで[回答を1回に制限する]をオンにすると、同じGoogleアカウントから繰り返し回答することを制限できます。ただし、アカウント一つと参加者一人、回答一件と確定枠一つは、それぞれ意味が違います。設定だけで氏名や申込み内容の重複まで判断できるわけではありません。

この記事では、受け付けを開く前に「何を一件と数えるか」「どの人が回答できるべきか」「どこからを確定と呼ぶか」を順番に決めます。九行の架空データを使い、同じ氏名でも別人の行を残し、別アカウントから届いた同一枠の申込みを確認待ちにする例も紹介します。Googleアカウントを持たない人も対象なら、ログインを求める方式を選ぶ前に、別の受け付け方を用意できるかも判断します。

最初に決めること:一件の単位、ログインの可否、連絡先を集める理由、重複候補の確認担当。送信された数を、参加確定の人数に読み替えないようにします。

一件の単位を、アカウント・参加者・時間枠から選ぶ

アカウント、参加者、時間枠のカードを別々のトレイに分けた例

初めに、守りたいルールを一文にします。「同じ人の重複を避けたい」だけでは、例えば午前と午後にそれぞれ参加できるのか、家族は代表者一人が申し込んでもよいのか、同じ人が別の回に応募できるのかが分かりません。「午前・午後のいずれか一枠だけ」「同じ参加者の同じ枠に一件まで、別枠なら各一件」「一世帯につき一回答、参加者はその中で複数名」では、フォームが受け取る行の意味が違います。回答を一回に制限する設定は、このうち何を自動で守れるかを後から選びます。

一件の単位 例 確認したいこと
配布済みのアカウント 社内の出欠アンケート 全員が使える指定アカウントを持ち、対象者だけが開けるか
参加者本人 参加者一名がどちらかの回に参加 二回目の回答が訂正か重複か。別アカウントで同じ人から届く場合の扱い
参加者と枠の組み合わせ 同じ人が午前と午後の両方に参加可能 同じ枠だけを重複候補にし、別の枠を落とさないか
代表者または世帯 一つの連絡先に複数名を登録 フォームの回答件数と、参加者の人数を別に数えるか

例えば、同じメールを使う二人を別々の参加者として登録するなら、メールアドレスを一件の単位にできません。反対に、少人数の社内アンケートで回答者全員に個別の社用アカウントが割り当てられ、申込みを一回にしたいなら、アカウント単位が運用ルールに近くなります。アカウントの所有者と実際の参加者が常に同じと判断できるかは、回答対象や代理申込みの規則によります。

受付ルールを「誰が何をするか」に書き直す

例えば地域の作業教室で、午前は道具の説明、午後は持ち込み相談を行うとします。一人が両方に参加できるなら、午前の定員と午後の定員は別です。フォームを一度しか送れない運用を選ぶ場合でも、同じ回答の中で両枠を選べる設計にするか、枠ごとに別の申し込みを受け付けるかを決めます。入力時にどちらか一枠しか選べず、後から午後を追加できないなら、利用者に別枠の参加が許可されていてもフォームでその意思を出せません。回答画面の設計は、集計のしやすさだけでなく、参加者が選べる内容に合わせます。

また、代表者一人が家族分を申し込める受付なら、一回答に希望者の人数を入力する形と、参加者を別の行で照合する形では、受け付け後の集計が違います。前者では一回答が複数席になる場合があり、後者では一つの連絡先が複数の申込みに出ます。どちらを採るかで「重複」と呼ぶ条件が変わるため、申し込み案内では、代表者が何回フォームを送るか、後から家族を追加できるかも説明します。

「同じ人かどうか」を判定するために、とりあえず氏名、電話、住所、メールをすべて集める必要はありません。例えば、すでに会員向けに発行した番号があり、照合に使うことを案内済みなら、その番号と希望枠だけで確認が済むことがあります。逆に、参加者が初めての一般客なら、もともと配布していない番号を入力必須にすると対象者を締め出します。どの情報が照合に必要で、その情報を持っていない人をどう扱うかを先に決めます。

申込みと確定の区別もここで書きます。説明欄に「このフォームは希望を受け付けるものです。確定方法は別に案内します」と明記し、送信直後の表示と矛盾しないようにします。空き状況で別の時間へ振り替える場合は、誰が確定枠を更新するのかまで決めておきます。ここを空欄のままにすると、フォームに表示される回答件数がそのまま会場の座席数として扱われがちです。

1回制限・公開範囲・アドレス収集を別々に設定する

1回制限・公開範囲・メール収集を別々の設定として示す操作盤のイメージ

回答者全員が利用できるGoogleアカウントを持っているなら、フォームの[設定]を開き、[回答]の項目を展開して[回答を1回に制限する]をオンにします。Googleのフォームを公開して回答者と共有する案内では、この設定を使うと回答者はGoogleアカウントへのログインが必要になると説明しています。対象にアカウントを持たない人がいるなら、オンにする前に、その人に別の申込み方法があるかを確認します。

次に、フォームを開ける範囲を確認します。社内用のフォームで組織のアカウントだけを対象にするか、外部の参加者も含めるかを決めます。[公開]と回答者へのアクセス設定は、回答が何回できるかとは別です。「アクセス権が必要です」と出る場合、回答回数の上限に達したのではなく、共有範囲や利用中のアカウントが条件に合っていない可能性があります。詳しくはGoogleのフォームを開く権限の案内も確認できます。

最後に、メールアドレスを収集する目的を確認します。Googleの案内では、回答を一回に制限してログインを求めることと、回答者のアドレスを記録する設定は別です。招待する対象かどうかをアクセス範囲で決め、結果を連絡する場合は必要な連絡先だけを収集します。メールを記入必須にしても、手入力の文字列を受け取るだけなら、Googleアカウントの同一性やメールの到達まで証明したことにはなりません。集めた連絡先を誰が見られるか、どこへ転記するかも事前に決めます。

確認項目 決める内容 試験時に見るもの
回答用の公開範囲 招待済みの対象者だけか、外部も開けるか 対象者が回答画面を開け、対象外を含めないこと
回答の1回制限 同じアカウントから一回にするか 初回は回答でき、同じアカウントで二度目を試したときの表示
メールアドレスの収集 結果通知や照合に必要か。確認済みか手入力か 送信後、意図した項目だけが作成者側に記録されるか
フォーム受付の開閉 いつまで回答を受け付けるか 受付を終了した後の表示と案内

例えば、社内アカウントだけで実施する確認なら、個人用のアカウントで開けないのは想定どおりです。逆に、地域の参加者向けに案内したフォームで全員が組織への参加を求められるなら、意図と公開範囲が食い違います。管理者のアカウントで自分が開けることだけでは、外部の人が開けるとは判断できません。テストは対象者の条件を再現できる検証用のアカウントで行い、実際の募集URLを広く配る前に結果を記録します。

確認済みのアドレスと手入力を区別する

受付担当が知りたいことが「結果を送る宛先」なのか、「配布したGoogleアカウントで回答したか」なのかで、収集する設定は違います。例えば社内向けなら配布済みアカウントと回答を照合する方針をとれる場合があります。一方、申込者に任意の連絡先を入れてもらう場合、打ち間違いが起きても、その文字列を受付けただけでは送信先が正しいとは分かりません。必要に応じ、連絡先の案内と確認方法を別途設けます。本人の確認に不要な情報は、照合のためにむやみに増やしません。

回答を一回に制限しない場合でも、公開範囲が限られていたり、アドレスを確認済みとして収集したりする設定を選ぶと、ログインを求められる場合があります。逆にログインを求める画面を見たからといって、作成者がアドレスを取得したとは判断できません。ログインなしを要件にするなら、制限だけを切って終わりにせず、公開設定とアドレス収集も確認します。作成者画面と回答者画面は別々に開き、フォーム名と検証日時を控えます。

集めた内容が他の回答者に見えてはいけない場合は、結果の概要を共有する設定も別に見ます。送信結果の通知や編集用リンクを付けるかは、回答回数の制限とは別の判断です。締切前の訂正を受け付ける仕組みは、Googleフォームの回答を送信後に編集し、結果を照合する方法にまとめています。新しい申込みを二度送らせる必要があるかは、その運用を決めてから案内します。

公開前に、送れる人と送れない人の条件を試す

対象・対象外を区別し、初回と同じアカウントでの再訪を未記入の試験票で確認する例

設定画面だけを見て「対象者は全員回答できる」と決めないようにします。検証用フォームと許可された検証用アカウントを使い、募集前に少なくとも、ログインしていない状態、対象のアカウントでの初回、同じアカウントでの再訪、公開範囲外のアカウントを区別して確認します。別の対象アカウントで申し込む家族や同僚がいる場合は、その条件も別にします。ここでの想定は公式仕様と受付設計にもとづくもので、この記事のために実在する参加者へ送った試験ではありません。

試す条件 期待する状態 食い違った場合に戻る設定
未ログインで、1回制限がオン ログインが必要。未ログインの人を募集対象に含めるなら別受付の検討 回答1回制限、アドレス収集、公開範囲を別々に見る
対象のアカウントで初回 回答画面を開き、テスト値を一件だけ送れる 公開、受付中、対象の範囲
同じアカウントで同じフォームに再訪 新規の二度目の回答は制限される想定。編集経路は別 回答1回制限と、開いているURLの版
別の対象アカウント 許可されたアカウントなら別の回答として成立し得る 回答者の公開範囲。本人との同一性は名簿で別確認
対象外のアカウント 対象外なら開けない。公開範囲が広すぎないかも見る 公開範囲とログイン中のアカウント

確認したことは「通った」「止まった」だけでなく、どのページで止まったかを記録します。回答URLに到達する前にアカウントの選択が出たのか、対象外で権限を求められたのか、既に回答したという表示なのかでは、戻る場所が違います。同じ人が二つのブラウザで同じアカウントを選べば、ブラウザが別でもアカウント単位の制限を別人扱いにする根拠にはなりません。別アカウントで開けても、参加者単位の重複を防げた証拠ではありません。

作成者側も、送ったはずのテスト行が正しいフォームの[回答]に届いたかを見ます。プレビューや作成者用のURLを配布用と取り違えていないか確認し、管理用のURLや編集用リンクは配布文に入れません。公開後に設定を変えた場合、変える前のテスト結果をそのまま使わず、影響する条件をもう一度確認します。テストのために本番の申込みを勝手に消したり、対象外の人にアクセス権を広げたりする必要はありません。

検証結果に、URLの種類と試した状態を残す

検証表には「回答URL・初回・対象アカウントで送信できた」「同じ回答URL・同アカウントで再訪・新規送信が制限された」「対象外・未送信」のように、到達したところまでを書きます。どのアカウントを使ったかは、実際のアドレスを共有する代わりに「組織用」「許可済みの検証用外部」「未ログイン」といった区分で記録できます。試験担当がフォームを改めて開いた時点で回答の受け付けが終わっていた場合は、アカウント制限の結果として混ぜません。

テストに使う値も架空だと分かるものを用意し、本番の申込みに混ざる仕組みで試すときは、確認用に分けられるかを事前に決めます。試験の送信は実際の送信と同じく受付一覧に行が作られ得るため、集計対象に入る前に運営者が判別できるようにします。イベントの応募者に試してもらう前提にせず、運営側が利用できる環境で対象条件を再現します。再現できない条件は未確認として記録しておきます。

例えば社外の参加者が一人だけ回答できないときは、全員向けに公開設定を広げる前に、意図したフォームか、受付中か、利用中のアカウントが対象に合うかを確認します。回答者向けの案内に、どこを見て連絡すればよいかも短く添えます。受信した相談を扱うときは、パスワードや認証コードを求めず、表示されたメッセージの種類と、利用しているアカウントの区分だけで状況を切り分けます。

架空の九行で、同名・別枠・重複候補を分ける

同じ表示名でコードが違う行と、同じコードで時間枠が違う行を並べた照合例

次の練習では、同じ参加者が午前と午後に各一回参加できる想定にします。照合に使うのは、事前に割り当て済みの参加者コードと枠の二つです。表示名や連絡先は補助で、照合のキーにはしません。九行は架空データです。実際のGoogleフォームへの送信やアカウント操作で取得したデータではありません。照合だけを再現する例として、表にあるコードと枠の組み合わせをまとめています。

元の行 コード 枠 表示名・状況 扱い
R01 K01 午前 アオ、初回 R02と同じキー。確定は保留
R02 K01 午前 アオ、別アカウントからと仮定 R01と同じキー。本人と意図を確認
R03 K02 午前 アオ、同じ表示名 別コード。自動で消さない
R04 K01 午後 アオ、同じ参加者 別枠なので独立した候補
R05 K03 午前 ミドリ、連絡先はR06と共通 別コード。独立した候補
R06 K04 午前 キイロ、連絡先はR05と共通 別コード。独立した候補
R07 未記入 午前 アオ 分類保留。氏名だけで結び付けない
R08 K06 未記入 シロ 分類保留。希望枠を推測しない
R09 K05 午後 クロ 独立した候補

元の回答行は九つです。このうちコードと枠がそろう行を組み合わせで分けると、識別できるキーは六つあります。その六つにはR01とR02の重複候補一つが含まれ、重複のない候補キーは五つです。コードまたは枠がないR07とR08は分類を保留します。ここまでで自動的に確定した席はゼロです。あとで運営者が確認して確定するため、回答九行、識別できた六キー、重複候補一キー、分類待ち二行を混ぜずに報告します。

同じ表示名のR03を消すと、午前の別参加者が名簿から落ちます。連絡先だけで比較すると、同じ連絡先のR05とR06のどちらかが消えます。R04をR01と統合すると、午後も申し込めるというルールに合いません。反対に、アカウントだけで照合した場合、同じ参加者コードと枠のR01・R02が別々に残ることがあります。何でまとめるかは、最初に決めた受付ルールへ戻って判断します。

確認欄を行と候補の両方に設ける

九行の一覧を紙に書くなら、左側に受信行、中央に照合キー、右側に担当者の確認を置きます。右側は最初から空欄で、件数の欄には「受信9」「同一コードかつ同一枠の候補1組」「不足2行」とだけ書きます。R01とR02のように二行ある候補は、それぞれの元の行番号を両方残して一つの確認票にまとめます。確定時に必要なのは、最新の行を選ぶことだけではなく、当初の希望を取り消す意思があったかです。どちらも同じ人だと確認できない場合は、別の情報で照合するまで確定を待ちます。

一人一枠までという別のルールで同じ架空例を読むと、R04の扱いが変わります。コードK01を午前と午後で分けられないので、本人に希望を確認する対象になります。元のデータが同じでもルールを変えると確認が必要な行が変わる例です。集計式を作り始める前に、コードだけを使うのかコードと枠を組み合わせるのかを、受付担当と共有してください。同一枠の中だけで見たいときに別枠までひとまとめにすると、取り消すべきでない申込みが落ちます。

一方、番号が一致していても、番号の配布を間違えていれば本当に同じ参加者とは限りません。本人の確認手段がないのにコードを身元の証明として扱わず、確認に必要な連絡だけを行います。架空表のコードは照合の動きを見せるためのもので、外部の参加者全員にコードを振ることを勧めるものではありません。

実際の表で照合列を追加するなら、元のフォーム回答の列をいじらず、担当者が扱える範囲で作業用の一覧を用意します。コードの先頭ゼロや大文字・小文字が意味を持つ場合は、運用上定めた形を確認するまで一律に消したり変換したりしません。入力漏れは空欄のまま判別できるようにして、同じ空欄同士だから重複とする扱いを避けます。入力値を勝手に埋めないよう、誰がどの根拠で確認したかを残します。

ログインなしの受付では、重複を「候補」として照合する

候補二枚を確認待ちへまとめ、別に情報不足の札を残した受付作業ボード

対象にGoogleアカウントを持たない人が含まれるなら、ログインを要する1回制限を外したり、ログインなしで利用できる別窓口を用意したりする選択肢があります。ただし、ログイン不要と、個人単位の厳密な一回制限を同時に実現したと案内してはいけません。フォーム以外の受付を併用するなら、フォームと別窓口で別々に確定席を作らず、確認を担当する一つの一覧へ合流させます。そのとき、必要な情報だけを転記します。

受付後に重複を照合する場合、申込番号があれば、回答者本人にその番号と希望枠を確認します。初めから番号が配布されていない場合は、氏名と同じ文字列が二つあるだけで判断せず、参加者自身が確認できる受付情報と照らし合わせます。本人からの訂正、代理申込み、別枠を追加、誤って二度送信した場合では、正しい残し方が違います。新しい行を古い行より無条件に優先するのではなく、何を確定するかを担当者が確認します。

見つかった状態 確認先 確定前の扱い
同じ人の同じ枠らしい 受付番号、申込み本人の意思 候補をまとめ、採用行を判断するまで二席と数えない
同じ人が別の枠を希望 別枠の参加可否というルール 許可されるなら別候補。禁止なら本人と希望枠を確認
別人が同じ連絡先を使う 参加者の番号と代理申込みの扱い 連絡先の一致だけで削除しない
照合の情報が足りない 確認に必要な最小限の情報 分類保留の件数に分け、確定席に含めない。受信済みは記録する

連絡を受け付けたら、元の行はそのまま残して、確定用の一覧にだけ「確認待ち」「本人確認済み」「別枠として受付」などの状態を付けると、判断の前後が追えます。「重複」とだけ書いて元の行を消すと、誤って外した参加者がいた場合に戻りにくくなります。複数の担当者が同じ一覧を触るなら、確認担当と最終確定担当を決め、決定時刻を残します。連絡先を共有範囲の広い別表へコピーしたり、他の参加者へ見える方法で照会したりする必要はありません。

フォーム外の受付を一緒に扱うときの例

例えば、フォームで午前を申し込んだ人が、後から窓口でも午後を申し込んだとします。受信経路は違いますが、同じ参加者でも別枠の参加を許可するルールなら、それぞれ候補にできます。反対に、窓口から午前の希望がもう一度来た場合は、同じ申込みを訂正したいのか、追加参加者がいるのかを聞きます。窓口側で勝手に別の番号を発行するとフォーム側と照合できなくなる場合があるので、元の受付番号を確認できる欄と、どこから受け付けたかの欄を分けます。

窓口から照会するときは、申し込み一覧をまとめて渡す必要はありません。相手が把握している番号や希望枠を一つずつ確認し、他の人の申込み内容を見せないようにします。メールアドレスが同じ家族については、連絡先の役割と、参加者それぞれの枠を別欄に保ちます。案内の文面を考えるときも、「あなたの申込みは二重です」と断定せず、「同じ枠について複数の入力があるため確認しています」と、確認中の状態が分かる言い方にします。

受付の説明も運用にそろえます。たとえば「同じ枠について追加の送信をすると、確認に時間がかかることがあります。訂正は確認番号を添えて受付窓口へ」と案内すると、同じ人の連続送信を抑える助けになります。ログインできない人向けに別窓口を用意する場合は、返答の見込みと確定の通知方法を同じように書きます。事情が違う人を一律に不備として落とさないための案内です。

回答数と確定枠を分け、締め切る前に引き継ぐ

架空の受付で受信9件と確定0枠を別のカウンターで示す例

同じアカウントの二度目を防ぐ設定と、受付全体の件数を一定数で止める設定、参加者へ枠を確定する手続きは別です。Googleのフォームの回答を表示・管理する案内では、フォームの受付を止める方法に加え、終了日や回答数の上限に関する説明があります。複数のユーザーが同時に回答すると上限を越えて受け付けられる場合があるとも案内されているため、回答数の上限を会場の厳密な定員保証として扱わないようにします。使っている環境で対象の設定が見えるかも個別に確認してください。

午前の枠と午後の枠がそれぞれ別にあるなら、フォーム全体の回答数だけでは一方の満席を判定できません。九行の例でも、同じ午前の候補を二席と数えるか、午前午後を別とみるかで席数は変わります。受付を終了する担当は、フォームの受信数、希望枠別の確認中の数、確定済みの数を別欄で見ます。「受付済み」が届いただけの状態と、席が決まっている状態を、参加者への表示でも区別します。

  1. 公開前に、一件の定義、代理申込み、別枠の可否を決める。
  2. 回答対象に合わせ、公開範囲とログイン・1回制限を確認する。
  3. 必要な連絡先だけを収集し、検証用の値で初回と再訪の違いを見る。
  4. 応募行は保持し、重複候補と情報不足は別にして照合する。
  5. 締切では回答の受け付け状態と確定枠を別々に確認する。

引継ぎでは「フォーム回答九行、識別可能なキー六つ、重複候補一つ、未分類二行」と書き、いつまでの受信分を数えたかも添えます。件数だけでなく、誰が次の判断をするかが分かると、別の担当者が二重に連絡したり、重複候補を同時に確定したりするのを避けやすくなります。保留中に枠を押さえるかは、最初の運用ルールに従います。保留を自動で取り消したと誤解されないよう、連絡の目安も案内します。

受付終了・照合完了・参加確定の時刻を別々に残す

当日の受信を集計するなら、時刻を決めて、その時点の回答一覧をもとに照合を始めます。受付を閉じる前後には、担当者の確認時刻と、最後に集計した回答の時刻が一致しない場合があります。「終了時点で何行」「そのうち未照合はいくつ」「何席を確定したか」を分ければ、後から届いた問い合わせにどの段階の結果を伝えたかが分かります。受付を止めた後に例外対応が必要なときは、元のルールと違う経路で受けたこと、担当者、枠の最終判断を控えます。

記録する時刻 担当者が確認するもの その時点で残り得る作業
受付を閉じた時刻 実際の回答URLから、新規の回答を受け付けない表示になったか 受付を閉じた直前の申込みをまだ一覧へ反映していない
照合用の一覧を固定した時刻 何行を受け、何行を確認待ちにし、どのキーをまとめたか 同一枠の申込みが二つ見つかったが、本人の意思を確認していない
確定した時刻 承認した枠、承認した担当、本人へ伝える内容 枠は確定したが、本人へまだ結果を伝えていない

記録用の一覧は、誰でも見られる共有ページではなく、受付の担当が扱う場所に置きます。手順を再現する目的なら、個別の連絡先を伏せて、結果だけを共有できます。例えば「午前は単独候補三件、照合待ち一組、情報不足一行」と書き、個人への問い合わせは別の記録へ分けます。次回の担当に残すのは、どの段階で何を判断し、どの条件が未確認だったかです。同じ枠の重複を防ぐために、必要でない個人情報を常に引き継ぐわけではありません。

確認の途中で受付ルール自体を変えると、変更前に申し込んだ人の扱いも変わり得ます。締切前の案内と異なる結果になる場合は、その場で設定を変えるだけで解決したと考えず、いつの申込みにどのルールを適用するかを運営内でそろえます。保留にした行を残しておくと、変更前後の判断も追えます。

確認待ちがあるときに参加者へ確定済みと表示すると、後から取り消す必要が生じるかもしれません。逆に空き枠が残っているのに、回答数だけで満員と案内してしまうと、参加できる人を逃します。締切の担当は、枠ごとの確定人数と確認待ちの内訳を見て、案内の表示を更新します。回答画面を閉じた事実と、確定通知を送った事実は、完了欄を別にします。

数が合わないときは、フォームの返信通知を何通見たかではなく、実際の回答タブ、照合に使った一覧、最後に承認した参加枠を別に開きます。どこで増えたのか、どの行が確認待ちなのかが分かれば、フォーム設定を変える必要があるか、それとも名簿を確認するだけでよいか判断できます。Googleフォームの1回制限を使える場面でも、受付対象に届くことと、必要な席だけが確定することを両方確認してから始めてください。