注文書OCRの選び方7つの基準
注文書OCRを選ぶ際に確認したい7つの軸を、明細行、商品コード補完、FAX画質、手書き、確認画面、既存システム連携、料金体系の順に解説します。
注文書OCRを比較するとき、文字の読み取り精度だけを見ても、受注現場で残る作業までは分かりません。注文書には複数の明細行があり、取引先の商品名を社内の商品コードへ置き換え、数量単位を確認し、既存システムへ登録する工程が続きます。読み取った文字をどこまで受注データにできるかが選定の分かれ目です。
この記事では、実名製品の順位付けではなく、自社の注文書で確認したい七つの選定軸を整理します。デモ用の整った帳票だけで判断せず、低画質のFAX、手書き追記、マスタにない商品、複数ページなど、日常的に担当者が扱う例外を含めて比較するための観点です。
FAX受注の整理に使える資料
AI受注さんの仕組みと提供内容をまとめたサービス資料をご覧いただけます。
サービス資料をダウンロード注文書OCRは読み取り後の作業まで含めて選ぶ
OCRは画像内の文字をデータへ変える仕組みです。しかし受注業務では、文字列を得るだけでなく、得意先・注文日・商品・数量・単位・納品日などの項目へ分ける必要があります。さらに、商品マスタとの対応・担当者による確認・ExcelやCSVへの出力まで続きます。
自社帳票で試す範囲を決める
評価用の注文書は、件数の多い取引先だけでなく、書式が異なる取引先も含めます。通常の印字帳票、FAX転送で画質が落ちた帳票、手書きの追記がある帳票、訂正版、複数ページを用意します。直近一週間だけでなく、繁忙期や締め日前後の帳票も確認すると例外を拾いやすくなります。
比較時には、読み取れた文字数ではなく、受注登録に使える状態までに担当者が何を直したかが記録の対象です。商品コードを検索した。明細の行ずれを直した。数量単位を選び直した。出力ファイルの加工。そういった作業です。七つの軸は、この残作業を同じ条件で見るために使います。
選定軸1・2：明細行の読み取りと商品コード補完
1．複数の明細行を保ったまま読み取れるか
注文書では、商品名・規格・数量・単位・単価・備考が横方向に並び、商品ごとに行が増えます。確認したいのは、文字を個別に読めるかだけではありません。どの商品と数量が同じ行に属するかを保てるかです。罫線が薄い帳票や、途中に空行がある帳票でも明細の対応を確認します。
一枚あたりの明細数が多い場合は、先頭行だけでなく中段と最終行も見ます。ページをまたぐ注文では、得意先情報や注文番号を次ページの明細へ引き継げるか、ページ単位で別注文にならないかを確認します。行の追加や削除を確認画面で行えるかも、運用に影響する項目です。
2．取引先の商品名を社内コードへ補完できるか
帳票に社内の商品コードが書かれていない場合、読み取った商品名を商品マスタへ対応させる工程が必要です。表記ゆれ、略称、容量や荷姿の違いをどの情報で絞るかを確認します。候補が複数あるときに自動で決めず、担当者へ候補を示せる設計も確認対象です。
マスタ連携では、初回の登録方法だけでなく、新商品・終売・コード変更をどう反映するかも聞きます。担当者が確認画面で修正した内容を次回の候補へ反映できるか、取引先別の呼び方を管理できるかを見ると、運用後の検索作業を想像しやすくなります。
選定軸3・4：低画質FAXと手書きへの対応
3．低画質のFAXで必要項目を読めるか
FAX画像は、元の注文書より解像感が落ち、細い罫線や小さな文字がかすれることがあります。送信時の傾き・黒い帯・縮小・ページ端の欠けも起こります。画像補正の有無だけでなく、日常的に届く画質で、得意先名・商品・数量・納品日がどの程度確認対象になるかを見ます。
既存のFAX番号を残す場合は、複合機やFAXサービスからメール転送した実際の添付ファイルを使うのが基本です。スキャンし直した鮮明な画像では受信条件が変わります。受信からOCRへ渡すまでのファイル形式、複数ページの分割、向きの補正も含めて一連の流れで試します。
4．手書き文字と印字が混在しても確認できるか
手書き対応では、整った数字だけでなく、印字欄への上書き・余白の追記・丸囲み・訂正線を含む帳票を使います。読めない文字を空欄や低信頼の項目として示せるか、元画像の該当箇所へ戻れるかを確認します。手書きの原因と運用設計は別の記事で詳しく扱います。
選定軸5：確認画面を実際の担当者が運用できるか
OCRの結果には、人が判断する項目が残ります。確認画面では、元の注文書と抽出値を同時に見られるか、該当箇所を拡大できるか、キーボードで項目間を移動できるかを確認します。一件ずつ開き直す手順や、修正後に別画面へ転記する手順があると処理時間へ影響します。
5．確認画面で元帳票と処理状態を扱えるか
複数の担当者が使う場合は、未確認・確認中・承認済み・出力済みなどの状態を共有できるかを見ます。同じ注文を二人が処理しない仕組み・締め時間が近い注文を見つける並び順・訂正版と再送を確認する方法も必要です。担当者別の作業量を見る機能より、注文の滞留場所を把握できることを優先します。
試用時は受注担当者自身に操作してもらい、注文一件あたりのクリック数や修正項目を記録します。管理者だけがデモを見ると、日々繰り返す小さな手間を見落としやすくなります。入力ミスの確認設計と重なる論点は関連記事にまとめているため、選定時には画面上の残作業が評価の対象です。
選定軸6：既存システムへの連携方法
6．確認済みデータを使える形式で渡せるか
注文書をデータ化しても、既存の受注管理へ登録できなければ転記が残ります。まずは現在使っているExcelの列、または基幹システムが読み込めるCSVの仕様を確認します。得意先コード・商品コード・数量・単位・納品日・備考の順序や形式を、出力側で合わせられるかを見ます。
CSV連携では、文字コード・日付形式・先頭ゼロ・空欄・改行を含む備考なども試す項目です。ファイルを出した後に担当者が列を並べ替えたり、数式で値を補ったりする場合、その作業を連携機能やマスタで吸収できるかを確認します。API連携がなくても、既存の取り込み機能を使える場合があります。
受信から連携までの全体像を確認したい場合は、FAX受注自動化の記事を参照してください。OCR選定では機能名の多さではなく、自社の登録先へ届くまでに残る操作を比較します。エラー時に元帳票と出力データをたどれることも、運用担当者の調査時間に関わります。
選定軸7：料金体系を自社の件数に当てはめる
7．従量課金と定額に含まれる範囲をそろえる
料金は、一枚あたり・一項目あたり・月間処理枠・利用者数など、数え方が異なります。OCRだけの費用か、確認画面・帳票設定・マスタ補完・データ出力・保守まで含むかをそろえて比較します。基本料金が低くても、明細行や再処理が別計算なら月額の見え方が変わります。
自社の月間枚数に加え、一枚あたりの明細行数・繁忙月の増加・再送や訂正・保存期間・利用人数も整理が必要です。通常月だけでなく最も件数が多い月を当てはめ、上限を超えた場合の単価や翌月への繰り越しも確認します。従量課金と定額の考え方は、費用の記事で月間件数別に説明します。
最終比較では、七つの軸ごとに、対応の有無だけでなく担当者の残作業を書きます。自社の過去帳票を同じ組み合わせで試し、確認項目数・修正理由・出力後の加工を記録すると、読み取り精度の一つの数字だけに偏らず選べます。運用開始後に帳票やマスタを更新する方法も確認します。
7つの基準を質問と実帳票で判定する
製品説明で「対応しています」と聞くだけでは、注文書OCRの実力はつかめません。自社の帳票を見せ、どこまで自動で進み、どの状態で人に戻るかを質問します。七つの基準ごとに、商談や試用でそのまま使える聞き方へ直すと次のようになります。
| 選定基準 | 実際に聞く質問 | 回答がこうなら要注意 |
|---|---|---|
| 明細行 | 空行、欄外追記、二ページ目がある注文を通した場合、品名と数量の組み合わせはどこで崩れますか | 先頭行の読取率だけを示し、行ずれやページ継続の結果を見せられない |
| 商品コード補完 | 取引先の略称から候補が二つ出たとき、誰が決め、次回へどう反映されますか | 最初から一件に自動確定する、または毎回ゼロから検索する |
| 低画質FAX | 複合機から転送した原寸のFAXで、傾きや縮小を含めて試せますか | 鮮明なスキャン画像だけで評価し、受信後の補正条件を説明できない |
| 手書き | 訂正線、丸囲み、欄外の数量は、値と注意表示のどちらで返りますか | 判別できない値まで確定値として出し、元画像へ戻る導線がない |
| 確認画面 | 受注担当が一件処理する操作を最初から最後まで見せてください | 修正後の転記や画面の開き直しをデモから外している |
| システム連携 | 当社のCSV仕様で先頭ゼロ、空欄、複数明細、取込エラーを再現できますか | 標準CSVを出せるという回答だけで、基幹の受付結果まで扱わない |
| 料金 | 明細行、再送、確認画面、マスタ更新、API利用のうち、別料金になるものはどれですか | 月額の数字だけを示し、課金単位と運用後の作業範囲を分けない |
PoCは最低30件を三つの組に分ける
試用では、件数上位の取引先から通常帳票を10件、書式が違う取引先を10件、訂正・手書き・低画質・複数ページなどの例外を10件用意します。最低30件です。同じ注文を各候補へ通し、項目単位の正誤に加えて、商品コードを確定できた割合、一件の確認時間、基幹へ入るまでの修正回数、保留になった理由を測ります。平均だけで済ませず、通常と例外を分けて集計すると、きれいな帳票の多さで結果が良く見えるのを防げます。
合否は読取率だけで決めません。数量と単位の誤りを人へ戻せること、元帳票から基幹の受付結果まで追えること、締め時間内に30件を処理できることを先に置きます。正しく止まった注文は失敗ではありません。黙って誤登録される方が問題です。
導入後に増える作業も月間工数へ入れる
選定時には毎月のマスタ更新件数を聞き取ります。確認へ回る注文数と、例外一件の調査時間も必要です。月間運用工数は「マスタ更新件数×一件の更新時間＋確認件数×一件の確認時間＋例外件数×一件の調査時間」で置けます。新商品や終売が多い会社では、初期設定の軽さより更新手順が効きます。誰が別名を承認するか、締め直前の保留を誰へ渡すかまで決まれば、導入後の人員配置も見積もれます。