FAXやPDFで届く注文書を読み取って受注データを作る

処理の起点を決める

SharePointの受領フォルダにファイルが作成されたことを起点にします。Power Automate の SharePoint コネクタには「ファイルが作成されたとき」トリガーが標準で用意されています。

FAX受信サーバが共有フォルダにPDFを出力する運用であれば、その出力先をSharePointに向けるか、オンプレミスデータゲートウェイ経由でファイルシステムを監視します。

メール添付は、Office 365 Outlook コネクタの「新しいメールが届いたとき（V3）」トリガーと組み合わせます。このトリガーは、Exchange 管理者が設定した上限（または50MB）を超えるメールを飛ばす仕様なので、大きな添付が来る運用では上限の確認が必要です。 また、注文以外の添付ファイルも大量に届くため、専用のメールアドレス（order@ 等）を用意し、取引先にそこへ送ってもらうのがもっとも確実です。

注意すべきなのは、このトリガーが「ポーリング」であることです。 到着した瞬間に発火するわけではなく、契約プランに応じた間隔で受信箱を見に行きます。締め時間の直前に届いた注文が、締めに間に合わないことがあります。締め時間の5分前からは手動実行できる導線を残してください。

入力データを集める

このうち、いちばん効く入力データは「受注実績」です。 過去にその得意先が「VP13×4m」と書いたときに何番で登録したかが分かれば、候補付けの精度は大きく変わります。新しく作るデータではなく、すでに販売管理システムの中にあります。

データの取得方法を決める

OCR： Azure AI Document Intelligence にPDFを渡します。ここは2段構えにします。

1. カスタム分類モデルで、まず書類の種別と得意先のレイアウトを判定します。分類モデルの学習には、クラスごとに最低5件、クラスは2つ以上が必要です。「A社様式」「B社様式」「手書き伝票」「注文書以外」といった分け方をします。
2. 判定された種別に応じて、カスタム抽出モデル（得意先の様式が固定しているもの）または prebuilt-layout（様式が定まらないもの）で読み取ります。カスタム抽出モデルは、同じ様式の書類が5件あれば学習を始められます。

複数のカスタムモデルは合成モデル（composed model）にまとめられ、1つのモデルIDで呼び出せます。1つの合成モデルには最大200個のカスタムモデルを割り当てられるため、上位200様式までは個別に学習させる設計が取れます。

prebuilt-layout は、表・選択マーク・見出しなどの構造を取り出します。明細が表になっている注文書では、この表構造がそのまま明細行になります。

マスタ類： 販売管理システムのAPI、または日次でエクスポートしたファイルを参照します。リアルタイム連携が要るのは在庫だけです。

受注実績： 「得意先コード × 注文書の記載文字列 × 登録した品番」の組み合わせを集計したテーブルを作ります。月1回の更新で足ります。

AIへ渡す前に整形する

1. 複数注文の分割 … 1つのPDFに複数の注文書が入っていることがあります。分類モデルの結果がページごとに変わる箇所で分割します
2. 向きの補正と画質の判定 … FAXは上下逆・横向きで届くことがあります。あわせて解像度を見て、低すぎるものは先に人へ回します。入力要件として、抽出する文字の高さは1024×768の画像で12ピクセル以上が目安とされています（150dpiの8ポイント相当）。これを下回るFAXは、無理に読ませず手入力にします
3. 重複の検出 … 同じ注文書が再送されることがあります。「得意先コード＋注文番号＋合計数量」で既存の受注と照合し、重複なら処理を止めます。これを入れないと二重出荷が起きます
4. 注文書以外の除外 … 見積依頼、納品書の控え、請求書が混ざります。分類モデルで振り分け、別フォルダへ移します
5. 文字の正規化 … 全角と半角、カナと漢字、「×」と「x」、ハイフンの種類をそろえます。品名の突き合わせは、この正規化をしないと当たりません

AIに処理させる

OCRとLLMで役割を分けます。

OCR（Document Intelligence）にさせること： 文字と項目の読み取り、明細表の行の切り出し、数量・納期・単価の抽出。ここはLLMにさせません。座標付きで返るため、確認画面でのハイライト表示に使えます。

LLMにさせること：

単位の扱いは明示的に処理します。 「塩ビ管 13 100」が100本なのか100mなのかで、出荷量が4倍変わります。単位が書かれていないときは推測させず、過去実績の単位を候補として示し、確信度を下げます。

指示内容を固定する

あなたは建築資材商社の受注センターを支援する担当者です。
OCRで抽出された注文書の内容と、得意先マスタ・商品マスタ・過去の受注実績を
もとに、受注登録の候補を作ってください。

【厳守事項】
- 数量、希望納期、注文番号を書き換えないでください。
  OCRの抽出結果をそのまま引き継いでください。
