AI自動化の例外処理を決める｜入力不足・重複・失敗時の業務ルール

フォームを受け取り、AIで内容を分類し、担当者へ通知する。正常な一件が流れたら完成に見えますが、実際の仕事では、連絡先がない、同じ申込が二度届く、通知先が応答しない、といったことが起こります。

自動化を始める前に決めたいのは、処理できない一件をどこへ残し、誰がどう再開するかです。この記事では、社内の備品申請を振り分ける架空例で、実装担当者へ渡せる業務ルール表を作ります。特定ツールを契約・導入する前でも整理できます。

一つの申請を、受付から完了まで追えるようにする

最初に、申請を識別するIDを決めます。連携を実行するたびに変わる実行IDとは別に、受付時に付いた申請IDを引き継ぎます。これがないと、二回届いた申請なのか、同じ申請を再実行したのか見分けにくくなります。

記録には、申請ID、受付時刻、処理状態、担当、最後に完了した処理を持たせます。AIの自由文を状態欄へ入れるより、「受付済み」「確認待ち」「通知待ち」「完了」のような固定値を使う方が、処理を再開する場所を決めやすくなります。

受付 → 入力確認 → 分類 → 担当確認 → 通知 → 完了

どの段階でも、条件を満たさない申請は確認待ちへ残す。記録から消したり、成功扱いで通したりしない。

「AIが迷った」と「システムが失敗した」を分ける

同じ確認待ちでも、再試行すればよいものと、人の判断が必要なものがあります。

起きたこと	処理の例	再開する条件
利用日が未入力	申請を保存し、入力不足へ分ける	申請者の補足を受け取った
備品名が曖昧	AIの分類候補と原文を担当者へ回す	担当者が分類を決めた
同じ申請IDを再受信	処理済み状態を確認する	未完了部分だけを再開できる
通知サービスが一時的に応答しない	回数・間隔を決めて再試行する	通知成功を確認した
通知できたか不明	再送前に送信先の状態を調べる	送信済みか未送信かを判断できた
通知先の権限がない	自動再試行を止め管理担当へ回す	権限と宛先を修正した

表が収まらない場合は、左右に動かして読めます。

「もう一度実行する」をすべての解決策にしないことが要点です。入力不足は何回AIへ渡しても埋まりません。通知が実は成功していた場合、最初からやり直すと同じ連絡を二度送るおそれがあります。

二重通知を防ぐには、送信の前後を記録する

架空の申請R120を例に考えます。担当の分類までは完了したものの、通知サービスからの応答が途切れました。この時点で「失敗だから未送信」と決めず、結果不明として残します。

送信先が重複防止用のキーを扱えるなら、同じ業務の再送で同じキーを使う設計を検討できます。対応していなければ、申請ID・通知種類・通知先を組にした送信記録と、送信先での確認方法を設けます。単純な送信済みフラグだけでは、同時実行や送信直後の停止まで防げないため、実装時は同じ申請を並行して処理しない仕組みも必要です。

この設計で目指すのは、どんな障害でも必ず一回だけ処理されると断言することではありません。不明な状態を発見し、根拠を見て復旧できるようにすることです。自動再開できない申請が少数残る方が、重複送信を見逃すよりよい業務もあります。

AIに例外を洗い出してもらう依頼文

業務の流れと、実際に困った事例を渡します。社内情報を使う場合は承認された環境で、不要な個人情報を外してください。

備品申請の振り分け業務について、例外処理表を作ってください。
通常の流れ：フォーム受付→入力確認→備品の分類→担当決定→通知。
完了の定義：担当者への通知成功を記録できたこと。

入力不足、分類不能、重複受付、外部サービス失敗、結果不明を分ける。
各例外に、検知方法、保存する情報、戻し先、自動再試行の可否、再開条件を書く。
不明な社内ルールや権限を推測しない。
例外を理由に元の申請を捨てたり、成功扱いにしたりしない。
担当者・回数・期限が未決なら、その項目を明示する。

出てきた表は、業務担当者と実装担当者で読みます。「管理者に通知する」だけなら、誰がどの画面を見て申請を復旧するのかまで具体化します。担当不在の場合の引継ぎ先も、普段の業務体制に合わせて決めてください。

n8nなどの機能は、決めたルールを実装するために使う

n8nの公式ドキュメントには、失敗時に別のエラーワークフローを動かす仕組みがあり、Error Triggerから開始する構成が説明されています。また、Stop And Errorを使って、指定した条件で処理を失敗にできることも案内されています。

これは、入力不足を自動的に発見したり、二重通知を必ず防いだりする保証ではありません。業務上止めたい条件を実装し、どの失敗を誰へ知らせるかを決める必要があります。ツールのエラー機能と、自社の例外処理表を対応させて使います。

正常終了したのに分類を間違えた場合など、システム上のエラーにならない誤りもあります。件数の突き合わせや、人が確認するサンプルを別に設けておくと発見しやすくなります。

分岐を実装するところで止まるなら、学ぶ内容から選ぶ

例外処理表は作れたものの、n8nのノードをどうつなぐか分からない。そうした段階では、稼働用サーバーを先に契約するより、ワークフローを自分で組む基礎を学ぶ方が前に進めます。

DMM 生成AI CAMP 学び放題は、n8nの基本操作から生成AIを組み込むワークフローまでを扱うコースを案内しています。記事を読んで一件試せる人は独学を続けられますが、条件分岐やデータの受け渡しで何度も止まる人には、体系的に学ぶ選択肢です。

受講前には「この備品申請の流れを、自分で組めるようになるために何を学ぶか」を具体的にしてください。業務システムの受託開発や、本番の例外処理の保証が付くサービスではありません。教材の範囲と質問の方法、学習時間を確認してから料金を判断します。

公開前に、正常な一件だけでなく壊した入力も流す

外部への実通知を行わないテスト先を用意し、次を試します。

必須項目を一つ空欄にする。確認待ちへ残るか。
同じ申請IDを二回渡す。二件の新規申請にならないか。
分類できない文章を渡す。勝手な分類で通知しないか。
通知先をテスト用に失敗させる。上限なく再試行しないか。
途中まで完了した申請を再開する。完了済みの処理を繰り返さないか。

確認待ちの件数と元の申請件数も突き合わせます。「通常処理10件、確認待ち2件、合計12件」のように、行き先が説明できることを確認してください。動かなかったこと自体より、何件がどこで止まったか分からないことが運用の負担になります。

週次集計へ広げるなら、週報をAIで自動作成する仕組みで、未報告や再実行の扱いも確認できます。動かす場所を選ぶ段階では、AIエージェントクラウドとVPSの比較を読み、保守を自分で担う範囲から選んでください。先に例外処理表があれば、必要な管理機能も具体的になります。