消防設備点検の会社が点検員の手書きの点検票を読み取り、建物ごとの不良箇所を報告書に添える一覧と改修の見積依頼にそろえる

処理の起点を決める

1棟の点検を終えた時点で、点検員がタブレットから全枚を送信したことを起点にします。 送信先は Cloud Storage の受付用のバケットで、建物番号ごとのフォルダに画像が入ります。最後に「送信完了」の小さなファイル（枚数を書いたもの）を置き、これが置かれたときに1棟分をまとめて処理します。

1枚ずつ処理を始めない理由は、点検票の不足を調べるためです。 1枚ずつだと、まだ撮っていない設備と、撮り忘れた設備の区別がつきません。1棟分がそろったときに、物件の台帳の設置設備と突き合わせます。

夕方にまとめて送る形にもしません。 現場ごとに送れば、食い違いの確認が点検員が次の現場へ移動している間に届きます。 夕方まとめると、翌日の朝まで誰も答えられません。

入力データを集める

質を決めるのは、下の3つです。 設置設備の一覧が無ければ、点検票が1枚足りなくても気づけません。点検項目の一覧が無ければ、生成AIは読み取った文字列をどの項目のものとして扱うかを推測で決めます。 言い換えの表が無ければ、見積依頼の書き方が点検員の数だけ残ります。

点検項目の一覧は、消防庁の様式の点検票から作ります。 様式は消防用設備等ごとに定められていて、千葉市の案内では、平成31年4月に改正された様式が使われているとされています。様式が変わったときに一覧も直す、という運用にします。

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

読み取りは、Python から Form Parser のプロセッサを呼ぶだけです。オンライン処理は1回の要求あたり15ページまで（imageless_mode を有効にすると30ページまで）なので、1棟6〜8枚ならまとめて1回で送れます。 ファイルの大きさはオンライン処理で40MB、画像の解像度は40メガピクセルが上限です。

判定の欄は、○×を書く様式と、チェックを入れる様式があります。 チェックボックスは、表の中では ✓ や ☐ の文字として、キーと値のペアでは filled_checkbox／unfilled_checkbox として返ります。どちらで返ってきたかを残し、生成AIに渡す前にそろえます。

物件の台帳と点検項目の一覧は、Python がスプレッドシートから読みます。建物番号が先、建物名は確認用です。 建物名から引くと、「〇〇ハイツ」と「〇〇ハイツ第2」を取り違えます。

AIへ渡す前に整形する

1. 枚数の確認 … 送信完了のファイルに書かれた枚数と、バケットの画像の数を比べます。足りなければ処理を止め、点検員に再送を頼みます
2. 形式と大きさ … JPEG と PNG を受け付けます。40MB と40メガピクセルを超えるものは縮めます。JPEG を何度も保存し直すと画質が落ちるとされているので、撮影した元の画像から1回だけ縮めます
3. 向きと傾き … 横向きに撮られたものを回転します
4. 解像度 … 公式の案内では、スキャンは最低200dpi、300dpi以上で一般に最良の結果とされています。A4 を撮影して200dpi相当に届かない画像は、撮り直しの印を付けます
5. 設備の種類の見分け … 点検票の上部の様式名（「消火器具」「自動火災報知設備」など）を OCR のテキストから拾い、点検項目の一覧のどれを当てるかを決めます
6. 重複の検知 … 同じ設備の点検票が2枚あれば、どちらも残して印を付けます。片方を捨てる判断はしません

4番目は、現場の撮影で一番崩れるところです。 機械室や屋上は暗く、点検票を手で持ったまま撮ると傾きます。撮影の手引きに「点検票を平らな面に置き、枠が画面いっぱいに入るように」と1行書くだけで、読めない欄が減ります。

AIに処理させる

させるのは、読み取り結果を点検項目に対応づけ、欄の中身をそのまま書き写すことです。 加えて、不良内容を見積依頼に使える形（設備・設置場所・数量・不良の内容）に分けて書き直させます。

右端の列の「推測で埋めない」が、この構成でいちばん守りたい線です。 「202 煙感 NG」とあれば、設置場所は「202号室」、数量は1と読めます。しかし「煙感 NG」だけなら、どの部屋か分かりません。 ここで物件の台帳の設置階から「たぶん2階」と埋めると、見積依頼に間違った場所が載り、工事課が現地で探し回ることになります。

1行目と2行目は、生成AIがいちばんやりたがることです。 ×が付いて不良内容が空なら「軽微な不良」と書き、不良内容があって判定が○なら「×の書き忘れ」と判断して直そうとします。どちらも、現場を見ていない者の推測です。

指示内容を固定する

あなたは消防用設備等の点検会社の業務課で、点検員が手書きした点検票を
清書の下書きに起こす担当です。OCRの読み取り結果だけを見て書き写してください。
推測で埋めないでください。判定を書き換えないでください。

【入力】
- 点検票の種類：{equipment_type}（例：自動火災報知設備）
- 点検項目の一覧：{item_list}（項目コード、大項目、小項目の名前）
- OCRの読み取り結果：{ocr_result}（表の行、テキスト、信頼度、位置）
- 不良内容の言い換えの表：{wording_table}

【やること】
1. 読み取った各行を、点検項目の一覧のどの項目コードに当たるか対応づける。
   当てはまる項目が無い行は item_code を null、match を "unmatched" とする。
2. 判定の欄を judgement に書き写す。値は "ok"（○）、"ng"（×）、
   "na"（該当なし・斜線）、"blank"（空欄）、"unreadable"（読めない）のどれか。
