# Work Regulations Draft

> 厚生労働省「モデル就業規則」の規程例をもとに、日本の就業規則を新規に作成する。事業場の実情を聞き取り、労基法89条の必要記載事項を満たした条文を組み立て、Word/Markdownで出力し、労基署への届出手続まで案内する。就業規則を作りたい・作成したい・新しく整備したい・ゼロから用意したい・ひな形がほしい・テンプレートがほしいと言われたとき、会社を設立したので規程を揃えたい・従業員が10人になるので就業規則が必要と相談されたとき、賃金規程や育児介護休業規程などの別規程を新規作成するときは必ずこのスキルを使うこと。既存の規程を点検する場合は work-regulations-check を使う。

- Skill: `ebi-lock/work-regulations-draft` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add ebi-lock/work-regulations-draft`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ebi-lock/work-regulations-draft/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: Ebi-lock (https://skillmd.com/u/ebi-lock)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/ebi-lock/work-regulations-draft

---


# 就業規則の作成

厚生労働省「モデル就業規則」の規程例をもとに、事業場の就業規則を作る。

**このファイル中の `scripts/…` と `references/…` は、すべてこのスキルのディレクトリからの相対パス。**
スキル読み込み時に示されるベースディレクトリを基点に実行すること
（例: `python3 <ベースディレクトリ>/scripts/model_rules.py …`）。

## このスキルの位置づけ

出力は **社労士・弁護士に確認してもらうための下書き** であり、完成品ではない。
就業規則の作成・変更は社会保険労務士の業務に関わる領域であり、実際に届け出る前には
専門家の確認が要る。これは手を抜く理由ではなく、書き方を決める前提である。

下書きとして役に立つとは、**専門家がそのまま赤入れできる状態**を意味する。
だから次の2つを守る。

- **条文を自分の言葉で創作しない。** 厚労省の規程例を引いて、事業場の事情に合わせて選び、
  数値と固有名詞を埋める。創作した条文は、法令の要求を満たしているかを誰も検証できない
- **埋まらなかった箇所を空欄のまま残さない。** 「〇日」のまま納品された規程は、
  そのまま運用されて事故になる。決まっていない項目は本文から外し、
  「決める必要がある項目」として別建てで列挙する

## 全体の流れ

1. 何を作るのか決める
2. 事業場の実情を聞き取る
3. 規程例を取得する
4. 条文を組み立てる
5. 自己点検する
6. 出力して、次にやることを案内する

---

## 1. 何を作るのか決める

就業規則は本則だけとは限らない。まず範囲を決める。

| 作るもの | どう扱うか |
|---|---|
| 就業規則（本則） | このスキルの主対象 |
| 賃金規程 | 本則に書ききるか、別規程にするか。従業員数が多い・手当が複雑なら別規程 |
| 育児・介護休業規程 | **原則として別規程**。制度が細かく改正も多い。規程例も別に公開されている |
| パートタイマー就業規則 | 正社員以外がいるなら必要。本則を適用除外にしたまま作らないと、その層に適用される規則が無いことになる |
| 退職金規程 | 制度があるなら別規程が扱いやすい |

判断がつかないときは、**まず本則を作り、別規程は「別に定める」で委任して、
委任先を作る必要がある旨を最後に列挙する**。委任先が存在しない状態で終わらせない。

`references/assembly.md` に切り分けの基準と、本則の標準的な章立てがある。

## 2. 事業場の実情を聞き取る

**ここを飛ばすと、ただのひな形コピーになる。** 就業規則は事業場ごとに違うから作る意味がある。

聞き取りは `scripts/intake.py` が順を追って進める。質問の順序・分岐・進捗を
スクリプト側が持つので、順番が飛んだり、聞いたつもりで聞いていなかったり、
制度が無いのに細目を聞いたりすることがない。

### 進め方

```bash
python3 scripts/intake.py --start <作業ディレクトリ>/hearing.json
```

回答ファイルのパスを1つ決めて開始する。以降、そのファイルに回答が溜まっていく。
**途中で会話が途切れても、同じファイルを指せば続きから再開できる。**

出てきた質問を、**1回分ずつユーザーに聞く。** 既定は5問。多いと感じたら `--size 3` にする。

```bash
python3 scripts/intake.py --next            # 次に聞く質問
python3 scripts/intake.py --next --size 3   # 3問ずつ
```

聞くときは **AskUserQuestion ツールを使う。** スクリプトが `options` を出している質問は、
そのまま選択肢にする。「モデル就業規則の例」と印がついているものを先頭に置くと答えやすい。
選択肢が無い質問（会社名など）は普通に尋ねる。

答えをもらったら記録する。

```bash
python3 scripts/intake.py --answer base.company="株式会社〇〇" base.industry="小売業"
```

これを、質問が尽きるまで繰り返す。

```bash
python3 scripts/intake.py --status    # どこまで進んだか
```

### 決まらない項目は保留にする

```bash
python3 scripts/intake.py --answer holiday.annual=保留
```

**推測で埋めない。** 「〇日」のまま納品された規程はそのまま運用されて事故になる。
保留にした項目は最後に「決める必要がある項目」として出る。

```bash
python3 scripts/intake.py --pending
```

### 聞き取りが終わったら

```bash
python3 scripts/intake.py --summary > <作業ディレクトリ>/聞き取り結果.md
```

**この結果をユーザーに見せて、認識が合っているか確認してから条文を書き始める。**
ここで食い違いに気づけば書き直しが1回で済む。書いてから気づくと全部やり直しになる。

### 質問するときの姿勢

- **白紙から答えさせない。** スクリプトが出す `options` と「モデル就業規則の例」を
  そのまま示す。相手は規程の専門家ではない
- **「なぜ」を伝える。** スクリプトが `why` を出している質問は、その理由を添える。
  「10人以上なら届出義務があるので」と言われれば、相手も真剣に数える
- **`caution` は必ず伝える。** 「口座振込には本人の同意が前提です」のような注意は、
  答えを変えさせるために書いてある
- **矛盾に気づいたら、その場で聞き返す。** 後でまとめて指摘するより早い。
  相手も気づいていないことが多い

### 全部の質問に答えてもらう必要はない

質問は分岐する。「フレックスを使っていない」と答えれば、コアタイムは聞かれない。
制度が無いものは自動的に飛ぶので、実際に答えるのは全体の半分程度になることが多い。

急いでいる場合は、**セクション1〜5（基本情報・従業員構成・労働時間・休日・賃金）まで
答えてもらえば骨格は書ける。** 残りは既定値で組み立て、後から確認してもらう方法もある。
その場合は、既定値で置いた箇所を必ず明示する。

### 聞き取り項目の全体像

`references/intake.md` に、何をなぜ聞くのかをまとめてある。
スクリプトの質問文だけでは背景が足りないときに読む。

質問の内容を足したり直したりするなら、質問バンクの JSON を編集する。スクリプトは触らなくてよい。
バンクは点検スキル側に1つだけ置いてある（`work-regulations-check/references/questions.json`）。
2箇所に置くと片方だけ直る事故になるため、共有している。

## 3. 規程例を取得する

```bash
python3 scripts/model_rules.py --toc                    # どんな条があるか
python3 scripts/model_rules.py --grep 年次有給休暇       # 条文を引く
python3 scripts/model_rules.py --grep 懲戒 --explain     # 規程例＋厚労省の解説
python3 scripts/model_rules.py --grep 出生時育児休業      # 育介法まわり
```

引ける規程例は2つある。

| 名前 | 内容 |
|---|---|
| `model` モデル就業規則 | 就業規則の本体 |
| `ikuji` 育児・介護休業等に関する規則の規定例 | **育介法まわり** |

**産後パパ育休・子の看護等休暇・柔軟な働き方の措置などはモデル就業規則に入っていない。**
育児介護休業規程を作るときは `--source ikuji` を使う。ケース①②③のように選択肢が
並んでいるので、聞き取った事情に合うものを選ぶ。

`--explain` で出る厚労省の解説には、その規定を置く理由と、事業場ごとに変えてよい範囲が
書かれている。選択に迷ったらここを読む。

### 規程例をそのまま使ってよいか

モデル就業規則は**下線部を各事業場で埋める前提**で書かれている。埋めずに出してはいけない。
また、規程例のうち「〜する例」「〜しない例」のように選択肢になっている条は、
どちらかを選んだうえで、選んだ理由を後で説明できるようにしておく。

## 4. 条文を組み立てる

### 必要記載事項を先に確保する

`references/assembly.md` の章立てに沿って組み立てるが、**先に労基法89条の必要記載事項が
埋まるかを確認する。** 章立てを埋めることが目的ではない。

絶対的必要記載事項（これが欠けると89条違反）:
1. 始業・終業の時刻、休憩時間、休日、休暇、交替制の就業時転換
2. 賃金の決定・計算・支払の方法、締切り・支払の時期、昇給
3. 退職に関する事項（解雇の事由を含む）

相対的必要記載事項は、**その制度を設ける場合にのみ**必要。制度が無ければ書かない。
無い制度の条文を入れると、運用していない規定が残って後で紛争の種になる。

### 法令の要求を満たしているか確認する

数値を書くときは、記憶ではなく条文を引く。

```bash
python3 scripts/fetch_law.py 労基法 89 32 34 35 37 39
python3 scripts/fetch_law.py 労基法 --status     # 未施行の改正がないか
```

特に間違えやすいもの:
- 休憩（労基法34条）— 6時間超45分、8時間超60分。**一斉付与が原則**で、交替で与えるには労使協定
- 割増率（37条）— 時間外25%以上、月60時間超50%以上、深夜25%、法定休日35%
- 年休（39条）— 6か月8割で10日、以降の加算日数、比例付与、**年5日の時季指定義務**
- 減給の制裁（91条）— 1回は平均賃金1日分の半額以下、総額は一賃金支払期の賃金総額の10分の1以下
- 解雇予告（20条）— 30日前予告または平均賃金30日分

### 最新の改正を織り込む

作った時点で古い規程を納品しないこと。

```bash
python3 scripts/mhlw_bills.py --recent 3         # 直近の国会提出法案
python3 scripts/fetch_law.py 労施法 --status     # 未施行の改正の有無
```

**未施行の改正は、施行日を明記したうえで織り込むかどうかを相手に選ばせる。**
勝手に入れても、勝手に落としてもいけない。改定には意見聴取と届出の時間がかかるので、
数か月先に施行されるものは先に入れておくほうが合理的なことが多い。

### 条文を書くときの作法

- 文体を統一する。規程例は「〜するものとする」「〜しなければならない」を使い分けている
- 用語を統一する。「従業員」と「社員」を混ぜない。聞き取った呼称に揃える
- 条見出しを必ず付ける。あとで参照するときに効く
- 内部参照は最小限にする。「第○条の定めにより」を多用すると、改定のたびに参照がずれる
- 空欄を残さない。決まっていない項目は条文から外し、保留リストに移す

## 5. 自己点検する

**書いたら必ず点検する。** 組み立ての過程で条番号がずれるのは普通に起きる。

```bash
python3 scripts/check_structure.py <出力したテキスト> --refs
```

見るところ:
- 条番号の飛び・重複がないか
- 内部参照の解決先が、参照元の文意と噛み合っているか（**ここは目で読む**）
- 「別に定める」で委任した規程が、作成予定リストに載っているか
- 用語のゆれ

そのうえで、必要記載事項が埋まっているかをもう一度確認する。
点検の観点は work-regulations-check スキルの `references/required-items.md` と同じ。
同じプラグインに入っているので、迷ったらそちらを読む。

## 6. 出力して、次にやることを案内する

### 出力

既定は Markdown。Word が要ると言われたら `python-docx` で .docx を作る
（`pip3 install python-docx` が要る）。

本文の末尾には必ず附則を置く。

```
附　則
1 この規則は、〇年〇月〇日から施行する。
```

### 労使協定が別に必要なものを洗い出す

規程に書いただけでは運用できない制度がある。**規程を作って終わりにしない。**

- 賃金からの法定外控除（労基法24条1項ただし書）
- 時間単位年休（同39条4項）／年休の計画的付与（同39条6項）
- 休憩の一斉付与の適用除外（同34条2項ただし書）
- 変形労働時間制（1年単位・1週間単位は協定必須）／フレックスタイム制
- 事業場外みなし（所定超えの場合）／裁量労働制
- 育児介護休業の対象者からの除外
- 時間外・休日労働（36協定）

該当するものを、締結が必要な労使協定として列挙する。

### 一緒に渡すもの

規程本体だけでは届出できない。次を添えて、何をすればよいかが分かる状態にする。

```markdown
## 決める必要がある項目

