フォームの回答をシートに記録して担当者へ通知する流れの作り方

1. 先に設計メモを1枚書く

画面を開く前に、次の表を埋めます。空欄が残る部分が、後で止まりやすい部分です。

• トリガー、決めること：何の回答で動くか／どれくらいの遅れが許されるか、説明用の例：「備品申請フォーム」の送信／10〜15分以内なら可
• 記録、決めること：保存先／列名／1回答=1行にするか／受付IDの付け方、説明用の例：「申請ログ」シートに追記／受付ID・受信日時・申請者・品目・数量・緊急度・担当・状態
• 通知、決めること：誰に／どこへ／何を載せるか／失敗時は誰が気づくか、説明用の例：緊急度「高」は総務の担当者へチャットで、それ以外は日次確認／件名・緊急度・シートの該当行リンク

列名を先に固定する

フォームの質問文は後から変わりがちです。シートの列名は、質問文とは別に自分で決めた短い名前（例：申請者）にして、ツール側で「質問→列」を対応づけます。質問文を直しても、シートの列が崩れにくくなります。

状態列を1つ足す

「状態」列に 未対応 と入れて記録します。担当者が対応後に 対応中・完了 へ書き換えれば、通知を見落としても、シートで未対応だけを絞り込めます。

2. トリガー：即時か、定期確認かで選ぶ

トリガーには、回答の送信をきっかけに動く即時型と、一定間隔で新着を見に行く型があります。この違いは通知の遅れに影響しますが、即時型でも処理や送信に時間がかかるため、必要な時間内に通知が届くかテストします。

• n8n：Form Triggerノードが、フォームのページ自体を生成します。送信をきっかけにワークフローが始まり、認証はBasic Auth、n8nユーザー認証、なしから選べます。テスト用URLと本番用URLがあり、本番ではデータがエディタ画面に表示されない点に注意が必要です（n8n公式：Form Trigger）。Google Formsを使う場合は別の接続方法になるため、フォーム自体をn8nで作るかどうかも設計メモに書きます。
• Zapier：公式のGoogle Forms×Google Sheetsの連携ページでは、トリガー「New Form Response」（Instant表記）と、アクション「Create Spreadsheet Row」の組み合わせが紹介されています。このテンプレートには、回答をスプレッドシートへ保存する設定済みのフォームが必要です。追記先は、その回答保存先とは別の「申請ログ」シートにして、同じ回答を二重に記録しないようにします（Zapier：Google Forms + Google Sheets）。
• Make：シナリオは既定で15分ごとに実行され、最短間隔はプランで異なります。実行間隔はスケジュール設定で確認します（Make：Schedule a scenario）。名前が「Watch」で始まるモジュールは、一定間隔で新着を確認するポーリング型の典型で、即時型は稲妻アイコンで見分けます（Make：Types of modules）。Google Formsのモジュールがどちらの型かは、追加したときの表示で確認してください。

判断表

• 数分の遅れも困る（問い合わせ初動など）、向く選び方：即時型のトリガーを使う。Makeならモジュールに稲妻表記があるか確認
• 15分程度の遅れは許容、向く選び方：どのツールでも可。ポーリング型でも間隔を設計メモに書いておく
• フォームも自前で用意したい、向く選び方：n8nのForm Triggerなど、フォーム生成込みの方法
• 既存のGoogleフォームを変えたくない、向く選び方：ZapierやMakeのGoogle Forms連携

3. 記録：通知より先に、1回答1行で追記する

シートへの書き込みは「行を追加する」操作を使います。n8nのGoogle Sheetsノードには、新規行を作るAppend Rowと、既存行があれば更新するAppend or Update Rowがあります（n8n公式：Google Sheets）。Zapierなら「Create Spreadsheet Row」が対応します。

迷ったら単純な追記を選びます。 更新型は、照合に使う列の値が重複すると意図しない行を書き換える可能性があるためです。同じ回答の再処理による重複を防ぎたいときは、再処理でも変わらない受付IDを列に入れて、追記前に既存行を検索する手順を足します。同時実行では検索と追記が競合するため、実行を直列化するなどの対策も必要です。内容が同じ別の回答も除外するかは、別途決めます。

