PC ログで残業を確かめる前に。分からない日を埋めると「問題なし」に見える

「打刻のあとも、PC を使っていないか確かめたい」。PC のログで残業を確かめたい、という話は人事や労務の人からよく出る。ログがあれば分かりそうに見える。

ある会社（約90名）で、Mac のログを勤怠と突き合わせたい、という依頼を受けた。特に欲しいのは退勤の時刻だ。

10月分を、14人、延べ246日（1人の1日を1日と数える）で、退勤の打刻と Mac のログを照らし合わせた。Mac を閉じた時刻が分かったのは80日だけだった。残りの166日は、閉じた時刻が分からなかった。

表を埋める方法はある。「その日の最後のログイン」を退勤の代わりに入れれば、全部の日に数字が入る。勤怠と比べる表（以下、比較の表）では、それをやめて空欄にした。埋めると、分からない日が「差なし」に見えるからだ。

先に3つ断っておく。この記事で使う「30分」は自分が置いた仮の線で、先方の基準はまだ答えをもらっていない。労働時間にあたるかどうかの法的な判断はしない。そして、これは「PC のログは使えない」という話ではない。眠った記録まで Mac に残っていた10日間は、約9割の日で閉じた時刻が分かった。例は Mac だが、確かめることは Windows でも同じだ。コマンドや集計の細かい話は、後半の「担当者向け」にまとめた。

▼何が起きたか：延べ246日のうち、Mac を閉じた時刻が分かったのは80日

依頼の中身はこうだ。勤怠のデータにも PC ログの列はあるが、Mac を閉じた時刻は分からない。だから Mac 側でも取ってほしい。月に1回、ログインとログオフの時刻を日本時間の表にして、勤怠の記録と突き合わせたい。

ところが、会社の Mac をまとめて管理しているサービス（JumpCloud）を調べると、残っているのはログインだけだった。閉じた時刻の記録がない。そこで、Mac の中に残る記録を毎日読み取って貯める小さなプログラムを作り、Mac に配った。

これを打刻と比べると、延べ246日のうち、閉じた時刻が分かったのは80日だった。そのうち、打刻より30分以上あとまで Mac が開いていた日は27日（30分は仮の線）。以下、これを「30分以上の差」と書く。

「30分以上の差が27日」だけを聞けば、多いのか少ないのか読めない。分母が246なのか80なのかで話が変わるし、残りの166日に何があったかは、この数字からは何も言えない。だから差を読む前に、閉じた時刻が分かる日を数える。

比べた14人は、Mac のログと勤怠のデータを氏名で結びつけられた人だ。結びつかなかった分は、対象外でよいかを確かめる。

▼原因：Mac が眠った記録は約2週間で消える。閉じた時刻が分かる日数は、貯め始めた日で決まっていた

80日を時期で分けると、理由が見える。

差を分けたのは、記録がいつまで Mac に残っていたかだ。Mac は眠った・目覚めたの記録を中に持っているが、古い分から消えていく。すぐ読める場所は Mac によって数日から1週間ほどで消え、元になる記録も約2週間で消える。

順番に書くとこうなる。

• ▶ 10月9日：依頼を受けた
• ▶ 11月4日：貯めるプログラムを配った。さかのぼれたのは10月28日まで
• ▶ 11月5日：約2週間残る別の場所があると分かり、そこも読むように直して配り直した。10月22日まで戻った

別の場所は毎日1日分ずつ消える。配るのが1日遅れると、取れる日が1日減る状態だった。10月21日より前の眠った・目覚めたの記録は、もう残っていなかった（手元の Mac で確認。ほかの Mac もほぼ同じ期間だった）。

10月1日〜21日の8日は、シャットダウンやログアウトの記録で閉じた時刻が分かった日だ。こちらは長く残る。ただし蓋を閉じて眠らせるだけで使い続ける人が多く、そういう日には残らない。

先に貯め始めていれば、10月分はもっと取れた計算だ（推定）。一方で、ログが残っていた10日間は約9割の日で閉じた時刻が分かった。貯め始めたあとの結果は、11月分を集計してから分かる。

▼判断の分かれ目：最後のログインで埋めず、空欄にした。埋めると、分からない日が「差なし」に見える

