Googleフォームの回答をエクセルで集計する｜毎回同じ加工をやめる

「google フォーム 集計 エクセル」で検索してこのページにたどり着く人は、たいてい同じところで止まっています。回答は問題なく集まっている。書き出す方法も分かっている。それでも毎月、同じ順番で列を並べ替え、同じ数式を貼り直し、同じピボットを作り直している。困っているのは書き出し方ではなく、書き出したあとに毎回発生する手作業のほうです。

この記事では、Googleフォームの回答をエクセルに持っていって集計するときに、その手作業を減らすための組み立て方を書きます。具体的には、どの列を自分で足すのか、書き出しをどういう手順に固定するのか、集計をどこに置くのか。この3つを最初に決めておくと、次の月からの作業が「貼るだけ」に寄っていきます。

あわせて、Googleの公式資料に書かれている件数の上限も整理しました。回答が増えたときに何が動かなくなるのかは公式に明記されています。ここを知らないまま運用を続けると、ある日いきなり集計画面が消えて慌てることになります。逆に言えば、上限を知った上で組めば、かなりの規模まで表で回せます。確認したのはすべて2026年9月1日時点の公式ページです。

エクセルでの集計が、受付の現場に残り続けている理由

申し込みや応募や問い合わせを受ける窓口で、フォームで集めて表で数える流れは長く定着しています。この流れがなくならないのは、担当者がエクセルを好きだからではありません。集計の出口が表だからです。

受付を担当している人の仕事は、集めることでは終わりません。集めた結果を誰かに渡すところまでが仕事です。上長への報告、経理への回付、所管の窓口へ出す様式、委託元への実績報告。渡す先が求めてくるのは、たいてい行と列で並んだ表です。フォームの管理画面に円グラフが出ていても、それをそのまま提出できる場面はほとんどありません。だから、どこかで必ず表に落とす工程が挟まります。

もうひとつの理由は、既存の資産です。何年も使ってきた集計フォーマット、部署で共有されている関数入りのブック、決まった形のピボット。これらを全部作り直してまで別のやり方に移る動機は、普通は生まれません。フォームを新しくしても、集計の出口だけは前のまま残るというのは、よくある形です。

コストの面から見ても、フォームで集めて表で数える形は安く済みます。Google Workspaceの日本語の公式料金ページでは、1ユーザーあたりの月額が Starter で800円、Standard で1,600円、Plus で2,500円と表示されています（Enterprise は料金の表示がなく、営業への問い合わせが案内されています。閲覧時点では割引表示も併記されていました）。同ページの機能一覧では「フォームのアンケート作成ツール」が Starter から Enterprise まですべてのプランで利用可と表示されています。つまり、すでにメールやドライブのために契約している組織なら、フォームのために追加の費用は発生しない構成になっています。

ストレージも同ページに記載があり、Starter が1ユーザーあたり30GBのプール、Standard が2TB、Plus が5TB、Enterprise が5TBで追加も可能と書かれています。書類を集める用途では、この数字が効いてくる場面があります。

こうした前提があるので、「集計をエクセルでやること」自体を見直す必要は、多くの場合ありません。見直す価値があるのは、集計そのものではなく、集計にたどり着くまでに毎回発生している加工の部分です。

書き出して集計するだけで足りるのは、どういう使い方か

先に、いまのやり方を変える必要がない場合をはっきりさせておきます。次のような使い方なら、フォームで集めて表に落とすだけで完結します。道具を増やすほうがかえって手間になります。

第一に、集めるのが一度きりで、期間が決まっている場合です。年に1回のアンケート、単発のセミナーの申し込み、社内の意向調査。開始と終了があり、終わったら集計して報告して終わる。この形なら、締め切って書き出して数えるだけで足ります。

第二に、集計が「数える」で済む場合です。参加人数、選択肢ごとの内訳、平均値。回答そのものが答えであり、回答者と個別にやり取りする必要がない。この場合、フォーム側の回答の概要画面だけで用が足りることも多く、表に落とすのは報告書に貼るためだけ、ということになります。

