飲食店・給食の現場で手書きされる冷蔵庫と加熱の温度記録を読み取り、基準を外れた記録と記入漏れを拾って、店舗別の月次の点検表にする

処理の起点を決める

店舗用の受付フォルダに画像が保存されたことを起点にします。 フォルダは店舗ごとに分け、店舗のコードをフォルダ名にします。どの店舗の記録表かを、画像の中身から推定させないためです。 店名の書き方は記録表によって違い、略称や手書きで書かれていることもあります。

読み取りと照合は保存のたびに動かし、点検表は月初の定時実行でまとめます。 前月分の記録表が届いた店舗から読み取りを進め、月の3営業日目の朝に、届いた記録表で点検表を作り、届いていない店舗を一覧にします。 記録表が届かない店舗は、点検の対象から抜け落ちやすいからです。

受付フォルダは Azure Blob Storage のコンテナーにし、Azure Functions の Blob Storage トリガーで動かします。 遅延の小さいイベントベースの実装が推奨されており、失敗したファイルは既定で計5回まで再試行され、すべて失敗すると専用のキューに記録されます。月初の点検表を作る前に、そのキューが空であることを確かめます。 同じ画像を二度保存したときは、ファイル名と撮影日で同じ記録表かを見分け、新しいほうを読み、古いほうの読み取り結果を差し替えます。

入力データを集める

質を決めるのは、基準の表です。 計画のPDFに書かれた基準を、店舗・機器ごとに1行ずつ起こします。冷蔵庫の基準を「10℃以下」のように1つにまとめず、機器ごとに持ちます。店舗が冷蔵庫を入れ替えたときに、表の更新を忘れると、正しい記録が基準外に見えます。

営業日の表は、記入漏れと休業日を分けるために持ちます。 休業日の空欄を記入漏れとして返すと、店舗は点検表を信用しなくなります。

加熱の条件の表には、同等とする組み合わせを並べます。 中心部を75℃で1分間の加熱と同等の条件として、70℃で3分、69℃で4分、68℃で5分、67℃で8分、66℃で11分、65℃で15分が妥当と考えられるとされています。どの組み合わせを自社の計画で採るかは品質管理部が決め、表にはその結果だけを入れます。

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

列の見出しは、読み取り結果と様式の対応表の両方で決めます。 見出しが手書きで「冷1」「冷2」と書かれている様式では、読み取りだけでは機器が決まりません。様式の版ごとに列の並びを表にしておけば、見出しが読めなくても列の位置で機器を決められます。

数字の信頼度は、単語ごとの confidence を使います。 セル全体の読み取りが確かでも、小数点やマイナスの記号だけが薄いことがあります。 値を作る単語の信頼度のうち、最も低いものをその欄の信頼度にします。

AIへ渡す前に整形する

1. 形式の確認 … PDFと画像（JPEG・PNG・BMP・TIFF・HEIF）であることを確かめます
2. 画像の寸法の確認 … 50×50から10,000×10,000ピクセルの間である必要があります
3. 文字の大きさの確認 … 抽出するテキストの最小高さは、1024×768の画像で12ピクセル（150dpiで約8ポイント）です。1か月分を1枚に詰めた表は、欄が小さく、この下限に近づきます
4. ページの確認 … 1つのファイルに複数の記録表が入っていれば、表ごとに分けます。PDFとTIFFは最大2,000ページ、有料（S0）レベルで500MBまでです
5. 月の確認 … 記録表の年月の欄を読み、ファイル名の年月と合わなければ担当者へ回します

3番目を軽く見ないでください。 レイアウトモデルの案内でも、ドキュメントごとに1つの明確な写真か高品質のスキャンが勧められています。斜めや遠くから撮った写真は、文字の高さが下限を割ります。店舗には、表が画面いっぱいに入るように真上から撮る撮り方を案内します。

AIに処理させる

させるのは、読み取られた表のセルを「日付・時間帯・機器・値・記入者」の行にそろえることだけです。

3行目がいちばん起きやすい失敗です。 冷凍庫の欄に「18」とだけ読めると、冷凍庫だから −18 だろうと補います。補った値はたいてい正しいのですが、マイナスが本当に書かれていなかった場合、それは冷凍庫が止まっていた記録かもしれません。 補わずに人へ回します。

指示内容を固定する

あなたは飲食店チェーンの本部の品質管理の担当として、店舗が手書きした
温度記録表を、点検のための行にそろえる立場です。
渡すのは Azure AI Document Intelligence のレイアウトモデルが返した
表のセル（行・列の位置、文字、信頼度、手書きかどうか）と、
この記録表の様式の対応表です。
読み取り結果に書かれていることだけを使ってください。推測で埋めないでください。

【やること】
- 表のセルを、date / time_slot / equipment / value / unit / recorder /
  corrective_action / manager_check の行にそろえてください。
