INSIGHT ／ 受注・注文書AI
注文書をAIで読ませるだけでは、受注業務は自動化できない理由
PDFやFAXで届いた注文書から、品番・数量・単価・希望納期を読み取ること自体は、AI-OCRや生成AIによってかなり現実的になりました。読み取りの実演を見て、これで受注入力の仕事は無くなると感じた方も多いはずです。
ところが、実際に受注業務のしくみを作ってみると、「読めた」だけでは仕事は終わりません。そのあとには、この商品で本当に合っているか、この単価で受けてよいか、この納期で回答できるか、足りない情報は誰に聞くのか。そういう仕事が残ります。ここを設計しないまま読み取りだけを速くすると、人の作業は消えず、形を変えて残ります。
この記事では、業務判断支援AIを実装する中で分かった「AI-OCRの次に設計すべきこと」を整理します。特定の製品を選ぶ話ではなく、受注業務のどこを機械に任せ、どこを人に残すかを決めるための材料として読んでいただければと思います。
ここで紹介する仕組みは、YURAIの実装として動かし、デモ環境で検証したものです。特定のお客様の本番業務での稼働実績を示すものではありません。できないこととまだ自動化していないことは、記事の後半にまとめてあります。
注文書を読むのは、受注業務の入口にすぎない
受注業務を「注文書の内容をシステムに入れる作業」と一言で言うと、読み取りが自動化されれば全部終わるように見えます。しかし工程に分けてみると、読み取りは最初のひとつでしかありません。
受け取る
- 01注文書が届く（PDF・FAX・メール添付・紙）
AIが読む ── AI-OCRが担うのはここまで
- 02文字を読み取る
- 03項目として組み立てる
御社の基準で確かめる
- 04取引先と商品を特定する
- 05単価・納期・取引条件と照らす
- 06不足と差異を洗い出す
人が決める
- 07確認が必要なものだけを判断する
- 08登録内容を確定する
読み取りが担うのは02と03です。04以降は、注文書の中だけを見ていても答えが出ません。御社の商品マスタ、取引先ごとの単価、標準納期、承認の決まりごとと突き合わせてはじめて判断できる領域です。ここは読み取りの精度をいくら上げても、自動的には片づきません。
読み取った後に残る、本当の受注業務
04以降を具体的に書き出すと、受注担当者が実際にやっていることが見えてきます。注文書を受け取って受注登録までを人がやっている業務では、だいたい次のような確認が並びます。
- 商品の特定 注文書の品名や略称が、自社のどの商品コードに当たるのか
- 取引先の特定 同じ会社名でも、支店・部署・請求先が別々に登録されていないか
- 数量と単位の整理 「1ケース」「10枚入り」、「m」と「本」のような単位の読み替え
- 単価の確認 前回の取引と単価が違わないか。違うなら理由があるのか
- 納期の確認 希望納期が標準の納期に収まっているか。収まらないなら誰の判断が要るのか
- 必須情報の不足確認 発注日や納入先など、登録に必要な項目が空欄になっていないか
- 例外の切り分け 訂正注文・取消・特別条件つきの注文を、通常の注文と混ぜない
- 登録内容の組み立て 基幹システムに入れる形へ整え、根拠を残す
重要なのは、この8つのほとんどが読み取りの正確さとは別の問題だという点です。品名が一文字も間違いなく読み取れていても、その品名がどの商品コードを指すのかは、自社のマスタを見なければ決まりません。単価が正しく読めていても、それが受けてよい単価かどうかは、過去の取引を見なければ分かりません。
この記事でいちばん言いたいこと
「読めること」と「業務が終わること」は違います。受注業務の自動化とは、読み取りの自動化ではなく、読んだ後に何を確かめ、どこから人へ戻し、どの状態を完了とするかの設計です。
商品マスタの突合を、生成AIだけに任せない
読み取りの次にいちばん最初に来るのが、商品の特定です。そして、ここが生成AIをそのまま使うと、いちばん危ない場所でもあります。
生成AIは、書かれている文章を読んで項目に整える仕事には向いています。表記の揺れ、全角と半角、改行の混ざった住所欄なども、うまく吸収してくれます。しかし「この表記はどの商品コードか」を自由回答で答えさせると、性質の違う失敗が出ることがあります。答えが見つからないときに、もっともらしい別の商品を選んでしまうことがあるのです。私たちの実装でも、そこを決定的な処理へ出すまでは同じ失敗の形が残っていました。
やりにくいのは、その答えが文章として自然なところです。似た名前の商品、厚みだけが違う商品、取り扱いを終えた旧品番は、文字列としてはよく似ています。自然な答えが返ってくるぶん、人が読んでも間違いに気づきにくくなります。読み取りの誤字とは違って、確認の網をすり抜けやすい種類の誤りです。
そこでYURAIの実装では、商品の突合をAIの外に出しました。商品コードの一致、表記を整えたうえでの照合、候補の絞り込みは、同じ入力に対して必ず同じ結果を返す決定的な処理として書いています。AIに任せるのは「注文書に何が書かれているか」を読むところまでで、「それが自社のどの商品か」を決めるのはマスタと処理の側です。
この分け方には、精度以外の利点もあります。決定的な処理なら、なぜその商品になったのかを後から説明できます。受注は取引の入口なので、あとで「なぜこの商品で受けたのか」をたどれること自体に価値があります。
「分からない」を、正しい答えとして持たせる
突合を決定的な処理にしても、それだけでは足りません。絞り込めなかったときに何を返すかを決めておく必要があります。
開発の途中で分かったことがあります。部分的にしか一致していない品名を強く信用して1件に絞り込むと、誤った特定が起こり得るのです。たとえば材質と厚みだけが書かれた短い品名は、複数の商品に等しく当てはまります。それでも「最も点数の高い候補」を機械的に選ぶ作りにしていると、取り扱いを終えた商品を選んでしまうことがあります。
そこで方針を変えました。一致の度合いだけで一意に特定せず、次に近い候補との差も見る。どちらも十分でないときは、無理に1件へ決めない。候補を並べたまま人へ返す。誤って1件に決めるより、分からないものを分からないまま渡すほうが、業務としては安全だからです。
注文書の品名欄に、材質と厚みしか書かれていない
- 候補A同じ材質・同じ厚み・仕上げが違う
- 候補B同じ材質・厚みが違う
- 候補C旧品番（取り扱い終了）
YURAI
この明細は一意に特定できません
- 候補が3件。どれも同じくらい当てはまる
- 候補Cは取り扱いを終えた品番
候補と、そう判断した理由を添えて返す
決定は人が行います
「AIなのに決めてくれないのか」と思われるかもしれません。しかし受注の現場で困るのは、答えが出ないことよりも、間違った答えが自信ありげに出てくることです。絞り込めないという状態を正しい出力として持たせておくと、人が見る場所が「全部」から「確認が必要なものだけ」に変わります。
確信度の数字だけを信用しない
読み取りの結果には、項目ごとの確信度が付いてくることがあります。便利な数字ですが、扱いには注意が必要です。
ここで区別が必要です。OCRエンジンが返す認識スコアは、その文字をどれだけ確からしく読めたかを示す値です。一方、生成AIに項目ごとの確信度を出させた場合、それはAI自身の申告であって、統計的に校正された「この値が正しい確率」とは限りません。どちらであっても、その項目が業務上正しいことの保証にはなりません。読めた文字が正しくても、それが受けてよい単価かどうかは別の話だからです。だからデモの画面では、この数字がAIの自己申告であることを明示しています。
したがって、確信度が高いから自動で確定する、という作りにはしていません。自動で先へ進めてよいかどうかは、マスタと照合できたか、必須項目が埋まっているか、単価や納期が過去の条件と合っているかという、検証できる事実の側で決めます。確信度は、人が確認するときの見どころを示す補助情報として使います。
設計の原則
自動で進めるかどうかの判断は、AIの自己評価ではなく、検証できる事実に置く。AIの申告値は、人の目を向ける先を示すために使う。
自動化するほど、人の役割を先に決める
自動化の設計というと、機械に任せる範囲を広げる話だと思われがちです。実際にやってみると逆で、人が見るものを先に決めるほど、機械側を素直に作れます。
受注業務で人に残すべきものは、だいたい次のように整理できます。
- 商品を一意に特定できなかったもの
- 単価が過去の取引と違うもの
- 希望納期が標準の納期に収まらないもの
- 登録に必要な情報が欠けているもの
- 特別な条件がついているもの、訂正や取消の注文
- 金額や数量が大きく、承認が必要なもの
先頭の1つは機械が特定できなかったものですが、残りは機械が計算できても人に残します。取引の条件が変わる可能性がある場所だから人が見るのです。目的は人をなくすことではなく、全部を読む仕事から、確認が必要なものだけを見る仕事へ変えることです。
この線引きを先に決めておくと、機械側の作りも決まります。機械は「人へ回す理由」を作れなければならないので、判断の材料を必ず添えて出す形になります。逆に線引きを決めないまま作ると、なんとなく自動で通ったものと、なんとなく止まったものが混ざり、結局すべてを人が見直すことになります。
YURAIでは、受注業務をどう分けているか
ここまでの話を、YURAIの役割分担として整理します。YURAIはこの4段で動きます。AIが読み、御社の基準で確かめ、判断材料を出し、人が決める。受注業務に当てはめると、それぞれの中身は次のようになります。
| 段 | 受注業務での中身 |
|---|---|
| 01 ／ READAIが読む | 注文書に書かれている項目を読み取り、日付や金額の書き方を整える。書かれていないことは補わない |
| 02 ／ RULE御社の基準で確かめる | 商品マスタ・取引先・前回の単価・標準納期と突き合わせ、事実として一致・不一致・不足を出す。そのうえで、そのまま進めてよいのか、誰の確認が必要なのかをルールが決める |
| 03 ／ OPTIONS判断材料を出す | 確認事項を、根拠と候補を添えて並べる。絞り込めなかったものは絞り込めないまま出す |
| 04 ／ HUMAN人が決める | 材料を見て、内容を直し、登録内容を確定する |
この分け方の効き目は、AIが賢くなっても人の確認が消えないところにあります。読み取りの品質が上がれば、機械が確かめられる範囲は広がります。しかし「単価が違う」「納期が合わない」「承認が必要」は、読み取りの品質とは関係なく発生します。だから確認の口は残しておく。これが「御社の基準で動く」の中身です。
なお、この分け方は受注のために考えたものではありません。図面の検図や文書の審査でも、私たちは同じ4段で組んでいます。分け方が業務ごとに変わらないのは、業務の性質ではなく、AIに任せられることの性質に沿って分けているからです。
まだ自動化しないもの
最後に、できることと同じくらい大事な、できないことを書いておきます。ここまで説明した内容はYURAIの実装として動かし、デモ環境で検証したものです。特定のお客様の本番業務での稼働実績を示すものではありません。
いま自動化しないと決めていること
基幹システムへの書き込みは自動で行いません。自動でできるのは、受注入力の下書きの作成、事前の確認、取込用データの出力までです。基幹への取り込みは人が行います。連携が必要な場合は個別の設計になります。
曖昧な商品は人が確定します。候補を絞り込めないものを機械が決めてしまわないことが、この設計の目的です。
AIの自己申告値だけでは自動確定しません。進めてよいかどうかは、検証できる事実の側で判断します。
御社のマスタと承認の決まりごとの整理が必要です。どの単価差なら通してよいか、どの金額から承認が要るかは会社ごとに違います。そこが決まっていない状態で自動化を進めると、基準のないまま動くしくみができます。
仕様や法令の適否そのものは判断しません。規格や認定の要否といった専門的な確認は、御社の基準を預かってから設計する領域です。
まとめ：「読める」の次を設計する
AI-OCRや生成AIによる読み取りは、受注業務を変えるための重要な部品です。しかし部品だけでは業務は変わりません。読み取りの精度を上げることと、受注業務が終わることは、別の問題です。
受注業務を変えるために設計すべきなのは、読んだ後に何を確かめ、どこから人へ戻し、どの状態を業務完了とするかです。商品を一意に特定できないときにどう振る舞うか。単価や納期が過去の条件と違ったときに、誰の判断を求めるか。自動で進めてよい根拠を、どこに置くか。
この線引きは、扱う商品や取引の慣習、承認の決まりごとによって会社ごとに変わります。だからこそ、AIに業務を合わせるのではなく、業務にAIを合わせる必要があるのだと考えています。