Claude CodeのCLAUDE.mdとSkillsは何が違うか?使い分けと書き方を解説
Claude Codeを使い込んでいくと、ほぼ全員が同じ壁にぶつかります。「毎回同じ説明をするのが面倒だからCLAUDE.mdに書き足していったら、ファイルがどんどん長くなった。最近はSkills(スキル)という仕組みもあるらしいけれど、結局どちらに何を書けばいいのか分からない」という悩みです。
どちらもClaudeへの指示を書いておくMarkdownファイルなので、見た目はよく似ています。ところが、Claudeが中身を読み込むタイミングがまったく違うため、書き分けを間違えると「指示を守ってくれない」「トークンを無駄に消費する」「必要な手順が呼び出されない」といった問題が起きます。
この記事では、2026年10月時点のClaude Code公式ドキュメント(メモリ)と公式ドキュメント(Skills)をもとに、CLAUDE.mdとSkillsの違い、どちらに何を書くべきかの判断基準、CLAUDE.mdからSkillを切り出す具体的な手順を整理します。実例として、当ブログの記事作成ルールを書いた329行のCLAUDE.mdをどう分ければいいかも紹介します。



結論:毎回守らせるならCLAUDE.md、ときどき使う手順ならSkills
違いは「読み込まれるタイミング」の一点に集約される
最初に結論です。Claudeが毎回のセッションで必ず知っておくべき「事実」や「ルール」はCLAUDE.mdに書きます。一方で、特定の作業をするときだけ必要な「手順」や「参考資料」はSkillsに分けます。
この使い分けが生まれる理由は、読み込みのタイミングの違いです。公式ドキュメントでは、CLAUDE.mdはセッション開始時に全文が読み込まれ、その後のすべてのリクエストに含まれ続けると説明されています。これに対してSkillsは、名前と説明文(description)だけが常に読み込まれ、本文は使われるときに初めて読み込まれる仕組みです。公式ドキュメントにも、CLAUDE.mdと違ってスキル本文は使われたときにだけ読み込まれるため、長い参考資料も必要になるまでほとんどコストがかからない、という趣旨の記述があります(参考:Extend Claude with skills)。
一目で分かる比較表
公式の機能比較ページの内容を、実務で迷いやすい観点に絞って表にまとめました。
| 観点 | CLAUDE.md | Skills |
|---|---|---|
| 読み込まれるタイミング | セッション開始時に毎回全文 | 説明文は常時、本文は使うときだけ |
| コンテキスト消費 | 毎リクエストで全文ぶん消費 | 普段は説明文ぶんだけ(低い) |
| 呼び出し方 | 呼び出し不要(常に有効) | Claudeが自動で判断、または/スキル名で手動 |
| 向いている内容 | ビルドコマンド、命名規則、「必ず〇〇する」ルール | 手順書、チェックリスト、長い参考資料 |
| 置き場所(例) | ./CLAUDE.md、~/.claude/CLAUDE.md |
.claude/skills/名前/SKILL.md |
「どっちに書いても動く」が一番の落とし穴
厄介なのは、どちらに書いても一応は動いてしまうことです。手順書をCLAUDE.mdに書いてもClaudeは読みますし、ルールをSkillに書いても呼び出されれば守ります。だからこそ「なんとなく全部CLAUDE.md」に流れがちです。しかし、その積み重ねがファイルの肥大化を招き、後述するように指示の遵守率そのものを下げてしまいます。使い分けは「動くかどうか」ではなく、「毎回必要かどうか」で判断するのが正解です。

なぜ使い分けが必要なのか:仕組みから理解する
CLAUDE.mdは毎回全文がコンテキストに入る
Claude Codeの各セッションは、まっさらなコンテキストウィンドウ(AIが一度に参照できる情報の枠)から始まります。CLAUDE.mdは、この枠にセッション開始時から全文が入り、会話が続く間ずっと残ります。
つまり、CLAUDE.mdに500行の手順書を書くと、その手順を使わない日でも、毎回のやり取りで500行ぶんのトークンを消費し続けることになります。公式ドキュメントはCLAUDE.mdを1ファイルあたり200行未満に収めることを推奨しており、長いファイルほどコンテキストを消費し、指示の遵守率も下がると明記しています(参考:How Claude remembers your project)。
なお、@パス形式で別ファイルを読み込む「インポート」機能を使っても、インポートされたファイルも起動時に読み込まれるため、整理にはなってもコンテキストの節約にはならない点に注意してください。
Skillsは説明文だけが常駐し、本文は必要なときに読まれる
Skillsは「段階的な読み込み」をする仕組みです。セッション中、Claudeが常に見ているのは各スキルの名前と説明文(description)だけです。ユーザーの依頼内容が説明文とマッチしたとき、またはユーザーが/スキル名と入力したときに、はじめて本文(SKILL.md)が読み込まれます。さらに、SKILL.mdから参照している補助ファイル(詳細なリファレンスや例文集など)は、Claudeが実際にそれを開いたときにだけ読み込まれます。
このため、数千行の参考資料をスキルにしても、使わない限りほとんどコストがかからないのが最大の利点です。
どちらも「お願い」であって強制ではない
誤解しやすいポイントとして、CLAUDE.mdもSkillsもClaudeが読んで従おうとする「指示」であり、システムとして強制される設定ではありません。公式ドキュメントも、CLAUDE.mdの内容はシステムプロンプトの後にユーザーメッセージとして渡されるもので、厳密な遵守は保証されないと説明しています。
「.envファイルは絶対に編集しない」のように、必ず守らせたいルールはHooks(フック)で機械的にブロックするのが公式の推奨です。CLAUDE.mdは「行動の方針」、Hooksは「強制力のあるガードレール」と考えると整理しやすくなります。