一度は入れていた

最初から空欄にしていたわけではない。表の形は3回変わった。

• ▶ 1回目（Mac の月次の表。以下、Mac の表）：閉じた記録がない行に、最後のログインを色付きで入れた。「これより後は分からない」と注記した
• ▶ 2回目（比較の表の最初の版）：閉じた時刻がある日と、最後に閉じた記録がない日を分けた。後者は「少なくともこの分は動いていた」という下限として、差の分数も出した
• ▶ 3回目（比較の表の今の版）：最後に閉じた記録がない日の差を、空欄にした。これが自分の判断だ

Mac の表は、Mac の記録を並べる表なので今も1回目の形だ。空欄にしたのは、打刻との差を計算する比較の表のほうだ。

埋めると何が起きるか

閉じた時刻が分からなかった166日は、2つに分かれる。埋めた場合と空欄の場合を並べると、空欄にした理由が見える（30分は仮の線）。

ログインは「そこから使い始めた」時刻で、「そこで終わった」時刻ではない。最後に閉じた記録がなければ、そのあといつ閉じたかは分からない。だから埋めた数字は、実際より短い側にしかずれない。

一番困るのは129日だ。最後のログインが打刻より前なら、表の上では「打刻の前に終わった」と読める。実際には、ログインのあと打刻を越えて開いていたかもしれない。分からない日が、問題のない日に化ける。確かめたくて始めた作業が、確かめていない日に「問題なし」の印を押すことになる。

37日にも同じことが起きる。差の分数は入るが、それは「少なくともここまで」の数字だ。閉じた時刻の27日に、ログインだけの27日を足せば54日になる。ただしこの2つは別の種類の数字で、足すと同じ「差の分数」の列に2つの意味が入る。読む人には分けられない。

補足すると、「最後のログイン」も仕事の終わりの目印にはなりにくい。この会社の10月分では、1人1日のログインは中央値で4回あった。画面ロックの解除まで数えている可能性が高い（未確定）。

消さずに残したもの

空欄は、なかったことにする意味ではない。37日は備考に時刻を残した。分かるのは「その時刻に Mac が動いていた」だけで、それ以上は言わない。37日のうち27日は、打刻から30分以上あとのログインがある。差の列に数えないことは、「問題なし」という意味ではない。

▼一番の注意：差が出ても、残業の日数とは読まない。同じ「PC ログ」でも、差の出る日は4日と20日

30分以上の27日のうち、12日は放置で止まった日だった

閉じた時刻が分かった80日のうち、30分以上の差は27日あった。これをそのまま残業の日数とは読まない。

27日のうち12日は、放置で眠った、または画面が消えた日だ。この日の閉じた時刻には、最後の操作から自動で眠るまでの時間が入っている。かといって12日を引いて残りを数えることもしない。放置の前まで仕事をしていた日もありうるからだ。

Mac が開いている時間は、操作していた時間ではない。差があっても、それだけで働いていたとは言えない。逆に、Mac 以外で働いた時間はここには出ない。差は、本人に聞いたり、事情を確かめたりするきっかけにはなる。答えそのものではない。

その PC ログは、何の時刻か

勤怠のデータの PC ログの列と、Mac の閉じた時刻の両方がそろっていた日が57日あった。30分以上の差が出た日は、こう分かれた。

57日のうち48日は、Mac のほうが遅かった。勤怠のデータの PC ログは、閉じた時刻ではなく、ネットワークにつないでいる時間に近いと見ている。接続を切ったあとも Mac を開いている分が見えていない、という推定だ（未検証）。

どちらが正しいという話ではない。同じ「PC ログ」と呼んでいても、何の時刻かで数字が変わる。Mac のログをどう使うかを決める前に、この差を先方へ伝えることにした。

公的な指針で確かめたこと

人事・労務の方のために、確かめたことだけ書く。厚生労働省のガイドラインは、タイムカードや IC カードと並べて「パソコンの使用時間の記録」を、始業・終業を確かめる客観的な記録の例に挙げている。「著しい乖離」があるときの実態調査は、自己申告で把握する場合の項目に書かれている。何分という数字は載っていない。

