注文書のAI-OCRは「読めた後」で決まる｜取引先の品番を自社の品番につなぐ表と、読めなかった注文の戻し先

注文書のAI-OCRで受注の入力が減るかどうかは、文字を読む精度だけでは決まりません。読めた品名や品番を自社の品番につなぐ表、数量と単位をその取引先の過去の注文と比べる点検、人に回す条件、そして読めなかった注文をどこへ戻すか。これらが決まっていないと、読み取りが正しくても、担当者は結局すべての注文を見直すことになります。

品番をつなぐ表（以下、対応表）は、過去の注文書と、そのとき販売管理に入力した受注データを突き合わせれば作り始められます。人に回す条件や、読み取りの信頼度をどこで区切るかは、自社の注文書で試した記録を見て決めます。記録の取り方を先に決めておけば、帳票型のAI-OCRと、LLM（大規模言語モデル）で読む方式も、同じ物差しで比べられます。

この記事では、FAXやPDFで届いた1枚の注文書が受注一覧に載るまでを、工程の順に追います。FAX・電話・Webの注文を同じ受注一覧に集める設計は、FAXで注文してくる取引先が残っても、受注のシステム化はできるで書きました。ここでは、読み取った後の突き合わせと、例外の扱いに絞ります。

読めた文字を、そのまま受注には入れられない

AI-OCRを受注の入力に使う例は、中小企業を対象にした調査にも出てきます。東京商工会議所が2026年6月に公表した「中小企業のデジタルシフト・DX実態調査」集計結果（調査は2026年3〜4月、主に東京23区の中小企業1,272社が回答）の自由回答には、AI-OCRの導入で受注の入力作業が減ったという卸売業（101〜300人）の声や（p.33）、請求書・注文書・出荷の書類をAIで読み取って基幹システムにつないだ卸売業（21〜50人）の声が載っています（p.36）。

ただ、文字が正しく読めても、そのまま受注に入れられるとは限りません。注文書を読んだ後には、たとえば次のような行が残ります。

• 品名が取引先の呼び方（略称、取引先側の品番、古いカタログの番号）で書かれていて、自社の品番と一致しない
• 数量の単位が書かれておらず、「10」がケースなのか個なのか、注文書だけでは決まらない
• 読み違えた品番が、たまたま自社の別の品番と一致してしまう
• 手書きの訂正、備考欄の「前回と同じ」「至急」、前に送った注文の変更や取り消しなど、注文書の外の情報が要る

厄介なのは3つ目です。読み取った品番が商品マスタにあるかどうかだけを確かめていると、この行は点検を通ってしまいます。読んだ文字を商品マスタと照らして、近い品番に自動で置き換える機能を持つ製品もありますが、置き換えた先が正しいかどうかは、その取引先がふだん何を頼んでいるかを見ないと分かりません。

品番がそろわないのは、読み取りの問題というより、取引の側の事情です。中小企業庁の委託調査の報告書（令和3年度「中小企業の受発注のデジタル化推進方策に関する調査」報告書、2022年3月）は、電気工事・電材卸の業界について、メーカーごとに型番や商品コードが違い、ビスやボルトのように1本単位では商品コードが無い部品もあるため、データにしにくい商品があると書いています（p.47）。流通のボランタリーチェーンについては、新商品や季節商品で毎年何万件もの商品マスタが改められ、メーカーによっては商品コード（JANコード）を使い回しているために誤注文が起きている、としています（p.53）。どの読み取り方式を選んでも、読んだ後に自社の品番へつなぐ工程は残ります。

読み取りから受注一覧までを工程に分ける

工程ごとに、機械に任せることと、人に回す条件、回す先を並べると次のようになります。機械に任せる部分と人が見る部分の境目は、この図の上で決めていきます。

PDFで届く注文書のうち、取引先の販売管理から書き出されたものには、文字の情報がそのまま入っていることがあります。PDFの上で文字を1文字ずつ選択できれば文字の情報があり、ページ全体が1枚の画像としてしか選べなければ、画像のPDFです（Azure AI Document Intelligence のドキュメントも、同じ見分け方を紹介しています）。文字の情報を使えるなら、画像から文字を読む工程を通さずに済みます。Excelで届いた注文書も、セルの値をそのまま取り込めます。ただし、品番を引く工程から先は、FAXの注文書と変わりません。