3. 不良内容の欄を defect.raw にそのまま写す。読めない文字は「〓」とする。
4. 不良内容から、設置場所（階・部屋・系統）と数量を分けて取り出す。
   書かれていなければ null とする。物件の情報から補わない。
5. 言い換えの表に当てはまる言い方は defect.normalized に正式の書き方で書く。
   当てはまらなければ defect.raw と同じにする。
6. 措置内容の欄を action.raw に写す。

【厳守事項】
- judgement を、不良内容の有無を見て変えないでください。
  ×なのに不良内容が空欄でも、○なのに不良内容があっても、そのまま写してください。
- 設置場所と数量を、ほかの行や物件の情報から推測しないでください。
- 「異常なし」「良」などの文字は、判定の欄にあれば ok、不良内容の欄にあれば
  defect.raw に写したうえで、判定は判定の欄の記載だけで決めてください。
- 改修が必要か、どの部品を交換すべきか、費用がいくらかを書かないでください。
- confidence には OCR が返した値をそのまま入れてください。
- 読み取り結果に点検票でない書類が含まれる場合は document_type に種類を書き、
  items を空にしてください。

「判定を不良内容の有無を見て変えない」を、例を挙げて書いているのが要です。 抽象的に「書き換えない」とだけ書くと、生成AIは「整合させる」ことを良いことだと考えて直します。食い違いをそのまま残すことが仕事だと、具体的な2つの型で伝えます。

設置場所を補わない指示も同じです。 物件の台帳を渡していないのに、別の行の「2F」を見て補うことがあります。「ほかの行から推測しない」まで書いて、行をまたいだ補完を止めます。

出力形式を固定する

Claude API の構造化出力で、次の形の JSON を受け取ります。 構造化出力は output_config.format に type: "json_schema" でスキーマを渡すと有効になり、オブジェクトには additionalProperties: false が必要です。数値の minimum・maximum は使えないので、信頼度が0〜1に収まっているかは Python の側で確かめます。

{
  "building_id": "B-0412",
  "document_type": "inspection_sheet",
  "equipment_type": "自動火災報知設備",
  "header": { "inspection_date": "", "inspector": "", "inspection_kind": "機器点検" },
  "items": [
    {
      "item_code": "AFA-2-03",
      "match": "matched | unmatched",
      "judgement": "ok | ng | na | blank | unreadable",
      "defect": { "raw": "202 煙感 NG", "normalized": "煙感知器 作動不良",
                  "location": "202号室", "quantity": 1 },
      "action": { "raw": "" },
      "confidence": 0.0,
      "page": 3
    }
  ]
}

1つ目の理由は、判定と不良内容を別の欄に置けることです。 judgement と defect.raw が別々にあるので、食い違いは Python が機械的に拾えます。

2つ目は、点検票の不足を数えられることです。 物件の台帳の設置設備と equipment_type を突き合わせ、設置されているのに点検票が無い設備を一覧にします。

3つ目は、前回の不良と比べられることです。 前回の不良箇所と item_code・location が同じ不良は「再発」の印を付けます。前回の改修が終わっていないのか、直したのにまた壊れたのかは、点検員と工事課が確かめます。

システムへ連携する

報告書の作成ソフトへは書き込みません。 業務課が確認を終えた下書きを、既存の取り込みの手順で入れます。未確認の判定が報告書に入る経路を作らないためです。

物件の台帳も読むだけです。 今回の不良を前回の不良の列に書き戻すのは、報告書が確定した後に業務課が行います。確定前の不良を書き戻すと、次の点検で「再発」の印が誤って付きます。

人が確認する

1. 業務課が印の付いた欄を見る … unreadable、blank、unmatched、信頼度の低い欄。確認の画面に画像の該当箇所を並べ、読み取りの誤りはその場で直します
2. 点検員が食い違いと不良の内容を確かめる … ×と不良内容の食い違い、設置場所や数量の抜け、点検票の不足。チャットで届いた一覧に答えます。判定を直せるのは点検員だけにします
3. 点検員が不良箇所の一覧を見る … 言い換えた書き方が現場の不良と合っているか。見積依頼の内容は、ここで決まります
4. 業務課が報告書を仕上げ、見積依頼を送る … 下書きを確かめてから工事課へ送ります

2番目で、業務課が判定を直さないことを決めておきます。 業務課は画像を見られますが、現場は見ていません。読み取りの誤り（×を○と読んだ）は業務課が直し、記入の食い違い（×なのに空欄）は点検員に聞く。 この線を引いておかないと、忙しい月に業務課の推測で埋まります。

目標は、1棟あたり15分です。 ○ばかりの点検票は一覧で流し見て終わり、時間を使うのは印の付いた欄と不良箇所だけにします。

例外に対処する

2行目と6行目は、AIの読み取りとは関係の無い確認です。 撮り忘れか点検し忘れかは画像からは分かりませんが、報告書を出す前に気づければ取り返せます。

記録を残す

• 点検票の元の画像と、撮影・送信の日時、建物番号、点検員
• OCR が返した JSON の全文
• 生成AIの出力（items）と、使ったプロンプトの版、点検項目の一覧と言い換えの表の版
• 業務課と点検員が直した記録 … どの欄を、何から何へ、誰が直したか
• 確定した不良箇所の一覧と、送った見積依頼
• 点検員ごとの unreadable と食い違いの件数

4番目は、報告書の内容を後から説明するために残します。 建物の管理者や消防署から問い合わせがあったとき、手書きの原本、読み取り、人の修正の順にたどれることが必要です。

最後の行は、書き方の手引きと撮影の手順を見直す材料です。