労働者名簿・賃金台帳・出勤簿の抜け漏れをClaude Codeで点検する

先に断っておくと、本記事は複数の支援経験をもとに一般化した実装パターン解説です。登場する数値は想定モデルケースの試算で、特定企業の実測値ではありません。また、帳簿の記載内容や保存の要否に関する法的な判断は、最終的に社会保険労務士・労働基準監督署への確認が必要です。この記事が扱うのは「その手前の突合と検知を機械化する」部分です。

労務まわりのAI活用支援で、三帳簿の話は少し意外な形で出てきます。36協定や有給の管理を仕組み化しようとして勤怠データを開いた瞬間、「そもそも労働者名簿の住所が更新されていない」「賃金台帳に深夜労働時間数の欄がない」「退職者の帳簿をいつまで持っていればいいか誰も知らない」という足元の問題が先に見つかるのです。三帳簿は労働基準監督署の調査でほぼ確実に提示を求められる書類なのに、日常業務では誰も開かないため、抜けが静かに蓄積します。

本記事は、36協定の上限超過チェック、年5日の有給取得義務チェックに続く労務レーンの3本目です。前2本が「日々動く数字の先読み」だったのに対し、今回は「静かに腐る台帳の定期健診」。実装の骨格は同じで、法定ルールを決定的なコードに固定し、AIは正規化と整理を担います。

先に法律の要求を固定する——労基法107・108・109条と施行規則

チェッカーを書く前に、条文が実際に何を求めているかを一次情報で固定します。ここが曖昧なままAIに「労務帳簿をチェックして」と投げると、もっともらしいが根拠のない項目リストが返ってきます。以下はすべてe-Gov法令検索の現行条文（2026年7月時点）で確認したものです。

労働者名簿——労働基準法107条・施行規則53条

使用者は、各事業場ごとに、各労働者（日々雇い入れられる者を除く）について労働者名簿を調製しなければなりません（労基法107条1項）。記載事項に変更があった場合は遅滞なく訂正する義務もあります（同条2項）。記載事項は法本体と施行規則53条をあわせて次の9つです。

#	記載事項	根拠	備考
1	氏名	法107条1項
2	生年月日	法107条1項
3	履歴	法107条1項	社内の異動歴等
4	性別	規則53条1項1号
5	住所	規則53条1項2号	転居時は訂正義務の対象
6	従事する業務の種類	規則53条1項3号	常時30人未満の事業では記入不要（同条2項）
7	雇入の年月日	規則53条1項4号
8	退職の年月日及びその事由	規則53条1項5号	解雇の場合はその理由を含む
9	死亡の年月日及びその原因	規則53条1項6号

様式は施行規則の様式第19号ですが、これは「必要な事項の最少限度」を定めたもので、横書き・縦書きその他異なる様式を用いてよいことが明文で認められています（規則59条の2第1項）。つまり人事システムの従業員マスタがこの9項目を持っていれば、それ自体を名簿として運用できます。逆に言えば、チェックすべきは様式の見た目ではなく項目の網羅性と更新の鮮度です。

賃金台帳——労働基準法108条・施行規則54条

使用者は、各事業場ごとに賃金台帳を調製し、賃金支払の都度遅滞なく記入しなければなりません（労基法108条）。記入事項は施行規則54条1項に8つ列挙されています。

#	記入事項	チェック時の落とし穴
1	氏名
2	性別
3	賃金計算期間	日々雇い入れられる者（1か月を超えて引き続き使用される者を除く）は記入不要（54条4項）
4	労働日数
5	労働時間数	管理監督者等（法41条該当者・高度プロフェッショナル制度対象者）は5号・6号の記入不要（54条5項）
6	時間外・休日・深夜の労働時間数	深夜（原則22時〜5時）の欄が給与システムの標準帳票に無いことがある
7	基本給、手当その他賃金の種類ごとにその額	通貨以外で支払う賃金がある場合は評価総額の記入が必要（54条3項）
8	賃金の一部を控除した場合はその額	労使協定に基づく控除（法24条1項）の額

様式は常時使用される労働者について様式第20号、日々雇い入れられる者について様式第21号です（規則55条）。こちらも様式自体は自由ですが、「給与明細の控えの束」は賃金台帳の代わりになりません。労働日数・労働時間数・時間外内訳が明細に載っていないケースが多いからです。ここは後述のチェッカーで最初に引っかかるポイントです。