列の対応づけ（説明用の例）

• 受付ID、入れる値：回答元の一意な回答ID。ない場合は初回受信時にUUIDなどで発行・保存し、同じ回答の再処理でも同じIDを使う。日時だけでは重複する可能性がある
• 受信日時、入れる値：回答のタイムスタンプ
• 申請者／品目／数量／緊急度、入れる値：フォームの各回答
• 担当、入れる値：緊急度が「高」なら総務A、それ以外は空欄
• 状態、入れる値：未対応（固定値）

4. 通知：短く、判断できる情報だけを載せる

通知は「誰が・何をすればいいか」が1画面で分かる内容にします。回答の全文を送らず、シートへのリンクと最小限の項目にすると、個人情報がチャット側に広く残るのを避けられます。

通知文の例（説明用）：

【備品申請・未対応】REQ-20261027-0930
緊急度：高／品目：モニターアーム ×1
申請者：山田（総務部）
確認先：<シートの該当行リンク>
対応後は「状態」列を「対応中」に変えてください

送信先は、メール、Slack、Teamsなど普段見ているものを選びます。担当者を回答内容で分ける場合は、分岐の条件を設計メモの「通知」欄に書き、条件に当てはまらない回答の行き先（例：共通の受付窓口）も必ず決めます。これを決めないと、想定外の回答が誰にも通知されません。

5. 公開前の動作チェック項目

テストは、実在の人の情報ではなく、ダミーの回答で行います。失敗させるテストには、テスト用のシートと通知先を使います。

1. 最小の回答：必須項目だけ入力して送る。シートに1行記録され、通知する条件なら設計した時間内に1通届くか。日次確認に回す条件なら、確認対象として残るか。
2. 全項目の回答：全部入力して送る。各項目が正しい列に入るか、列ずれがないか。
3. 条件の分岐：緊急度「高」と「低」を1件ずつ送る。通知先が設計メモ通りか。
4. 条件外の回答：想定していない選択肢や空欄を送る。共通窓口へ届くか。
5. 長文・改行・記号：長い文章や改行、カンマ、引用符を入れる。シートで崩れないか、通知が途切れないか。
6. 同じ内容の連続送信：2回送る。2行できる想定か、重複排除が働く想定か、設計通りか。
7. 記録失敗時の挙動：接続アカウントのテスト用シートへの書き込み権限を一時的に外して失敗させる。通知が「記録されていないのに届く」状態になっていないか。確認後は権限を戻す。
8. 通知失敗時の気づき方：テスト用の通知先を無効な宛先にして失敗させる。誰がどの実行履歴やエラー通知で気づくか。復旧時に通知だけを再送できるか、全体を再実行するなら記録が重複しないかも確認する。
9. 本番切り替え：n8nなら保存・公開したワークフローの本番用URLを使う。Makeならスケジュールの有効化と、対応するトリガーの取得開始位置（Choose where to start）を確認する。開始位置は後から設定し直せるため、テスト済みの回答を再取得しない設定か確認する（Make：Select the first bundle to process）。
10. 後片付け：テスト行を削除し、状態列とテスト通知が本番の運用に混ざらないようにする。

AIに任せられるところ、人が確認するところ

ChatGPTなどに頼めるのは、列名の案、通知文の文面、テスト用ダミー回答の作成です。次のように依頼します。

次の設計メモをもとに、(1) テスト用のダミー回答を5件（通常3件、空欄あり1件、長文・記号入り1件）、
(2) 通知文の改善案を2パターン作ってください。実在しそうな氏名や連絡先は使わないでください。
【設計メモ】……（上の表を貼る）

一方、権限設定、通知先の宛先、個人情報をどこまで通知に載せるかは、人が決めて確認します。実際の回答をAIに貼る必要はありません。ダミーで十分です。

補足：ツールごとの上限と料金

実行回数の上限や価格はプランと時期で変わるため、この記事では扱いません。導入前に、各社の最新の料金ページで、想定する月間の回答数に収まるかを確認してください。