Claude Code の rules/ と skills/ の境界線をどう引くか — 『常時ルール』と『手順書』を分ける判断基準

Claude Code の運用に慣れてくると、.claude/ 配下に置くファイルが増えます。

.claude/
├── CLAUDE.md
├── rules/
│   ├── commit.md
│   ├── security.md
│   └── ...
└── skills/
    ├── post-article/
    ├── collect-metrics/
    └── ...

3層に分けるパターン自体は知られていますが、実運用で詰まるのは 「これは rules/ に書くべき？ skills/ にすべき？」 という境界の判断です。

筆者は CLAUDE.md / rules / skills の3層を実運用で半年回した結果、「迷ったらこの基準で判断する」というルールに落ち着きました。本記事はその判断基準と、境界を間違えて起きた失敗例を共有します。

結論：境界は「常時参照されるか」で引く

最初に結論を言うと、判断基準は1つで足ります。

項目	配置先
すべての作業で守ってほしい こと	rules/（または CLAUDE.md 本体）
特定の作業のときだけ実行する 手順	skills/

「常時ルール」か「呼び出し手順」かで分ける。これだけです。

ただし、Claude Code は rules/ も skills/ も自動読み込みしない （@rules/foo.md でCLAUDE.md から参照する or skills の description にマッチして呼ばれる）。なので、「常時参照される」という言葉の意味は、CLAUDE.md からの参照経路をどう作るかと同じ意味です。

rules/ に置くべきもの

筆者の現場では、以下を rules/ に置いています。

1. 「絶対やらないこと」リスト

# rules/no-mock-db.md

## ルール
統合テストでデータベースをモックしない。

## Why
2025年Q4に、モックDBで通っていたテストが本番マイグレーションで失敗。
モック/プロダクション差異が原因。

## How
Supabase ローカルインスタンスを使う。`pnpm db:test:reset` でリセット可能。

特徴：

• 守らないと事故になる、過去のインシデントが背景にあるルール
• 状況を選ばず常に守ってほしい
• AIが「これはやっていいかな？」と迷うポイント

2. プロジェクト全体の規約

• コミットメッセージのフォーマット
• ブランチ命名規則
• ディレクトリ構造の原則

3. セキュリティ・コンプライアンス系

• .env を絶対に commit しない
• console.log で個人情報を出力しない
• 外部API呼び出しのレート制限

skills/ に置くべきもの

一方、skills/ には「特定作業の手順」を置きます。

1. 定型作業の手順書

# skills/post-article/skill.md
---
description: ブログ記事をMarkdownで生成し、note APIで投稿する
---

## 手順

1. トレンドを `collect-trends` skill で収集
2. 過去投稿との重複を確認
3. Markdown生成 → HTML変換
4. note 内部APIに POST
5. 投稿履歴を更新

2. 複数ファイル横断の作業フロー

例：「メトリクス収集」は MENTAダッシュボード + GitHub API + ファイル更新の3つにまたがる。これを skill にまとめると、ステップ漏れがなくなります。

3. 専門知識を要する作業

例：「Stripe Webhook の整合性チェック手順」「OAuth トークンリフレッシュの実装パターン」など、毎回ドキュメントを引きながら進める作業。

境界を間違えると何が起きるか

失敗例1: ルールを skills/ に書いた

「テストでDBをモックしない」というルールを、最初 skills/run-tests/skill.md の冒頭に書いていました。

問題は、この skill が呼ばれない作業（例：新しい機能を追加するとき）では、ルールが読まれないことです。

その結果、「機能追加 → テスト追加（このときDBをモックしてしまう）→ run-tests skill が後から走るときには既に書かれている」 という事故が起きました。

→ 解決：rules/no-mock-db.md に切り出し、CLAUDE.md から @rules/no-mock-db.md で参照。

失敗例2: 手順を rules/ に書いた

逆に「記事投稿の手順」を最初 rules/post-article.md に書いていました。

問題は、CLAUDE.md から常時参照されるため、記事投稿しない日でも200行のドキュメントが Claude のコンテキストに乗る ことです。

CLAUDE.md が肥大化して、本当に守ってほしい他のルールが流し読みされる事象が起きました。

→ 解決：skills/post-article/ に移動。description を書いて、必要時のみ呼ばれる構造に。

判断フローチャート

迷ったときの実用的な判断フローはこうなります。

このファイルは…

├── すべての作業で AI に守ってほしいか？
│   ├── Yes → rules/ （CLAUDE.md から @ で参照）
│   └── No  → 次へ
│
├── 特定のキーワード／作業のときだけ呼びたいか？
│   ├── Yes → skills/（description で自動トリガー）
│   └── No  → 次へ
│
└── プロジェクト全体の前提情報か？
    └── Yes → CLAUDE.md 本体に直書き

実装上のコツ

rules/ は短く・例外なし

rules/ のファイルは1ファイル30行以内を目安にします。

理由は単純で、ルールが長いと AI が要約しながら読み流すから。

「これだけは守って」と決めたものは、ルール → Why（背景）→ How（具体策）の3ブロックに圧縮します。

skills/ は description が命

skills/ の skill.md には frontmatter で description を必ず書きます。

---
description: MENTA返信チェック。/member/message を全ページ巡回し、メンティー一覧を更新する。
---

description のキーワードに引っかかったときだけ skill が呼ばれるので、「いつ呼ばれてほしいか」をdescription に込める のがコツです。

「MENTA」「返信」「メンティー」が入っていれば、ユーザーが「MENTAの返信チェックして」と言ったときに自動で発火します。

CLAUDE.md は「目次」役に徹する

CLAUDE.md 本体には、長い説明を書かないようにします。代わりに、ファイル参照だけ並べます。

## ルール
- @rules/no-mock-db.md
- @rules/security-check.md

## 定型作業
- 記事投稿: skills/post-article/
- メトリクス収集: skills/collect-metrics/

## 環境
- Next.js 15 / TypeScript / Supabase / Vercel
- テストは Vitest

このパターンなら、CLAUDE.md は50行以内に収まります。

まとめ

種類	配置	例	読まれるタイミング
絶対ルール	rules/	DBモック禁止	関連作業時に AI が参照
手順書	skills/	記事投稿手順	description 一致時
全体前提	CLAUDE.md	技術スタック	常時

迷ったら「常時参照されるか」で分ける。これだけで CLAUDE.md の肥大化と skill の取り違えを両方防げます。

---

関連: 教材で手を動かして学ぶ

• まず無料で試したい方: 教材の体験版を GitHub で配布中（git clone してすぐ動かせます） → https://github.com/ayies128/next-ai-camp-trial
• 全20セッション完全版＋メンタリング → https://menta.work/plan/20251
• YouTubeチャンネル → https://www.youtube.com/channel/UC1rXVD9WYsQPQEWZyd-A1KA/