この流れは、架空の書類で操作できる当社のデモ「請求書・注文書の読み取り」でも追えます。注文書の例では、商品マスタに無い品番（英字のOと数字の0の取り違え）と、価格表と違う単価に印が付き、人が候補の品番を選んだり、取引先に確かめるために注文を保留にしたりして確定するまでを、段階ごとに見られます（画像の読み取りは、用意した結果を表示する再現です）。

品番の対応表は、取引先と書き方の組を1行にする

対応表は、取引先の書き方と自社の品番を並べた表です。同じ「A-10」でも、取引先ごとに別の品物を指すことがあるので、行の単位は品番ではなく、取引先と書き方の組にします。

1行に持たせる列

表を持つ担当は、商品マスタを管理している人にします。受注の担当が行を足すことはあっても、「確定」にするのは商品マスタの担当、と分けておくと、似た品番への取り違えが表に入りにくくなります。

そろえてよい違いと、そろえてはいけない違い

表を引く前に、書き方の細かな違いをそろえます。全角と半角、英字の大文字と小文字、空白の有無、品番の中のハイフンに見える記号（「-」「－」「ー」など）の違いは、そろえても意味が変わりません。

一方で、英字のOと数字の0、英字のIや小文字のlと数字の1のように形の似た文字は、そろえる対象にしません。読み取りで取り違えやすい文字でもあるため、機械的に置き換えると、読み違いが表の上で正しい品番に化けてしまいます。完全に一致する行が無いときは、形の似た文字だけが違う品番を候補として人に見せ、人が選ぶ形にします。

品番の無い品目と、使い回される品番

1本単位のビスやボルトのように商品コードの無い品目は、品名と規格（「六角ボルト M8×30」など）で行を作ります。規格の書き方（「×」と「x」、全角と半角）をどうそろえるかは、品目の種類ごとに決めておきます。

商品コードが後から別の品物に使われる場合や、自社の品番を切り替えた場合に備えて、行には使い始めた日とやめた日を持たせます。やめた日より後に古い品番で注文が来たら、新しい品番を候補として人に見せ、自動では置き換えません。

最初の表は、過去の注文書と入力済みの受注を突き合わせて作る

表をゼロから手で書く必要はありません。過去の注文書には取引先の書き方が、そのとき販売管理に入力した受注データには、担当者が選んだ自社の品番が残っています。二つを組にすれば、担当者の頭の中にあった対応を表に起こせます。

1. 期間を決める：直近の数か月分を使います。季節によって頼まれる品目が変わるなら、1年分あると抜けが減ります。
2. 書かれていた文字を取り出す：過去の注文書が画像で残っていれば、試したい読み取りの仕組みで読ませます。紙しか残っていなければ、注文の多い取引先の分からスキャンします。
3. 注文書と受注を結びつける：取引先・注文日・注文番号で、注文書1枚と受注1件を対応させます。
4. 行を組にする：同じ注文の中で、数量と並び順を手がかりに、注文書の行と受注の明細を組にし、「書かれていた文字」と「入力された自社の品番」を並べます。
5. 組を数える：同じ取引先・同じ書き方に同じ品番が繰り返し入力されている組は、担当者が確かめたうえで「確定」にします。一度しか出てこない組は「候補」として残します。
6. 食い違いを人が決める：同じ書き方に別々の品番が入力されている組は、担当者が原本を見て決めます。入力の誤りのほかに、欠品で代わりの品物を出した、特別に別の品番で出した、といった事情が混ざっているからです。

作った表がどれだけ引けるかは、使い始める前に確かめられます。たとえば5か月分で表を作り、残りの1か月分の注文書の行を表で引いてみて、引けた行の割合と、引けなかった行の書き方を見ます。引けなかった行は、使い始めたときに人に回る行の見込みにもなります。

人が直した内容は、理由を見てから表に足す

使い始めると、人に回った明細を担当者が直すたびに、表に足す材料が出てきます。ただし、直した内容をすべて表に足すと、一度きりの事情が次の注文にも当てはめられてしまいます。直すときに理由を選んでもらい、理由によって表への反映を分けます。

AI-OCRの製品には、人が直した結果を覚えて、次から同じ書き方に同じ品番を入れる機能を持つものがあります。使う場合は、覚えた対応を一覧で見て直したり消したりできるか、直すたびに自動で覚えるのか、覚えるかどうかを選べるのかを確かめておきます。

読み取りそのものの誤りは、対応表では直りません。Microsoft の Azure Content Understanding のドキュメントは、正しい値を付けた見本で読み取りを改善する機能について、英字のlが数字の1として認識されるような文字の認識の問題は、見本を足しても直らないと説明しています（ドキュメントアナライザーの品質を信頼度、根拠、ラベル付けされたデータで検証する）。形の似た文字の取り違えは、表を引く段階と、次に書く過去の注文との比べで止めます。