第三に、受け付けたあとの対応が定型で、担当が実質1人の場合です。誰が返したか、いつ返したか、どこまで進んだかを記録しなくても、頭の中で追える件数に収まっている。30件前後までなら、記録より記憶のほうが速い場面はあります。

第四に、締切や定員で自動的に止めたいだけの場合です。Googleの公式ブログによると、2026年1月に、指定した日時で締め切る設定と、指定した回答数に達したら自動で締め切る設定が追加されています。フォームのオーナーと編集者が使え、既定ではオフで、フォームを公開したあとに作成者が有効にする仕様と書かれています。提供範囲は、Google Workspace のすべてのお客様、Workspace Individual の契約者、そして個人の Google アカウントの利用者とされています。定員に達したら受付を止めたい、という要望はこれで満たせます。

以上に当てはまるなら、この先を読む必要はありません。この記事が役に立つのは、受け付けたあとに人が動く場合、つまり返信したり、書類を確認したり、可否を判断したりする場合です。そこから先で、表の加工が毎回発生します。

Googleフォームの回答が、いまどこに置かれているのか

加工を減らす話に入る前に、回答が物理的にどこにあるのかを整理しておきます。ここがあいまいなまま作業していると、「どのファイルが正なのか」が分からなくなり、結果として毎回作り直すことになります。

公式ヘルプによると、Googleフォームを作成すると、そのフォーム自体は Google ドライブに保存されます。回答の置き場は、そこからさらに分かれます。ひとつはフォーム内の回答タブ。もうひとつはスプレッドシートへの保存。そしてもうひとつが CSV でのダウンロードです。

スプレッドシートに保存する場合、保存先は「新しいスプレッドシートを作成」するか、既存のスプレッドシートを選ぶかのどちらかです。公式ヘルプには「回答をスプレッドシートに保存すると、Google スプレッドシートによってデータが自動的にテーブル形式になり、データの形式と構造が設定されます」と書かれています。

ここで押さえておきたいのは、フォームとスプレッドシートが独立した2つのファイルだという点です。公式ヘルプによれば、リンクを解除すると「新しい回答はスプレッドシートに送信されませんが、現在のデータはそのまま残ります」とされ、「後でスプレッドシートに再接続できます」とも書かれています。また、一方を削除しても他方は削除されません。つまり、スプレッドシートは「回答の窓口」ではなく「回答の写し」に近い扱いだと理解しておくと、事故が減ります。

一方で、公開資料では確認できなかったこともあります。回答が1件につき1行ずつ追加されるのかどうか、タイムスタンプ列がどう付くのかといった行と列の具体的な挙動は、今回確認した公式ページには記載が見当たりませんでした。フォーム側で設問を追加したり削除したり並べ替えたりしたときに、連携済みのスプレッドシートの列がどうなるのかも同様です。スプレッドシート側で直接データを編集した場合の扱いについても、記載は見当たりませんでした。

この「確認できない」は、後で述べる列の設計に直結します。設問を触ったときに連携先の列がどう動くかが公式に明記されていない以上、自分で足した列を連携先のシートに直接書き込む設計は、避けておくのが安全です。

エクセルに持っていく2つの経路と、それぞれの前提

回答をエクセルで扱うまでの経路は、大きく2つです。どちらを使うかで、後の手順の固定の仕方が変わります。

スプレッドシートに保存してから書き出す経路

フォームの回答をスプレッドシートに保存する設定にしておき、そのスプレッドシートをエクセル形式で書き出す流れです。この経路の利点は、途中に「常に最新が入っている1枚」が存在することです。フォームからスプレッドシートへの流れは自動なので、書き出しのタイミングを自分で決められます。

公式の製品説明には「You can use Google Forms to create online surveys, quizzes, and forms, send them to others to fill out and then analyze their responses in real time.」という記述があり、リアルタイムに分析できることが製品の説明として書かれています。締切前でも途中経過を見たい、という運用にはこの経路が向きます。

