現場の手書き作業日報を読み取って生産実績に反映する

処理の起点を決める

共有フォルダに新しいスキャンファイルが置かれたことを、定期実行で確認します。 n8n の Schedule Trigger は、秒・分・時・日・週・月・cron式の7種類の間隔を設定できます。30分ごとに確認する設定にすれば、午前中に回収した日報が昼までに処理されます。

リアルタイムである必要はありません。 ただし、「翌日」から「当日中」に短縮することには意味があります。 遅れや不良の発生に、その日のうちに気づけるためです。

なお、セルフホストの n8n では既定のタイムゾーンが America/New_York です。環境変数で変更するか、ワークフロー側でタイムゾーンを設定してください。

入力データを集める

「過去の自由記述 → コード」の対応が、振り分けの精度を決めます。 「キズ」という同じ記述が、設備によって違うコードに振り分けられている、という実態が見えます。その実態ごと学習させるのが正しい形です。

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

OCR： 2つのモデルを組み合わせます。

1. カスタム抽出モデル … 日報の様式が固定しているので、これが本命です。同じ様式の書類が5件あれば学習を始められます。 項目の位置が決まっているため、「この枠の中の数字」として読み取れます
2. prebuilt-read … 手書きかどうかの判定に使います。Read モデルは、各テキスト行が手書きかどうかを分類し、確からしさのスコアを付けて返します（styles の中に isHandwritten と confidence が入ります）。また、抽出した単語ごとに confidence が返ります

この confidence が、この構成の要です。 数値項目の confidence がしきい値を下回ったものを、人の確認に回します。

入力の要件を確認してください。 抽出する文字の高さは、1024×768の画像で12ピクセル以上が目安とされています（150dpiの8ポイント相当）。複合機のスキャン解像度を300dpi以上に設定してください。 200dpiだと、小さく書かれた数字が読めません。

マスタ類： 生産管理システムから日次でエクスポートしたファイルを参照します。リアルタイム連携は不要です。

AIへ渡す前に整形する

1. ファイルの分割 … 複合機の一括スキャンは、数十枚が1つのPDFになります。1ページ1日報として分割します
2. 向きの補正 … 上下逆に置かれた日報があります。日報の様式に含まれる固定の文字列（表題など）の向きで判定し、回転させます
3. 解像度の判定 … 300dpi未満のものを弾きます。読めないものを無理に読ませないことが重要です
4. 重複の検出 … 同じ日報が2回スキャンされることがあります。「日付＋作業者番号＋設備番号」で重複を検出します
5. 白紙・非日報の除外 … 仕切り紙や別の書類が混ざります。様式の固定文字列の有無で判定します
6. 既登録の確認 … 同じ日付・作業者の実績が既に登録されていないかを確認します。二重登録は在庫と原価を狂わせます

AIに処理させる

OCRとLLMで役割を分けます。

OCR（Document Intelligence）にさせること： 枠内の文字と数字の読み取り、手書きかどうかの判定、確からしさの算出。数値の読み取りはここで完結させます。LLMに数字を推測させません。

LLMにさせること：

LLMに数値を読ませないでください。 数値はOCRの出力をそのまま使い、確からしさが低ければ人に回します。LLMに「この日報の良品数は何個ですか」と画像を渡して聞く構成にすると、確からしさが得られず、誤りの検出ができません。

振り分けについても、既存のコードからのみ選ばせます。 新しい不良区分をAIに作らせると、集計が崩れます。

指示内容を固定する

あなたは、製造現場の作業日報の入力を支援する担当者です。
OCRで読み取られた日報の内容から、自由記述の区分への振り分けと、
確認すべき点の洗い出しを行ってください。

【厳守事項】
- 数値を読み取ったり、書き換えたりしないでください。
  良品数、不良数、時間はOCRの結果をそのまま引き継いでください。
  OCRが読めなかった項目を、あなたが推測して埋めないでください。
- 不良区分・停止区分は、下記のコード一覧からのみ選んでください。
  新しいコードを作らないでください。
  該当するものがない場合は code を null にし、
  needs_review に「区分に該当なし」と入れてください。
- 自由記述が空欄の場合、区分を推測しないでください。
  「不良数が記入されているが、内容が空欄」として needs_review に入れてください。
- 標準時間との乖離について、原因を断定しないでください。
  「稼働時間3.0時間に対し標準は5.2時間（乖離42%）」という事実だけを書き、
  「段取りに手間取ったと思われる」と推測しないでください。
- 現場への確認文は、作業者がその日のうちに答えられる形で書いてください。
  「不良の詳細を教えてください」ではなく、
  「不良3個の内容が空欄です。外観・寸法・その他のどれでしたか」と書いてください。
- 備考欄の記述のうち、作業者の体調や勤務態度に関する記述は転記しないでください。

【不良区分のコード一覧】
{defect_codes}

