AI自動転記の「確認待ち」を作る方法｜誤登録・二重登録・上書きを防ぐ設計
AIが読み取った情報をすぐ本番台帳へ書かず、原文と候補を確認して確定する仕組みを、状態管理・重複防止・修正履歴まで説明します。
公開仕様と一般的な業務上の確認事項を基に整理したガイドです。本文の例は説明用に作成し、個別の顧客や個人を特定する情報は掲載していません。
AIが作った候補と、人が確定した値を分けて保存します。原文・止めた理由・確認担当を一画面に置き、重複処理や確定値の上書きを防いでから、承認済みの値だけを登録します。
メールやチャットをAIで読み取り、台帳へ移す。試してみると、「名前が似ている」「日付が書いていない」「同じ内容が二回届く」といった問題が出てきます。読み取り精度を上げるだけでは、誤登録を防ぎきれません。
最初に作りたいのは、候補と原文を並べて確認できる場所です。本記事では、実装前に決めておくとよい「確認待ち」の設計を説明します。
1. AIの候補と、確定した台帳を分ける
AIが出した値を本番台帳へ直接書かず、下書きの一覧へ入れます。状態は、少なくとも次のように分けます。
| 状態 | 意味 | 次にすること |
|---|---|---|
| 確認待ち | 候補ができたが、登録の判断は未完了 | 担当者が原文と照合する |
| 差し戻し | 原文だけでは決められない | 不足情報を確認する |
| 登録待ち | 人が値を確定した | 決めた登録先へ反映する |
| 登録済み | 登録先で反映を確認できた | 登録先IDと日時を残す |
| エラー | 読み取りや登録が完了していない | 原因と実際の反映状況を調べる |
「AIが読み取りを終えた」と「業務が完了した」は別の状態です。予定日が過ぎても、実施や入金などの完了を自動的に付けないようにします。
NISTのAIリスク管理資料でも、運用後の監視に加え、人による判断の変更、事故対応、復旧の仕組みを持つことが示されています。NIST：MANAGE 4.1
2. 確認画面には、止めた理由を出す
確認者が毎回メッセージを探し直すと、自動化しても手間が減りません。一件のカードや行から、次の情報を見られるようにします。
- 受付IDと、権限のある人だけが開ける原文・添付の参照先
- 原文の受信日時、読み取った版、処理日時
- AIの候補値と、該当する原文の短い部分
- 「数量の単位がない」など、確認が必要な理由
- 確認担当、対応期限、確定者、確定日時
- 登録先IDと、修正・取消の履歴
例えば架空の文「品目C、20、来月初め」では、数量の単位と具体的な日付が決まりません。「20個」「翌月1日」と補わず、未確定のまま止めます。人名・品目名は登録済みの候補と照合し、複数に一致した時も確認へ回します。
AI自身が出した「自信度90％」は、その業務で正解する確率として検証された数字とは限りません。最初は自己申告の点数で通過させず、「必要項目がある」「候補が一つ」「原文と値を照合できる」といった確認条件を使います。条件を満たしても、金額や期限などの重要項目は人が確認します。
3. 同じ入力を二回処理しても増えないようにする
通信が切れると、同じ処理が再実行されることがあります。LINEでも同じWebhookイベントが重複して届く可能性があり、公式資料はイベントIDによる重複検出を案内しています。LINEの再送仕様
台帳側では「元データのID・版・登録対象・処理の種類」を識別し、同じ登録が完了していれば追加しない仕組みを作ります。同時に二つ届く場合も、二つの処理がそれぞれ「未登録」と判断しないよう、実装担当者に確認します。
文章が同じという理由だけで重複扱いにすると、別の日の正当な依頼まで消えることがあります。一方、原文が訂正された場合は、新しい版として変更候補を作り、以前の確定値との差を確認します。
4. 人が直した値を、再実行で上書きしない
候補欄と確定欄を別に持ち、AIの再実行は候補欄だけを更新します。確定済みの数量や日付を変える時は、変更前・変更案・理由を並べ、もう一度確認します。
確認後、登録するまでに別の人が台帳を直した場合もあります。登録直前に「確認時と同じ版か」を確かめ、違えば自動更新を止めます。これは、最後に実行した処理が勝手に正解になる事故を防ぐためです。
訂正履歴には必要な項目だけを残します。パスワードや不要な個人情報を原文の抜粋、通知メール、エラーログへ広げないようにします。
5. エラー時は、反映済みか確かめてから再実行する
登録先が保存した直後に通信が切れると、こちらにはエラーでも台帳には入っていることがあります。何も確認せず再登録すると二重になります。登録先IDや受付IDで照合し、未反映が確認できた処理だけ再実行します。
誤登録を戻す時も、古い台帳全体を復元すると、その後に人が直した情報まで失われかねません。Microsoftの設計資料も、復旧では他の処理による変更を考慮する必要があると説明しています。失敗した処理を取り消す設計
戻す範囲を特定できる記録を残し、影響を確認して修正します。外部へ送ったメールなど、元どおりに戻せない処理は、台帳への登録と別の承認段階に置きます。
6. 確認待ちをためない運用にする
担当者が不明な確認待ちは、形を変えた作業漏れです。誰がいつ一覧を見るか、不在時に誰へ回すか、期限を超えた時にどこへ知らせるかを決めます。通知には機密の本文を載せず、権限付き画面への案内を使います。
初回テストでは、同じ入力の再送、途中停止、原文の訂正、確認者二人の同時操作を試します。「一回うまく入った」だけで運用開始を判断しないことが重要です。
この設計だけでは足りない場合
確認できる原文がない、確認者が正誤を判断できない、取り消せない処理が多い場合は、対象範囲を絞ります。確認待ちを作るだけで安全になるわけではありません。まず、間違いを見つけられ、止められ、修正できる社内台帳から始めます。
確認担当者の一回の操作を具体化する
架空の訂正「数量を8個から6個へ変更」を受けたら、画面に「現在の確定値8個」「変更候補6個」「訂正の原文」を並べます。担当者は対象の行を確かめ、数量だけの変更を承認します。日付など、今回の訂正に関係しない欄まで同時に更新しないようにします。
ボタンも「確認」だけでは曖昧です。「この値で登録」「情報不足で差し戻し」「対象外として終了」のように結果が分かる名前にします。対象外を選んだ記録は、本番台帳に入りません。
一括承認を付ける場合は、未確定項目や訂正がある行まで選択されないかを試します。画面に出ていない行をまとめて承認せず、承認する範囲と変更内容が見える状態にします。
参考にした公式情報
確認日：2026年10月15日。本記事の画面・状態名は設計例です。特定製品に標準搭載されていることを示すものではありません。