定型業務をAIで自動化しても、入力不足、重複、期限切れ、外部サービス停止などの例外は必ず起こります。例外を無視して処理を進めると、誤送信や二重登録、公開事故につながります。
原因は正常系の速さだけを設計し、どの条件で止め、誰へ戻し、どこから再開するかを決めていないことです。例外処理は後付けではなく本番条件の一部です。
この記事では「AI 業務自動化 例外処理」の運用を、四つの実務工程に分けて解説します。株式会社ラクボは、ツール導入だけでなく、入力、承認、実行、記録、改善までを少人数で続けられる業務として設計しています。
例外を入力・判断・外部連携・権限の四種類に分ける
最初に例外を、入力不足や形式違い、判断不能、API停止やタイムアウト、権限不足へ分類します。同じエラー文でも業務上の影響が違うため、金銭、顧客連絡、公開、削除を伴う処理は別の重大度にします。
各種類に検知条件、処理中の案件ID、影響範囲、担当部署を設定します。空欄をAIが推測で埋めることや、失敗を成功として次工程へ渡すことを禁止します。
危険な状態は自動継続せず安全側で停止する
危険な例外では、最後に確認できた状態を保存して停止します。無制限の再試行は二重処理や費用増加を招くため、回数と間隔を決めます。外部応答が不明な時は、未実行と決めつけず相手側の状態を照合します。
顧客送信、契約、決済、公開、削除は人の承認を残します。軽微な通信失敗だけを自動再試行し、内容や対象が変わる場合は担当者へ戻します。
担当者へ根拠と再開地点を一つにまとめて渡す
通知には案件ID、失敗工程、入力、直前の成功、エラー、試した対応、推奨する次の操作、期限を含めます。ログだけを丸投げせず、担当者が判断できる要約と原文を分けます。
再開は最初からやり直さず、確認済みの地点から行います。ただし外部へ送信済みか不明な場合は、送信履歴や相手IDを確認してから続けます。担当者と再開者を同じ台帳に残します。
再発率と復旧時間から自動化ルールを改善する
月次で例外件数、重大度、復旧時間、手作業、同じ原因の再発を確認します。多い例外は入力画面や事前検査へ戻し、発生後の対応より発生前の防止へ移します。
最初は一業務の代表例外十件を故意に発生させ、停止と再開を試します。正常系と例外処理を一緒に整えたい場合は、ラクボのAI顧問・AI部門代行をご覧ください。例外処理の設計を相談できます。
例外台帳では、技術的なエラー名だけでなく、顧客影響、金額影響、公開範囲、期限への影響を分けて記録します。例えば通信タイムアウトは同じでも、社内集計の再取得と顧客への契約通知では許容できる再試行が異なります。処理の重要度に応じて、自動再開、担当確認、責任者承認の三段階を決めておくと、障害時に判断がぶれません。
本番前テストでは、入力欠損、重複要求、権限切れ、外部サービス遅延、途中応答、送信済みか不明な状態を意図的に作ります。停止通知が届くだけでなく、元の案件が保全され、担当者が一度だけ再開でき、処理後に完了記録が残るところまで確認します。復旧時間の目標も重大度別に置き、長引いた例外から手順や監視を改善します。
導入時は、通常の成功例だけでなく、入力が足りない例、判断が分かれる例、途中で外部連携が止まる例を含む検証セットを作ります。担当者、承認者、復旧担当が同じ完了条件を使い、結果を元データと照合できる状態にします。変更は一度に広げず、対象件数と影響範囲を限定して試し、合格記録を確認してから次の範囲へ進めます。また、月次の振り返りでは処理時間だけでなく、差し戻し、見逃し、手作業、利用者からの指摘を確認します。自動化率が上がっても確認負担や重大な誤りが増える場合は、入力条件や承認点を見直します。例外時に安全に止まり、根拠を示して人へ戻り、再開後まで追跡できることが、継続運用の前提です。
運用記録には、対象、入力、担当者、確認日時、合否、修正理由、再実行結果を残します。成功例だけでなく停止した例も保存し、同じ問題を繰り返さないよう共通ルールへ戻します。担当者が変わっても、どこで止め、誰が承認し、何をもって完了とするか追える状態が重要です。