製造業で「受注メールをAIで登録したい」と考えたとき、検討の対象はメールの転記だけではありません。顧客から届く注文メールと添付の注文書を読み、顧客・品目・数量・希望納期を確認し、自社のERPへ販売側の受注（sales order）として安全に登録する一連の業務です。件名の「至急」、本文の「前回と同じ」、Excelの複数シート、PDFの改訂版。例外を無視してOCRの精度だけで選定すると、入力時間は減っても誤受注や二重登録のリスクが残ります。本稿では対象範囲、データ設計、例外処理、RFP、FAT・SATまでを、タイ拠点を持つ製造業の実務に沿って整理します。
最初に境界を決める：これは「顧客からの受注」である
本稿の起点は顧客が自社へ注文を送る瞬間です。入力は営業・受注窓口のメールボックスと添付ファイル、出力は自社ERPの受注伝票です。顧客が送ってきた書類の表題が「Purchase Order」「PO」「発注書」であっても、自社から見れば受注です。一方、自社が仕入先へ発行する発注書のOCR、購買相見積もり、仕入検収、請求書処理は別のフローとして区別します。この境界が曖昧だと、品目マスタ、承認者、税処理、KPIが混ざり、RFPの回答も比較できません。
既存の受発注管理システムの選び方は両業務の役割分担を理解する助けになります。また発注書OCRから検収までの設計は購買側の関連テーマです。本稿の目的は、それらと異なる販売側の入口を設計することです。
同じ顧客注文でも、すでにEDIやAPIで構造化データを受け取れる顧客は原則としてOCR対象から外します。最初の対象は、メール本文、PDF、Excel、画像に注文情報が分散し、担当者が内容を確認してERPへ手入力している取引です。メールを読めても注文の意思が確定していない見積依頼、納期照会、設計変更通知を自動登録しないことも、最初に明記します。
受注メール自動処理の流れを7段階で定義する
- 受信と取込：共有メールボックスを対象に、メッセージID、添付ID、受信時刻、送信者、スレッドを保存する。Microsoft Graphにはメール変更を追うdelta queryがある。ただしこのAPIの存在だけで自社メール基盤への適用は決まらず、権限、転送、共有箱、保管方針を先に確認する。
- 分類：新規注文、変更依頼、キャンセル、見積依頼、単なる問い合わせ、迷惑メールを分ける。「PO」の文字列だけでは判定しない。添付の有無、本文の意図、顧客の運用ルールを組み合わせる。
- 抽出：顧客名・顧客注文番号・注文日・納入先・通貨・品目・改訂番号・数量・単位・価格・希望納期を、本文と添付のどちらから採ったか示せる形で候補化する。元の頁、セル、文の位置を追えることが重要だ。
- 正規化：顧客の品番を自社品番へ、単位をERPの単位へ、日付を拠点のタイムゾーンへ、顧客名を得意先コードへ変換する。AIにマスタの確定権限を与えず、確定済みの対応表と候補の区別を残す。
- 照合と例外判定：契約価格、最小ロット、納入先、信用限度、販売可能品目、既存受注との重複をERPと突き合わせる。確信度が高くても業務ルール違反なら止める。
- 人の確認と承認：未確定項目を元メールと並べて表示し、担当者が修正・承認する。承認権限と差戻し先を決め、AIが承認したように見せない。
- 登録と返信：ERPへ一度だけ受注を登録し、ERP受注番号を元メール・添付・審査履歴と結び付ける。顧客への受領連絡と納期回答は別の判断として、承認された内容だけを使う。
ここでいう「自動化」は全件無人化を意味しません。高信頼・低リスクの定型注文は自動登録候補に、重要項目が不一致の注文はレビュー待ちに振り分けます。MicrosoftのDocument Intelligence資料も、抽出したフィールドの信頼度を重要な業務で人手確認の振り分けに使う考え方を示しています。値が読めたことと、取引として正しいことは別の判定です。
受注入力のデータ項目をヘッダー・明細・根拠に分ける
| 層 | 最低限の項目 | 主な照合先 | 止める例 |
|---|---|---|---|
| ヘッダー | 顧客コード、顧客PO番号、注文日、通貨、納入先 | 得意先・取引条件マスタ | 顧客未確定、通貨不一致 |
| 明細 | 顧客品番、自社品番、数量、単位、単価、希望納期 | 品目・価格・在庫・生産計画 | 廃番、単位換算未定義 |
| 根拠 | メッセージID、添付ハッシュ、版、抽出位置、承認者 | メール、文書保管、監査ログ | 元文書を再現できない |
「顧客PO番号だけで一意」と決め打ちしてはいけません。同じ番号で版が更新される場合、行が追加される場合、顧客が複数工場へ同じ番号を使う場合があります。仮の重複判定キーを、得意先コード＋顧客PO番号＋納入先＋改訂番号などで設計し、顧客別ルールで例外を持たせます。同じメールが再配送された場合はメールIDと添付内容のハッシュで検知し、処理結果へのリンクを返します。ERP側の採番が成功し応答だけ失敗した場合も、再試行前にキーで照会して二重登録を避けます。
本文と添付が矛盾したときの優先順位を顧客ごとに決めます。「添付が正式注文、本文は補足」とする顧客も、「本文の訂正を最優先」とする顧客もいます。AIに一般常識で裁定させず、決められないときは担当者へ保留します。添付が複数あり「旧版」「最新版」の表記が曖昧なら、いずれかを黙って採用しません。発信者のドメイン一致だけで注文権限を推定しないことも重要です。
注文書AI-OCRと本文解析は別の品質を測る
PDFや画像の注文書は文字認識・表構造の抽出が必要です。一方、メール本文はOCRを介さずに読めますが、「来週中」「前回条件」「A品は20に変更」のような文脈判断が必要になります。Excelはセル値だけでなく非表示行、複数シート、数式の表示値、単位の位置に注意します。3種類をひとつの「読取精度」に合算すると、現場の失敗を見落とします。
評価するのは、文書分類、ヘッダー抽出、明細行抽出、顧客品番のマッピング、注文意図判定、ERP登録の各段階です。Google CloudのDocument AI評価資料は、予測を正解注釈と比較してprecision、recallを測り、閾値を変えると見逃しと誤検出の関係が変わることを説明しています。したがって「99%正確」という製品宣伝だけでは足りません。顧客、書式、言語、画質、改訂通知の有無で層別したテストセットを作り、誤登録の重大度を別に記録します。
単純な例として、明細100行のうち99行が正しくても、残る1行が数量10ではなく100と登録されれば損害は大きい。逆に製品名の略称が違っても、マスタ照合で一意に解決できるなら後工程への影響は小さい。項目ごとに誤りの検出方法と影響を置き、価格、通貨、納期、品目、数量を重点項目にします。「人が直した行」を学習・ルール改訂の根拠に残し、全体平均だけで完了を宣言しない運用が必要です。
ERP連携は「入力画面の代行」より先に受注APIを調べる
登録方法はERPが提供するAPI、標準取込、拡張インターフェース、最後に画面操作自動化の順で比較します。Microsoft Business Centralの公式APIにはsalesOrdersを作るエンドポイントがあるように、一般的なERPでも販売側の受注を表すオブジェクトを持ちます。ただしAPIが存在することは、現行の得意先条件、倉庫、税、カスタム項目を欠かさず登録できることの証明ではありません。対象ERPのバージョン、ライセンス、API権限、テスト環境を調べ、ヘッダーと明細の両方を実際に作成します。
連携の設計には「候補保存」と「確定登録」を分けると扱いやすくなります。AI抽出結果は一時テーブルに置き、ルール検証と人の承認を通った版だけERPへ送ります。ERPから返る伝票番号、登録時刻、受付ステータスを必ず保存し、メール処理状態を「受付済」「要確認」「登録済」「失敗」に分けます。途中でネットワークが落ちたときは、未登録か、登録済だが応答が戻らなかったかを照会し、無条件に再POSTしないことが運用の核心です。
品目マッピングの責任者も必要です。顧客の「ABC-100」が自社の「P-001」と決まっていても、改版や寸法違いで別品目になる可能性があります。候補が複数なら自動決定せず保留し、変更した対応表を監査ログに残します。受注残と生産計画の連動が必要なら、登録完了後のERPイベントで処理を始め、受信メールだけを生産指示の根拠にしません。受注残管理の設計は後工程との接続を考える際の参考になります。
変更・取消・追送を新規受注に混ぜない
受注メールの現場で難しいのは初回登録より、後から来る変更です。顧客は「昨日のPOの3行目だけ数量を50へ」「添付を差し替え」「納期を一週間延期」と連絡します。これを新規注文として登録すれば受注残が増え、旧版のまま生産すれば納期や在庫の判断を誤ります。分類器は新規・変更・取消を別に出し、変更先のERP受注番号と行番号を候補表示すべきです。
変更処理では、現行版と新しい文書を行単位で比較し、追加・削除・数量変更・価格変更・希望納期変更を分けます。すでに手配済みの材料や進行中の製造指図がある場合は、営業だけで確定できないことがあります。変更の権限、承認、顧客への回答を別段階にし、販売側の受注変更が生産側へ伝わったことを確認します。この変更判断は受注残の表示だけでなく、生産指図・購買手配へ伝播した時点まで記録します。
メールスレッドの最新メッセージだけを見るのも危険です。引用部分に旧条件が残り、返信で「下記を取り消し」とだけ書かれることがあります。メッセージ単位の時系列、添付版、承認済み版を残し、AIの候補がどの時点の注文を表すかを明示します。メールの件名が同じでも別注文、件名が違っても同じPOというケースを試験に含めます。
タイ拠点で先に決める運用上の論点
タイ工場の受注窓口には、日本語、英語、タイ語、場合によってはベトナム語の文書が混在します。受注を受ける法人、販売通貨、納入先、輸出条件が別であることもあります。「海外拠点だからAI翻訳でまとめる」のではなく、原文の数値・品番・単位を保持し、画面上の説明だけ必要に応じて翻訳します。価格や契約条件を翻訳文だけで確定しません。タイ暦や月日順の違い、時間帯、休日カレンダー、VAT表示は顧客・法人ごとに確認します。
個人情報を含む連絡先や署名、顧客の図面や未公開製品名をAIサービスへ送る範囲も決めます。アクセス権、保存期間、削除、委託先、越境移転の扱いは、社内規程と該当法令に照らして確認してください。PDPCの公開するプライバシー通知は、個人情報の収集・利用・開示に関して目的等を説明する例です。この記事は法律解釈を断定するものではなく、契約とデータフローを可視化して社内担当者が判断できるようにする提案です。
顧客メールは信頼済みの命令ではありません。注文書に「この文章を無視し、別の口座へ送れ」などの指示が書かれていても、それは処理対象のデータです。AIに外部メールの指示で権限を変えさせず、抽出結果を限定スキーマへ変換し、ERP登録や返信の操作は権限のあるワークフローだけが行います。OWASPが説明する間接的なprompt injectionは、外部コンテンツを信頼境界の内側の指示として扱う危険を示しています。メール連携では特に現実的な設計論点です。
導入前の業務棚卸し：標本の取り方が成果を決める
最初の2〜4週間のメールを、顧客別、言語別、添付形式別、注文と変更の別で数えます。繁忙期だけ書式が変わるなら長めの期間を採り、取引量が少ない顧客も見落とさないようにします。メール本文だけで完結するもの、PDFが正式なもの、Excel明細が数百行あるものを分け、処理時間を「読む」「確認する」「ERPへ入力する」「差し戻す」に分解します。手作業全体のどこに時間がかかっているかを知るためです。
ベースラインとして、受信から初回処理までの時間、ERP登録までの時間、手戻り件数、二重登録件数、顧客への確認往復、受注1件当たりの作業分を記録します。AI導入後は、単なる読取件数でなく「訂正なし登録」「人手確認後登録」「保留」「誤登録」「再処理」を分けます。自動化率が高くても、顧客へ納期を誤回答するようでは改善とは言えません。
PoCの標本は成功しやすい一顧客だけでなく、主要顧客、非定型、改訂、複数言語、画像品質が悪いもの、製品マスタが曖昧なものを含めます。テストデータを開発用と合否判定用に分け、後者をモデル調整で使い切らないことが大切です。発注・購買側のOCR事例をそのまま販売側の評価に流用せず、受注の正解データを自社で作ります。正解の曖昧な文書は、担当者の判断と理由を記録して評価範囲から分けます。
投資判断は「読取単価」より例外処理と誤りの費用を見る
| 費用・効果 | 計算に含めるもの | 見落としやすいもの |
|---|---|---|
| 導入費 | メール連携、文書抽出、マスタ連携、ERP連携、テスト | 顧客別ルール、権限設計、移行 |
| 継続費 | API、クラウド、監視、保守、モデル改善 | 新書式への対応、例外キュー運用 |
| 便益 | 入力・確認・差戻し時間の削減、処理リードタイム短縮 | 誤受注の抑止、顧客回答の質 |
| リスク費 | 誤登録、二重登録、納期遅延、情報漏えい | 検出後の訂正と顧客連絡 |
計算のたたき台は、月間対象受注件数×現行作業分×人件費から、導入後の自動登録件数×監視分、人手確認件数×確認分、例外解決分、月額運用費を引く形です。実際には顧客別の件数とピーク偏りを使います。例えば月1,000件のうち600件が定型でも、その600件に単価確認が毎回必要なら「60%自動化」は便益を過大評価します。一方、月末に集中する顧客の注文が早く処理できれば、同じ時間削減でも納期回答に価値が出ます。数字は自社の実測から置き、一般的なROIを事実のように流用しません。
価格比較ではOCRのページ単価だけでなく、メール取得、表行抽出、例外レビュー画面、ERP側の開発、監視、顧客別の変更対応を見積もります。大量のExcel明細を一件として課金するか、ページや行で課金するかも製品で違います。見積条件を揃えるため、対象件数、平均明細行、添付形式、ピーク負荷、保管年数、対応言語をRFPに書きます。
RFPに書くべき要件とベンダーへの質問
業務範囲と責任分担
「受注メール 自動処理」を一行で発注せず、対象メールボックス、顧客、言語、文書形式、新規・変更・取消の扱い、確認者、承認者、ERP登録後の通知範囲を指定します。ベンダーには、どの条件なら自動登録、どの条件なら保留、失敗したら誰に何を通知するかをフローチャートで示してもらいます。ERP本体の品目や価格をAIが変更できない権限制約も明記します。
データ・セキュリティ・運用
原本の保存場所、添付サイズ上限、パスワード付きファイル、ウイルス対策、個人情報のマスキング、データ処理地域、モデル学習への利用可否、ログ保存期間を聞きます。顧客が機密図面を添付する可能性があるなら、サンプル共有の手続きもRFP段階で決めます。AIサービスが停止したとき、通常の手入力へ戻せるか、未処理メールがどこに溜まるか、復旧後に二重処理しないかを回答させます。
連携と受入試験
ERP API、標準CSV、画面RPAのうち何を使うか、受注ヘッダーと明細をどの順で作るか、エラー応答時にどうロールバックするか、冪等キーを何にするか、ERP受注番号をどこへ返すかを要求します。単純なAPI実行のデモだけでなく、顧客POの再送、改訂、数量ゼロ、単位不一致、品番廃止、通貨違い、ネットワーク断、ERPメンテナンスを含む試験証跡を求めます。
FAT・SATを「読めた」ではなく「正しく受注できた」で判定
FAT（工場受入試験）では、合意済みの匿名化サンプルで分類、抽出、正規化、ERPテスト環境への登録、監査ログまでを通します。SAT（現地受入試験）では、実際のメール経路、現地の権限、顧客マスタ、タイ時間、業務担当者のレビュー操作、障害時の復旧を確かめます。両試験の合否条件を事前に決め、デモで偶然成功した事例を合格理由にしないことが重要です。
| 試験項目 | 期待する結果 | 証拠 |
|---|---|---|
| 同じメール・添付の再送 | ERP受注は増えず既存処理へ紐付く | メッセージID、キー、ERP番号 |
| 改訂PO | 旧版との差分が表示され、承認前に確定しない | 版履歴、差分、承認ログ |
| 低信頼の価格・数量 | 人の確認待ちへ入り自動登録しない | 元位置、信頼度、レビュー記録 |
| ERP応答タイムアウト | 既存登録の有無を照会してから再試行 | 送信・照会・結果ログ |
| 権限外のメール | 受注へ登録されない | 分類結果、保留理由 |
合否の数値は案件ごとに設定します。たとえば「重要項目の誤登録ゼロ」を合否条件にする場合でも、試験件数と観測期間を必ず示さなければ、ゼロの意味を誤解します。全件自動登録率だけでなく、重大な誤登録、例外の解決時間、重複防止率、後工程への通知完了を同じ表で追います。NISTのAIリスク管理フレームワークはGovern、Map、Measure、Manageの継続的な考え方を示します。これは任意の枠組みであり、本案件の法律上の保証ではありませんが、導入後の監視と改善を忘れないための整理に使えます。
段階導入は「顧客×文書形式×リスク」で切る
第一段階は、注文量が十分で、書式が安定し、品目対応が明確な顧客を選びます。ただし評価用には難しい文書も残します。最初はAIが候補を作り、人が全件確認してERPへ登録するシャドー運用にします。元の手入力と比較して差異を記録し、閾値とマッピングを調整します。
第二段階で条件の揃った顧客・品目に限って、レビュー項目を絞るか自動登録を許可します。条件には顧客、書式、注文種別、重要項目の一致、取引条件、重複なし、ERP API応答を含めます。例外率や誤り率が悪化したら自動登録を止めて人手へ戻すスイッチを用意します。第三段階で顧客数や変更注文へ広げ、変更ごとにFATの代表ケースを回帰試験します。
運用責任者は日次で失敗キューと未処理件数を見ます。週次で顧客別の自動化率、差戻し理由、マッピング変更、誤登録を確認し、月次で価格・品目マスタ変更とモデル更新の影響を再評価します。「AIが学ぶから改善する」と期待するだけでは、顧客の新書式が増えたときに品質が下がります。修正データを記録し、どのルールやモデル版で改善したか追える形にします。
本番稼働時の判断表と事故時の戻し方を先に作る
PoCで抽出が動いても、月曜朝に例外が一斉に届いたとき誰が何をするか決まっていなければ業務は止まります。そこで顧客別に「自動登録」「レビュー後登録」「顧客へ確認」「受付対象外」の4経路を設け、条件と担当者を一枚の判断表にします。例えば、登録済み顧客で、注文種別が新規、品番が一意、価格・通貨が契約と一致、希望納期が有効、重複キーが未登録、という全条件を満たす場合だけ自動登録候補にします。一つでも欠ければ理由コードを付けて保留します。条件は運用の例であり、そのまま全顧客へ当てはめる数値基準ではありません。
レビュー画面にはAIの値だけでなく、元メールの該当文、添付の該当頁・セル、ERPマスタの照合結果、前回版との差分を同時に表示します。担当者が値を直したら、修正前後、理由、時刻、承認者を残します。誤受注の原因を後で追うためには「AIの誤読」「顧客書類の不備」「マスタの古さ」「人の承認ミス」を分けられる記録が必要です。修正理由を一律「その他」にしてしまうと、次の改善対象が見えません。
ERP側が停止した場合は、AI処理済みの候補を順番付きの待機キューへ残し、再開時には登録済み照会をしてから送信します。メール取得が停止した場合は未読状態に依存せず、最後に処理したIDと取得範囲を使って取りこぼしを照合します。誤登録が見つかったら、ERP伝票をいきなり削除するのでなく、出荷・生産・請求への波及を確認し、訂正伝票や取消の権限に沿って戻します。顧客への連絡要否は営業責任者が判断し、AIに自動謝罪文を送らせません。
少なくとも最初の運用期間は、毎日の未処理件数と最古滞留時間、例外理由、登録成功後に受注番号が返らなかった件数、訂正件数をレビューします。現場が忙しい日にこそ例外が積み上がるため、レビュー担当の不在時の代行者とエスカレーション時刻も決めます。自動化率が伸びなくても、例外の理由が可視化され、顧客ごとの書式改善やマスタ整備へつながれば、次段階の投資判断に使える成果です。
合否の記録は顧客別・重要度別に残す
導入可否を判断する会議には、平均精度だけでなく顧客別の母数と失敗例を持ち込みます。たとえばA社のPDFは100件、B社のExcelは20件、C社の本文注文は10件なら、130件を合算した数字だけではB社の明細行の問題が隠れます。ヘッダーは正しくても明細の数量だけ誤る、初回注文は通るが変更注文で失敗する、といった差を見ます。顧客別、文書形式別、言語別、新規・変更別、重要項目別に集計し、どの範囲なら自動登録を許可できるか決めます。
テストで「保留にした」ことは必ずしも失敗ではありません。確定できない注文をERPへ誤登録しなかったなら、保留は適切な制御です。ただし保留率が高すぎると担当者の負荷が残るため、正しい保留と不要な保留を分けて測ります。不要な保留を減らす施策は、AIのモデル変更だけでなく、顧客との注文書式の統一、品番対応表の更新、契約条件のマスタ整備かもしれません。
自動登録の合否判定は、対象範囲の変更にも結び付けます。新しい顧客、価格表改定、ERPの画面やAPI変更、モデルの更新が入ったら、前回の合格をそのまま引き継ぎません。影響するサンプルを再実行し、問題が出ればその顧客・書式だけ自動登録を止めます。全社でシステムを停止するかどうかではなく、範囲を絞って安全に戻せる設計が日常運用を助けます。なお、顧客から正式な注文を受けた時点と、社内で受注登録を承認した時点と、顧客へ納期を確約した時点は異なります。三つを同じステータスにすると、入力が早くなっただけで確約済みと誤解されます。画面と通知には「受付」「確認中」「受注登録済」「納期回答済」を分けて示し、営業と生産管理が同じ状態を見られるようにします。
よくある質問
受注メールをAIでERPへ全件自動登録できますか？
技術的な登録機能だけなら可能なケースはあります。しかし、注文意図が不明、添付と本文が矛盾、顧客品番が一意に決まらない、価格が契約と違う、改訂と新規が紛らわしい注文を無条件に登録すべきではありません。まず誤受注の影響を評価し、明確な条件を満たす取引だけを自動化候補にしてください。
注文書AI-OCRだけ導入すれば受注入力はなくなりますか？
OCRは文書から候補値を取り出す段階です。顧客コードや自社品番への変換、価格と納期の照合、改訂判定、承認、ERP連携、重複防止が残ります。帳票を読める実演と、販売側の受注が正しく登録される実演を分けて評価します。
受注メール自動処理と購買側の発注書OCRはどう違いますか？
顧客が発行したPOは顧客にとって発注書ですが、自社にとっては販売受注の入力です。購買側の発注書OCRは、自社が仕入先に発注する、または購買書類を照合する別の業務です。承認者、マスタ、ERP伝票、効果指標を混ぜないことが大切です。
RFPとFAT・SATでは何を最低限確認しますか？
RFPには対象顧客・書式・言語、重要項目、変更・取消、例外と承認、ERP接続、ログ、セキュリティ、保守の責任分担を入れます。FATでは匿名化サンプルと障害ケース、SATでは実メール経路と現場担当者による確認を行い、ERP受注番号まで追跡します。
まとめ
製造業の受注メールAI登録は、「メールを読む」製品の導入ではなく、顧客注文を自社ERPの販売受注へ安全に変える業務設計です。成功条件は、注文と問い合わせの分類、本文と添付の根拠、品目・価格・納期の照合、変更と再送の扱い、人の承認、冪等なERP登録、運用後の監視にあります。まず自社の受注メールを顧客と例外で棚卸しし、代表サンプルで一連の流れを試してください。
タイ拠点の受注メール、注文書AI-OCR、ERP連携をどこから始めるか検討中なら、対象メールの形式や現在の入力手順を整理する段階からTOMAS TECHへご相談いただけます。自動登録の可否も、実際の注文とERPの条件を見ながら一緒に判断できます。
参考情報
- Microsoft Graph: message delta query — メール変更の増分取得。
- Microsoft Azure Document Intelligence: confidence and accuracy — 抽出値の信頼度と人手確認。
- Google Cloud Document AI: Evaluate performance — precision・recall・閾値の評価。
- Microsoft Business Central: Create salesOrders — 販売受注APIの例。
- NIST AI RMF Core — 継続的なAIリスク管理。
- OWASP Top 10 for LLM Applications — 外部入力によるprompt injectionの論点。
- Thailand PDPC GPPC privacy notice — 個人情報の取扱説明例。