注意点は、共有の権限です。公式ヘルプには「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.」ともあり、その後にフォーム側の権限を変えても、スプレッドシート側には自動では反映されません。人の入れ替わりがある部署では、ここが放置されがちです。

CSV でダウンロードする経路

もうひとつは、回答を CSV でダウンロードして、それを表計算ソフトで開く流れです。締め切ったあとに一度だけ書き出す、という使い方ならこちらが単純です。

この経路で知っておくべき前提が、件数による挙動の変化です。Google Workspace ラーニング センターには「If you download your responses in a CSV file and the responses aren't sorted by the timestamp when users submit them, it can be because your form has more than 10,000 responses.」と書かれています。回答が10,000件を超えると、CSV が送信日時の順に並ばなくなることがある、という意味です。

これは、並べ替えを自分でやる前提で組めば回避できます。ただし「毎回同じ順で出てくる」ことを前提に手順を組んでいると、ある月から突然おかしくなります。後述する手順の固定のところで、並べ替えを工程に組み込んでおくと安全です。

なお、表計算ソフトの設定によって CSV の読み込み方が変わることがあります。最初の1回で読み込み手順を決めて、その手順を文書に残しておくと、担当が代わったときに同じところで止まらずに済みます。

毎回同じ加工を繰り返さないための、3つの決めごと

ここが本題です。書き出したあとの加工が毎回発生するのは、決めていないことが3つあるからです。列、手順、置き場。この3つを最初に決めて文書に残すと、翌月からの作業が減ります。

列を決める：設問が作る列と、受付側が足す列を分ける

まず、表の列を2種類に分けます。フォームが作る列（以下、設問列）と、受け付ける側が業務のために足す列（以下、業務列）です。この2つを混ぜないことが、加工を減らす最大の分かれ目になります。

設問列は、フォームの設問がそのまま列になる部分です。ここは触りません。列名を分かりやすく書き換えたくなりますが、書き換えると次回の書き出しと突き合わなくなり、毎回の手作業が増えます。設問文が長くて読みにくいなら、表示側で列幅を調整するか、別シートで参照するときに短い見出しを付けます。元の列名は原文のまま残します。

業務列は、受け付けたあとに人が使う列です。最低限、次の6つを用意しておくと、返し忘れと二重返信が目に見えるようになります。

・受付番号（連番。この番号で会話する） ・担当（誰が見るか） ・状態（未対応／確認中／返信済／保留／完了／見送り） ・返信日（いつ返したか） ・次にやること（誰が何をするか） ・備考（判断の理由。あとで説明を求められたときの根拠）

このうち効き目が大きいのは「状態」と「返信日」です。返信したかどうかが表に残っていないと、二重返信と返し忘れは必ず起きます。メールの送信済みフォルダを見に行けば分かる、というやり方は、担当が1人で件数が少ないうちしか成立しません。

業務列を作るときのルールは3つです。第一に、業務列は設問列のすべての右側にまとめます。左に挿入したり、設問列の間に割り込ませたりすると、次回の貼り付けで位置がずれます。第二に、状態のような列は自由入力にせず、選択肢を固定します。「返信済」「返信ずみ」「済」が混ざると、集計のたびに表記ゆれを直す作業が発生します。第三に、業務列の一覧を1枚の文書にして、列名・意味・選択肢・誰が入れるかを書いておきます。これが引き継ぎ資料そのものになります。

先に触れたとおり、フォーム側で設問を追加・削除・並べ替えしたときの連携済みスプレッドシートの列の挙動は、公開資料では確認できませんでした。そのため、業務列は連携済みのシートに直接足すのではなく、後述する「作業」シート側に置くほうが安全です。設問の変更が業務列を巻き込む可能性を、構造的に断てます。

書き出しの手順を固定する：ファイル名と保存場所まで決める

