AI業務を変更した後のレビュー方法｜現場負担と手戻りを見直す

AIを組み込んだ業務フローを変更した後は、AIの出力だけでなく、現場に増えた確認時間、修正、例外対応、記録漏れを確認します。変更前後を同じ業務単位で比べ、対象期間と件数、担当者、確認日、継続・修正・停止の条件を記録します。

設定どおりに動いていても、人が別の画面で確認する回数や、記録されない手作業が増えていれば、業務全体では改善したと判断できません。この記事では、特定のAI製品に依存せず、変更後の業務を見直す手順を整理します。

変更後のレビューで確認する対象

最初に、確認対象を「AI」ではなく「業務フロー」に置きます。問い合わせの要約、案件の分類、返信案の作成、CRMへの記録など、開始から完了までを一つの業務として扱います。

確認する対象は次の5つです。

AIの出力を人が確認する時間
修正や差し戻しが起きた箇所
通常の流れから外れた例外と、その処理
別画面への転記や、記録に残らない手作業
問題が起きたときに止める人と、元へ戻す手順

NISTのAI Risk Management Framework Playbookは、本番運用後の監視に、利用者などからの入力、変更管理、問題への対応と記録を含めています。2026年3月に公開されたNISTの報告書も、本番環境では予期しない出力や影響が起こり得るため、導入前の評価だけでなく運用後の監視が必要だと説明しています。

ただし、監視の共通手法はまだ整備途上です。すべての業務へ同じ指標を当てはめるのではなく、その業務で人が引き受けている作業を確認します。

AI業務を変更した後の5つの手順

1. 変更した業務と境界を一つに絞る

「営業業務全体」のように広く置かず、「問い合わせを受けてから、担当者が最初の返信を承認するまで」のように、開始と完了が分かる単位に絞ります。

あわせて、今回変えた内容を一文で記録します。AIへ渡す情報を増やした、分類条件を変えた、人の承認点を移した、といった具体的な変更です。複数の変更を同時に扱うと、手戻りの原因を切り分けられません。

2. 変更前後を同じ条件で比べる

変更前と変更後で、業務の開始点と完了条件をそろえ、対象期間と件数を記録します。件数まで同じにする必要はありません。件数が違う場合は、総時間だけでなく1件当たりの確認時間も見ます。

繁忙期と通常期、難しい案件と定型案件を混ぜると、AIや業務変更の影響と、案件構成の違いを分けられません。条件をそろえられない場合は、その違いを記録して判断を保留します。

3. 集計値と実物を照合する

ダッシュボードの件数だけでは、現場の確認や修正を把握できません。実際の出力、差し戻し、CRMやタスク管理の履歴を同じ対象で照合します。

たとえば、処理件数が増えていても、担当者が別のメモへ修正内容を残していれば、その作業は集計に含まれません。逆に、確認作業が増えていても、事故を防ぐために必要な承認であれば、単純に削る対象ではありません。作業の量と必要性を分けて記録します。

4. 継続・修正・停止の条件を決める

レビューの結論は、継続、修正、停止の3つに分けます。

継続: 完了条件を満たし、追加作業が許容範囲に収まっている
修正: 業務は続けられるが、確認箇所、入力データ、例外処理の変更が必要
停止: 誤った処理結果を取り消せず、変更前の手順へ戻す方法もない。責任者が不明、または安全に運用できない場合も含む

「許容範囲」は会社や業務によって異なります。変更前に責任者と合意するのが原則です。事前に決めていなかった場合は、最初のレビューで基準を置き、その時点の結論を暫定判断として記録します。次の確認日まで同じ基準で観測してから、継続・修正・停止を確定します。

5. 次の確認日と変更権限を残す

修正したら、誰が変更できるか、誰が承認するか、いつ再確認するかを記録します。変更の履歴が残らないと、同じ問題が起きたときに原因を追えません。

デジタル庁が公表したAIエージェント利用環境も、職員が業務の内容に合わせてAIエージェントを作成・実行し、使いながら改善する考え方を示しています。この公表は、民間企業の承認方法を定める資料ではありません。本稿では安全に変更を続けるため、現場が変更できる範囲と、その変更を承認する人を分けて記録します。

変更前後のレビュー記録表

次の表は、業務を一つ選び、変更前後を同じ条件で比べるための記録欄です。確認できない項目は0とせず、「未取得」と記録します。

記録すること	基準・変更前	変更後	確認する資料	判断
対象業務と完了条件			業務フロー、手順書	条件が同じか
対象期間と件数			実行ログ、案件一覧	比較できる母数か
人が確認した時間			作業記録、担当者の確認	増減と理由
修正・差し戻し			実物、変更履歴	どこで起きたか
例外対応			保留一覧、通知履歴	戻せるか
記録に残らない作業			画面と実物の照合	集計との差
継続・修正・停止	―		上記の確認結果	責任者の判断
次の確認日	―		タスク、会議予定	誰が確認するか

この表は、効果を証明するための数値表ではありません。変更によって増えた作業と、その必要性を分けて判断するための記録です。

既存の導入手順と、変更後レビューの違い

AIを業務へ組み込む前には、起動条件、入力データ、人の承認点、例外処理を設計します。これはAIエージェントとRevOpsで扱っている導入・実装の設計です。

運用開始後に組織の現在地を確かめる方法は、AI活用を組織に定着させる方法とAI OMMで扱っています。業務フロー図を更新し続ける方法は、業務フロー図をAIで作る方法の対象です。

この記事の対象は、個別の業務変更を実施した後です。組織全体の成熟度ではなく、変更した一つの業務について、現場が引き受けた確認と手戻りを変更前後で比べ、次の判断を残します。

次に確認すること

直近でAIの設定、入力データ、承認点を変えた業務を一つ選んでください。変更前後で業務の開始点と完了条件をそろえ、対象期間と件数を記録します。次に「人が確認した時間」「修正・差し戻し」「記録に残らない作業」を埋めます。判断する前に残りの行も確認し、継続・修正・停止と次の確認日を記録します。

業務の境界、変更権限、停止条件を社内だけで決めにくい場合は、diverへ相談するから、対象業務と現在の確認方法を共有してください。

参照元

NIST AI RMF Playbook — Manage（本番運用後の監視、利用者からの入力、変更管理。2026-11-11確認）
NIST — Challenges to the monitoring of deployed AI systems（本番運用後の監視の目的と現時点の課題。2026-03-06公開、2026-11-11確認）
デジタル庁 — ガバメントAI 源内におけるAIエージェント利用環境と「源内基準」（業務に合わせたAIエージェントの作成・実行・改善。2026-11-06更新、2026-11-11確認）

記事情報

著者: diver編集部
レビュー: diverチーム
作成日: 2026年11月11日