Claudeのルールとスキルの違い｜迷わない設定先と使い分け

Claudeのルールとスキルは何が違う？

違いは、主にいつ、何のために読ませるかです。ルールは作業中に守ってほしい基準、スキルは特定の仕事を進めるための知識や手順をまとめる場所です。

たとえば「APIの入力値を検証する」は実装時の規約です。一方、「変更差分を読み、入力検証の漏れを調べ、結果を報告する」はレビューの手順です。同じ入力検証が題材でも、前者はRules、後者はSkillsに分けると役割が明確になります。

ここで扱う配置はClaude Code用です。Claudeのチャット画面へ同じフォルダを置くだけで設定できる、という意味ではありません。

出典：Claude Code公式・メモリとルール、スキルの概要

CLAUDE.mdには毎回必要な前提を残す

CLAUDE.mdには「このプロジェクトで作業するなら最初に知ってほしいこと」を短く書きます。ルートのCLAUDE.mdまたは.claude/CLAUDE.mdが代表的な配置先です。

# プロジェクトの基本
- 管理画面は src/admin/ にある。
- 変更後は npm test を実行する。
- 仕様が不明な項目は推測で確定せず確認する。

公式は、CLAUDE.mdを200行未満に収めることを目標として示しています。これは「200行を超えると動かない」という形式上の上限ではありません。毎回読み込む内容を絞り、重要な指示を見つけやすくするための目安です。

詳細なレビュー手順や一部のフォルダだけで使う規約まで詰め込んだら、分割を検討します。なお、@pathによる別ファイルの取り込みは整理には役立ちますが、取り込み先も起動時に読み込まれるため、分割だけでコンテキスト消費が減るわけではありません。

出典：公式・CLAUDE.mdの書き方とファイル取り込み

Rulesは対象ファイルに合わせて規約を渡す

Rulesは.claude/rules/に置くMarkdownファイルです。testing.mdやapi-design.mdのように、内容が分かる名前でトピックを分けます。

特定の場所だけに適用したい場合は、冒頭のYAMLにpathsを書きます。次は.claude/rules/api-design.mdの例です。

---
paths:
  - "src/api/**/*.ts"
---

# API実装の規約
- 外部入力は処理前に検証する。
- エラー応答は既存の共通形式にそろえる。
- 挙動を変えた場合は対応するテストを更新する。

このルールは、Claudeが一致するファイルを読み書き・編集するときに読み込まれます。画面側の作業でAPI専用の規約を常に持たせる必要がなくなります。

一方、pathsのないRulesは起動時に読み込まれます。「Rulesに移せば何でも必要時だけになる」と考えず、適用範囲まで設計してください。個人共通のルールには~/.claude/rules/という配置先もありますが、チーム共有の規約はプロジェクト側へ置くと管理しやすくなります。

出典：公式・Rulesの構成とパス指定

Skillsは繰り返す仕事を手順としてまとめる

Skillsは、同じチェックリストや複数工程を毎回チャットへ貼っているときに向いています。プロジェクトで共有する場合は、.claude/skills/<名前>/SKILL.mdへ配置します。

たとえば.claude/skills/review-api/SKILL.mdを次のように書きます。これは説明用の自作例です。

---
name: review-api
description: API変更の差分をレビューする。APIのレビューや入力検証の点検を依頼されたときに使う。
---

# APIレビュー
1. 対象の変更差分を読み、影響するAPIを列挙する。
2. 該当するプロジェクトの規約と照合する。
3. 入力検証・エラー処理・テストの不足を確認する。
4. 指摘箇所と理由を示し、未確認事項を分けて報告する。

Claude Codeで/review-apiと入力すれば、明示的に呼び出せます。説明が依頼内容と合えば、Claudeが関連すると判断して使うこともあります。自動選択を試す場合は「API変更の入力検証を点検して」のように、説明に対応する依頼で確認します。

スキルの本文は使うときに読み込まれるため、長い手順を常時の指示から切り離せます。ただし、説明が曖昧だと選ばれにくくなります。「何をするか」に加え「どんな依頼で使うか」まで書くことが大切です。

出典：公式・スキルの作成、配置、呼び出し

迷ったら「前提・規約・手順」で振り分ける

同じ話題が複数の設定先に関係していても問題はありません。重要なのは、同じ文章を複製せず、それぞれの役割を分けることです。

たとえばレビュー用スキルには「既存のAPI規約と照合する」と書き、エラー形式の細部はRules側で管理します。規約が変わった際に、スキル内のコピーだけ古く残る問題を避けられます。

また、「必ず守る内容だからスキルに書けばよい」とは限りません。呼び出されない仕事の本文は読み込まれないため、毎回必要な前提をスキルだけに置くと抜ける可能性があります。

この振り分けは、公式の読み込み仕様を実務向けに整理した判断例です。

出典：公式・RulesとSkillsの使い分け

既存の指示を整理する5つの手順

最初から設定一式を作り直す必要はありません。繰り返している指示から、小さく移して確認すると進めやすくなります。

1. CLAUDE.mdと普段の依頼文を読み、重複する注意や長い手順を抜き出します。
2. 各項目を「全体の前提」「領域の規約」「特定の仕事」に分類します。
3. 領域の規約をRulesへ移し、必要ならpathsで対象を限定します。
4. 特定の仕事を一つだけSKILL.mdにまとめ、説明と順序付きの工程を書きます。
5. 新しいセッションで呼び出しと成果物を確認してから、元の重複部分を整理します。

確認では、APIを編集するケースと無関係な文書を編集するケースを分けると、パス指定の範囲を判断しやすくなります。スキルも、明示呼び出しと自然文による依頼を分けて試します。

期待どおりの回答が出たかだけでなく、対象ファイル、実行した確認、残った未確認事項まで見ます。テストした例で成功しても、あらゆる依頼で同じ挙動になるとは限らないためです。

出典：公式・指示ファイルの読み込み、スキルを試す方法

効かないときは配置・条件・矛盾を確認する

ルールが効かない場合は、まずファイルの配置とpathsの一致を確認します。スキルが出てこない場合は、SKILL.mdのファイル名、配置先、説明、呼び出し名を点検します。

続いて、CLAUDE.mdとRulesとSkillsに相反する内容がないかを調べます。「必ずテストする」と「テストを省略する」が別々のファイルに残っていても、細かく分けたことで解決するわけではありません。古い指示を削除するか、適用条件を明確にします。

公式が説明するように、CLAUDE.mdやRulesは文脈として渡す指示です。記載だけで操作を必ず阻止する仕組みではありません。特定の操作を判断に関係なく止める必要がある場合は、公式が案内するPreToolUseフックなど、実行を制御する仕組みも検討します。

ルールとスキルを増やす前に、毎回必要な基準と、必要時だけ使う仕事を分ける。この整理から始めると、どのファイルを直せば挙動を改善できるか追いやすくなります。

出典：公式・指示が守られないときの確認と制御の考え方