次に、書き出しの手順を文章にして固定します。頭の中にある手順は、毎回わずかに違う手順になります。違うから、毎回考える時間が発生します。

決めるのは次の項目です。

・いつ書き出すか（毎週月曜の朝、月末の締切後、など日付と時刻まで） ・どの経路で書き出すか（スプレッドシートからか、CSV からか。両方使わない） ・ファイル名の付け方（例：受付_2026-09-01.csv のように、日付を後ろに固定桁で入れる） ・どこに保存するか（フォルダを1つに決める。デスクトップに置かない） ・開いたあと最初にやること（送信日時の列で並べ替える。前回分との重複を確認する） ・前回分をどう扱うか（上書きしない。前回のファイルは残す）

ファイル名に日付を入れるのは、あとから「どの時点の書き出しか」を追えるようにするためです。受付の仕事では、あとから「9月1日時点で何件だったか」を聞かれる場面が必ず来ます。上書き運用にしていると、その質問に答えられません。

並べ替えを手順に明記しておく理由は、前の章で書いたとおりです。回答が10,000件を超えると CSV が送信日時順に並ばなくなることがあると公式に書かれています。「並んでいるはず」を前提にせず、「毎回並べ替える」を工程にしてしまえば、件数が増えても手順は変わりません。

集計の置き場を決める：3枚に分ける

3つ目が置き場です。1枚のシートの上で、貼り付けも作業も集計もやってしまうと、毎回すべてを作り直すことになります。ブックを3枚のシートに分けます。

1枚目は「生データ」。書き出したものをそのまま貼るだけのシートです。ここには数式を書きません。色も付けません。列も足しません。次回はこのシートの中身を差し替えるだけで済むようにします。差し替えが「貼るだけ」で終わるかどうかが、加工の量を決めます。

2枚目は「作業」。生データを参照して、業務列を持つシートです。受付番号、担当、状態、返信日はここに置きます。生データの各行と作業シートの各行を対応させるために、突き合わせのキーを1つ決めます。メールアドレスと送信日時を組み合わせた文字列など、重複しない値をキーにします。キーが決まっていれば、生データを差し替えても、前回入力した担当や状態が消えません。ここが3枚構成の要です。

3枚目は「集計」。報告に出す形を作るシートです。件数、内訳、状態別の残件数、期間別の推移。ここは作業シートを参照して自動で更新されるようにします。報告のたびにピボットを作り直しているなら、その作り直しをここで1回だけやって、以後は参照範囲を広げるだけにします。

この3枚構成にしておくと、毎月の作業は「1枚目を差し替える」「2枚目の新しい行に担当を入れる」「3枚目を印刷または書き出す」の3工程になります。列の並べ替えも数式の貼り直しも発生しません。

加工の記録を、同じファイルの中に残す

もう1つ足しておくとよいのが、手順を書いた4枚目です。上で決めたこと（列の定義、書き出しの手順、キーの作り方、集計の見方）を、同じブックの中に文章で書いておきます。別ファイルの手順書は、たいてい行方不明になります。同じブックの中にあれば、ファイルを開いた人が必ず見つけます。

受付の担当は入れ替わります。引き継ぎのときに渡すべきものは、完成したブックではなく、そのブックがどういう決めごとで動いているかの説明です。ここが書いてあると、次の担当が独自の加工を足し始めるのを防げます。加工が毎回発生する原因の一定部分は、担当ごとの流儀が積み重なったことにあります。

回答が増えたときに、公式に書かれている上限

表で回し続けられるかどうかを判断するには、どこで何が止まるかを知っておく必要があります。Googleは、回答が多くなったときに効かなくなる機能を公式に明記しています。

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

同じページに書かれている具体的な件数は次のとおりです。

重要なのは、引用のとおり「回答自体は受け付け続け、CSV でダウンロードできる」と明記されている点です。上限に達したからフォームが使えなくなるのではなく、画面上の便利機能から順に効かなくなる、という構造です。だから、CSV を軸にした手順に固定しておくと、件数が増えても運用が変わりません。

