業務自動化で残る例外処理：人が判断する工程を組み込む方法

業務自動化を進めると、必ず「自動では処理しきれないもの」が残ります。結論から言うと、例外処理はなくすものではなく、最初から業務フローの一部として設計しておくものです。どのような状態を例外とみなすかを定義し、検知したら誰に通知し、人が何を判断し、結果をどこに記録して自動処理へ戻すのか。この一連の流れを決めておけば、自動化は止まらず、担当者も安心して任せられるようになります。

逆に、例外の扱いを決めずに自動化だけを先に作ると、エラーが起きた案件が誰にも気づかれずに放置されたり、結局すべてを人が目視で確認し直したりして、自動化した意味が薄れてしまいます。「自動化したのに手間が減らない」という相談の多くは、正常系の処理ではなく例外の扱いに原因があります。

この記事は、受注処理、請求、問い合わせ対応、データ連携などの業務自動化を進めている、またはこれから進める事業責任者・業務改善担当の方に向けたものです。例外の洗い出し方、分類の仕方、人が判断する工程の組み込み方、通知と記録の設計、運用しながら例外を減らしていく方法を、手順とチェックリストで整理します。

業務自動化で例外処理が必ず残る理由

自動化の対象になる業務は、多くの場合「だいたい同じ手順で回っている」業務です。しかし、実際の業務には、担当者が経験で吸収している小さなばらつきが数多く含まれています。自動化はその「暗黙の吸収」をしてくれないため、ばらつきが例外として表面化します。

例外が生まれる典型的な原因は次のとおりです。

• 入力データの揺れ：顧客名の表記違い、全角と半角の混在、必須項目の空欄、想定外のファイル形式など
• ルールで決めきれない判断：値引きを認めるかどうか、与信の範囲を超えた注文をどう扱うか、クレームを含むメールの優先度など
• 外部要因：連携先システムの停止、API の仕様変更、ネットワークの一時的な障害、取引先側の様式変更
• 業務ルールの変更：価格改定、新商品の追加、組織変更による承認者の変更などが自動化の設定に反映されていない
• そもそも件数が少ない特殊ケース：年に数回しか発生しない返品処理や、特定顧客だけの個別契約条件

これらのうち、いくつかは設計段階で潰せますが、すべてをルール化しようとすると、ルールが複雑になりすぎて自動化そのものが保守できなくなります。どこまでを自動で処理し、どこからを人に渡すのかを意識的に決めることが、例外処理設計の出発点です。

自動化の対象業務をどう選ぶかについては、自動化すべき業務の見つけ方：頻度・時間・ルールで優先順位を付けるで詳しく解説しています。例外の多さは、対象選びの段階でも重要な判断材料になります。

例外を「エラー」と「判断待ち」に分けて考える

例外と一口に言っても、性質の異なるものが混ざっています。設計の前に、少なくとも次の二つに分けて考えると整理しやすくなります。

一つ目は エラー型の例外 です。システムが処理しようとして失敗したもので、連携先の停止、データ形式の不一致、必須項目の欠落などが該当します。多くは原因を取り除けば同じ処理を再実行できます。

二つ目は 判断待ち型の例外 です。処理自体は可能だが、人の判断を挟むべきものです。金額が一定以上の注文、初めて取引する顧客、AI による分類の確信度が低いメール、契約条件が標準と異なる案件などが該当します。

この二つは、通知先も対応方法も記録すべき内容も違います。

エラー型は「減らすべきもの」、判断待ち型は「意図して残すもの」と捉えると、設計の方向性がはっきりします。判断待ち型を無理に自動化すると、誤った処理がそのまま顧客に届くリスクが高まります。

AI を組み込んだ処理では、この判断待ち型の工程を意識的に設けることが特に重要です。人が判断する工程を処理の流れに組み込む考え方は、用語としてはヒューマン・イン・ザ・ループ（HITL）と呼ばれます。

例外処理を業務フローに組み込む手順

例外処理の設計は、自動化の開発と並行して、次の順番で進めるのが現実的です。