なお、年次有給休暇管理簿・労働者名簿・賃金台帳はあわせて調製してよいと明文で認められています（規則55条の2）。従業員マスタを軸に3つを1つのデータ基盤へ寄せる設計は、規則上も正面から許容されています。

出勤簿——「出勤簿」という条文は存在しない

意外に思われるかもしれませんが、労働基準法に「出勤簿を調製せよ」という条文はありません。根拠は2つの規定の合わせ技です。

1. 労基法109条——「労働者名簿、賃金台帳及び雇入れ、解雇、災害補償、賃金その他労働関係に関する重要な書類」の保存義務。厚生労働省の「労働時間の適正な把握のために使用者が講ずべき措置に関するガイドライン」（平成29年1月20日策定）は、出勤簿やタイムカード等の労働時間の記録に関する書類がこの109条に基づく保存対象であることを明記しています
2. 同ガイドラインの記録義務——使用者は労働者の労働日ごとの始業・終業時刻を確認・記録すること。方法は原則として「使用者による現認」または「タイムカード、ICカード、パソコンの使用時間の記録等の客観的な記録」のいずれかによること

つまり出勤簿のチェックは「様式が正しいか」ではなく、労働日ごとの始業・終業時刻が客観的記録として残っているかを見ます。出勤・欠勤の○×だけが並ぶ紙の出勤簿は、日数は分かっても時刻が分からないため、ガイドラインの要求水準を満たしません。また賃金台帳に労働時間数を記入するには労働時間の把握が前提になるので、出勤簿の欠落は賃金台帳の記載不備に連鎖します。

保存期間と起算日——「5年、当分の間3年」と帳簿ごとの起算日

労基法109条の本則は5年間の保存を義務付けています。ただし附則143条1項により、当分の間は3年間と読み替えられています（2026年7月時点で読み替えは継続中）。実務上の要注意点は、起算日が帳簿ごとに違うことです（施行規則56条）。

書類	保存期間の起算日	根拠
労働者名簿	労働者の死亡・退職・解雇の日	規則56条1項1号
賃金台帳	最後の記入をした日（賃金の支払期日がそれより遅い場合は支払期日）	規則56条1項2号・2項
雇入れ・退職に関する書類	労働者の退職・死亡の日	規則56条1項3号
出勤簿等、賃金その他労働関係の重要書類	その完結の日（賃金支払期日が遅い場合は支払期日）	規則56条1項5号・2項

「在籍中の従業員の名簿」には保存期限が来ません。期限のカウントが始まるのは退職・解雇・死亡の日からです。退職者データを入社年でフォルダ分けして「古い年度から順に消す」運用は、この起算日ルールと合っていないため、コードで退職日ベースの期限管理に置き換える価値があります。

電子化の要件と罰則

三帳簿は紙で備え付ける必要はありません。厚生労働省のFAQでは、労務関係書類をパソコンで作成・保存する場合の条件として、法定の記載事項を満たしたうえで画面上に表示・印字ができること、労働基準監督署の検査等の際に速やかに出力・提出できることが挙げられています。人事SaaS＋給与SaaS＋勤怠SaaSの組み合わせで要件を満たすことは十分可能で、問題はむしろ「3つのシステムに分散した結果、どこにも完全な帳簿がない」状態の方です。

罰則も条文で確認しておきます。労基法120条1号は「第百六条から第百九条まで」の違反を30万円以下の罰金の対象としています。つまり労働者名簿の調製義務（107条）、賃金台帳の調製義務（108条）、保存義務（109条）のいずれの違反も罰則付きです。前掲の適正把握ガイドラインも、賃金台帳に労働時間数等を記入していない場合や故意に虚偽の時間数を記入した場合が120条の罰金対象になることを明記しています。

なぜ三帳簿は抜けるのか——現場で見る4つの難所

支援先で三帳簿を点検すると、抜け方にはパターンがあります。