フォームそのものの上限も公開されています。公式ヘルプには「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枚あたりのサイズ上限については、今回確認した公式ページには記載が見当たりませんでした。機能や制限が存在しないという意味ではなく、公開資料で確認できなかったという意味です。仕様は変わりますので、実運用の前に最新の公式ページで確認してください。

自動化まで踏み込む場合の数字も公開されています。Forms API の使用量制限は、1分あたり読み取りがプロジェクトあたり975回・ユーザーあたり390回、高コストの読み取りがプロジェクトあたり450回・ユーザーあたり180回、書き込みがプロジェクトあたり375回・ユーザーあたり150回と記載されています。1日あたりのプロジェクト上限はいずれも無制限で、超過時は「429: Too many requests」が返ります。あわせて、API についてはファイルアップロード質問を作成できないこと、2026年6月30日以降に API で作成したフォームは既定で未公開の状態になることが公式に書かれています。後者は、公開しないと回答を受け付けないという意味なので、自動でフォームを量産する運用を考えている場合は要注意です。

表での集計が回らなくなるのは、たいてい件数ではない

上限の話をしたばかりですが、現場で表が回らなくなる理由は、多くの場合10,000件という数字とは無関係です。もっと手前で詰まります。よく聞くのは、次の4つです。

返信したかどうかが、表と別の場所にある

いちばん多いのがこれです。回答は表にある。返信はメールソフトの中にある。この2つが別々にあるかぎり、突き合わせは人の手で行うしかありません。担当が2人になった時点で、同じ人に2通返す事故と、誰も返していない案件が同時に発生します。

対策は前述の「状態」と「返信日」の列ですが、この列は誰かが手で埋めないと埋まりません。埋め忘れが起きると、表は嘘をつきます。件数が増えるほど、埋め忘れの確率も上がります。表での運用が限界に近づいているかどうかは、この列の埋まり具合で判断できます。2割以上が空欄のまま残っているなら、仕組みのほうを変える段階です。

通知を複数人で受け取りたい

フォーム側の通知は、回答タブのその他アイコンから「新しい回答についてのメール通知を受け取る」でオンとオフを切り替えます。スプレッドシート側にも通知ルールがあり、フォームが送信されたときに通知を受け取れます。頻度は1日1回のまとめ（Email - daily digest）か、変更のたび（Email - right away）から選びます。

ただし、公式ヘルプにははっきりと「You can only set up notifications for yourself.」と書かれています。通知の設定は自分に対してしか作れません。複数人で受け取るための標準の手段は、今回確認した公開資料では確認できませんでした。

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

書類を受け取ると、条件が増える

応募書類や見積書のように、ファイルを一緒に受け取る受付では、いくつかの条件が加わります。公式ヘルプには「To answer this question, responders need to sign in to a Google Account.」とあり、ファイルのアップロード質問に答えるには、回答者が Google アカウントにログインする必要があります。日本語版のヘルプにも同じ趣旨で「質問に回答する際にアップロードを実行するには、Google アカウントにログインする必要があります」と書かれています。

社外の不特定多数から書類を集める場面では、ここで応募をやめる人が出ます。ログインを求めた瞬間に離脱する人がどれくらいいるかは事前には分かりませんが、応募の受付では無視できない要素です。

作成者側で設定できることも公式に書かれています。回答者がアップロードできるファイルの種類、1回の回答でアップロードできるファイル数の上限、1ファイルの最大サイズを指定できます。フォーム全体で集めるファイルの合計容量の上限を設定する項目もラーニング センターに説明があります。ただし、そこで選べる具体的な数値の一覧は、公開資料では確認できませんでした。

