味噌の醸造所が手書きの仕込み・天地返し・熟成点検の記録を読み取り、桶ごとの熟成の台帳と出荷の予定表を作る

処理の起点を決める

毎日17時に、共有フォルダに入った新しいファイルを処理します。 蔵の作業は朝から夕方までで、記録票は作業のたびに書かれます。夕方にまとめて読めば、翌朝には前日の記録が台帳の更新の案になっています。

ファイルの保存ごとに動かす形にはしません。同じ桶の仕込みと天地返しが同じ日に書かれることがあり、1日分をまとめて照合したほうが、桶の番号の書き間違いに気づきやすいからです。 1日分の記録票を並べると、「A-12 に天地返しが2枚、A-21 に0枚」のような偏りが見えます。

入る経路は2つです。事務所の複合機でスキャンしたPDFと、蔵のタブレットで撮影した画像です。どちらも同じフォルダに入れ、そこから先は区別しません。処理が終わったファイルは処理済みのフォルダへ移し、移すのは読み取りと書き出しの両方が成功したときだけにします。 元のフォルダに残っている数が、そのまま未処理の数になります。

入力データを集める

質を決めるのは、桶のマスタと商品の熟成の決まりです。 マスタが無ければ、読み取った桶の番号が実在するかを確かめられません。熟成の決まりが無ければ、予定の月も天地返しの予定日も計算できず、台帳は「写した記録の集まり」で止まります。

熟成の決まりは、責任者の頭の中から表に出す必要があります。 「麦の1年物は仕込みから3か月前後で天地返し」のような目安を、商品ごとに1行ずつ書き出します。これがこの構成でいちばん時間のかかる準備で、AIの有無にかかわらず、責任者が休んでも出荷の見込みが立つようにするために要る作業です。

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

読み取りは、スクリプトからレイアウトモデルを呼ぶだけです。このとき出力の形式を Markdown にします（outputContentFormat=markdown）。 v4.0（2024-11-30 GA）では、Markdown の表は結合セルや複数行の見出しを表せる HTML の表になり、チェック欄は ☒ と ☐ の文字で表されます。生成AIに渡すのは、この Markdown の本文です。

記録票の種類は、生成AIに渡す前にスクリプトで決めます。 様式の上端に「仕込記録」「天地返し記録」「熟成点検表」と印刷しておき、手書きでない行（isHandwritten が付かない行）からこの文字を探します。種類をAIに推させないことで、書き分けの指示を種類ごとに短くできます。

ロットの番号は仕込みのときにしか書かれないので、 天地返しと点検の記録は桶の番号だけでつなぎます。

AIへ渡す前に整形する

1. 形式の確認 … PDFまたは画像であることを確かめます。撮影の画像が HEIF で届いても、そのまま入れられます
2. ページ数と大きさの確認 … 有料（S0）のレベルで500MB、PDFとTIFFは2,000ページまで。実際の記録票は1〜2ページなので、超えるのは束ごとスキャンした場合だけです
3. 画像の寸法の確認 … 50×50から10,000×10,000ピクセルの間であることを確かめ、範囲外は撮り直します
4. 文字の大きさの確認 … 1024×768の画像で12ピクセルが下限です。鉛筆のかすれた字は、この下限より先に読めなくなります
5. 1枚に1つの記録票かの確認 … 公式のページは、写真やスキャンは1文書につき1枚の鮮明なものを勧めています。2枚を重ねて撮ったものは撮り直します
6. 重複の検知 … 同じ桶・同じ日付・同じ種類の記録票が直近にあれば、二重のスキャンとして印を付けます

4番目を軽く見ないでください。 蔵の中の記録票は、濡れた手で触られ、味噌の色が付きます。読めないのは字の癖より紙の汚れのことが多く、 スキャンの濃さを上げるか、記録票を透明のファイルに入れて書くほうが効きます。

AIに処理させる

させるのは、読み取った記録票の本文を、種類ごとに決めた項目へ書き分けることだけです。 書いていないことを補わせず、日付の計算もさせません。

右端の列で次の作業が変わります。 空欄は職人に聞く、unreadable は撮り直す、uncertain は画像を見る、です。

略し方の書き分けは、言い換えの一覧で行います。 「天返」「天地」「切返し」は天地返し、「タマリ多」「たまり有」は所見の「たまり」というように、蔵で使われている略し方を一覧にして指示に添えます。 一覧にない言葉は、原文のまま「その他のメモ」に入れさせます。

いちばん起きやすいのは3行目です。 桶の番号の棟の記号が抜けていると、AIは前後の記録票から「たぶん A 棟」と補います。補った番号で照合が通ると、間違いが台帳まで素通りします。 補わせず、照合できないものとして人に回します。

指示内容を固定する

あなたは味噌の醸造所で、蔵の記録票を台帳の項目に書き分ける係です。
渡すのは、OCR が読み取った記録票1枚分の本文（Markdown）と、記録票の種類です。
本文に書かれていることだけを使ってください。推測で埋めないでください。

【記録票の種類】{record_type}（shikomi / tenchigaeshi / tenken のいずれか）

【書き分ける項目】
- tank_no：桶の番号。書かれた文字のまま。棟の記号が無くても補わない
- date：日付。書かれた文字のまま（例「10/14」「R8.10.14」）。年を補わない
- product：商品の区分（仕込みのときだけ）。書かれた文字のまま
- amounts：大豆・麹・塩・種水の量と単位（仕込みのときだけ）
- move_to_tank：移し替え先の桶の番号（天地返しのときだけ。無ければ空）
- findings：所見のチェック欄。☒ を checked、☐ を unchecked として写す
- memo：色・香り・その他の手書きのメモ。原文のまま
- worker：担当の名前または印。書かれた文字のまま

