Claude Code拡張6種の使い分け完全ガイド【2026年版】

クイックサマリー: Claude Codeには CLAUDE.md / Skills / Hooks / Subagents / MCP / Plugins という6つの拡張ポイントがあり、それぞれ「毎回読むルール」「定型手順」「必ず実行される処理」「独立コンテキストの別働隊」「外部接続」「配布パッケージ」と役割が明確に分かれています。この記事は Claude Code（CLI / VS Code拡張）ユーザー向けに、6つの役割・設定方法・使い分けの判断基準を整理する実践ガイドです。

「Skillsは使っているけれど、HooksとSubagentsは何が違うのか」「CLAUDE.mdに書くのとSkillにするのはどちらが正しいのか」——Claude Codeを使い込むほど、この整理に消耗していませんか。6つの拡張ポイントは名前だけ見るとどれも「Claudeをカスタマイズする仕組み」に見えるため、混同したまま運用してコンテキストを浪費してしまう課題がよく起こります。

この記事では、Zennで公開されている整理記事「【Claude Code】エコシステム完全整理」（M16合同会社・2026年7月時点の公式ドキュメントに基づく解説）を参照しながら、6つの拡張ポイントを「お願い（LLM任せ）か、仕組み（必ず実行）か」という軸で一枚の地図にまとめます。

• 6つの拡張ポイントの役割と設定場所（最小の設定例付き）
• SkillsとSubagentsの違い（コンテキストを分離するかどうか）
• 実際の開発フローへの組み込み方と導入順序
• 迷ったときの判断フローと早見表

なお、Claude Code本体はAnthropicの製品（クローズドソース）ですが、ここで扱う拡張ファイル群（SKILL.md・settings.json・エージェント定義など）はすべて自分のリポジトリに置くプレーンなMarkdown/JSONであり、チームで自由に共有できます。

6つの拡張ポイントの全体像 — 競合ではなく役割分担

まず結論の地図です。元記事では6つをたとえ話で整理しており、この対応関係を頭に入れるだけで大半の混乱が解消すると考えられます。

重要なのは、6つは競合ではなく役割分担だという点です。「SkillsとHooksのどちらが良いか」ではなく「この仕事はどちらの担当か」で考えると、一気に整理できます。最重要の軸は「お願い（LLMの判断に任せる）」か「仕組み（100%必ず実行される）」かです。CLAUDE.mdやSkillsに書いた指示はLLMが読んで従う「お願い」なので、忘れられる可能性があります。一方Hooksはツール実行などのイベントに紐づいてシェルコマンドとして走る「仕組み」なので、モデルの判断と無関係に実行されます。

各拡張ポイントの設定方法（最小の書き方）

ここからは各拡張ポイントの最小構成を示します。いずれも公式ドキュメント（code.claude.com/docs）に基づく標準的な書き方です。

CLAUDE.md — スコープは3段階

CLAUDE.mdはセッション開始時に毎回読み込まれる指示書です。ユーザー全体（~/.claude/CLAUDE.md）、プロジェクト共有（./CLAUDE.md）、自分だけ（./CLAUDE.local.md）の3スコープがあります。ビルドコマンドやディレクトリ規約など「毎回必要な短い事実」だけを書き、長い手順書を書き続けるのはアンチパターンです。毎回コンテキストを消費するためです。

# プロジェクト規約
## コマンド
- ビルド: `npm run build`
- テスト: `npm run test`
## コーディング規約
- インデントは2スペース

Skills — progressive disclosureで低コスト

.claude/skills/review-code/SKILL.md のようにフォルダを作り、frontmatter付きMarkdownを置きます。ユーザー全体で使うなら ~/.claude/skills/ です。

---
name: review-code
description: コードをレビューして改善点を提案する。「レビューして」と依頼されたときに使う
---
コードを以下の観点でレビューしてください:
1. セキュリティ
2. パフォーマンス
3. テストカバレッジ

