結論：年5日の有給取得義務（労働基準法39条7項）のチェックは、年休データを「基準日・付与日数・取得記録」に正規化し、カウントしてよい取得（1日単位・半日単位）とカウントできない取得（時間単位年休・特別休暇）を決定的なコードで判定し、基準日ごとの履行期限から「このペースでは間に合わない人」を先読みする仕組みまで含めて、Claude Codeで構築できます。AIに任せるのは正規化とレポート生成で、5日・基準日・控除ルールの数字そのものはコードに固定します。
- 要点1：義務の対象は「年10日以上の年次有給休暇が付与される労働者」で、管理監督者・有期雇用労働者も含む。基準日から1年以内に5日を取得させなければ、対象労働者1人につき1罪として30万円以下の罰金の対象（労働基準法39条7項・120条、厚生労働省）
- 要点2：チェックの精度を決めるのは「カウントの定義」。半日単位は0.5日として控除できるが、時間単位年休と法定外の特別休暇は労働者が自ら取得しても5日から控除できない。ここを勤怠SaaSの合計値だけで見ると誤判定する
- 要点3：基準日は人ごとに違い、前倒し付与や基準日統一をしている会社では「月数÷12×5日」の按分ルールまで入る。締め後の集計では遅く、残り期間と残り日数から未達リスクを先読みするアラートまでコード化して初めて、労務担当が時季指定に動ける時間が生まれる
対象読者：人事・労務部門とAI活用を進める開発者・PM・経営企画
今日やること：自社の勤怠システムから年休の取得記録を1年分エクスポートして、「半日単位」「時間単位」「特別休暇」が取得記録上どう区別されているかを確認する
先に断っておくと、本記事は複数の支援経験をもとに一般化した実装パターン解説です。登場する数値は想定モデルケースの試算で、特定企業の実測値ではありません。また、年次有給休暇の付与・時季指定に関する法的な判断は、最終的に社会保険労務士・労働基準監督署への確認が必要です。この記事が扱うのは「その手前の突合と検知を機械化する」部分です。
労務まわりのAI活用を支援していると、年5日の話は毎回ほぼ同じ形で出てきます。「うちは取得率が高いから大丈夫だと思っていたら、年度末に未達の人が数名見つかって慌てた」という形です。会社全体の取得率がどれだけ高くても、この義務は労働者ごと・基準日ごとに判定されるので、平均値は何の保証にもなりません。中途入社で基準日がずれている人、育児休業から年度途中で復帰した人、半日単位で細かく取っている人。未達はいつも「全体集計では見えない端」で起きます。
この構造は、前回書いた勤怠データから36協定の上限超過を先読みするClaude Code実装とまったく同じです。法令要件を決定的なコードに固定し、AIには表記ゆれの正規化とレポート整形だけを任せる。労務レーンの2本目として、今回は年次有給休暇の取得義務チェックを同じ骨格で組んでいきます。
先に法律の数字を固定する——年5日義務を構成する6つのルール
実装に入る前に、判定コードに固定すべきルールを厚生労働省の一次情報で確定させます。出典は労働基準法の条文（e-Gov法令検索）と、厚生労働省のパンフレット「年5日の年次有給休暇の確実な取得 わかりやすい解説」（2023年2月版）です。
| ルール | 内容 | 根拠 |
|---|---|---|
| 対象者 | 年次有給休暇が10日以上付与される労働者。管理監督者・有期雇用労働者を含む。パートタイム労働者も比例付与で10日以上になれば対象 | 労働基準法39条7項 |
| 義務の内容 | 基準日（付与日）から1年以内に5日、使用者が時季を指定して取得させる | 労働基準法39条7項 |
| 控除ルール | 労働者が自ら請求・取得した日数、計画的付与（計画年休）で取得させた日数は5日から控除。合計5日に達した時点で時季指定は不要かつ不可 | 労働基準法39条8項 |
| 意見聴取 | 時季指定にあたっては労働者の意見を聴き、その意見を尊重するよう努める | 労働基準法施行規則24条の6 |
| 年次有給休暇管理簿 | 時季・日数・基準日を労働者ごとに記録した書類を作成し、対象期間中およびその満了後3年間保存（施行規則の本則は5年間、附則71条により当分の間3年間） | 労働基準法施行規則24条の7・附則71条 |
| 罰則 | 年5日を取得させなかった場合、30万円以下の罰金。違反は対象労働者1人につき1罪として扱われる | 労働基準法120条 |
カウントの定義も一次情報で確定できます。厚生労働省パンフレットのQ&Aによると、半日単位の年休は取得1回につき0.5日として5日から控除できる一方、時間単位年休は使用者による時季指定の対象にならず、労働者が自ら取得した場合でもその時間分を5日から控除できません。また、法定の年次有給休暇とは別に会社が設けている特別休暇（法定外の有給の休暇）を取得した日数も控除できません。前年度からの繰越分を取得した場合は、繰越分か当年度分かを問わず控除できます。
もうひとつ、判定を複雑にするのが前倒し付与です。入社と同時に10日以上付与するなど、法定の基準日（雇入れから6か月後)より前に10日以上付与した場合は、その付与日から1年以内が履行期間になります（施行規則24条の5）。さらに、初年度と2年目で基準日がずれて履行期間が重複する場合は、重複を通した期間の長さに応じて「月数÷12×5日」を按分取得させる方法も認められています。18か月なら7.5日です。この按分ルールは手計算でやると必ずどこかで壊れるので、コードに落とす価値が最も大きい部分です。
取得率が高い会社でも未達者は出る——全体集計の落とし穴
勤怠SaaSの多くには年休の取得状況画面があります。それでも支援先でチェックの仕組み化を求められるのは、全体集計と個人別判定の間に、次のようなギャップがあるからです。
- 基準日が人ごとに違う — 中途採用が多い会社では、履行期限が毎月どこかで到来します。「年度末にまとめて確認」という運用自体が構造的に間に合いません
- カウント対象の混在 — 時間単位年休や特別休暇を含んだ「取得日数合計」で見ると、実際には5日に達していない人が達しているように見えます
- 前倒し付与・基準日統一の按分 — 履行期間の重複と按分（月数÷12×5日）を正しく扱える集計画面は多くありません
- 年度途中の変化 — 育児休業からの復帰者にも義務はあり（残りの労働日数が足りない場合を除く）、契約社員から正社員への転換で基準日が前倒しになるケースもあります。名簿が動くたびに判定条件が変わります
ある支援先の労務担当者は、基準日別の管理表を月1回、半日かけて手作業で更新していました。それでも「半日と時間単位の区別はセルの色分けで覚えている」状態で、担当者が休むと誰も判定できない。この属人化の解消が、そのまま実装要件になります。
実装の全体像——台帳正規化・判定エンジン・先読みアラートの3層
構成は労務レーン共通の3層です。36協定チェックと同じく、法律の数字はコードに固定し、AIは揺れの吸収と整形だけを担当します。
- 台帳正規化層 — 勤怠SaaSからエクスポートした付与・取得データを「社員ID・基準日・付与日数・取得日・取得単位（1日/半日/時間/特別休暇）」の正規形に変換する。Claude Codeにスクリプトを書かせる部分で、実装工数の大半はここ
- 判定エンジン層 — 労働者ごとに履行期間（基準日から1年、按分適用時は重複を通した期間）を確定し、控除できる取得だけを合算して残り日数を計算する。ルールは決定的なコードで、AIは介在させない
- 先読みアラート層 — 履行期限までの残り月数と残り日数から「未達リスク」を3段階で判定し、月次で労務担当と部門長に届くレポートを生成する。期限の2〜3か月前に時季指定の候補者リストが自動で出てくる状態がゴール
出力の正本は年次有給休暇管理簿そのものではなく「管理簿と突合するチェックレポート」に置きます。管理簿は労働者名簿や賃金台帳とあわせて調製でき、必要なときにいつでも出力できる仕組みならシステム上での管理も認められているので（厚生労働省パンフレット）、既存の勤怠SaaSを正本のまま、チェック側だけを外付けするのが現実的です。この「正本はいじらず突合レポートを外付けする」発想は、経理の月次決算・残高照合の仕組み化で使ったものと同じです。
実装コード例1：取得記録の正規化と基準日レジストリ
最初に確定させるのは「取得1件が何日分としてカウントできるか」です。勤怠SaaSのエクスポートは製品ごとに列名も単位表記も違うので、正規化層でカウント値まで解決してしまいます。
# normalize.py — 年休取得記録の正規化（抜粋）
# カウント規則（労基法39条7項・8項、厚労省パンフレットQ&Aに基づき固定）
# 1日単位 -> 1.0日として控除可
# 半日単位 -> 0.5日として控除可
# 時間単位 -> 控除不可（0.0日扱い・ただし記録は保持）
# 特別休暇 -> 控除不可（法定年休ではない）
COUNT_RULES = {
"full_day": 1.0,
"half_day": 0.5,
"hourly": 0.0, # 時間単位年休は5日から控除できない
"special": 0.0, # 法定外の特別休暇は控除できない
}
def normalize_leave_records(df, column_map):
"""勤怠SaaSのエクスポートを正規形に変換する。
column_map はシステムごとの列名対応（Claude Codeに生成させる部分）。
"""
out = df.rename(columns=column_map)
out["unit"] = out["unit_raw"].map(UNIT_ALIASES) # 表記ゆれ辞書
unknown = out[out["unit"].isna()]
if len(unknown):
# 未知の単位表記は落とさず必ず人間に返す
raise ValueError(f"未知の取得単位が{len(unknown)}件: "
f"{unknown['unit_raw'].unique()[:5]}")
out["countable_days"] = out["unit"].map(COUNT_RULES)
return out[["employee_id", "taken_date", "unit", "countable_days"]]
ポイントは、未知の単位表記が出たら推測せずに例外で止めることです。「リフレッシュ休暇」のような社独自の休暇名を年休として数えるかどうかは法解釈と就業規則の確認が必要で、コードが勝手に決めてよい話ではありません。
次に基準日レジストリです。判定の起点になる基準日は、法定どおり(雇入れ6か月後)の会社なら入社日から機械的に計算できますが、前倒し付与や基準日統一をしている会社では就業規則と労使協定から確定させる必要があります。
# basedate.py — 基準日と履行期間の確定（抜粋）
from dateutil.relativedelta import relativedelta
def fulfillment_window(base_dates, grant_days):
"""基準日リストから履行期間を返す。
按分ルール: 履行期間が重複する場合、通した期間の
月数/12*5 日を当該期間に取得させる方法が認められる
(労基法施行規則24条の5、厚労省パンフレット)。
"""
windows = []
for i, (bd, days) in enumerate(zip(base_dates, grant_days)):
if days < 10:
continue # 10日未満の付与年は義務対象外
end = bd + relativedelta(years=1, days=-1)
prev = windows[-1] if windows else None
if prev and bd <= prev["end"]:
# 重複あり: 通した期間で按分 (月数/12*5)
months = month_span(prev["start"], end)
required = round(months / 12 * 5, 1) # 18か月なら7.5日
windows[-1] = {"start": prev["start"], "end": end,
"required": required, "prorated": True}
else:
windows.append({"start": bd, "end": end,
"required": 5.0, "prorated": False})
return windows
実装コード例2：判定エンジンと「間に合わない人」の先読み
正規化が済めば、判定エンジン自体は短く書けます。重要なのは「未達かどうか」（過去形）ではなく「このままだと未達になるか」（未来形）を出すことです。
# judge.py — 年5日義務の判定と先読み（抜粋）
from datetime import date
def check_window(win, records, today: date):
"""1人×1履行期間の判定。"""
taken = sum(r["countable_days"] for r in records
if win["start"] <= r["taken_date"] <= win["end"])
remaining = max(win["required"] - taken, 0.0)
days_left = (win["end"] - today).days
if remaining == 0:
level = "OK" # 5日到達済み: 時季指定は不要かつ不可
elif days_left < 0:
level = "VIOLATION" # 履行期限超過: 専門家に即相談
elif days_left <= 60 and remaining >= 2:
level = "RED" # 残り2か月で2日以上不足
elif days_left <= 120 and remaining >= 3:
level = "YELLOW" # 残り4か月で3日以上不足
else:
level = "WATCH"
return {"employee_id": win["employee_id"],
"window": (win["start"], win["end"]),
"required": win["required"], "taken": taken,
"remaining": remaining, "days_left": days_left,
"level": level}
RED/YELLOWのしきい値（残り2か月で2日以上不足、など）は法律の数字ではなく運用パラメータなので、労務担当と相談して決めます。ここだけは会社ごとに変えてよい部分です。逆に required と countable_days の計算は法律由来なので、設定ファイルで書き換えられないようコード側に固定します。この「法律の数字はコード、運用の数字は設定」という切り分けは、経費精算の規程照合・上限チェックの自動化と共通の設計です。
月次で回すと、レポートはこんな形になります（想定モデルの出力例）。
## 年5日取得義務 月次チェック 2026-07（従業員218名・対象203名）
- VIOLATION: 0名
- RED: 3名（履行期限まで60日以内・残り2日以上）
- E0142 期限2026-09-30 取得2.5日 残り2.5日 ※半日のみで消化中
- E0201 期限2026-08-31 取得3.0日 残り2.0日 ※時間単位6hは控除対象外
- E0187 期限2026-09-30 取得2.0日 残り3.0日 ※4月に育休復帰
- YELLOW: 7名 / WATCH: 12名 / OK: 181名
「時間単位6hは控除対象外」のような注記が自動で付くのが、正規化層でカウント規則を解決しておくことの効きどころです。担当者はこのリストを持って、意見聴取と時季指定の調整に入るだけになります。
Claude Codeに投げているプロンプト集
実装フェーズで実際に使っているプロンプトを5つ挙げます。いずれも末尾の一行（不足情報の確認）を省くと手戻りが増えます。
1. エクスポート列の意味調査
この勤怠システムの年休エクスポートCSV（ヘッダーとサンプル10行を添付）について、
各列が「付与」「取得」「残日数」のどれを指すか、取得単位（1日/半日/時間）が
どの列でどう表現されているかを整理してください。
推測になる列は「推測」と明記し、不足している情報があれば、
最初に質問してから作業を開始してください。
2. 正規化スクリプトの生成
添付の列定義メモをもとに、このCSVを employee_id / taken_date / unit /
countable_days の正規形に変換するPython関数を書いてください。
カウント規則は COUNT_RULES 定数（既存コード）を必ず参照し、
独自の数値を定義しないでください。未知の単位表記は例外で停止させてください。
仮定した点は必ず"仮定"と明記してください。
3. 境界テストケースの生成
judge.py の check_window に対するpytestテストを書いてください。
必ず含めるケース: (1)半日0.5日×10回で5.0日到達 (2)時間単位のみで
合計40時間取得しても remaining が減らないこと (3)基準日重複時の
按分7.5日 (4)履行期限当日 (5)10日未満付与の年はwindow自体が生成されないこと。
期待値の根拠（条文・厚労省パンフレットの該当箇所）をコメントで添えてください。
4. 月次レポートの整形
判定結果のJSONから、労務担当向けの月次レポート（Markdown）を生成してください。
RED該当者には「なぜ残っているか」の機械的な注記（半日のみ/時間単位は控除対象外/
復帰月）を付け、時季指定を促す文言は入れないでください。時季指定の判断は
人間が行います。数字と固有名詞は、根拠（元データの行）を添えてください。
5. 就業規則との突合チェックリスト
添付の就業規則の年次有給休暇の条項を読み、この判定エンジンの前提
（基準日の決め方、前倒し付与の有無、計画年休の有無、半日単位の可否）と
食い違う箇所を洗い出してください。法解釈が必要な論点は「要社労士確認」と
ラベルを付けて分離してください。不足している情報があれば、最初に質問して
から作業を開始してください。
AIに任せてはいけないこと
このシステムでAIが担当するのは正規化・テスト生成・レポート整形までです。次の4つは意図的にAIの外に置いています。
- 時季指定の判断そのもの — 誰にいつ取得させるかは、意見聴取（施行規則24条の6）を経た人間の意思決定です。AIが「この日に休ませるべき」と出力する設計にはしません。リストアップまでがシステムの仕事です
- 就業規則・労使協定の解釈 — 特別休暇を年休に振り替えられるか、計画年休の協定が有効か、といった論点は社会保険労務士の領域です。判定エンジンには「確認済みの結論」だけをルールとして固定します
- 5日・0.5日・按分式などの法定数値 — プロンプトで毎回生成させると、いつか違う数字が混入します。法律由来の定数はコードにハードコードし、AIには参照だけさせます
- 氏名などの個人情報の投入 — 取得状況は個人の休暇履歴そのものです。AIに渡す前に氏名を社員IDに置換し、健康状態や休職理由など判定に不要な列は正規化の段階で落とします。個人情報の取り扱いは所属組織の規程・コンプライアンスに従ってください
想定される効果（試算）
以下は従業員200名規模・中途採用が毎月ある会社を想定したモデルケースの試算です。実測値ではなく、導入検討時の参考値として見てください。
| 指標 | 導入前（手作業） | 導入後（想定） |
|---|---|---|
| 月次の取得状況確認 | 基準日別の管理表を半日〜1日かけて更新 | CSVエクスポート＋実行で30分程度 |
| 未達リスクの検知タイミング | 年度末の棚卸しで発覚（期限まで1〜2か月） | 期限4か月前にYELLOWで自動リスト化 |
| カウント誤り（時間単位・特別休暇の混入） | 担当者の記憶と色分けに依存 | 正規化層で機械的に分離・注記 |
| 担当者交代時の引き継ぎ | 管理表の運用ルールが属人化 | ルールはコードとテストに明文化 |
効果の中心は工数削減よりも「発見が早くなること」です。期限2か月前に3日残っている社員に時季指定でまとめて休んでもらうのは、現場との調整コストが高い。4か月前に分かっていれば、月1日ずつの調整で収まります。
段階的導入のロードマップ
Phase 1（1〜2か月）: 勤怠システム1つ・過去1年分のデータで正規化と判定を作り、手作業の管理表と全件突合する。差分が出た箇所は必ず原因（データ側か、手作業側か、ルール解釈か）を確定させる。ここで見つかる「手作業側の誤り」が、導入の社内説得材料になります。
Phase 2（2〜4か月）: 月次の自動実行とレポート配信を定着させる。育休復帰・雇用形態転換・中途入社の基準日イベントを人事システム側から自動で取り込む接続を作り、名簿更新の手作業をなくす。
Phase 3（4〜6か月）: 同じ骨格を労務の他の台帳チェックへ横展開する。36協定の上限チェック、派遣管理台帳の期限管理など、「法定ルール×名簿×期限」の形をした業務は同じ3層構成がそのまま使えます。
【要注意】よくある失敗パターンと回避策
失敗1：時間単位年休を5日にカウントしてしまう
❌ 勤怠SaaSの「年休取得日数合計」をそのまま5日と比較する
⭕ 取得単位ごとに控除可否を解決してから合算する（時間単位・特別休暇は控除不可）
なぜ重要か：時間単位で細かく取る社員ほど合計値は大きく見えるため、合計ベースの判定は「実際は未達なのにOK表示」という最悪の誤判定を起こします。厚生労働省パンフレットのQ&Aで控除の可否が明示されているので、必ず単位別に扱ってください。
失敗2：基準日を入社日や年度初日と思い込む
❌ 全社員を4/1起点の同じ1年間で判定する
⭕ 付与実績から基準日を人ごとに確定し、前倒し・統一がある場合は按分ルールまで実装する
なぜ重要か：法定の基準日は雇入れから6か月後で、人ごとに違います。基準日を統一している会社でも、統一初年度の重複期間には按分（月数÷12×5日）が絡みます。ここを単純化すると、判定が1年近くずれる社員が出ます。
失敗3：チェックレポートを年休管理簿の代わりにしてしまう
❌ 自作レポートを正本にして管理簿の整備を後回しにする
⭕ 管理簿（時季・日数・基準日）は勤怠システム側で整備し、レポートは突合用の外付けに徹する
なぜ重要か：年次有給休暇管理簿は施行規則24条の7で作成・保存が義務付けられた法定書類です。自作ツールを正本にすると、保存期間（当分の間3年）や記載事項の要件まで自前で背負うことになります。役割分担を最初に切ってください。
失敗4：アラートを出して終わりにする
❌ REDリストを労務担当のメールボックスに送って完了とする
⭕ 意見聴取→時季指定→取得確認までの後工程を運用として設計し、取得されたかを翌月の判定で必ず検証する
なぜ重要か：厚生労働省のQ&Aが明言するとおり、時季指定をしただけでは足りず、実際に基準日から1年以内に5日取得させていなければ法違反として扱われます。検知は義務履行の入口にすぎません。
よくある質問
Q. パート・アルバイトも年5日義務の対象になりますか？
当年度に付与される法定の年次有給休暇が10日以上であれば対象です。比例付与のパートタイム労働者では、たとえば週4日勤務なら勤続3年6か月以降（付与10日）、週3日勤務なら勤続5年6か月以降（付与10日）で対象に入ります。なお、前年度からの繰越分を合わせて10日以上になっても、当年度付与の法定日数が10日未満なら対象外です（厚生労働省パンフレットQ&A）。管理監督者や有期雇用労働者も対象に含まれる点に注意してください。
Q. 半日単位や時間単位の取得は5日にカウントできますか？
半日単位は取得1回につき0.5日として5日から控除できます。使用者が時季指定する際も、労働者の希望があれば半日単位での指定が可能です。一方、時間単位年休は使用者による時季指定の対象にならず、労働者が自ら取得した場合でもその時間分を5日から控除することはできません。会社独自の特別休暇（法定外）も控除できません。判定コードではこの区別を最初に固定するのが安全です。
Q. 未達の労働者が1名でも出たら罰則を受けるのですか？
年5日を取得させなかった場合は労働基準法120条により30万円以下の罰金の対象で、違反は対象労働者1人につき1罪として扱われます。ただし厚生労働省は、労働基準監督署の監督指導では原則としてまず是正に向けて丁寧に指導し改善を図るとしています。休職などで履行が不可能だった場合は法違反を問わないという取り扱いも示されています。個別の事案は所轄の労働基準監督署または社会保険労務士に確認してください。
Q. 入社と同時に有給を付与している場合、判定はどう変わりますか？
法定の基準日より前に10日以上を付与した場合は、その付与日から1年以内に5日を取得させる必要があります。また、初年度と翌年度で基準日がずれて履行期間が重複する場合は、重複を通した期間の月数÷12×5日を按分して取得させる方法が認められています（例：18か月なら7.5日）。10日のうち一部だけを前倒し付与した場合は、合計が10日に達した日が起点になります。自社の付与方式がどのパターンかを就業規則で確定させてから、履行期間の計算をコードに落としてください。
Q. 年次有給休暇管理簿はシステム上の管理でもよいですか？保存期間は？
時季・日数・基準日を労働者ごとに記録し、必要なときにいつでも出力できる仕組みであれば、システム上で管理しても差し支えないとされています。労働者名簿または賃金台帳とあわせて調製することも可能です。保存期間は対象期間中およびその満了後3年間です（施行規則の本則は5年間で、附則71条により当分の間3年間とされています）。本記事のチェックレポートは管理簿の代替ではなく、管理簿と突合する監査用の位置付けで運用してください。
まとめ：今日から始める3つのアクション
- 今日やること：勤怠システムから年休の付与・取得データを1年分エクスポートし、半日単位・時間単位・特別休暇が取得記録上どう区別されているかを確認する。区別できない場合、それが最初に解くべき課題です
- 今週中：社員ごとの基準日を付与実績から一覧化し、前倒し付与・基準日統一の有無を就業規則で確定させる。基準日が確定すれば履行期限は機械的に計算できます
- 今月中：Phase 1（過去1年分の再判定）を小さく回し、手作業の管理表との差分を労務担当と一緒にレビューする。時間単位や特別休暇の混入が見つかったら、その時点で判定ルールを社労士に確認します
年5日チェックは、36協定の上限超過の先読みに続く労務レーンの2本目で、派遣元・派遣先管理台帳の仕組み化とも同じ「法定ルールを決定的なコードに固定し、AIは正規化と整理を担う」パターンです。名簿と期限がある法定業務なら、この骨格はほぼそのまま流用できます。
著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』（SBクリエイティブ）。
参考・出典
- 労働基準法（昭和22年法律第49号）第39条・第109条・第120条 — e-Gov法令検索（参照日: 2026-07-30）
- 労働基準法施行規則 第24条の5〜24条の7・附則第71条 — e-Gov法令検索（参照日: 2026-07-30）
- 厚生労働省「年5日の年次有給休暇の確実な取得 わかりやすい解説」（2023年2月版）（参照日: 2026-07-30）
- 厚生労働省「働き方改革」の実現に向けて（政省令・パンフレット一覧）（参照日: 2026-07-30）
- 厚生労働省 年次有給休暇取得促進特設サイト（参照日: 2026-07-30）
ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。
