◆監修・編集責任者
B2B EC-COLUMN
この記事のポイント
- 公開されている精度の値は、製品・帳票・画像・設定者による条件つきの値で、自社のFAXが読めるかは実際の受信画像で試して確かめる
- 導入事例は、読み取り・商品コードへのひも付け・システム連携のどれが変わったかを分けて読み、記載のない効果を自社の効果と見なさない
- 導入後の確認は照合の作業に変わり、誤りの影響が大きい項目を中心に、どこまで見るかを受け手が決める
- 受注システムが取り込める形式と、商品コードへの対応づけまで通るかで、残る転記が決まる
- 試行結果をもとに導入・限定導入・見送りを選び、EDIへ移れる取引先は分けて考える
目次

FAX-OCRの導入事例では、どの帳票のどの作業が変わったのか
取引先から毎日届くFAXの注文書を、画面と見比べながら一件ずつ受注システムへ打ち込み、別の人が見直している。
入力ミスや処理の遅れが出ていても、FAX-OCRを入れれば本当に楽になるのか、確信が持てない場面は少なくありません。
公開されている精度の値は、各社の基準帳票や自治体の手書き帳票など、それぞれ別の条件で測った結果です。
自社のFAXにそのまま当てはまるものではありません。
送り手を変えられない受信側にできることは三段階あります。
まず導入事例で、どの帳票のどの作業が変わったかを読み分けます。
次に、自社に実際に届いたFAXで試します。
最後に、確認作業の残り方と受注システムへの渡し方まで見て、導入・対象を絞った導入・見送りを決めます。
EDI化後に残るFAX発注書という事例の位置づけ
FAX-OCRは、FAXで受け取った帳票の画像から文字を読み取り、入力できるデータに変える仕組みです。
OCR(光学文字認識)のうち、AIで文字や項目を読み分けるものはAI-OCRと呼ばれます。
公開されている導入事例のひとつに、ミツカングループの物流・受注部門を担うMizkan Logitecがあります。
同社は大阪と名古屋の受注センターで、全国からの注文を処理しています。
受発注の大部分は、すでにEDI(企業間で受発注データを電子的にやり取りする仕組み)に移っていました5。
それでも、残る約15%にあたる月間約1万2000枚のFAX発注書は、手入力とダブルチェックが必要な状態だったと報じられています5。
同社は2026年に、invoxの発注書AI-OCRを導入しました5。
受信側の担当者にとってこの事例が参考になるのは、EDIを進めた会社でもFAXがなくなっていない点です。
残った分は、手作業の負担として積み上がっていました。
EDIへ移れるかどうかは、送り手である取引先の事情にも左右されます。
そのため、受け手だけで全面移行を決めることはできません。
残るFAXを受け手の工程でどう処理するかという問題は、規模の大小にかかわらず同じ形で現れます。
一方で、自社とそのまま重ねられない部分もあります。
この事例は1社の物流・受注部門のもので、対象は発注書です。
請求書や納品書を受け取って経理側で処理する場合や、月に数百枚を少人数で入力している場合は、帳票の中身も、OCRで減らしたい作業も違ってきます。
事例を読むときは、企業名や枚数の大きさより先に、二つの点を見ます。
自社と同じ種類の帳票かどうかと、同じ工程の負担を減らそうとしているかどうかです。
この二つを見ると、参考にできる範囲が分かります。
事例から読み取れる変化と、読み取れない効果
報道から読み取れる変化は、次の三つです5。
- FAXやメール(PDF)で届いた発注書を、AIでデータ化する
- 読み取った商品名から候補を自動で認識し、自社の商品コードへ自動でひも付ける
- データを既存の受発注システムへ自動で連携する
同社は、これにより入力作業が大幅に減ったとしています5。
ただし、入力時間や件数がどれだけ減ったかを示す数値は記事にありません。
導入前に必要だったダブルチェックが導入後にどうなったかも書かれていません5。
「大幅に減った」は導入企業の受け止めとして読むのが妥当です。
自社で同じ効果が出る根拠にはしないほうが安全です。
事例を自社に当てはめるには、FAX1枚を入力するときの作業を分けて考えると見通しが立ちます。
担当者は、FAXの文字を読み、品名から自社の商品コードを探し、受注システムに打ち込みます。
そのあと、別の人が原本と画面を照合します。
Mizkan Logitecの事例で変わったと書かれているのは、このうち「読む」「コードを探す」「打ち込む」にあたる部分です。
「照合する」がどうなったかは分かりません。
どの作業に時間がかかっているかは、会社ごとに違います。
品名が取引先独自の書き方で、コード探しに手間取っているとします。
その場合は、商品コードへのひも付けがあるかどうかが効果を左右します。
読みづらい手書きの判読に時間を取られている場合は、読み取り精度のほうが先に問題になります。
そのため、導入を検討し始めた段階で、今の入力作業を工程ごとに数日分記録しておくと、あとで試行結果と比べられます。
記録しておきたいのは次の三つです。
1枚あたりの入力時間、コード探しに迷った件数、照合で見つかった誤りの件数です。
これがそろっていれば、OCRで減ったのがどの工程なのかを自社の数字で説明できるようになります。
| 作業 | 導入前 | 事例で報じられた導入後 |
|---|---|---|
| 文字を読む | 担当者がFAXを見て読む | AIがデータ化する |
| 商品コードを探す | 担当者が品名から探す | 商品名候補を自動認識し自社コードへ自動ひも付け |
| システムへ入力 | 手入力 | 既存の受発注システムへ自動連携 |
| 照合(ダブルチェック) | 必要とされていた | 記載なし |
▼ 図の内容を文字で読む
- 変化が報じられた作業
- 文字を読む
- 商品コードを探す
- システムへ打ち込む
- 記載のない部分
- 照合(ダブルチェック)がどうなったか
- 入力時間や件数がどれだけ減ったか
- 自社で先に記録しておく数値
- 1枚あたりの入力時間
- コード探しに迷った件数
- 照合で見つかった誤りの件数
自社のFAXでも読めるか:精度の数値が成り立つ条件
公開されている精度の値は何の条件の値か
事例の次に気になるのは、自社に届くFAXがきちんと読めるかどうかです。
製品の紹介や実証の報告には、精度の値が載っています。
ただ、その値がどんな帳票で、誰が設定して測ったものかを見ないと、自社に当てはまるかは判断できません。
PFUの2025年のコラムは、FAX注文書を題材に、従来型のOCRとAI-OCR(DynaEye 11)の認識率を比べています。
結果は、AI-OCRのほうが高いというものでした1。
ただしこれは、PFUが用意した基準帳票を使った結果です。
実際の取引先から届いた注文書での値ではありません1。
また、このコラムは、手書きの注文書や、取引先ごとにレイアウトが違う非定型の帳票には触れていません1。
NTTデータは2019年に、自治体での実証の結果を公表しました。
町田市や横浜市など6自治体の実帳票73種から集めた手書きのサンプルで、AI-OCRの正読率は約93%でした3。
この検証では、帳票定義(どの欄に何が書かれるかをOCRに教える設定)に慣れていない作業者が設定することを前提にしています。
熟練した人が設定すれば、正読率が上がる可能性があるとされています3。
対象は自治体の手書き帳票で、FAXで受信した画像ではありません3。
この二つの値は、製品も帳票も時期も、読み取りの条件も違います。
並べて、どちらが優れているかを言うことはできません。
読み取れるのは、精度が「条件つきの値」だということです。
帳票の作り、画像の質、手書きかどうか、設定する人の慣れによって値は変わります。
さらに、率が同じでも、外れた文字がどの欄に出るかで、受け手の手間と危険は大きく変わります。
数量や納期の欄で外れるのと、備考欄で外れるのとでは、意味がまったく違います。
公開値は、自社のFAXで試すときに何を条件として揃えるかを考える材料として使うのが確かです。
FAXの画質と受信画像の扱い
FAXは、送り手の原稿をいったん粗い白黒の画像にして送ります。
そのため、受け取った時点で文字がつぶれていたり、かすれていたりすることがあります。
受け手は送り手の原稿や送信機を選べません。
しかし、受け取った画像の扱い方は自社で決められます。
PFUのコラムは、FAX注文書の読み取り精度を上げる要点として、次の三つを挙げています1。
- FAXの画像を学習したAI-OCRを選ぶ
- FAXの紙をスキャンせず、複合機の受信画像を使う
- 傾きや拡大縮小を補正する機能があるかを確かめる
日常の運用でつまずきやすいのは、二つ目です。
複合機でFAXを紙に印刷し、それを回覧したあとでスキャナーにかけ直すとします。
すると、印刷とスキャンのたびに画像の質が変わり、紙の傾きも加わります。
受信画像をそのままフォルダーやメールに保存できる設定があれば、FAX-OCRにはその画像を渡します。
そうすれば、受け取ったときの状態に近いまま読み取りにかけられます。
受信画像の保存方法は、複合機の機種や設定で違います。
試行の前に、今の複合機で受信データを画像やPDFとして取り出せるかを確かめておくと、検証の段取りが組みやすくなります。
傾きや拡大縮小は、送り手の側で起きます。
原稿を斜めに差し込んだり、用紙サイズが合わずに縮小されたりするためです。
どの欄に何が書かれているかを位置で捉えるOCRでは、画像がずれると欄の位置もずれます。
そのため、製品が自動で補正するかどうかで読み取り結果が変わります。
自社に届くFAXのなかに、毎回斜めに届く取引先や、縮小されて届く取引先はないでしょうか。
あれば、その画像を試行のサンプルに入れておくと、補正の効き方が分かります。
手書き・罫線と文字の重なり
手書きの注文書が混じる場合は、NTTデータの実証で示された誤読の原因が参考になります。
判読が難しい字や、罫線・枠線と文字が重なっている部分は、誤読しやすいとされています3。
様式を見直すことで、精度の向上が期待できるとも述べられています3。
枠からはみ出した数字や、罫線の上に書かれた品番は、人でも読み間違えやすい箇所です。
OCRでも同じところが弱点になります。
受け手は、取引先の書き方を変えられません。
ただ、取引先が自社用の注文書様式を使ってくれている場合は、事情が違います。
次に様式を改める機会に、記入欄を広げるといった見直しを検討する余地があります。
取引先が自前の様式を使っている場合は、様式に手を出せません。
手書きの比率が高い取引先ほど、試行の結果を見て対象に含めるかを決めることになります。
製品の対応範囲も一様ではありません。
PFUは2025年にDynaEye 11 Entry AI-OCRを発売しました。
この製品は、レイアウトがある程度決まった準定型帳票に対応します。
主に流通業向けの用途として、伝票・注文書・納品書のほか、ドットプリンター印字やFAXの帳票を挙げています2。
手書きにどこまで対応するかは、製品ごとに確かめる必要があります。
手書きの注文書が多い受け手ほど、製品の説明よりも、自社の手書きサンプルでの結果を判断の中心に置くことになります。
▼ 図の内容を文字で読む
- 受け手が決められる要因
- 複合機の受信画像を使うか、紙を再スキャンするか
- 帳票定義を作る人の慣れ
- 送り手側で生じる要因
- 傾きや拡大縮小による欄のずれ
- 判読が難しい手書き文字
- 罫線・枠線と文字の重なり
- 読み取り結果に出ること
- 誤読が出る欄と件数
- 人が直す手間
導入後も人の確認が残る工程と、誤読の減らし方
事例で分かる範囲と、記載のない範囲
読み取りの精度が分かっても、受け手が本当に知りたいのは、導入後に誰がどこを見続けるかです。
Mizkan Logitecの事例では、入力作業が大幅に減ったとされています。
理由は、商品名候補の自動認識と、商品コードへの自動ひも付けです。
しかし、導入前に行っていたダブルチェックが残ったのか、なくなったのかは書かれていません5。
PFUのコラムも、認識結果を人がどの程度目で確かめる必要があるかは明記していません1。
公開情報からは、確認がなくなるとも、そのまま残るとも決められません。
そのうえで押さえておきたいのは、導入後の確認が、導入前と同じ作業ではなくなる点です。
導入前の確認は、手で打ち込んだ内容を原本と照合する作業でした。
導入後は、OCRが出した結果を画像と見比べ、読み違いを直す作業に変わります。
打ち込む手間が減っても、見る手間が同じだけ残れば、担当者の負担は思ったほど軽くなりません。
確認の負担を左右するのは、線の引き方です。
全項目を毎回見るのか、誤りの影響が大きい項目だけを見るのか。
この線は製品が決めるものではありません。
受け手が、自社の取引と誤りの影響から決めるものです。
ミスの影響が大きい帳票での二重入力の考え方
NTTデータの実証では、参加した自治体から意見が出ています。
入力ミスが許されない業務では、AI-OCRと二重入力を併用することも検討できる、というものです3。
OCRを入れたら人の確認をやめる、という二択だけではありません。
業務の性質に応じて、確認を重ねる選択肢もあります。
注文書であれば、項目ごとに誤りの影響を分けて考えられます。
- 数量・単価・金額:誤ると出荷量や請求額が変わる
- 商品コード・品番:誤ると別の商品が出荷される
- 納期・届け先:誤ると届く日や場所が変わる
- 備考・担当者名:誤っても出荷や請求そのものは変わらない場合がある
たとえば、数量と商品コードは全件を画像と見比べ、備考欄は気になるものだけを見る、という分け方ができたとします。
その場合、全項目を照合していた頃より、見る量は減ります。
逆に、取引先の多くが手書きで数量を書いてくる場合は、数量欄の照合がそのまま残ります。
効果は、打鍵が減る分に限られます。
どちらになるかは、試行で項目ごとの誤りを記録して初めて見えてきます。
誤読を減らす手立ては、読み取った後の確認だけではありません。
NTTデータの実証が示すように、帳票定義を作る人の慣れで正読率が変わる可能性があります3。
誤読が出た欄を記録し、取引先ごとの帳票定義を見直すことも手立てになります。
同じ取引先の同じ欄で誤読が繰り返されるなら、読み取る範囲の指定や受信画像の扱いを変えることで、改善する見込みがあります。
誤読は、「誰が直したか」ではなく「どの取引先の、どの欄で、なぜ外れたか」で記録しておきます。
そうすると、確認の範囲を狭めてよいかを、後で判断する材料にもなります。

