包装に印字した賞味期限とロット番号を生産ラインのカメラ画像で読み取り、印字の欠け・かすれと生産計画との食い違いを見つけてラインを止める

処理の起点を決める

包装がカメラの前を通ったことを、通過のセンサーで捉えて撮ります。 センサーの信号でカメラが1枚撮り、その画像を Python の処理に渡します。1個ごとに撮るので、抜き取りの間の包装もすべて見ます。

品目の切り替えは、別のきっかけとして扱います。 作業者が検査の画面で切り替えを登録すると、生産計画の次の品目の正しい文字列に切り替わります。登録が無いまま印字が変われば、1個目から mismatch が続き、止まります。 登録だけして設定を変え忘れた場合も同じです。

印字確認記録は、時刻で作ります。 切り替えの直後と1時間ごとに、それまでの判定の集計と代表の画像をまとめます。紙の記録の時点をそのまま引き継ぐので、品質保証部の承認の流れは変わりません。

入力データを集める

質を決めるのは、品目マスタの賞味期間と表示の形式です。 正しい文字列は、ここから計算で作ります。品目マスタの値が誤っていれば、正しく印字された包装をすべて mismatch で止めてしまい、 逆に印字の設定と同じ誤りがあれば、誤りを素通しします。品目マスタの値は、品質保証部が承認したものだけを使います。

年月で表示する品目は、どの月を表示するかの決め方を品目マスタに持たせます。 賞味期限の日を年月で表すときの月の決め方は、自社の表示の取り決めとして品質保証部が決めているはずです。計算の側で勝手に決めないでください。

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

生産計画と品目マスタは、それぞれの仕組みの書き出しの機能で表の形のファイルを出し、始業前と、生産計画が変わったときに読み直します。 書き出しを API で取れる仕組みなら定時に取りに行きます。

画像は、検査用の端末で処理し、外に送りません。 ラインの速度の中で判定を終える必要があり、通信の遅れや切断で判定が止まると、ラインも止まります。 クラウドの読み取りのサービスに送る作りは、この用途には向きません。

追加学習の画像は、ラインで撮ったものを使います。 立ち上げの1〜2か月は判定をせずに撮りため、その時点の生産計画から作った正しい文字列を付けます。正しく印字された包装の画像なら、正しい文字列がそのまま答えになるので、1枚ずつ文字を打ち込む必要はありません。 手で答えを付けるのは、かすれた印字や欠けた印字の画像だけです。プリンタの種類、包装の色、日付の形（年月か年月日か）ごとに偏りなく集めます。

AIへ渡す前に整形する

1. 位置合わせ … テンプレートの画像で matchTemplate を行い、一致の度合いが閾値に届かなければ missing（印字の面が撮れていない）とします
2. 印字の領域の切り出し … 一致した位置からの相対の位置で、賞味期限とロット番号の領域を切り出します
3. 傾きの補正 … 包装が搬送の上で少し回っていることがあるので、枠の線の向きから傾きを直します
4. 明るさの正規化 … フィルムの光沢や照明のむらを抑えるため、領域の中の明るさをそろえます
5. 印字の濃さの測定 … 領域の中で文字と判定される画素の割合と、文字と地のコントラストを測ります
6. 正しい文字列の作成 … 製造日に賞味期間を足し、品目マスタの書式で日付にし、ロット番号の付け方で組み立てます

5番目は、読み取りとは別に測ります。 読み取りのモデルは、かすれていても文脈で正しく読んでしまうことがあります。読めたから合格、とすると、店頭で人が読めない印字を通します。 濃さの数値は、良品の印字で測った範囲と比べます。

6番目の計算は、モデルに任せません。 日付の計算と書式は決まった規則で書き、月末の日付や閏年の2月、年をまたぐ賞味期限を、立ち上げのときに試験の値で確かめておきます。

3番目と4番目は、良品の範囲を作るときと同じ処理にします。 濃さの基準は、立ち上げのときに良品の画像で測った値の範囲です。基準を作ったときと判定のときで明るさの正規化が違うと、 照明が少し暗くなっただけで全部が faint になります。処理の版を記録し、変えたら基準を測り直します。

AIに処理させる

させるのは、切り出した印字の領域の文字を読み、確からしさを返すことだけです。 照合、濃さの判定、排出と停止の判断は、決まった規則で行います。

mismatch と uncertain の分かれ目が、この構成でいちばん大事な区別です。 確からしさが高いまま違う文字を読んだのは、印字そのものが違うということで、品目の切り替えの誤りを疑います。確からしさが低いのは、印字が崩れているか、撮り方が悪いということです。対応する人と手順が違います。

2行目がいちばん起きやすい失敗です。 読み取りの結果を正しい文字列と照らして「1文字違いなら正しい方に直す」補正を入れると、本当に1文字違って印字された包装が ok になります。 補正は一切入れません。

指示内容を固定する

この構成は生成AIを使わないので、プロンプトの代わりに、読み取りの設定と判定の規則を書いておきます。

【読み取り】
- paddleocr.TextRecognition（自社の印字で追加学習した PP-OCR の読み取りのモデル）
- 入力：切り出した領域の画像（賞味期限・ロット番号の2つ）
- 出力：rec_text（文字列）、rec_score（確からしさ）
- 文字の辞書は変えない。追加学習の画像は、プリンタの種類ごとに集める

【正しい文字列】
- 賞味期限の日 = 製造日 + 賞味期間（日数）
- 表示の形式 = 品目マスタの値（年月 / 年月日）
- 年月表示の月の決め方 = 品目マスタの値（品質保証部が決めたもの）
- ロット番号 = 品目マスタの付け方（例：工場の記号 + 製造日 + ラインの記号）

