Claude CodeのCLAUDE.md・Skills・MCPの違いと使い分けガイド

TL;DR

Claude Codeの拡張機構にはCLAUDE.md、Skills（Commands統合済み）、MCPの3つがある。CLAUDE.mdは全セッションで常時読み込まれる基盤層で、コーディング規約やビルドコマンドを書く場所。Skillsはオンデマンドで読み込まれる手順・知識層で、自動検出や支援ファイルに対応する。MCPは外部サービスとの接続プロトコルだ。CLAUDE.mdは「憲法」、Skillsは「手順書・専門知識」、MCPは「手足」と捉えるとわかりやすい。

拡張機構の全体像

Claude Codeを使い込んでいくと、CLAUDE.md、.claude/skills/、MCP serverという3つの拡張ポイントに出会う（.claude/commands/はSkillsに統合済み）。それぞれの役割は異なるが、重なる部分もあり、初見では混乱しやすい。

まず全体像を図で示す。

graph LR
    A["ユーザーの指示"] --> B["Claude Code CLI"]
    B --> C["CLAUDE.md / rules"]
    B --> D["Skills / Commands"]
    B --> E["MCP Servers"]
    C -->|"常時読み込み"| F["規約 / 設定 / 知識"]
    D -->|"オンデマンド"| G["templates / reference.md"]
    E -->|"通信"| H["Figma / GitHub / DB等"]

層構造で捉えると、CLAUDE.md（基盤知識層）→ Skills/Commands（手順・タスク層）→ MCP（外部接続層）という関係になる。

CLAUDE.md：常時読み込みの基盤層

CLAUDE.mdはClaude Codeの最も基本的な拡張だ。セッション開始時に自動で読み込まれ、全ての作業に適用される。プロジェクトの「憲法」に相当する。

何を書くべきか：

  • コーディング規約（インデント、命名規則）
  • よく使うコマンド（ビルド、テスト、リント）
  • プロジェクトのアーキテクチャ概要
  • 使用技術やフレームワークの注意点

スコープの階層

公式ドキュメントによると、CLAUDE.mdには複数のスコープがある。

スコープ設定場所共有範囲
Managed policy/Library/Application Support/ClaudeCode/CLAUDE.md 等組織全体
Project./CLAUDE.md or ./.claude/CLAUDE.mdGitでチーム共有
Project rules./.claude/rules/*.mdGitでチーム共有
User~/.claude/CLAUDE.md個人の全プロジェクト
Local./CLAUDE.local.md個人（.gitignore自動追加）

より具体的なスコープの指示が優先される。例えばProject rulesの指示はUser memoryの指示より優先される。

.claude/rules/ によるモジュール化

CLAUDE.mdが大きくなったら、.claude/rules/でトピック別に分割できる。

.claude/
├── CLAUDE.md           # メインの指示
└── rules/
    ├── code-style.md   # コーディング規約
    ├── testing.md      # テスト規約
    └── security.md     # セキュリティ要件

pathsフロントマターで特定ファイルにのみ適用するルールも書ける。

---
paths:
  - "src/api/**/*.ts"
---
# API開発ルール
- RESTful命名規則に従う
- 統一エラーフォーマットを使う

CLAUDE.mdとSkills（知識型）の境界

ここが混乱しやすいポイントだ。どちらも「Claudeに知識を与える」という点では同じだが、判断基準は明確にある。

  • CLAUDE.md = 全セッション・全作業で常に適用したいルール。「このプロジェクトではpnpmを使う」「テストはvitest」など。
  • Skill（知識型） = 特定の作業文脈でのみ必要な知識。「Figmaデザインの実装手順」「記事執筆のスタイルガイド」など。

常に読み込まれるCLAUDE.mdにあらゆる知識を詰め込むと、コンテキストを無駄に消費する。特定の場面でしか使わない知識はSkillに分離すべきだ。

Commands：最もシンプルな拡張

Commandsは.claude/commands/にMarkdownファイルを置くだけで使える、最も手軽な拡張だ。

.claude/commands/
├── deploy.md
├── review.md
└── fix-issue.md

/deployのように手動で呼び出す。引数も$ARGUMENTSで受け取れる。

# .claude/commands/fix-issue.md
Fix GitHub issue $ARGUMENTS following our coding standards.
1. Read the issue description
2. Implement the fix
3. Write tests
4. Create a commit

これだけだ。シンプルで、単発の定型作業には十分に機能する。

Skills：Commandsの上位互換

公式ドキュメントには以下のように明記されている。

Custom slash commands have been merged into skills. A file at .claude/commands/review.md and a skill at .claude/skills/review/SKILL.md both create /review and work the same way. Your existing .claude/commands/ files keep working.

つまりCommandsは廃止されていないが、機能的にSkillsに統合された。Skillsが持つCommandsにない機能は以下の通り。

機能CommandsSkills
手動呼び出し (/name)oo
Claudeによる自動検出・呼び出しxo
支援ファイル (templates, examples等)xo
サブエージェント実行 (context: fork)xo
動的コンテキスト注入 (!`command`)xo
呼び出し制御 (disable-model-invocation)xo

