3年保存、派遣元・派遣先管理台帳をClaude Codeで仕組み化

本記事は特定の実在企業の支援事例ではありません。労働者派遣事業者・派遣先企業向けのシステム開発でくり返し相談される「派遣元管理台帳・派遣先管理台帳の作成・記載・保存が属人化して回らない」という課題を一般化した実装パターン解説です。文中の工数の数値はすべて試算・想定であり、実測結果ではありません。また記事中の記載事項・保存期間は労働者派遣法および厚生労働省「労働者派遣事業関係業務取扱要領」に基づいて整理していますが、法令解釈・労務管理上の最終判断は必ず社会保険労務士や所轄の都道府県労働局需給調整事業部にご確認ください。

派遣管理システムを扱う開発者の間で、「派遣元管理台帳と派遣先管理台帳の違いがそもそも整理できていない」という相談は意外と多い。話を聞くと、根本原因は同じパターンに集約される。台帳を1つのExcelシートで済まそうとして、派遣元が書くべき項目と派遣先が書くべき項目が混在してしまう。あるいは、勤怠システムの実績データと台帳の記載事項がリンクしておらず、月末に手作業で転記している。さらに、抵触日（期間制限の上限）をExcelの別シートで管理していて、担当者が異動すると更新が止まる。これらはどれも労務管理の判断ミスというより、記録を継続させる仕組みの設計問題だ。だとすれば、Claude Codeで台帳運用の周辺処理を小さく組んで、法令が定める記載事項・保存期間に沿って育てていくアプローチと相性がいい。この記事では、2つの台帳の違いを条文ベースで整理したうえで、就業実績データからの台帳生成、抵触日アラート、3年保存の保管構成まで、実装パターンとして書いていく。

派遣元管理台帳と派遣先管理台帳は「別の帳簿」であることを正確に理解する

まず前提を揃える。労働者派遣法には、派遣に関わる法定台帳が2種類ある。

• 派遣元管理台帳（労働者派遣法第37条）：労働者派遣事業を行う事業主（派遣会社）が、派遣労働者ごとに作成する台帳。
• 派遣先管理台帳（労働者派遣法第42条）：派遣労働者を受け入れる企業（派遣先）が、派遣労働者ごとに作成する台帳。

名前が似ているうえに、記載事項の一部（派遣期間、就業日、業務の種類、苦情処理に関する事項など）が重なるため、「1つの台帳を共有すればいい」と誤解されがちだが、これは誤りだ。作成義務を負う主体が異なり、記載事項にもそれぞれ固有の項目がある。実装の設計段階でこの区別を曖昧にすると、「派遣元向けの機能なのか派遣先向けの機能なのか」が混在したシステムになり、後から分離するコストが大きくなる。

派遣元管理台帳（第37条）の記載事項

厚生労働省「労働者派遣事業関係業務取扱要領」の様式集をもとに、派遣元管理台帳の主な記載事項を整理すると次のとおりになる。

区分	記載事項の例
派遣労働者の属性	協定対象派遣労働者か否かの別、無期雇用か有期雇用かの別（有期の場合は契約期間）、60歳以上の雇用継続対象者か否かの別
派遣先・就業条件	派遣先の氏名または名称、事業所の所在地その他派遣就業の場所・組織単位、労働者派遣の期間・派遣就業をする日、始業・終業の時刻、従事する業務の種類
雇用管理に関する事項	雇用の安定等に関し講じた措置、教育訓練を行った日時・内容、キャリアコンサルティングを行った日時・内容
その他	派遣労働者から申出を受けた苦情の処理に関する事項、紹介予定派遣に係る事項、その他厚生労働省令で定める事項

実務上は、上記の「派遣先・就業条件」区分の情報の多くが、派遣先から通知される内容（後述）と重複する。この重複部分をどう同期させるかが、実装のポイントになる。

派遣先管理台帳（第42条）の記載事項と通知義務

派遣先管理台帳は、受け入れ企業側の実績・管理事項が中心になる。

