多言語請求書OCRの評価手順：正解データ・精度計算・会計連携の確認方法

製造業における多言語請求書OCRの評価とは、受け取った請求書から文字と項目を取り出し、確認・修正を経て会計システムに渡すまでを、自社の正解データで検証することです。製造業の経理・DX担当者が判断したいのは、デモで何文字読めたかに加え、誤った金額や通貨を止められるか、確認作業を含めて負担が減るかです。本記事では、評価前に何を決め何を残すかを起点に、実帳票を調整用と最終評価用に分けて経理担当と正解データ・照合ルールを確定する進め方を示し、これを多言語OCR PoCとして小規模に設計する手順を説明します。

評価は、対象帳票と正解を固定し、①文字認識、②項目抽出、③会計連携、④運用と費用の順に進めます。日本語・英語・タイ語・ラオス語を扱う場面を想定し、計算例と判定表を使って説明します。各社共通の合格点は置かず、自社で許容できる誤りと人手確認の条件から決めます。本文の数値例は計算を説明するための架空データです。税務処理・法定保存の適合判断は、適用国ごとに経理責任者や専門家へ確認してください。

最初に、対象の取引先・言語・帳票と、OCRに任せる処理の終点を決めます。「入力候補を作る」「承認済みデータを転記する」「支払処理へ渡す」では、誤りの影響も必要な試験も異なります。評価計画に対象範囲、正解の定義、合格条件、判定者を記録し、製品の結果を見る前に承認します。

受領した請求書を棚卸しし、取引先、言語、通貨、レイアウト、入力方法、ページ数を一覧にします。日本語の取引が大半でも、少数のタイ語・ラオス語帳票を含むなら、その条件を評価表から落とさないようにします。言語名だけで分類すると、同じ英語でも単一通貨の一枚物と、複数ページに明細が続く帳票の差を見失います。

通常の受領状況を代表する帳票群に加え、傾き、薄い印字、印影、折り目、手書き追記、ページ欠落など、止め方を試したい帳票を集めます。通常群は業務全体の負担を推定するため、難しい条件の群は例外への対応を確かめるために使い、結果を分けて報告します。難例を多く入れた集合の修正率を、そのまま全社の月間修正率として扱わないためです。

用意した帳票は、設定・抽出ルール・確認閾値を調整する集合と、最終判定に使う固定集合に分けます。同じ請求書のPDFと撮影画像、ほぼ同じ帳票の複製が両側に入らないよう、元の文書単位で管理してください。最終集合の答えを見ながら調整した場合は、別の未使用帳票で評価し直します。Googleのデータ分割解説も、学習・調整・テストの分離、重複の除外、実データを代表するテスト集合を扱っています。

必要件数は、対象条件と許容する誤りを決めてから計画します。JAISAの画像認識技術導入ガイドライン26ページは、サンプル数を一律に決める難しさを述べ、顧客要件を伝えて相談しながら目標を決める考え方を示しています。特定の枚数を集めること自体を合格条件にせず、各条件で何文書・何項目を試し、何が未評価かを残します。

成果物は「文書ID、条件、調整用／最終評価用、正解作成者、版」を持つ帳票台帳です。評価用に加工した画像を使う場合も、原本との対応を残します。社外サービスへ渡す前に、利用目的、送信先、保存・削除、アクセス権を確認し、必要なマスキングを行います。

正解データは、原本を見て人が確定させた比較基準です。OCRの出力をそのまま正解へコピーすると、同じ誤読を見逃します。作成と確認を別の人が担当し、読み取れない箇所や判断が割れる箇所は、推測で埋めず保留理由を記録します。人数の多さより、正解の確定とツールの調整を区別できることが大切です。

各項目には、原文の値、機械処理用の値、変換ルールを持たせます。例えば、請求書番号は先頭ゼロを保持する文字列、金額は十進数として正確に扱える表現、通貨は別項目です。日付が「03/04/2026」なら、文書の地域・取引条件から解釈を確定できるまで変換を保留します。日付の順序や通貨を、言語だけで決めないでください。

単価や数量を一律に小数点2桁へ丸めると、原本との照合段階で情報を失います。小数桁、桁区切り、負数、値引き、単位換算、端数処理は項目別に定義し、会計側の受入仕様に合わせた変換の前後を記録します。金額が一致しても通貨が違えば不一致です。記載のない税区分と、抽出に失敗した税区分も区別します。仕訳・税コードの決定は、読み取った文字とは別の業務ルールとして経理担当が確定させます。

明細は「文書ID、ページ、正解行ID、品番、数量、単位、単価、税・値引き、行金額」で対応を持たせます。行の順番だけに頼ると、一行抜けた後の全行が誤対応になります。複数ページの継続行、同一品番の別行、ページごとの小計をどう対応させるかも先に決めます。