【停止区分のコード一覧】
{stoppage_codes}

【この設備・この品番の過去の振り分け実績（直近12か月）】
{past_classifications}

【OCRの読み取り結果】
{ocr_result}

【マスタ照合の結果】
作業者: {worker} / 設備: {machine} / 製造指示: {order} / 品番: {item}
標準加工時間: {standard_time} / 標準段取り時間: {standard_setup_time}

【整合の計算結果】
{consistency_check}

「数値を読み取ったり、書き換えたりしないでください」の1行が、この構成の安全装置です。 これを書かないと、OCRが空で返した良品数を、LLMが「指示数量と同じでしょう」と埋めます。その数字は原価計算に入ります。

「原因を断定しないでください」も外せません。 「段取りに手間取ったと思われる」と書かれると、担当者がそのまま停止区分を選んでしまいます。事実だけを示し、判断は人に残します。

出力形式を固定する

{
  "report_id": "",
  "page_image": "",
  "extracted": {
    "work_date": { "value": "", "confidence": 0.0, "is_handwritten": true },
    "worker_no": { "value": "", "confidence": 0.0, "matched": "" },
    "machine_no": { "value": "", "confidence": 0.0, "matched": "" },
    "order_no": { "value": "", "confidence": 0.0, "matched": "" },
    "item_code": { "value": "", "confidence": 0.0, "matched": "" },
    "good_qty": { "value": null, "confidence": 0.0 },
    "defect_qty": { "value": null, "confidence": 0.0 },
    "setup_minutes": { "value": null, "confidence": 0.0 },
    "run_minutes": { "value": null, "confidence": 0.0 },
    "stop_minutes": { "value": null, "confidence": 0.0 }
  },
  "classified": {
    "defect_code": "",
    "defect_text": "",
    "defect_basis": "",
    "stoppage_code": "",
    "stoppage_text": "",
    "stoppage_basis": ""
  },
  "consistency": [
    {
      "check": "run_time_vs_qty | setup_vs_standard | qty_vs_order | time_total",
      "result": "ok | deviation | cannot_check",
      "detail": ""
    }
  ],
  "low_confidence_fields": [],
  "missing_fields": [],
  "needs_review": [],
  "confirmation_to_site": ""
}

すべての読み取り項目に confidence を持たせます。 これがないと、どの数字を疑うべきかが分かりません。確認画面では、しきい値を下回った項目を色分けします。

matched は、マスタ照合の結果です。読み取った作業者番号がマスタにない場合、matched は空になります。マスタにない番号を自動で登録しないでください。

defect_basis には、その区分を選んだ根拠（過去の振り分け実績のどれに基づくか）を入れます。担当者が「なぜこのコードか」を確かめられるようにするためです。

なお、Claude API には出力をJSONスキーマに沿わせる構造化出力の機能があります（2026-09-15時点ではベータ機能として提供）。項目数が多く後段が機械処理なので、利用できると安全です。

システムへ連携する

承認後、生産管理システムへ実績を登録します。連携方法は3通りあります。

国産の生産管理システムでは、実績のCSV取込が用意されていることが多く、まずそこを確認してください。 APIの有無と仕様は、自社の生産管理システムのベンダーに確認が必要です。この部分は利用環境に応じた個別確認になります。

日報の画像は、登録した実績と紐づけて保管します。あとから「この数字はどの日報から来たのか」を追えるようにするためです。

人が確認する

全件、人が承認します。段階的な自動化もしません。

理由は、実績値が在庫・原価・納期の計算に直結するためです。誤った良品数が登録されれば、在庫が合わなくなり、棚卸まで気づきません。

ただし、確認の重さを分けます。

確認を速くするための設計が重要です。

• 確認画面で、日報の画像と読み取り結果を左右に並べて表示する
• OCRが読み取った箇所を、画像上でハイライトする（座標が返るので実装できます）
• 数値項目は、確からしさの低いものだけにカーソルが飛ぶようにする
• 1枚ずつではなく、同じ設備・同じ日の日報をまとめて表示する

これらがないと、確認に2.5分かかり、削減効果が出ません。

例外に対処する

記録を残す

• 日報のスキャン画像（原本。実績と紐づける）
• OCRの読み取り結果（生の状態。confidence と座標を含む）
• LLMが振り分けた区分コードと、その根拠
• 整合の確認結果
• 承認者、承認日時
• 人が修正した項目と、修正前後の値
• 現場への確認と、その回答

「人が修正した項目と、修正前後の値」が二重に効きます。 ひとつは読み取り精度の実測値になること。「良品数は98%そのまま通るが、設備番号は15%修正されている」と分かれば、どこを改善すべきかが決まります。 もうひとつは、不良区分の振り分けの基準が蓄積することです。

紙の日報は、法令や社内規程で定めた保存期間に従って扱ってください。 電子化したから廃棄してよいとは限りません。品質記録として保存が求められる場合があります。