1. 現状の業務で起きている例外を書き出す：担当者に「普段と違う対応をしたケース」を思い出してもらい、過去のメールやチャット、修正履歴からも拾います。頻度が低いものも含めて一覧にします。
2. 例外を分類する：エラー型か判断待ち型か、発生頻度、放置したときの影響、対応に必要な権限で分類します。
3. 自動で処理する範囲を決める：自動処理の条件を明文化し、条件に当てはまらないものは例外として人に回す、という線を引きます。最初は範囲を狭めに設定します。
4. 検知の方法を決める：どの時点で、何をもって例外と判定するのかを決めます。入力時のチェック、処理中のエラー、処理後の突き合わせなど、検知のタイミングは複数あります。
5. 通知先と対応期限を決める：例外の種類ごとに、誰に、どのチャネルで、いつまでに対応してもらうかを決めます。担当者不在時の代理も決めておきます。
6. 人の対応画面と手順を用意する：対応者が何を見て、何を判断し、どの操作をすれば処理が先に進むのかを用意します。対応手順は短い文書にまとめます。
7. 自動処理への戻し方を決める：人が修正・承認した案件を、自動処理のどこから再開させるのかを決めます。二重処理を防ぐ仕組みもここで考えます。
8. 記録と振り返りの仕組みを作る：例外の発生と対応結果を記録し、月次などで集計して、自動化範囲の拡大やルール修正に使います。

この順番のうち、もっとも省略されやすいのが6と7です。「例外はメールで通知する」だけを決めて、受け取った人が何をすればよいのかが決まっていないと、対応は担当者の経験頼みになり、属人化が自動化の外側で再発します。

検知と通知の設計：気づかれない例外をなくす

例外処理でもっとも避けたいのは、例外が発生しているのに誰も気づかない状態です。自動化は静かに失敗します。人が手作業でやっていたときは「処理できなかった」という事実を本人が把握していましたが、自動化すると、その把握を仕組みで代替しなければなりません。

検知のタイミングを複数持つ

例外は、次の三つのタイミングで検知できます。

• 入力時：データを受け取った時点で、必須項目、形式、値の範囲をチェックします。ここで止めれば、後工程への影響を防げます。
• 処理中：連携先へのデータ送信の失敗、タイムアウト、想定外の応答などを捕まえます。一時的な障害であれば、一定回数の再試行で自動復旧させます。
• 処理後：処理件数の突き合わせ、合計金額の照合、処理されずに残っている案件の確認などで、「エラーにはならなかったが結果がおかしい」ものを見つけます。

処理後のチェックは見落とされがちですが、重要です。たとえば、連携は成功したが一部の明細が欠落している、という状態はエラーとして検知されません。前日分の受注件数と連携先に登録された件数を突き合わせる、といった単純なチェックでも効果があります。連携処理の再試行や不整合への備えについては、API連携の障害対策：リトライ設計とデータ不整合への備え方も参考にしてください。

通知は「対応できる形」で届ける

通知の設計で大切なのは、受け取った人がその場で対応に着手できることです。次の情報を通知に含めます。

• 何の処理で、どの案件に、何が起きたか
• 想定される原因と、取るべき対応の候補
• 対応期限（業務上の締め切り）
• 対応画面や対象データへの導線
• 対応済みにする方法

通知のチャネルは、社内で日常的に見ている場所を選びます。チャットツールに例外専用のチャンネルを作る方法がよく使われますが、通知が多すぎると見られなくなります。緊急度の高いものだけを個人宛てに通知し、それ以外は一覧で日次確認する、といった段階を設けます。通知の設計の考え方はSlack・Teams通知で業務を回す：通知設計と自動化の勘所で詳しく扱っています。

「放置」を検知する

通知を送っても、対応されなければ意味がありません。例外を一覧で管理し、対応期限を過ぎたものを上長や代理担当者に再通知する仕組みを用意します。例外の状態は「未対応」「対応中」「対応済み」「対応不要」程度の区分で十分です。状態を持たせることで、件数の推移を追えるようになります。

人が判断する工程の作り方

判断待ち型の例外では、人が判断しやすい環境を用意することが、そのまま業務の速度と品質に影響します。

判断に必要な情報を一画面にそろえる

担当者が判断のために複数のシステムを行き来しなければならないと、対応に時間がかかり、確認漏れも起きます。判断対象の案件、関連する過去の取引、適用されるルール、AI による判定結果とその根拠などを、一つの画面や一つの通知にまとめます。

判断の選択肢を限定する

自由記述で「対応内容」を書かせると、後から集計できません。「承認」「修正して承認」「差し戻し」「個別対応へ移行」など、選択肢を決めておき、必要に応じて理由を一言添えてもらいます。選択肢が決まっていれば、どの判断が多いかを分析でき、自動化範囲を広げる根拠になります。

判断基準を文書にする

