注文書PDFの入力を減らすには、文字を読み取るだけでなく、自社の商品コードに結び付け、曖昧な明細を確認してからExcelに出力する流れが必要です。取引先ごとの呼び方や数量の単位に合わせた処理まで含めて、開発する範囲を決めましょう。

この記事では、注文書の転記と商品照合に時間がかかっている経営者・業務責任者に向けて、個別開発が向く条件、用意するデータ、誤りを止める確認手順、PoCの成功条件を整理します。PoCとは、本格導入の前に小さく作って、実際の業務で役立つか確かめる取り組みです。

注文書PDFの読み取りと商品マスター照合で行うこと

読み取りは、原本の文字と明細を取り出す工程

OCRは、画像になっている文字をデータにする技術です。注文書では、商品名、品番、数量、単位、希望納期などを読み取り、どの商品と数量が同じ行にあるかも整理します。文字情報を含むPDFなら、埋め込まれたテキストを利用できる場合もあります。[1]

たとえば品番が読めていても、数量を隣の行から拾えば注文内容は変わってしまいます。文字単位の正しさに加え、明細の行数、ページをまたぐ行、備考との対応まで確認する必要があります。

商品照合は、自社で扱う商品を特定する工程

商品マスターは、自社の商品コード、正式名、規格、販売単位などをまとめた一覧です。注文書の呼び方を、この一覧のどの商品に対応させるか決めるのが商品照合です。

文字が正しく読めても、「青テープ」が幅や長さの違う複数の商品を指すなら、一つには決まりません。得意先の品番、規格、入数などを組み合わせて絞り込みます。商品マスターにない品物を、名前の近い別の商品で埋めない設計が重要です。

既製のOCRで足りる場合と個別開発が向く場合

既製のOCR製品にも、マスターを参照してコードを補完したり、不一致を表示したりする機能があります。[2] 「商品照合があるから個別開発が必要」とは限りません。実際の注文書と出力先を使って、既存機能でどこまで対応できるかを先に確認します。

既製品の設定で足りる可能性があるのは、帳票の種類が限られ、商品コードが記載され、既存の出力形式をそのまま使える場合です。CSVや受発注システムから元データを受け取れるなら、PDFを読む工程自体を減らせないかも検討しましょう。

個別開発が候補になるのは、次のような条件です。

  • 同じ商品でも、得意先ごとに品番や略称が違う
  • ケース・箱・個の換算に、自社の商品別ルールがある
  • 複数候補を原本と並べて確認する画面が必要
  • 既存のExcel帳票の列やシート、確認手順に合わせたい

一方、処理件数が少なく確認の手間も小さい、商品マスターが未整備で担当者も正解を決められない、原本が人にも読めない、といった状態では、開発を急がない方がよい場合があります。入力様式やマスターの整備を先に行う方が、効果を確かめやすくなります。

商品マスター照合を含む開発前に用意するデータ

注文書と、担当者が確定した正解

注文書は、普段のきれいな帳票だけを集めないようにします。取引先別の書式、スキャン、手書き修正、薄い文字、複数ページ、取消や再送など、現場で起きている例を含めます。

それぞれに、担当者が確定した商品コード・数量・単位・希望納期を対応させます。原本にも答えがない項目は、推測で正解を作らず「取引先への確認が必要」と残してください。調整に使うデータと、最終評価用のデータは分けておきます。

商品マスターと、得意先ごとの対応表

最低限確認したい項目は、自社商品コード、正式名、規格、販売単位、入数、取扱終了の状態です。必要に応じて、得意先コード、得意先品番、承認済みの別名、適用開始日も用意します。

対応表は「得意先Aの品番Xは自社商品Y」という関係を持たせます。同じ品番が別の得意先では違う商品を指す場合があるため、品番だけで照合するか、得意先と組み合わせるかを決めます。入数が時期によって変わる場合は、いつのルールで処理したかも追えるようにします。

使い続けたいExcelの完成例

列名だけでなく、実際に使いたいExcelファイルの完成例を一つ用意します。商品コードの先頭ゼロ、日付の形式、空欄の扱い、シート名、数式を残すセルまで確認します。

「一行に一明細」「注文単位で別ファイル」などの出力単位も決めましょう。既存の集計や取り込みが動くことまでが、出力の確認範囲です。

最初の相談では、帳票の種類や困っている点の説明から始められます。実データを渡す前に、秘密保持、利用する外部サービス、送信する情報、閲覧権限、保存期間と削除方法を確認してください。

曖昧な商品や数量を人が確認できる処理にする

自動で候補にする条件を決める

まず、得意先と品番の一致、承認済みの別名対応、規格の一致など、根拠のはっきりしたルールを使います。表記の似ている商品をAIで探す場合も、規格・単位・取扱状態を確認し、条件を満たさない候補は保留にします。

OCRの信頼度は、読み取り結果を確認に回すための一つの手がかりです。Microsoftの公式資料でも、人による確認を組み込む考え方が示されています。[3] ただし、文字を読めた確からしさだけでは、別名や規格を含む商品特定の正しさは判断できません。

「候補なし」「候補が複数」「規格が食い違う」「数量・単位が不明」「マスター未登録」は、確認対象にします。信頼度のしきい値も、実データで誤り方を確かめてから決めます。

仮の明細で、照合と単位換算を確認する

