警備会社で警備員が施設ごとに手書きする巡回記録と警備日誌を読み取り、巡回時刻・異常の有無・引継ぎ事項を契約先への月次報告書にそろえて、巡回の抜けを拾う

処理の起点を決める

施設ごとのフォルダにファイルが保存されたことを起点にします。 隊長が勤務明けにスキャンし、その日のうちに読み取りまで終わらせます。月初めにまとめて流す形にはしません。 まとめると、抜けに気づくのが翌月になるという今の問題がそのまま残ります。

フォルダは施設ごとに分け、ファイル名は「施設コード_日付」に決めておきます。 施設を読み取り結果から推定させると、同じ書式を使う施設どうしで取り違えます。施設と日付はファイルの置き場所と名前から決め、OCRには中身だけを読ませます。

処理が終わったファイルは処理済みのフォルダへ移します。移すのは成功したときだけです。 施設のフォルダに残っている数が、そのまま未処理の数になります。月次報告書の下書きは、毎月1日の朝に前月分をまとめて作る定時の処理にします。

入力データを集める

質を決めるのは、巡回計画の表です。 計画が「夜間3回程度」のような文章のままだと、何をもって抜けとするかが決まりません。回ごとに予定の時刻と許す遅れの幅（たとえば30分）を数字で持たせます。 契約先と取り決めた幅がなければ、そこから決める必要があります。

チェックポイントの一覧は、巡回記録表の行の並びと同じ順にします。 表の何行目がどのチェックポイントかを、書式ごとに対応表で持ちます。現場ごとに書式が違うため、書式の種類ごとに1つずつ対応表を作ります。

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

読み取りは、ワークフローからレイアウトモデルを呼ぶだけです。PDFを送ると、ページごとの結果が返ります。

時刻は、表のセルの内容と単語の信頼度を両方見ます。 セルの内容が「22:05」でも、その数字の単語の信頼度が低ければ「2:05」や「22:55」の読み違いかもしれません。セルの内容だけを使うと、信頼度の情報が落ちます。

警備日誌は、Markdown 形式の出力を使うと読みやすくなります。 outputContentFormat=markdown を指定すると、表は HTML の表として、段落は段落として並びます。結合されたセルもそのまま表せます。生成AIへ渡すのはこの Markdown にします。 座標の情報を落とした分だけ、渡す量が減ります。

巡回計画と施設マスタは、表を読むだけで足ります。参照するのは、その日の時点で有効だった計画です。 計画を途中で変えた月は、変更日をまたいで2つの計画を使い分けます。

AIへ渡す前に整形する

1. 形式の確認 … PDFまたは画像（JPEG、PNG、BMP、TIFF、HEIF）であることを確かめます
2. ページ数とサイズの確認 … PDFとTIFFは最大2,000ページ、有料（S0）レベルで500MBまでです。1日分の綴りなら十分に収まります
3. 画像の寸法の確認 … 50×50ピクセルから10,000×10,000ピクセルの間である必要があります
4. 解像度の確認 … 抽出するテキストの最小の高さは、1024×768の画像で12ピクセル（150dpiで約8ポイント）です。巡回記録表の欄は狭く、時刻を小さく書く人の字は、この下限に近づきます
5. ページの種類の振り分け … 綴りの中の巡回記録表と警備日誌を、表の有無と見出しの文字で分けます
6. パスワードの解除 … 複合機の設定でPDFにパスワードが付く場合は、提出前にロックを解除する必要があります
7. 同じ日の重複の検知 … 同じ施設・同じ日付のファイルが2つあれば、後のものを差し替えとして扱い、前の結果を残します

4番目は、スキャンの設定で決まります。 複合機の既定のまま白黒・低い解像度でスキャンすると、鉛筆で書いた時刻がかすれます。現場の複合機の設定を、最初に一度そろえてください。

AIに処理させる

生成AIにさせるのは、警備日誌の文章を項目に分けることだけです。 巡回記録表の時刻の比較は、前処理の後でプログラムが行います。

右端の列でいちばん大事なのは、「対応済みと推測しない」です。 日誌に「水漏れ発見、設備担当へ連絡」とあっても、直ったとは書いていません。報告書に「対応済み」と載せるかどうかは、書かれていることだけで決めます。

指示内容を固定する

あなたは警備会社の本社で、現場の警備日誌を読んで
契約先への報告の材料を整理する担当です。
以下はOCRで読み取った1日分の警備日誌です。書かれていることだけを使い、
推測で補わないでください。

【取り出す項目】
1. 異常（設備の故障、水漏れ、警報の作動、施錠の不備など）
2. 不審事案（不審な人・車・物、立ち入りの制止）
3. 対応（誰に連絡したか、何をしたか、いつ終わったか）
4. 鍵の貸出と返却、時間外の来訪
5. 引継ぎ事項（次の勤務者や翌日への申し送り）

【厳守事項】
- 日時・場所・対応が書かれていなければ「不明」としてください。
  前後の記述から推測して埋めないでください。
- 「連絡した」と書かれていても、解決したとは扱わないでください。
  resolved は、終わったことが明記されているときだけ true にします。
- 欄の外や余白に書かれた記述も対象にしてください。
- 読み取れない、または意味の確定しない文字列は、直さずに
  unreadable_spans にそのまま写してください。
