製パン工場で手書きされるロットごとの製造記録を読み取り、仕込み・発酵・焼成の温度と時間と数量を製造の台帳に転記して、管理の範囲を外れた値と改善措置の書き漏れを拾う

処理の起点を決める

記録票の画像がフォルダに保存されたことを起点にします。 撮るのはロットの焼成が終わったときで、オーブンの出口の担当が、ラインの脇に固定したタブレットで撮ります。撮影の台を決めておけば、毎回同じ距離と角度で撮れます。

1日の終わりにまとめて動かす形にはしません。ロットごとに読み取れば、外れた値の一覧は、そのロットの製品が冷却を終える前に出ます。 (a)の「気づくのが出荷のあと」を、「工場にあるうち」に変えるのが狙いです。

ファイル名には、撮影の日時とラインの番号を入れます。品目とロット番号は記録票から読み取り、生産計画表と照らします。 処理が終わったものは処理済みのフォルダへ移し、移すのは成功したときだけにします。 その日の生産計画にあるロットの数と、撮られた記録票の数を夕方に比べ、撮り忘れも拾います。

入力データを集める

質を決めるのは、製品規格表と欄の一覧です。 規格表が品目の改廃に追いついていないと、新しい品目の記録票が「範囲が無い」と出ます。季節の品目を出すときに、規格表の行を足すのを品目の立ち上げの手順に入れます。

欄の一覧は、品目によって違います。 調理パンは焼成のあとに具材を挟む工程があり、食パンは焼成のあとに型から抜く工程があります。一覧が品目ごとでないと、書かれなくてよい欄を記入漏れとして拾います。

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

読み取りは、Python から Form Parser のプロセッサを呼ぶだけです。返ってくる Document から、キーと値のペアと表と信頼度を取り出します。

公式の説明では、text が認識されたテキストの唯一の元で、ほかの欄は startIndex と endIndex でその位置を指すとされています。キーと値のペアの文字も、この位置から原文を引いて取り出します。 表は headerRows と bodyRows に分かれ、行や列をまたぐセルの無い表だけが対象とされています。

キーの文字は、記録票の印刷のラベルとそのまま一致するとは限りません。 「捏ね上げ温度」が「捏上温度」と読まれる、ラベルと値が隣の欄と組み合わされる、ということが起こりえます。キーの文字で台帳の項目を引くのではなく、生成AIに対応づけさせ、対応づけの結果を欄の一覧と照らします。

生産計画表は、毎朝の書き出しを読みます。照合は日付・ライン・ロット番号の組で行います。 品目の名前で引くと、同じ日に同じ品目を2つのラインで作ったときに取り違えます。

AIへ渡す前に整形する

1. 画像の向きと傾き … 撮影の台で撮っても残る傾きを、紙の四隅で補正します
2. 解像度 … 公式の説明では、スキャンは最低200dpi、300dpi以上で一般に最良の結果とされています。撮影の解像度はこれに相当する大きさにします
3. ファイルの形式 … JPEG か PNG で保存します
4. 粉と油の汚れ … 記録票は粉や油で汚れます。汚れで欄が読めない画像は、撮り直しを促します
5. 重複の検知 … 同じロット番号の記録票が二度撮られたら、新しい方だけを使います
6. 品目の確定 … 記録票の品目とロット番号を生産計画表と照らし、品目を確定してから欄の一覧と規格表を引きます

6番目を、ほかの照合より先に行います。 品目が確定しないと、どの範囲と比べるかも、どの欄が書かれるはずかも決まりません。品目が読めない記録票は、生産計画表のロット番号から品目を引き、それも引けなければ人に回します。

AIに処理させる

生成AIにさせるのは2つだけです。 読み取った欄と表を製造の台帳の項目に対応づけること、値を文字のまま写すことです。

比較と計算は、プログラムの側で行います。

3行目がいちばん起きやすい失敗です。 焼成の温度の欄がにじんでいると、同じ品目の前のロットと同じ値で埋めたくなります。埋めた瞬間、その記録票は「範囲内」になり、外れていたかもしれない事実が消えます。

指示内容を固定する

あなたは製パン工場の品質管理課で、製造記録票の読み取り結果を台帳の形にそろえる担当です。
OCRが返したキーと値のペアと表だけを見てください。推測で埋めないでください。

【台帳の項目】
item_name（品目）、lot_no（ロット番号）、line（ライン）、mix_minutes（ミキシングの時間）、
dough_temp（捏ね上げ温度）、ferm_temp（一次発酵の温度）、ferm_humidity（一次発酵の湿度）、
ferm_start / ferm_end（一次発酵の開始と終了の時刻）、divide_weight（分割の重さ）、
proof_temp / proof_humidity（ホイロの温度と湿度）、proof_start / proof_end（ホイロの開始と終了）、
bake_temp（焼成の温度）、bake_minutes（焼成の時間）、
qty_planned / qty_good / qty_defect / qty_sample（仕込み数・良品数・不良数・抜き取りの数）、
corrective_action（改善措置）、stamp_*（工程ごとの担当者の印）

【厳守事項】
- 各ペアと表の列がどの項目に当たるかを field_map に書いてください。
  決められないものは unknown にしてください。
- 値は書かれた文字のまま写してください。単位も書かれていれば一緒に写してください。
- 時刻は書かれたとおりに写してください。長さを計算しないでください。
  「2:05」を「14:05」に直すなど、午前・午後を推測しないでください。
- 読めない値は空にし、その項目を unreadable_fields に入れてください。
  前のロットの値や、ありそうな値で埋めないでください。