自分の会社にどう当てはまるか、どこを線にするかは、社労士などに確かめる話だ。この記事では判断しない。

▼出し方：全部そろうのを待たず、使う列は先に絞る

配った先のうち9台からは、結果が返ってこなかった。調べると、9台とも配ったあとに一度も接続していなかった。10月に使われていた Mac も混じる。この9台は追わず、10月分の Mac の表を、取れている分で共有する判断をした。追っても、10月分の多くはもう戻らない（推定）。ログインの記録がある行は、そのまま残している。

別の会社の記事では、記録が全員分そろうまで打刻の徹底を急がなかったと書いた。食い違うように見えるが、見ているものが違う。あちらは運用に乗せる話で、人が丸ごと抜けたまま進めると「記録がない＝働いていない」と誤解される。こちらは、いまの状況を見せる段階だ。閉じた記録が1件もない利用者もいるが、ログインの行は残し、分からない日が分かる形にしている（Mac の表では色、比較の表では空欄）。

勤怠のデータには、休暇の種類やメモなど、個人の事情に関わる列もある。比較に使う列は氏名・日付・打刻などに絞った。PC ログと差の列は、4日と20日を出すときと検算に使い、今の表からは外している。それ以外は使っていない。休暇は種類を落として「休暇」とだけ出す。人ごとのまとめのシートも、出す項目を絞るときになくした。作った表は個人の勤怠の情報なので、作業の履歴を残す場所には入れていない。

▼まだやっていないこと

• ▶ 差の基準：何分を差とするかは、先方の答えを待っている。30分は仮の線のまま
• ▶ 結びつかなかった分：対象外でよいかの確認
• ▶ Mac のログの使い方：4日と20日の差を伝えたうえで、どう使うかを決める
• ▶ 11月分：12月1日〜9日に、全部の Mac で手動で動かしてから集計する
• ▶ 置き場所と閲覧できる人：個人の勤怠の情報なので、絞って決める。未着手
• ▶ 毎月の手順書：未着手

▼まとめ：自分の会社で確かめること

PC のログで残業を確かめたいと言われたら、差を見る前に、担当者に次を聞いてほしい。

• ▶ 閉じた時刻が分かる日は何割か：差の日数を出す前に、その日数を数えているか
• ▶ その PC ログは何の時刻か：閉じた時刻か、ログインか、ネットワークにつないでいる時間か
• ▶ 社員にどう説明するか、誰が見るか：端末で記録を貯めると、画面には何も出ない。目的の説明と閲覧できる人は、別に決める
• ▶ 閉じた時刻はどこに何日残るか。今日から貯めているか：残る場所と期間は OS で違う。Windows でも確かめることは同じだ
• ▶ 分からない日をどう出すか：別の数字で埋めていないか
• ▶ 何分を差とするか：誰に確かめて決めるか

専用の PC ログのサービスを入れている、または入れる会社でも、確かめることは変わらない。入れる前に決めることは、こちらの記事に書いた。

▼担当者向け：設定と手順の詳細

ここからは、実際に集計する人向け。前半の言い方と、実際の名前の対応から。

JumpCloud に残るもの

• ▶ Directory Insights に、開閉に使える Mac のイベントはログイン（login_attempt）だけで、ログアウトもスリープもなかった（この環境で API を読んで確認）
• ▶ System Insights は uptime・logged_in_users など今の状態で、履歴がない
• ▶ 管理画面から出した CSV はちょうど500行で止まっていて、上限で切れている疑いがある。API から読むと切れなかった。CSV の時刻は UTC なので、日本時間は9時間足す

端末で読むもの

• ▶ Clamshell Sleep は蓋を閉じた、Idle Sleep は放置で眠った。メンテナンスの一時的な復帰（DarkWake）は数えない。画面のオン・オフ（Display is turned off など）も読む
• ▶ pmset -g log は man に「管理とデバッグ用」とあり、残る期間の記載はない。端末によって数日〜1週間で消えた。統合ログ（log show）では、さかのぼれなかった
• ▶ .asl は手元の Mac で15日分あった。配り直した直後に成功した17台のうち、16台で10月22日から取れた
• ▶ スクリプトは読み取りと履歴ファイルへの書き込みだけで、設定は変えない。端末に400日分を貯め、直近40日分を出す。2回動かしても重複しない。利用者の画面には何も出ないので、社員への説明は別に要る
• ▶ last は console の行とシャットダウン・再起動だけを見る。件数で切ると、ターミナルの行で埋まって押し出される