数量と単位は、その取引先の過去の注文と比べる

品番が引けたら、数量と単位を確かめます。比べる相手は、その取引先がその品目を過去に頼んだときの数量です。取引先と自社の品番の組ごとに、過去の注文の回数、数量の範囲（いちばん少ないとき・多いとき）、よく頼む数量、使う単位を、入力済みの受注データから出しておきます。

そのためには、過去の注文がデータで残っている必要があります。中小企業庁の報告書は流通業界（ボランタリーチェーン）の課題として、電話やFAXなどアナログのやり取りでは過去の発注数量を振り返りにくいことを挙げています（p.54）。販売管理に受注を入力しているなら、その明細から作れます。

同じ考え方で、単価はその取引先の価格表と比べ、納期は日付として成り立つか（過去の日付や休業日になっていないか）を見ます。

図の最後の「初めての組」が、読み違えた品番が別の実在する品番に一致してしまう行を止める点検です。商品マスタにあるかどうかではなく、その取引先が頼んだことがあるかどうかを見ます。本当に初めての注文なら、一度人が確かめても手間は小さく、次からはその組も過去の注文に加わります。

どこからを「大きく超える」とみなすかは、会社と品目によって違います。最初は厳しめに止め、後で書く試験の記録で、止めすぎた件数と、止めずに誤っていた件数を見ながら緩めていきます。数量は機械で直さず、印を付けて人に回すだけにします。

人に回す条件と、信頼度の使い方

ここまでの点検で止まった明細のほかに、次のような注文も人に回します。

• 品番：表に無い書き方、候補が複数ある、「候補」の行で引いた
• 数量・単位・単価・納期：前の節の点検のどれかに当たった
• 読み取りの信頼度：製品が返す信頼度が、決めた値より低い
• 金額：1行または注文全体の金額が、社内で決めた額を超える（読み取りも照合も通っていても、誤ったときの損が大きいため）
• 注文書の外の情報：手書きの訂正や追記、備考欄の指示、前に受けた注文の変更や取り消し、初めての取引先

回すときは、注文全体を止める理由と、その明細だけを人が見れば済む理由を分けておきます。取引先が分からない、ページが欠けている、変更や取り消しの注文書である、といった場合は注文全体を止めます。品番や数量の印は明細ごとに付け、確認の担当は印の付いた明細だけを見ます。回した理由は自由な文章ではなく、決めた選択肢で残します。後で理由ごとの件数を数えるためです。

使い始めの数週間は、条件に当たらない注文も人が見て、条件で止められなかった誤りが無いかを確かめます。そのうえで、誤りを一度も見つけていない条件は緩め、誤りを通してしまった条件は厳しくする、という順で直していきます。

信頼度は、項目ごと・明細の行ごとに見る

Azure や Google の読み取りのサービスは、読んだ値ごとに、どれくらい確からしいかを0から1の数値で返します。Azure AI Document Intelligence のドキュメントは、この信頼度を予測が正しい見込みを表す値とし、自動で受け入れるか人の確認に回すかを決めるのに使えるとしたうえで、次のような注意を挙げています（正確性スコアと信頼度スコアの解釈と改善）。

• いまのところ、すべての項目が信頼度を返すわけではない
• 文字の読み取りの信頼度と、項目に当てはめた結果の信頼度は別のもので、両方を見る必要がある
• カスタムモデルでは、表（注文書でいえば明細）に表・行・セルそれぞれの信頼度があり、セルが正しくても、その行の信頼度は低いことがある

Google の Document AI も、抽出した項目ごとに0から1の信頼スコアを返し、低いときに人の審査に回す使い方を示しています（カスタム エクストラクタの概要）。評価の説明では、しきい値を高くするほど、しきい値を超えた値が正しい割合（適合率）は上がり、拾える値の割合（再現率）は下がるとしています（パフォーマンスを評価する）。業務に置き換えれば、しきい値を上げるほど、自動で通す値の誤りは減り、人に回る値は増える、ということです。

信頼度が高くても、誤りが無いという意味ではありません。前掲の Azure のドキュメントの説明でも、信頼度0.95は、20回のうち19回は正しい見込み、という意味です。信頼度は人に回す条件の一つとして使い、品番の照合や過去の注文との比べを省く理由にはしません。信頼度が高いのに読み違える例や、請求書での突き合わせの組み方は、OCRの結果をどう信じる？突合・例外リスト・ルール化までの考え方で書いています。

