地元の加工業者・工事業者からFAXで届く手書きの見積書を読み取って見積比較表にそろえ、合計の計算違いと見積条件の抜けを購買担当へ返す

処理の起点を決める

受信用の保管場所にPDFが置かれたことを起点にします。 インターネットFAXの多くは、受信したFAXをPDFにしてメールに添付して転送します。共有メールボックスに届いた添付ファイルを保管場所に移すところまでは、メールの振り分けの機能か、小さなプログラムで行います。

1日1回のまとめ処理にはしません。 急ぎの修繕の見積は、届いた当日に比較表がほしいものです。届くたびに1枚ずつ処理します。 処理が終わったPDFは処理済みの場所へ移し、移すのは成功したときだけにします。受信用の場所に残っている数が、そのまま未処理の数になります。活字のPDFやメール本文の見積はこの経路に混ぜません。

入力データを集める

質を決めるのは、下の2つです。 確かめる条件の一覧が無ければ、生成AIは「書かれていた条件」を並べるだけで、「書かれていなかった条件」を拾えません。 抜けは、あるべきものの一覧と比べて初めて見えます。

条件の一覧は、加工と工事で分けます。

工事の行の「内訳」と「工程ごとの日数」は、建設業法の第20条に沿ったものです。 建設業者は、工事の種別ごとの材料費・労務費などの内訳と、工程ごとの作業とその準備に必要な日数を記載した見積書（材料費等記載見積書）を作るよう努めなければならないとされています（2025-12-12 施行の改正後の条文）。書かれていなければ「記載なし」と拾い、業者にお願いする材料にします。

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

読み取りは、レイアウトモデル（prebuilt-layout）を呼ぶだけです。出力の形式は Markdown を指定します（outputContentFormat=markdown）。v4.0 では表が HTML のテーブルとして出力され、結合されたセルや複数行の見出しも表現できます。 手書きの見積用紙は「品名」の欄が2行にまたがっていることが多く、この形のほうが生成AIに渡したときに列を取り違えにくくなります。

数字の信頼度は、セルではなく単語で見ます。 表のセルの文字列は返りますが、信頼度は単語ごとに返ります。セルの範囲に入る単語の信頼度のうち、いちばん低いものをそのセルの信頼度として扱います。「12,800」のうち「8」だけが怪しいとき、平均を取ると埋もれます。

AIへ渡す前に整形する

1. ページ数の確認 … 見積が2枚以上にわたるFAXは、明細が次のページに続きます。ページをまたぐ表は、読み取った後で1つの表につなぎます
2. 送付状の除外 … 1枚目がFAXの送付状だけのことがあります。表が無く「送付状」「FAX送信票」の文字があるページは明細の対象から外します（業者名と日付は拾います）
3. 文字の大きさの確認 … 抽出するテキストの最小の高さは、1024×768ピクセルの画像で12ピクセルとされ、150dpiで約8ポイントの文字に当たります。FAXの細かい但し書きは、この下限に近いことがあります
4. 業者の特定 … 送信元のFAX番号から業者を引き、区分（加工／工事）を決めます。社名から先に引くと「㈲山田製作所」と「山田製作所」で引けません
5. 依頼の候補の絞り込み … その業者に出していて、回答期限が過ぎていない見積依頼だけを候補にします。全部を渡すと、品名の似た別の依頼に紐づけます
6. 重複の検知 … 同じ業者から同じ日に同じ枚数のFAXが来ていれば、送り直しの疑いとして印を付けます

AIに処理させる

させるのは、業者ごとにばらばらな書き方を、比較表の決まった項目に対応づけることだけです。

2行目がいちばん起きやすい失敗です。 1桁が読めない単価を数量と金額から割り戻して埋めると、比較表はきれいにそろいますが、業者の計算違いだった場合、その証拠が消えます。

指示内容を固定する

あなたは製造業の購買課で、業者からFAXで届いた見積書を比較表の項目に
そろえる担当です。OCRの読み取り結果だけを見て作業してください。

【やること】
1. 明細の表の各行を、item_name / spec / quantity / unit / unit_price /
   amount / delivery の項目に対応づける
2. 見積書に書かれた見積依頼番号を拾う。無ければ【依頼の候補】の中から
   品名・数量・図面番号が合うものを1つ選び、選んだ根拠を書く。
   合うものが無い、または2つ以上合うときは request_no を空にする
3. 【確かめる条件】の項目ごとに、stated / not_stated / unclear を付ける
4. 但し書き・備考は、そのまま写す

【厳守事項】
- 数字はOCRが返した文字列をそのまま写してください。
  桁区切りの「,」の有無を直す以外の書き換えをしないでください。
- 読めない桁があるときは、その数字を空にせず、読めた文字列のまま
  返し、digits_unclear を true にしてください。
- 計算をしないでください。数量と単価から金額を出す、合計から単価を
  割り戻す、消費税を計算する、のいずれもしないでください。
  書かれていない金額は空のままにしてください。
- 「式」「一式」は単位です。数量を1に書き換えないでください。
- 運賃・据付費・材料の手配などが書かれていないときは not_stated です。
  「一般に込みである」などの推測で stated にしないでください。
- 「別途」「別」「含まず」は、その費用が見積に含まれていないと
  書かれているので stated です。value に書かれたとおり写してください。