区分	記載事項の例
派遣労働者・派遣元の属性	派遣労働者の氏名、協定対象派遣労働者か否かの別、無期雇用か有期雇用かの別、派遣元事業主の氏名または名称・事業所の名称および所在地
就業実績	派遣就業をした事業所の名称・所在地・組織単位、従事した業務の種類、派遣就業をした日、始業・終業の時刻および休憩した時間
雇用管理に関する事項	派遣労働者が従事する業務に伴う責任の程度、教育訓練を行った日時・内容
その他	派遣労働者から申出を受けた苦情の処理に関する事項、紹介予定派遣に係る事項、派遣先責任者・派遣元責任者に関する事項、その他厚生労働省令で定める事項

ここで実装上とくに重要なのが、派遣先には派遣元事業主への定期通知義務がある点だ。労働者派遣法第42条第3項により、派遣先は派遣就業日・始業終業時刻・休憩時間などの実績事項を、1か月に1回以上、一定の期日を定めて派遣元に通知しなければならない。この通知の頻度・期日をシステムでどう担保するかは、後述する実装で扱う。

2つの台帳の違い（誰が・何を・いつ）

項目	派遣元管理台帳（第37条）	派遣先管理台帳（第42条）
作成義務者	派遣元事業主（派遣会社）	派遣先（受け入れ企業）
記載の中心	雇用管理（無期・有期の別、教育訓練、キャリアコンサルティング等）	就業実績（実際の就業日・始業終業時刻・休憩時間等）
派遣元・派遣先間の連携	派遣先からの通知事項を反映	実績事項を1か月1回以上派遣元へ通知する義務あり
保存期間	派遣終了日から3年間	派遣終了日から3年間

保存期間はどちらも「3年間」で同じだが、起算点はいずれも「派遣終了日」であり、契約を更新している派遣労働者については最後の派遣が終了した日が起算点になる。単発の契約ごとにファイルを消していくと、更新を繰り返した派遣労働者の記録が途中で欠落するリスクがあるため、実装では「派遣労働者単位」で保存期間を管理する設計が必須になる。

Claude Codeが担う範囲、事業者が担う範囲

ここが最も誤解されやすい部分なので、先に明確にしておく。Claude Codeにやらせるのは以下の作業に限定する。

1. 台帳下書きの自動生成 — 勤怠・シフトの実績データ（CSV等）から、派遣元管理台帳・派遣先管理台帳それぞれの様式に沿った下書きを生成するスクリプトの実装
2. 記載項目の突合・欠落チェック — 派遣先からの通知事項と派遣元台帳の記載内容にズレ・欠落がないかを機械的に照合する処理
3. 抵触日（期間制限の上限日）の期限管理 — 事業所単位・個人単位の期間制限に基づく上限日を計算し、一定期間前にアラートを出す仕組み
4. 3年保存のファイル命名・保管構成の整備 — 派遣労働者単位・派遣終了日起算で検索・棚卸しできるディレクトリ構成とアーカイブ処理の実装

逆に、Claude Codeにやらせてはいけないのは、台帳の記載内容が法令上正しいかどうかの最終判断、抵触日の法的な起算・延長手続きに関する解釈、派遣先から派遣元への通知義務が適法に履行されているかどうかの判断だ。これらは労働者派遣法上、事業者自身（多くの場合は労務担当者・社会保険労務士と連携した派遣元責任者・派遣先責任者）が担う責任であり、AIが代替できる領域ではない。実装者としては、システムの設計段階で「これはあくまで台帳の生成・突合・期限管理の道具であり、記載内容の適法性を保証するものではない」という前提をUIやドキュメントに明記しておくことをすすめる。

実装全体像：就業実績データ → 台帳下書き生成 → 抵触日アラート → 保管構成

骨格は4段構成にする。想定環境はPython 3.11 / pandas 2.x、就業実績データはローカルのCSV（将来的に既存の勤怠・給与システムからのAPI連携に置き換えやすい設計）とした。

