「取引先にFAXをやめてもらう」が通らない力関係のなかで、受注入力だけをどう軽くするか。書式が揃わない・手書きが混じる・画質が悪いという三重苦を、レイアウト依存の定型OCRとレイアウト非依存のVLM-OCRに分けて考えます。読取率を約束する前に、まず何を検証すべきかを整理します。
FAX受注の入力業務が残る最大の理由は、受注側の努力だけでは発注側の運用を変えられないという力関係にあると考えられます。EDIやWeb発注に一本化したい受注担当者は多いはずですが、長年FAXで発注してきた取引先に「明日から様式を変えてください」と求めるのは、こちらが立場の弱い受発注関係では現実に通りにくいものです。結果として、届いたFAXを人が目で読み、基幹システムへ手入力するという工程が今も回り続けています。
この工程は、単純な人手作業でありながら止められない業務です。受注の締切に追われる時間帯に大量の注文書が集中し、担当者が一枚ずつ品番・数量・納期・届け先を転記します。慢性的な人手不足のなかで、この転記に熟練者の時間が奪われ、しかも入力ミスが出れば誤出荷や欠品に直結します。属人化しやすく、担当者が休むと受注が滞るという脆さも抱えています。
「紙をやめる」という上流の解決が最良である点は論を俟ちません。ただ現実には、取引先の都合・業界慣習・監督官庁への提出様式など、受注側では動かせない事情でFAXや紙が残り続けます。だとすれば、発注の形を変える交渉と並行して、受注側だけで完結する入力の自動化を進めておくことが、当面の負荷を下げる合理的な打ち手になりうると考えます。この記事では後者、つまり届いてしまったFAXをどう軽く処理するかに絞って整理します。
従来型OCRがFAX注文書でつまずいてきた根本原因は、「決まった位置に決まった項目が来る」ことを前提に設計されているからだと考えられます。OCR（光学的文字認識）とは、画像中の文字を機械可読なテキストに変換する技術の総称です。多くの定型OCRは、事前に「この座標に品番、この枠に数量」というテンプレートを定義し、その位置から文字を切り出します。ところがFAX受注の現場は、この前提がことごとく崩れる場所です。
取引先が10社あれば注文書のレイアウトは10種類あり、項目名も「品番／商品コード／型式」とまちまちです。定型OCRでこれに対応するには帳票ごとにテンプレートを作り込む必要があり、取引先が増減したり先方が様式を微修正したりするたびに保守が発生します。レイアウト変動への対応が構造的に弱いことが、多品種・少量の受注現場で定型OCRが続かない主因の一つだと考えます。
印字された注文書に、数量だけ手書きで直す、余白に「至急」と書き足す、二重線で消して書き換えるといった訂正は日常的に入ります。活字前提のOCRは手書きの崩し字や訂正線に弱く、どこが最終的な値なのかという判断は文字認識だけでは決まりません。手書き帳票のOCRがどこまで読めるかは、その帳票の書き手の癖や訂正の入り方に強く依存すると考えられます。
FAXは送受信の過程で解像度が落ち、かすれ・つぶれ・傾き・黒スジ・部分的な欠けが入ります。同じ原本でも送信機と受信機の組み合わせで画質が変わり、細い罫線と文字が潰れて混ざることもあります。人間なら文脈で補って読めますが、一文字ずつ確信度で切り出す方式にとっては、この低品質画像がそのまま誤認識の温床になりうると考えます。
VLM方式が定型OCRと決定的に違うのは、文字の位置ではなく「この画像は注文書で、ここに書かれているのは品番と数量だ」という意味と文脈から項目を読み取る点にあると考えられます。VLM（Vision Language Model／視覚言語モデル）とは、画像と言語を同時に扱い、画像の内容を文章で説明したり指定された情報を抽出したりできるAIモデルです。テンプレートで座標を教え込む代わりに、「品番・数量・納期・届け先を抜き出して」という指示で項目を取り出す発想に近いものです。
この性質は、書式が揃わないFAX注文書と相性が良い可能性があります。取引先ごとにレイアウトが違っても、項目名が「品番」でも「商品コード」でも、人間が見て理解できる注文書であれば、フォーマット定義を作り込まずに項目を拾える見込みがあるためです。書式が増減しても都度テンプレートを起こす保守が要らないことは、多品種の受注現場で効いてくると考えます。書式が揃わない帳票の読み取りについてはVLM-OCRの考え方が参考になります。
一方で、VLM方式なら何でも読めるわけではありません。FAXでつぶれた小さな数字や、判読に迷う手書きの崩し字は、文脈補完をもってしても一意に定まらないことがあります。むしろVLMは「もっともらしい値」を自然に埋めてしまう傾向があり、間違っていても自信ありげに出力しうる点は、定型OCRとは別種の注意を要します。読めない箇所を「読めない・自信がない」と正直に返させる設計と、その後の人の確認が、実運用では不可欠だと考えます。
整理すると、定型OCRが向くのは、取引先が固定で様式もほぼ変わらず、印字が中心で画質が安定している注文書です。逆にVLM方式が向くのは、取引先が多く様式がバラバラ、手書きや訂正が混じり、FAXで画質が劣化しているといった、まさに従来型が挫折してきた条件だと考えられます。両者は排他ではなく、安定した定型帳票は従来型、非定型はVLMと使い分ける構成も現実的です。
設計で最初に決めるべきは、読み取りの精度そのものより「間違いをどこで止めるか」だと考えられます。受注データは誤ると誤出荷・欠品・請求違算に直結するため、全件を無条件に自動投入する設計は危険です。項目ごとにモデルの確信度を持たせ、確信度が低いものだけ人の目に回す関門を置くことが、実務では出発点になります。
読み取り値を、自社が持つマスタと照合するとミスを大きく減らせる可能性があります。照合とは、読み取った品番や取引先名を、既存の商品マスタ・取引先マスタと突き合わせて存在するか・整合するかを検証する処理です。品番がマスタに無ければ誤読を疑う、数量が桁外れなら確認に回す、といった業務ルールを重ねることで、VLMが埋めてしまった「もっともらしい嘘」を機械的にふるいにかけられます。読み取りAI単体でなく、この照合の作り込みが実用性を左右すると考えます。
読み取れても、そこから基幹システムへ人が再入力していては工数は半分しか減りません。抽出した項目を確認画面を経て受注データとして流し込むところまでを一続きの動線として設計する必要があります。帳票OCRとシステム連携の観点で、既存の受注入力画面やAPIにどう接続するかを早めに握っておくと、後戻りが減ると考えられます。
取引先情報や単価を含む注文書を外部のクラウドに送りたくない、という要請は受注業務では珍しくありません。オンプレミス（自社内の設備で完結させる方式）やエッジ（現場の機器上でAIを動かす方式）でVLM-OCRを動かせれば、データを社外に出さずに処理できる可能性があります。Nsightは元キーエンス画像処理事業部の現場知見に、VLMとJetsonエッジ、産業用カメラ、現場ライティングを組み合わせる立場から、この閉域での運用も含めて設計を検討できると考えます。
現実的な運用の形は、全件自動ではなく「確信度の高いものは自動、低いものだけ人が確認する」という確認付き自動化から始めることだと考えられます。最初から100%無人化を狙うと、たった数%の誤りが誤出荷という重い事故になり、かえって信頼を失います。まずは人の負荷を「全件をゼロから入力する」から「AIの下書きを確認・訂正する」へ移すことを目標にするのが穏当です。
このとき鍵になるのが訂正作業の動線です。AIが読み取った値を、元のFAX画像と並べて表示し、疑わしい項目を強調し、キーボードから素早く直せる画面があるかどうかで、確認作業の速さが大きく変わります。訂正作業の動線設計を軽視すると、読み取り精度が高くても現場の体感工数が減らず、定着しないことがあると考えます。
訂正の記録は、次の改善の材料にもなります。どの取引先の・どの項目で・どんな間違いが多いかが蓄積されれば、その帳票だけ確認を厚くする、指示の出し方を調整するといった打ち手が取れます。運用は一度作って終わりではなく、間違いの傾向を見ながら関門の閾値や照合ルールを育てていく前提で考えるのが現実的だと考えられます。紙を構造化する入口としては帳票のデジタル化の発想も併せて参考になります。
最後に、正直に共有しておきたい落とし穴を挙げます。読取率を事前に約束できないのは技術の未熟さではなく、対象が自社に届く現物のFAXに強く依存するからです。次の点は、実際の帳票で検証してみないと分からない領域だと考えます。
始め方の結論は明快で、まず自社に実際に届いている注文書を数十枚そのまま読ませ、どこで間違うかを客観的に把握することだと考えられます。仕様書やサンプルではなく、かすれや手書き訂正を含む現物で試すことに意味があります。ここで得られるのは「読める・読めない」の二値ではなく、取引先別・項目別にどこが弱いかという地図です。
次の一歩は、その地図をもとに関門の位置を決めることです。確信度が高く照合も通る項目は自動、それ以外は確認へ、という線引きを実データで調整します。この段階では読取率の高さを競うより、「誤りを人手前で止め切れているか」を評価軸に置くのが安全だと考えます。小さく確認付きで回し、間違いの傾向を見て閾値と照合ルールを育てる——この順序が、事故を起こさずに工数を減らす現実的な道筋になりうると考えます。
Nsightは、元キーエンス画像処理事業部の現場知見を持つエンジニアが、VLM-OCRの読み取りから照合・確認画面・基幹連携までを一続きに検討する立場にあります。読取率を先に約束するのではなく、まず自社の現物FAXで何が読めて何が確認行きになるかを一緒に見るところから始めるのが、遠回りのようでいて確実だと考えます。
読み取れる可能性はありますが、書き手の癖・崩し方・訂正の入り方に強く依存します。印字部分に比べ手書きは一意に定まりにくく、VLM方式でも読めない箇所は確認に回す前提が現実的です。どこまで読めるかは自社に届く現物での検証が必要で、他社の数値がそのまま当てはまるとは限らないと考えられます。
レイアウトに依存しないVLM方式であれば、帳票ごとにテンプレートを作り込まずに項目を読み取れる可能性があります。定型OCRのように様式ごとの座標定義や、様式変更のたびの保守を避けられる点が利点と考えられます。ただし読み取り値をマスタと照合するなど、業務ルールの作り込みは別途必要になります。
対象帳票の種類・枚数、要求精度、基幹システム連携やオンプレミス要件の有無によって大きく変わるため、一律の金額は申し上げられません。まずは自社の現物FAXを数十枚読ませて、どこまで自動化できそうかを把握する小さな検証から始め、その結果をもとに費用対効果を見積もるのが現実的だと考えます。
全件を無条件で自動登録するのは推奨しにくいと考えます。受注データの誤りは誤出荷や欠品に直結するためです。確信度が低い項目やマスタ照合を通らない項目は人の確認に回す「確認付き自動化」から始め、間違いの傾向を見ながら自動化の範囲を広げていく順序が安全だと考えられます。
オンプレミスやエッジでVLM-OCRを動かす構成であれば、注文書データを社外に出さずに処理できる可能性があります。取引先情報や単価を含む帳票では有効な選択肢です。ネットワーク要件やセキュリティ方針は各社で異なるため、具体的な構成は自社の情報システム部門の基準と照らして検討することをおすすめします。
読取率をお約束する前に、実際に届いているかすれ・手書き・書式バラバラの現物を読ませ、どこが自動化でき・どこが確認行きになるかを一緒に見るところから始められます。元キーエンス画像処理事業部の知見を持つエンジニアが、読み取りから照合・基幹連携までを一続きに検討します。
FAX受注のOCR自動化について相談する