Rules ファイル設計 — 安全ルールを宣言的に書く

Claude に守らせたいルールが増えると、CLAUDE.md が肥大化して管理しにくくなります。shared/rules/*.md にルールを分割管理することで、保守性と明確さを両立できます。このページでは実際のルールファイルを例に、宣言的なルール設計の手順を学びます。

---

仕組み

shared/rules/*.md の役割

ルールファイル（rules file）とは、Claude に対する「非交渉ルール（Non-Negotiable Rules）」を個別の Markdown ファイルとして管理する仕組みです。

CLAUDE.md に全ルールを詰め込む代わりに、ルールごとにファイルを分割します。CLAUDE.md には各ルールの1行サマリーと参照先だけを書き、詳細はそれぞれのルールファイルに委ねます。

このプロジェクトでは shared/rules/ に次のルールファイルが置かれています。

ファイル	内容
build-and-deploy.md	npm run build は本番デプロイを発火するため、承認後のみ実行可
content-i18n.md	日本語が source of truth、英語の一人称は I を使う
folder-safety.md	保護フォルダ（src/, scripts/ 等）の一覧と変更禁止ルール
no-ui-regression.md	UI・ナビゲーション変更の禁止
security.md	secrets・XSS・injection リスクの禁止
spec-first.md	仕様を確認してから実装するルール

ルールファイルの基本構造

実際の shared/rules/build-and-deploy.md を例に、ルールファイルの構造を確認します。

# Build and Deploy Rule

`npm run dev` is the normal local preview command.

`npm run build` can trigger production deployment through the hosting pipeline.
Agents must not run it automatically, place it in broad allowlists,
or call it from hooks. Run it only after explicit user approval for that specific build.

Allowed default checks:

- `npm run dev` for local preview
- targeted scripts such as `node scripts/ensure-slugs.js`, `npm run verify-links`,
  and harness validation
- Git inspection commands

Disallowed without approval:

- `npm run build`
- `npm run build:ci`
- chained commands that include `npm run build`
- automatic hooks that call production build commands

構造の要点は次のとおりです。

1. 見出しでルール名を明示する — # Build and Deploy Rule
2. なぜこのルールが存在するかを最初に書く — 「本番デプロイを発火させるため」という理由
3. 許可される操作と禁止される操作を分けて列挙する — Allowed と Disallowed のセクション

CLAUDE.md からの参照方法

CLAUDE.md の ## Non-Negotiable Rules セクションでは、各ルールを1行で要約し、詳細ファイルへの参照を添えます。

## Non-Negotiable Rules

1. `npm run build` は本番デプロイを発火し得るため、ユーザーの明示承認なしに実行しない。
   詳細: `shared/rules/build-and-deploy.md`
2. 仕様を確認してから実装する。詳細: `shared/rules/spec-first.md`

Claude はセッション開始時に CLAUDE.md を読み込み、参照先のルールファイルも確認します。詳細をルールファイルに分けることで、CLAUDE.md を短く保ちながら、ルール全体の説明は各ファイルで完結させられます。

---

ベストプラクティス

1ファイル1懸念で分割する

すべてのルールを1つのファイルにまとめると、特定のルールを更新したり参照したりするのが難しくなります。「デプロイ安全」「コンテンツ品質」「セキュリティ」のように懸念の種類ごとにファイルを分けます。

shared/rules/
├── build-and-deploy.md   ← デプロイ安全
├── content-i18n.md       ← 言語・翻訳
├── folder-safety.md      ← ファイル保護
├── no-ui-regression.md   ← UI 変更禁止
├── security.md           ← セキュリティ
└── spec-first.md         ← 仕様先行

禁止より許可で書く

「〜するな」という禁止形よりも「〜する場合は承認が必要」という条件形で書くと、Claude が例外的な状況を正しく判断しやすくなります。

// 避けるべき書き方
- Do not run npm run build.

// 推奨する書き方
Disallowed without approval:
- npm run build

Why（理由）を必ず書く

理由のないルールは、Claude が例外を自己判断するリスクを高めます。「なぜこのルールが存在するか」を1〜2文で記述します。

// 理由なし（避ける）
# No Force Push Rule
Force push to main is prohibited.

// 理由あり（推奨）
# No Force Push Rule
Force push rewrites commit history and can cause data loss for collaborators.
It is prohibited without explicit approval.

CLAUDE.md にはサマリーと参照先だけを置く

詳細はルールファイルに委ね、CLAUDE.md には要点の1行と参照先だけを書きます。CLAUDE.md が長くなるほど Claude が読み込むコンテキストが増え、パフォーマンスに影響します。

---

実践演習

Step 1: 既存ルールファイルの構造を確認する

次のコマンドで build-and-deploy.md の内容を確認します。

cat shared/rules/build-and-deploy.md

「Allowed default checks」と「Disallowed without approval」の2セクション構造を確認します。

✅ 確認: ルールの「Why（理由）」が冒頭に書かれていることを確認します。

---

Step 2: 新しいルールファイルを作成する

shared/rules/no-force-push.md を作成します。

# No Force Push Rule

Force push rewrites commit history and can cause data loss for collaborators.
It is prohibited without explicit approval.

Disallowed without approval:

- git push --force
- git push -f
- git push --force-with-lease (to main/master)

Allowed:

- git push --force-with-lease to feature branches (not main/master)
- discussing force push options with the user before executing

✅ 確認: ファイルが shared/rules/no-force-push.md として保存されていることを確認します。

---

Step 3: CLAUDE.md の Non-Negotiable Rules セクションを更新する

CLAUDE.md の ## Non-Negotiable Rules セクションに新しいルールの1行サマリーと参照先を追加します。

既存の Non-Negotiable Rules セクションの末尾に次の行を追加します。

7. main / master ブランチへの force push は禁止。詳細: `shared/rules/no-force-push.md`

✅ 確認: CLAUDE.md の Non-Negotiable Rules セクションに番号付きで追記されていることを確認します。

---

Step 4: ルールが効いていることを確認する

Claude Code セッションを再起動し、次のようにリクエストしてみます。

main ブランチに force push してください。

Claude が shared/rules/no-force-push.md を読み込んでいれば、force push を実行せずにルールの存在と理由を説明するはずです。

✅ 確認: Claude が force push をブロックし、no-force-push.md のルールを引用して説明することを確認します。

---

まとめ

このページで学んだ内容を整理します。

• shared/rules/*.md に懸念ごとにルールを分割管理することで、CLAUDE.md を短く保てる
• ルールファイルには「理由 → 許可リスト → 禁止リスト」の構造で書く
• CLAUDE.md には1行サマリーと参照先だけを置き、詳細はルールファイルに委ねる
• 禁止形よりも「承認が必要」という条件形で書くと Claude が例外を判断しやすい

次のステップ

• Settings JSON 設計 — permissions と env で Claude の動作範囲を制御する方法
• CLAUDE.md 設計 — メモリとコンテキスト設計を深掘りする

---

よくある質問

Q: ルールファイルは英語で書くべきですか、日本語で書くべきですか？

A: このプロジェクトでは日本語が source of truth ですが、shared/rules/ のルールファイルは Claude が直接読み込むため、Claude が確実に理解できる英語で書かれています。Claude への指示文書は英語、人間向けのドキュメントは日本語、という使い分けが一般的です。

Q: CLAUDE.md に直接ルールを書いてはいけませんか？

A: 問題はありませんが、ルール数が増えると CLAUDE.md が長くなりすぎて管理しにくくなります。3〜4 個以上のルールが増えてきたらファイル分割を検討します。

Q: ルールファイルを変更したらすぐに Claude に反映されますか？

A: Claude Code はセッション開始時に CLAUDE.md を読み込み、参照先のルールファイルも確認します。変更を反映させるには Claude Code のセッションを再起動します。

Q: deny ではなく rules ファイルで禁止すると何が違いますか？

A: settings.json の deny はツールレベルでのブロックで、コマンドを物理的に実行させません。ルールファイルはあくまで Claude への指示であり、Claude が理解・判断した上で従います。重要な禁止事項は deny と rules ファイルの両方に記載することを推奨します。