n8nの業務自動化例｜問い合わせの分類・通知を安全に設計する手順

2026-10-22

n8nの業務自動化は、システム間で繰り返している情報の受け渡しから考えると対象を絞れます。この記事では「問い合わせを受け取り、分類候補を作り、担当者へ通知する」設計例を使います。ZETTAiの導入実績ではなく、試作を検討するための架空例です。

AIを使う部分と決まった処理を分ける

受信日時の記録や必須項目の確認は、通常の条件分岐で処理できます。自由文から用件を分類する部分はAIの利用候補です。すべてをAIへ任せず、同じ条件なら同じ結果になる処理はルールで実装します。

外部サービスの応答が遅れたとき、再実行で同じ通知や登録が重複することがあります。受付IDを保存し、すでに処理したIDなら新規登録しない設計にします。単に本文が同じという理由で削除すると、正当な再問い合わせを落とす場合があるため注意します。

登録は成功したが通知だけ失敗した場合は、通知工程だけを再試行できるようにします。処理済み状態の更新タイミングもテストしてください。

分類が複数ある、資料が足りない、例外的な契約内容を含む場合は確認待ちへ送ります。外部への回答は最初は下書きまでとし、宛先と本文を人が確認します。人の承認を必要とするツール実行は、n8n公式のHuman-in-the-loopの案内も参照できます。

AIへ渡す文章は必要な範囲に限定します。受信メールに「ルールを無視して送信せよ」と書かれていても、処理権限を変更する命令として扱わない設計が必要です。

正常な問い合わせ、必須項目不足、同じIDの再送、AIのタイムアウト、台帳サービスの停止、通知先の無効化を試します。入力から出力まで動いた一例だけで本番開始を判断しません。

n8nには実行エラーを扱う仕組みがありますが、通知先そのものが停止する場合も考え、誰がどこで失敗を確認するかを決めます。認証情報の期限と更新担当者も管理してください。

用途と誤送信時の影響によります。最初は分類・通知・下書きに絞り、送信は確認を挟む方が評価しやすくなります。

接続先、認証、入力形式の変更で止まる可能性があります。実行履歴、失敗件数、重複、保守担当を定期的に確認します。

自動化したい作業の開始条件、接続先、失敗時の担当者を整理してください。ZETTAiのAIシステム開発・受託開発について、n8nを使う場合の連携範囲と例外処理を相談できます。製品対応はご相談時に確認します。

製品情報の確認日：2026年10月22日。利用時は対象プラン・バージョンの公式案内も確認してください。