役割は、経理担当が値と業務ルールを承認し、技術担当が設定・出力・連携を記録し、評価責任者が範囲と判定を承認する形にすると整理できます。兼任する場合も、最終評価の正解を使って設定を直す手順にはしません。正解ファイル、項目定義、判定ルールを同じ版番号で固定し、変更したら影響する集計をやり直します。

文字認識は、正解テキストと出力テキストを同じ規則で比較します。CERとWERは誤りの傾向を調べる指標です。帳票全体の値が良くても、請求金額の一文字の誤りは残り得るため、業務上の重要項目はStep2で別に評価します。

CERは文字誤り率、WERは単語誤り率です。正解と出力を最小編集距離で対応付け、置換・削除・挿入を数えます。OCR-Dの評価仕様の定義に沿うと、計算は次の形になります。

CER =（置換文字数S＋削除文字数D＋挿入文字数I）÷ 正解文字数N

WER =（置換単語数S＋削除単語数D＋挿入単語数I）÷ 正解単語数N

説明用の計算例として、正解「AB1234」に対し出力が「AB1284」なら、置換1、削除0、挿入0、正解6文字なのでCERは1÷6＝約16.7%です。「AB12345」なら挿入1です。挿入が多い場合はCERが100%を超えることもあるため、「100%からCERを引けば文字認識率になる」とは扱いません。正解が空の領域は分母がゼロになるので、通常のCERと分けて不要文字の出力件数を記録します。

WERの計算例は、正解「TOTAL USD 100」、出力「TOTAL USD 1000」を空白で3単語に分ける場合です。単語の置換が1なのでWERは1÷3＝約33.3%になります。この値は分かち書きの規則で変わります。日本語・タイ語・ラオス語を同じ方法で比較するなら、使う単語分割器、辞書、版を固定してください。文字で数える場合も、Unicode正規化、結合文字を含む文字単位、空白と改行の扱いを記録します。OCR-DではNFC正規化した書記素クラスタを用います。

原文どおりの厳密比較と、合意した表記差だけを整える比較は別々に出します。空白の扱いを揃える変換と、通貨記号・小数点・マイナス記号を消す変換は同じではありません。評価しやすくするために重要な誤りを消していないか、原文と変換後を確認します。

実際の集計では、言語、帳票形式、画質ごとに、文書数、正解文字数、S・D・I、CERを残します。全体CERは各文書の誤り数を合計し、正解文字数の合計で割ります。短い文書と長い文書のCERを単純平均した値とは区別してください。読み取りに失敗した文書を成功分から黙って除外せず、失敗件数と評価から外した理由を併記します。これで、文字認識を直すべき条件と、項目抽出で確認するべき箇所を絞れます。

項目抽出では、値だけでなく「どの文書の、どの項目・明細行に属する値か」を照合します。主要項目の適合率・再現率・F1と、重要項目が一式揃った文書の割合を分けると、平均値に隠れる金額・通貨の誤りを見つけやすくなります。

最初に照合条件を決めます。本記事の評価設計では、文書ID・項目名・必要な明細行が対応し、値が正解と一致する出力をTP（正しい抽出）とします。正解に対応しない出力はFP（余分・誤った抽出）、取得できなかった正解はFN（取りこぼし）です。誤った値を一つ出すと、誤出力のFPと、本来の正解を取れなかったFNの両方になります。照合は一対一とし、同じ正解項目に複数の出力を一致させません。余った重複出力はFPとして数えます。この数え方はGoogle Document AIの評価説明でも使われています。

適合率（Precision）= TP ÷（TP＋FP）

再現率（Recall）= TP ÷（TP＋FN）

F1 = 2TP ÷（2TP＋FP＋FN）

計算例として、正解項目100個に対して98個を出力し、そのうち95個が正しく、3個が誤値、残り2個は未出力だった場合を考えます。TP＝95、FP＝3、FN＝5です。適合率は95÷98＝96.94%、再現率は95÷100＝95.00%、F1は190÷198＝95.96%になります。この数値は方式の説明用で、製品の実測値ではありません。分母がゼロかどうかは指標ごとに判定します。正解があるのに出力がない場合、適合率は算出不可、再現率とF1は0です。正解も出力もない場合はすべて算出不可とし、満点を付けません。

まず請求書番号、取引先、日付、金額、通貨、税の記載、品番、数量、単位を項目別に集計します。全体のF1はTP・FP・FNをそれぞれ合計してから計算し、言語別・項目別F1の単純平均とは区別します。原文の一致と、承認済み変換後の一致は列を分けます。取引先名の略称を同じ企業へ対応させる処理も、OCRの文字認識とは別に評価してください。