1. 帳簿がシステム3つに分散している——名簿相当は人事システム、賃金台帳相当は給与システム、出勤簿相当は勤怠システム。それぞれのベンダー標準帳票が法定項目を全部持っているとは限らず、「うちはSaaSだから大丈夫」の思い込みの下で欄が欠けている。特に深夜労働時間数と解雇理由の欄は欠けやすい
2. 訂正義務が運用に乗っていない——名簿は変更があれば遅滞なく訂正する義務がある（107条2項）のに、住所変更や結婚による氏名変更が総務のメール受信箱で止まっている。「調製した日」は正しくても「現在の記載」が古い
3. 条件分岐が人の記憶に依存している——30人未満の事業場の特例、管理監督者の記載緩和、日々雇用の扱い。判定条件はすべて条文にあるのに、担当者の頭の中にしかない状態だと、担当交代で失われる
4. 保存期限の起算日がバラバラ——上述の通り帳簿ごとに起算日が違うため、Excelの「入社年度フォルダ」管理では期限切れの誤廃棄と、逆に消してよいものの無限保管が同時に起きる

どれも「知識としては単純、運用として続かない」タイプの問題です。この性質の業務は、ルールをコードに固定して定期実行する仕組みに向いています。

実装の全体像——台帳インベントリ・ルール判定・保存期限レジストリの3層

実装は3層に分けます。年5日有給チェックと同じ骨格です。

層	役割	担い手
1. 台帳インベントリ	人事・給与・勤怠システムのエクスポート（CSV/Excel）を共通スキーマに正規化し、「どの帳簿がどのデータで構成されるか」を宣言する	Claude Code（正規化コードの生成・列マッピングの推定）
2. ルール判定エンジン	条文由来の必須項目・条件分岐を決定的なコードで判定し、従業員×帳簿ごとの不備リストを出す	人間がレビューした固定ルール（AIは判定しない）
3. 保存期限レジストリ	退職者・過年度帳簿の保存期限を起算日ルールから計算し、期限前の誤廃棄と期限後の放置を両方向で検知する	固定ルール＋定期実行

Claude Codeの使いどころは第1層に集中させます。人事システムのエクスポートは会社ごとに列名も文字コードもバラバラで、ここを人手でマッピングするのが一番つらい。「このCSVのヘッダーを読んで、労働者名簿の法定9項目への対応表を作って。対応する列が見つからない項目は『欠落候補』として報告して」という仕事はClaude Codeが得意です。一方、第2層の必須項目リストや保存年数をプロンプトで毎回AIに聞くのは事故のもとです。条文の数字はコードに、揺れる入力の整形はAIに。この分担は労務レーン3本を通じて変わりません。

実装コード例1：労働者名簿の必須項目チェッカー

第2層の中核です。ポイントは、条文の要求をRULESとしてコードの先頭に根拠条文付きで書き切ること。レビューする社労士が「このルール表は条文と合っているか」だけを見ればよくなります。

# roster_check.py — 労働者名簿の法定項目チェック
# ルール根拠: 労働基準法107条 / 労働基準法施行規則53条
from dataclasses import dataclass
import datetime as dt

# 法定記載事項（規則53条1項の番号を根拠としてコメントに残す）
REQUIRED_FIELDS = [
    ("name",        "氏名",              "法107条1項"),
    ("birth_date",  "生年月日",          "法107条1項"),
    ("history",     "履歴",              "法107条1項"),
    ("sex",         "性別",              "規則53条1項1号"),
    ("address",     "住所",              "規則53条1項2号"),
    ("job_type",    "従事する業務の種類", "規則53条1項3号"),  # 30人未満は免除
    ("hired_date",  "雇入の年月日",      "規則53条1項4号"),
]
# 退職・死亡関係は「該当者のみ必須」の条件付きルール
CONDITIONAL_FIELDS = [
    ("retired_date",   "退職の年月日",  "規則53条1項5号"),
    ("retire_reason",  "退職の事由",    "規則53条1項5号"),  # 解雇なら理由必須
    ("death_date",     "死亡の年月日",  "規則53条1項6号"),
    ("death_cause",    "死亡の原因",    "規則53条1項6号"),
]

@dataclass
class Establishment:
    name: str
    regular_headcount: int  # 常時使用する労働者数（事業場単位）

