書類読取AIに任せない「値の確定条件」

たとえば、取引先から届いた見積書を生成AIで読み取り、社内システムへ登録する場面を考えます。金額も日付も所定の欄に入り、画面上は完成しています。ところが、金額の単位は千円、日付は見積日ではなく有効期限だったとしたら、どの段階で気付けるでしょうか。

本稿は、AIの読み取り結果をそのまま確定値にせず、「原文から拾った値」「業務向けに変換した値」「検証を通過した値」を分ける設計を勧めます。先に決めるべきなのは、出力の見た目より、各項目を何の根拠で受け入れるかです。

読み取りと業務上の変換を分ける

リコーは、企業や担当者の処理ルールに合わせて読み取り結果を変換する「適応型AI-OCR」を、受領請求書・受領納品書のサービスに実装したと説明しています。[1] OCR（光学的文字認識）は、画像などに含まれる文字を読み取る技術です。[4] 同社の説明には、番号の一部を抽出する処理や、和暦を西暦へ変換する処理が挙げられています。[1]

現行のサービス解説でも、利用者の修正履歴を生成AIへ取り込み、処理ルールに合わせた出力を行うとしています。[4] いずれも提供企業の説明であり、利用企業の削減効果を独立に検証した資料としては扱いません。

ここから考えたいのは、正しく写す作業と、業務用の値へ直す作業の境界です。たとえば、番号の先頭を取り除く場面では、相手の管理番号としては正確でも、自社の登録ルールには合わない値があり得ます。最終値だけを比較する試験では、読み取りと変換のどちらが違ったのか判断できません。

設計時には、原文の文字列、変換後の値、適用したルール、根拠となるページや箇所を別々に持たせます。原文を読み取れていないのに変換後だけ埋まっている場合は、確定せず確認へ回す方針にしてください。根拠箇所もAIに出させるなら、その場所に対象の記載があるかを検証対象に含めます。

出力の型が正しくても、値の意味は別に確かめる

構造化出力とは、項目名やデータ型などを定めた形式で回答を受け取る方法です。[2]GoogleのGemini API公式文書は、JSON Schemaという形式定義に沿った出力を説明する一方、構文が正しいJSONでも値はアプリケーション側で検証するよう求めています。[2] 形式に合っていても意味が誤った出力への対処も、明記されています。[2]

この区別を業務の受け入れ条件へ落とし込みます。金額欄なら数値であるかに加え、通貨、単位、税込み・税抜きの別を確認対象にします。日付欄では日付として読めるかだけでなく、発行日、有効期限、納期のどれを指すのかを定義してください。

たとえば「金額12、単位は千円」という架空の入力を円単位へ変換するなら、登録候補は12,000円です。単位を失った12という値も数値としては成立します。試験では文字列の一致だけに頼らず、単位を含めた変換結果を比較する必要があります。

空欄の扱いも仕様です。「記載なし」「文字を判読できない」「候補が複数ある」「対象外」を一つの空欄にまとめないことを勧めます。記載がない金額をゼロで埋めると、未確認なのか、金額がゼロなのかを区別できなくなります。値を空にできる形式と、空である理由を併せて設計しましょう。

AIへ任せる部分と、決まった規則で検証する部分

選択肢は、AIに抽出から修正まで任せる、決まった規則だけで処理する、両者を組み合わせる、の三つです。本稿では、書類の表現を読み取る段階にAIを使い、確定済みの変換規則や照合条件は通常のプログラムで実行する構成を第一候補とします。

たとえば、部署コードが登録済みか、期間の開始日が終了日以前か、同じ明細が重複していないかを確かめます。合計額を照合する場合は、割引や端数処理を含む計算規則を業務側と決めてから実装してください。規則が未確定のまま差額を誤りと断定すると、確認担当者に根拠のない修正を求める設計になります。