判定表は、重要項目の誤りを先に読める形にします。

モデルの信頼度は、手元の請求書で測った正答率とは分けます。確認へ回す閾値は調整用データで決め、固定した閾値を最終集合で試します。信頼度が高くても誤る例を集計し、金額と通貨の組合せや明細の欠落など、信頼度以外の確認条件も試してください。Microsoftの透明性ノートは、自社用途での評価と、人手確認を含む設計を扱っています。

連携試験では、送信成功の応答と、会計側に保存された内容を照合します。テスト用の事業所・環境に接続し、認識から登録まで文書IDで追跡してください。OCRの設定が固まる前でも、正解データから作った入力で連携仕様を先に確かめられます。

会計ソフトの対象製品・版・連携方式を記録し、実際に使う公式仕様から必要項目、文字コード、日付、通貨、税コード、認証、制限を確認します。APIがすべてOAuth方式である、再送をすべて自動で重複排除する、といった共通仕様は仮定しません。CSVとAPIの両方を採用する場合は、それぞれ試します。

正常系では、原本、正解、OCR出力、変換後データ、会計側の保存値を一件ずつ突き合わせます。CSVなら区切り文字、引用符、セル内の改行、先頭ゼロ、小数・負数、多言語文字を確認します。APIなら項目の型、必須値、認証失効、リクエスト制限、エラー応答を確認します。取り込み件数だけでなく、金額・通貨・取引先・伝票の対応まで一致したことを合格条件に含めます。

障害時の試験には、次の観点を入れます。これは評価項目の設計例であり、すべての会計ソフトが同じ動作をするという意味ではありません。

同じ請求書番号でも別の取引先が発行する場合があります。重複判定は番号だけで決めず、元文書・取引先・送信履歴・会計側IDをどう結び付けるか設計します。訂正請求書や取消も想定し、「似た値だから重複」として新しい取引を消さないことを確認します。

試験後は、入力文書の一覧と、正しく登録されたもの、確認待ち、失敗、取消の状態を照合します。一件も所在不明にしない管理表を作り、エラーを直した後に再開した結果まで残してください。APIの成功率だけが高くても、未送信・重複・誤った保存値があれば連携の合格にはしません。

最終判断は、精度、誤りを止める仕組み、担当者の負担、復旧の手順を合わせて行います。ここで使う受入条件は自社で決めるもので、特定のF1を超えれば無人化できるという業界共通の基準は置きません。

評価の前に、次の表の「条件」を業務責任者と決め、最後に実測値と未達理由を書き込みます。

「重要誤りは試験中に観測しなかった」と「重要誤りが起きない」は別です。少数の帳票で誤りがゼロでも、今後の安全を保証しません。評価した範囲に限って導入し、金額・通貨・取引先・税処理など影響の大きい箇所には、承認や照合を残すか、止める条件を明確にします。

人手工数は、OCR後に修正した項目数だけでは測れません。文書ごとの確認、修正、例外調査、再送、会計側との突合にかかった時間を合計し、同じ帳票を従来手順で処理した時間と比較します。説明用の計算例では、確認・修正60分、例外調査20分、突合10分なら、人手作業は合計90分です。既に合計した時間へ修正件数を再び掛けることはしません。初期設定・正解作成の一時費用と、毎月の利用料・確認工数も分けます。

判定は「全条件を満たした範囲で開始」「人手確認を残して限定開始」「原因を直して再評価」のいずれかにし、未評価の言語や帳票を明記します。導入後に取引先の様式やモデルの版が変わったら、固定した評価セットと新しい帳票で影響を確認します。

同じ帳票を使っていても、集計の分母、対象範囲、確認作業の数え方が変われば結論も変わります。比較表を埋める前に、良い結果だけが残る選び方や、運用上の負担が抜けていないかを点検します。

全体のF1が高くても、件数の多い日本語帳票に結果が引っ張られ、少数のラオス語帳票だけで起きる誤りを見落とすことがあります。言語・帳票形式ごとのTP・FP・FNと文書数を示し、「全体が良いから各条件も良い」と結論を広げないでください。複数言語が同じ請求書に混在する場合も、言語不明のまま全体集計へ寄せず、混在条件として記録します。

比較対象の製品には同じ固定集合と正解を使い、採用する機能・モデルの版、前処理、設定、評価日を残します。文字認識の対応言語と、請求書の項目抽出の対応言語は機能ごとに確かめます。OCR部分で言語を扱えることを、取引先名や明細の抽出まで保証する根拠にはしません。

