FAX注文書の入力は、AI-OCRで品番や数量を読み取り、自社の商品情報と照合してから、販売管理へ渡す流れで自動化できます。
取引先にFAXをやめてもらう前に、受信後の転記を減らす方法があります。
ただし「3箱」を正しく読めても、登録先が個数で管理していれば、そのまま「3」と入力することはできません。
本記事では、架空の商品と注文データ7件を使い、単位の換算や再送・訂正の判定を実際に動かしました。
OCRの読取精度は試しておらず、読み取った後の処理を検証した記事です。
入力データと処理結果を公開します。
この記事で分かること
- 注文書に書かれた値と、販売管理へ登録する値を両方残します
- 「送信した」ではなく、登録先の受付番号と登録内容を確認して完了にします
- 既製品で読み取り・照合・取込まで満たせるかを先に試し、残った業務だけ追加開発を検討します
FAX注文書の入力は
どう自動化する?
「文字を読む」「商品と数量を確かめる」「販売管理に登録する」の三つをつなぎます。
AI-OCRは、紙や画像の文字を読み取り、品番・数量・希望納期などの項目に分ける部分を担います。
| 工程 | 自動化する作業 | 人が確認する場面 |
| 注文書を受け取る | FAXのPDFやメール添付を集め、注文内容を読み取る | 文字がつぶれている、ページが足りない |
| 受注データを作る | 商品コードを照合し、数量と単位を登録先に合わせる | 商品が一つに決まらない、単位や納品先が不明 |
| 販売管理に渡す | 承認済みのデータを取り込み、登録結果を確認する | 訂正注文、取込エラー、登録結果が分からない |
FAXを複合機で受けているなら、受信内容をPDFで保存できるかが最初の確認点です。
紙をスキャンして試すこともできますが、毎回印刷とスキャンを挟む運用では、その作業が残ります。
受信方法を変える場合は、現在のFAX番号と転送方法への影響も確認します。
すでに取引先からCSVなどのデータを受け取れる場合は、直接取り込む方法を検討できます。
Web受発注で商品を選択してもらえる取引と、FAXが残る取引を分けても構いません。
既存業務のどこから着手するかは、中小企業のAI導入の進め方でも解説しています。
読み取り結果を受注データにするために、商品・数量の確認を挟みます。
商品コードと数量を、
登録先に合わせる
注文書に書かれた値と、販売管理へ登録する値を両方残します。
担当者が確認する際に、AIが読み間違えたのか、商品や単位の変換が違うのかを切り分けられるためです。
商品名が似ていても、
規格まで照合する
商品マスタは、自社の商品コード・名称・規格・入数などを管理する一覧です。
注文書に取引先独自の品番が書かれる場合は、取引先と品番を組み合わせて自社コードに対応させます。
同じ略称でも、取引先が変われば別の商品を指す可能性があります。
例えば「商品A」に500mLと1Lの規格があれば、名称だけでは一つに決まりません。
似た名前の商品を自動選択せず、規格や過去の対応付けを確認できる状態にします。
注文頻度だけでは、今回の商品を確定できません。
「3箱」と「3個」は
別の数量になる
今回の架空データでは、商品Aの500mLを1箱12個、登録単位を「個」と設定しました。
注文書の「3箱」は36個へ換算します。
数量の数字だけを転記すると、必要な数量と登録数量がずれます。
入数は商品ごとのマスタで管理し、注文書の数量・単位、使った換算率、換算後の数量を記録します。
入数が未登録、単位が空欄、小数が許されない商品で端数が出る場合は、推測で埋めず確認へ回します。
包装が変わる商品では、換算ルールの適用日も管理対象です。
架空の計算例です。入数は商品ごとに登録された値を使います。
7つの注文パターンで
処理を試した
再送や訂正を含む注文を流し、受注データを追加してよい条件を確かめました。
弊社が2026年9月10日に、この記事用の架空データを使ってローカルで実行した結果です。
OCRやFAX画像の読み取りは実行せず、人が用意した読み取り後に相当するCSVを照合しました。
特定のAI製品の性能を試した結果ではありません。
商品は500mLと1Lの2種類に絞り、「取引先・注文番号・明細行」が同じなら同じ注文を指すルールを、試験用に設定しました。
| 入力した条件 | 実際の処理結果 | 導入時に見る点 |
| 01 新規の注文。商品コード00042、3個 | 3個の下書き候補を作成 | コードの先頭の0を保ったまま取り込めるか |
| 02 別の新規注文。同じ商品を3箱 | 1箱12個を参照し、36個の下書き候補を作成 | 注文単位と登録単位を正しく換算できるか |
| 03 「商品A」とだけ記載。規格が不明 | 商品候補が2件あり、要確認として保留 | 似た商品を勝手に確定しないか |
| 04 商品コードと数量3はあるが、単位が空欄 | 個数か箱数か決められず保留 | 必須項目の欠落を見つけられるか |
| 05 01と同じ注文番号・同じ内容が別ファイルで到着 | 再送候補として保留。下書きを追加しない | ファイル名が違っても重複を検出できるか |
| 06 01と同じ注文番号で、数量だけ5個に変更 | 訂正候補として保留。元の3個を上書きしない | 再送と数量訂正を区別できるか |
| 07 コード00042が、先頭の0を失って42になった | 該当コードなしで保留。0を自動補完しない | 取込時の文字列・数値の扱いを確認できるか |
比較のために、あえて照合を省き、全行を追加する説明用の処理も動かしました。
その処理では7件とも追加対象となり、「3箱」の数量欄も3のままでした。
照合を加えた処理では、新規の下書き候補は2件となり、残り5件を理由付きで保留できました。
保留件数は、読み取りの精度を示す数値ではありません。
7件の入力条件と処理結果をCSVでダウンロードできます。
仕組みを確認したい担当者向けに、架空データ・マスタ・再現用プログラムの一式も用意しました。
いずれも説明用で、実際の受注システムには接続しません。
CSVは、Excelなどの取込機能で「入力コード」列を文字列に指定して開いてください。
直接開くと先頭の0が消える場合があります。
同じ注文番号でも
「再送」とは限らない
05と06の違いは、前に受け取った内容から数量が変わっていることです。
単に「同じ注文番号は捨てる」と決めると訂正を見落とし、反対に全部追加すると二重の注文候補を作ります。
元の注文と変更後の内容を並べ、担当者が訂正か追加注文かを決められるようにします。
注文番号が毎月繰り返される、訂正時に行番号が変わる、番号自体がない取引では、今回の識別ルールをそのまま使えません。
取引先との運用に合わせて注文を識別し、確定できないものは照会へ回します。
すでに出荷済みなら、データを直す前に出荷先や在庫への影響も確認が必要です。
今回の試験では、本番登録・複数注文の同時処理・複数明細をまたぐ訂正・在庫確認・納期回答は行っていません。
また、誤読したコードが別の実在商品と一致する場合は、マスタ照合だけでは誤りを見抜けません。
導入時には実際の帳票の読取試験と、承認・登録先との連携試験を別途行います。
受信した事実は残し、注文として追加・更新するかを確認します。
販売管理への
登録で確認すること
「送信した」ではなく、登録先の受付番号と登録内容を確認して完了にします。
処理が途中で止まったときに、入力済みなのか未処理なのかを追えることが、二重登録を避けるために必要です。
CSV・API・画面入力の
どれが使えるか
まず、現在の販売管理にCSV取込やAPIがあるかを確認します。
APIは、別のシステムからデータを登録・照会するための接続口です。
CSVで足りるなら、登録先の列名・並び順・文字コード・日付形式に合わせて出力する方法から始められます。
取込画面では、コードの先頭の0、必須列、明細と伝票の区切りを確かめます。
一部の行だけ失敗したときに、ファイル全体を取り消すのか、成功分は登録されるのかも重要です。
再取込で成功済みの行まで追加されないかを、テスト環境で確認してください。
取込機能がなく画面操作を自動化する場合は、RPAなどを使う選択があります。
その際は入力位置だけでなく、画面の変更、処理待ち、エラー表示を検出する仕組みまで必要になります。
使っている製品の連携仕様を確認してから、方法を決めます。
登録結果が分からない
ときは、再送前に確認する
通信が途切れても、販売管理側では登録が終わっている場合があります。
応答がない処理には「結果不明」と記録し、注文番号や受付番号で照会してから再実行する流れにします。
今回のローカル試験で行った再送判定だけでは、こうした本番の二重登録まで防げません。
同じ注文を複数の処理が同時に受け取る場合も、登録先を含めた重複防止が必要です。
受信原本、読取結果、担当者の修正、登録先の番号を対応付けて残します。
締切前の確認待ちは代理担当へ回せるようにし、障害時に手入力へ戻した分も、自動処理と重複しない形で記録します。
既製品と追加開発をどう選ぶ?
既製品で読み取り・照合・取込まで満たせるかを先に試し、残った業務だけ追加開発を検討します。
帳票の種類、取引先別の呼び方、販売管理への接続条件を一式で確かめると、必要な範囲を絞れます。
例えば、WisOCR for 注文書は、注文書のデータ化に加え、マスタ検索による補完やCSV整形・連携を案内しています。
CO-NECT AIデータ変換の公式ページには、商品マスタとの照合、単位換算、CSV出力やAPI連携の説明があります。
機能があることと、貴社の注文ルールに合うことは、導入前の試験で確かめます。
| 現在の状況 | 最初に試す方法 | 判断のポイント |
| 取引先から整ったCSVを受け取れる | 既存の取込機能で連携する | コード対応と列形式を合わせれば済むか |
| FAXが多く、商品情報も整理されている | 受注向けAI-OCRの標準機能を試す | 自社帳票の読み取りから登録まで通るか |
| 読取はできるが、照合や訂正の手作業が残る | 既存OCRに確認・連携処理を追加する | 担当者の判断をルール化できるか、確認画面が必要か |
ベンダーの読取精度だけで、確認作業がなくなるとは判断できません。
Microsoftの文書抽出の信頼度の説明でも、抽出結果の推定値と、人による確認を含む運用が扱われています。
文字を正しく読めるかと、その商品・単位で受注してよいかは別に確かめます。
費用を見積もる際は、月の注文件数に加えて、ページ数、明細行数、帳票の種類、確認が必要な割合を整理します。
読み取り料金だけでなく、初期設定、マスタ整備、連携、保守に何が含まれるかを比較してください。
利用料金の単位は製品によって異なるため、候補先の見積条件で揃えます。
導入前後は、転記に使う時間に加え、読み取りの修正、確認待ちの処理、マスタ更新、エラー対応の時間も計測します。
単に「自動処理した枚数」が増えても、担当者の負担が減ったとは限りません。
開発を依頼する場合の費用の考え方は、AI開発の費用と依頼範囲も参考になります。
まず一つの注文書式で試す
よく届く注文書式を一つ選び、通常の注文と、単位不明・再送・訂正の注文をセットで試します。
商品情報と登録先の取込仕様を揃え、担当者が完成形を確認できる下書きまで作るのが最初の到達点です。
初回の相談では、注文の受け取り方、入力しているシステム、転記後に担当者が判断することを整理すれば進められます。
実際の帳票や取引先情報を共有する際は、利用目的と保存・削除の条件を確認し、必要な範囲に絞ります。
項目名だけの見本や、今回のような架空データから説明する方法もあります。
「読み取れるか」に加えて、「迷った注文を誰が確認し、どこへ登録すれば完了か」まで決めておくと、試作から運用へ進めやすくなります。
確認待ちや手入力への切替も含めて試し、任せられる注文から対象を広げてください。