漬物の工場が手書きの漬け込みの記録表から樽・塩分・重量・漬け替えを読み取り、樽ごとの製造の台帳と基準から外れた値の一覧を作る

処理の起点を決める

班長がスキャンした記録表が、Blob Storage のコンテナに保存されたことを起点にします。 スキャンは1枚1ファイルにします。1枚に10行しかない表を、何十枚もまとめた1つの PDF にすると、どの行がどの日のどの紙かを、後で記録表に戻って確かめにくくなります。

同じファイルを二度処理しない仕組みは、ランタイムの側にあります。 Azure Functions は、同じ新しい（または更新された）Blob に対して Blob のトリガーの関数を二度呼ばないよう、Blob の受領の記録（blob receipts）を持ちます。ただし、班長が同じ記録表を別の名前で二度スキャンしたものは、別の Blob として処理されます。 これは票の日付と行の中身で見分けます。

処理に失敗したファイルは、既定で合わせて5回まで試し直され、それでも失敗すると webjobs-blobtrigger-poison という名前のキューにメッセージが入ります。 このキューを毎朝見て、読み取れなかった記録表があれば、品質管理の担当がスキャンし直します。

入力データを集める

質を決めるのは、樽の一覧と基準の表です。 読み取った樽番号が樽の一覧に無ければ、その行はどの樽にも積めません。基準の表が古いと、正しい値を「外れ」として回し続け、一覧が読まれなくなります。

学習に使う見本は、少なくとも5枚です。 カスタム テンプレート モデルは様式ごとに少なくとも5枚の見本を用意するよう案内されています。10行が全部埋まった表だけでなく、途中までしか書かれていない表、書き直しのある表、水や塩で汚れた表を混ぜます。

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

読み取りは、Azure Functions から Document Intelligence の 2024-11-30 の版の API を呼びます。表は10行×12列ほどの固定の表としてラベルを付けたので、行と列の番号がそのまま返ります。

「書かれていない」と「読めなかった」は、空のセルの信頼度で分けます。 案内では、値の無いセルは NULL とその信頼度を持ち、信頼度が高ければ「値が無い」という予測が正しい可能性が高く、低ければ値を見落とした可能性があるとされています。

信頼度は、表全体 → 行 → セルの順に見ます。 案内でも、表の信頼度から見始め、行、セルと下りていくのがよいとされています。表全体の信頼度が低い記録表は、汚れや折れで表の形が崩れている恐れがあり、行ごとに見る前に記録表ごと人に回します。

AIへ渡す前に整形する

1. 形式とページ数の確認 … PDF か画像で、1ページであることを確かめます。2ページ以上は分けます
2. 解像度の確認 … 文字の高さの下限は、1024×768の画像で12ピクセル（150 DPI で約8ポイント）です。小数点が残る解像度でスキャンします
3. 記録表の日付 … 表の上の日付の欄から取ります。行ごとに日付を書かない様式なので、この日付が読めないと全行が宙に浮きます
4. 樽番号の正規化 … 全角と半角、前後の空白をそろえます。それ以上は直しません
5. 数字の正規化 … 「kg」「％」などの単位の文字を外します。小数点の補いはしません

2番目の「小数点が残る解像度」は、この構成でいちばん効く設定です。 塩分の「3.5」と「35」は、小数点1つの違いです。複合機の既定の解像度で小数点が消えるなら、解像度を上げるか、現場で小数点を大きく書く決まりにします。

AIに処理させる

AIにさせるのは、表のセルの文字とチェックの状態を、信頼度とともに返すことだけです。 基準との照合、記録の抜けの洗い出し、一覧づくりは Python の決まった処理で行います。

照合の処理で拾うものは次のとおりです。

「急な変化」を入れているのは、読み違いを拾うためでもあります。 前回 3.5 だった樽が今回 35 なら、塩分の範囲の外として拾えますが、前回 3.5 の樽が今回 2.5 と読まれたら、範囲の中に収まって見逃します。 前回との差を見れば、こちらも拾えます。

2行目がいちばん起きやすい失敗です。 重石の重さは前回と同じことが多く、空なら前回の値を入れたくなります。しかし、記録の抜けを拾うのがこの構成の目的の1つで、埋めた瞬間にそれが消えます。

指示内容を固定する

この構成の読み取りはカスタム テンプレート モデルで、生成AIへの文章の指示はありません。指示にあたるのは、ラベルの付け方と、Python の照合の設定です。

【ラベルの付け方（Document Intelligence Studio でモデルを作るとき）】
- record_date, recorder … 表の上の欄の値
- work_table … 固定の表（10行）。列は次のとおり
  tank_no, item_code, lot_no, raw_kg, salt_kg, salinity_pct, weight_kg,
  op_shitazuke, op_honzuke, op_tsukekae, op_sashijio, op_toridashi（選択マーク）,
  liquid_ok（選択マーク）, note
- 見本は少なくとも5枚。途中までしか書かれていない表、書き直しのある表、
  汚れのある表を混ぜる。空の行も「空」としてラベルを付ける。

【照合の設定（Python）】
thresholds:
  table_confidence_min: 0.70     # 表全体がこれ未満 → 記録表ごと人へ
  cell_confidence_min: 0.80      # 値のあるセルがこれ未満 → 読めなかった
  null_confidence_min: 0.80      # NULL のセルがこれ以上 → 書かれていない