Skillsの鍵は progressive disclosure（段階的開示）という設計です。普段Claudeが見ているのは各Skillのdescription（1〜数行）だけで、本文は起動時に初めて読み込まれます。そのためSkillを数十個作っても普段のコンテキスト消費はごくわずかで、ここがCLAUDE.mdとの最大の違いです。なお、以前の「カスタムスラッシュコマンド（.claude/commands/*.md）」はSkillsに統合されており、旧形式も互換動作しますが新規作成はSkills形式が推奨されています。

Hooks — exit code 2でツール実行をブロック

.claude/settings.json にイベントとコマンドを書きます。以下は「ファイル編集後に必ずlintを実行する」例です。

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [{ "type": "command", "command": "npm run lint" }]
      }
    ]
  }
}

イベントは SessionStart / UserPromptSubmit / PreToolUse / PostToolUse / Stop / PreCompact などが用意されています。特にPreToolUseのフックが exit code 2 を返すとそのツール実行自体をブロックできるため、rm -rf や git push --force を機械的に止めるガードレールが組めます。

Subagents — 独立コンテキストの専門家

.claude/agents/security-reviewer.md のようにエージェント定義を置きます。frontmatterで使えるツールを制限したり、用途に応じてモデルを変える（重い調査は上位モデル、ログ要約は安価なモデル）ことも可能です。

---
name: security-reviewer
description: セキュリティ脆弱性を専門に検査するエージェント
tools: Read, Grep, Bash
---
あなたはセキュリティの専門家です。
渡されたコードをOWASP Top 10の観点で検査し、
指摘事項を重大度順にまとめて報告してください。

MCP — 外部サービスへの接続

コマンド1行、またはプロジェクト直下の .mcp.json でチーム共有できます。スコープはlocal（自分だけ）/ project（チーム共有）/ user（自分の全プロジェクト）の3段階です。

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"]
    }
  }
}

Plugins — 「作る」ではなく「配る」仕組み

Pluginsだけは毛色が異なり、新しい機能ではなくSkills・Subagents・Hooks・MCPを束ねて配布するパッケージです。.claude-plugin/plugin.json をルートに置き、skills/・agents/・hooks/・.mcp.json を同梱します。marketplaceに登録すれば他のユーザーが /plugin コマンドからインストールでき、プラグイン由来のSkillは /plugin-name:skill-name と名前空間付きになるため手元のSkillと衝突しません。1リポジトリで完結するなら .claude/ 直置きで十分で、複数プロジェクト・複数人に配りたくなった段階でPlugins化するのが自然な順番です。

実際の開発フローに組み込む方法

6つを組み合わせた実務での使い方を、職種別のシナリオで示します。

Webアプリ開発チームの場合: CLAUDE.mdにビルド・テストコマンドとディレクトリ規約を書き、PostToolUseフックで編集のたびにlintを強制します。「コミット前にlintして」とCLAUDE.mdに書くのは「お願い」で忘れられることがありますが、Hooksなら100%実行されます。PRレビューの定型観点はSkill化し、/review-code で呼び出します。

SRE・インフラ担当の場合: PreToolUseフックで破壊的コマンド（rm -rf・強制push）をブロックするガードレールを敷き、リリース手順書をSkillにして手順の抜け漏れを防ぎます。監査ログをフックで外部システムに送る構成も組めます。

大規模コードベースを扱うエンジニアの場合: 「1000ファイルをgrepするような探索」をメイン会話でやるとコンテキストが検索結果で溢れるため、Subagentsに委譲します。調査の過程は別室に閉じ、要約だけがメインに戻ってくるのがSubagentsの本質（コンテキストの分離）です。さらにGitHubのissueを読んでPRを作る、SentryやDBに直接クエリするといった外部連携はMCPが担当します。

元記事の筆者は実案件でSkillが29個まで増え、ルーティング用のメタSkillを作ったと報告しています。実際に運用が育つと「困りごとが先にあり、対応する拡張ポイントを後から足す」流れになることがうかがえる体験談です。導入順序も同様で、CLAUDE.md → Skills → Hooks → Subagents → MCP → Plugins と困りごと駆動で育てるのが推奨されており、最初から6つ全部をセットアップする必要はありません。

使い分けの判断基準と他CLIとの比較

迷ったときの判断フローは4問だけです。

1. 100%必ず実行させたいか？ → YES なら Hooks（プロンプトのお願いでは保証できない）
2. 外部サービス・データに繋ぎたいか？ → YES なら MCP
3. 何度も使い回す手順・ノウハウか？ → YES なら Skills（短い事実・規約なら CLAUDE.md）
4. 調査が重くてメインの会話を汚したくないか？ → YES なら Subagents

作ったものをチームに配りたくなったらPluginsで箱詰めします。参考として、類似のAIコーディングCLIとの拡張機構の対応関係も整理しておきます。

料金面では、2026年時点のレビュー記事によると Claude Code は Pro プラン（月額20ドル、年払い換算で月額17ドル相当）から利用でき、ヘビーユーザー向けに Max 5x（月額100ドル）/ Max 20x（月額200ドル）が用意されています。無料枠は Claude Code 自体には無く、APIキーによる従量課金も選べます。最新の料金は公式サイトで確認してください。

注意点・制約・セキュリティ

• Hooksは任意のシェルコマンドを実行します。他人が作ったPluginsやリポジトリのsettings.jsonに含まれるHook定義は、導入前に必ず中身を確認してください。イベント駆動で自動実行されるため、悪意ある定義はSkillより影響が大きい構造です。
• MCPサーバーは外部通信を伴います。接続先（GitHub・DB・SaaS API）にどのデータが渡るかを把握し、認証トークンは .mcp.json をgit管理から外すか環境変数で渡す運用が安全です。
• CLAUDE.mdの肥大化はコンテキスト浪費に直結します。毎回読み込まれる性質上、長い手順はSkillsへ切り出すのが公式ドキュメントでも示されている方向性です。
• 機能変更が速い点にも注意が必要です。元記事も「Claude Codeは月単位で機能が追加・変更されるので、細部は必ず公式ドキュメントで最新情報を確認してください」と明記しています。カスタムスラッシュコマンドのSkills統合のように、書き方が世代交代することがあります。
• 向かない人: 単発の質問応答やごく小規模なスクリプト作成が中心であれば、6つの拡張を整備するコストは見合いません。まずCLAUDE.md1枚から始めるので十分と考えられます。

まとめ — 困りごと駆動で育てる

• Claude Codeの拡張ポイントは6つ。競合ではなく役割分担で、最重要の軸は「お願い（LLM任せ）か、仕組み（必ず実行）か」。守らせたいことはHooksに書きます
• SkillsとSubagentsの違いは「同じ机か、別室か」。コンテキストを分離したい重い調査はSubagentsが担当します
• 導入はCLAUDE.md→Skills→Hooks→Subagents→MCP→Pluginsの順に、困りごとが出てから足していくのが健全です

全体像が頭に入っていると「この困りごとはどの引き出しで解決するか」が一瞬で判断できるようになります。細部の仕様は変化が速いため、さらに詳しくは Claude Code 公式ドキュメントと、本記事の元になったZennの解説記事を参照してください。