def check_roster_row(row: dict, est: Establishment) -> list[str]:
    """従業員1人分の名簿レコードを判定し、不備メッセージのリストを返す"""
    issues = []
    # 日々雇い入れられる者は名簿の調製対象外（法107条1項かっこ書き）
    if row.get("employment_class") == "daily":
        return issues

    for key, label, basis in REQUIRED_FIELDS:
        # 30人未満の事業場は「従事する業務の種類」の記入不要（規則53条2項)
        if key == "job_type" and est.regular_headcount < 30:
            continue
        if not str(row.get(key) or "").strip():
            issues.append(f"[欠落] {label}（{basis}）")

    # 退職者は退職日・事由が必須。解雇の場合は理由まで必要
    if row.get("status") == "retired":
        if not row.get("retired_date"):
            issues.append("[欠落] 退職の年月日（規則53条1項5号）")
        reason = str(row.get("retire_reason") or "").strip()
        if not reason:
            issues.append("[欠落] 退職の事由（規則53条1項5号）")
        elif row.get("is_dismissal") and "解雇" in reason and len(reason) < 6:
            issues.append("[要確認] 解雇の場合は理由の記載が必要（規則53条1項5号）")

    # 訂正の鮮度: 住所・氏名の最終更新が人事イベントより古い場合に警告（法107条2項）
    updated = row.get("last_updated")
    event = row.get("last_hr_event_date")
    if updated and event and updated < event:
        issues.append("[要確認] 人事イベント後に名簿が未更新の可能性（法107条2項の訂正義務）")
    return issues

実際の運用では、この判定結果を従業員ID×帳簿のマトリクスに集計し、「欠落」「要確認」の2段階でCSV出力しています。要確認をアラートに混ぜて量が増えると誰も見なくなるので、欠落だけを月次レポートの先頭に置くのがコツです。

実装コード例2：保存期限レジストリと双方向アラート

保存期限は「期限が過ぎたのに残っている」だけでなく、「期限が来ていないのに消えている」方が重大です。監督署対応や未払賃金請求への備えが失われるからです。そこで期限レジストリは両方向で検知します。

# retention_registry.py — 三帳簿の保存期限計算
# ルール根拠: 労働基準法109条（本則5年・附則143条により当分の間3年）
#            労働基準法施行規則56条（起算日）
import datetime as dt
from dateutil.relativedelta import relativedelta

RETENTION_YEARS = 3  # 附則143条の経過措置。5年本則への移行は法改正を監視して更新する

def retention_deadline(doc_type: str, employee: dict,
                       last_entry: dt.date | None = None,
                       pay_date: dt.date | None = None) -> dt.date | None:
    """帳簿種別ごとの起算日から保存期限を返す。在籍中など未確定ならNone"""
    if doc_type == "roster":  # 労働者名簿: 死亡・退職・解雇の日が起算日（56条1項1号）
        base = employee.get("separation_date")  # 退職・解雇・死亡日
        if base is None:
            return None  # 在籍中は期限のカウントが始まらない
    elif doc_type == "wage_ledger":  # 賃金台帳: 最後の記入日（56条1項2号）
        if last_entry is None:
            return None
        base = last_entry
        # 賃金支払期日が最後の記入日より遅ければ支払期日が起算日（56条2項）
        if pay_date and pay_date > base:
            base = pay_date
    elif doc_type == "attendance":  # 出勤簿等: 完結の日（56条1項5号・2項準用）
        if last_entry is None:
            return None
        base = max(last_entry, pay_date) if pay_date else last_entry
    else:
        raise ValueError(f"unknown doc_type: {doc_type}")
    return base + relativedelta(years=RETENTION_YEARS)

def audit(records: list[dict], today: dt.date) -> dict:
    """両方向の不整合を検知する"""
    report = {"missing_but_in_period": [], "expired_still_kept": []}
    for r in records:
        deadline = retention_deadline(r["doc_type"], r["employee"],
                                      r.get("last_entry"), r.get("pay_date"))
        if deadline is None:
            continue
        exists = r["file_exists"]  # ストレージ実査の結果
        if today <= deadline and not exists:
            report["missing_but_in_period"].append(r)   # 重大: 保存期間内に実体がない
        elif today > deadline and exists:
            report["expired_still_kept"].append(r)      # 廃棄候補（個人情報保護の観点で棚卸し）
    return report