- 時間帯と機器は、様式の対応表の列の位置で決めてください。
  決められないセルは status を ambiguous にしてください。
- value には、セルに書かれた文字をそのまま入れてください。

【厳守事項】
- 値を直さないでください。「3」か「8」か、「1」か「7」か迷う文字は、
  読み取られた文字のまま入れ、status を low_confidence にしてください。
- 記号を補わないでください。マイナスの記号が読み取られていなければ、
  冷凍庫の欄でもマイナスを付けないでください。sign_unclear を true に
  してください。
- 空欄は value を空にし、status を blank にしてください。
  前後の日の値や、ほかの機器の値で埋めないでください。
- 「休」「—」「停止」などの書き込みは、value に書かれたとおり入れてください。
- 是正の欄は、書かれた文を原文のまま入れてください。要約しないでください。
- 基準内か基準外か、是正が十分かどうかは書かないでください。
- confidence は読み取り結果の値のうち、その欄で最も低いものを入れてください。

【読み取り結果】{layout_result}
【様式の対応表】{form_map}

「マイナスを補わない」を明記しないと、冷凍庫の欄では必ず補います。 冷凍庫の温度がマイナスであることは常識なので、AIにとって補うことは親切な訂正に見えます。 禁じるのは、読めなかった記号を読めたことにする判断です。

出力形式を固定する

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

{
  "store_code": "",
  "form_type": "cold_storage | cooking | general_hygiene",
  "year_month": "",
  "rows": [
    {
      "date": "",
      "time_slot": "morning | evening | other",
      "equipment": "",
      "value": "",
      "unit": "celsius | minutes | check",
      "sign_unclear": false,
      "recorder": "",
      "corrective_action": "",
      "manager_check": "",
      "status": "ok | blank | ambiguous | low_confidence",
      "handwritten": true,
      "confidence": 0
    }
  ]
}

1つ目の理由は、判定をプログラムに渡せることです。 rows を基準の表と営業日の表に照らし、AIではなく Azure Functions が次の区分を付けます。

2つ目は、needs_review を判定より先に人へ回せることです。 読み取りが不確かな欄は、基準と照らす前に担当者が原本で値を直し、直した値で判定をやり直します。 読み違いから out_of_range が出ることを防ぎます。

3つ目は、点検表を件数の表にできることです。 店舗ごとに、out_of_range・no_corrective・missing・no_manager_check の件数と、該当する日付を並べます。店舗が月をまたいでどう変わったかが、件数の推移で見えます。

構造化出力ではすべてのフィールドを必須にし、オブジェクトに additionalProperties: false を付けます。数値の範囲の制約はスキーマで書けないため、値を数として読めるかの確認はプログラムで行います。

システムへ連携する

点検結果の表へは、担当者が確定してから書き込みます。 needs_review の欄が残ったまま件数を出すと、読み違いの件数が店舗の成績として残ります。

人が確認する

担当者が見るのは、needs_review と out_of_range、no_corrective の欄です。

1. needs_review を先に見る … 原本の画像で値を確かめ、読み違いなら値を直します。直した値で判定をやり直します
2. out_of_range を原本で見る … 信頼度が高くても、基準外の欄は画像で値を確かめます
3. no_corrective を店舗に確かめる … 是正をしたが書いていないのか、是正をしていないのかを聞きます
4. 点検表を確定する … 件数と日付を確かめ、是正の依頼の下書きを直します

2番目を省かないでください。 基準外の記録は、店舗にとっては指摘の記録です。 読み違いで指摘された店舗は、次の月から記録を丁寧につけるのではなく、本部の点検を疑うようになります。

目標は、120枚をならして1枚6分です。 多くの記録表は件数を確かめて終わり、基準外や読みにくい欄が多い記録表だけに時間を使います。needs_review が多い店舗は、撮り方か記入のしかたに理由があります。

例外に対処する

上の2行が大半を占めます。 どちらもAIの問題ではなく、撮り方と様式の管理の問題です。 撮り方の案内を1枚の紙にして店舗に貼ってもらうほうが、読み取りの精度を上げるより効きます。

記録を残す

• 記録表の画像と、受け取った日時・店舗コード
• レイアウトモデルが返した読み取り結果の全文
• そろえた行のJSONと、そのとき使った様式の対応表の版
• 判定の結果と、そのとき照らした基準の表・営業日の表の版
• 担当者が直した値と、直す前の値
• 確定した点検表と、店舗へ送った是正の依頼
• 店舗ごとの needs_review の発生率と、no_corrective の件数の推移

4つ目で基準の表の版を残すのは、基準が後から変わるためです。 機器の入替えや計画の見直しで基準が変わったあとに照合し直すと、過去の月の判定が変わってしまいます。

原本は店舗で保管し、本部に残すのは画像と読み取り結果です。 どちらを記録の正本とするか、何年保存するかは、衛生管理計画の記録の保存の定めに合わせて先に決めます。