まず確認すること:今のCLAUDE.mdの状態をチェック
/contextで実際に読み込まれているファイルを確認する
使い分けを考える前に、今どのファイルが読み込まれているかを確認しましょう。Claude Codeのセッション内で/contextを実行すると、「Memory files」の欄に読み込まれているCLAUDE.mdやルールファイルの一覧が表示されます。/memoryでは、ユーザー用・プロジェクト用のCLAUDE.mdを一覧から開いて編集できます。
CLAUDE.mdは置き場所によって適用範囲が変わります。主な置き場所は次の3つです。
~/.claude/CLAUDE.md:自分のPC上のすべてのプロジェクトに適用(個人の好み)./CLAUDE.mdまたは./.claude/CLAUDE.md:そのプロジェクトに適用(Gitで共有してチームでも使う)./CLAUDE.local.md:そのプロジェクトで自分だけに適用(.gitignoreに追加して共有しない)
これらは上書きではなくすべて連結されて読み込まれます。複数のファイルで矛盾する指示があると、Claudeがどちらか一方を任意に選ぶことがあるため注意が必要です。
200行を超えていないか数える
次に行数を確認します。ターミナルでwc -l CLAUDE.mdと打てば一発で分かります。200行を超えていたら、何かをSkillsや後述のrulesに移すサインです。
実例を出します。当ブログの記事作成ルールを書いたCLAUDE.mdは、確認したところ329行・約16,000文字ありました。公式推奨の1.6倍以上です。このファイルには「ブログの運用方針」と「記事作成の6ステップ」と「見出しや吹き出しのHTMLコード」がすべて同居していました。
中身を「事実」と「手順」に仕分ける
行数が多いときは、各セクションを次の2種類に仕分けます。
- 事実・ルール:「パッケージ管理はpnpmを使う」「テストは
npm testで実行」「APIの処理はsrc/api/に置く」など、どの作業でも前提になる情報 - 手順・資料:「デプロイ時はこの順番で確認する」「記事を書くときは6ステップで進める」など、特定の作業のときだけ使う情報
公式ドキュメントも、CLAUDE.mdに書くべきなのは毎セッション必要な事実であり、複数ステップの手順やコードベースの一部にしか関係しない内容はスキルかパス指定ルールに移すべきとしています。



ケース別の答え:その内容はどちらに書くべきか
CLAUDE.mdに書くべきもの
公式ドキュメントが挙げる「CLAUDE.mdに追記すべきタイミング」は次のとおりです。
- Claudeが同じミスを2回した
- コードレビューで「このプロジェクトなら知っておくべきこと」を指摘された
- 前回のセッションと同じ訂正をチャットで打ち込んでいる
- 新しくチームに入った人にも同じ説明が必要になる
具体的には、ビルド・テストのコマンド、命名規則、フォルダ構成の要点、「必ず〇〇する」「〇〇は絶対しない」という短いルールです。書くときは「コードをきれいに整形する」のような曖昧な表現ではなく、「インデントはスペース2つ」のように確認できるレベルまで具体的に書くことが遵守率を上げるコツです。
Skillsにすべきもの
公式の機能比較ページでは、次のような場面でスキル化を勧めています。
- タスクを始めるときに毎回同じプロンプトを打っている
- 同じ手順書やチェックリストを3回以上チャットに貼り付けている
- CLAUDE.mdの一部が「事実」ではなく「手順」に育ってしまった
- API仕様書や文体ガイドなど、ときどき参照する長い資料がある
Skillsには大きく2種類あります。文体ガイドのように知識として参照される「リファレンス型」と、/deployのように特定の作業を実行させる「アクション型」です。どちらも「毎回は要らないが、必要なときには確実に使いたい」内容である点が共通しています。
どちらでもないもの:rules・Hooks・サブエージェント
実は、CLAUDE.mdとSkillsの二択で考えないほうがよいケースもあります。
| やりたいこと | 使うべき仕組み |
|---|---|
| 特定の言語・フォルダだけに適用するルール | .claude/rules/(paths指定で該当ファイルを扱うときだけ読み込み) |
| 毎回必ず実行したい処理(編集後のLint等) | Hooks |
| 大量のファイルを読む調査を本会話から切り離したい | サブエージェント |
| 外部サービス(Slack、DB等)につなぎたい | MCP |
たとえば「TypeScriptのファイルを触るときだけ守ってほしい規約」は、Skillsよりもpaths指定付きのrulesのほうが確実です。rulesは該当ファイルを読んだタイミングで自動的に読み込まれるため、Claudeの判断に頼らずに済みます。