判断待ち型の例外は、担当者ごとに判断がぶれやすい領域です。「この条件ならこう判断する」という基準を短い文書にまとめ、新しい担当者でも同じ判断ができるようにします。基準が文書になれば、次の段階でその基準自体を自動化のルールに取り込めます。

架空の例：受注処理の判断待ち

ここでは、ある卸売業の会社を想定した架空の例で考えます。取引先からメールで届く注文を、生成AIで読み取って受注データにする仕組みを導入したとします。

自動処理の条件を「既存取引先」「登録済みの商品コード」「数量が過去の注文の範囲内」「AI の読み取り結果に不明項目がない」の四つに限定し、すべてを満たす注文だけを自動で受注登録します。一つでも満たさない注文は、判断待ちとして営業事務の担当者に回します。

担当者の画面には、元のメール、AI が読み取った内容、満たさなかった条件、取引先の過去の注文履歴が並びます。担当者は内容を確認し、「承認」「修正して承認」「取引先に確認」のいずれかを選びます。承認された注文は、自動処理と同じ経路で受注登録されます。

運用開始後、判断待ちの理由を月次で集計したところ、「数量が過去の範囲外」の多くが季節要因による正常な注文だったと分かれば、季節ごとに範囲を見直すルールを加えて自動処理の範囲を広げられます。このように、判断待ちの記録が改善の材料になります。

自動処理への戻し方と記録の設計

人が対応した後、案件をどう自動処理に戻すかは、見落とされやすい設計ポイントです。

再開の位置を決める

例外が発生した案件を、最初から処理し直すのか、止まった工程から再開するのかを決めます。最初からやり直すと二重登録の危険があり、途中から再開するには処理の状態を保持する必要があります。案件ごとに一意の識別子を持たせ、同じ識別子の処理が二度実行されても結果が変わらない作りにしておくと、どちらの方式でも安全に再開できます。

手作業で処理した場合の記録

例外の一部は、自動処理に戻さず人が手作業で最後まで処理することもあります。その場合も、処理結果を自動化の仕組みが参照する場所に記録しておかないと、後の突き合わせで「未処理」と誤検知されたり、二重に処理されたりします。

記録しておく項目

例外の記録には、最低限次の項目を残します。

• 発生日時、対象案件、例外の種類
• 検知した工程と、検知の理由
• 対応者、対応日時、対応内容（選択肢）、理由
• 自動処理に戻したか、手作業で完了したか
• 再発防止のために取った措置（あれば）

この記録は、後述する例外の削減だけでなく、監査や取引先からの問い合わせへの回答にも使えます。

例外処理設計のチェックリスト

自動化の設計レビューや、既存の自動化の見直しで、次の項目を確認してください。

• 例外の一覧があり、エラー型と判断待ち型に分類されている
• 自動処理の条件が文章で定義されており、条件外のものは必ず人に回る
• 入力時・処理中・処理後のそれぞれで検知の仕組みがある
• 一時的な障害に対する再試行の回数と間隔が決まっている
• 例外の種類ごとに通知先、通知チャネル、対応期限が決まっている
• 担当者不在時の代理対応者が決まっている
• 通知に、対応に必要な情報と対応画面への導線が含まれている
• 判断の選択肢と判断基準の文書がある
• 人が対応した案件の再開位置が決まっており、二重処理が防がれている
• 例外の状態（未対応・対応中・対応済みなど）を一覧で確認できる
• 対応期限を過ぎた例外が再通知される
• 例外の発生と対応が記録され、定期的に集計されている
• 自動化を止めて手作業に切り替える手順（縮退運用）が決まっている

最後の縮退運用は、連携先の長時間停止など、自動化そのものが使えなくなる場面への備えです。手作業での処理手順が残っていないと、障害時に業務が止まります。

よくある失敗とその避け方

すべての例外をルール化しようとする

例外を見つけるたびにルールを追加していくと、自動化の設定が複雑になり、誰も全体を把握できなくなります。頻度が低く影響も小さい例外は、人に回す方が全体の手間は小さくなります。ルール化するのは、頻度が高い、または判断基準が明確に書けるものに限ります。

例外の通知先が「全員」になっている

関係者全員に通知を送ると、誰かが対応するだろうという状態になり、結果として誰も対応しません。例外の種類ごとに一次対応者を一人決め、その人が対応できないときの代理を決めます。

エラーを握りつぶす作りになっている