読み取ったデータを基幹システムへ渡すために要ること
商品コードへの対応づけ
確認の線引きまで決まっても、読み取った文字がそのまま受注データになるわけではありません。
FAXの注文書には、取引先が使っている品名や品番が書かれている場合があります。
受注システムに登録するには、それを自社の商品コードへ置き換える必要があります。
Mizkan Logitecの事例で入力が減った理由として挙げられているのも、文字の読み取りだけではありません。
商品名候補の自動認識と、自社商品コードへの自動ひも付けでした5。
全国の取引先から発注を受ける受注センターでは、同じ商品でも取引先ごとに書き方が違いえます。
文字を正しく読めても、どのコードにあたるかを人が調べる作業が残れば、入力の手間は大きく減りません。
自社で検討するときは、品名から商品コードへの対応づけを誰が担うのかを確かめます。
製品が自動で行えるのか、受け手が対応表を用意して登録するのか、それとも読み取り後に人が選ぶのか。
この三つを分けて確かめると、導入後にどの作業が残るかが見えます。
対応表を用意する場合は、導入前に作業が発生します。
取引先ごとの品名と自社コードの組み合わせを洗い出す作業です。
取引先や取扱商品が多い会社ほど、この準備に時間がかかる点も見込んでおく必要があります。
出力形式の変換と受け側の取り込み形式
次は、OCRが作ったデータを、受注システムや販売管理システムへどう渡すかです。
Mizkan Logitecは、データ化した発注書を既存の受発注システムへ自動で連携しています5。
一方で、製品側の説明だけでは、連携の仕組みまでは分からないことがあります。
PFUのDynaEye 11 Entry AI-OCRには、出力データ変換の機能があります。
読み取った値の置換や、出力ファイル名の設定などを行う機能です。
ただし、接続できるシステム名やAPI(システム同士をつなぐ窓口)は、発売時の発表には示されていません2。
ここで判断が分かれるのは、受け側のシステムがどんな形でデータを受け取れるかです。
CSVファイルの取り込み機能があれば、OCRの出力を合わせるだけで済みます。
合わせるのは、列の並びや日付の書き方、コードの桁数です。
取り込み機能がなく、画面からの手入力しか受け付けない場合は話が変わります。
OCRで読み取っても、その結果を見ながら結局打ち込むことになります。
減るのは、原本を読む手間だけです。
受注システムを外部の会社が保守しているなら、確かめることがあります。
取り込みに使える形式と、取り込み時のエラーの扱いです。
たとえば、OCR側で数量を数値として出力しても、受け側が全角数字を受け付けないことがあります。
日付の区切り文字が違うといった小さな食い違いで、取り込みが止まることもあります。
試行の段階で、出力されたCSVを受注システムの検証環境へ一度取り込んでみるとよいでしょう。
読み取りの精度とは別の詰まりどころを、導入前に見つけられます。
▼ 図の内容を文字で読む
- 読み取り
- 注文書の文字をデータにする
- 商品コードへの対応づけ
- 製品が自動でひも付ける
- 受け手が対応表を用意して登録する
- 読み取り後に人が選ぶ
- 出力形式の変換
- 列の並び・日付の書き方・コードの桁数を受け側に合わせる
- 受注システムへの取り込み
- 取り込み機能があればCSVで渡せる
- 手入力しか受け付けなければ打ち込みが残る
どの帳票から試し、導入・限定導入・見送りをどう決めるか
無償検証・無料トライアルの条件と準備
ここまでの判断材料は、どれも自社のFAXで試さないと答えが出ないものでした。
読み取れるか、確認がどこに残るか、受注システムへ渡せるか。
これらを導入前に小さく確かめる方法として、製品によっては無償の検証や無料トライアルが用意されています。
例として、PFUのDynaEye 11には、法人向けの無償事前検証サービスがあります4。
読み取りたい項目は、帳票1種類あたり最大20項目まで指定できます4。
検証できる帳票の種類やサンプルの枚数にも、上限があります4。
対象はレイアウトが一定の定型帳票で、画像の傾きや拡大縮小が一定の範囲内であることが条件です。
個人情報を含む帳票は出せず、結果はPDFとCSVで返ってきます4。
また、Entry AI-OCRには、処理枚数に上限のある無料トライアルもあります2。
これらの条件は、FAXを受け取る側にとって、準備の中身を決めます。
最大20項目という上限があるため、注文書のすべての欄ではなく、受注入力に必要な欄を選んで指定することになります。
傾きや拡大縮小の条件もあるため、斜めに届きがちな取引先のFAXは、検証の対象外になったり、結果が悪く出たりすることがあります。
個人宅への届け先や個人名が載る注文書は、そのままでは出せません。
FAXの受信画像をそのまま検証に出せるかどうかも、公開情報からは分かりません。
申し込む前に提供元へ尋ねておけば、用意したサンプルが無駄になりません。
結果がCSVで返ってくる点には、受け手にとって使い道があります。
サンプルにした注文書は、すでに担当者が手で受注システムへ入力しているはずです。
その入力済みデータと検証結果を項目ごとに突き合わせれば、どの欄で何件外れたかを、自社の基準で数えられます。
同じCSVを受注システムの取り込み形式と見比べれば、前の節で触れた形式の食い違いも、同時に確かめられます。
試す帳票の選び方
試せる帳票の種類が限られる以上、どの取引先のFAXを選ぶかで、試行の価値が変わります。
勧めたいのは、次の条件がそろう取引先から選ぶことです。
- 毎月届く枚数が多い:効果が出たときの手間の減り方が大きく、導入の根拠にしやすい
- 書式が一つに決まっている:帳票定義の手間が少なく、定型帳票向けの検証条件にも合いやすい
- 誤りが出荷や請求に響く:確認の線引きを、試行の段階で決めておく意味が大きい
一方で、よく読める帳票だけで試すと、導入後に期待を外す原因になります。
手書きや画質の悪いFAXで、思ったように読めないということが起こりえます。
試行の枠に余裕があれば、手書きが混じる注文書や、かすれて届きやすい取引先の画像も少しだけ入れておきます。
そうすれば、読み取れる範囲の端がどこにあるかが分かります。
結果が悪くても、その取引先を対象から外す判断材料になります。
試行としては無駄になりません。
試行で記録しておきたいのは、次の四つです。
項目ごとの誤読の件数、誤読を直すのにかかった時間、商品コードへの対応づけが自動でできた割合、受注システムへの取り込みでエラーになった件数です。
導入前に記録しておいた1枚あたりの入力時間と並べると、減ったのが入力なのか、照合なのか、コード探しなのかを分けて見られます。
費用の見方
試行で効果の見込みが立ったら、費用と比べることになります。
料金の公開例として、PFUのDynaEye 11 Entry AI-OCRがあります。
ライセンスの金額は初年度と2年目以降で分かれ、2年目以降は年ごとの支払いです。
いずれも税抜・サポート込みで、処理枚数の制限はないとしています2。
これは2025年に発売された1製品の条件で、FAX-OCR全体の相場を示すものではありません。
この例から読み取れるのは、費用の比べ方の観点です。
処理枚数に制限がない料金体系なら、FAXの枚数が増えても費用は変わりません。
枚数の多い会社ほど、1枚あたりの負担は軽くなります。
反対に、枚数に応じて課金される製品なら、月ごとの枚数の変動が費用に直結します。
初年度と2年目以降で金額が違う場合は、1年目だけでなく、数年続けた合計で比べます。
そうしないと、継続した場合の負担を見誤ります。
ライセンス以外に、受け手の側で発生する作業もあります。
取引先ごとの帳票定義の作成、商品名と自社コードの対応表の整備、受注システムへの取り込み設定です。
これらが製品の料金に含まれるとは限りません。
見積もりを取るときは、提供元が引き受けるのか、自社で行うのかを分けて確かめておきます。
そうすれば、導入後に想定外の作業が残りにくくなります。
見送り・代替の条件
試行と見積もりがそろうと、選べる道は大きく三つに分かれます。
一つ目は、全面的な導入です。
対象にしたい取引先の多くで誤読が少なく、商品コードへの対応づけと受注システムへの取り込みも試行で通ったなら、検討できます。
二つ目は、限定導入です。
書式の決まった大口の取引先ではよく読めたものの、手書きの多い取引先では誤読が目立った、という結果なら、読める取引先だけを対象にするのが現実的です。
手書きの取引先は、従来どおり手で入力します。
OCRの対象を後から広げるかは、運用しながら決められます。
Mizkan Logitecの例でも、受発注の大部分はEDIで受け、残ったFAXにOCRを使っています5。
一つの手段ですべてのFAXを処理しなくてよいと考えると、選択肢が広がります。
三つ目は、見送りです。
書式が取引先ごとにばらばらで手書きが中心、試行でも誤読が多く、確認の手間が今の照合と変わらない。
そうした場合は、見送るのも合理的な判断です。
また、取引先がEDIへ移行できる見込みがあるなら、その取引先のFAXはOCRで読むよりEDIで受け取るほうが、読み取りも読み取り結果の確認も要りません。
ただし、EDIへの移行には取引先の協力が要り、受け手だけでは決められません。
主要な取引先にEDIの意向を尋ね、そのうえで残るFAXの枚数からOCRの規模を考える、という順番もあります。
どの結論を選んでも、試行で集めた項目ごとの誤読と修正時間の記録は無駄になりません。
見送った場合も、どの取引先のどの欄が読めなかったかが分かっています。
製品が変わったときや、取引先の様式が変わったときに、もう一度試す価値があるかをすぐに判断できます。
▼ 図の内容を文字で読む
- 導入
- 対象にしたい取引先の多くで誤読が少ない
- 商品コードへの対応づけが試行で通る
- 受注システムへの取り込みが通る
- 限定導入
- 書式の決まった大口の取引先では読める
- 手書きの多い取引先は従来どおり手で入力する
- 対象は運用しながら広げるか決める
- 見送り
- 書式がばらばらで手書きが中心
- 試行でも誤読が多く、確認の手間が今の照合と変わらない
- EDIへ移れる取引先は、先にEDIの意向を尋ねる
公開事例や精度の値だけでは、自社の取引先ごとのFAXでどの工程が減り、どこに照合が残るかまでは判断しにくいため。
現在の入力工程と、受け取っているFAXの書式・枚数を整理し、試行に出す取引先と記録する項目を一緒に決められます。無料相談で要件を整理する
要点の整理
| 軸 | 基準 |
|---|---|
| 事例の読み方 | 同じ種類の帳票か。読む・コード探し・入力・照合のどれが変わったか |
| 精度の公開値 | 製品・帳票・画像・設定者による条件つきの値。値どうしの比較や自社の予測には使わない |
| FAX画像 | 紙を再スキャンせず受信画像を使う。傾き・拡大縮小の補正を確かめる |
| 確認作業 | 項目ごとの誤りの影響で照合範囲を決める |
| 連携 | 商品コードへの対応づけと、受注システムの取り込み形式 |
| 判断 | 試行結果で導入・限定導入・見送りを選ぶ。EDIへ移れる取引先は分けて考える |

