学生服の販売店が採寸のときに手書きする学校ごとの採寸・注文票を Azure AI Document Intelligence で読み、品目・サイズ・数量を発注の一覧に転記して、採寸値とサイズの食い違いを拾う

処理の起点を決める

店長がその日の注文票を複合機でスキャンし、PDF が Blob Storage の受付のコンテナーに保存されたことを起点にします。 1日の分をまとめて1つの PDF にし、店舗ごとに保存先のフォルダを分けます。 保存されると Azure Functions の処理が動きます。

スキャンは閉店の前に行います。 翌朝には店長の確認の一覧が出ているので、保護者への電話を午前のうちに済ませ、その日のうちにメーカーへ送れます。 学校での採寸の日は、店に戻ってからその日の分をスキャンします。

処理が終わった PDF は処理済みのコンテナーへ移します。移すのは、全ページの分類と読み取りと照合が終わったときだけにします。 受付のコンテナーに残っている数が、未処理の数になります。

入力データを集める

質を決めるのは、下の2つの表です。 指定品目の表が無ければ、その学校に無い品目かどうかを判断できません。メーカーのサイズの表が無ければ、採寸値とサイズの照合ができません。どちらも学校やメーカーの改訂のたびに直す決まりにします。

採寸値とサイズの照合には、身長と胸囲（上衣）、胴囲（下衣）を使います。 どの採寸値をどの品目に使うかも、メーカーのサイズの表に持たせます。

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

読み取りは、Azure Functions から Document Intelligence の REST API で合成モデルを1回呼びます。 v4.0 の合成モデルは分類モデルと学校ごとのテンプレート モデルをまとめたもので、1ページずつ分類され、その学校のモデルで読まれた結果が返ります。 API のバージョンは 2024-11-30 に固定します。

分割の設定は「1ページずつ」にします。 公式の説明では、v4.0 の分類モデルは既定では文書を分けず（splitMode の既定は none）、perPage を指定すると1ページずつを別の文書として分類するとされています。注文票は1人1枚なので、1日分の PDF を1ページずつ分類させます。

分類の信頼度にも閾値を置きます。 学校の様式の判定を誤ると、別の学校のモデルで読まれ、欄の対応がすべてずれます。 閾値を下回ったページは読み取りの結果を使わず、店長に回します。

指定品目の表とメーカーのサイズの表は、店の共有のフォルダの表計算のファイルを Python で読みます。照合の順は、学校が先、品目が後、サイズが最後です。

AIへ渡す前に整形する

1. ページの向きと白紙の確認 … 上下が逆のページを直し、白紙のページを除きます
2. 解像度の確認 … 取り出す文字の高さの下限は、1024×768の画像で12ピクセル（150dpiで約8ポイントの文字）とされています。採寸値の欄は小さいので、300dpiに固定します
3. ページ数とサイズの確認 … PDF は最大2,000ページ、有料（S0）のレベルで500MBまでとされています
4. 裏面の確認 … 注文票の裏に保護者のメモが書かれていることがあります。裏面は読み取りの対象にせず、画像として保存だけします
5. 重複の確認 … 同じ学校・同じ生徒の名前・同じ日の注文票が既にあれば、上書きせずに店長に確かめます

2番目を軽く見ないでください。 採寸値は「82.5」のように小数点を含み、小数点が読めないと「825」になります。 解像度が足りないと、小数点は最初に消えます。

AIに処理させる

させるのは、注文票を学校の様式に振り分け、その学校の枠に書かれた値と丸印を読み、信頼度を返すことだけです。 照合と判定は Python が規則で行います。

Python が行う照合は、次の4つです。

size_gap を「2段階以上」にしているのは、1段階は普通のことだからです。 成長を見込んで1サイズ大きめを選ぶのはよくあることで、そこまで店長に回すと、確認の一覧が埋まって本当の書き違いが埋もれます。 何段階からを回すかは、店の経験で決めて設定に持ちます。

size_gap は「誤り」ではなく「確かめる理由」です。 体格に合わせて保護者が意図して選ぶこともあります。この構成はサイズを直さず、店長が採寸に立ち会った記憶と保護者への確認で決めます。

指示内容を固定する

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

【分類モデル】
- 区分：25校それぞれの様式（学校のコードを区分の名前にする）＋「その他」
- 各区分に、実際に書かれた注文票を5枚以上（年に数枚しか来ない学校も5枚そろえる）
- 「その他」には、体操服だけの注文票、別の店の書類、
  旧様式の注文票など、振り分けたくないものを入れる
- 学校の様式が改訂されたら、新しい様式の見本を足して学習し直す
  （v4.0 は既存の分類モデルに見本や区分を足す学習に対応）

【学校ごとのテンプレート モデル】
- 学習のモード（buildMode）は template
- 1校につき、ラベル付けした見本を5枚以上
- 次のばらつきを入れる
  ・サイズを丸印で付けたものと、数字で書いたもの
  ・採寸係と保護者の筆跡が混ざったもの
  ・裾上げの欄が空欄のもの、品目が1つだけのもの
- フィールドの名前は学校をまたいで同じ名前にそろえる
  （身長、胸囲、胴囲、股下、品目ごとのサイズと数量、裾上げ）
- 1つの枠を2つのフィールドに割り当てない（重なり合うフィールドは使えない）