RETENTION_YEARS = 3には注意書きを付けています。109条の本則は5年で、3年はあくまで附則の経過措置です。将来の法改正で経過措置が終了する可能性があるため、この定数だけは四半期に一度、e-Govの現行条文と突合するタスクをカレンダーに入れています。安全側に倒すなら、社内規程で最初から5年保存に統一してしまう選択肢もあります（法定より長い保存は違反になりませんが、個人情報の保有期間の説明はできるようにしておきます）。

Claude Codeに投げているプロンプト集

三帳簿点検の構築・運用で実際に使っているプロンプトを5つ挙げます。いずれも「ルールを聞く」のではなく「作業をさせる」プロンプトである点に注目してください。

1. 列マッピングの推定——「このCSV（人事システムのエクスポート）のヘッダー行とサンプル3行を読んで、労働者名簿の法定項目（氏名・生年月日・履歴・性別・住所・従事する業務の種類・雇入の年月日・退職の年月日と事由・死亡の年月日と原因）への対応表をYAMLで作って。対応する列が見つからない法定項目は mapping: null として、欠落候補の一覧を別途出して」
2. 帳票の欄チェック——「この給与システムの賃金台帳PDFのレイアウトを読み取り、労働基準法施行規則54条1項の8項目それぞれについて、対応する欄が存在するかを表で整理して。深夜労働時間数の独立した欄があるかは特に注意して確認して」
3. 正規化コードの生成——「3つのエクスポート（hr.csv, payroll.csv, attendance.csv）を employee_id で結合し、共通スキーマ employees.parquet に変換するPythonスクリプトを書いて。文字コードはShift_JISとUTF-8が混在。日付列は和暦表記（例: 令和6年4月1日）を含むのでパースを実装して。変換できなかった行は捨てずに rejects.csv に理由付きで出して」
4. 差分レポートの整形——「roster_check.py の出力JSONを読んで、事業場別・不備種別のサマリーと、前月レポートとの差分（新規発生・解消済み）をMarkdownで作って。欠落を先頭に、要確認は折りたたみ想定の後半に」
5. テストデータの生成——「30人未満の事業場・管理監督者・日々雇用・年度途中退職・解雇・死亡退職を含む従業員テストデータを20件作り、roster_check.py と retention_registry.py のpytestを書いて。各条件分岐が最低1回は通ることをカバレッジの観点で確認して」

5番のテスト生成は地味に効きます。労務ルールの実装は条件分岐の見落としがバグの大半で、「30人未満の事業場で job_type 欠落を誤検知しない」のような境界ケースをAIにテストとして書き出させると、レビューが具体的な議論になります。

AIに任せてはいけないこと

労務レーン共通の線引きですが、三帳簿では特に次の3つを人間側に残します。

• 法解釈と個別判断——「この嘱託契約者は日々雇用に当たるか」「この手当は賃金台帳のどの区分か」といった当てはめの判断。チェッカーは「要確認」を出すところまでで、確定は社労士に委ねます
• 解雇理由の記載内容——規則53条は解雇の場合に理由の記載を求めますが、その文言は紛争時の証拠になりうるもので、AIの下書きをそのまま貼る場所ではありません
• 廃棄の実行——期限レジストリが「廃棄候補」を出しても、削除ボタンは人が押します。保存期間内の誤廃棄は取り返しがつかないため、廃棄はレポート→労務責任者の承認→実行の3段階に固定しています

想定される効果（試算）

従業員80名・3事業場・人事/給与/勤怠が別システムという想定モデルケースで、三帳簿の年次点検を手作業からコード化した場合の試算です（特定企業の実測値ではありません）。

指標	手作業	コード化後	備考
三帳簿×全従業員の突合工数	年1回・約3人日	初回構築2〜3人日＋月次実行は数分	2年目以降に効く
点検頻度	年1回（監督署対応や監査の直前）	月次	訂正漏れの検知が最大11か月早まる
保存期限管理	入社年度フォルダの目視	退職日起算の期限レジストリ	両方向（誤廃棄・放置）の検知
属人性	担当者の記憶に依存	ルール表がコードとして残る	担当交代・引き継ぎに強い