読めなかった注文の戻し先を、止まった理由ごとに決める

人に回した注文のうち、確認の担当だけでは片付かないものは、止まった理由ごとに戻す先を決めておきます。戻す先が「誰か見ておいて」のままだと、締め時刻を過ぎてから、誰の手元にも無かったことが分かります。読めなかった注文も受注一覧から外さず、止まっている理由と、いま誰の手元にあるかが一覧で見えるようにしておきます。

それぞれに、片付ける期限も決めます。基準にするのは、その取引先の注文の締め時刻です。締め時刻までに片付かないときに誰が取引先へ連絡するかを決め、連絡の窓口は一つにします。確認のために、同じ取引先へ別々の担当が何度も電話することを避けるためです。

変更や取り消しの注文書を新しい注文として受けてしまうと、同じ品物を二重に引き当てたり出荷したりすることになります。元の注文がすでに引当や出荷に進んでいれば、出荷の担当にもすぐ伝わるようにしておきます。

受注一覧には、読み取った値と確定した値を並べて残す

確認を通った注文は、Webから入った注文と同じ受注一覧に入れ、同じ状態の流れで扱います。そのうえで、読み取りを通った注文には、次のものを一緒に残しておきます。

• 原本（FAXの画像やPDF）
• 読み取った値と、確定した値（品番・数量・単位）
• 品番を引くのに使った対応表の行
• 人に回った理由、直した人、直した理由
• 製品が返した信頼度

引当・出荷・請求では、確定した値だけを使います。読み取った値を残すのは、後で取引先から誤りを指摘されたときに、読み違い、照合の誤り、確認での見落としのどこで起きたかをさかのぼるためです。次の節で書く記録を、日々の運用からも取れるようになります。

自社の注文書100枚で試すときの記録の取り方

製品の試用などで自社の注文書を読ませる前に、何を記録するかを決めておきます。見るのは、文字がどれだけ読めたかではなく、受注に入れる値（品番・数量・単位）が明細の行ごとに正しかったかです。Microsoft の透明性に関する注記も、読み取りの誤りを単語の単位で数える指標と、名前や金額といった項目の単位で数える指標を分けて説明し、書類全体では1文字の誤りでも、それが支払額の中にあれば、その請求書全体が誤りとして扱われうるとしています（Content Understanding の透明性に関する注記）。

選ぶ100枚

• 注文の多い取引先の注文書を中心に、注文の少ない取引先のものも混ぜる
• 手書き、FAXでかすれたもの、複数ページのもの、手書きの訂正があるもの、PDFで届いたものを含める
• 一部の取引先の注文書は、製品の設定や見本に使わずに残しておき、初めて見る書式としてどう読まれるかを確かめる

正解には、その注文書から実際に販売管理へ入力した受注データを使います。ただし入力データにも、打ち間違いや、欠品による代わりの品物が混ざります。読み取りの結果と入力データが違った行は、原本を見てどちらが正しいかを決めてから数えます。

明細の行ごとに残す項目

集計して見る数字

• 明細の行ごとの品番の一致率（表で引いた後の値で数える）
• 数量と単位の一致率
• 人に回らずに通った行のうち、正解と違っていた行の件数と中身
• 人に回ったが、直す必要のなかった行の件数
• 人が直した件数と、理由ごとの内訳
• 1枚あたりの確認の時間

中でも大事なのは、人に回らずに通った誤りです。一致率が高くても、ここに残った行はそのまま出荷の誤りになります。1件ずつ中身を見て、どの点検を足せば止まったかを考えます。反対に、直す必要のない行ばかりが人に回っていれば、確認の手間は手入力と変わらなくなります。信頼度のしきい値と、数量の点検の範囲は、この二つの件数を並べて決めます。

明細の行の区切りを読み違えると、その行の品番・数量・単位はまとめて誤りになります。Google の評価の仕組みでも、表の行にあたる親の項目が正解と一致しなければ、中の項目は文字が同じでも誤りとして数えられます（前掲の「パフォーマンスを評価する」）。行の区切りの誤りは、文字の読み違いとは分けて数えておくと、原因を切り分けやすくなります。同じ注文書を日を変えて2回読ませ、結果が同じになるかも記録しておくと、次の節の比べ方に使えます。

LLMで読む方式と帳票型のAI-OCRは、同じ記録で比べる