AIにすべてを任せる案を採ると、抽出結果と検証結果の両方をどう評価するかが課題になります。AIが生成した説明を、値が正しい証明として扱うべきではありません。反対に、様式や表現が変わるたびに規則を追加する案は、追加作業を誰が継続するかまで比較する必要があります。

もともと必要な項目が構造化されたデータで受け取れるなら、書類画像へ変換してAIで読み直す前に、直接連携を検討してください。AIの導入自体を目的にせず、受け渡す値と意味を双方で合意できる経路を優先します。

信頼度のしきい値を、確定の唯一の条件にしない

MicrosoftのDocument Intelligence公式文書は、抽出項目について推定信頼度を返すものの、すべての項目が信頼度を持つわけではないと説明しています。[3] また、表のセルが正しくても、同じ行に読み落としの可能性があれば、セルと行の信頼度は異なり得るとしています。[3]

したがって、書類全体に一つのしきい値を置く前に、どの項目をどの単位で判定するかを決めます。信頼度が得られない項目を、問題なしとして通す方針にはしません。値の形式、根拠箇所、業務上の整合性、信頼度が得られる場合の水準を、別々の条件として扱います。

受け入れ条件は、読みやすい書類だけで決めないでください。試験用の書類には、単位が欄外にある例、ページをまたぐ明細、似た名前の取引先、訂正前後の値が併記された例、必須項目がない例を含めます。調整に使う書類とは別に、条件を決めた後で試す書類も取り置きます。

試験では、読み取れた項目の割合だけでなく、誤った値を確定候補へ通した件数と、確認へ回した件数を併記することを勧めます。確認を増やせば現場の負担も増えます。逆に、確認を減らすために条件を緩めるなら、どの種類の誤りを受け入れる判断なのかを明示しなければなりません。

確定条件を、業務側が更新できる成果物にする

確認画面では、抽出値だけでなく、原文の該当箇所、変換内容、条件に合わなかった理由を並べます。担当者が値を直した際は、読み取り誤り、変換規則の不備、書類そのものの矛盾を分けて記録してください。修正結果を一律に学習へ戻す前に、何を修正したのかを区別する方針です。

顧客と企画から試作、実装、定着まで進めるForward Deployed Engineering（FDE）では、項目ごとの定義表を業務側と開発側の共通成果物にすることを勧めます。項目の意味、根拠、変換規則、欠損時の扱い、確定条件、その条件を変更する責任者まで記載します。モデルや指示文を変更したら、取り置いた書類で再確認します。

原文を確認できず、項目の意味や正解を業務側でも定義できないという場合には向きません。その状態では、AIの出力を業務値として確定する条件を設計できないためです。まず書類の受領方法や入力項目の定義を見直すところから始めてください。

実務への示唆

提言1：項目の意味と欠損の扱いを、試作前に決めてください。 金額なら単位と通貨、日付なら何の日付かを、期待する出力例とともに定義します。

提言2：原文、変換値、検証結果を分けて受け渡してください。 正しい形式で届いたという理由だけで、業務システムの確定値にはしません。

提言3：誤った値を通した件数と、確認へ回した件数を並べて判断してください。 自動化の範囲は、見栄えのよい出力ではなく、確認担当者が処理できる条件まで含めて決めます。

参考資料

1. リコー「生成AIが企業・担当者ごとの帳票処理ルールに合わせてOCR結果を最適化する『適応型AI-OCR』を開発」（2025-05-08、発表時のニュースリリース、確認日：2026-09-23）
2. Google, Structured outputs（2026-09-17、現行HTML（版番号なし）、確認日：2026-09-23）
3. Microsoft, Interpret and improve accuracy and confidence scores（2026-04-08、Document Intelligence v4.0、API 2024-11-30 GA、確認日：2026-09-23）
4. リコー「生成AI活用によるAI-OCRの更なる進化」（公開・更新日不明、現行HTML（版番号なし）、確認日：2026-09-23）

本記事はAIを活用して作成し、公開前に自動レビューを実施しています。情報の確認日：2026-09-23。