特に重要なのは自動検出だ。Commandsはユーザーが/nameで明示的に呼び出す必要があるが、Skillsはdescriptionフィールドに基づいてClaudeが「この場面ではこのSkillを使うべきだ」と自動判断できる。

Skillのディレクトリ構造

.claude/skills/
└── my-skill/
    ├── SKILL.md           # メインの指示（必須）
    ├── reference.md       # 詳細なリファレンス
    ├── templates/          # テンプレート集
    │   └── template.md
    └── scripts/
        └── validate.sh    # 実行可能なスクリプト

SKILL.mdの基本形

---
name: api-conventions
description: API design patterns for this codebase
---

When writing API endpoints:
- Use RESTful naming conventions
- Return consistent error formats
- Include request validation

descriptionがClaudeの自動判定のトリガーになる。ここに適切なキーワードを含めることで、ユーザーが明示的に呼び出さなくてもClaudeが必要な場面で読み込んでくれる。

Skillの2つの使い方

Skillの中身は大きく2種類に分かれる。

1. 知識・ガイドライン型 — Claudeが作業中に参照するドメイン知識。

---
name: api-conventions
description: API design patterns for this codebase
---
# APIの設計規約をここに書く

2. タスク実行型 — 特定のアクションを実行する手順書。

---
name: deploy
description: Deploy the application to production
context: fork
disable-model-invocation: true
---
# デプロイ手順をここに書く

disable-model-invocation: trueを設定すると、Claudeが自動で呼び出すことを防げる。デプロイのように副作用のある操作には必須の設定だ。

MCP：外部サービスとの接続

MCPはSkillsとは根本的に異なる。Skillsが「Claudeに何を知っていてほしいか、何をしてほしいか」を定義するのに対し、MCPは「Claudeがどの外部サービスと通信できるか」を定義する。

sequenceDiagram
    participant U as ユーザー
    participant C as Claude Code
    participant M as MCP Server
    participant E as 外部サービス

    U->>C: "FigmaのデザインをReactで実装して"
    C->>C: Skill読み込み (implement-design)
    C->>M: MCP Tool呼び出し (get_design_context)
    M->>E: Figma API
    E-->>M: デザインデータ
    M-->>C: コード + スクリーンショット
    C->>U: Reactコンポーネント生成

この図がSkillsとMCPの関係を端的に表している。Skillは「Figmaデザインの実装方法」という知識を提供し、MCPは「Figma APIとの通信手段」を提供する。

MCPの設定スコープ

スコープ設定場所共有範囲
Project.mcp.jsonGitでチーム共有
User~/.claude.json個人の全プロジェクト

MCPが必要なケース

  • GitHub APIの操作（PR作成、Issue取得）
  • Figmaデザインの取得
  • データベースクエリの実行
  • Slack等への通知送信
  • ブラウザの自動操作

逆に言えば、外部サービスとの通信が不要なら、MCPは必要ない。

実践的な選択フローチャート

flowchart TD
    A["機能を拡張したい"] --> B{"常に適用したいルール？"}
    B -->|"Yes"| C["CLAUDE.md / rules"]
    B -->|"No"| D{"外部通信が必要？"}
    D -->|"Yes"| E["MCP Server"]
    D -->|"No"| F{"複数ファイルの参照資料？"}
    F -->|"Yes"| G["Skill"]
    F -->|"No"| H{"自動検出させたい？"}
    H -->|"Yes"| I["Skill"]
    H -->|"No"| J{"サブエージェント分離？"}
    J -->|"Yes"| K["Skill (context: fork)"]
    J -->|"No"| L["Command"]

組み合わせの実例

実際のワークフローでは、これらを組み合わせて使う。

例1: Figmaデザインの実装

  • CLAUDE.md: Reactのコーディング規約、コンポーネント命名規則
  • MCP: figma-remote-mcp（Figmaからデザインデータを取得）
  • Skill: /implement-design（取得したデータをコードに変換する手順）

例2: コードレビュー → 修正 → コミット

  • CLAUDE.md: プロジェクトのテスト方針、lint設定
  • MCP: なし（ローカル操作のみ）
  • Skill: /claude-review（レビュー手順と観点の定義）

例3: 画像生成プロンプトの作成と実行

  • CLAUDE.md: なし（プロジェクト規約は関係しない）
  • MCP: nanobanana（Gemini画像生成APIとの通信）
  • Skill: /nanobanana-prompt-writer（高品質なプロンプトを書くためのドメイン知識）

このように、CLAUDE.mdが「憲法」として常に基盤ルールを提供し、MCPが「手足」としてAPIを叩き、Skillが「手順書」として特定タスクの知識を提供する。

まとめ

判断基準選択
全セッションで常に適用したいルール・知識CLAUDE.md
外部サービスとの通信が必要MCP
特定の作業文脈での知識・手順 + 自動検出Skill
単純な定型手順を手動で呼ぶだけCommand（既存ならそのまま）
新規作成するならSkill（Commandは非推奨）

CLAUDE.mdに全てを詰め込むのではなく、常時必要な基盤ルールだけをCLAUDE.mdに、特定場面の知識はSkillに分離する。この使い分けがコンテキストウィンドウの効率的な利用につながる。Commandsは後方互換のために残されているが、新しく作る理由はない。

以上。