安全書類のチェック、何時間かけていますか？
下請各社が提出する16種類の書類を一枚一枚目視で確認し、元請名称の(株)有無や所長名の誤記まで突合する作業は、現場代理人の隠れた負担です。
私は 現役施工管理18年・JV現場代理人 として、この苦行をAIに任せられないかと考え、Claude Code を使った安全書類自動チェックシステムを自主開発しました。
2026年2月に現場に入り、約4ヶ月の開発・改良を経て、これまでに 46社分の安全書類整理 に活用しています。
この記事では、施工管理がAI開発に挑むときに 必ずぶつかる3つの壁 と、その乗り越え方を、開発ログから具体的に紹介します。
「AIで現場仕事を減らしたい」と考えている同業の方の 設計指針 として活用してください。
なぜ施工管理がAI開発に手を出したのか
正直に言えば、安全書類のチェック作業が嫌いだったから です。
JV案件の現場では、ざっと以下の量の確認作業が発生します。
- 下請業者：一次〜三次まで多数（現状で 整理した業者は46社）
- 提出書類：1社あたり16種類（再下請通知書・建設業許可証・主任技術者資格証明書など）
- 突合項目：元請名称・所長名・許可番号・社保情報・現場代理人名 etc.
これを 目視で全数チェック していると、半日では終わりません。
しかも何度確認しても、後から「(株)が抜けている」「所長名が一文字違っている」といった指摘が入ります。
人間の集中力には限界があると痛感しました。
システム全体像｜何を作ったのか
ざっくりした構成は以下です。
- 入力：下請各社が提出した安全書類PDF（16種類）
- 処理①：Gemini OCR で書類内のテキスト・印影位置を読み取り
- 処理②：Claude が業務ルールに基づいて元請書類と突合
- 出力：差し戻しが必要な箇所を「赤入れ指示書」として自動生成
- 進捗管理：業者別の進捗を JSON で正本管理し、HTML で可視化
技術スタックは Python + Gemini API + Claude API + Claude Code（CLAUDE.md による業務ルール記述） という構成です。
図解すると、書類PDFが入ると赤入れ指示書が出てくる「業務専用パイプライン」をひとつ作ったイメージです。
教訓①｜OCRに凝るのは「遠回り」だった
開発初期、私は OCRの精度を上げること に時間をかけすぎました。
具体的には、Windows 標準の OCR と Gemini OCR を組み合わせる「ハイブリッドOCR構成」を検討していました。
しかし、開発ログ#1 を書きながら立ち止まったとき、本質的な問いに気づきました。
「文字認識の精度を上げても、領域の取り違えが残れば頻出ミスは消えない」
つまり、書類のどこに何が書いてあるかという 座標ベースの分割 を先に固めなければ、いくらOCRを磨いても効果が出ないのです。
施工管理の業務ミスの多くは「読み間違い」より「見落とし・取り違え」から発生します。
ここで方針を転換し、ハイブリッドOCRはフェーズ3に先送りしました。
💡 学び：AIで業務を自動化するときは、OCRや認識精度の前に「書類のどこを見るか」の構造化が先。
教訓②｜「精度」と「カバレッジ」のジレンマ
次にぶつかったのは、定型フォーム検出器を3様式に拡張するときの選択でした。
ユーザー（自分）の問いはシンプルでした。
「ミスは許されないが、早く正確に作業したい場合は？」
選択肢は3つ。
- A：1様式をピクセル単位まで詰める（精度最大）
- B：3様式を概略レイアウトで揃える（カバレッジ最大）
- C：中庸（突合キーだけ精密化）
最初は A（精度最大）に惹かれました。
ところが、よく考えると A の最大リスク は「対応していない別書類で全項目素通り」してしまうことです。
精度を1%上げるより、検出可能な様式を増やすほうが業務リスクの削減効果が大きい という結論に至りました。
最終的に選んだのは B（カバレッジ優先）。
そして、もうひとつ重要な気づきがありました。
「完璧を目指さず、不確実性を明示的に返す設計」
「○マーク（チェックマーク）」を密度ベースで判定すると、文字数の差で逆転判定が起きます（『加入』2文字 vs 『未加入』3文字）。
これは bbox 精度の問題ではなく、密度ベースというアプローチの構造的限界 でした。
そこで信頼度を階層化しました。
- ◎ 円形検出が単一 → 最高信頼度で確定
- ✓ 密度比が明確差 → 確定
- ? 密度比が曖昧 → LLM で再判定
- ・ 全候補が薄い → チェックなし
「最後の数%」の精度より、「判定不能を見える化」する仕組みのほうが、現場では強いのです。
教訓③｜「整える日」を意図的に作る
3つ目の壁は、開発を進めれば進めるほど、環境がカオスになる ことでした。
ある朝の状況確認では以下の問題が積み上がっていました。
- 検証中の素材が積み上がっている（20時間分以上）
- API キーが PCに点在
- Python 環境の汚染（venv が複数）
- 重い依存ライブラリが何重にも
これを放置したまま新機能を足していくと、再現性が崩れて後戻りできなくなります。
そこで「業務を進める日」と「環境を整える日」を分けることにしました。
「整える日」は業務を進めない
具体的には以下のようなチェックを行います。
- gitignore のパターン穴を埋める（`samples/*.png` の除外漏れなど）
- 重い依存は隔離する（OCR用 Python は専用 venv に分離）
- 既存運用を壊さずに git を導入する手順を確定
これは現場で言えば「安全大会の日は工事を止める」のと同じ発想です。
進めるだけでは、いずれ事故が起きます。
4ヶ月で46社を整理してわかったこと
このシステムを 2026年2月から現場で運用 し、これまでに 46社の安全書類整理 に使ってきました。
何ができるようになったか。
- 安全書類16種類のチェックを 半日 → 約1時間 に短縮
- 元請名称・所長名などの 頻出ミスをほぼゼロ に
- 業者別進捗が HTMLで一目で見える 状態に
- 「今月誰が何を出していないか」を即答可能
何が残っているか。
- 印影の照合は精度が安定せず、半自動運用
- 新しい業者の様式追加時は、座標マスタの調整が必要
- 印刷物の傾き補正は、まだチューニング中
完璧ではありません。
しかし「ゼロから手で全部やる」と比べれば、現場代理人の時間は 明らかに取り戻せた と言い切れます。
正直に言えば、開発を始めたのは2026年2月、まだ わずか4ヶ月 です。
それでも 46社分のチェックを潜らせた経験から、改良の方向性は十分に見えてきました。
次に作るもの｜施工計画書・工程表シリーズへ
安全書類の自動チェックは、施工管理の業務AI化のうち 入口のひとつ に過ぎません。
次に取り組んでいるのは以下の2つです。
- 施工計画書のたたき台を Claude Code に作らせる
- 工程表（バーチャート）を AI に骨格出力させる
このシリーズでは、現役施工管理が 実際に試して動いたもの だけを記録していきます。
理論や提案ではなく、動いた実装 を共有することが、このサイトの独自軸です。
💡 シリーズ予定
第1弾（本記事）：安全書類チェック自動化
第2弾：施工計画書のたたき台生成
第3弾：工程表の骨格自動生成
まとめ｜施工管理がAI開発に挑むときの3原則
最後に、現役施工管理が AI で業務を自動化するときの 3つの原則 をまとめます。
- ① OCR・認識精度に凝る前に、書類のどこを見るかを構造化する
- ② 完璧な精度より、不確実性を明示できる設計を優先する
- ③ 「整える日」を意図的に作り、環境のカオスを管理する
施工管理の現場には、目視で何時間もかかる繰り返し作業 が無数に隠れています。
その一つひとつを Claude Code に肩代わりさせるだけで、現場代理人の時間は確実に取り戻せます。
「AIなんて自分には関係ない」と思っていた方こそ、まず 手元の最も嫌な作業ひとつ をAIに任せる実験から始めてみてください。
施工管理18年が断言します。現場のAI活用はもう、できる人とできない人で差がつく段階に入っています。
あわせて読みたい
- 大手ゼネコン5社のAI活用事例をまとめた記事 → 施工管理AI活用事例7選
- 次回（公開準備中）：Claude Codeで施工計画書のたたき台を作る方法
- 次々回（公開準備中）：工程表（バーチャート）の骨格をAIに作らせる方法
AIで時間を取り戻したら、活かせる現場へ
業務効率化で時間が浮いても、それを許す現場や評価する会社でなければ、努力は報われません。
「もっと裁量のある現場で働きたい」「AI活用を歓迎する会社に移りたい」と感じたら、建設業特化の転職エージェントを使うのが近道です。
：建設業特化・資格取得サポートありどちらも登録・相談は無料です。
コメント