勤怠の二重打刻チェックを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つのシステムに存在することになりました。二重打刻は仕様なのです。意図せず起きているのではなく、構造的にそうなっています。 2つのシステムの打刻が一致しているか確認し、間違いを本人に連絡して修正させる――これが照合作業の全体像です。 VBAが登場する前、担当者は両方のシステムを自分の目で見比べていました。1件ずつ開いて、メモして、比べるという作業です。

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

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

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

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

VBAの限界と課題

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

VBAにはそれ以外にも配布の問題や、バージョン管理の煩雑さがありました。この点については過去のシリーズで書きましたので、ここでは繰り返しません。

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でシステムを作れるようになった分、「壊れたときに直せる」という強みもついてきました。

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

設計ミスは恥ずかしいものですが、直すことができました。それで十分だと思っています。 無料プレゼント Excel業務を自動化する前に確認するチェックリスト（PDF） 自動化していい作業かどうか、VBAかPythonか、最初に避けるべき落とし穴。実務でよく迷うポイントを1枚にまとめました。メールアドレスだけで受け取れます。

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

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