n8nで問い合わせ受付を自動化する方法｜重複登録・失敗時の復旧まで設計する

情報確認日：2026年10月14日（本文で引用した公式資料を再確認）。

問い合わせを台帳へ転記する作業を自動化すると、入力の取りこぼしを減らせます。ただし、処理が途中で止まったときに全体を実行し直すだけでは、同じ問い合わせを二重登録したり、担当者へ何度も通知したりします。

この記事では、n8nを使う際の実務設計として「受付→入力確認→台帳登録→社内通知」を具体化します。公式資料をもとにした設計ガイドであり、掲載例はAIGNALが作成した説明用の例です。接続先での動作を実機検証した完成ワークフローではありません。

まず決めるのは、入力と完了条件

最初の対象は、問い合わせへの自動返信まで広げず、社内台帳と担当者への通知に絞ります。フォーム側で受付IDを発行できるなら、そのIDを処理の追跡に使います。

項目	設計例
入力	受付ID、受付日時、問い合わせ区分、本文
台帳の完了	受付IDに対応する行が1件あり、登録先IDを記録できた
通知の完了	台帳へのリンクを担当者へ通知し、成否を記録できた
人へ戻す条件	必須項目不足、区分不明、登録結果が確認できない

通知には本文全体を貼らず、受付IDと台帳リンクを使う設計が扱いやすくなります。個人情報を閲覧できる人を台帳側で管理できるためです。

n8nの公式入門では、トリガーと処理ノードをつなぎ、データを渡す形でワークフローを作ります。[1] 問い合わせ受付では、次の順で小さく組み立てます。

AI分類を追加する場合も、最初は元の区分とAIの分類候補を並べて確認します。AIが返した「確信度」を、そのまま正答率として扱わないでください。運用データで分類の誤りを調べてから、自動処理の対象を決めます。

「検索して、なければ登録」という流れでも、同時に2件の処理が動くと両方が未登録と判断することがあります。保存先で受付IDの一意制約や重複を防ぐAPIを利用できる場合は、それを使う設計にします。

表計算を保存先にする場合は、行を検索するだけで強い重複防止を保証できません。同時処理を制限する方法や、登録処理を一つに集約する方法を検討し、二重送信の試験を行います。使える制御は環境と接続先で確認が必要です。

運用記録は、例えば次の状態に分けます。これはn8n標準の状態名ではなく、業務側で管理する項目の例です。

APIがタイムアウトしても、登録先では処理が完了している場合があります。失敗表示だけで再登録せず、受付IDで保存先を検索してください。台帳が登録済みで通知だけ失敗したなら、台帳登録を飛ばして通知から再開する設計にします。

問い合わせを消さないため、受付記録は処理結果と分けて残します。また、認証情報を本文やログに書かず、接続権限と実行データの保存範囲を決めます。自前運用ではサーバーの更新、バックアップ、復旧作業の担当も必要です。

確認に要した時間と月間実行量も記録します。接続AIや保存先の費用はn8nとは別の条件で発生し得るため、月額だけで採算を判断しない設計にします。

最初の成果は、ノードの多さではなく「止まった問い合わせを担当者が1件ずつ追えること」です。受付ID、登録先ID、未通知の一覧がそろえば、AI分類を後から追加するときも変更の影響を確認しやすくなります。