コマンドの出力は 1MB で切れる。古い順に出すと、新しい分から失われる

JumpCloud の Commands の出力には 1MB の上限がある。古い順に出していたので、実際に切れたときに失われたのは新しい分だった。ある端末の結果が、実行日より1週間近く手前で止まっていて気づいた。

原因は、蓋を閉じたまま画面が15秒ごとに点いて消える Mac だった（10月末の4日で約6,200回）。なぜ点滅するかは調べていない。

• ▶ 閉じている間の「画面が点いて1分未満で消えた」組を、出力から外した（履歴には残す）
• ▶ それでも100万バイトを超えたら古い分から削り、削った印を出す。最後に終わりの印を出して、無ければ切れたと判定する
• ▶ 結果：1,048,576 バイトで切れていた出力が 12,244 バイトになり、最後まで出た。実行は68秒（タイムアウトは120秒）
• ▶ 減らして壊していないかも確かめた。手元の全部の出力で開閉の結果は変わらず、10月分を出し直しても閉じた時刻は全行同じだった

差し替えたあとも、定時実行は端末に残った古い版で動く

コマンドの本体を新しい版に差し替えて全台へ手動で実行したあとも、毎日の定時実行は端末に残った古い版で動くことがあった。問題の端末では、差し替えた11月5日のあと、11月9日まで最初の版のままだった。結果の画面に見える本体は新しい版なので、画面では気づけない。

• ▶ 手動の実行（/api/runCommand）は新しい版で動く
• ▶ 切り替わる条件は分かっていない。再起動のあとに変わった端末も、再起動なしで変わった端末もある。公式の直接の説明は見つけられなかった
• ▶ 出力の1行目に版の印を入れる。これで、どの版が動いたかが結果から分かる
• ▶ 月次の集計の前に、手動で全台へ実行する。集計は、新しい版で最後まで出ている最新の結果を使う
• ▶ 古い版が履歴に足した行が残らないように、last 由来の行は毎回作り直す

last の年を読み違える

last の既定の出力には年が出ない。最初の版は、全部を今年の行として読んだ。ログアウトが未来の日付になる端末が2台あって気づいた。履歴が前年まである端末は3台で、うち1台は10月のシャットダウンに前年の分が混ざっていた。途中の集計もこの影響を受けていた（気づいて直した）。

• ▶ 曜日が合って未来にならない年を、今年からさかのぼって探す形に直した
• ▶ 古い版の出力で履歴が前年まである端末は、集計で last 由来の行を使わない
• ▶ last -y なら開始時刻に年が出る（手元の man と実行で確認）。今回の修正では使っていない。これから作るなら、先に試す価値がある

集計の決めごと

• ▶ 1分未満の開閉は数えない
• ▶ 16時間以上開いたままの日は、スリープしない設定の可能性があるので差を出さない
• ▶ 5時より前のログインは、前日の続きの可能性があるので別に出す
• ▶ 閉じたあとにまたログインしている日は、その閉じた時刻を最後の閉じた時刻にしない
• ▶ 日をまたいで閉じたら、開いた日の行に 25:10 の形で出す
• ▶ 人との結びつけは、端末名に入れている氏名で行う。同じ人の同じ日に複数の行があれば、最初と最後を取る
• ▶ 検算：勤怠のデータの差の列を打刻と PC ログから計算し直して、ほぼ一致を確認した。Mac の退勤の差も、80日のうち79日分を別の経路で計算し直して、差がなかった

結果が来ない端末の確かめ方

9台は、配る先のグループに入っているか（割り当ての間違いでないか）と、最後の接続が配った日より前か（動く機会がなかっただけか）を見た。9台ともグループに入っていて、最後の接続は配った日より前だった。古い重複の登録と思われるものも混じっていたが、削除はしていない。オフラインの端末へのコマンドは、3日間待機する設定にしている。