製麺所が手書きの製造記録（配合・加水率・ゆで時間・検品）を読み取り、ロットごとの製造台帳と基準外の値の一覧を作る

処理の起点を決める

12時30分と18時の定時に、共有フォルダの新着を見に行くことを起点にします。 動かすのは、品質管理の PC かサーバーのタスクの予約の機能です。

1日2回にしているのは、出荷の前に一覧を見られるようにするためです。 午前のロットの多くは、その日の午後か翌朝に出荷されます。終業の後に1回だけ読むと、午前のロットの基準外に気づくのが翌朝になります。 昼の休憩で午前の記録表をいったんスキャンし、終業の前に午後の分をスキャンします。

読み取りが終わったファイルは、処理済みのフォルダへ移します。 移すのは台帳に書き出すところまで成功したときだけで、共有フォルダに残っている数が、そのまま未処理の数になります。

入力データを集める

質を決めるのは、品目マスタの基準の数字です。 文書の「おおむね」「〜前後」のような書き方を、下限と上限の数字に直す作業は、品質管理と製造の責任者で行います。 直し方が決まらない値は、基準の照合から外し、台帳に記録するだけにします。

見出しの対応表は、記録表の見出しが読み違えられたときのために持ちます。 「ゆで時間」が「ゆで時問」と読まれても、対応表に読み違えやすい表記を足しておけば、同じ列に入ります。

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

Python のプログラムから、公式のライブラリ google-cloud-documentai で Form Parser を呼びます。 公式の手順では、DocumentProcessorServiceClient を作り、ProcessRequest にプロセッサの名前と文書（raw_document）を渡して process_document を呼びます。us 以外の地域を使うときは、api_endpoint に地域の付いたエンドポイントを指定します。

表をロットの行に直す処理は、次のような流れです。

from google.cloud import documentai_v1
from google.api_core.client_options import ClientOptions

client = documentai_v1.DocumentProcessorServiceClient(
    client_options=ClientOptions(api_endpoint=f"{LOCATION}-documentai.googleapis.com"))
raw = documentai_v1.RawDocument(content=pdf_bytes, mime_type="application/pdf")
doc = client.process_document(
    request=documentai_v1.ProcessRequest(name=PROCESSOR_NAME, raw_document=raw)).document

def cell_text(cell):
    # textAnchor の位置から全文を切り出す（startIndex は省かれることがある）
    return "".join(doc.text[s.start_index:s.end_index]
                   for s in cell.layout.text_anchor.text_segments).strip()

for page in doc.pages:
    for table in page.tables:
        header = [HEADER_MAP.get(cell_text(c)) for c in table.header_rows[0].cells]
        if None in header:
            mark_table_for_review(table)        # 列が決まらない表は全部確認へ
            continue
        for row in table.body_rows:
            values = {col: (cell_text(c), c.layout.confidence)
                      for col, c in zip(header, row.cells)}
            add_lot_row(values)                 # 検算と照合は別の関数で行う

読み取りと判定を別の関数に分けておくと、基準の値や計算式を直したときに、読み取りをやり直さずに判定だけをやり直せます。

表の中のチェック欄は、文字として返ります。 公式の説明では、表の中のチェック欄は ✓（付いている）や ☐（付いていない）の文字で表れ、表の外のチェック欄はキーと値のペアとして返り、valueType が filled_checkbox か unfilled_checkbox になります。 金属検出機の作動確認は表の中なので、セルの文字が ✓ か ☐ かで見ます。

ページの上限は、オンラインの処理で15ページです。 記録表は1枚1ページなので届きません。ファイルの大きさはオンラインで40MBまでです。

AIへ渡す前に整形する

1. 様式の改訂 … 見出しを1行にし、行や列をまたぐセルを無くします。 「ゆで麺」の見出しの下に「時間」「湯温」を並べる2段の見出しをやめ、「ゆで時間」「ゆで湯温」の1段にします
2. 生麺のラインの空欄 … 生麺のラインはゆで時間などを書きません。空欄に斜線を引く決まりにし、 空欄と読み落としを見分けます
3. 数字の書き方 … 小数点は必ず書く、単位は見出しに印刷して欄には書かない、を決まりにします
4. 確認者の欄 … 確認者の印は記録表の上のキーと値で取ります。Form Parser は値の空いたキーと値のペアを確実には取り出せないとされているため、キーが見つからない、または値が無いときは「未確認」として扱います
5. スキャンの設定 … 公式の説明では、スキャンは200 dpi 以上、300 dpi 以上で最もよい結果になります。複合機を300 dpi にそろえます
6. ファイルの形式 … PDF、JPEG、PNG、TIFF などが使えます。TIFF は、以前の JPEG の圧縮方式のものは使えないため、複合機の保存形式を PDF にします
7. 汚れ … 記録表を透明のファイルに入れてラインに置くと、水や粉が付きにくくなります。スキャンの前にはファイルから出します

1番目の様式の改訂がいちばん効きます。 2段の見出しのままだと、Form Parser が表として認識できず、セルの並びがずれて、ゆで時間の列に湯温が入ります。 学習の要らないプロセッサなので、様式の側を合わせます。

AIに処理させる

Form Parser にさせるのは、表とキーと値を読み取り、信頼度を付けることだけです。 列の決定、検算、照合は、Python の決まった規則で行います。

加水率の計算式は、自社の決まりをそのまま使います。 水の量で計算するか、塩水の量で計算するか、粉に対する割合か全体に対する割合かは製麺所によって違います。品質管理の文書にある式を、プログラムに1か所だけ書きます。

させないことも決めておきます。