haken-ledger/
├── data/
│   ├── attendance/          # 就業実績データ (勤怠CSV, 派遣先別・月別)
│   └── notices/             # 派遣先からの通知事項 (第42条3項の通知控え)
├── config/
│   └── contracts.yaml       # 派遣契約ごとの派遣開始日・事業所単位/個人単位の情報
├── scripts/
│   ├── build_hakenmoto_ledger.py   # 派遣元管理台帳の下書き生成
│   ├── build_hakensaki_ledger.py   # 派遣先管理台帳の下書き生成
│   ├── reconcile_notices.py        # 通知事項と台帳記載内容の突合
│   └── teishokubi_alert.py         # 抵触日アラート
└── archive/
    └── {派遣労働者ID}/{派遣先ID}/  # 派遣終了日起算3年保存の保管構成

この構成をClaude Codeに作らせる際の最初の指示は、次のように役割分担を明示すると実装のブレが少ない。

厚生労働省「労働者派遣事業関係業務取扱要領」の様式集に沿って、派遣元管理台帳と
派遣先管理台帳を別々のスクリプトで生成するPythonプロジェクトを初期化してください。
派遣元台帳と派遣先台帳で記載事項が異なる前提で、共通の就業実績データ(CSV)から
それぞれの様式にマッピングする設計にしてください。
台帳の記載内容が法令上正しいかどうかの判定はこのシステムの範囲外とし、
生成した下書きは必ず人（派遣元責任者・派遣先責任者）が確認するステータスを
残す設計にしてください。
不足している情報があれば、実装前に質問してください。

就業実績データから2つの台帳を生成する

派遣先の勤怠システムやタイムカードから出力した就業実績CSV（派遣就業日・始業終業時刻・休憩時間）を起点に、派遣元台帳と派遣先台帳それぞれの下書きを生成する。両者は記載事項が異なるため、生成関数も分ける。

# scripts/build_hakensaki_ledger.py の骨子（Claude Codeと一緒に実装した例）
import pandas as pd

REQUIRED_COLUMNS = [
    "派遣労働者氏名", "派遣元事業主名", "派遣元事業所名", "派遣元事業所所在地",
    "就業事業所名", "就業事業所所在地", "組織単位", "従事業務の種類",
    "派遣就業日", "始業時刻", "終業時刻", "休憩時間",
]

def build_hakensaki_ledger(attendance_csv: str, contract_yaml: dict) -> pd.DataFrame:
    df = pd.read_csv(attendance_csv)
    missing = [c for c in REQUIRED_COLUMNS if c not in df.columns]
    if missing:
        raise ValueError(f"就業実績データに不足項目があります: {missing}")
    # 責任の程度・協定対象派遣労働者の別など契約情報側の項目を突合
    df["協定対象派遣労働者"] = contract_yaml.get("kyotei_taisho", "要確認")
    df["責任の程度"] = contract_yaml.get("sekinin_teido", "要確認")
    return df[REQUIRED_COLUMNS + ["協定対象派遣労働者", "責任の程度"]]

Claude Codeへの実装指示では、「わからない項目は空欄で埋めずに”要確認”と明示する」ことを徹底させた。

就業実績データや契約情報から自動で埋められない記載事項（協定対象派遣労働者の別、
責任の程度など）は、空欄のまま出力せず "要確認" という文字列で明示してください。
これは台帳の記載漏れを防ぐためのフェイルセーフです。
"要確認" が残っている行は、月次の突合レポートで一覧化してください。

この「わからないものは空欄にせず要確認と書かせる」という指示は、記録系の実装全般で効く。空欄は「未入力」なのか「意図的に該当なし」なのか区別がつかないが、”要確認” というフラグなら、後で人が確認すべき箇所が一目でわかる。

派遣先からの通知事項と台帳記載内容の突合

派遣先には、就業実績事項を1か月に1回以上、期日を定めて派遣元に通知する義務がある（労働者派遣法第42条第3項）。この通知が実際に行われたか、通知内容と派遣元台帳の記載内容が一致しているかを機械的に突合する処理は、Claude Codeとの相性がいい領域だ。

# scripts/reconcile_notices.py の骨子
import pandas as pd

def reconcile(hakenmoto_ledger: pd.DataFrame, hakensaki_notice: pd.DataFrame) -> pd.DataFrame:
    merged = hakenmoto_ledger.merge(
        hakensaki_notice, on=["派遣労働者氏名", "派遣就業日"],
        how="outer", suffixes=("_台帳", "_通知"), indicator=True
    )
    mismatches = merged[
        (merged["_merge"] != "both") |
        (merged["始業時刻_台帳"] != merged["始業時刻_通知"]) |
        (merged["終業時刻_台帳"] != merged["終業時刻_通知"])
    ]
    return mismatches