【合成】
- 分類モデルの区分と、学校ごとのテンプレート モデルを対応づけて合成する
- 「その他」の区分は、どのモデルにも対応づけない
- 分類の信頼度の閾値を決める

「フィールドの名前を学校をまたいでそろえる」が、照合を1つにする工夫です。 学校ごとに様式は違っても、読み取った結果の項目名がそろっていれば、Python の照合は学校に関係なく同じ処理で済みます。 違うのは、照合に使う指定品目の表だけになります。

「その他」の区分をどのモデルにも対応づけないのは、読ませないためです。 公式の説明では、合成モデルは信頼度の閾値を置いたり、区分をどの抽出モデルにも対応づけなかったりすることで、特定の文書の種類を無視できるとされています。振り分けたくない書類を、無理に学校のモデルで読ませないための設定です。

判定の基準値は、処理の側の設定として持ちます。 初期値は、分類の信頼度の閾値0.85、採寸値とサイズの数字の信頼度の下限0.85、選択マークの下限0.80とし、最初の1か月で店長が直した欄の分布を見て見直します。

出力形式を固定する

注文票1枚ごとに、次の形のJSONを作ります。

{
  "sheet_id": "S2-20261015-012",
  "school": "C07",
  "class_conf": 0.96,
  "student": { "grade": "1", "name": "", "contact": "" },
  "measures": {
    "height": { "value": "158", "conf": 0.97 },
    "chest": { "value": "82.5", "conf": 0.93 },
    "waist": { "value": "68", "conf": 0.95 },
    "inseam": { "value": "", "conf": 0.90 }
  },
  "items": [
    { "item": "ブレザー", "size": "165A", "qty": "1", "conf": 0.94,
      "suggested_size": "160A", "check": "ok" },
    { "item": "スラックス", "size": "W70", "qty": "2", "conf": 0.91,
      "hem": "", "check": "missing" }
  ],
  "needs_review": true
}

1つ目の理由は、品目ごとに check を持てることです。 店長が見るのは、ok 以外の品目だけになります。

2つ目は、suggested_size を並べて持つことです。 採寸値から引いたサイズを、選ばれたサイズとは別の項目に入れ、size は書き換えません。 1段階の差は ok のまま、2段階以上で size_gap になります。

3つ目は、class_conf を残すことです。 学校の振り分けの信頼度が低い注文票は、品目の照合が正しくても、欄の対応がずれている可能性があります。 店長の確認の一覧では、この値の低い順に並べます。

発注の一覧の下書きは、確かめ終わった品目をメーカーごと・品番ごと・サイズごとに集計し、生徒ごとの引き渡しの票には学校・学年・名前・品目・サイズ・数量・裾上げを並べます。

システムへ連携する

メーカーへの送信は、事務が下書きを確かめてから行います。 発注は取り消しのきかないことが多く、誤った発注は在庫と交換の手間になって戻ってきます。

指定品目の表とサイズの表は読むだけです。 表に無い品目やサイズが出ても書き足さず、学校やメーカーの改訂を店長が確かめてから表を直します。

人が確認する

店長が見るのは、確認の一覧で印の付いた注文票と品目だけです。 印の無い注文票は、学校ごとの枚数を流し見ます。

1. unclassified を先に見る … 学校の振り分けができなかったページ。画像を見て学校を決め、その学校のモデルで読み直します
2. missing を見る … 裾上げの寸法と数量の書き漏れ。採寸の記録が手元にあれば補い、無ければ保護者に電話します
3. size_gap を見る … 採寸値と選ばれたサイズを並べて見ます。採寸に立ち会った店長が、保護者の希望を覚えていればそのまま、迷えば電話します
4. not_designated と invalid_size を見る … 別の学校の品目や、選べないサイズ。保護者に確かめます
5. 直した内容を記録する … どの欄を、何から何に直したか、保護者に確かめたかを残します

3番目は、直すことより「確かめた」と残すことが大事です。 意図して大きめを選んだ保護者に何度も電話をすると、かえって手間になります。確かめた結果「そのまま」なら、その記録が次の買い替えのときの参考になります。

目標は、400枚をならして1枚1.5分です。 印の付く注文票が3割前後という想定で、それより多い日は、学校の振り分けの閾値か、スキャンの設定を疑います。

例外に対処する

上から3行は、取引校の変化に伴う作業です。 学校の制服のモデルチェンジや新しい取引校は、分類とテンプレートの両方を直す必要があります。 v4.0 の分類モデルは、既存のモデルに見本や区分を足す学習に対応しているので、全部を作り直さずに済みます。

記録を残す

• 元の PDF と、ページごとの画像、スキャンした日時と店舗
• 分類と読み取りの JSON の全文と、使った合成モデル・分類モデルの ID と API のバージョン
• 照合の結果（check、suggested_size）と、そのとき参照した指定品目の表とサイズの表の版
• 店長が直した記録と、保護者に確かめた記録
• メーカーへ送った発注の一覧と、送った日時
• 納品の後に交換になった品目と、その注文票の判定の記録

3つ目で表の版を残すのは、学校の指定品目が年度で変わるためです。 版が残っていないと、not_designated だった理由を後から説明できません。

最後の行が、この構成の精度を測る物差しです。 ok で流した品目から交換が出たら、その品目の信頼度と、採寸値とサイズの差を見ます。同じ型が続くなら、閾値か size_gap の段階を見直します。