生協が組合員から回収する手書きの注文用紙を Azure AI Document Intelligence で読み、商品番号と数量を注文データに転記して、読み取りの怪しい欄を確認に回す

処理の起点を決める

スキャンした PDF が Blob Storage の受付のコンテナーに保存されたことを起点にします。 センターの複合機の保存先を受付のコンテナーにつながるフォルダにしておき、コースごとに1つの PDF にまとめてスキャンします。保存されると Azure Functions の処理が動き、PDF を用紙1枚ずつに分けて読み取りに回します。

夜にまとめて動かすのではなく、保存のたびに動かします。 午前にスキャンしたコースの確認を、午後のスキャンの前に終わらせられることが効きます。

処理が終わった PDF は処理済みのコンテナーへ移します。移すのは、全ページの読み取りと照合が終わったときだけにします。 途中で止まった PDF は受付のコンテナーに残り、残っている数がそのまま未処理の数になります。 夕方には配達のコースの一覧と突き合わせ、PDF が届いていないコースを一覧にします。

入力データを集める

質を決めるのは、その週の企画の一覧です。 商品番号は企画の回ごとに割り当てが変わることがあり、先週の一覧で照合すると、読み違えた番号が ok になります。

前週までの注文は、確認の材料として画面に出すだけです。 前週の注文から番号を埋めることはしません。

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

読み取りは、Azure Functions から Document Intelligence の REST API でカスタム テンプレート モデルを呼びます。API のバージョンは 2024-11-30（v4.0 の GA）に固定します。 カスタム モデルのフィールドに単語の信頼度が含まれるのも、表・行・セルの信頼度が返るのも、このバージョンからとされています。

信頼度は2つの層を合わせて見ます。 公式の説明では、フィールドの信頼度は取り出した値の位置についての確からしさを表し、文字そのものの確からしさは単語の信頼度として別に返るとされています。2つのうち低いほうを、その欄の信頼度として扱います。

表の信頼度は、表全体から順に見ます。 公式の説明では、表全体、行、セルの順に上から見ていくことが勧められ、決まった行数の表ではセルの信頼度を見るだけでもかなりのことが分かるとされています。注文用紙は40行の決まった表なので、セルの信頼度を中心に、行の信頼度で行ごとの漏れを補います。

組合員の台帳と企画の一覧は、毎晩の書き出しのファイルを Python で読みます。照合の順は、企画の回が先、商品番号が後です。 企画の回を取り違えると、それ以降の照合がすべてずれます。

AIへ渡す前に整形する

1. ページ分けと向きの確認 … コースごとの PDF を1枚ずつに分け、上下が逆のページを直します。裏返しでスキャンされた白紙のページは除きます
2. 解像度の確認 … 取り出す文字の高さの下限は、1024×768の画像で12ピクセル（150dpiで約8ポイントの文字）とされています。数量の枠は小さいので、複合機は300dpiに固定します
3. 画像の寸法の確認 … 50×50から10,000×10,000ピクセルの間である必要があります
4. 様式の確認 … 読み取り結果の文書の種類の信頼度が低い用紙は、古い様式や別の用紙が混ざった可能性があるので、読み取りの結果を使わずに担当へ回します
5. 重複の確認 … 同じ組合員・同じ企画の回の用紙が既に処理されていれば、上書きせずに担当に確かめます

2番目を軽く見ないでください。 複合機の既定の設定は文書の読みやすさに合わせてあり、枠の細い線と数字が重なると、数字の一部が線に吸収されます。 1と7の見分けがつかない原因の多くは、組合員の書き方ではなくスキャンの設定です。

4番目は、テンプレート モデルの性質から来ています。 公式の説明では、テンプレート モデルは決まった見た目の様式に頼るため、様式が変わると正確さが下がるとされています。カタログの改訂で用紙の様式が変わった週は、古い用紙と新しい用紙が混ざります。

AIに処理させる

させるのは、注文用紙の決まった枠に書かれた数字を読み、欄ごとの信頼度を返すことだけです。 企画の一覧との照合、数量の上限、行ごとの判定は、Python が決まった規則で行います。

Python が行う行ごとの判定は、次の順で決めます。

3番目を4番目より先に置くのが、この判定の要です。 信頼度が低い番号を先に照らすと、たまたま企画にある番号に読めた行が ok になります。

not_in_catalog の行には、候補を並べます。 読み取った番号と1桁だけ違う、その週の企画の番号を最大3つまで出し、それぞれの商品名を添えます。選ぶのは担当で、候補を自動で採用することはしません。 第3章の（b）の探し方の違いを、候補の出し方として1つにそろえます。

4行目は、善意から起こりやすい失敗です。 上限が3の商品に「5」と書かれていても、「3」の読み違いか、上限を知らずに書いたのかは用紙を見ないと決められません。

指示内容を固定する

この構成では生成AIを使わないため、プロンプトの代わりにテンプレート モデルの学習の指示と、ラベル付けの決まりを示します。

【見本の集め方】
- 現行の様式の注文用紙を、実際に組合員が書いたものから集める
- ラベル付けした見本は最低5枚。できれば30枚程度を、次のばらつきが入るように選ぶ
  ・行が1〜2行だけの用紙と、40行近く埋まった用紙
  ・数字を枠からはみ出して書いた用紙、二重線で書き直した用紙
  ・「今週は注文しない」に印がある用紙
  ・鉛筆で書かれた薄い用紙、ボールペンで書かれた用紙
- スキャンの設定は本番と同じ300dpiにそろえる

