AI業務自動化はどこで人に戻す？例外対応を決める5つの設計項目
2026/10/11
結論：AI業務自動化は、情報が足りない・根拠と合わない・決めた範囲を超える場面で止め、人に判断を戻せるように設計します。
そのために「停止条件」「引き継ぐ担当者」「渡す情報」「再開・中止の判断」「例外を含むテスト」の5項目を先に決めましょう。通知を送るだけでなく、誰が何を確認すれば次へ進めるかまで決めることが大切です。
※アイキャッチ画像はAIと人の役割分担を考えるイメージです。AI生成画像で、実在の導入現場を撮影したものではありません。
なぜ「困ったら担当者へ連絡」だけでは足りないのか
問い合わせの分類や返信文の下書き作成を自動化しても、すべての入力が想定どおりとは限りません。参照資料にない質問や、必要事項が欠けた依頼も届きます。
「エラーが出たら知らせる」だけでは、通知を見た人が最初から調べ直すことになります。また、担当者が不在のまま案件が残ったり、手作業で処理した内容を自動処理がもう一度実行したりするおそれもあります。
ここでいう例外は、システムの故障だけではありません。処理自体は動いていても、業務上は人の判断が必要な状態を含みます。
Microsoftの公式資料でも、Power Automateの承認機能を使い、自動化したワークフローに人の意思決定を組み合わせられると説明されています。Microsoft Learn「承認の準備を始める」（確認日：2026年10月11日）
以下の5項目は、特定製品の設定手順ではなく、導入前に業務担当者と整理するための実務提案です。既存記事の対象業務の選定や効果測定とは分け、今回は例外が起きた後の引き継ぎを扱います。
1．止める条件を、観察できる言葉で決める
「AIが自信を持てないとき」だけでは、止める基準が曖昧です。必要項目が空欄、参照資料が見つからない、資料同士で内容が異なる、といった確認可能な状態に置き換えます。
また、AIが作った案を確認する工程と、その案を送信・登録する工程は分けます。最初の試験では外部への自動送信を行わず、下書きまでに範囲を限定すると、止め方を確かめやすくなります。
| 止める場面 | 確認する事実 | 止めた後 |
|---|---|---|
| 入力不足 | 対応に必要な商品名や依頼内容が未記入 | 不足項目を示して担当者へ渡す |
| 根拠の不足・矛盾 | 回答に対応する資料がない、資料間で説明が異なる | 根拠の確認が終わるまで下書きを確定しない |
| 対象外の依頼 | 個別の値引き、契約条件の変更など、あらかじめ除外した内容 | 判断権限のある担当者へ戻す |
| 実行結果が不明 | 登録操作の応答が途切れ、完了したか分からない | 結果を調べてから再実行の可否を決める |
この表は架空の運用例であり、実際の顧客事例ではありません。停止条件の検出方法も別途必要です。入力欄の確認で判定できるものと、内容の照合や人の確認が必要なものを分けて実装します。
2．担当者・不在時の引き継ぎ先・確認期限を決める
「営業部に通知する」だけでなく、案件を受け取る役割を一つ決めます。通知先が複数でも、誰が対応を引き受けたかを記録できる形にしましょう。
- 最初の担当者：内容を確認し、対応方法を決める役割。
- 不在時の引き継ぎ先：担当者が休みの場合や、期限までに確認できない場合の相談先。
- 確認期限：業務上必要な期限。夜間・休日を含め、実際に対応できる体制に合わせる。
- 未対応の見える化：通知履歴とは別に、保留中の案件を一覧で確認する場所。
期限が過ぎたことを理由に、自動で承認済みにしない運用から始めます。急ぎの案件は手作業へ切り替えるなど、業務を続ける方法も決めてください。確認期限に一律の正解はありません。
3．元の情報・AIの案・停止理由をひとまとめで渡す
担当者には、結論だけでなく判断に必要な材料を渡します。「処理できませんでした」ではなく、どの案件が、どこまで進み、何を確認する必要があるかを示します。
引き継ぎ票に入れる情報
- 案件を区別する番号と受付日時
- 元の依頼・参照資料への、担当者が閲覧できるリンク
- AIが作成した案と、参照した資料の版・確認日時
- 止まった工程と停止理由
- すでに実行した処理、まだ実行していない処理、結果不明の処理
- 担当者に判断してほしい内容と確認期限
例えば「価格に関する質問で、参照資料に対象商品の条件がない。返信案は作成済みだが未送信。担当者に条件確認を依頼」と記録します。これは説明用の想定例です。
通知へ元の情報をすべて貼り付ける必要はありません。社内で利用が認められた保存場所へ必要な情報を置き、閲覧できる人を絞ります。試作には実在の顧客情報を含まない模擬データを使いましょう。
4．承認・修正・中止と、再開する位置を分ける
「確認済み」の一言では、送信してよいのか、修正が必要なのかが伝わりません。人の判断を「この案で進める」「修正して再確認する」「中止する」などに分けます。
承認は、確認した内容の版と結び付けて記録します。承認後に宛先や本文が変わった場合は、そのまま実行せず再確認へ戻す設計にしてください。
- 保留にした案件を担当者が引き受ける。
- 元情報と案を照合し、進める・修正・中止を記録する。
- 進める場合は、実行済みの処理がないか確認する。
- 決めた工程から再開し、実行結果を確認して完了にする。
特に、外部への送信や登録で応答が途切れた場合、「エラーだから未実行」と決めつけないことが重要です。実際には相手側で処理済みの可能性があります。結果不明として保留し、登録先の記録などを確認してから再実行を判断します。
人が手作業で処理した案件は、その結果も自動化側の管理表へ残します。同じ案件を二重に処理しないために、案件番号と状態を使って進行を管理します。
5．正常な例だけでなく、止まる例・戻る例も試す
試験では、下書きが作れたかだけでなく、例外が担当者に届き、判断後に正しい位置から再開できたかを確かめます。実送信や本番登録を伴わない検証環境から始めます。
- 必要な入力を欠けさせたとき、指定の条件で止まるか。
- 資料に答えがないとき、根拠のない案を確定せず人へ戻せるか。
- 担当者が不在でも、保留案件が消えずに残るか。
- 修正や中止の判断が、次の処理に正しく反映されるか。
- 承認後に内容が変わったとき、再確認に戻るか。
- 結果不明の処理や手作業済みの案件を、重複して実行しないか。
期待した結果と実際の結果を案件ごとに記録し、止まらなかった条件を修正します。確認した条件が限られる以上、小規模な試験だけですべての例外に対応できるとは判断しないでください。
運用で注意したいこと
AIへの指示と、実際に処理を止める仕組みを混同しないこと。「分からなければ止めて」と指示文に書くだけでなく、必須項目の検査や承認待ちの状態管理など、業務の仕組みとして確認します。
自己申告の確信度だけで自動実行を決めないこと。AIが「自信がある」と回答しても、それだけで内容が正しいことを検証したことにはなりません。原資料との照合や、決めた業務条件の確認を残します。
保留件数だけを減らすことを目標にしないこと。安全のために人へ戻すべき案件もあります。通知を減らすために停止条件を緩める前に、入力や参照資料の改善で解決できるかを見直しましょう。
使用サービス、参照資料、担当体制を変更したら、影響する停止条件と試験例を見直します。特定サービスの料金・権限・データ取扱条件は導入時に別途確認してください。
よくある質問
Q．すべて人が確認すると、自動化する意味がありませんか？
情報収集や下書き作成を自動化し、判断だけを人に残す方法もあります。最初は確認を広く残し、例外と修正の記録を見ながら任せる範囲を検討します。確認を含めた負担で評価してください。
Q．AIの確信度は何％以上なら自動処理してよいですか？
一律の数値は決められません。数値の意味や実際の正しさとの関係が検証されているか、誤った場合の影響は何かを確認します。まずは観察できる業務条件と人の確認を組み合わせます。
Q．担当者が一人の場合はどうしますか？
確認できる時間と対応できない時間を分け、不在中は保留する条件を決めます。代わりの担当者がいないなら、その間に自動で進める範囲を狭めるか、手作業へ戻す運用を用意します。
Q．エラーが出たら自動で何度もやり直してよいですか？
処理の種類によります。情報を読む処理と、送信・登録など結果を残す処理は分けて考えます。後者は実行済みか不明なまま再試行せず、結果確認と重複防止を設計してから判断してください。
Chain-Moviesが支援できる範囲
Chain-Movies株式会社では、AI活用・業務自動化に関する業務整理や、運用方法の相談を承っています。自動化する対象だけでなく、人が確認する場面、担当者への渡し方、試作で確かめる項目を一緒に整理します。
既存システムとの連携や実装の可否は、利用環境・権限・扱う情報を確認して判断します。すべての例外の自動解決や、特定の削減効果を保証するものではありません。
「自動化したいが、間違ったときの対応が不安」という段階からご相談ください。
対象業務、現在の手順、人が判断している場面を、機密情報を除いてお知らせください。
出典・確認日
- Microsoft Learn「承認の準備を始める」：ワークフローに人の意思決定を組み込む承認機能の説明を参照。確認日：2026年10月11日。
本記事の5項目、引き継ぎ票、試験項目は一般的な業務整理のための実務提案です。Microsoftが指定した設計標準や、Power Automateの個別設定手順ではありません。想定例は実在の顧客事例・導入成果を示すものではありません。
