先に結論：AI導入の変更後に例外や情報不足が見つかったら、通常処理を続ける前に影響範囲、例外の理由、確認者、手動の戻し先、記録先、再開条件を決めます。顧客・契約・金額・個人情報・公開情報に関わる、または戻し先が分からない場合は、AI処理を止めて人へ戻してください。
ルールを更新した直後は、通常の入力だけを想定していると、最初の例外で流れが崩れます。変更前は担当者が見ていた項目をAIが先に分類するようになった、確認者が別の部署になった、FAQの回答は更新されたがCRMの入力欄は古いまま、といった小さな差分が原因です。
例外を「今回だけの面倒なケース」として処理すると、担当者ごとに違う判断が残ります。この記事では、通常・境界・停止の比較、例外を手動へ戻す6手順、記録テンプレート、公開前チェックリスト、FAQを整理します。変更前の周知はAI導入の変更を社内へ知らせる前の6項目、周知後の質問整理は問い合わせが増えた時の5項目も参照してください。
例外を通常処理に混ぜると、判断の境界が消える
通常処理とは、対象業務、入力できる情報、AIに任せる範囲、人間確認、出力先が現行の正本どおりにそろっている状態です。例外は、必ずしも失敗ではありません。現行ルールの外側にある一件を見つけ、通常処理と分けるための合図です。
| 見つかった状態 | 判断の特徴 | 最初の扱い | 戻し先 |
|---|---|---|---|
| 通常 | 入力・条件・確認者が正本と一致 | 決めた手順で処理 | 現行手順と記録欄 |
| 境界 | 条件の一部が不明、範囲外か迷う | 保留して確認者へ送る | 判断ログ・責任者 |
| 停止 | 顧客・契約・機密・公開情報に影響、戻し先なし | AI処理を止める | 手動手順・承認者 |
「確認できそうだから続ける」は、境界を通常へ寄せる危険な合図です。確認者が決まっていない、元データと照合できない、処理後に戻せない場合は、時間短縮より判断の保全を優先します。停止は失敗の印ではなく、再開に必要な条件を集める状態です。
例外を見つけた時に先に記録する6項目
手動対応を始める前に、最低限の情報を一枚へ置きます。短いメモでも、後から「なぜ止めたか」「誰が戻したか」が分かれば、同じ例外を次の人が最初から調べ直さずに済みます。
| 項目 | 確認する問い | 空欄の時の扱い |
|---|---|---|
| 対象業務 | どの案件、顧客、担当者、変更に関係するか | 対象を一件に絞る |
| 例外の理由 | 入力不足、条件外、矛盾、権限、出力先のどれか | 推測せず保留 |
| 影響範囲 | 顧客、契約、金額、個人情報、公開情報に触れるか | 停止寄りに扱う |
| 確認者 | 判断、承認、復旧を担う人は誰か | 自動処理を進めない |
| 手動の戻し先 | どの手順、台帳、承認経路へ戻るか | 担当者へ確認 |
| 再開条件 | 何がそろえば通常処理に戻せるか | 停止を継続 |
この6項目は、原因を精密に分析するためだけのものではありません。例外が出た瞬間に、処理を続けるか、保留するか、止めるかをそろえるための境界線です。特に「手動の戻し先」と「再開条件」がない例外は、AIだけで解決しようとしないでください。
6手順で例外を手動へ戻し、再開条件を残す
- 処理を一時保留する：例外を見つけた案件を通常のキューから分け、出力や送信を先に進めません。すでに生成した下書きがあれば、未確認であることを表示します。
- 対象と変更を特定する：どの業務の、どの変更後に起きたかを記録します。変更前の正本、現在の正本、利用した入力を並べ、変更日だけで現行と決めません。
- 影響のある情報を分類する：顧客条件、契約、金額、個人情報、社外公開情報を含むか確認します。影響があるのに人の確認者が決まらない場合は停止にします。
- 手動の戻し先を選ぶ：変更前へ戻すのか、別の承認ルートへ送るのか、入力を補って保留するのかを責任者が決めます。チャットで決めた場合も正本や判断ログへ戻します。
- 例外と判断を記録する：理由、判断者、対応、未確定点、次の確認日を残します。個別案件の履歴と、一般化してFAQへ戻せる知見を混ぜません。
- 小さく再開する：代表的な通常ケースと今回の境界ケースを人が照合し、出力先、確認者、停止条件を確認します。再開できない時は手動運用を継続し、再開条件が変わった理由を記録します。
最初の手順で保留することが重要です。例外の原因を調べながらAIの処理も走らせると、どの条件で出力されたか分からなくなります。処理を止める範囲は業務全体でなくても構いませんが、少なくとも対象のキューと出力を分離します。
手動へ戻す判断を、担当者の経験だけにしないために、変更後に古い案内を正本へ戻す6手順で現行条件と履歴を分けてください。例外が一般化できるなら、判断ログを社内FAQへ戻す6手順のように、質問・条件・人間確認へ変換します。
例外記録を現行手順・FAQ・判断ログへ分ける
一件の例外をそのまま手順書へ追記すると、手順書が個別案件の記録で膨らみます。一方、チャットだけに残すと、次の担当者が検索できません。記録の目的に応じて置き場所を分けます。
| 記録先 | 残す内容 | 更新の判断 |
|---|---|---|
| 現行手順 | 通常処理の順番、入力、確認、完了条件 | 同じ条件の案件へ再利用できるか |
| FAQ | 繰り返す質問、適用条件、例外、戻し先 | 問い合わせの答えとして短く説明できるか |
| 判断ログ | 今回迷った理由、根拠、承認、停止、再開条件 | 個別の履歴を監査・引き継ぎに残すか |
FAQへ戻すのは、同じ条件で再び起きる可能性がある部分だけです。顧客名や個別契約などの情報を一般化せずにFAQへ貼らないようにします。反対に、判断ログへ「例外だった」とだけ書くのも不十分です。どの条件が正本から外れ、誰がどの手動経路を選んだかを残します。
変更後の例外を比較するチェックリスト
- 例外案件を通常キューと出力先から分けた
- 対象業務、変更日、利用した正本を特定した
- 入力不足、条件外、矛盾、権限、出力先の理由を分類した
- 顧客、契約、金額、個人情報、公開情報への影響を見た
- 判断者、承認者、手動復旧を担う人を確認した
- 手動で戻る手順、台帳、承認経路を一つ選んだ
- チャットの決定を正本または判断ログへ戻した
- 個別案件の履歴とFAQへ一般化する内容を分けた
- 通常ケース、今回の境界ケース、停止ケースを一件ずつ確認した
- 再開条件、停止条件、次回確認日を記録した
このチェックで空欄が残る時は、公開や自動処理を急がず保留します。特に「誰が再開を承認するか」「手動処理が終わった後どこへ記録するか」が決まらない状態では、例外を解消したつもりでも次の案件で同じ問題が起きます。変更後の判断ログを更新する合図はAI判断ログを更新する6つの合図にも整理しています。
FAQ：変更後の例外をどこへ戻すか
AI導入の変更後に例外が出たら、すぐ手動へ戻しますか？
影響範囲と戻し先を確認します。顧客、契約、金額、個人情報、公開情報に触れる場合や、確認者が決まらない場合は処理を止めて人へ戻します。範囲内で照合できる場合だけ、決めた通常手順を続けます。
例外と単なる問い合わせはどう分けますか？
現行ルールの範囲内で答えられる問い合わせは通常処理、入力や判断条件が範囲外なら例外として保留します。返答できるかではなく、同じ条件で再現できるかを基準にします。
手動へ戻した後、いつ再開できますか？
例外の原因、対象範囲、確認者、手動手順、テストケース、停止条件を記録し、責任者が再開条件を確認してから小さく戻します。条件がそろわなければ手動運用を続けます。
例外記録はどこへ残せばよいですか？
現行手順の代わりにチャットへ埋め込まず、判断ログや正本に戻せる記録先へ残します。FAQへ戻せる一般化と、個別案件の履歴は分けて管理します。
無料診断で、変更後の例外ルートを一緒に整理する
例外対応で必要なのは、すべてを自動化することではありません。通常の流れ、境界で人へ戻す場所、停止後に再開する条件を、担当者が同じ言葉で確認できることです。
Miraigentの無料診断（60秒）では、AIへ任せる業務、送らない情報、人間確認、例外、停止後の戻し先を整理できます。まず直近の一件を選び、6項目の空欄を埋めてください。手動へ戻した理由が残れば、変更を恐れて全体を止めるのではなく、影響のある範囲だけを安全に扱えます。
関連：変更を社内へ知らせる前の6項目 ／ 問い合わせが増えた時の5項目 ／ 古い案内を正本へ戻す6手順 ／ 停止後の再開条件