効果の本体は工数削減よりも「点検が年1回のイベントから月次の習慣に変わる」ことです。三帳簿の不備は発生から発見までの期間が長いほど訂正コストが膨らむ（退職者に住所を聞き直す、過去の勤怠を復元する）ため、検知の早期化がそのまま是正コストの圧縮になります。

段階的導入のロードマップ

Phase 1（1〜2週間）：台帳インベントリの作成。三帳簿それぞれについて「どのシステムのどのエクスポートで構成されるか」を宣言し、列マッピングをClaude Codeと作る。この時点で欄の欠落（帳票に深夜労働時間数がない等）は見つかることが多い

Phase 2（2〜4週間）：名簿チェッカーと賃金台帳チェッカーを最小構成で動かし、直近1年分を判定。出てきた不備リストを社労士とレビューし、判定ルールの誤り（会社固有の雇用区分の扱い等）を潰す

Phase 3（1〜2か月）：保存期限レジストリと月次の定期実行を整備。レポートをSlack等に自動配信し、「欠落ゼロ・要確認n件」を労務定例の定点観測項目にする。36協定・年5日有給のチェックと同じ従業員マスタ基盤に載せると、労務レーン全体が1つのパイプラインになる

【要注意】よくある失敗パターンと回避策

失敗1：AIに「労務帳簿の必須項目」を毎回聞いてしまう

❌ プロンプトで「労働者名簿の必須項目を挙げてチェックして」と依頼する→回答が実行のたびに揺れ、根拠も確認できない
⭕ 必須項目は条文から書き起こしたREQUIRED_FIELDSとしてコードに固定し、根拠条文をコメントで併記する。AIには揺れる入力の正規化だけを任せる

失敗2：「SaaSを使っているから帳簿はある」と思い込む

❌ 人事・給与・勤怠SaaSを導入した時点で三帳簿が整備済みだと判断する
⭕ ベンダー標準帳票と法定項目の対応表を一度作って確認する。深夜労働時間数・解雇理由・履歴の3項目は標準帳票から漏れていることがある。確認は1回きりではなく、SaaSの仕様変更に備えて年1回再実行する

失敗3：保存期限を「作成日から3年」で一括管理する

❌ 帳簿ファイルの作成日や年度で一律に期限を切る
⭕ 起算日は帳簿ごとに違う（名簿=退職等の日、賃金台帳=最後の記入日か支払期日の遅い方）。規則56条のルールをそのまま関数にし、在籍者の名簿には期限を付けない

失敗4：チェックレポートを帳簿そのものと混同する

❌ 「チェッカーが通っているから帳簿は適法」とレポートを成果物扱いする
⭕ レポートはあくまで監査用の突合結果で、法定帳簿の実体は名簿・台帳・出勤簿のデータ本体。監督署に提示するのは帳簿側であり、いつでも表示・印字できる状態の維持（厚労省FAQの電子保存要件）が本体の要件になる

よくある質問

Q. 法定三帳簿とは何ですか？すべての会社に義務がありますか？

労働者名簿（労働基準法107条）・賃金台帳（同108条）・出勤簿等の労働時間の記録（同109条の「その他労働関係に関する重要な書類」）の3つを指す実務上の呼び名です。労働者を1人でも雇用する事業場に適用され、会社の規模による免除はありません。ただし労働者名簿は日々雇い入れられる者について調製不要、常時30人未満の事業場では「従事する業務の種類」の記入が不要といった条文上の緩和があります。

Q. 三帳簿の保存期間は5年と3年のどちらが正しいのですか？

労働基準法109条の本則は5年間ですが、附則143条により「当分の間」は3年間と読み替えられており、2026年7月時点でこの経過措置は続いています。将来の改正で5年へ移行する可能性があるため、本記事の実装では保存年数を定数として一箇所に置き、条文の変更を監視する運用にしています。法定より長く保存すること自体は違反になりません。

Q. 出勤簿はタイムカードや勤怠システムのデータで代用できますか？

できます。厚生労働省の労働時間適正把握ガイドラインは、始業・終業時刻の確認・記録の原則的な方法として「使用者の現認」または「タイムカード、ICカード、パソコンの使用時間の記録等の客観的な記録」を挙げています。重要なのは媒体ではなく、労働日ごとの始業・終業時刻が記録され、労働基準法109条に基づき保存されていることです。出欠の○×しか残らない形式では時刻の記録として不十分です。

