AI OCRは読めても終わらない — 商品名・費目名を揃える「名寄せ」の話

AI OCRを比較しても導入に進めない理由

AI OCR製品をいくつか試すと、発注書や見積書、請求書から文字や金額を読み取るところまでは十分使えそうだと感じることがあります。それでも本番導入を考えた途端、手作業が残るケースがあります。

よくある場面を想定例として挙げます。FAXで届く手書きの発注書を読み取り、販売管理システムへ登録する場面です。OCRが商品名や数量を読み取れても、その商品名が自社の商品マスターと一致するとは限りません。取引先が独自の商品名や略称を書いていれば、自社の商品コードへ変換する作業が必要になります。手書きが混ざる帳票では、読み取り結果の確認も残ります。

会社ごとに様式が違う見積書を読み取り、金額や内訳を横並びで比較する場合も同様です。必要な項目を取り出せても、取り出した文字列をそのまま業務で使えるとは限りません。

ここで必要になるのが、OCRの後段に置く名寄せや表記揺れ補正です。AI OCRの導入を検討するときは、「読めるか」だけで評価を終えず、「読み取った値を自社で使う値へどう変換するか」まで確認する必要があります。

取引先ごとの商品名を自社の商品コードへ変換する仕組み

商品名の名寄せでは、まず取引先ごとの表記と自社の商品コードを対応させます。

ある商品について、自社では一つの商品コードで管理していても、発注書には取引先ごとに異なる名称が書かれることがあります。そのため、「この取引先のこの表記は、自社ではこの商品コードとして扱う」という対応表、いわば変換辞書を用意します。

最初からすべての表記を登録する必要はありません。実際に処理する帳票から表記を集め、確認した結果を変換辞書へ追加していく方法があります。運用を続けながら辞書を育てる考え方です。

AIを組み合わせる場合は、読み取った商品名から変換候補を出し、判断に迷うものだけ人が確認する方法も考えられます。確認された結果を次回以降の変換に利用すれば、人がすべての商品名を毎回探す運用を減らせます。

さらに業務で必要になる場合は、商品コードへ変換した結果を販売管理システムへ登録するところまでつなぎます。OCR、名寄せ、既存システムへの登録を一連の処理として考えると、どこに人の確認を残すべきかも整理しやすくなります。

「送料」「配送料」「運賃」をどう揃えるか

名寄せが必要なのは商品名だけではありません。請求書や見積書では、同じ費用が異なる名前で記載されることがあります。

たとえば「送料」「配送料」「運賃」が同じ費用を指していたとしても、文字列だけを見れば別の項目です。そのまま集計すると、同じ費用が複数の項目に分かれてしまいます。

この場合も、OCRが正しく文字を読めたかどうかとは別に、自社で使う費目へ変換する処理が必要です。

対応方法は商品名と同じです。帳票上の表記と自社の費目を結ぶ変換辞書を用意し、過去に確認した表記は自動で変換します。辞書にない表記についてはAIが候補を示し、判断が難しいものだけ人が確認する方法が考えられます。

こうした処理を設けることで、帳票の表記をそのまま保存するだけで終わらず、集計や会計処理で利用する項目へ揃えるところまでつなげられます。

OCR製品の標準機能と自社向け作り込みの境界

AI OCR製品を比較するときに混同しやすいのが、「文字を取り出す機能」と「自社の業務ルールに合わせて変換する処理」です。

OCR製品は、帳票から文字や金額などを読み取るための製品です。一方、「取引先Aが書くこの商品名を自社の商品コードXへ変換する」「この費目表記を自社の勘定上の分類へ揃える」といったルールは、その会社の業務やマスターに依存します。

そのため、OCR製品の標準機能だけを比較していても解決しない場合があります。

PoCやデモでは帳票を読み取れていたのに、本番運用になると進まなくなる理由もここにあります。実運用では、例外となる表記への対応、既存システムとの連携、人が確認する条件、確認後の修正を次回へどう反映するかといった設計が必要になります。

これはAI導入全般でも起こります。デモで処理できることと、日々の業務として継続して扱えることの間には、例外処理や既存システム連携、運用設計があります（「AI導入がPoCで止まる3つの理由」で書いた「作り込み不足」の、これが具体例です）。

私たちのようなエンジニアリングサービスが担当するのも、この部分です。OCR製品自体を新しく作るのではなく、既存のAI OCR製品を利用し、その後ろに必要な変換・補正・システム連携を組み合わせます。

クラウドOCRを自社で使うか、作り込みを外部へ頼むか

すべての帳票処理で個別開発が必要になるわけではありません。

読み取った内容を人が確認し、そのまま転記できる業務であれば、クラウド型のOCRサービスを自社で設定して運用する方法があります。帳票の種類が限られ、名寄せや既存システム連携がほとんど必要ない場合も、この方法を検討できます。

一方、OCRの後に商品コードや費目への変換が必要で、さらに販売管理や会計など既存システムへの登録までつなげたい場合は、OCRサービスの設定だけでは作業が残る可能性があります。

判断するときは、OCRが何文字読めるかだけを見るのでは足りません。

読み取った後に人が何を確認しているのか。どの値を自社のマスターへ変換しているのか。どのシステムへ登録しているのか。例外が出たとき誰が判断しているのか。

ここまで整理すると、自社設定で運用できる範囲と、個別に作る部分を分けやすくなります。

守りの設計 — 帳票を外へ送ってよいか

発注書や見積書には、取引先名・商品名・単価・数量が並びます。クラウドのOCRサービスを使う場合は、読み取り精度の前に、どの帳票を外部へ送ってよいかを決める必要があります。

• 帳票ごとの線引き: 外部のサービスへ送ってよい帳票と、社内で読み取る帳票を分ける
• 変換辞書も機密として扱う: 取引先ごとの表記と自社コードの対応表は、取引関係そのものを表す
• 登録の権限: 既存システムへの登録は、必要な項目への書き込みだけを許可する

外へ出せない帳票は、社内に置いたサーバーで読み取りと変換を行う閉域の構成も検討できます。

フォースネットのセキュリティFDEでは、既存のOCR製品を活用する前提で、帳票の線引き、変換辞書の扱い、既存システムへの登録の権限まで含めて検討します。AI OCRを使いたいが、帳票を外へ送ってよいか判断がつかない場合は、初回の見立て（無料・30分・オンライン）でご相談ください。