【判定の規則】
- missing  : 位置合わせの一致の度合い < 0.70、または文字の画素の割合 < 良品の下限の 30%
- uncertain: rec_score < 0.90（文字列が一致していても）
- mismatch : rec_score ≧ 0.90 かつ 文字列 ≠ 正しい文字列（補正しない）
- faint    : 文字列 = 正しい文字列 かつ 濃さ < 良品の範囲の下限
- ok       : 上のどれにも当たらない

【排出と停止】
- ok 以外は1個ずつ排出する
- mismatch が連続 3 個 → 停止の信号（切り替えの誤りを疑う）
- faint または uncertain が直近 50 個のうち 10 個 → 停止の信号（ヘッドの汚れを疑う）
- missing が連続 5 個 → 停止の信号（カメラ・照明・搬送を疑う）

「文字列が一致していても uncertain」を書いておかないと、確からしさの低い一致が ok になります。 確からしさが低いのに一致したのは、たまたまかもしれません。一致したかどうかより先に、確からしさで分けます。

閾値の数字は、立ち上げのときに自社の画像で決め直します。 上の数字は形を示すための例です。良品の画像と、わざとかすれさせた印字・前の品目の印字の画像を集め、 ok の取りこぼしと見逃しの両方を数えてから決めます。

出力形式を固定する

包装1個ごとに、次の形のJSONを残します。

{
  "line": "",
  "captured_at": "",
  "product_code": "",
  "expected": { "best_before": "2027.04", "lot": "A0412K3" },
  "read": {
    "best_before": { "text": "", "score": 0 },
    "lot": { "text": "", "score": 0 }
  },
  "print_density": { "ink_ratio": 0, "contrast": 0 },
  "align_score": 0,
  "verdict": "ok | mismatch | faint | missing | uncertain",
  "action": "pass | reject | reject_and_stop",
  "image_path": "",
  "model_version": ""
}

1つ目の理由は、expected と read を並べて残せることです。 何と照らし、何と読んだかが1件ごとに残るので、mismatch で止まったときに、作業者は画面でどの文字が違うかを見られます。 品目の切り替えの誤りなら、日付の全体が違います。

2つ目は、score と print_density を分けて持てることです。 かすれは濃さに、崩れは確からしさに出ます。ヘッドの汚れが進むと、まず濃さが下がり、次に確からしさが下がります。 両方を時系列で見ると、止まる前に清掃の時期が分かります。

3つ目は、action を判定と分けていることです。 同じ faint でも、1個だけなら排出、続けば停止です。判定はAIの読み取りと規則で、処置は規則だけで決まります。

システムへ連携する

排出と停止は、既存の装置の入力に信号を渡すだけです。 制御盤の中の手順は変えず、停止の解除は作業者が盤の側で行います。 検査の側から再開させる経路は作りません。

検査の端末が止まったときは、ラインも止める側に倒します。 検査が動いていない間に流れた包装は、誰も見ていない包装になります。検査の端末から一定の間隔で「動いている」という信号を出し、途切れたら制御盤の側で止まるように組みます。

人が確認する

人が見るのは、停止したときと、排出された包装と、時点ごとの記録です。 ok の包装の画像を人が見ることはしません。全数を人が見る設計にすると、第10章の20.0時間には収まりません。

1. 停止したら、理由の種類を先に見る … mismatch の連続ならプリンタの設定と生産計画を照らします。 faint と uncertain ならヘッドの清掃、missing ならカメラと照明と搬送を見ます
2. 排出された包装の画像を見る … 本当に印字が悪いのか、撮り方が悪いのかを見分けます
3. 停止の前に流れた包装の範囲を決める … mismatch で止まったときは、直前の切り替えの時刻からの包装をすべて見直す対象にします
4. 記録を承認する … 品質保証部が、時点ごとの集計と排出・停止の履歴を確かめます

3番目を省かないでください。 mismatch が3個続いて止まったのなら、その前の包装も同じ誤りの可能性があります。排出された3個だけを外して再開すると、検査の前に流れた分が残ります。 検査の前に流れた分とは、カメラより上流で印字されたがまだカメラを通っていない包装と、検査の端末の起動前に流れた包装です。

停止の原因と処置は、作業者が画面の決まった選択肢から選んで残します。 「ヘッドの清掃」「設定の直し」「照明の調整」などです。自由な文章にすると、同じ原因が人によって違う言葉で書かれ、 どの原因が多いかを数えられません。

目標は、1,200件をならして1件1分です。 時点ごとの記録は画面で集計を確かめて承認するだけで、時間がかかるのは停止と排出の対応です。 それが多い月は、ヘッドの清掃の周期か、閾値を見直します。

例外に対処する

上から2行目が、運用の最初にいちばん起きます。 急な品目の変更で、生産計画を直す前に包装を始めると、正しい印字なのにすべて mismatch で止まります。 止まったからといって検査の画面で品目を直す運用にすると、生産計画と検査の両方を同じ人が変えることになります。

記録を残す

• 包装1個ごとの判定のJSON（expected、read、print_density、verdict、action）
• ok 以外の包装の画像と、時点ごとの ok の代表の画像
• 切り替えの登録の記録（ライン・品目・時刻・登録した人）
• 停止の記録（理由の種類、停止と再開の時刻、作業者が行った処置）
• 時点ごとの印字確認記録と、品質保証部の承認
• 読み取りのモデルの版と、学ばせた画像の件数、試験の画像での見逃しの数
• 品目マスタ・生産計画を読んだ時刻と、そのときの値

最後の行で「そのときの値」を残すのは、品目マスタが後から直ることがあるためです。 賞味期間を直した後に過去の判定を見直すとき、当時の正しい文字列が何だったかが残っていないと、どの包装が誤りだったかを決められません。