- 品番は、商品マスタに存在するものからのみ選んでください。
  マスタにない品番を作らないでください。
- 候補が1つに絞れない場合は、最大3つまで candidates に並べ、
  それぞれに根拠（過去実績の受注番号、または商品マスタの品名）を付けてください。
- 単位が注文書に明記されていない場合は、推測せず unit を null にし、
  needs_review に「単位の記載なし」と入れてください。
- 「前回と同じ」のような記載は、過去実績に該当が1件だけ見つかる場合に限って
  その品番を候補にしてください。複数ある場合は人に回してください。
- 数量が、その得意先のその品番の過去12か月の最大値を超える場合は
  warnings に入れてください。処理は止めないでください。
- 備考欄の出荷条件（直送、時間指定、事前連絡など）は、
  要約せずそのまま remarks に転記してください。

【OCR抽出結果】
{ocr_result}

【送信元の情報】
FAX番号: {fax_number} / 送信元メールアドレス: {from_address}

【得意先マスタの候補（名称の近い上位5件）】
{customer_candidates}

【この得意先の過去の受注実績（注文書の記載文字列 → 登録品番、直近24か月）】
{past_orders}

【商品マスタの候補（品名・規格の近い上位20件）】
{item_candidates}

「マスタにない品番を作らないでください」の1行が重要です。 これを書かないと、それらしい体裁の存在しない品番が返ります。存在しない品番は登録時にエラーになるので発見はできますが、確認画面で担当者が一度信じてしまう分、時間を損します。

「備考欄は要約せずそのまま転記」も外せません。 「午前中着」を「納期指定あり」に要約されると、出荷指示に載りません。

出力形式を固定する

{
  "document_type": "order | quotation_request | other",
  "customer_code": "",
  "customer_name_matched": "",
  "customer_match_basis": "",
  "order_no": "",
  "order_date": "",
  "requested_delivery_date": "",
  "line_items": [
    {
      "printed_text": "",
      "candidates": [
        { "item_code": "", "item_name": "", "basis": "", "confidence": "high | medium | low" }
      ],
      "quantity": 0,
      "unit": "",
      "unit_price": 0,
      "price_check": "matched | mismatched | no_contract",
      "stock_status": "available | shortage | not_found"
    }
  ],
  "remarks": "",
  "duplicate_check": "ok | duplicate",
  "warnings": [],
  "needs_review": []
}

数量と単価は文字列でなく数値で返させます。文字列にすると「1,200」のようにカンマ入りで返り、後段の計算で壊れます。

printed_text（注文書に実際に書かれていた文字列）を必ず残します。これがないと、確認画面で「なぜこの品番になったのか」を担当者が追えません。 また、この文字列と最終的に承認された品番の組み合わせが、翌月以降の受注実績データそのものになります。

なお、Claude API には出力をJSONスキーマに沿わせる構造化出力の機能があります（2026-09-14時点ではベータ機能として提供）。利用できる場合は、スキーマを渡して形の崩れを防げます。

システムへ連携する

承認後、販売管理システムへ受注を登録します。連携方法は3通りあります。

国産の販売管理システムでは、受注のCSV取込機能が用意されていることが多く、まずそこを確認してください。 APIの有無と仕様は、自社の販売管理システムのベンダーに確認が必要です。この部分は利用環境に応じた個別確認になります。

注文請書の返信は、承認後に定型のPDFを生成し、注文書が届いた経路（FAXならFAX、メールならメール）へ返します。返信経路を1本に統一しないでください。 取引先の運用を変えることになり、導入の障害になります。

人が確認する

全件、人が承認します。 受注は出荷と請求の起点で、誤りがそのまま現場に届くためです。この構成で減らしているのは「読んで探して打ち込む時間」であって、「確認の責任」ではありません。

ただし、確認の重さは段階を分けます。

確認を速くするための設計が重要です。

• 確認画面で、PDFの原本と抽出結果を左右に並べて表示する
• OCRが抽出した箇所を、PDF上でハイライトする（座標が返るので実装できます）
• 締め時間までの残りと、未処理の件数を常に表示する

これらがないと、確認に6分かかり、削減効果が出ません。

例外に対処する

記録を残す

• 注文書PDFの原本（受注番号と結び付ける）
• OCRの抽出結果（生の状態。座標を含む）
• LLMが付けた候補と confidence、その根拠
• 承認者、承認日時
• 人が修正した項目と、修正前後の値

最後の項目が二重に効きます。ひとつは精度の実測値になること。もうひとつは、「注文書の記載文字列 → 正しい品番」という対応表が自動で貯まることです。これが翌月以降の候補付けの材料になり、使うほど精度が上がる形になります。