LPガスの販売会社が保安点検・調査の手書きの記録票を読み取り、不良の項目と再調査の要否を保安の台帳に転記する

処理の起点を決める

スキャンした記録票がフォルダに保存されたことを起点にします。 点検員が営業所に戻ってスキャンすると、その日の夕方のうちに読み取りが終わり、翌朝には担当者の確認の一覧ができています。 1日1回の夜間の一括処理にしないのは、否のある票を早く見たいからです。通知した日から期間が数えられるので、登録が数日遅れると、再調査の予定を立てるのが遅れます。

保存先は営業所ごとに分け、ファイル名にスキャンした日時と営業所を入れます。 複合機でまとめて数十枚を1つのPDFにする運用でも、後段で1件ずつに分けます。

処理が終わったファイルは処理済みのフォルダへ移し、移すのは成功したときだけにします。 元のフォルダに残っているファイルが、そのまま未処理の数になります。

入力データを集める

質を決めるのは、下の3つです。 設備の区分が無いと、記録票のどの項目が今回の対象なのかが分からず、空欄が「対象外」なのか「書き忘れ」なのかを区別できません。 不良区分の一覧が無いと、所見を区分にそろえる先がありません。

期間の決まりは、顧問や保安業務の責任者と一度決めて設定に持ちます。 「一月を経過した日」をどう数えるかを担当者ごとに決めていたことが、第3章の（c）の原因です。

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

読み取りは、Azure Functions からカスタム モデルを呼ぶだけです。このとき、追加機能のバーコードの抽出を有効にします。 公式ページでは、バーコードの抽出は無料の追加機能で、QRコードに対応し、値と種類と位置が返るとされています。顧客番号を手書きから読むのではなく、印字したQRコードから読むので、顧客の取り違えが起きません。

チェック欄の信頼度は、2つを合わせて見ます。 公式ページでは、選択マークを持つフィールドは、フィールドの選択と選択マークそのものの信頼度を組み合わせたものが全体の信頼度をよく表すとされています。どちらかが低ければ、判読不能 にします。

保安管理のシステムからは、顧客番号で設備の区分と今回の予定だけを引きます。氏名や電話番号は、この処理では使いません。

AIへ渡す前に整形する

1. 1件ずつに分ける … まとめてスキャンしたPDFを、QRコードが出てくるページで区切ります
2. 向きを確かめる … 読み取り結果のページの角度を見て、逆さのものは回して読み直します
3. 画像の寸法を確かめる … 50×50ピクセルから10,000×10,000ピクセルの間である必要があります
4. 文字の大きさを確かめる … 抽出できる文字の最小の高さは、1024×768の画像で12ピクセルで、150dpiで約8ポイントの文字に当たります。チェック欄と所見の小さい字のために、300dpiでスキャンします
5. ファイルの大きさを確かめる … 有料（S0）レベルで500MBまでです。1日分を1つにまとめても届きませんが、上限を設定に持ちます
6. 二重のスキャンを見つける … 同じ顧客番号と点検日の票が直近にあれば、二重に読まずに印を付けます
7. 様式の版を確かめる … QRコードに様式の版を入れておき、学習に使っていない古い版は 読み取り要確認 に回します

4番目を軽く見ないでください。 複合機の既定の設定は200dpi前後のことが多く、鉛筆の細いチェックが選択マークとして拾われないことがあります。 読めなかったチェックと、書かれていないチェックは、画像を見ないと区別がつきません。

7番目は、様式を変えるときに効きます。 テンプレート モデルは見た目の様式に頼るので、欄の位置を変えた新しい版は、学習し直すまで正しく読めません。 版をQRコードに入れておけば、混在している時期でも取り違えません。

AIに処理させる

OCRにさせるのは、記録票に書かれていることをそのまま値にすることです。 生成AIにさせるのは、所見の手書きを不良区分の候補にそろえ、短い要約を作ることだけです。

3行目がこの構成でいちばん大事な区別です。 対象外の項目の空欄は正常で、対象の項目の空欄は点検員の書き忘れです。 設備の区分を引かずに空欄をすべて同じに扱うと、書き忘れが「対象外」に紛れます。

1行目を外さないでください。 生成AIに所見を渡すと、「ゴム管に亀裂」から「否とすべき」と結論を書きたがります。チェックが適で所見に亀裂と書いてあれば、それは食い違いとして人に回すもので、AIが否に直すものではありません。

指示内容を固定する

あなたはLPガスの保安機関で、点検・調査の記録票の所見を
保安の台帳の不良区分にそろえる事務の担当です。
点検員が手で書いた所見の文と、その票の項目ごとのチェック結果だけを見てください。
推測で埋めないでください。

【やること】
1. 所見の文を、不良区分の一覧の中から最も近い区分の候補にそろえる（最大2つ）
2. 所見を、台帳の備考欄に入れる40字以内の要約にする
3. 所見の文が、どの項目のことを書いているかを、項目コードで示す
4. 所見とチェック結果が食い違っているように見える場合は、mismatch に書く

【厳守事項】
- 所見に書かれていないことを足さないでください。
  「交換を勧めた」「次回確認」などの文が無ければ、要約にも入れないでください。