【ラベルの決まり】
- member_code ...... 組合員コードの印字の枠
- issue_no ......... 企画の回の印字の枠
- no_order ......... 「今週は注文しない」のチェック欄（選択マーク）
- order_lines ...... 表のフィールド。40行固定。列は item_no と qty
- item_no .......... 商品番号の5つの枠をまとめて1つの値として囲む
- qty .............. 数量の枠。枠の外へはみ出した書き込みも含めて囲む
- 1つの枠を2つのフィールドに割り当てない（重なり合うフィールドは使えない）
- 空欄の行もラベルの対象にし、値が無いことを学ばせる

【学習と評価】
- 学習のモード（buildMode）は template
- 学習の結果の推定の正確さは80％以上を目安にする。
  注文は届け先と請求に直結するので、100％に近づくまで見本を足す
- 様式の改訂があったら、新しい様式で5枚以上の見本を作り、学習し直す

「空欄の行もラベルの対象にする」を外さないでください。 公式の説明では、任意の項目の空欄について、学習の見本に空欄がどのくらい含まれるかによって、値が無いという予測の信頼度も変わるとされています。注文用紙は40行のうち大半が空欄なので、ここを外すと空欄の扱いが不安定になります。

判定の基準値は、処理の側の設定として持ちます。 初期値は、商品番号の信頼度の下限0.90（フィールドと単語の低いほう）、数量の下限0.85とし、最初の1か月で、直した行の信頼度の分布と返品の記録を見て見直します。

出力形式を固定する

用紙1枚ごとに、次の形のJSONを作ります。

{
  "sheet_id": "2026-W42-C07-0153",
  "member_code": "1048831",
  "issue_no": "42",
  "no_order": false,
  "sheet_status": "has_review | all_ok | no_order | form_mismatch",
  "lines": [
    { "row": 1, "item_no": "31207", "qty": "2",
      "item_conf": 0.98, "qty_conf": 0.97,
      "check": "ok", "item_name": "", "candidates": [] },
    { "row": 2, "item_no": "47195", "qty": "1",
      "item_conf": 0.71, "qty_conf": 0.95,
      "check": "low_confidence", "item_name": "",
      "candidates": ["17195", "41195"] }
  ],
  "reviewed_by": "",
  "reviewed_at": ""
}

1つ目の理由は、行ごとに check を持てることです。 用紙の単位ではなく行の単位で判定を持つので、確認の画面には ok 以外の行だけを出せます。

2つ目は、読み取った値と直した値を分けて残せることです。 item_no は読み取ったままの値で、担当が直したら別の項目に書き、元の値は消しません。 どの数字がどの数字に読み違えられやすいかは、この差から分かります。candidates は担当が選ぶための材料で、item_no に自動で入ることはありません。

取り込みファイルには、確かめ終わった行だけを、受注システムの取り込みの形式（組合員コード、企画の回、商品番号、数量）で書き出します。

システムへ連携する

受注システムへは、取り込みファイルを渡すところまでにします。 取り込みの操作は担当が行い、取り込んだ件数と、用紙の数・行の数が合っているかを取り込みの画面で確かめます。 自動で取り込む経路を作ると、照合の設定を誤った週にそのまま誤った注文が発注まで進みます。

組合員の台帳と企画の一覧は読むだけです。 台帳に無い組合員コードが出ても書き足さず、担当が確かめます。

人が確認する

人が見るのは ok 以外の行と、用紙ごと回された用紙だけです。 ok だけの用紙は、コースごとの件数と行の数を一覧で流し見ます。

1. 用紙ごと回されたものを先に見る … form_mismatch（古い様式・別の用紙）と、組合員コードが台帳に無いもの。多くはスキャンの取り違えか、様式の切り替えの週の混在です
2. low_confidence の行を、画像の切り出しと並べて見る … 数字が読めれば直し、読めなければ配達担当への確認に回します
3. not_in_catalog の行を、候補と並べて見る … 候補の商品名と、前週の注文を見て決めます。決めきれなければ、候補を採用せずに確認に回します
4. over_limit と ambiguous の行を見る … 数量の書き方の解釈は、生協で決めた扱い（「正」の字の数え方など）に従います
5. 直した内容を記録する … どの行を、何から何に直したかを残します

3番目で「決めきれなければ確認に回す」を守ってください。 候補が1つしかなく、前週も同じ商品を頼んでいると採用したくなりますが、組合員に聞くほうが返品より安く済みます。 発注の締切に間に合わない行は、その週の注文から外し、組合員に伝えます。

目標は、2,400枚をならして1枚1分です。 確認の要る行が用紙の3割前後に1行ずつ出るという想定で、それより多い週は、スキャンの設定か、企画の一覧の取り込みを疑います。

例外に対処する

下から3行目は、テンプレート モデルの性質から来ています。 枠の位置に頼って読むので、枠を大きくはみ出して書かれた数字は、どのフィールドにも入らないことがあります。 空欄と出た行の数が、用紙の見た目と合わないときは疑います。

記録を残す

• 元の PDF と、用紙1枚ごとの画像、スキャンした日時とコース
• Document Intelligence が返した JSON の全文と、使ったモデルの ID と API のバージョン
• 行ごとの判定（check、信頼度、candidates）と、照合に使った企画の一覧の版
• 担当が直した記録 … どの行を、何から何に直したか。確認した担当と日時
• 配達担当に確認を頼んだ行と、その結果
• 届けた後に返品・交換になった注文と、その行の判定の記録

3つ目で企画の一覧の版を残すのは、欠品で商品が週の途中で差し替わることがあるためです。 版が残っていないと、ok だった理由を後から説明できません。

最後の行が、この構成の精度を測るいちばん確かな物差しです。 ok で流した行から返品が出たら、その行の信頼度と、読み取った数字と、正しい数字の組み合わせを見ます。同じ組み合わせが続くなら、下限の値か学習の見本を見直します。