rules:
  - 値を直さない。小数点を補わない。空を前回の値で埋めない。
  - tank_no と item_code は一覧に当たらなければ要確認。近いものに寄せない。
  - 作業の種類の選択マークがちょうど1つでなければ要確認。
  - 塩分・塩の割合は、item_code と作業の種類から基準の表の行を引いて照らす。
  - 同じ tank_no の前回の salinity_pct との差が、基準の表の幅を超えたら「急な変化」。
  - 毎朝、漬け込み中の樽を樽の一覧から数え、
    次の作業の目安の日を過ぎた樽、決めた日数のあいだ行の無い樽を拾う。
  - 読めなかったセルを含む行は、台帳に積むが、照合の結果を「保留」にする。

「読めなかったセルを含む行も台帳に積む」のは、記録の抜けと取り違えないためです。 積まずに捨てると、その樽はその日に記録が無いことになり、翌朝の「記録の抜け」に誤って出ます。 積んだうえで照合を保留にすれば、樽の側から見て「記録はあるが読めていない」と分かります。

しきい値の「0.70」「0.80」は例です。 最初の1か月は、保留に回る行が多くても全部確かめ、どのセルでどの程度の信頼度のときに誤りが出たかを数えてから決めます。

出力形式を固定する

次の形で、行ごとに台帳に積みます。

{
  "record_date": "2026-10-28",
  "sheet_id": "",
  "row": 3,
  "tank_no": "T-118",
  "item_code": "TK",
  "operation": "tsukekae",
  "lot_no": "",
  "raw_kg": { "value": 420.0, "state": "ok", "confidence": 0.94 },
  "salt_kg": { "value": null, "state": "not_written", "confidence": 0.91 },
  "salinity_pct": { "value": 35, "state": "ok", "confidence": 0.62 },
  "weight_kg": { "value": 300, "state": "ok", "confidence": 0.90 },
  "liquid_ok": true,
  "checks": ["salinity_out_of_range", "salt_not_written"],
  "result": "ok | out_of_range | hold | needs_check",
  "image_link": ""
}

1つ目の理由は、数字ごとに state を持てることです。 ok・not_written（書かれていない）・unreadable（読めなかった）の3つです。一覧で「塩の量が書かれていない」と「塩の量が読めなかった」を並べて見られます。 前者は現場に、後者は品質管理の担当が記録表の画像で確かめます。

2つ目は、confidence を値の隣に置くことです。 上の例の塩分 35 は信頼度が 0.62 で、基準の外であると同時に、読み違いを疑う値でもあります。 一覧ではこの両方を並べて出し、担当者が記録表を見る前に察しをつけられるようにします。

3つ目は、sheet_id と row で記録表に戻れることです。 一覧の行から、記録表の画像の何行目かがすぐに開けます。数字の確かめは、画像を見るのがいちばん早いからです。

樽ごとの製造の台帳は、この行を樽番号で並べたものです。 樽ごとに、漬け込みの日、品目、ロット、塩分の推移、漬け替えの日、経過の日数が1画面で見えます。原料のロットも行に持たせているので、ある産地の原料で塩分の外れが続いたときに、そのロットを使った樽を台帳から引けます。 原料の受け入れの記録と台帳をつなぐのは、この lot_no です。

システムへ連携する

出荷の仕組みとは、つなぎません。 基準から外れた樽の出荷を止めるかどうかは、品質管理の責任者が決めます。この構成が自動で出荷を止めると、読み違いで正常な樽が止まり、現場が一覧を信じなくなります。

人が確認する

1. 品質管理の担当が、毎朝の一覧を記録表の画像で確かめる … 読めなかったセルに値を入れ、保留を解きます
2. 書かれていない値は、班長に確かめる … 測り忘れなら、その日のうちに測り直せるかを決めます
3. 基準から外れた樽は、班長と現場で樽を見る … 測り直しの値を記録に足します
4. 扱いを品質管理の責任者が決める … 差し塩、漬け替えの前倒し、出荷の保留など
5. 人が値を入れ直したら、入れ直した記録を残す … 何を何に直したか

1番目で、一覧の行を必ず画像で見ます。 読み取りの値と信頼度だけで判断せず、記録表の数字を自分の目で読みます。 信頼度が高くても、汚れで別の数字に見える字はあります。

目標は、300枚をならして1枚2分です。 保留や外れが出るのは1枚に1行前後という想定で、それより多い日は、スキャンの解像度か、ある作業者の書き方に理由があります。

例外に対処する

上の2行は、行ごとに見る前に記録表ごと止める規則です。 日付や表の形が崩れたまま行を積むと、別の日の記録として台帳に残り、後から直すのに手間がかかります。

記録を残す

• 記録表のスキャンと、保存した日時・スキャンした人
• 読み取りの結果の全文（セル・行・表の値と信頼度、チェック欄の状態）
• 行ごとの state・checks・result と、そのときの基準の表の内容
• 人が値を入れ直した記録 … どのセルを、何から何に直したか、だれが
• 基準から外れた樽について、品質管理の責任者が決めた扱い

3つ目で基準の表の内容を残すのは、基準が後から変わるためです。 塩分の範囲を直すと、過去の外れの意味が変わります。当時の基準が残っていないと、過去の記録を見直すときに判断がつきません。

4つ目と5つ目は、衛生管理の記録として後から確かめられる形で残します。 記録の様式と保存の期間は、自社の衛生管理の計画に合わせて決めます。