保存先は「For the form owner, uploaded files are stored in a new folder on Google Drive.」と書かれており、フォームのオーナーの Google ドライブに新しいフォルダが作られてそこに入ります。ドライブ側の上限として、各ユーザーは24時間以内に750GBまでアップロードまたはコピーでき、1ファイルは最大5TBまでと記載されています。このページに Google フォーム固有の記載は見当たりませんでした。

そのほか、共有ドライブからのファイルアップロードはできないこと、ファイルのアップロード質問を含むフォームはメールに埋め込めないことも公式に明記されています。メールに埋め込んで回答してもらう運用を考えている場合は、この点が効いてきます。

自動返信の本文を書き換えたい

受け付けたことを相手に伝える手段として、標準機能では回答のコピーを回答者に送れます。メールアドレスを収集している場合に設定でき、設定画面の「回答」から「送信済みの回答のコピーを回答者に送信」で「リクエストされた場合」か「常に」を選びます。

ただし、これは回答内容の控えであって、案内文ではありません。本文を自由に書いた自動返信を標準機能として送れるという記載は、公開資料では確認できませんでした。公式ヘルプは代わりに Form notifications アドオンを案内しており、追加の通知やカスタマイズしたフォローアップ メールを扱う旨が書かれています。

また、公式ヘルプには「In certain circumstances, responders may not receive the expected response receipts due to spam filters or other counter-abuse measures.」という注記があります。迷惑メール対策で控えが届かないことがある、と公式が明記しているわけです。受け付けた事実を相手に確実に伝えたい受付では、控えメールだけに頼らない設計が必要になります。

Apps Script で自前の自動返信を組む場合の上限も公開されています。公式の割り当て表では、1日のメール送信先が消費者向けアカウントで100件、Google Workspace で1,500件。トリガーの総実行時間は消費者向けアカウントで1日90分、Google Workspace で1日6時間。1回の実行時間はどちらも6分です。これらは予告なく変更される可能性があると注記されています。あわせて、スクリプトの実行や API リクエストではトリガーが動かないことも明記されています。

Apps Script には「On form submit」というインストール型トリガーが用意されており、フォーム用と、回答がスプレッドシートに送られる場合のスプレッドシート用の2種類があります。インストール型トリガーの利点として、認可が必要なサービスを呼び出せることが挙げられています。ここまで作り込めば自動返信は実現できますが、作った人が異動したあと誰も直せなくなる、という別の問題が生まれます。

権限と締切まわりで、先に決めておくとよいこと

集計の話から少し離れますが、表を回す前提として権限を整理しておく価値があります。ここが曖昧だと、集計ファイルが「誰のものか分からないファイル」になります。

共同編集者は、共有画面から名前やグループを入れて Editor を選ぶことで追加します。ラーニング センターには「招待したユーザーは、回答、回答の保存場所など、フォームのどの部分でも編集できます」と書かれています。つまり編集者は回答そのものにも触れます。受付の記録を扱う以上、誰を編集者にするかは事前に決めておくべきです。共同編集者の人数上限については、公開資料では確認できませんでした。

オーナーの変更は、対象者を編集者にしたうえで、共有画面から所有権の譲渡を選びます。担当者が異動する前にこれをやっておかないと、アップロードされたファイルがオーナーのドライブに残ったまま、誰も触れない状態になります。

回答者側の公開範囲についても公式に記載があります。フォームを公開すると回答者がアクセスでき、未公開の状態ではリンクを持っていてもアクセスできません。全般的なアクセス権として、リンクを知っている全員に許可するか、対象のオーディエンスに限定するかを選べます。ドメイン、信頼できるオーディエンス、ユーザーのグループに制限することもできます。回答者ごとにアクセスレベルを選ぶこともでき、有効期限も設定できると書かれています。

回答を1回に制限する設定もありますが、この場合はフォームにアクセスして入力するために Google アカウントへのログインが必要になると公式に明記されています。重複応募を防ぎたい要望と、ログインを求めない要望は両立しません。どちらを取るかは、受付の性質で決める話になります。