- 見つからない項目は、結果に含めないでください。空の値を作らないでください。
- 改善措置の欄は、書かれた文を原文のまま写してください。要約しないでください。
- 担当者の印は、あるかどうかだけを present / absent / unclear で書いてください。
- 範囲を外れているか、出荷してよいかは書かないでください。

【OCRのキーと値のペア】{form_fields}
【OCRの表】{tables}

「見つからない項目は結果に含めない」と明記しているのは、記入漏れの判定をプログラムの側に置くためです。 生成AIが見つからない項目に空の値を作ると、空の値が「読めたが空だった」のか「欄ごと見つからなかった」のかが分からなくなります。欄の一覧との照合は、結果に無い項目を数えることで行います。

「午前・午後を推測しない」も同じ理由です。 夜勤のラインでは、「2:05」が深夜の2時のこともあります。時刻の解釈は、生産計画表のラインの稼働時間帯と照らして、プログラムが決めます。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "sheet_id": "",
  "captured_at": "",
  "field_map": [
    { "source": "form_field | table_cell", "source_text": "", "field": "" }
  ],
  "values": [
    { "field": "", "text": "", "confidence": 0 }
  ],
  "unreadable_fields": [ "" ],
  "corrective_action_text": "",
  "stamps": [
    { "process": "mix | ferm | divide | proof | bake", "state": "present | absent | unclear" }
  ]
}

値をすべて文字列で受けるのは、意図してのことです。 温度の「28°」、時刻の「14.05」、数量の「1,200」は、数値の型で受けると記号のところで崩れます。文字のまま受け、プログラムで数字として読めるかを確かめてから数値にします。

Claude の構造化出力は、output_config.format に JSON スキーマを渡して有効にし、オブジェクトには additionalProperties: false が必要とされています。 数値の minimum・maximum は対応していないとされているので、範囲の確認はもともとプログラムで行う設計と合っています。

後段の照合は、この出力に対して決まりで行います。

5行目が、この構成の中心です。 範囲外れだけなら、ラインの調整の記録として残ります。外れと改善措置が組になっていない記録票だけを最優先の一覧の先頭に出し、その日のうちにラインに確かめます。

時刻から長さを出す処理は、次のような形になります（要点だけ）。

def minutes_between(start_text, end_text, line_shift):
    s = parse_clock(start_text, line_shift)   # 「14:05」「14.05」「2:05」を稼働時間帯で解釈
    e = parse_clock(end_text, line_shift)
    if s is None or e is None:
        return None                           # 読めなければ計算しない
    if e < s:
        e += 24 * 60                          # 夜をまたぐロットは翌日として扱う
    return e - s

読めない時刻のときに None を返し、0分としないのが要点です。 0分にすると、範囲の比較で「短すぎる」という別の外れに化けます。

システムへ連携する

製造の台帳へ書き込むのは、人が確かめた記録だけです。 確認の要る欄の無い記録票は、品質管理課の担当が一覧で流し見て「確定」を押した時点で書き込みます。生成AIの出力を、そのまま台帳に流し込む経路は作りません。

製品規格表は、読むだけです。 範囲外れが続く品目があっても、規格表は書き換えません。範囲を見直すかどうかは、品質管理課と製造の課長が、記録の傾向を見て決めます。

人が確認する

人が見るのは、印の付いた記録票だけです。

1. 改善措置の書き漏れを先に見る … 範囲外れがあるのに改善措置の欄が空いている記録票を、その日のうちにラインの担当者に確かめます。書き足してもらうのは、実際にした措置だけです
2. 範囲外れを製造の課長に回す … 外れたロットの一覧を、ロットが工場にあるうちに渡します。扱いは課長が決めます
3. 記入漏れの候補を確かめる … 欄の一覧にあって読み取りの結果に無い欄を、画像で確かめます。本当に空いているのか、読み取れなかっただけかを見分けます
4. 数字の欄を確かめる … 信頼度の低い欄と、数字として読めない欄を、画像と並べて直します
5. 数量の食い違いと印の欠けを確かめる … ラインの担当者に確かめます

3番目を省かないでください。 欄ごと結果から消えるのは、空いていた場合だけではありません。汚れや筆跡で読めなかった欄も、結果に出てこないことがあります。 画像を見れば数秒で分かります。

目標は、900枚をならして1枚0.8分です。 印の無い記録票は一覧で流し見て数秒、改善措置の書き漏れのある記録票はラインに確かめるので数分かかります。

例外に対処する

上の2行が大半を占めます。 どちらもAIの精度の問題というより、粉と油のある現場で書く紙の性質の問題です。 記録票をクリップボードに挟んで書く、ペンを油性の細字に替えるほうが、指示を直すより効きます。

記録を残す

• 記録票の画像と、撮影の日時・ライン
• OCR が返した Document の全文（text、formFields、tables、信頼度）
• 生成AIの出力（欄の対応づけ、値、改善措置の原文、印の有無）
• 照合の結果（記入漏れの候補・範囲外れ・改善措置の書き漏れ・数量・印）と、そのとき使った製品規格表の版
• 人が直した欄の記録 … どのロットの、どの欄を、何から何に直したか
• 改善措置を書き足した記録 … 誰が、いつ、何を書き足したか

4つ目で「規格表の版」を残すのは、範囲が後から変わるためです。 範囲を見直すと、過去の記録の「範囲外れ」の意味が変わります。当時の範囲が残っていないと、外部の監査で記録を示すときに説明がつきません。

改善措置を書き足した記録も残します。 後から書き足したこと自体は問題ではありませんが、その日のうちに書いたのか、何日もたってから書いたのかが分かることが、記録の信頼につながります。