受発注のやりとりが自動化しにくい理由
受注側から見た発注の受け取りは、届いたメールを読んで、注文の内容を受注管理表へ写し、いつまでに何を用意するかの予定を立てる作業に分かれます。書類の読み取りだけを取り出せば請求書の処理と似ていますが、実務では扱いが変わります。理由は3つあります。
注文の内容がメール本文に書かれることがあります。 注文書のPDFが添付されていれば読み取り対象は明確ですが、本文に「前回と同じ品番を20個、月末までにお願いします」とだけ書かれている場合もあります。添付が正で本文が補足のこともあれば、逆のこともあります。
前のやりとりを参照した書き方をします。 「先日いただいた見積のうち、A品番だけ先に」「数量を10から12に変更」といった注文は、そのメール単体では確定しません。過去の見積や注文履歴と突き合わせないと数量も単価も決まりません。
読み取り結果の間違いが社外へ出ます。 請求書の処理は出力先が社内の会計システムですが、受注は納期回答や注文請書として取引先へ返り、そのまま生産や仕入の予定になります。誤読に気づくのが出荷直前になると、間に合わせるための調整が発生します。
この3つを踏まえると、設計の重心は読み取りの精度そのものより、確定できていない項目を先へ通さない作りに置くことになります。文字を取り出す方式の違いについては AI-OCRと生成AIの違い で扱っています。
発注メールから取り出す項目と、確定できないときの扱い
受注として登録するには、最低限そろえるべき項目が決まっています。項目ごとに、記載のばらつき方と、確定できなかった場合の扱いを先に決めます。
| 取り出す項目 | 記載のばらつき | 確定できないときの扱い |
|---|---|---|
| 取引先と発注担当者 | 送信元アドレスが担当者個人、代表、代理店のいずれか | 送信元と署名から候補を出し、取引先マスタと一致しなければ人へ回す |
| 品番と品名 | 自社品番、取引先の社内符号、通称の混在 | 過去の注文履歴から候補を示し、1件に絞れなければ登録しない |
| 数量 | 個数、ケース数、重量、長さなどの単位混在 | 単位が書かれていない場合は既定値で埋めず、人へ回す |
| 単価と金額 | 記載なし、税抜、税込、単価のみ、合計のみ | 見積や取引条件の単価と一致しない場合は差の理由を確認する |
| 希望納期 | 日付、週指定、「なるべく早く」などの表現 | 日付に置き換えられない表現は人が取引先へ確認する |
| 納入先と納入条件 | 本社宛と現場直送の混在、分割納入の指定 | 過去の納入先と違う場合は人へ回す |
| 注文の番号 | 取引先ごとの採番、記載なし | 記載がなければ自社側で採番し、メールのIDと紐づける |
表の右列を「人へ回す」で埋めた項目は、自動化の効果が薄いのではなく、事故の起きる場所を人の手前で止めているものです。ここを既定値で埋める作りにすると、間違いが受注登録の後まで残ります。特に数量の単位は、ケースを個数として登録すると数量が桁で変わるため、書かれていないものを推測で補わないようにします。
メールの本文から項目を取り出し、確からしさで人の確認を挟むこの型は、注文以外のメールにも使えます。問い合わせを仕分けて返信の下書きを作り、面談の候補日を出すまでの組み方は 問い合わせの一次返信と面談の日程調整をAIで自動化する で扱っています。
表記のばらつきをそろえる
読み取った文字列を、そのまま受注管理表へ入れることはできません。同じ内容を指す別の書き方を、社内で使う値へ寄せる処理が必要です。
品番。 取引先が使う符号と自社の品番が違う場合、対応表を持ちます。対応表は最初から完成させられないので、人が直した内容を記録して育てます。同じ取引先で同じ読み替えが繰り返されるなら、その取引先固有の対応として登録します。
数量と単位。 「20個」「20pcs」「2ケース（1ケース10個）」を、社内の在庫単位に換算した数へそろえます。換算に使う入り数は品番マスタから引き、マスタに無い品番は換算せず人へ回します。全角と半角、桁区切りの有無、単位が数字の前に来る書き方も、正規化の対象になります。
日付。 「8/末」「来週中」「9月第2週」を日付として持つには、どの日に寄せるかの規則を決めておきます。月末は当月の最終営業日、週指定はその週の最終営業日といった形です。規則で置き換えられない表現は空欄のまま人へ回します。ここを推測で埋めると、納期の約束が実際の依頼と食い違います。
単価と金額。 税抜と税込のどちらで書かれているかを、金額の関係から判定します。単価と数量の積が合計と合わない場合は、どちらかの読み取りを疑うか、値引きや諸費用が含まれていると考えます。合わないものは登録せず、差の理由が説明できるまで止めます。
正規化の規則は、コードの中に散らさず1か所にまとめて、人が読める形で置いておきます。運用中に必ず追加が出るためです。
受注登録と納期スケジュールまでの流れ
工程に分けると、どこを機械が持ち、どこで人が判断するかがはっきりします。
- 受信と仕分け … 受注用のメールアドレスへ集約し、注文か問い合わせかを分ける。届いた時点でIDを振る
- 読み取り … 本文と添付の両方から項目を取り出す。両方に記載がある場合は差分を残す
- 照合 … 見積、取引条件、取引先マスタ、品番マスタ、注文履歴と突き合わせる
- 確認 … 照合で合わなかったものと、確定できなかった項目だけを人が判断する
- 受注登録 … 受注管理表へ登録する。メールのIDと注文の番号を残す
- 納期スケジュール … 在庫と手配のリードタイムから、着手日と出荷日を置く
3の照合を省いて、読み取った結果をそのまま人の確認へ回す構成になりがちです。その形だと、担当者が過去のやりとりを探しながら1件ずつ見比べることになり、作業量が変わりません。見積の単価と合っているか、品番がマスタにあるか、数量が過去の注文と大きく違わないかは、機械で照らせます。
6の納期スケジュールは、受注登録と分けて考えます。登録は注文された内容の記録で、スケジュールは自社が動く予定です。在庫がある品番はそのまま出荷日を置けますが、手配が必要なものは仕入や生産のリードタイムを足します。希望納期に間に合わない見込みが立った時点で担当者へ知らせる形にすると、取引先への連絡が遅れずに済みます。
人の確認をどこに置くか
確認を全件に残すと自動化の意味が薄れ、外しすぎると誤読が社外へ出ます。判断の性質で分けます。
| 人が持つ判断 | 人へ回す条件 | 自動で通さない理由 |
|---|---|---|
| 注文かどうかの解釈 | 見積依頼や問い合わせと区別がつかない、条件付きの表現がある | 注文として登録すると取引先の意図と食い違う |
| 品番の特定 | マスタに無い、候補が複数残る、後継品への読み替えが要る | 別の品を手配すると出荷直前まで気づけない |
| 数量と単位 | 単位が書かれていない、入り数がマスタに無い | 桁が変わる誤りになりやすい |
| 単価と取引条件 | 見積の単価と違う、値引きや諸費用が含まれる | 金額の合意は自社の取引条件に依存する |
| 納期の回答 | 希望納期に間に合わない、分割納入になる | 社外への約束になるため機械で確定させない |
| 変更と取消 | 既に手配や出荷が進んでいる注文への変更 | 後工程への影響を人が判断する必要がある |
確認の画面は、元のメール本文と添付、読み取った値、照合した相手（見積や過去の注文）を並べて表示し、値がどこから来たかを追える形にします。人が直した内容は記録して、対応表や正規化の規則へ戻します。確認を目視だけで終わらせると、同じ直しが毎回発生します。
変更と取消は、受発注では独立した工程として扱う必要があります。同じ取引先から届く「先の注文の数量を変更」というメールを新規の注文として登録すると、二重に手配します。過去の注文を参照している注文は、参照先を特定してから変更として処理し、手配が進んでいる場合は人へ回します。
誤読を後工程へ流さない
自動化で決めるべきは、うまく処理できたときの流れよりも、処理できなかったものの行き先です。
差し戻しは2種類に分けます。社内で直せるもの（品番の読み替え、単位の換算、納入先の特定）と、取引先へ確認しないと進まないもの（数量や納期の表現が曖昧、見積と条件が違う、注文の重複が疑われる）です。前者は担当者の作業待ち、後者は取引先の返答待ちで、放置されたときの影響が違います。
差し戻したものには状態を持たせます。誰の手元にあるか、いつから止まっているか、返答があったか。状態を持たない作りにすると、確認待ちのまま数日たった注文が、納期の直前に見つかります。滞留の一覧と、一定時間を超えたときの通知までを含めて、はじめて運用に乗ります。
止めたものの件数と理由は記録しておきます。「単位が書かれていない」が特定の取引先に集中しているなら、正規化の規則を足すより、注文の書式をそろえてもらう相談のほうが早く解決します。自動化の対象を広げる判断も、この記録から行います。効果の測り方は AI導入の効果測定と投資判断 を参照してください。
検収から請求へ引き渡す
受注登録と納期スケジュールができると、その先の出荷、検収、請求へつながります。ここで受け渡す情報を決めておかないと、請求の段階で受注の内容をもう一度調べることになります。
引き渡すのは、注文の番号と自社の受注番号、品番ごとの数量と単価、納入した日付、検収が済んだ日付、そして請求の単位（注文ごとか、月ごとにまとめるか）です。分割納入した注文は、どの納入分がどの注文に対応するかを残します。
請求側で起きる差異の多くは、この引き渡しの欠けから生まれます。請求金額が発注書の金額と合わない、検収数量と請求数量が違う、締めのタイミングがずれる、といった食い違いです。受注の時点で単価と数量を確定させ、変更があったときに履歴を残しておけば、請求時に照合できます。請求書側の処理は 請求書処理の自動化をAIで進める、保存の要件は 電子帳簿保存法に対応した請求書処理の自動化 で扱っています。
受発注のメールそのものも、取引に関する書類として保存の対象になり得ます。注文の内容が本文に書かれている場合、そのメールが証憑になるためです。読み取って管理表へ写した後に元のメールを消さず、IDで引ける形で残しておきます。
どこから手を付けるか
範囲を絞らずに始めると、取引先ごとの例外の対応で止まります。順に狭めます。
経路を1つに限る。 受注用のメールアドレスに届くものだけを対象にし、電話やFAXでの注文は当面これまでのやり方を続けます。
取引先を絞る。 件数が多く、書式が安定している数社から始めます。ここで正規化の規則と対応表の形が固まります。
工程を絞る。 読み取りと照合までを自動化し、受注登録は人が確認したうえで行います。この段階で、どの項目に直しが集中するかを記録します。
返信は最後に回す。 納期回答や注文請書の自動送信は、社外に出る文面です。まず下書きの作成までに留め、登録された内容と一致しているものに限って範囲を広げます。
記録を見て次を決める。 直しがほとんど出なかった項目から、人の確認を外していきます。着手前に自動化の割合を決めてしまうと、判断の材料がないまま範囲を広げることになります。
始める前に用意するものは、対象とする取引先の一覧と過去の注文履歴、品番マスタと入り数、取引条件（単価と支払条件）、納期を決める規則、そして運用を直し続ける担当です。最後の1つが決まっていないと、正規化の規則が更新されず、例外が増えた時点で使われなくなります。検証から本番運用までの進め方と見積の考え方は AIエージェント開発の進め方 で扱っています。
まとめ：受発注の自動化を設計するときの要点
- 発注メールは本文と添付のどちらにも注文の内容が書かれ、過去のやりとりを参照した書き方をする。読み取り単体では確定しない
- 取り出す項目ごとに、確定できなかったときの扱いを先に決める。数量の単位や納期の表現を既定値で埋めない
- 品番、単位、日付、金額の表記のばらつきをそろえる規則を1か所にまとめ、人が直した内容を戻して育てる
- 読み取りの後に照合を置く。見積の単価、品番マスタ、過去の注文と機械で照らしてから人の確認へ回す
- 人が持つのは注文かどうかの解釈、品番の特定、単価、納期の回答、変更と取消の扱い。社外へ出る文面は自動で確定させない
- 差し戻しは社内で直すものと取引先へ確認するものに分け、状態と滞留の通知を持たせる
- 受注の時点で単価と数量を確定させ、履歴を残しておくと検収から請求への引き渡しで照合できる
Augueでは、メールや帳票の読み取りから既存の管理システムへの連携までを含めたAIエージェントの開発に対応しており、どこまでを機械に任せどこに人の確認を残すかの線引きから一緒に検討できます。自社の受発注業務を自動化の対象にできるか判断したい方は、是非ご相談ください。
関連する記事
読み取り方式の選び方は AI-OCRと生成AIの違い、請求までつなげる設計は 請求書処理の自動化をAIで進める、開発の進め方と見積の考え方は AIエージェント開発の進め方 を参照してください。
よくある質問
発注メールへの返信（注文請書や納期回答）まで自動送信してよいですか？
返信は社外に出る文面なので、当面は下書きの自動作成までに留める運用が扱いやすいです。読み取り結果から返信案を組み立て、担当者が承認して送る形にします。自動送信へ広げる場合も、既存の取引で数量と単価と納期が受注登録の内容と一致しているものに限り、初回取引や条件変更を含むものは対象から外します。
EDIやWeb発注、FAXの注文とは並行して進められますか？
出口を先に揃えると並行できます。受注管理表と納期スケジュールの形式を決めておき、経路ごとに入口の処理だけを差し替える構成にします。EDIは項目が決まっているため読み取りが不要で、FAXは画像からの読み取りになります。経路ごとに設計をやり直すと維持できなくなるため、受注登録の手前で1本にまとめます。
既に受注管理システムを使っている場合、どこを作ることになりますか？
作るのはメールから受注データを組み立てる部分と、既存システムへ渡す部分です。管理システム側に取込用の形式や接続の口があるかを先に確認します。無い場合は、人が入力する画面へ候補として表示する形に留めるほうが、二重管理を作らずに済みます。読み取り結果を別の表で持ち始めると、どちらが正しいのか分からなくなります。
導入にどれくらいの期間と費用がかかりますか？
一律の目安は出せません。取引先の数、経路の種類、既存システムへの渡し方で変わります。見当をつけるには、対象を1経路と数社に絞った範囲で試し、読み取りの直しがどこに集中するかと、既存システムへの接続にどれだけ手間がかかるかを先に確かめます。この2つが分かると、範囲を広げたときの見積もりが立てられます。
読み取りの精度はどう評価すればよいですか？
全体の正解率ではなく、項目ごとの直しの発生率で見ます。品番、数量、単価、希望納期のどれで直しが起きたかを記録し、機械での照合で気づけたか、人の目でしか気づけなかったかを分けて数えます。後者が残っている項目は、自動で先へ通す対象から外します。