実務ガイド / 人とAIの協働
AIの出力を人が確認する業務フローの設計ポイント
「人が確認する」と決めるだけでは、誰が何を見て、どこまで判断するのかが曖昧なままです。AIの候補・根拠・未確認事項を判断者に渡し、承認、修正、差し戻し、保留を使い分ける手順に落とし込む方法を解説します。
大切なのは承認ボタンを追加することではなく、誤りが起きたときに影響を抑え、担当者が自分の判断で処理を止められることです。確認の深さは業務リスクに合わせ、通常処理と例外処理の両方を設計します。
候補を受け取る人に、判断材料と差し戻しの選択肢を渡す。確認工程は業務フローの一部として設計します。
この記事で整理すること
確認が必要な場面の分け方、判断に必要な画面情報、例外時の停止と引き継ぎ、役割と継続的な見直しまでを順に確認できます。
01 / 確認の深さ
人が確認すべき場面を、影響と不確かさで分ける
すべての出力を同じ手間で確認すると負担が大きくなり、重要な判断に注意を向けにくくなります。一方、確認を省く条件が曖昧だと例外的な入力まで通常処理として通るおそれがあります。処理の性質を分け、誰がどう対応するかをあらかじめ決めます。
通常
定型・低影響
形式や必須項目がそろい、結果を後から照合できる処理。自動で進める場合も、抜き取り確認や記録など問題を見つける方法を残します。
要確認
低確信・曖昧
候補が複数ある、分類理由が弱い、表記ゆれが大きい場合。担当者が原文と候補を比較し、必要なら修正してから進めます。
情報不足
欠落・不一致
必要な値がない、参照先と内容が合わない場合。推測で補完せず、不足情報の確認依頼か差し戻し・保留へ送ります。
高影響
重要な判断
金額、権利、安全、顧客への確定回答など、誤りの影響が大きい処理。権限を持つ人の確認・承認を必須にし、自動確定の範囲を限定します。
区分は業務ごとに決めます。同じ「分類」でも、社内の参考整理と顧客への回答決定では必要な確認が異なります。誤りの影響を言葉にし、確認者、確認箇所、停止条件を対応づけましょう。
02 / 判断材料
「承認」だけでなく、判断の根拠を並べる
担当者が候補だけを見て承認する画面では、内容を独立して検証できません。判断を支える情報を同じ場所で確認でき、承認以外の操作も選べるようにします。業務で使う情報に応じ、次の項目を設計の出発点にしてください。
根拠
元の情報に戻れる
AIが参照した文章、項目、該当箇所を候補の近くに表示します。担当者が原文や記録を開いて照合できる導線も用意します。
未確定
分からない点が見える
欠けている値、曖昧な分類、根拠のない推定を明示します。「空欄」と「確認済みの該当なし」を混同させないことも大切です。
承認
確認して次へ進める
担当者が内容と根拠を確認し、通常の次工程へ渡す操作です。何を承認したのかを画面と記録で追えるようにします。
修正・差し戻し
誤りを直し、戻せる
候補を修正して進める操作と、入力元や前工程へ戻す操作を区別します。後の品質点検に役立つ範囲で、理由や修正箇所を残します。
保留も正規の判断です。 すぐに確定できない人が無理に選ばず、相談先や再開条件を確認できる状態にします。
03 / 例外と引き継ぎ
迷ったら止める。その後の行き先まで決める
例外対応は、エラー時に「人が確認する」と書いて終わりではありません。どの状態で自動処理を止め、誰が受け取り、何を確認して再開または差し戻すのかを決めます。問い合わせの初期分類なら、低確信の案件を自動回答せず確認キューへ送り、担当者が分類と緊急性を判断する流れが考えられます。
STEP 01
候補を作る
分類候補と根拠、未確認項目を提示する。
STEP 02
条件を判定
必須情報、低確信、緊急性などを確認する。
STEP 03
人へ引き継ぐ
担当先不明や高影響の案件を確認キューへ送る。
STEP 04
判断を記録
修正・保留・確定と、その後の処理を記録する。
構想例で考える
問い合わせの分類候補を、人の判断につなぐ
問い合わせ本文から分類候補を作り、不足情報や緊急語句を確認。担当候補と振り分け理由を示し、低確信・苦情・個別判断が必要なものは人の確認キューに送ります。担当者が分類を直し、顧客への回答や緊急対応を判断します。
これは設計を考えるための構想例であり、顧客実績の紹介ではありません。
問い合わせの初期分類と担当振り分け例
もう一つの構想例
請求書の候補情報を、原本と照合してから進める
文書から抽出した候補をそのまま確定するのではなく、担当者が原本と照らし、金額や必須情報、例外を確認する流れを考えます。情報の欠落や不一致があれば処理を止めて確認へ回し、支払い承認は担当者が行います。
このページの内容と同様、顧客実績ではなく業務設計を検討するための構想例です。
請求書処理の確認・振り分け設計例例外として決めておきたいケース
- 担当先が不明：自動で別の担当へ割り当てず、窓口責任者へ回す。
- 情報が欠けている：不足内容を明示して保留または入力元へ差し戻す。
- 誤りが見つかった：処理を止め、影響範囲を確認して記録・訂正する。
04 / 責任と権限
誰が確定し、誰がルールを変えるのか
自動処理の範囲と、人が持つ権限を分けて記します。現場担当者が日常の修正を行うのか、承認者が高影響の判断を確定するのか、ルール変更を誰が許可するのかを明らかにすれば、誤りが起きた際の対応が宙に浮きにくくなります。
役割
実務担当者
原文と候補を照合し、修正・保留・差し戻しを選ぶ。異常や誤りを記録して所定の窓口へ知らせる。
役割
承認者・業務責任者
重要な処理の確定、例外時の判断、停止後の再開可否を決める。担当者が判断できない案件の相談先になる。
役割
運用ルールの管理者
自動化範囲、条件、権限の変更を管理する。変更理由を記録し、テストと周知を経て運用へ反映する。
これは役割分担を検討するための一般的な例です。実際の配置は組織の規模、業務権限、取り扱う情報に合わせて定めてください。担当者に権限がないのに結果の責任だけを負わせる状態や、ルール変更の記録が残らない状態は避けます。
05 / 点検と更新
修正、例外、見逃し、負担を一緒に見る
運用を始めた後は、誤分類や修正の内容、例外の発生傾向、担当者が確認に要する手間を点検します。正解率だけでは、確認に時間がかかりすぎていることや、まれでも影響の大きい誤りを見逃すことがあります。何を記録し、誰が振り返るかを決め、必要に応じて確認条件や担当手順を更新します。
- AI候補の修正・差し戻しが多い分類や入力条件は何か
- 担当先不明、情報不足、停止がどのような理由で起きたか
- 確認待ちの滞留や見落としが発生していないか
- 担当者の確認負担と、処理全体の品質にどんな変化があるか
運用チェックのサイクル
- 1
事実を集める。 修正、保留、例外、確認負担を同じ期間・条件で記録する。
- 2
傾向と影響を見る。 件数だけでなく、どの業務・入力・判断に影響したかを確かめる。
- 3
変更を小さく検証する。 条件や手順を変える場合は、影響するケースをテストし、担当者に伝える。
次に読む・検討する
確認手順を、業務設計と組織のルールにつなぐ
確認・差し戻し・停止条件を業務フローへ組み込む方法、確認権限や社内ルールを整理する方法、問い合わせ振り分けの構想例を続けて読めます。