勤怠の二重打刻チェックをPythonで自動化したら、現場の「例外ケース」に一発で壊された話｜AIで1時間以内に直した全記録

自動化は「作って終わり」ではない。これを身をもって知ったのは、苦労してPythonで組んだシステムが。ある月の照合でおかしな結果を返し始めたときだった。

犯人は「現場の例外」ではなかった。自分の設計ミスだった。

基幹と勤怠、意図的な二重打刻

まず、うちの会社では、基幹システムと勤怠管理システムの2つが並走している。どちらも「人の時間」を記録しているように見えて、目的がまったく違う。

基幹は工事管理が主役だ。誰がどの現場に何時に入って、見積はいくらで、注文書と請書の受領は済んでいるか。検収書の発行はいつか——そういう情報が入る。現場ごとの入退場時刻は記録されているが、それはあくまで工事単位の記録であって。「この人が今日何時間働いたか」という視点では設計されていありません。

午前中にA現場で8時から13時まで作業して、移動して。午後からB現場で14時から17時まで作業する。このパターンが当たり前に発生する。基幹にはA現場の8:00-13:00とB現場の14:00-17:00が個別に入るが。「この人の1日の労働時間は何時間か」という問いには答えてくれない。なお、現場間の移動時間は通勤と同じ扱いで、労働時間には含まれない。A→Bの1時間移動は休憩時間として計算する。これが後で設計ミスの温床になる。

次に、だから勤怠管理システムを別に入れた。一般的なオフィスワーカーと同じように、出勤・退勤・休憩を打刻してもらう。

結果、同じ人の同じ日のデータが2つのシステムに存在することになった。二重打刻は仕様だ。意図せず起きているのではなく、構造的にそうなっている。

VBAでの照合ツールの限界と課題

2つのシステムの打刻が一致しているか確認して。間違いを本人に連絡して修正させる——これが照合作業の全体像です。

一方で、VBAが登場する前、担当者は両方のシステムを自分の目で見比べていた。1件ずつ開いて、メモして、比べる。

作業員が打刻した勤怠データを、担当者が一件ずつ目視で確認していた。勤務実績と申請内容のズレを手作業で突き合わせる。作業員数や現場数が多い月は確認対象も膨大で、集計から確認。修正依頼まで長時間かかった。繁忙期は半日から1日以上。担当者にとって、月末の一番しんどい仕事がこれだった。

少ない拠点で5〜10名、多いところは60〜80名。後者を担当する人は、締め日前後に1日の半分以上をこの作業だけに費やしていた。

そのため、ExcelVBAで照合ツールを作ったのは、そのためだ。ファイルサーバーに置いてある2つのCSVを読み込んで、比較結果を一覧表示する。照合自体は数秒で終わる。

VBAの限界と課題

ただ、問題は照合後だ。「この人の5日の打刻が合っていない」と分かっても、本人に連絡して。修正してもらって。また確認する——このやり取りはVBAがあってもなくても変わらない。ツールが解決したのは「発見するまでの時間」だけだった。

VBAにはそれ以外にも配布の問題、バージョン管理の煩雑さがあった。この話はArc4シリーズで書いたので繰り返さありません。

AIとPythonでVBA脱却、CSV突合システム

しかし、VBAをやめてPythonで作り直した。

正直に言う。生成AIがなければ無理だった。CSVを読んで比較してGUI表示するシステムを、独力で0から書ける気はしない。でも「こういうCSV形式で、こういう照合ロジックで。こういう画面を出したい」と伝えながら進めれば、書けた。

やり方はシンプルだった。実現したい業務内容と、必要な画面・機能を整理して、それをAIに伝える。出てきたコードを動かして、おかしければ修正を依頼する。その繰り返し。生成されたコードをそのまま使えることはほとんどなかったが、「ここが違う。こう直したい」と伝え続けることで、少しずつ業務に合う形になっていった。