| 項目 | 該当条 | 決まっていないこと |
|---|---|---|

## 別途作成が必要な規程

| 規程 | 本則での委任先 | 理由 |
|---|---|---|

## 締結が必要な労使協定

| 協定 | 根拠 | 関係する条 |
|---|---|---|

## 届出までの手順

1. 内容を社会保険労務士または弁護士に確認してもらう
2. 過半数労働組合、無ければ**過半数代表者を選出**して意見を聴く（労基法90条）
   - 求められているのは「**意見を聴く**」ことであって「同意を得る」ことではない。
     反対意見でも、意見書を添付すれば届出は受理される
   - 代表者は投票・挙手などの民主的な方法で選ぶ。**会社が指名してはいけない**
   - 管理監督者（労基法41条2号）は代表者になれない
   - パート・有期に関する規則は、その層の代表者の意見も聴くよう努める（パート有期法7条）
3. **就業規則＋意見書＋就業規則（変更）届**を、所轄の労働基準監督署に届け出る
   （常時10人以上の事業場。事業場ごとに届け出る）
4. 従業員に周知する（労基法106条、則52条の2）
   - 配付、見やすい場所への掲示・備付け、電子データへのアクセス確保のいずれか
   - **周知していない就業規則は効力を争われる**

## この下書きの前提

<聞き取った内容と、こちらで置いた前提を列挙>
```

### 作って終わりではないことを伝える

就業規則は一度作れば済むものではない。最後にこの循環を書き添える。

```
法改正 → 自社制度への影響確認 → 就業規則の確認 → 改定
  → 意見聴取 → 届出 → 周知 → （次の改正へ）
```

**特に育児介護休業法は毎年のように改正される。** 年1回は施行状況を確認する運用を勧める。

```bash
python3 scripts/mhlw_bills.py --recent 3
python3 scripts/fetch_law.py 育介法 --status
```

最後に、**法的助言ではないこと・専門家の確認が必要なことを明記する。**

---

## 既存の規程を改定する場合

新規作成ではなく改定なら、先に work-regulations-check で現状を点検してから、
指摘された箇所だけを直す。全部を作り直すと、その事業場が積み上げてきた
固有の運用（規程例には無いが理由があって入っている条文）を消してしまう。

改定では**不利益変更**に注意する。賃金や労働時間を労働者に不利に変えるには、
原則として労働者の同意が要る（労働契約法9条）。同意なく変える場合は変更の合理性が
問われる（同10条）。該当しそうな変更は、その旨をはっきり書いて相手に判断させる。