注文書を読み取る仕組みは、大きく分けて二通りあります。この記事では、次のように呼び分けます。

• 帳票型のAI-OCR：取引先の書式ごとに、読む位置や項目を設定するか、書式ごとの見本を読ませて学習させてから使う方式
• LLMで読む方式：生成AIに、読みたい項目を言葉で指定して読ませる方式。書式ごとの設定や見本なしで読ませ始められ、足りないところは見本を足して補える製品もある

このほか、請求書などの決まった種類の書類について、書式を問わず決まった項目を読む学習済みのモデルを用意している製品もあります。注文書向けのものがあれば候補に加え、同じ物差しで比べます。

公式ドキュメントで確かめられる範囲では、どちらの方式も同じ会社がそろえて提供しています。Microsoft では、見本で学習させる Azure AI Document Intelligence のカスタムモデルと、生成AIを使う Azure Content Understanding が、別のサービスとして並んでいます。Document Intelligence のカスタムモデルのうち、テンプレート型は見た目の一貫した書式を前提にし、書式のバリエーションごとにモデルが要ります。ニューラル型は、見本は要るものの、構造の違う書類を一つのモデルで扱えます（ドキュメント インテリジェンスのカスタム モデル）。

Google Document AI のカスタム抽出は、学習のさせ方を生成AI・カスタムモデル・テンプレートから選べるようにしており、テンプレートはレイアウトが固定された書類向けで見本は3件、生成AIはレイアウトのばらつきが大きい書類にも使え、見本は0〜50件以上、という目安を示しています（前掲の「カスタム エクストラクタの概要」）。Microsoft の選び方のガイドは、仕入先ごとにレイアウトが違う発注書を、書式のばらつきが大きい書類の例に挙げ、生成AIを使う Content Understanding を先に挙げつつ、見本で学習させる Document Intelligence のモデルも選択肢にしています（ドキュメント処理に適した Foundry ツールを選択する）。

どちらの方式を候補にする場合も、同じ100枚で次の点を確かめます。

表の「値の位置」と「信頼度」について、Microsoft の選び方のガイドは、Azure OpenAI などのモデルで自前に組む場合、信頼度と値の出どころ（根拠）は標準では得られず、作り込みが要るとしています。信頼度が無ければ、すべての結果を受け入れるか、見込まれる誤りの率をもとにすべての結果を確かめることになる、とも書いています。一方、生成AIを使う Content Understanding は、設定で有効にすると、項目ごとの信頼度と、ページと座標で値の出どころを示す情報を返します（信頼度と根拠づけの説明）。書類に無い値を補う働きは、LLMの方式に限りません。Google Document AI のドキュメントには、特定の処理と項目で、書類に書かれていない仕入先の住所を外部の知識から補う例が載っています（処理レスポンスを処理する）。

どちらの方式を選んでも、品番の対応表、数量と単位の点検、人に回す条件と戻し先は、同じように要ります。方式の違いが表れるのは、前の節の記録のうち、初めて見る書式での一致率、人に回らずに通った誤りの件数、新しい取引先を足すたびにかかる手間です。候補の製品を同じ100枚で試し、同じ表に記録して比べます。

kintoneで受注を管理している場合は、当社のOCR入力補助プラグインのように、レコードに添付した画像やPDFを生成AI（Anthropic・OpenAI・Gemini）に読ませて項目に入れ、人が直す流れを持つ部品もあります。この記事の呼び分けではLLMで読む方式にあたり、品番の対応表と戻し先は、読み取りとは別に用意します。

読み取りを試す前に、照合の表と戻し先を用意しておく

注文書のAI-OCRは、読み取りの製品選びから始まりがちですが、製品が決まる前に用意できるものがあります。過去の注文書と入力済みの受注から作る対応表、取引先ごとの過去の数量、人に回す条件、止まった理由ごとの戻し先、そして試験で残す記録の形です。これらがあれば、自社の注文書を試しに読ませたその日から、受注にそのまま入れられる行がどれだけあるかを数えられます。

Aurant Technologiesでは、読み取りの方式を自社の注文書で比べるところから、対応表と人に回す条件、戻し先の決め方、受注一覧への入れ方までを、今の販売管理や受発注の仕組みを止めずに組み立てています。受注から在庫・出荷・請求データまでをひとつながりで扱う仕組みは受発注・在庫管理システムの開発のページで、AIに任せる範囲と、人の確認や承認を通してから登録する形はAI活用支援のページで紹介しています。