解決手順:CLAUDE.mdの手順部分をSkillに切り出す
Step1:スキル用のフォルダを作る
スキルは「フォルダ1つ=スキル1つ」で管理します。置き場所によって使える範囲が変わります。
- 個人用:
~/.claude/skills/スキル名/SKILL.md(自分のPCの全プロジェクトで使える) - プロジェクト用:
.claude/skills/スキル名/SKILL.md(そのリポジトリでのみ使える。Gitで共有可能)
ターミナルで次のように作成します。
mkdir -p .claude/skills/write-article
Step2:SKILL.mdを書く(description が最重要)
SKILL.mdは、先頭にYAML形式のフロントマター(---で囲んだ設定欄)を置き、その下に指示本文を書きます。当ブログのCLAUDE.mdから「記事作成の手順」部分を切り出すなら、次のようになります。
---
name: write-article
description: ブログ記事を作成・投稿するときの手順。記事を書いて、記事を作って、新しい記事を投稿して、と頼まれたときに使う。
---
# 記事作成の手順
1. 想定読者・読了後のゴール・トーンを定義する
2. 公式情報を優先してリサーチし、参照URLを記録する
3. H2/H3の構成案を先に作る
4. 6,000字以上で本文を書く(見出しは reference/blocks.md のHTMLを使う)
5. セルフレビューして修正する
6. 表記揺れ・リンク切れを確認して投稿する
ポイントはdescriptionの書き方です。Claudeはこの説明文と依頼内容を照らし合わせて、スキルを使うかどうかを判断します。公式ドキュメントは「ユーザーが自然に口にするキーワードを含めること」「主な用途を先頭に書くこと」を推奨しています。なお、説明文(when_to_useと合わせて)は1スキルあたり1,536文字が上限です。
見出しや吹き出しのHTMLコードのような長い資料は、reference/blocks.mdのような補助ファイルに分け、SKILL.mdから参照しておくと、必要なときだけ読み込まれます。一方、「1記事1テーマ」「煽らない」といった運用方針はCLAUDE.mdに残します。記事を書く以外の作業(タイトル修正やリライト)でも守ってほしいルールだからです。
Step3:呼び出して動作を確認する
保存したら、Claude Codeを再起動しなくても反映されます。公式ドキュメントによると、Claude Codeはスキルのフォルダを監視しており、追加・編集・削除はセッション中に自動で反映されます(ただし、セッション開始時に存在しなかった最上位のスキルフォルダを新しく作った場合は/reload-skillsが必要です)。
確認方法は2つあります。
- 自動で呼ばれるか:「新しい記事を書いて」と自然に頼んでみて、スキルが使われるかを見る
- 手動で呼べるか:
/write-articleと入力して直接呼び出す
最後に、CLAUDE.mdから移した部分を削除し、/contextでMemory filesのサイズが減ったことを確認すれば完了です。セッションが長くなったときのコンテキスト整理については、Claude Codeの/clearと/compactの違いを解説した記事も参考にしてください。