Google Workspace の管理者側では、フォームを有効にするために Google ドライブも有効にする必要があると書かれています。設定の反映には最長で24時間ほどかかることがあるとも記載されています。外部共有についても、ドメイン内のユーザーが外部で作成されたフォームに回答できるかどうか、回答のためにフォームを外部と共有できるかどうかを管理者が選べます。急に「フォームが開けない」と言われたときは、ここを疑う価値があります。

なお、個人情報を含む回答を扱う場合の法的な取り扱いについては、この記事で断定はしません。所管の窓口や専門家に確かめてください。制度の考え方については個人情報保護委員会の公開情報が出発点になります。

表を続けるか、受付そのものを変えるかを、何で決めるか

ここまでの内容を踏まえると、判断の物差しは4つに絞れます。件数ではありません。

1つ目は、受け付けたあとに人が動くかどうかです。動かないなら表で足ります。動くなら、動いた記録をどこに置くかを決める必要があります。

2つ目は、受ける人が何人いるかです。1人なら記憶で回ります。2人以上になった瞬間に、状態と担当を表に書く必要が生まれ、書き忘れが発生します。

3つ目は、返信の本文を自由に書きたいかどうかです。控えの送信で足りるなら標準機能で済みます。案内文を差し替えたい、条件で文面を変えたいとなると、アドオンかスクリプトの話になり、そこから保守の担当者が必要になります。

4つ目は、書類を受け取るかどうかです。受け取るなら、回答者にログインを求めることの是非、保存先のドライブの管理、オーナーが異動したときの引き継ぎまでを設計に入れることになります。

この4つのうち3つ以上が該当するなら、集計の加工を減らす工夫だけでは追いつかなくなります。そこから先は、送信されたあとを回す道具が最初からそろっている形の受付に移すかどうかの検討に入ります。移すかどうかは別として、いま何が足りていないのかは、上の4つで言語化できます。

受付の形ごとに、どこで加工が発生しているか

受け付ける対象によって、表の加工が発生する場所は違います。用途別に整理しておくと、自分の窓口がどこで詰まっているのかを見つけやすくなります。

応募を受け付ける窓口では、書類の受け取りと選考の段階管理が同時に発生します。書類はドライブに、選考の進み具合は表に、連絡はメールにあり、3か所を人が突き合わせています。応募の受付でどこまでを1つの画面に置けるかは、採用の応募受付にまとめてあります。ログインを求めずに書類を受け取れるかどうかが、応募数に直接効きます。

助成金や公募の受付では、締切と要件確認が中心になります。期限を過ぎた提出をどう扱うか、不備の差し戻しをどう記録するかで、表の列が増え続けます。この形の受付については助成金・公募の受付で整理しています。締切の自動化はGoogleフォームの標準機能でも2026年1月から可能になっているので、そこだけなら移す必要はありません。

日々届く問い合わせを受ける窓口では、返信の記録が最大の論点です。誰が返したか、いつ返したか、まだ返していないのはどれか。この3つが表に残るかどうかで、二重返信の発生率が変わります。問い合わせの受付に、この形の受付で必要になる項目をまとめています。

イベントや講座の申し込みでは、定員と当日の名簿が論点になります。定員に達したら止める、キャンセルが出たら1枠戻す、当日の受付名簿を出す、という流れです。イベントの申し込みと講座の受講申し込みに、それぞれの受付で発生する作業を書いています。なお、質問の選択肢ごとに定員を設ける標準機能については、公開資料では確認できませんでした。日程ごとの残席管理を表でやっている窓口が多いのは、このためです。

施設の利用申請では、申請から承認までの往復が発生します。誰が承認したかを残す必要があり、表の列が「状態」だけでは足りなくなります。施設利用の申請に、往復のある受付での組み立て方を書いています。

入会の申し込みでは、申込者の情報がそのまま名簿になります。受付表と名簿が同じものである以上、書き出しのたびに新しいファイルを作る運用は破綻します。会員の入会申し込みを参照してください。修理やサポートの受付も、1件が長く続く点で似た構造です。修理・サポートの受付に、対応が複数回にわたる受付での記録の残し方をまとめています。