試行結果を、確認の線引き・受注システムへの取り込み・費用の比べ方まで含めて導入判断にまとめるには、社内だけでは見落としが出やすいため。 試行で集めた項目ごとの誤読と修正時間の記録をもとに、導入・限定導入・見送りのどれが合うかを確かめられます。
よくある質問
FAXをスキャンし直してOCRにかけてもよいか。
避けたほうが無難です。
PFUのコラムは、FAXの紙をスキャンせず、複合機の受信画像を使うことを精度向上の要点に挙げています1。
印刷と再スキャンを挟むと、画質や傾きが変わるためです。
紙で回覧する運用を残す場合も、OCRには受信時の画像を別に保存して渡せるかを、複合機の設定で確かめるとよいでしょう。
手書きの注文書が混在していてもFAX-OCRは使えるか。
使える可能性はありますが、手書き分の読み取りは自社のサンプルで確かめる必要があります。
NTTデータの自治体での実証では、手書きサンプルで正読率が約93%でした3。
ただし、これはFAXではなく、帳票定義に未習熟な作業者を想定した条件での値です3。
判読しにくい字や罫線と重なる字は誤読しやすいため3、手書きの多い取引先は対象から外して限定導入する選択肢もあります。
取引先ごとに書式が違う場合、何種類まで登録できるか。
登録できる書式の数は製品や契約で異なり、この記事で確かめた資料には上限が示されていません。
見積もりの際に確認しましょう。
あわせて、取引先ごとの帳票定義や商品コードの対応表を誰が作り、維持するかも確かめておくと、導入後の負担を見通せます。
なお、無償の事前検証では、試せる帳票の種類に上限がある例があります4。
無償検証や無料トライアルで見るべき指標は何か。
見るべきは次の四つです。
項目ごとの誤読件数、誤読を直す時間、商品コードへの自動対応づけができた割合、受注システムへの取り込みエラーの件数です。
正読率の一つの数字だけでは、誤りが数量欄に出たのか備考欄に出たのかが分かりません。
すでに手入力した受注データと項目ごとに突き合わせると、判断に使える数字になります。
OCRで読み取ったあと、ダブルチェックは不要になるか。
不要になるとは言えません。
導入事例でも、ダブルチェックの扱いが書かれていない例があります5。
自治体の実証では、ミスが許されない業務で二重入力との併用を検討できるとの意見が出ています3。
数量や商品コードなど、誤りの影響が大きい項目は照合を続け、影響の小さい項目は確認を絞る、というように項目ごとに線を引くのが現実的です。
取引先がEDIに移行できる場合でもFAX-OCRは必要か。
EDIに移る取引先の分には、FAX-OCRは要りません。
ただ、すべての取引先が移るとは限りません。
Mizkan Logitecのように、受発注の大部分をEDI化したうえで、残るFAXにAI-OCRを導入した例もあります5。
移行の見込みを取引先に確かめ、残るFAXの枚数からOCRの規模を考えるとよいでしょう。
- 1 出典:株式会社ピーエフユー「FAX注文書はOCRできる?精度を向上させる3つのポイント」(2025年)
- 2 出典:株式会社ピーエフユー「DynaEye 11 Entry AI-OCR 発売ニュースリリース」(2025年)
- 3 出典:株式会社NTTデータ「町田市、郡山市、市川市、つくば市、横浜市、福岡市におけるAI-OCR実用性の検証結果について」(2019年)
- 4 出典:株式会社ピーエフユー「DynaEye 11 無償事前検証サービス」(2025年)
- 5 出典:LNEWS「Mizkan Logitec/AI-OCR導入、持続可能な物流体制構築へDXを加速」(2026年)
画像の出典元
- Close-up of hands organizing tax forms on a desk with a calculator, laptop, and notebook./Photo by Mikhail Nilov on Pexels