うまくいかない場合の対処法
スキルが自動で呼び出されない
最も多いトラブルです。公式ドキュメントのトラブルシューティングでは、次の順で確認するよう案内しています。
- descriptionに、ユーザーが自然に使う言葉が入っているか
- 「What skills are available?(使えるスキルは?)」と聞いて一覧に出てくるか
- 依頼の言い回しをdescriptionに近づけると呼ばれるか
/スキル名で直接呼べるか- フロントマターのYAMLの書式が壊れていないか
日本語で依頼する場合、descriptionも日本語の言い回しを含めておくと一致しやすくなります。英語のdescriptionだけだと、日本語の依頼とうまく結びつかないことがあります。
また、スキルを大量に入れていると、一覧の文字数予算(初期設定ではコンテキストウィンドウの1%)を超え、使用頻度の低いスキルから説明文が省略される仕様があります。スキルが増えすぎていないかも確認しましょう。
スキルが呼ばれすぎる・勝手に実行されて困る
逆に、関係ない場面でスキルが使われる場合は、descriptionを具体的にして範囲を絞ります。それでも困る場合や、デプロイや投稿のように実行すると取り消せない作業を含むスキルは、フロントマターにdisable-model-invocation: trueを追加しましょう。これでClaudeが自動で呼び出すことはなくなり、/スキル名で自分が呼んだときだけ動くようになります。公式ドキュメントも、副作用のあるスキルにはこの設定を推奨しています。
CLAUDE.mdに書いた指示を守ってくれない
Skillsに移したのにCLAUDE.mdの指示が守られない場合は、次を疑ってください。
- 読み込まれていない:
/contextのMemory filesに表示されているか確認する - 指示が曖昧:「きれいに書く」ではなく「1文は60字以内」のように確認可能な表現にする
- 矛盾がある:ユーザー用・プロジェクト用・サブフォルダのCLAUDE.mdで食い違いがないか見直す
- そもそも強制すべきルール:毎回必ず守らせたいならHooksに移す



よくある質問
Q. .claude/commands/ に置いたカスタムコマンドとは何が違う?
現在、カスタムコマンドはSkillsに統合されています。公式ドキュメントによると、.claude/commands/deploy.mdと.claude/skills/deploy/SKILL.mdはどちらも/deployを作り、同じように動作します。既存のcommandsファイルはそのまま使えますが、Skillsには「補助ファイルを置けるフォルダ構成」「自動で呼び出すかどうかの制御」「Claudeによる自動呼び出し」が追加されています。新しく作るならSkillsで作るのがおすすめです。
Q. サブエージェントとSkillsはどう使い分ける?
Skillsは「Claudeに読ませる指示や知識」、サブエージェントは「別のコンテキストで作業させる担当者」です。スキルの内容はメインの会話に読み込まれますが、サブエージェントは独立したコンテキストで作業し、要約だけを返します。大量のファイルを読む調査のように、途中経過で会話を埋めたくない作業にはサブエージェントが向いています。なお、フロントマターにcontext: forkを指定すると、スキルを独立したコンテキストで実行することもできます。
Q. Skillsは他のAIツールやclaude.aiでも使える?
Claude CodeのSkillsはAgent Skillsというオープンな標準に沿っており、対応する他のAIツールでも同じ形式が使えます。Claude Codeはこの標準に、呼び出し制御やサブエージェント実行などの独自機能を追加しています。また、claude.aiのアカウントで管理しているスキルは、claude.aiアカウントでログインしたClaude Codeのセッションなどに同期されます。ただし、手元の~/.claude/skills/に置いた個人スキルは、クラウド上のセッションでは読み込まれない点に注意してください。
Claude Codeの基本的な使い方から確認したい方は、Claude Code(CLI)使い方完全ガイドもあわせてご覧ください。

まとめ:こういう人はこう選べばいい
CLAUDE.mdとSkillsの違いは、突き詰めると「毎回読まれるか、必要なときだけ読まれるか」の一点です。この違いを押さえておけば、どちらに書くべきか迷うことはなくなります。最後に、状況別の選び方を整理します。
- Claude Codeを使い始めたばかりの人:まずはCLAUDE.mdだけで十分です。
/initで土台を作り、Claudeが同じミスを2回したらルールを1行追記する運用から始めましょう。 - CLAUDE.mdが200行を超えてきた人:中身を「事実」と「手順」に仕分け、手順部分をSkillsに切り出すタイミングです。特定の言語・フォルダ向けのルールは
.claude/rules/に移します。 - 同じプロンプトを何度も貼り付けている人:それはスキル化の合図です。descriptionに「どんな依頼のときに使うか」を日本語で具体的に書きましょう。
- 投稿・デプロイなど取り消せない作業を自動化したい人:Skillsに
disable-model-invocation: trueを付け、自分で/スキル名を打ったときだけ動くようにします。 - 絶対に守らせたいルールがある人:CLAUDE.mdやSkillsではなくHooksで機械的に制御します。
大切なのは、最初から完璧な構成を作ろうとしないことです。公式ドキュメントも「最初からすべてを設定する必要はなく、きっかけが生まれたときに順番に追加すればよい」という考え方を示しています。CLAUDE.mdは短く保ち、繰り返し使う手順だけをSkillsに育てていく。この運用を続けるだけで、トークンの無駄遣いが減り、Claudeが指示を守る精度も上がっていきます。
参考:How Claude remembers your project(Claude Code Docs)/Extend Claude with skills(Claude Code Docs)/Extend Claude Code(Claude Code Docs)
