FAX やメールで届く注文書を AI で読み取り、受注入力を自動化する。PoC で数枚の注文書を読ませると、思ったよりきれいに読めることが多いはずです。ところが毎日の業務で回し始めると、別の問題が出てきます。読み取りに失敗した注文書が誰にも気づかれずに消える。取引先がメールを再送して、同じ注文が二つできる。AI が返した商品コードが基幹システムのものと一致しない。どれも、AI の読み取り精度とは別の問題です。
frectas は、卸売・運送の会社で、FAX・メールの注文書の受け取りから在庫引当・配車の提案・既存の倉庫システムへの書き戻しまでを一つの業務画面にまとめました。この記事では、そのうち「注文書から基幹システムへ、データを落とさず・重ねずに運ぶ」ための設計を書きます。読み取りの後の名寄せや在庫引当を含めた全体の選び方は「FAX受注をAIで自動化する方法」にまとめています。
この記事の数字は、frectas の案件の記録（開発・検証の記録）によるものです。
PoCで読めても、本番で困ること
PoC と本番の違いは、注文書が「人が選んで渡すもの」から「勝手に届くもの」に変わることです。本番では次のことが起きます。
| 起きること | 何が困るか |
|---|---|
| AI の呼び出しが失敗する・時間切れになる | 原本を保存する前に失敗すると、注文書が消える |
| 取引先が同じメールを再送する | 受注が二重にできる |
| 仕組みの中で同じ処理が二度動く | 同上。キューは一度の依頼を二回以上届けることがある |
| 注文書でない添付（案内文・ロゴ画像）が混ざる | 黙って捨てると、本当の注文書の取りこぼしに気づけない |
| AI が ID や数字を少し変えて返す | 基幹システムで照合できない。気づかないと誤った受注になる |
どれも、読み取りの精度を上げても解決しません。仕組みの側の設計で防ぎます。
全体の流れ：AI を呼ぶのは一か所だけ
この案件の流れを、AI を使う所と使わない所に分けて書くと次のようになります。
| 段階 | やること | AI |
|---|---|---|
| 受け取り | メールを受け、原本と添付を保存し、添付ごとに処理の記録を作る | 使わない |
| 読み取り | 添付の注文書を構造化する（取引先・納品先・品名・数量・納期） | 使う |
| 名寄せ | 読み取った名前を、自社の取引先・商品のマスタに結びつける | 使わない（候補が複数なら人に聞く） |
| 受注の保存 | 受注の下書きを作り、担当者が確認・確定する | 使わない |
| 書き戻し | 既存の倉庫・運送システムへ送る | 使わない |
AI に任せるのは「紙の文字を構造にする」ところだけです。それ以外は、同じ入力からいつも同じ結果が出る処理にしています。AI の出力が揺れても、揺れが他の段階に広がらないようにするためです。
受け取りと読み取りを分ける
いちばん大事なのは、受け取りの段階では AI を呼ばず、原本を先に保存する ことです。
メールを受けたその場で AI に読ませる作りにすると、AI の呼び出しが失敗したとき、注文書がどこにも残りません。メールの受信を担うサービスは、受け取った側がすぐに応答しないと再送や破棄をすることがあり、AI の応答を待つ処理を置くには向いていません。
この案件では、受け取りの処理は「原本を保存して記録を作る」だけにし、読み取りは別の処理としてキュー（Cloud Tasks）に積みました。こうしておくと、次のことができます。
- AI が失敗しても、原本から何度でも読み直せる
- AI のモデルや指示文を変えたとき、過去の注文書で読み直して比べられる
- 担当者が確認画面で、読み取り結果と原本を並べて見られる
添付ファイルごとに処理の状態を持つ
処理の状態は、メール単位ではなく 添付ファイル単位 で持ちます。1通のメールに注文書が2枚付いていることも、注文書と案内文が一緒に付いていることもあるからです。
状態は、たとえば次のように分けます（考え方を示すための例で、案件の実際の名前とは違います）。
| 状態 | 意味 |
|---|---|
| 受け取り済み | 原本を保存した。まだ読んでいない |
| 読み取り中 | AI に渡した |
| 読み取り失敗 | AI がエラーを返した、または結果の形が正しくない。読み直しの対象 |
| 受注作成済み | この添付から受注の下書きを作った |
| 対象外 | 注文書ではないと担当者が判断した |
この状態があると、二重登録を防げます。読み取りの処理は、始める前に「この添付はもう受注を作ったか」を確かめ、作っていれば何もせずに終わります。メールの再送でも、キューが同じ依頼を二度届けても、受注は一つのままです。
一般的なやり方として、状態の確認と更新はデータベースの中で一度に行い、「受注作成済み」への切り替えと受注の作成を同じトランザクションに入れます。確認と作成の間に別の処理が割り込むと、二つの処理が同時に「まだ作っていない」と判断してしまうためです。添付ファイルの中身のハッシュ値を記録しておけば、別のメールで同じファイルが届いたことにも気づけます。ただし、取引先が意図して同じ注文を出し直すこともあるので、黙って捨てずに担当者に知らせる形が安全です。
AI にキーを書き換えさせない
開発中に、AI に渡した長い ID を、モデルが短くして返してきたことがありました。照合に使うキーが変わってしまい、既存の倉庫システムとの照合がすべて失敗しました。
AI は、文字列を「意味が同じなら少し変えてもよいもの」として扱うことがあります。人の目には同じに見える短縮や、桁区切りの追加、全角・半角の置き換えも起こり得ます。そこで、以後は 受け取った値はそのまま持ち、キーを加工しない を設計の原則にしました。
具体的には、次のようにします。
- ID やコードを AI に往復させない。AI に渡す前に仕組みの側で保持し、AI の出力とは別に持っておく
- AI に候補から選ばせたいときは、長い ID ではなく「1」「2」「3」のような短い番号を付けて渡し、返ってきた番号を仕組みの側で元の ID に戻す（一般的なやり方です）
- AI が読み取った値（注文書に書かれていた品名やコード）は、加工せずにそのまま保存する。整形や変換は、記録を残せる別の処理で行う
CSV と API で、同じデータの形が違う
既存の倉庫システムとの連携でも、似た落とし穴がありました。最初は CSV で受け取ったデータで処理を作り、動くことを確かめていました。ところが API で同じデータを受け取ると、表現が違っていました。CSV は出力するときに整形されていて、API のほうが整形前の生の値に近かったのです。
一般に、CSV の出力ではコードの先頭のゼロ、日付の書き方、数値の桁区切り、空欄の扱いなどが、出力の設定によって変わります。「CSV で試して動いたから、API でも動く」とは言えません。連携の方式を変えるときは、同じ日のデータを両方の方式で取り、項目ごとに比べてから切り替えます。
受注にならなかった添付を「未対応」に残す
AI が「注文書ではない」と判断した添付や、読み取りに失敗した添付を、仕組みが黙って捨ててはいけません。注文書なのに案内文と誤って判断された添付は、そこで消えてしまいます。
この案件では、受注にならなかった添付は、担当者が画面で判断するまで未対応の一覧に残しています。「対象外」にするのは人です。未対応の一覧が空になっていれば、その日に届いた添付はすべて誰かが見た、と言える状態にしています。
人に聞く所を決める
注文書には、様式に書かれていない読み方のルールがあります。この案件では、次の二つが代表的でした。
同じ会社でも、店舗ごとに納品先コードが違う。 注文書に親会社の名前しか書かれていないとき、名前だけで納品先を決めると、別の店舗に届けてしまいます。候補が一つに絞れるときだけ自動で決め、複数の候補があるときは担当者に選ばせるようにしました。
月間の定期注文書は、1枚に1か月分が載っているが、出荷するのはその日の分だけ。 この読み方は、打ち合わせで実物の注文書を見ながら訂正が入ったものです。説明を聞くだけでは、こうした読み違いは見つかりません。
人に聞く所を増やしすぎると、AI を入れた意味が薄れます。顧客からも「修正する項目が多いと導入の意味が薄れるので、人による修正を極力減らしたい」という要望を受けています。数量が0の行を受注から除くなど、手直しを減らす改善を続けています。自動で決めるか人に聞くかの線は、実物の注文書を見ながら一つずつ引いていきます。
AI の呼び出しを1回ずつ記録する
AI の使用量は、呼び出し1回ごとに、モデル名・トークン数・所要時間・成否を記録しています。月の請求額だけを見ていると、次のことが分かりません。
- どの取引先の注文書で、失敗や時間切れが多いか
- モデルや指示文を変えたとき、費用と所要時間がどう変わったか
- 費用が増えたとき、注文書が増えたのか、読み直しが増えたのか
原本を保存してあるので、記録と原本を組み合わせれば、失敗した注文書を後から同じ条件で読み直して原因を調べられます。
読み取り精度は、まだ検証中です
正直に書くと、この案件では、注文書の読み取り精度はまだ数字として出せる段階ではありません。案件の記録でも、実際のメール・FAX での精度の検証は完了したと扱わないと明記しており、実際の注文書と人の入力を比べる準備を進めているところです。
精度を測るときは、次の点を押さえます。
- 自社に実際に届いた注文書で測る。サンプルの様式では、取引先ごとの癖が出ません
- 項目ごと（取引先・納品先・品名・数量・納期）に、人の入力と比べる
- 「人が直した項目の数」も数える。顧客にとっての手間はこちらに出ます
精度を測る前でも、この記事で書いた設計があれば、読み間違いは確認画面で直せ、読めなかった注文書は未対応の一覧に残ります。精度を上げる工夫より先に、間違えても業務が止まらない流れを作ります。PoC の合格ラインの決め方は「AI 開発を PoC で止めないための合格ラインの決め方」で書いています。
本番の前に確かめること
- 受け取りの処理は、AI を呼ばずに原本を保存しているか
- 処理の状態を、添付ファイル単位で持っているか
- 同じ依頼が二度届いても、受注が一つのままか（実際に二度流して確かめる）
- AI に ID やコードを往復させていないか
- 連携の方式（CSV・API）を変えたとき、項目ごとに比べたか
- 受注にならなかった添付が、人が判断するまで残るか
- AI の呼び出しを1回ずつ記録しているか
- 検証環境で一通り動かしてから、本番を立てているか
案件の全体像は事例「卸売・運送業者の受注業務を、注文書の読み取りから配車の提案まで一つの仕組みに」に、支援の内容は「FAX・メール受注の AI 化」にまとめています。既存の基幹システムとの連携を含めて作る場合は「システム・アプリの受託開発」もご覧ください。
注文書の AI 読み取りを試したものの、本番で回すところで止まっている方は、お問い合わせからご相談ください。いまの受注の流れと、注文書が届く経路（FAX・メール・その他）、書き戻したい基幹システムの入口（CSV・API・画面入力）を教えていただければ、どこで取りこぼしや二重登録が起きやすいかをお伝えします。