Claude Codeへの指示では、通知の期日管理も明示的に扱わせた。

派遣先からの通知が「1か月に1回以上、一定の期日を定めて」行われているかを
チェックするため、config/contracts.yaml に契約ごとの通知期日を設定できるようにし、
期日を過ぎても通知データが届いていない場合は警告リストに出してください。
この警告はあくまで社内の期日管理を助けるためのものであり、
法的な通知義務の履行証明そのものではないことをコード内コメントに明記してください。

抵触日（期間制限の上限）のアラート実装

労働者派遣には、同一の事業所に対する派遣受け入れの上限期間（事業所単位の期間制限）と、同一の組織単位における同一の派遣労働者の受け入れ上限期間（個人単位の期間制限）がある。この上限に達する日は、実務上「抵触日」と呼ばれる。抵触日を超えて派遣を継続すると、労働契約申込みみなし制度の対象になりうるなど、事業者側のリスクが大きい。台帳の記載事項そのものではないが、台帳運用と密接に関わる期限管理として、Claude Codeで仕組み化する価値が高い。

# scripts/teishokubi_alert.py の骨子
import pandas as pd
from dateutil.relativedelta import relativedelta

def check_teishokubi(contracts: pd.DataFrame, alert_days_before: int = 90) -> pd.DataFrame:
    contracts = contracts.copy()
    contracts["抵触日"] = pd.to_datetime(contracts["派遣開始日"]) + relativedelta(years=3)
    today = pd.Timestamp.today().normalize()
    contracts["残日数"] = (contracts["抵触日"] - today).dt.days
    return contracts[contracts["残日数"].between(0, alert_days_before)]

ここで強調しておきたいのは、抵触日の起算・延長手続き（労使協定の締結・意見聴取手続き等）の解釈はこのスクリプトの範囲外であり、あくまで「契約情報として登録された派遣開始日から機械的に計算した目安日」を通知するものだという点だ。実際の抵触日の判断・延長手続きの要否は、必ず社会保険労務士や労働局に確認したうえで、config側の値を正としてシステムに反映する運用にする。定期実行したい場合は、非対話モード（-p）に実行を許可するツールを絞って渡すのが法人運用の基本だ（--allowedTools、または settings.json の permissions で必要なコマンドだけを許可する）。公式CLIには全権限プロンプトをスキップする --dangerously-skip-permissions というオプションも存在するが、名前のとおり危険側の設定で、隔離されたCI/コンテナ環境以外での常用は推奨しない。台帳のような法定書類を扱うcronでは、なおさら許可範囲を明示する構成にする。

0 9 1 * * cd /path/to/haken-ledger && \
  claude -p "teishokubi_alert.py を実行し、90日以内に抵触日を迎える契約の一覧を
  労務担当者向けの通知テキストに整形して" \
  --allowedTools "Bash(python3:*),Read" >> logs/teishokubi_cron.log

3年保存に耐えるファイル命名・保管構成

保存期間の起算点が「派遣終了日」であり、契約更新を繰り返した派遣労働者は「最後の派遣が終了した日」が起算点になる点は前述のとおりだ。この特性に合わせて、ファイル・ディレクトリ構成は契約単位ではなく派遣労働者単位で設計する。

archive/
└── {派遣労働者ID}/
    └── {派遣先ID}/
        ├── hakenmoto_ledger_{派遣終了日}.csv   # 派遣元管理台帳
        ├── hakensaki_ledger_{派遣終了日}.csv   # 派遣先管理台帳
        └── notices/                              # 通知控え一式

Claude Codeへの実装指示では、削除タイミングの自動化は慎重に扱わせた。

archive/ 配下のディレクトリごとに「派遣終了日+3年」を保存期限として算出する
スクリプトを実装してください。ただし保存期限を過ぎたディレクトリを
自動削除する処理は実装しないでください。
削除は必ず人が確認して実行する運用にするため、削除候補の一覧を出力する
機能に留めてください。

