受注の入り口は取引先の都合で決まります。EDIの取引先もあれば、注文書のPDFをメールで送ってくる取引先も、いまだにFAXの取引先もある。そのうえ内示が先に来て、確定が後から来て、途中で数量が変わる。この記事では、受注入力そのものより「変わった分を取りこぼさない」ことを軸に、AIに任せられる範囲と人が確定すべき範囲を整理します。
受注入力の負担を「入力作業が遅いから」と捉えると、対策はシステムの操作性の話に寄っていきます。しかし多品種を扱う製造業で実際に効いているのは、入り口が取引先の数だけ存在するという構造の方です。
自動車部品のTier2・Tier3であれば、主要な得意先とはEDIやWeb-EDIでつながっている一方、二次的な得意先や補給品・試作の依頼は注文書のPDFがメールで届きます。飲料や食品の工場であれば、量販店向けは内示が先に来て、特売の企画によって数量が大きく動きます。遊技機の部品や治具のように機種の入れ替わりが速い領域では、そもそも図面と手配が同時に走ります。
どのケースでも共通しているのは、一つの注文が一度で完結しないことです。先に大枠の数量が来て、後から確定が来て、その間に変更が入る。受注入力の実務は「入力」よりも、この時間差のある情報を照らし合わせる作業に時間を取られていきます。
内示は生産計画を立てるための見込みであり、確定注文は納入義務を伴う指示です。ただし内示の拘束力は一様ではなく、取引先によっては内示のうち直近の区間だけを確定枠として扱う運用や、内示に基づいて手配した材料の扱いをあらかじめ取り決めている場合もあります。性質が違うため、社内では別々の帳票・別々のメール・別々のExcelとして扱われがちです。ところが現場が本当に知りたいのは、この二つを並べた差分です。
この四つは、担当者がExcelを二枚並べて目で追う形で処理されていることが少なくありません。品番数が数十であれば成立しますが、数百を超えると見落としが発生する余地が増え、しかも見落としたことに気づくのは欠品や特急便が発生した後になります。
ここが、AIを入れる価値が出やすい地点だと考えられます。差分そのものは機械的な比較であり、判断を必要としません。人が判断すべきなのは差分が出た後の対応であって、差分を見つけること自体ではありません。
「受注をAIで自動化する」と一括りにすると、すでに構造化されているEDIにまでAIを噛ませるような無駄が生じます。チャネルごとに何が課題で、何が適した手段かを分けて考える必要があります。
| 受注チャネル | 実務上の主な課題 | 適していると考えられる手段 |
|---|---|---|
| EDI(JCA手順・全銀手順などのデータ連携) | データは構造化されているが、社内の基幹システムへの取込後に品番の読み替えや単位換算が手作業で残る | マスタ整備と取込処理の自動化。AIによる読み取りは不要 |
| 取引先のWeb発注画面(Web-EDI) | 画面を人が見に行かないと新規注文に気づかない。注文が画面表示やPDFでしか出てこず、ダウンロードしたCSVの形式も取引先ごとに違う | 取得の定型化とフォーマット変換。読み取りより「取りに行く」工程の設計が中心 |
| 注文書PDF(メール添付) | レイアウトが取引先ごとに異なる。改訂版が同じ件名で再送されることがある | AI・OCRによる抽出とマスタ照合。改訂の検知が重要 |
| Excel(メール添付) | 結合セル・複数シート・非表示行・独自の記号が混在する | 表の意味を読み取る方式。ただし非表示行やシート分割は人の確認へ回す |
| メール本文への直書き | 「先ほどの分は取消し」「追加で3個」といった訂正が自由文で混じる | 抽出はするが自動確定させない。人の確認を前提とした下書き扱い |
| FAX | 手書きの追記・かすれ・押印の重なり。到着に気づかない | OCRと確信度による振り分け。読めない分を隠さず確認へ出す設計 |
| 電話 | そもそも記録が残らない。言った言わないになりやすい | AIの前に、受けた内容を必ず書き残す運用の確立が先 |
この表で伝えたいのは、AIが効くのは表の中ほど(PDF・Excel・メール本文・FAX)に限られるということです。EDIにAIは要りませんし、電話の課題はAI以前の運用設計の問題です。
受注は、間違えると相手の生産に影響し、しかも取り消しが効きにくい業務です。だからこそ、どこまでを自動で進め、どこから人が確定するかを先に決めておく必要があります。
| 工程 | AIに任せられると考えられる範囲 | 人が確定すべき範囲 |
|---|---|---|
| 受領 | メール・添付・FAXの受信を検知し、受注らしきものを一箇所に集める | 受注か問い合わせか判断がつかないものの仕分け |
| 読み取り | 品番・数量・納期・送り先の抽出と、社内マスタとの突き合わせ | マスタに一致しない品番の同定。新規品番かどうかの判断 |
| 差分 | 前回受領分との比較、増減・追加・消滅の一覧化 | 差分に対して受けるか・調整を依頼するかの判断 |
| 登録 | 登録内容の下書き作成 | 基幹システムへの確定登録 |
| 回答 | 過去の類似案件と現在の負荷状況の提示 | 納期回答・価格の適用・特急を受けるかの決定と、取引先への連絡 |
この線引きの根拠は精度ではなく取り返しがつくかどうかです。読み取り違いは登録前なら直せますが、誤った納期回答は相手の計画に入り込んだ後では戻せません。
権限と承認の設計そのものについては、AIエージェントに任せる範囲と人の承認ポイントの設計で扱っています。
差分を出すこと自体は難しくありません。難しいのは、出した差分が現場で見られる形になっているかどうかです。実務で機能させるには、少なくとも次の三点が必要だと考えられます。
社内での変更情報の伝わり方については、製造業の営業と生産管理の情報共有で、部門をまたぐ側から扱っています。
読み取りの精度以外のところで止まることが多いのが、この領域の特徴です。
次のいずれかに当てはまる場合、AIによる読み取りより先に検討すべき手段があると考えられます。
| 状況 | 先に検討すべき手段 | 理由 |
|---|---|---|
| 取引先が数社で、うち大半の物量を占めている | EDI化・Web発注への移行の交渉 | 構造化されたデータを受け取れれば読み取り自体が不要になる |
| 注文書の書式が完全に固定されている | 定型のOCRテンプレートやRPA | レイアウトが変わらないなら、より安価で挙動が読める手段で足りる |
| 受注件数が1日数件 | 現状維持、または受信の見落とし対策のみ | 自動化の維持コストが処理の削減量を上回る可能性がある |
| 基幹システムの品番マスタが未整備 | マスタ整備 | 照合先がなければ抽出結果を判定できない |
RPAや既存ツールとの使い分けの考え方は、AIエージェント・チャットボット・RPAの違いで整理しています。AIによる読み取りは、こうした手段に乗らない取引先が長い裾野として残るという前提を吸収するための選択肢です。
この領域は、いきなり全取引先を対象にすると例外の山で止まります。次の順序が現実的だと考えます。
この順序の背景にあるのは、読み取りの精度を上げることよりも、読み違いが起きたときに人が気づける状態を先に作るという考え方です。
取引先ごとの書式が固定で、ファイルの受け渡しの型が決まっているなら、Excelの関数やマクロで十分に対応できる場合があります。難しくなるのは、取引先ごとに列の並びや品番の書き方が違い、しかもPDFやメール本文といった表になっていない形式が混ざるときです。差分の計算そのものではなく、比較できる形に揃える手前の工程に手作業が残っているかどうかが判断の分かれ目だと考えます。
必要ないと考えます。EDIで受け取れているデータは既に構造化されているため、読み取りの工程自体が存在しません。EDI取引で手作業が残るとすれば、取引先の品番と社内品番の読み替えや、単位・荷姿の換算といったマスタ側の課題であることが多く、そちらはAIによる読み取りではなくマスタ整備と取込処理の問題です。ただしWeb-EDIで、注文が画面表示や注文書PDFの形でしか受け取れず人が転記している場合は、読み取りの対象になり得ます。
注文番号と改訂番号が注文書の中に記載されているなら、それを抽出して既存の受注と突き合わせることで、新規か差し替えかを判定できる可能性があります。ただし改訂番号が記載されていない書式もあり、その場合は取引先と受領時刻と品番構成の組み合わせで類似を検知し、疑わしいものは自動登録せず人の確認に回す設計が現実的です。完全に防げると考えるべきではありません。
全件を無条件に自動登録することは推奨しにくいと考えます。受注の誤りは相手の生産計画に影響し、取り消しが効きにくい性質があります。品番マスタと一致し、過去の受注パターンと矛盾せず、数量や納期が想定の範囲内に収まっているものに限って自動候補とし、それ以外は差分を提示して人が確定する順序が安全だと考えられます。
特急を受けるかどうかは、現在の生産負荷、材料の在庫、他の得意先への影響、その取引先との関係といった要素が絡む経営判断に近い領域です。AIが担えるのは、特急依頼が来たことを見落とさずに検知し、関連する受注残や工程の状況を並べて提示するところまでで、受諾の判断と取引先への回答は人が行う範囲として残すべきだと考えます。
自動化率をお約束する前に、実際に届いている取引先ごとの注文書PDF・Excel・FAXの現物を読ませ、どこが自動候補になり、どこが確認行きになるかを一緒に見るところから始められます。EDI化を先に進めた方がよい取引先があれば、そのように申し上げます。
受注取込の自動化について相談する