いま使っている道具のまま進めるか、比べてから決めるか

ここまで書いてきた「列を決める」「手順を固定する」「置き場を3枚に分ける」は、Googleフォームを使い続ける前提でも効果があります。まずこの3つをやってみて、それでも毎回の加工が減らないなら、道具の側を見直す段階です。

Googleフォームでどこまでできて、どこから別の道具が要るのかは、公式資料に書かれている仕様を並べてGoogleフォームとの比較に整理しました。この記事で触れた件数の上限、通知の制約、ファイルアップロードの条件も、そこで一覧にしています。

WordPressのサイトにフォームを置いている場合は、事情が少し違います。送信されたあとの記録をどこに置くかが、プラグインの構成に左右されるためです。その前提での違いはContact Form 7との比較にまとめています。Microsoft 365 を使っている組織なら、エクセルとの相性という観点でMicrosoft Formsとの比較も見る価値があります。

受け付けたあとにどこまで1つの画面で完結するかは、できることに機能単位で書いています。実際の画面の動きを先に見たい場合は動くところを見るから確認できます。費用の考え方は料金に、導入前によく出る疑問はよくある質問にまとめました。

集計の加工が減ったかどうかを、何で測るか

最後に、この記事の内容を実行したあとの確かめ方を書いておきます。作業が減ったかどうかは感覚では分かりません。次の3つを1か月だけ記録すると、はっきりします。

1つ目は、書き出してから報告を出すまでにかかった時間です。ストップウォッチである必要はなく、開始と終了の時刻をメモするだけで十分です。列と手順と置き場を決める前と後で比べます。3枚構成が効いていれば、2回目以降で明確に短くなります。

2つ目は、状態列の空欄の割合です。受け付けた件数のうち、状態が入っていない行がどれだけあるか。これが増え続けるなら、表に書く運用そのものが持たなくなっています。件数が理由ではなく、書く手間が理由です。

3つ目は、同じ相手に2回返した件数と、返し忘れた件数です。ゼロが理想ですが、記録しないと存在自体に気づきません。この数が増えたタイミングが、受付の形を変える検討に入る合図になります。

これらは、フォームの性能とは関係のない指標です。受付を回すのは表ではなく人なので、人の動きを測らないと判断できません。Googleフォームは集めるところまでを確実にこなす道具です。集めたあとをどこで回すかは、上の3つの数字を見てから決めれば十分間に合います。

Q1. Googleフォームの回答をエクセルで集計するとき、まず何を決めればよいですか？

列、書き出しの手順、集計の置き場の3つです。フォームが作る設問列は触らず、受付番号や担当や状態などの業務列を右側にまとめます。書き出しは日時とファイル名の付け方まで文章で固定し、ブックは生データ・作業・集計の3枚に分けます。この3つを決めると、翌月からは1枚目を差し替えるだけで済みます。

Q2. 回答が何件を超えると、集計に影響が出ますか？

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

Q3. 新しい回答の通知を、複数人で受け取れますか？

スプレッドシートの通知ルールについて、公式ヘルプは自分に対してのみ設定できると明記しています。複数人に送る標準の手段は、今回確認した公開資料では確認できませんでした。公式が案内しているのはForm Notificationsアドオン（提供元Google、価格無料）で、オーナーと共同編集者に回答数のしきい値で通知を送れると掲載されています。

Q4. 応募書類をフォームで受け取るとき、注意することはありますか？

ファイルのアップロード質問に答えるには、回答者がGoogleアカウントにログインする必要があると公式に書かれています。社外から集める場合はここで離脱が出ます。また共有ドライブからのアップロードはできず、アップロード質問を含むフォームはメールに埋め込めません。ファイルはオーナーのドライブの新しいフォルダに保存されるため、担当者の異動前に所有権の譲渡を済ませてください。