法定保存書類の自動削除は、削除してはいけないデータを誤って消すリスクの方が、手間の削減効果より大きい。実装パターンとしては「候補の可視化まではAIに任せ、削除の実行は必ず人が行う」という非対称な設計にするのが安全だ。

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

Phase 1（2〜4週間程度）：現状の台帳運用を棚卸しし、派遣元台帳・派遣先台帳それぞれの記載事項をCSVスキーマとして設計。1つの派遣先・少人数の派遣労働者でプロトタイプを試す。

Phase 2（1〜2ヶ月）：台帳下書き生成・通知突合・抵触日アラートのスクリプトを実装し、既存の台帳作成フローと並行運用。”要確認”フラグの発生頻度から、契約情報側の整備不足を洗い出す。

Phase 3（継続運用）：派遣労働者単位の3年保存アーカイブ構成を定着させ、複数派遣先・複数契約への横展開と、法改正・要領改訂への追従体制を整える。

想定される工数の変化（試算）

以下はあくまで実装パターンとしての試算モデルであり、特定企業での実測結果ではない。手作業での台帳作成・突合と、実績データ連携後の確認作業を比較したイメージとして参考にしてほしい。

作業	想定：手作業での台帳作成	想定：実績データ連携＋自動生成
派遣元・派遣先台帳の月次記載	勤怠データを見ながら台帳へ手入力・転記	実績CSVから下書きを自動生成し、要確認箇所のみ人が入力
通知事項と台帳のズレ確認	気づいた人が個別に見比べるまで見えない	突合スクリプトが不一致行を機械的にリストアップ
抵触日の管理	担当者個人のExcelやカレンダーに依存	契約情報から自動計算し、期限前にアラート

正直に言うと、台帳の記載項目自体を減らせるわけではない。効果が出るのは「複数の派遣契約・複数の派遣先をまたいで、抜け漏れなく期日管理する」フェーズであり、記載作業そのものの省力化だけを狙った実装は効果が薄い。

よくある失敗パターンと回避策

失敗1：派遣元台帳と派遣先台帳を1つの様式にまとめてしまう
❌ 記載事項が一部重なることを理由に、派遣元管理台帳と派遣先管理台帳を1枚のシートで兼用しようとする。
⭕ 作成義務者と記載事項が異なる別の法定台帳として設計し、共通項目のみ突合ロジックで同期させる。

失敗2：抵触日の判定・延長手続きの解釈までシステムに任せる
❌ 「システムが抵触日を計算しているから、期間制限の対応は大丈夫」と考えて、労使協定の締結や意見聴取手続きの要否確認を省略してしまう。
⭕ システムが出すのはあくまで契約情報に基づく目安日であり、法的な判断・手続きは社会保険労務士や労働局に確認する前提を崩さない。

失敗3：空欄のまま台帳を確定させてしまう
❌ 実績データから自動で埋まらない項目を空欄のまま出力し、そのまま正式な台帳として確定させる。
⭕ 自動で埋まらない項目は”要確認”として明示し、必ず派遣元責任者・派遣先責任者が確認してから確定させる運用にする。

失敗4：保存期限を過ぎたデータを自動削除する
❌ 「3年経ったから」という理由だけでバッチ処理により台帳データを自動削除する。
⭕ 削除候補の一覧化まではシステムに任せ、実際の削除は必ず人が確認してから実行する。

よくある質問

Q. 派遣元管理台帳と派遣先管理台帳は、どちらか一方だけ整備すればいいですか？

いいえ、両方とも別の法定義務です。派遣元管理台帳は労働者派遣法第37条に基づき派遣会社（派遣元事業主）が、派遣先管理台帳は同第42条に基づき受け入れ企業（派遣先）が、それぞれ作成・保存する義務を負います。記載事項の一部が重なりますが、作成主体が異なるため兼用はできません。

Q. 台帳の保存期間はどちらも3年間ですか？

はい、派遣元管理台帳・派遣先管理台帳ともに、派遣終了日から3年間の保存が義務付けられています。ただし契約を更新した派遣労働者については、最後の派遣が終了した日が起算点になる点に注意が必要です。