1行目がいちばん起きやすい失敗です。 同じ品目のロットは値が似ているので、読めない重量を前のロットの値で埋めると、台帳はきれいにそろいますが、その1ロットだけ重量が足りなかったことが消えます。

指示内容を固定する

この構成には生成AIへのプロンプトがありません。AIへの指示にあたるのは、見出しの対応表と、Python の照合の規則です。

【見出しの対応表（読み違えやすい表記も並べる）】
lot_no ......... ロット / ロット番号 / ロツト
item_code ...... 品目 / 品目コード
flour_kg ....... 小麦粉 / 粉 / 小麦粉(kg)
water_l ........ 水 / 水(L) / 加水量
baume .......... ボーメ / 塩水ボーメ / ボーメ度
water_ratio .... 加水率 / 加水率(%)
mix_min ........ 混合 / 混合時間
boil_min ....... ゆで時間 / ゆで時問 / 茹で時間
boil_temp ...... ゆで湯温 / 湯温
chill_temp ..... 冷却後品温 / 品温
ball_g ......... 1玉重量 / 重量 / 玉重量
metal_check .... 金検 / 金属検出 / 金属検出確認

【照合の規則（Python）】
1. 表ごとに見出しの行を対応表で引き、全部の列が決まらなければ表全体を「読み取りの確認」
2. 斜線は空欄として扱う。生麺のラインの boil_min・boil_temp・chill_temp は空欄でよい
3. 数字として読めない値、信頼度が基準より低い値は「読み取りの確認」
4. 自社の式で加水率を計算し、water_ratio との差が0.5ポイントを超えれば「加水率の食い違い」
5. item_code で品目マスタを引き、下限と上限の外の値は「基準外」
6. metal_check が ✓ でなければ「基準外」
7. 確認者のキーと値が無ければ「未確認」
8. 読めない値を、ほかのロットや平均で埋めない。書かれた値を書き換えない

8番の「埋めない」「書き換えない」が、この規則の中でいちばん大事です。 埋める処理も書き換える処理も、数行で書けます。書けるからこそ、書かない決まりとして残しておきます。

基準の値は、最初の1か月で決めます。 信頼度の基準を低めから始めて「読み取りの確認」を多めに出し、担当が直した値と、そのときの信頼度を並べて、 誤りが出なくなる信頼度を探します。

出力形式を固定する

ロット台帳は、ロットごとに1行の CSV に追記します。

「読み取りの状態」と「判定」を別の列にしているのが、この形の要です。 読み取りが確かでないロットは、判定の列を空にして「読み取りの確認」の一覧に出し、担当が値を直してから判定をやり直します。 読み違いの値で判定した結果を、台帳に残しません。

3つの一覧は、たとえば次の形で出します。

【読み取りの確認】 10/28 ゆで麺ライン
 L-1028-07  ball_g  「2〇5」  信頼度 0.41   記録表 p1 7行目
【加水率の食い違い】
 L-1028-03  粉 25.0kg 水 8.5L  書かれた加水率 36.0  計算 34.0  差 2.0
【基準外】
 L-1028-11  うどん(U12)  chill_temp 18.5℃  基準 上限 15.0℃

加水率の食い違いの例は、計算の誤りか、計量の書き間違いかのどちらかです。 計算した34.0が基準の範囲でも、書かれた36.0のままでは本当の配合が分かりません。ラインの責任者に、計量の値と計算のどちらが正しいかを聞いて、備考に残します。

システムへ連携する

出荷の仕組みには、何もつなぎません。 基準外のロットを止めるかどうかは人が決め、この構成から出荷を止めたり許したりする経路を作りません。

人が確認する

1. 「読み取りの確認」を先に見る … 記録表のスキャンを開き、値を直します。直したロットは判定をやり直します
2. 「未確認」を見る … 確認者の印が無い記録表は、ラインの責任者に確認を頼みます
3. 「加水率の食い違い」を見る … 計量の値と計算のどちらが正しいかを、ラインの責任者に聞きます
4. 「基準外」を見る … 事情を聞き、出荷の扱いを責任者と決めて、備考に書きます
5. 翌朝の出荷の前に、基準外のロットの扱いが決まっていることを確かめる

1番目を先に片付けることを省かないでください。 読み違いが残ったまま「基準外」を見ると、存在しない基準外のためにラインの責任者を探し、 本当の基準外への対応が後回しになります。

この構成は、現場の判断を後ろに置き換えるものではありません。 ゆで湯の温度が低い、品温が下がらないといったことは、ラインの担当がその場で気づいて対応するのが先です。 一覧は、その場の判断が記録に残っているかを、出荷の前にもう一度確かめるためのものです。

目標は、480ロットをならして1ロット1分です。 一覧に出るロットが2割前後という想定で、それより多い日は、記録表の汚れかスキャンの設定を疑います。

例外に対処する

上の2行は、運用を始めて最初の数週間によく出ます。 どちらも用紙の問題で、新しい様式に切り替わると減っていきます。

記録を残す

• 記録表のスキャン（紙の原本とあわせて、社内の記録の保存の期間に従う）
• Document AI が返した結果の JSON と、プロセッサの版
• ロット台帳の各行と、担当が直した値の記録（どの列を、何から何に直したか）
• 一覧に出たロットの、事情と扱いの備考
• 品目ごとの加水率・重量のばらつきの推移

3つ目の直した値の記録が、信頼度の基準を決める材料になります。 最後の推移は、月末を待たずに毎週見ます。 台帳が毎日そろうので、ばらつきが広がり始めた品目に、その週のうちに気づけます。