- 印刷された見出しの文字（例：「運賃」という欄の名前）があるだけで、
  値が空なら not_stated です。欄の名前を値として扱わないでください。
- evidence には根拠にした文字列をそのまま写してください。
- 業者の比較、発注先の推薦、金額の高い安いの評価は書かないでください。
- 見積書でない書類（送付状だけ、請求書、納品書）と判断したときは、
  document_type に種類を書き、明細を作らないでください。

【業者の区分】{vendor_category}
【確かめる条件】{required_terms}
【依頼の候補】{candidate_requests}
【読み取り結果（Markdown）】{ocr_markdown}

「欄の名前を値として扱わない」を明記しないと、条件の抜けが拾えません。 業者の見積用紙には「運賃」「納期」「有効期限」の欄が印刷されていて、空欄のまま送られてくることがよくあります。読み取り結果には「運賃」という文字が確かにあるので、何も言わなければ stated にします。styles の手書きの判定と組み合わせ、書き込まれた値があるかで見ます。

「別途」を stated にするのも明記が要ります。 「運賃別途」は含まれていないことがはっきり書かれている状態で、抜けではありません。

出力形式を固定する

次の形のJSONで受け取ります。 Azure OpenAI の構造化出力で、response_format に json_schema を strict: true で渡し、形を固定します。すべての項目を必須にし、additionalProperties を false にする必要があるので、値が無い項目も空文字で返させます。

{
  "document_type": "quotation",
  "vendor_code": "V0231",
  "request_no": "RQ-2610-045",
  "request_match_reason": "見積書右上に「RQ-2610-045」と手書き",
  "quote_date": "2026-10-08",
  "valid_until": "",
  "lines": [
    { "row": 1, "item_name": "ブラケット追加工", "spec": "図面 B-1182 穴あけ4か所",
      "quantity": "120", "unit": "個", "unit_price": "380",
      "amount": "45,600", "delivery": "10/24", "digits_unclear": false },
    { "row": 2, "item_name": "黒染め", "spec": "",
      "quantity": "1", "unit": "式", "unit_price": "",
      "amount": "8,000", "delivery": "", "digits_unclear": true }
  ],
  "subtotal": "53,600",
  "tax": "5,360",
  "total": "58,960",
  "terms": [
    { "term": "freight", "status": "stated", "value": "運賃別途", "evidence": "※運賃別途" },
    { "term": "valid_until", "status": "not_stated", "value": "", "evidence": "" },
    { "term": "material", "status": "unclear", "value": "", "evidence": "材料 支給・手配（どちらにも丸なし）" }
  ],
  "notes": ["材料支給の場合は単価-50円"]
}

金額を文字列で受け取るのは、読み取ったとおりの形を残すためです。 検算はプログラムが数値に直してから行います。

検算の結果は、プログラムが次の形で足します。

calc_mismatch と read_uncertain の分け方は、次の規則で決めます。

しきい値は最初は厳しめに置き、人が直したセルの記録を見て動かします。

システムへ連携する

比較表へは「行の追加」だけにします。 訂正の見積が届いたら新しい行として足し、古い行に「訂正あり」の印を付けます。 購買管理システムと仕入先マスタには書き込みません。

人が確認する

人が見るのは、印の付いたセルと条件の抜けだけです。 read_uncertain のセルは黄色、calc_mismatch のセルは赤で表示し、FAXの画像の該当箇所へのリンクを添えます。

1. 黄色（読み違いの疑い）を先に直す … 画像と見比べて直すと、そのセルを含む検算をやり直します
2. 赤（計算違いの疑い）を確かめる … 業者の書いた数字が読み取りと同じなら、業者の計算違いとして扱います
3. 業者に確かめるかを決める … 計算違いと条件の抜けは、まとめて1回で聞きます。文面は担当が作り、自動では送りません
4. 依頼番号の紐づけを確かめる … request_match_reason を読み、候補から選ばれた紐づけが正しいかを見ます
5. 直した記録を残す … どのセルを何から何に直したかが自動で記録されます

2番目を省かないでください。 赤のセルは「業者が計算を間違えた」という疑いで、それを業者に伝えるのは購買担当です。読み違いだったのに業者に指摘すると、その業者との次のやり取りに残ります。

目標は、240枚をならして1枚5分です。 印が5か所を超える見積が続く業者は、FAXの画質か用紙の書き方に理由があります。

例外に対処する

上の2行が、運用の最初の数か月で多く出ます。 どちらもAIの問題ではなく、仕入先マスタのFAX番号と、見積依頼に番号を書いてもらう習慣の問題です。 依頼書に「ご回答の際は依頼番号をご記入ください」と大きく書くだけで、2行目はかなり減ります。

記録を残す

• 受信したFAXのPDFと、受信日時・送信元のFAX番号
• Document Intelligence が返したJSONの全文
• 生成AIに渡した指示と、返ってきたJSON
• 検算の結果（checks）と、そのときのしきい値
• 人が直したセルの記録（直す前の値、直した後の値、そのセルの信頼度、直した人）
• 業者に確かめた内容と、その回答
• 業者ごとの read_uncertain と calc_mismatch の件数

5番目の記録が、しきい値を決める材料になります。 直されたセルの信頼度の分布を見れば、どこから下を人に回すべきかが分かります。最後の行は、業者に数字の欄を大きく書いてもらうといったお願いの材料です。