Q. Claude Codeで台帳の記載内容の正しさまで自動判定できますか？

できません。就業実績データからの台帳下書き生成、通知事項との突合、抵触日の期限管理といった周辺作業はサポートできますが、記載内容が法令上正しいかどうかの最終判断は、派遣元責任者・派遣先責任者、必要に応じて社会保険労務士や所轄の都道府県労働局需給調整事業部に確認する必要があります。

Q. 抵触日のアラートは、どのくらい前に出すのが適切ですか？

本記事のサンプルでは90日前を例としていますが、これは実装上の一例に過ぎません。労使協定の締結や意見聴取など延長手続きに必要な期間は状況により異なるため、実務上必要なリードタイムは社会保険労務士等に確認したうえで設定してください。

Q. 派遣先からの通知は書面でなければいけませんか？

労働者派遣法第42条第3項では、就業実績事項等を書面の交付等により通知することが求められています。電磁的方法による通知が可能な場合もありますが、要件の詳細は厚生労働省の資料や所轄の労働局に確認することをおすすめします。本記事はシステムでの期日管理・突合の実装パターンを扱うものであり、通知方法の適法性を判断するものではありません。

Q. どの労働局・部署に相談すればいいですか？

労働者派遣事業に関する指導・相談は、市区町村ではなく、都道府県労働局の需給調整事業部が窓口になります。台帳の記載事項や保存方法について疑義がある場合は、まず所轄の都道府県労働局需給調整事業部に確認してください。

Q. 記事中のコマンドやコード例はそのまま使えますか？

実装パターンの一例であり、自社の契約形態・勤怠システムの出力形式に合わせて調整が必要です。またClaude Code自体のコマンドやオプションの仕様は更新される可能性があるため、実装前に公式ドキュメント（code.claude.com/docs）で最新の仕様を確認してください。

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

1. 今日やること：自社（または支援先）の台帳運用が、派遣元管理台帳と派遣先管理台帳のどちらの記載事項を、誰が、どのタイミングで作成しているかを棚卸しする
2. 今週中：就業実績データ（勤怠CSV等）のどの列が、どちらの台帳のどの記載事項に対応するかのマッピング表を、Claude Codeと一緒にたたき台として作ってみる
3. 今月中：既存の台帳作成フローと並行運用しながら、通知突合・抵触日アラートのスクリプトを1サイクル回してみる

関連記事として、法定台帳・記録の保存期間管理という観点では「建設業の施工体制台帳をClaude Codeで効率化する実装パターン」「古物商の古物台帳・本人確認記録をClaude Codeで効率化する実装パターン」、人材業界の周辺業務という観点では「人材紹介の求人票・候補者サマリをClaude Codeで量産」もあわせて参考にしてほしい。なお本記事が扱う労働者派遣（労働者派遣法）と、上記の人材紹介記事が扱う職業紹介（職業安定法）は、法律上まったく別の制度である点に注意してほしい。

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

著者プロフィール

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

参照・出典

• 厚生労働省「労働者派遣事業関係業務取扱要領（令和3年1月1日以降適用）」（第15章様式集に派遣元管理台帳・派遣先管理台帳の様式を掲載。労働者派遣法第37条・第42条の記載事項の根拠資料）
• 厚生労働省「労働者派遣事業・職業紹介事業・募集情報等提供事業等」ポータルページ（労働者派遣事業の制度概要、都道府県労働局需給調整事業部の所管説明）
• 厚生労働省「改正後の労働者派遣事業関係業務取扱要領等」（法改正に伴う記載事項・様式の更新履歴）
• Claude Code公式ドキュメント CLIリファレンス（-p / --dangerously-skip-permissions の仕様）

あわせて読みたい

• ▸ 非エンジニアのClaude Code活用7選【2026年最新】｜業務担当者入門
• ▸ 【2026年最新】人材紹介の求人票・候補者サマリをClaude Codeで量産
• ▸ 【2026年最新】人材紹介エージェントのキャンディデート管理をClaude Codeで効率化｜実装5手順
• ▸ 人事の書類選考をClaude Codeで整理｜評価表と候補者メモ自動化