FAX受注は、AI-OCRを入れるだけでは最後まで自動化できません。AI-OCRが作るのは注文票の文字を項目に分けた候補です。その後に、得意先、商品、単位、数量、納期をマスタと照合し、曖昧な注文を人へ戻し、基幹システムへ登録して結果を確かめる処理が要ります。
午後3時の出荷締切前、FAXに「A-12 10」とだけ書かれている場面を考えます。A-12が自社品番なのか取引先の旧品番なのか、10は個数か10ケースか。文字を正しく読めても、意味を取り違えれば誤出荷になります。自動化の成否は読取精度だけでなく、この注文を止められるかで決まります。
FAX受注は、AI-OCRだけで自動化できるか？
できません。読取後のマスタ照合、例外確認、基幹登録と結果確認までを一つに設計します。
AI-OCRは、取引先名、品番、数量、希望納期などを画像から取り出す入口です。注文として成立させるには、文字列を自社のコードと業務ルールへ置き換えなければなりません。
| 段階 | 入力 | 確認すること | 次へ進めない条件 |
|---|---|---|---|
| 受信 | FAX画像 | ページ数、送信元、重複 | 欠落、同じ注文の再送疑い |
| 読取 | AI-OCRの候補 | 欄と値、読取状態 | 必須欄が空、複数候補 |
| 照合 | 得意先・商品マスタ | 品番、単位、取引条件 | 該当なし、複数一致、廃番 |
| 確認 | 注文候補 | 数量、納期、在庫、価格 | 上限超過、納期回答が必要 |
| 登録 | 確定データ | 基幹の受付番号、登録結果 | 通信失敗、応答不明 |
| 事後処理 | 登録結果 | 原本、修正、担当者 | 原本と登録値を追えない |
中小企業庁の中小企業の受発注デジタル化は、FAXや電話が残る取引を示しつつ、電子受発注と他システムのデータ連携を分けずに扱っています。画像をデータにしたところで止めず、そのデータが受注処理へつながるかを見る必要があります。
AI-OCRの後は、何をマスタと照合するのか？
得意先、商品、単位、価格、納入先を照合し、取引先独自の呼び方を自社コードへ変換します。
最初に照合するのは送信元です。同じ「中央店」でも複数の得意先があり得るため、FAX番号だけで確定せず、注文票の会社名、納入先、担当者など複数の情報を使います。
商品は、自社品番だけでなく、取引先が使う品番、旧品番、商品名の略称、荷姿を対応表に持ちます。「洗剤A 10」という記載で商品が一つに決まっても、10本と10ケースでは在庫も金額も変わります。数量と単位は別の項目として扱います。
GS1 Japanによると、GTINは取引される商品単位を重複なく識別するための標準コードで、受発注や検品にも使われます。GTINが付く商品では照合キーの一つになりますが、すべての取引品にあるとは限りません。自社品番や得意先別コードとの対応は別に整備します。
どんな注文を人の確認へ戻すべきか？
複数候補、単位不明、廃番、高額、納期回答が必要な注文は自動登録せず確認待ちへ戻します。
「OCRの確信度が低いとき」だけでは足りません。文字が明瞭でも、マスタに同名商品が二つある、得意先別の梱包単位が未登録、旧品番が複数の商品へ引き継がれた、といった業務上の曖昧さが残ります。
確認画面では、FAX原本と読取値、マスタ候補、警告理由を横に並べます。担当者が修正した値と理由も残します。修正が頻発する取引先や品番は、個人の経験で直し続けず、対応表または注文票を見直します。
AISIのデータ品質マネジメントガイドブック Version 1.02は、誤ったデータが処理全体の信頼性を損なうこと、品質を継続して確保する必要を示しています。AI-OCRの導入時だけ試験し、商品改廃や得意先変更後に見直さない運用では品質を保てません。
基幹システムへは、どう登録して結果を確かめるのか？
APIや取込機能で登録し、受付番号と登録値を読み戻して原本まで同じ処理IDで追えるようにします。
基幹システムにAPIがあれば、登録前の検証と登録後の応答を使います。CSV取込しかない場合は、出力ファイル、取込日時、エラー行、再取込の扱いを決めます。画面への自動入力は最後の候補です。画面変更や通信遅延で、登録されたか分からない状態が起きやすいためです。
タイムアウトした処理をそのまま再実行すると、同じ注文が二重登録されることがあります。FAXの受信ID、原本、注文候補、基幹の受付番号を一つの処理IDで結び、登録結果が不明なら再送前に照会します。
中小企業庁の受発注のデジタル化に関する推進方策では、FAXやスマートフォンの画像をデータ化する入口だけでなく、EDI形式への変換や基幹システムで受信できる形式への変換までを扱っています。入口を残しても、後続データの形式と接続は別に決める必要があります。
FAXを残すか、EDIへ移すかはどう判断するのか？
取引量、相手の対応、変更頻度を比べ、FAX後工程の整備と電子受発注への移行を併せて判断します。
少数の取引先だけがFAXを使い、帳票も安定しているなら、FAX受信後の処理を整えるほうが移行しやすい場合があります。一方、毎日多くの注文があり、商品改廃や納入先変更が多いなら、画像を読み続けるより、取引先と構造化データを交換するほうが自然です。
| 選択 | 向く条件 | 残る課題 |
|---|---|---|
| FAX＋AI-OCR | 相手がFAX継続、帳票が比較的安定 | 読取、照合、原本保管、例外確認 |
| Web注文 | 相手が画面入力でき、品目を選択式にできる | アカウント管理、入力支援 |
| EDI | 継続取引が多く、システム間連携が必要 | コード対応、接続仕様、相手との合意 |
| メール・CSV | 定型ファイルを交換できる | 版管理、添付間違い、取込エラー |
FAXを今すぐ廃止できないことと、ずっと画像を入口にすることは同じではありません。まず確認待ちが多い取引先を把握し、注文票の統一、Web注文、EDIの順で移行案を話します。
社内では、自動化前に何を決めておくべきか？
自動登録できる条件、確認担当、締切、マスタ更新者、障害時の代替手順を先に決めておきます。
次の七つを一枚に書き出します。
- 対象にする取引先と注文票
- 必須項目と、自動登録できる一致条件
- 人へ戻す例外と確認担当者
- 出荷締切に間に合わない注文の扱い
- 商品・得意先対応表を更新する責任者
- 二重登録を防ぐための注文識別方法
- AI-OCRや基幹が止まったときの手入力手順
確認担当者が休みの日も決めます。確認待ちを放置せず、代理担当へ回すのか、その取引先だけ手入力へ戻すのか。締切直前に権限を広げて自動登録する運用は避けます。
開発会社へは、どの資料を渡せばよいか？
実際の注文票、マスタ、例外、締切、基幹の取込仕様を匿名化して一組で渡してください。
きれいな注文票だけでなく、薄いFAX、手書き修正、複数ページ、再送、旧品番を含むものを用意します。得意先マスタと商品マスタは、列名だけの見本ではなく、匿名化した実データを数十件分見せると照合方法を検討できます。
基幹システムについては、製品名に加え、API、CSV取込、画面入力のどれが使えるか、テスト環境があるかを伝えます。SaaS・パッケージ・スクラッチ開発の選び方と要件書がない段階の相談方法も併せて確認してください。
一次情報は、どの資料を確認したか？
受発注連携、商品識別、データ品質を扱う公的機関と標準化団体の一次資料を確認しました。
- 中小企業庁「中小企業の受発注デジタル化」
- 中小企業庁「受発注のデジタル化に関する推進方策」
- GS1 Japan「GTIN（商品識別コード）」
- AISI「データ品質マネジメントガイドブック Version 1.02」
関連記事と相談先は、どこから確認できるか？
要件整理と開発方式の記事を往復し、実帳票を準備してからAI開発ページまたは問い合わせへ進めます。
Heygoodは、AI-OCRの製品選定だけで終わらせません。実際のFAXとマスタを見て、自動登録できる注文、人へ戻す注文、取引先と入口を変える注文を分けます。まず一社分の帳票で、受信から基幹の登録結果確認までを通すところから相談できます。