Q. 帳簿を電子データだけで保存しても問題ありませんか？

法定記載事項を満たしたうえで、画面上への表示と印字ができ、労働基準監督署の検査等の際に速やかに出力できる状態であれば、電子データでの作成・保存が認められています（厚生労働省FAQ）。様式も施行規則の様式19号・20号と同一である必要はなく、異なる様式の使用が明文で認められています（施行規則59条の2）。人事システムの従業員マスタや給与システムの帳票をそのまま帳簿として運用する設計が可能です。

Q. 三帳簿の点検をClaude Codeで自動化する際、AIの判定ミスが心配です

本記事の設計では、法定項目の有無や保存期限の判定はAIではなく、条文から書き起こした決定的なコードが行います。Claude Codeが担当するのは、システムごとにバラバラなエクスポートの正規化・列マッピングの推定・レポート整形といった「揺れる入力の整理」で、判定ルール自体は社労士がレビューできる固定のルール表として残します。判定の確定やグレーケースの解釈は人間と社労士の担当です。

まとめ：今日から始める3つのアクション

1. 今日やること：三帳簿それぞれが「どのシステムのどのデータで構成されているか」を1枚の表にする。名簿・台帳・出勤簿のどれかが「実体不明」なら、それが最優先の課題です
2. 今週中：給与システムの賃金台帳帳票と施行規則54条の8項目、人事システムの従業員マスタと名簿の法定9項目の対応表を作る。深夜労働時間数・解雇理由・履歴の3項目は特に注意して確認します
3. 今月中：退職者の帳簿について、退職日起算の保存期限一覧を作り、「保存期間内なのに実体がないもの」がないかを実査する。見つかった場合の復元可否は労務責任者・社労士と相談します

三帳簿の点検は、36協定の上限超過の先読み、年5日有給の未達先読みに続く労務レーンの3本目で、派遣元・派遣先管理台帳の仕組み化とも共通の「法定ルールを決定的なコードに固定し、AIは正規化と整理を担う」パターンです。この3本はいずれも同じ従業員マスタ基盤の上に載るので、どれか1本を作れば残りは差分実装で済みます。

---

著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』（SBクリエイティブ）。

参考・出典

• 労働基準法（昭和22年法律第49号）第107条・第108条・第109条・第120条・附則第143条 — e-Gov法令検索（参照日: 2026-07-30）
• 労働基準法施行規則 第53条〜第56条・第59条の2 — e-Gov法令検索（参照日: 2026-07-30）
• 厚生労働省「労働時間の適正な把握のために使用者が講ずべき措置に関するガイドライン」（平成29年1月20日策定）（参照日: 2026-07-30）
• 厚生労働省 労働基準法FAQ「労務関係の書類をパソコンで作成して保存したいのですが、可能でしょうか。」（参照日: 2026-07-30）
• 厚生労働省 スタートアップ労働条件「賃金台帳等の労働契約関係の書類の保存期間は何年ですか？」（参照日: 2026-07-30）

ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。

関連記事: 給与計算の検算をClaude Codeで仕組み化する実装パターン

関連記事: 【2026年最新】社労士事務所のClaude Code活用｜書類作成5ステップ

追記（2026年8月）：令和8年7月から障害者の法定雇用率が2.7%へ引き上げられ、対象事業主の範囲も常用労働者37.5人以上に拡大します。労働者名簿・賃金台帳の整備状況は、この対象拡大に伴う障害者雇用状況の算定・報告にも直結します。詳しい算定ロジックと実装パターンは障害者雇用率2.7%引き上げをClaude Codeで仕組み化する実装パターンで解説しています。

あわせて読みたい

• ▸ フリーランス新法の60日払い・条件明示をClaude Codeで自動チェック
• ▸ 障害者雇用率2.7%引き上げをClaude Codeで仕組み化する実装パターン
• ▸ 特定技能の支援計画・定期届出をClaude Codeで仕組み化する実装パターン
• ▸ 薬機法・景表法の広告表現チェックをClaude Codeで仕組み化する実装
• ▸ 与信管理・与信限度額の監視をClaude Codeで仕組み化する実装パターン