- 技術上の基準に適合するかどうか、否にすべきかどうかを書かないでください。
- 不良区分の一覧に無い区分を作らないでください。
  近いものが無ければ category_candidates を空にし、category_unknown を true にしてください。
- 読めない字は「〓」のまま残してください。
  前後の文脈から字を補わないでください。
- 日付、期限、再調査の時期を書かないでください。
- 測定値を書き換えたり、基準と比べたりしないでください。
- 所見の欄が空なら、全項目を空にして returned_empty を true にしてください。

【不良区分の一覧】{defect_categories}
【この票の項目ごとのチェック結果】{check_results}
【所見の文（OCRの結果のまま）】{remarks_text}

「否にすべきかを書かない」を明記しないと、要約に結論が入ります。 所見に亀裂と書かれていれば、何も言わなければ「否」と添えます。禁じるのは、点検員の判断を上書きすること自体です。

「〓」を残させるのは、読めなかった字を補わせないためです。 「ゴム管に亀〓」を「亀裂」と直すのは正しいことが多いのですが、直してよいかは画像を見た担当者が決めます。 補った字が台帳に入ると、元の記録票と違う記録が残ります。

出力形式を固定する

読み取りと判定の結果を、1票ごとに次の形のJSONにまとめます。 生成AIが返すのは remarks の部分だけで、構造化出力でスキーマを固定します。公式ページでは、構造化出力はJSONスキーマへの準拠を保証し、Chat Completions では response_format、Responses では text.format にスキーマを置き、strict を true にするとされています。

{
  "sheet_id": "",
  "form_type": "supply_inspection | consumer_survey",
  "form_version": "",
  "customer_no": "",
  "inspected_on": "",
  "items": [
    { "code": "C-07", "in_scope": true,
      "status": "適 | 否 | 判読不能 | 二重記入 | 記入なし",
      "measured_value": "", "confidence": 0 }
  ],
  "signature": "あり | なし",
  "remarks": {
    "category_candidates": [],
    "category_unknown": false,
    "summary": "",
    "related_items": [],
    "mismatch": "",
    "returned_empty": false
  },
  "revisit": { "required": false, "window_start": "", "window_end": "" },
  "verdict": "転記可 | 否あり要確認 | 読み取り要確認"
}

1つ目の理由は、items と verdict と revisit を別の層に置けることです。 items はOCRの結果から機械的に埋め、revisit はプログラムが日付から数え、verdict は規則で決めます。期間の数え方を見直しても、直すのは revisit の計算だけです。

2つ目は、in_scope で空欄の意味を分けられることです。 設備の区分から対象でない項目は in_scope を false にし、空欄でも 記入なし にしません。

3つ目は、confidence が一覧で読めることです。 担当者は画像を開く前に、どの項目の何が低かったのかを見られます。

システムへ連携する

保安管理のシステムへは、この構成から書き込みません。 担当者が確かめたあとに登録します。システムに取り込み用の機能があれば、確定した行だけを書き出して取り込みます。読み取り結果をそのまま流し込む経路は作りません。

保安管理のシステムが API を持たない場合は、毎晩、顧客番号と設備の区分と予定を書き出してもらい、それを引く形でも足ります。

人が確認する

担当者が開くのは 否あり要確認 と 読み取り要確認 の票だけです。 転記可 の票は一覧で件数と顧客番号を流し見て、まとめて登録します。

1. 否あり要確認 を先に見る … 否の項目、所見の要約、再調査の期間の候補を、記録票の画像と並べて確かめます
2. 通知した日を確かめる … 点検員が否の通知を渡した日が、点検日と同じかを確かめます。期間はこの日から数えます
3. 読み取り要確認 を見る … 二重記入、読めなかったチェック、対象の項目の空欄を画像で確かめ、分からないものは点検員に聞きます
4. 不良区分を決める … 候補から選ぶか、別の区分にします
5. 判定を直したら記録する … どの項目を、何から何へ直したかを残します

2番目を省かないでください。 否の通知を後日に郵送した家では、通知の日が点検日と違います。 点検日から数えると、再調査に行く時期が早すぎて期間の外になります。

目標は、600件をならして1件2分です。 開くのは否のある票と読めなかった票で、それより多い月は、スキャンの設定か、点検員のチェックの書き方を見直す合図です。

例外に対処する

上の5行が大半を占めます。 どれもAIの精度より、記録票の作り方とスキャンのしかたの問題です。 QRコードの印字を大きくする、チェック欄を広くする、といった様式の直しのほうが早く効きます。

記録を残す

• スキャンの原本と、営業所・スキャンした日時
• Document Intelligence が返した結果の全文（チェック、測定値、所見、QRコード、信頼度）
• 判定の結果（items、verdict、revisit）と、そのとき引いた設備の区分
• 生成AIに渡した所見の文と、返ってきた remarks
• 人が判定や区分を直した記録 … どの項目を、何から何へ
• 登録した日時と、登録した担当者
• 点検員ごとの 判読不能 と 二重記入 の件数

3つ目で設備の区分を残すのは、区分が後から変わるためです。 燃焼器を入れ替えた家では対象の項目が変わり、当時の区分が残っていないと、過去の判定がなぜそうなったかを説明できません。

最後の行は、点検員にチェックの書き方を伝える材料になります。