結果の表には、入力した文書数、処理成功数、失敗数、除外数を並べます。処理に成功した帳票だけで精度を出す場合は、その条件を明示し、全体の処理失敗率も同時に示します。調整に使った帳票を最終評価に混ぜたり、難しい帳票を外した後の値を実運用全体の精度として示したりしないことが必要です。

件数を増やせない場合は、確認できた範囲を狭く報告します。例えば、評価した取引先だけで入力補助を始め、未評価の言語・様式は従来の人手処理へ回す設計です。追加データが揃った後で対象を広げれば、調べていない範囲まで一度に承認する必要がなくなります。

OCRで作ったテキスト、変換したCSV、会計側の伝票が揃っても、受領原本を辿れなければ修正や問い合わせに困ります。元のファイルを保持し、文書IDから抽出結果、確認者、変更内容、送信履歴、保存先IDへ辿れることを試験します。画像が欠けた、多重に取り込んだ、途中で止まったときにも、担当者が処理の現在地を確認できる形にします。

日本の保存制度を検討する場合は、紙で受領した書類を画像化するスキャナ保存と、メール添付PDFなど電子取引で受領したデータの保存を区別します。国税庁は電子帳簿等保存制度特設サイトで、それぞれの資料を公開しています。OCR精度や会計への取り込み成功だけを、保存要件に適合する根拠にはしません。保存期間や検索・訂正履歴などの具体要件は、受領形態と自社の条件に応じて確認してください。海外拠点には現地の制度があるため、日本の要件をそのまま当てはめません。

外部OCRサービスの試験では、契約上のデータ利用、保存場所、再委託、学習利用の扱い、保存期間、削除方法、閲覧権限を確認事項にします。これらは製品・契約で異なるため、一般的な機能名だけから判断せず、採用する構成で確認します。評価データの削除や権限解除までを終了条件に含めると、試験用のコピーが残り続けるのを防げます。

例外の処理にも担当を割り当てます。低信頼度、通貨不明、合計不整合、重複候補、連携失敗が、誰の確認待ちになるかを決め、担当不在時の引き継ぎと保留期限を試してください。月末に確認待ちが積み上がるなら、その処理時間も導入効果の計算へ含めます。画面上の認識結果だけを見て終えず、原本へ戻れること、担当者が止められること、復旧後に突合できることまで確かめます。

評価計画で迷いやすいのは、日程の見積もりと、どこまで自動処理へ進めるかです。どちらも、評価する範囲と残す確認作業を決めると判断しやすくなります。

サンプルを揃える日、正解を承認する日、連携環境を使える日を先に確認し、作業量から見積もります。評価期間を一律に何週間と決める方法では、取引先からの提供待ちや、経理担当の確認待ちを取りこぼします。

見積もりは「帳票の収集・利用確認」「正解作成と検収」「OCRの設定と調整」「連携実装」「固定集合での試験」「不具合対応と再試験」に分けます。各作業に必要な人の作業時間と、外部の承認・提供待ちを別に記載し、並行できる作業を整理してください。まず少量で正解作成や確認にかかる実時間を測り、残りの件数と難度をもとに日程を更新します。対象言語や連携方式を追加したら、その作業分も見直します。

F1だけでは判断できません。金額・通貨・取引先の誤りを通した件数、重要項目一式の正しさ、重複・欠落、承認待ちの扱い、障害からの復旧を確認します。

自動処理へ回す条件を決め、その集合だけの誤りと、人手へ回った割合を測ってください。信頼度の閾値を上げて自動処理数が極端に減るなら、精度が高く見えても工数削減につながるとは限りません。支払いや税務判断へ影響する操作は、必要な承認・権限・照合を業務責任者と設計します。小規模評価では限定した入力補助から始め、停止・差戻しが機能する範囲で段階的に広げる判断もできます。

多言語請求書OCRを評価するには、最初に対象帳票と処理の終点を決め、経理担当が承認した正解データを用意します。調整用と最終評価用を分け、文字認識はCER・WER、項目抽出は項目別F1と重要項目一式の一致、会計連携は保存値・重複・欠落・復旧まで確認します。

計算式だけで導入可否は決まりません。どの誤りを止めるか、誰が確認するか、確認と例外処理を含めて負担が減るかが判断の中心です。必要枚数・期間・合格値は、対象条件と許容する影響から自社で決め、評価した範囲を超えて結果を一般化しないようにします。

まず、実際に届く請求書の台帳と項目定義を作り、本記事の判定表に自社の条件を書き込んでください。基本的な処理の範囲はAI-OCR・インテリジェント文書処理の導入ガイド、確認作業の設計は人間参加型の業務自動化の基礎と合わせると、評価後の運用まで具体化できます。