FAX やメールで届く注文書を AI で受注登録したいとき、最初に考えるべきなのは「どの AI が一番よく読めるか」ではありません。手間が本当に残っているのは、読み取った後の工程です。品名を自社の商品マスタに結びつける名寄せ、在庫の引当、同じ注文を二重に登録しない仕組み、そして人が確認して確定する画面。ここが業務に合っていないと、読み取りがどれだけ正確でも担当者の作業は減りません。この記事では、卸売・運送業者で FAX・メール受注から在庫引当・配車までを一画面にまとめた frectas の案件をもとに、AI-OCR・受注 SaaS・受託開発の選び方と、読み取りの後の設計の勘所をまとめます。
この記事の数字は、frectas の案件の記録（検証の記録・顧客への報告）によるものです。
結論：選び方は「読み取りの後」で決まる
先に答えを書きます。
- 読み取ったものを決まった形式で基幹システムに入れれば終わるなら、AI-OCR か受注 SaaS で足ります
- 取引先ごとの読み方のルールが多く、在庫の引当・配車・既存システムへの書き戻しまで一続きで扱いたいなら、業務に合わせて作る受託開発が向いています
- どちらの場合も、人が確認して確定する画面と、同じ注文を二重に登録しない仕組みは欠かせません
製造業の受注業務では FAX で注文を受け取っている会社が多いという調査があり、食品卸でも受注業務に毎日まとまった時間をかけている会社が少なくないと報告されています（末尾の「参考にした情報」を参照）。FAX がすぐになくならない前提で、読み取りの後までを含めて設計するのが現実的です。
FAX受注の業務を分解する
FAX 受注の作業は、次の7つの工程に分けられます。AI-OCR が受け持つのは主に 2 です。
- 注文書を受け取る（FAX 複合機、FAX を転送したメール、メール添付の PDF）
- 注文書を読み取る（取引先・納品先・品名・数量・納期）
- 取引先と納品先を、自社の取引先マスタに結びつける
- 品名を、自社の商品マスタに結びつける（名寄せ）
- 在庫から引き当てる（ロット・賞味期限・倉庫）
- 配送・引取の担当を決める
- 基幹・倉庫・運送のシステムに登録する
慣れた担当者は、2 から 7 を頭の中で一度にこなしています。「この店舗の注文は納品先コードが別」「この取引先の数量は重さで書いてある」「この品はあのロットから出す」といった判断です。自動化で手間が減るかどうかは、この判断をどこまで仕組みに移せるかで決まります。
AI-OCR・受注SaaS・受託開発の比較
| 観点 | 汎用の AI-OCR | 受注に特化した SaaS | 受託開発 |
|---|---|---|---|
| 主に受け持つ工程 | 2（読み取り） | 2〜4（読み取り・照合・CSV 出力） | 1〜7 を業務に合わせて |
| 向いている会社 | 様式が少なく、読み取り後の処理が単純 | 標準的な受注の流れで、CSV 取り込みで基幹に入る | 取引先ごとのルールが多い、引当・配車まで一続きにしたい |
| 自社のマスタとの照合 | 別途の仕組みが要る | 製品の機能の範囲で | 自社のマスタと運用に合わせて作る |
| 在庫の引当・配車 | 対象外 | 多くは対象外 | 作り込める |
| 既存システムへの書き戻し | CSV などを人が取り込む | CSV 出力が中心 | API・CSV・画面入力の代行など、相手に合わせて選ぶ |
| 始めるまでの期間 | 短い | 短い | 業務の範囲によります |
| 確かめること | 自社の注文書での読み取り精度 | 照合の柔軟さ、出力の形式 | 費用対効果、運用を引き継げるか |
SaaS で足りる会社に受託開発は要りません。逆に、SaaS を入れたものの「読み取りは速くなったが、照合と引当の手作業は変わらない」という状態なら、残っている工程を作り足すことを考えます。
読み取りの「後」が本番な理由
ここからは、卸売・運送業者の案件で実際に設計したことを工程ごとに書きます。この案件では、注文書の受け取り → 生成 AI での読み取りと構造化 → 商品・取引先の名寄せ → 受注の保存 → 在庫の自動引当 → 配車・引取担当の提案 → 既存の倉庫・運送システムへの書き戻し、を一つの業務画面にまとめました。詳しくは事例「卸売・運送業者の受注業務を、注文書の読み取りから配車の提案まで一つの仕組みに」に書いています。
1. 名寄せ：会社名だけでは納品先が決まらない
同じ取引先でも、店舗ごとに納品先コードが違いました。親会社の名前だけで納品先を確定すると、誤った店舗に届けてしまいます。そこで、候補が一つに絞れるときだけ自動で決め、複数の候補があるときは担当者に選ばせるようにしました。
名寄せは「自動で決める」か「人に聞く」かの線引きの設計です。全部を自動にしようとすると、誤りが静かに混ざります。全部を人に聞くと、AI を入れた意味が薄れます。この線をどこに引くかは、現場の担当者と実物の注文書を見ながら決めました。
2. 読み方のルール：様式ごとの約束事を拾う
注文書には、書かれていない約束事があります。この案件で出てきたものの例です。
- 月間の定期注文書は、1枚に1か月分が載っている。しかし出荷するのはその日の分だけ
- 品によって重さで数えるものと箱で数えるものがあり、数量の欄が2つある。どちらを引当の基準にするかは品によって違う
月間の定期注文書の読み方は、打ち合わせの場で実物を見ながら訂正が入りました。業務の読み違いは、説明を聞くだけでは見つかりません。実物の注文書で確かめるのが一番早い方法です。数量の扱いは、引当の基準にする数量を決めたうえで、もう一方の数量も捨てずに画面に表示する形にしています。
3. 在庫引当：最後は人が確定する
在庫にはロットや賞味期限があり、どの在庫から出すかの判断には現場の事情が入ります。仕組みは引当の候補を出し、担当者が確認して確定する形にしました。配車・引取の担当についても、AI は「この人が良さそう」という助言だけを返し、決めるのは人です。
4. 取りこぼしと二重登録を防ぐ
FAX 受注の自動化で見落とされやすいのが、受け取りの段階の設計です。この案件では次のようにしました。
- 受け取りと読み取りを分ける。 受け取りの段階では AI を呼ばず、原本を先に保存する。読み取りに失敗しても、注文書そのものは失われない
- 添付ファイルごとに処理の状態を持つ。 メールの再送や処理の二重実行があっても、受注を二重に作らない
- 受注にならなかった添付を一覧に残す。 注文書でない添付や読み取れなかった添付は、人が画面で判断するまで未対応の一覧に残る
「AI が読めなかった注文は、誰にも気づかれずに消える」という状態がいちばん危険です。読み取りの精度よりも先に、取りこぼしが起きない流れを作ります。
5. 人の確認：自動送信はすぐには有効にしない
確定したら倉庫・運送システムへ自動で送る機能も作れますが、運用のルールが決まるまで有効にしませんでした。確定した後に、担当者が明示的に送る操作を残しています。止める・戻す手順が決まる前に自動で外へ送ると、誤りを取り消すのが難しくなるためです。
6. 既存システムへの書き戻し：思わぬ落とし穴
既存の倉庫システムとの連携では、二つの失敗がありました。
- AI が長い ID を勝手に短くした。 AI に渡した長いキーを、モデルが短縮して返し、12件すべてが照合できなくなったことがあります。以後、「受け取った値はそのまま持ち、AI にはキーを書き換えさせない」を設計の原則にしました
- CSV で動いたものが API で動かなかった。 同じデータでも、CSV では出力時に整形されていた値が、API では整形前の形で届きました。「CSV で試して動いたから大丈夫」とは言えません
数字で見る案件の規模感
| 項目 | 数字 | 区分 |
|---|---|---|
| 配車担当の提案の一致率 | 71.1% → 72.9%（曜日ごとの傾向を学習に加えて +1.8ポイント） | PoC 実測（過去の実績を正解に見立てた評価） |
| 本番データベースの費用 | 月約43,400円 → 月約14,200円 | 見込み（請求額から逆算した概算） |
配車の一致率は、過去の実績データを使い、学習に使った期間より後の日付だけを順に予測して採点した値です。ただし、これは「過去にその担当が割り当てられていたか」との一致で、本番の正解率ではありません。記録にもそう明記しています。
注文書の読み取り精度と業務時間の削減は、まだ数字として出せる段階ではありません。案件の記録でも「実際のメール・FAX での精度の検証は完了したと扱わない」としており、実際の注文書9枚で人の入力と比べる準備を進めています。
精度をどう測るか
FAX 受注の AI 化で精度を測るときは、次の点に気をつけます。
- 自社の実際の注文書で測る。 取引先の様式ごとに難しさが違うので、サンプルの注文書では分かりません
- 項目ごとに測る。 取引先・納品先・品名・数量・納期のうち、どれを間違えたかで手直しの重さが違います
- 「人が直した項目の数」も見る。 この案件の顧客からは「修正する項目が多いと AI 導入の意味が薄れる」という要望を受けました。数量0の行を除外するなど、手直しを減らす改善を続けています
- 評価に使ったデータの範囲と、数字の意味を書き残す。 「一致率」と「正解率」は違います。報告の段階で混ざると、後で判断を誤ります
PoC の合格ラインの決め方は「AI 開発を PoC で止めないための合格ラインの決め方」で詳しく書いています。
導入の進め方
frectas で FAX 受注の AI 化を進めるときの手順です。
- 業務の聞き取り: 受注から登録までの工程と、担当者が頭の中でしている判断を書き出す
- 実物の注文書を集める: 取引先ごとの様式と、例外的な注文書（定期注文書、手書きの追記など）を集める
- 既存システムの入口を確かめる: CSV 取り込み・API・画面入力のどれで書き戻すかを決める
- PoC: 実際の注文書で読み取りと名寄せを試し、人の入力と突き合わせる
- 確認画面を作る: 人が直して確定する画面を先に作り、AI が間違えても業務が止まらないようにする
- 検証環境で通してから本番へ: 検証環境と顧客が使う環境を分け、検証環境で一通り動かしてから本番を立てる
- 使いながら直す: 定例で要望を確認し、手直しの多い項目から改善する
自社に合う方法を見極めるチェックリスト
次の質問に「はい」が多いほど、読み取りの後まで含めた受託開発が向いています。
- 取引先ごとに注文書の様式が違い、10社以上ある
- 同じ取引先でも、店舗や部署によって納品先や扱いが違う
- 品名の書き方が取引先ごとに違い、自社の商品コードとの対応表を人が覚えている
- 在庫のロット・賞味期限・倉庫を考えて引き当てている
- 配送・引取の担当決めも、受注と同じ担当者がしている
- 既存の倉庫・運送システムがあり、そこへの入力も手作業で行っている
逆に、様式が数種類で、読み取った内容を CSV で基幹に取り込めば終わるなら、まず SaaS を試すことをおすすめします。
サービスの内容は「FAX・メール受注の AI 化」にまとめています。
参考にした情報
確認日はいずれも 2026-10-17 です。
- MONOist「製造業の受注業務、7割が FAX での受領あり」: https://monoist.itmedia.co.jp/mn/articles/2409/10/news066.html
- インフォマート「食品卸の受注業務に関する調査」（2023年12月）: https://www.infomart.co.jp/asp/other/document/pdf/researchreport_seller_202312.pdf
自社の注文書で、AI がどこまで読めて、読み取りの後のどの工程に手間が残るのかを確かめたい方は、お問い合わせからご相談ください。取引先の様式の数、1日の注文書の枚数、お使いの基幹・倉庫システムを教えていただければ、SaaS で足りるか、作り込みが要るかを含めてお答えします。