架空の注文書に「青テープ 24mm、2箱」とある場面を考えます。これは設計を具体化するための仮例です。

商品マスターに幅24mmの商品があっても、長さが10mと20mの二種類なら、幅だけでは選べません。原本や承認済みの得意先対応表で長さを確定できなければ、二つの候補と不足情報を表示します。

商品と販売条件が確定し、その商品の「1箱=10個」が確認できた場合に限り、2箱を20個に換算します。出力には元の数量・単位と換算後の値を残します。入数が空欄なら、ほかの商品と同じと推測せず保留にします。

確認画面には、原本と判断の根拠を残す

担当者が確認する画面では、原本の該当箇所、読み取った値、商品候補、確認が必要な理由を並べます。「要確認」だけでは、毎回最初から商品を探す作業が残ってしまいます。

修正後は、誰が何を変えたかを記録します。今回の修正をすぐ全取引先のルールにせず、対応表への登録は管理担当者が確認します。仮の対応や一回限りの特例が、その後の誤照合につながらないようにするためです。

PoCの初期は、出力前に担当者が全明細を確認する方法も選べます。確認対象だけを見る運用へ移すかは、見逃した誤りを含む検証結果と、誤出荷の影響を見て判断します。

Excel出力で二重登録や未確認データの混入を防ぐ

出力前に、読み取った明細数と確定・保留の件数が一致するかを確認します。保留行を黙って落としたり、空欄をゼロで埋めたりしないようにします。

最初は、未確認の明細が残る注文を確定用Excelに出さない運用が分かりやすいでしょう。部分出力が必要なら、未処理の明細が分かる一覧と、後から残りを処理する手順を別途決めます。

同じPDFの再送や、内容が変わった改訂版も区別が必要です。得意先・注文番号・改訂情報などを使って重複候補を表示し、再出力する場合は担当者が確認します。希望納期は、納品を約束した日付と混同しない列名にしてください。

初回の範囲を「PDFの取り込みから、確認済みExcelの出力まで」にすると、検証を切り分けやすくなります。基幹システムへの自動登録、在庫引当、受注可否の判断は、連携方法と責任範囲を決めてから検討します。

PoCの成功条件は読み取り精度だけで決めない

検証では、注文書一枚単位と明細一行単位の両方を見ます。件数と割合を併記し、取引先や帳票の種類で結果を分けると、使える範囲を判断しやすくなります。

  • 読み取り:商品名・数量・単位・希望納期など、項目別の正解数
  • 商品照合:自動で候補確定した明細のうち、正しい商品だった件数
  • 見逃し:本来は保留すべきなのに、確認なしで通った明細の件数と内容
  • 確認負担:保留の割合、原本確認・修正・出力まで含む作業時間
  • 出力:行の欠落、重複、先頭ゼロの消失、既存Excelでの利用可否

候補をすべて保留にすれば誤った自動確定を減らせても、現場の作業は残ります。誤照合の少なさと、確認に必要な時間を一緒に評価してください。平均時間に加え、処理が長引いた注文と原因も記録します。

続ける条件は、合意した品質と確認負担を満たし、担当者が通常業務で運用できることです。原因を絞れる誤りは修正して再検証し、重大な誤照合を止められない、確認がかえって増える、正解データを用意できない場合は、対象を縮めるか中止を検討します。

検証で誤りがゼロでも、今後の無誤りは保証できません。新しい帳票や商品が増えたときに再確認する手順まで決めておきましょう。検証目標と、契約上の納品・検収条件は分けて合意します。

注文書自動化の開発費と運用費で確認すること

費用を左右するのは、帳票の種類と状態、商品マスターの整備量、単位換算の複雑さ、確認画面、Excelの形式、外部システム連携などです。「PDFをExcel化する一式」ではなく、どの機能とデータ整備が含まれるかを見積りで確認します。

運用費は、OCR・AIの利用料、保存先やサーバーの費用、保守、マスター更新、帳票変更への対応に分けて考えます。ページ数や処理回数が増えたときの費用、再処理分、利用上限も相談事項です。商品マスターを誰が更新し、エラー時にどの手順へ戻るかを決めておく必要があります。

AiPHAの現行PoC開発サービスは、一つの業務を対象とした開発・検証を20万円から、10日での納品と案内しています。金額は対象業務と開発範囲に応じた見積りで、AIサービス利用料などの別途費用は事前にご案内します。この記事で挙げた機能がすべて基本料金に含まれるという意味ではありません。対象範囲、納期の前提、継続保守の内容と費用を相談時に確認します。[4]

注文書PDFからExcel出力までの個別開発を相談する

最初の相談では、「月のおおよその件数」「主な帳票の種類」「商品マスターの有無」「使いたいExcel」「いま人が迷う箇所」を分かる範囲でお知らせください。開発内容が固まっていなくても、既製品で足りる部分と、個別の対応が必要な部分を整理できます。

発注前の整理をまとめたい方は、AIのPoC開発を外注する前に決める7項目もご覧ください。

注文書の商品照合・Excel出力の開発を相談する(無料30分)

参考資料

  1. Google Cloud「Enterprise Document OCR」
  2. パナソニック デジタル「WisOCRシリーズ マスター機能の設定方法」
  3. Microsoft Learn「Interpret and improve accuracy and confidence scores」
  4. AiPHA PoC開発サービス