- 人の名前は書き出さず、「来訪者」「設備業者」「テナント従業員」のように
  役割で書いてください。
- 巡回の回数や時刻についての評価はしないでください。
- 事案の重さや、契約先への報告の要否は書かないでください。
- evidence には、根拠にした日誌の文字列をそのまま写してください。

【施設】{facility_name}（{facility_type}）
【日付】{date}
【警備日誌（Markdown）】
{journal_markdown}

「連絡した」を「解決した」と扱わない、を明記しないと、多くの記述が対応済みになります。 警備日誌は、発見と連絡までを書き、その後の結果は翌日以降に書かれることがよくあります。解決を推測で埋めると、翌月の報告書から未解決の事案が消えます。

人の名前を書き出さない指示も最初から入れます。 警備日誌には、来訪者、テナントの従業員、不審者として声をかけた人の名前が書かれることがあります。報告書に要るのは出来事で、個人の名前ではありません。

出力形式を固定する

生成AIの出力は、構造化出力（JSON スキーマ）で受け取ります。 Claude API では output_config.format に json_schema の形でスキーマを渡すと、その形に沿った JSON が返ります。オブジェクトには additionalProperties: false が必要で、数値の minimum ／ maximum などの制約は使えません。 値の範囲の確認は、受け取った後にプログラムで行います。

{
  "facility_code": "",
  "date": "",
  "events": [
    {
      "category": "equipment | suspicious | key_visit | other | 要確認",
      "time": "",
      "location": "",
      "description": "",
      "action_taken": "",
      "resolved": false,
      "evidence": ""
    }
  ],
  "handover": [ { "text": "", "evidence": "" } ],
  "unreadable_spans": [ "" ]
}

巡回記録表の側は、プログラムが次の形にそろえます。AIの出力と同じファイルには入れず、別の層として持ちます。

{
  "facility_code": "",
  "date": "",
  "rounds": [
    {
      "round_no": 1,
      "planned_start": "22:00",
      "recorded_start": "22:05",
      "recorded_end": "22:40",
      "min_confidence": 0.0,
      "checkpoints_marked": 18,
      "checkpoints_total": 20,
      "status": "done | late | not_recorded | unreadable"
    }
  ]
}

1つ目の理由は、巡回の判定と日誌の整理を別々に直せることです。 遅れの幅を変えたいときはプログラムの設定だけ、取り出す項目を足したいときはスキーマだけを直します。

2つ目は、status の4つの値をプログラムの規則で決められることです。

3行目と4行目の区別が、この構成でいちばん大事なところです。 何も検出されていなければ not_recorded、検出されていて信頼度が低ければ unreadable。根拠を、OCRが返した数値に置きます。 チェックポイントの印が一部欠けている回は done のまま checkpoints_marked に数を残し、報告書では「一部未確認」として扱うかを業務課が決めます。

システムへ連携する

契約先へは、この構成から何も送りません。 月次報告書は下書きまでで、送るのは業務課と営業です。巡回の抜けを含む報告は、契約の継続に関わるからです。

巡回計画の表にも書き込みません。 遅れが毎日同じ回に出るなら、それは計画が現場に合っていないのかもしれませんが、計画を変えるのは契約先との取り決めです。

人が確認する

1. 翌朝、知らせのあった日だけを見る … not_recorded と unreadable があった施設と日です。業務課が画像を開き、本当に空欄か、かすれているだけかを目で確かめます
2. 隊長に理由を聞く … 空欄が本当なら、巡回しなかったのか、書き忘れたのかを隊長が答えます。答えは日別一覧の「理由」の欄に残します
3. 月末に下書きを読む … 異常の件数と記述、resolved が true の事案の根拠、引継ぎの抜けを確かめます
4. 営業が契約先向けの言い回しを決める … 巡回の遅れや抜けをどう書くかは、契約先との関係を知っている営業が決めます

1番目を翌朝にするのが、時間を減らす鍵です。 毎日1施設あたり数十秒で済む確認を、月初めに30日分まとめて行うと、また1日分4分に戻ります。

目標は、900件をならして1件1分です。 done だけの日は一覧で流し見て数秒、知らせのあった日と事案のある日は画像と下書きを見るので数分かかります。

例外に対処する

6行目は、運用の取り決めとして先に書いておきます。 この構成は勤務明けの記録を読むもので、事案の第一報を担う仕組みではありません。 急ぎの連絡の手順は今のまま残します。

記録を残す

• 元のスキャンのPDFと、保存した日時・施設・隊長
• OCRが返したJSONの全文（表、選択マーク、単語と信頼度、styles）
• 巡回の判定結果（rounds）と、そのとき参照した巡回計画の版
• 生成AIの出力（events、handover、unreadable_spans）
• 隊長が答えた抜けの理由と、答えた日時
• 業務課が下書きを直した箇所と、直す前の文
• 施設ごとの unreadable の発生率

2つ目の「巡回計画の版」を残すのは、計画が後から変わるためです。 契約の変更で回の時刻が変わると、過去の late の意味が変わります。当時の計画が残っていないと、契約先から問われたときに説明できません。

最後の行は、現場の改善の材料になります。 特定の施設だけ unreadable が多いなら、書式の欄が狭いか、スキャンの設定が合っていません。