さらに、CSV突合の仕組み自体はVBAと同じだ。基幹から出力した就業情報CSVと、勤怠管理システムから出力したCSVを読み込んで。社員番号と日付をキーに照合する。複数現場をまたぐ場合は、基幹側の複数行を集約して1日の労働時間として計算する。

動いた。照合精度も上がった。しばらくは問題なく使えていた。

設計想定の甘さで生じた運用バグ

運用から少し経ったころ、照合結果がおかしい、という声が上がり始めた。

まず、気づいたのは担当者だった。「なんか件数がおかしい」「この人。合ってるはずなのに×になってる」——そういう違和感の積み重ねだ。実際のデータと照合結果を突き合わせてみると、確かにズレがある。システムが間違った結果を出していた。日々画面を見ている人間の感覚が、バグの早期発見につながった。

一番ハマったのが複数現場の矛盾打刻だ。正しくはA=8:00-13:00。B=14:00-17:00（移動1時間は休憩扱い）なのに。実際の打刻がA=8:00-13:00。B=12:00-17:00になっているケース。基幹に入っている終了と次の開始が重複している。このデータを集約すると、休憩時間の計算がマイナスになる。最初の設計ではそのマイナスをそのまま計算に使っていた。アラートも出なかった。

掘っていくと他にも甘い部分が出てきた。手配枠はあるのに日報の時刻が未入力の行を「データなし」と判定してスルーしていたこと。法定休憩が不足していても2システムの時刻が「一致」していれば◎を出してしまっていたこと。どれも「そういうケースが存在しうる」という想像が最初から足りなかった。

AIデバッグ、方針転換で迅速解決

次に、ロジックのどこが問題なのか、自分では特定できなかった。コードを読み返しても、どこを直すべきか分からない状態だった。

生成AIにコードと状況を貼り付けた。

最初はうまくいかなかった。AIが比較ロジックに問題があると推測して修正案を出すが、直らない。別の箇所を直す。まだおかしい。そのうちUIコードを全面的に書き直す提案が出て。それを適用したら今度は既存の関数シグネチャが壊れた。直そうとして別のところを壊す、という最悪のループに入りかけた。

一方で、立ち止まって方針を変えた。「全部書き直す」のをやめて、「最小限だけ変える」に切り替える。原因を比較処理ではなく月次表示のロジック側に絞り込んで、そこだけを直す。既存の構造は触らない。その方針転換で、ようやく正しいエラー判定が出るようになった。

1時間かからなかった。「この条件分岐が抜けている」「この計算がマイナスになりうる」と指摘して。修正案まで出してくれた。自分でデバッグしていたら半日以上かかっていたと思う。もしかすると諦めていたかもしれありません。

修正したのは大きく3点——手配あり日報なしの検出ロジック追加。法定休憩不足時の強制NG判定、複数現場の矛盾打刻へのアラート処理。いずれも「こういうケースが存在しうる」という想像が最初から足りなかった部分です。

AIシステム：現場の現実への修正と信頼

そのため、自動化システムを作ることと、現場で使えるシステムを作ることは、別の話です。

正常ケースだけで設計していると、現場は必ず想定外を持ち込む。矛盾した打刻、未入力の枠、法定違反スレスレのシフト。「おかしい人がいるせい」ではなく、現場の日常です。

VBAの時代は、そもそもPythonで書けなかった。生成AIがなければ、今もそうだっただろう。でも生成AIでシステムを作れるようになった分。「壊れたときに直せる」という話も同時についてくる。

しかし、修正後、月次・日次ともに判定が安定した。これまで見逃していたケースも確実に検知できるようになった。担当者の反応は「現場の感覚と合うようになった」「ようやく安心して使える」。その一言が、一番の答えだと思った。

設計ミスは恥ずかしい。でも直せた。それで十分だと思っている。

関連リンクとチェックリスト

学習サービスとアンケート