処理の途中でエラーが起きたとき、その案件を飛ばして次の案件の処理を続ける作りは、処理全体を止めないという意味では合理的です。しかし、飛ばした案件を記録・通知していなければ、例外は消えてしまいます。自動化ツールの初期設定のままだと、エラーが起きても通知されないことがあるため、設定を確認します。RPA で同じ問題が起きやすい理由はRPAが止まる・使われなくなる原因と、破綻しない運用の設計でも触れています。

例外対応が特定の担当者に集中する

自動化の導入を担当した人に、例外対応がすべて集まってしまうことがあります。その人が異動や退職をすると、自動化そのものが維持できなくなります。対応手順を文書にし、複数の人が対応できる状態にしておきます。

例外の記録を見返さない

記録はしているが集計していない、という状態では、例外は減りません。月に一度、例外の種類別件数と対応にかかった時間を確認し、上位のものから対策を検討する時間を定例に組み込みます。

運用しながら例外を減らしていく方法

例外処理の仕組みは、作って終わりではなく、運用しながら育てるものです。

最初は自動処理の範囲を狭めに設定し、判断待ちとして人に回る案件が多い状態から始めます。運用が安定したら、記録された例外を分析し、次の観点で自動化範囲を広げていきます。

• 判断がほぼ同じ結果になっているもの：担当者が毎回同じ判断をしている例外は、その判断をルールとして自動処理に取り込めます。
• 入力データの揺れが原因のもの：入力フォームの選択肢化や、取引先への様式の案内など、入口で揺れを減らせないか検討します。
• 外部要因によるエラー：再試行の設定を見直す、連携先の停止予定を事前に把握する、といった対策を取ります。

一方で、範囲を広げる際は慎重さも必要です。自動処理の誤りは、人の誤りよりも件数が多くなりやすいからです。範囲を広げた直後は、自動処理された案件の一部を抜き取りで確認する期間を設けると安心です。

よくある質問

Q. 例外が全体のどのくらいなら自動化する意味がありますか？

一律の基準はありません。判断の材料は、例外を人が対応する時間と、正常な案件を自動化して削減できる時間の比較です。例外が多くても、例外への対応が短時間で済むなら自動化の効果はあります。逆に、例外一件の対応が重いなら、まず例外の発生原因を減らすことを優先します。自動化の効果の測り方は業務自動化の費用対効果の測り方：削減時間だけで判断しないで解説しています。

Q. 生成AIを使った処理では、例外の扱いは変わりますか？

基本の考え方は同じですが、生成AIの出力は同じ入力でも揺れることがあり、誤りがエラーとして表に出にくいという特徴があります。出力の形式チェック、確信度や不明項目の扱いの指定、一定条件での人の確認を組み合わせて、判断待ち型の例外として拾う設計にします。

Q. 例外の管理に専用のシステムは必要ですか？

件数が少ないうちは、スプレッドシートやチャットツールのスレッドで管理しても回ります。件数が増えて、状態管理や期限の再通知、集計が手作業で追いつかなくなったら、ワークフロー機能を持つツールや、自動化の仕組みの一部として例外管理の画面を作ることを検討します。

Q. 既に動いている自動化に、後から例外処理を追加できますか？

可能です。まず現在どんな例外が起きているかを、エラーログや担当者へのヒアリングで洗い出し、この記事のチェックリストで足りない部分を特定します。通知と記録の仕組みだけを先に追加するだけでも、放置される例外を減らせます。

Otsumuに相談できること

自動化の対象が一つの業務に限られていて、使っている自動化ツールに通知や再試行の機能があり、例外の種類もそれほど多くないのであれば、この記事の手順に沿って自社で例外処理を設計することは十分可能です。まずは例外の書き出しと分類、通知先と対応期限の決定から始めてみてください。

一方で、複数のシステムをまたぐ処理で例外の原因が特定しにくい、生成AIを組み込んだ処理で判断待ちの基準をどう決めればよいか分からない、すでに動いている自動化で例外対応が特定の人に集中している、といった状況では、外部の視点を入れた方が早く整理できることがあります。

Otsumuの自社サービス運用の自動化コンサルティングでは、業務の棚卸しから、自動化の範囲と例外の線引き、通知や人の確認工程を含めた仕組みの設計と実装、運用後の改善までを一貫して支援しています。自らも事業を運営する立場から、現場で回り続けることを重視し、必要な仕組みに絞って設計します。システム間の連携部分の開発が必要な場合は、API連携開発として対応することもできます。

今の自動化のどこで例外が詰まっているのか、まずは状況を伺いながら整理するところからでも構いません。30分の無料相談からお気軽にご連絡ください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01