判断の出発点
抽出された文字は記録の候補であり、承認済みの業務処理ではありません。重要な項目、照合方法、人が確認する条件を決めます。抽出器の信頼度は判断材料ですが、業務上の確認の代わりにはなりません。
具体例で考える
架空の請求書受付なら明細合計、通貨、仕入先ID、請求番号を照合します。元のページと抽出項目を並べ、該当箇所を強調します。見慣れた仕入先でも銀行情報が変わっていたら、文字が読めたかとは別の確認が必要です。
選択肢とその負担
固定書式にはテンプレートの規則、多様な書式には代表例で評価した学習型の抽出が候補です。例外だけの人手確認は測定が裏付けてから選びます。失敗の影響が大きいなら広く確認するところから始めます。
見落としやすい点
きれいなPDFだけで評価せず、スキャン、回転、欠落、重複、未知の書式を入れます。元文書、抽出の版、訂正をひも付け、疑義のある記録を追えるようにします。
疑わしい項目を中心に確認画面を作る
経理の運用担当と、小数点がコンマの請求書、通貨欠落、番号重複、明細と合わない合計を選びます。正しい値と不一致時の処理を記録します。これは試験集であり精度達成の宣言ではありません。学習用の例とリリース評価用の例は分離します。
原本の該当箇所、抽出値、検証問題、訂正を一緒に見せます。待ち行列を空けるため値を作るのではなく、却下や未解決を選べるようにします。例外承認には理由と責任者が必要です。最初の抽出と承認済み訂正を残し、モデルと人の判断を区別できるようにします。
抽出、承認、計上を分ける
文書に固定参照を与え、受領、抽出、要確認、承認、計上を追跡します。抽出の再試行で二重債務を作ってはいけません。重複キーは業務側と決め、仕入先と請求番号の組合せや訂正版の置換関係を検討します。ファイル名は新しい業務イベントの証拠ではありません。
サービス停止時も受領記録と待機状態を保ちます。緊急の手動経路にも同じ重複・承認確認を適用します。モデルや規則の変更時は、以前訂正した項目を含む難しい例を再試験します。計上を止める例外は運用側が決め、開発側が実装します。銀行口座を正しく読めたことは、その正当性の独立検証ではありません。
依頼前に確認すること
誰が承認するか。何の不一致で登録を止めるか。訂正を次の評価へどう使うか。AI連携で管理方法を決め、未確認の読み取り結果から重要操作へ直結させないでください。