【status の付け方】（項目ごと）
- ok ............ 値が読み取れている
- blank ......... 欄はあるが何も書かれていない
- unreadable .... 文字はあるが読めない
- uncertain ..... 読めたが確かでない（チェック欄の判定が怪しい、字が二通りに読める）
迷ったときに ok を選ばないでください。

【厳守事項】
- 桶の番号・日付・量を補ったり直したりしないでください。
  「12」は「12」のまま。前後の記録票から棟を推さないでください。
- 日付から経過の月数や予定の月を計算しないでください。
- 量の単位を換算しないでください。単位が書かれていなければ unit を空にしてください。
- 所見のメモを要約したり、問題の有無を判断したりしないでください。
- 熟成が十分か、出してよいかについて書かないでください。
- 略し方の一覧にある言葉は一覧のとおりに直し、
  一覧に無い言葉は memo に原文のまま入れてください。
- evidence には、その項目の根拠にした文字列をそのまま写してください。
- 記録票でない紙と判断した場合は、record_type_mismatch を true にして、
  項目を書き分けないでください。

【略し方の一覧】{abbreviation_list}
【記録票の本文】{markdown_content}

「棟を推さない」と名指しで書かないと、補います。 同じ日の記録票の多くが A 棟なら、AIはそれを手がかりに埋めます。禁じるのは「それらしい値に寄せる」ことそのものです。

出力形式を固定する

次の形の JSON で受け取ります。 Azure OpenAI の構造化出力で、response_format に json_schema と strict: true を指定します。

{
  "record_type": "shikomi | tenchigaeshi | tenken",
  "record_type_mismatch": false,
  "items": [
    { "field": "tank_no", "value": "A-12", "unit": "",
      "status": "ok | blank | unreadable | uncertain", "evidence": "A-12" }
  ],
  "findings": [
    { "label": "たまり", "state": "checked | unchecked", "status": "ok | uncertain" }
  ],
  "memo": "",
  "other_words": []
}

1つ目の理由は、構造化出力の決まりに合わせて、あとの処理を固定できることです。 公式のページによると、構造化出力ではすべての項目を required にし、すべての object に additionalProperties: false を付けます。任意の項目は、null との組み合わせの型で表します。項目が抜けることが無いので、スクリプトは毎回同じ列を読めます。

2つ目は、文字列の長さや数値の範囲の制約に頼らない設計にしてあることです。 Azure OpenAI の構造化出力は、文字列の minLength・maxLength・pattern・format、数値の minimum・maximum、配列の minItems・maxItems などに対応しません。桶の番号の形（英字1文字と数字2桁）や量の範囲は、スキーマではなくスクリプトの側で確かめます。 1つの schema の object のプロパティは合計100個まで、入れ子は5段までという上限にも収まる形にしてあります。

3つ目は、status と台帳の更新を別の層に置けることです。 AI が付けるのは項目ごとの status までで、台帳へ書き込むか・人に回すかはスクリプトの規則で決めます。

日付が前回より前の記録は、日付か桶の番号のどちらかが誤っています。 どちらかは決めずに、両方を人に見せます。

システムへ連携する

台帳の本体には直接書き込みません。 更新の案は「確認待ち」のシートに書き出し、事務の担当が確かめたものだけを本体へ移します。桶の番号を1つ取り違えた更新を本体に入れると、2つの桶の熟成の履歴が同時に壊れます。

出荷の予定表の下書きは、計算の結果だけを載せます。 載せるのは「予定の月が今月か来月の桶」「天地返しの予定日を過ぎて記録が無い桶」「直近の点検でカビ・たまり・異臭にチェックがある桶」の3つの一覧です。3つ目は所見の有無を並べるだけで、良し悪しは書きません。

人が確認する

人が開くのは、照合できなかったもの・日付の前後がおかしいもの・unreadable と uncertain を含むものだけです。 それ以外の更新の案は、桶の番号と日付を一覧で流し見て本体へ移します。

1. 照合できなかったものを先に見る … 画像を開き、桶の番号を目で読みます。多くは棟の記号の書き忘れで、書いた職人に聞けば1分で解決します
2. 日付の前後がおかしいものを見る … 前回の記録と並べ、どちらが誤っているかを決めます
3. 信頼度の低い項目を見る … チェック欄の判定と、かすれた数字を画像と見比べます
4. 直したら記録する … どの項目を、何から何へ直したかを残します

責任者は出荷の予定表の下書きを見て、味見をする桶を選び、味見の結果で出す月を決めます。

目標は、300枚をならして1枚2分です。 開くのは2割前後という想定で、それより多い月は、紙の汚れが増えているか、桶のマスタが実際の配置とずれています。

例外に対処する

大半は紙の扱いと記録票の書き方の問題です。 桶の番号の欄に棟の記号を印刷しておくだけで、照合できない記録票は大きく減ります。

記録を残す

• 元の記録票の画像・PDF と、撮影日時・経路（スキャン／タブレット）
• レイアウトモデルが返した JSON の全文と Markdown の本文
• 生成AIの書き分けの結果（items、findings、status）と、そのとき使った略し方の一覧の版
• 照合の結果と、台帳の更新の案
• 人が直した記録 … どの項目を、何から何へ直したか、誰が直したか
• 出荷の予定表の下書きと、責任者が味見をして決めた結果

略し方の一覧の版を残すのは、 新しい職人が入ると一覧が増え、過去の書き分けをやり直す範囲を決めるのに要るためです。

保管の期間は3年にそろえます。 先に見た手引書が、衛生管理の一連の記録を3年間保管するよう書いているためで、熟成の記録も同じ棚・同じ期間で管理すると、保健所の求めにも同じ場所から出せます。