フォーム受付を台帳へ。一度だけ登録する自動化の設計

台帳の列を先に決める

この記事は公式情報＋設計例です。稼働済みのテンプレートや実測結果ではありません。例として、社内の備品依頼をフォームで受け付け、スプレッドシートへ登録する処理を考えます。最初に受付番号、受付日時、依頼種別、数量、処理状態、最終更新日時の列を決めます。個人情報は業務に必要な項目だけに絞ります。

受付番号は同じ申請を見分けるための鍵です。再試行するたびに新しい番号を作ると、重複の検出に使えません。送信元が発行する識別子を保存するか、初回受付で番号を発行し、その後の処理で引き継ぐ設計にします。

受信、検証、保存を分ける

n8n Form Triggerはフォーム送信を起点に処理を始められ、Google Sheetsノードには行の追加や更新などの操作があります。MakeではWebhookを受信してシナリオを開始する方式を選べます。既存フォームを使う場合は、そのサービスが送信後の連携に対応するかを確認してください。

• 受信：受付番号と受信時刻を保存する。
• 検証：必須項目、数量の範囲、選択肢の値を確認する。
• 照合：同じ受付番号の完了記録があれば追加を止める。
• 保存：台帳への書き込みを確かめてから完了状態にする。
• 例外：入力不足と通信障害を別の状態で記録する。

検索してから追加するだけでは不十分な場合

同時に同じ依頼が届くと、二つの処理がともに『未登録』と判断して追加する可能性があります。小規模な検証では、書き込みを一つの順次処理へ集めます。複数の経路が台帳を更新する運用なら、受付番号の重複をデータベース側で拒否できる構成も検討します。単なる検索と追加を、重複しない保証として扱わないことが重要です。

また、通信が切れても保存だけ成功している場合があります。再試行では受付番号を照合し、完了済みなら次の工程へ進みます。通知を追加する場合は通知済みの記録も持ち、台帳の書き直しが二重送信を引き起こさないようにします。

公開前に再送と障害を確かめる

テストでは正常な入力だけでなく、同じ番号の再送、数量の空欄、接続権限の解除を試します。保存件数と元の受付件数を照合し、未処理の依頼が見つかることまで確認します。n8nのフォームはテスト用と本番用のURLが異なるため、本番用の経路でも検証が必要です。

Makeの未完了実行の保存は初期状態では無効です。必要な保存・再試行の設定を確認し、何度も失敗する依頼は自動処理を止めて例外一覧へ移します。無制限の再試行ではなく、回数、待ち時間、打ち切り条件を決めてから運用を始めます。