Claude Code 拡張機能の選び方

Claude Code の活用において、CLAUDE.mdを書くところまで進めたのち、その先のスキルやフック、サブエージェント利用で手が止まることがあります。公式ドキュメントを開くと機能の一覧は出てきますが、自分が今どれを足すべきなのかは、一覧からは分かりにくいものです。

Claude Code の公式ドキュメントには、この点について「Build your setup over time（設定は少しずつ育てる）」という考え方が示されています。最初に全部そろえる必要はなく、困りごとが出てきたタイミングで、それに対応する機能を 1 つ足していくというものです。

本記事は、Claude Code を日常的に使っていて、CLAUDE.md は用意したものの、その先の機能は触れていない方に向けて書いています。「こう困ったら、これを足す」という対応関係を、最小の設定例つきで 4 つ紹介します。読み終えたときに、次に自分が何を作ればよいかを決められる状態を目指します。

本記事で扱うのは、スキル・MCP・サブエージェント・フックの 4 つです。作った設定を複数のリポジトリで利用するプラグイン化、複数セッションを協調させるエージェントチーム、Claude Agent SDK による独自エージェントの開発は扱いません。

前提条件

本記事は、次のような状態を前提としています。

• Claude Code をインストールし、日常的に使っている。
• CLAUDE.md を書いたことがある。
• JSON と Markdown のファイルを、エディタで直接編集できる。

記事中のコマンドと設定は、2026年8月時点の Claude Code 公式ドキュメントの内容に基づいています。設定ファイルの記述例は、いずれもファイルの一部です。既に内容がある場合は、丸ごと置き換えずに項目を追加してください。

全部そろえなくてよい ― 困りごとから足すという考え方

Claude Code の拡張機能は、それぞれ別の困りごとに対応しています。裏を返すと、その困りごとが起きていないうちは、足しても効果を感じにくいということです。

公式ドキュメントでは、機能を足すきっかけ（トリガー）が次のように整理されています。

困っていること	足すもの
Claude Code が同じ規約やコマンドを 2 回間違える	CLAUDE.md に書く
同じプロンプトを毎回打ち込んでいる	スキルにする
同じ手順書を何度もチャットに貼り付けている	スキルにする
Claude Code から見えないツールの画面を、コピーして渡している	MCP でつなぐ
会話が調査ログで埋まる	サブエージェントに任せる
毎回やってほしいのに、実行されないことがある	フックにする
2 つ目のリポジトリでも同じ設定が必要になった	プラグインにまとめる

この表の良いところは、「思い当たらない行は、今は無視してよい」 と判断できる点です。以降の章では、この表の 2 行目から 6 行目までを、順に 1 つずつ見ていきます。

なお、機能を足すとその分だけ Claude Code が読み込む情報が増えます。増やしすぎたときに何が起きるかは、記事の後半「足しすぎないための目安」で扱います。

困りごと 1：同じプロンプトを毎回打ち込んでいる ― スキルにする

まず取り上げるのは、チャット欄に同じプロンプトを毎回打ち込んでいるという困りごとです。

たとえば作業の区切りごとに、「今の変更内容を要約して、気になる点があれば挙げて」と毎回入力しているとします。内容は毎回ほぼ同じで、その都度少しずつ言い回しが変わり、指示を書き忘れた項目は結果に反映されません。

こうした「決まった手順」は、スキルとして保存できます。スキルは SKILL.md という Markdown ファイルで、保存しておくと /スキル名 で呼び出せるようになります。

スキルを作る

ここでは、変更内容の要約を行うスキルを個人用として作ります。個人用のスキルは、自分のすべてのプロジェクトで使えます。

ディレクトリを作成します。

mkdir -p ~/.claude/skills/summarize-changes

作成したディレクトリに SKILL.md を保存します。

---
description: 未コミットの変更を要約し、気になる点を挙げます。変更内容の確認、コミットメッセージの作成、差分のレビューを頼まれたときに使います。
---

## 現在の変更

!`git diff HEAD`

## 手順

上の差分の内容を 3 点以内で要約してください。そのうえで、気になる点（エラー処理の漏れ、ハードコードされた値、更新が必要なテストなど）があれば挙げてください。差分が空の場合は、未コミットの変更がないことを伝えてください。

このファイルは、次の 3 つの部分でできています。

• --- で囲まれた frontmatter：スキルの設定を書く部分です。ここでは description だけを設定しています。
• ! で始まる行：Claude Code がこのコマンドを実行し、その結果に置き換えてから読み込みます。そのため、要約は「今の実際の差分」に基づいたものになります。
• 手順の本文：スキルが呼び出されたときに、Claude Code が従う指示です。

description は特に重要です。Claude Code はこの説明文を読んで、今の会話にこのスキルが関係するかどうかを判断します。「何をするか」だけでなく「どういうときに使うか」まで書いておくと、利用してほしいときに読み込まれやすくなります。

スキルを呼び出す

保存したスキルは、2 通りの方法で使えます。

1 つは、自分で明示的に呼び出す方法です。ディレクトリ名がそのままコマンド名になります。

/summarize-changes

もう 1 つは、Claude Code に任せる方法です。「何を変更したか教えて」のように、description に書いた内容と合う依頼をすると、Claude Code が自動でスキルを読み込みます。

置き場所で共有範囲が決まる

スキルは、置き場所によって使える範囲が変わります。

置き場所	パス	使える範囲
個人用	~/.claude/skills/<スキル名>/SKILL.md	自分のすべてのプロジェクト
プロジェクト用	.claude/skills/<スキル名>/SKILL.md	そのプロジェクトのみ

チームで共有したい手順は、プロジェクト用に置いて Git のバージョン管理に含めます。個人の作業だけで利用するものは、個人用に置きます。

CLAUDE.md との使い分け

ここで、「CLAUDE.md に書けばよいのでは」という疑問が出てきます。両方とも指示を書くファイルですが、読み込まれるタイミングが異なります。

	CLAUDE.md	スキル
読み込まれるタイミング	毎回のセッション開始時	呼び出されたとき
向いている内容	「常にこうする」という規約	ときどき使う手順・参照資料
/名前 での呼び出し	できない	できる

ビルドコマンドやコーディング規約のように毎回必要な事実は CLAUDE.md に、リリース手順やレビュー観点のように必要なときだけ参照する手順はスキルに置きます。

公式ドキュメントでは CLAUDE.md を 200 行以内に保つことが推奨されており、CLAUDE.md の中の「手順」の節が長くなってきたら、スキルに移す合図と考えられます。

困りごと 2：Claude Code から見えないツールの画面を、コピーして渡している ― MCP でつなぐ

次は、Claude Code から見えないツールの画面を、コピーして渡しているという困りごとです。

以下のような作業が続くようであれば、MCP（Model Context Protocol） でそのシステムを直接つなぐ段階です。

• 課題管理システムの Issue の内容をブラウザで開いてコピーし、チャットに貼り付けている。
• エラーの調査のために監視ダッシュボードの数値を書き写している。

MCP は、AI ツールと外部サービスをつなぐためのオープンな規格で、接続すると Claude Code が自分でその情報を読みに行けるようになります。

サーバーを追加する

MCP サーバーの追加は、claude mcp add コマンドで行います。クラウドサービスに接続する場合は、HTTP 型のリモートサーバーとして追加するのが基本です。

# 書式
claude mcp add --transport http <名前> <URL>

# 例：Notion に接続する
claude mcp add --transport http notion https://mcp.notion.com/mcp

コマンドを実行しただけでは、まだ接続は完了していません。多くのリモートサーバーはログインを必要とするため、/mcp コマンドを実行して認証を行います。サーバーごとの接続状況とトークンの消費量もあわせて確認できます。

スコープでチーム共有を切り替える

MCP サーバーには 3 つのスコープがあり、「どのプロジェクトで読み込まれるか」と「チームで共有されるか」が変わります。

スコープ	読み込まれる範囲	チームでの共有	保存先
local（既定）	追加したプロジェクトのみ	されない	~/.claude.json
project	追加したプロジェクトのみ	される	プロジェクト直下の .mcp.json
user	自分のすべてのプロジェクト	されない	~/.claude.json

例えば、チーム全員に同じ接続先を配りたい場合は、project スコープを指定します。

claude mcp add --transport http shared-server --scope project https://example.com/mcp

このコマンドを実行すると、プロジェクト直下に .mcp.json が作成されます。

{
  "mcpServers": {
    "shared-server": {
      "type": "http",
      "url": "https://example.com/mcp"
    }
  }
}

このファイルを Git のバージョン管理に含めると、チームの全員が同じ MCP サーバーを使えるようになります。

なお、.mcp.json に書かれたサーバーは、対話セッションで初めて使うときに承認を求められます。他の人がコミットした接続先が、気づかないうちに使われることを防ぐための挙動です。

一方、個人の検証用サーバーや、認証情報をバージョン管理に載せたくないサーバーは、既定の local スコープのままにします。

困りごと 3：会話が調査ログで埋まる ― サブエージェントに任せる

3 つ目は、本題に入る前に、会話が調査の出力で埋まってしまうという困りごとです。

「この機能がどこで実装されているか調べて」と頼むと、Claude Code は多数のファイルを検索して読み込みます。

知りたいのは結論の数行だけなのに、そこに至るまでの検索結果とファイルの中身が会話に残り、本題の実装を始めるころには会話が長くなっている、という状況です。

このときに使うのがサブエージェントです。サブエージェントは独立したコンテキストで動く作業者で、調査そのものは別の場所で行い、要約だけを元の会話に返します。途中の出力は元の会話に残りません。

組み込みのサブエージェントを使う

サブエージェントは、自分で定義しなくても使えます。

Claude Code には、ファイル検索とコード解析を担当する読み取り専用の Explore などが組み込まれており、「〜がどこにあるか調べて」といった依頼に対して、Claude Code が委譲を判断します。

独自のサブエージェントを定義する

「毎回この観点でレビューしてほしい」といった役割が決まっている場合は、独自に定義できます。プロジェクト用のサブエージェントは .claude/agents/ に Markdown ファイルとして置きます。

---
name: code-reviewer
description: コードの品質・セキュリティ・保守性を確認します。コードを書いた直後のレビューに使います。
tools: Read, Grep, Glob, Bash
model: inherit
---

あなたはシニアコードレビュアーです。

実行するときの手順:

1. `git diff` で最近の変更を確認する
2. 変更のあったファイルに絞ってレビューする

確認する観点:

- 変数名・関数名が分かりやすいか
- エラー処理が実装されているか
- シークレットや API キーがコードに書かれていないか
- テストが不足していないか

指摘は、Critical（修正が必要）・Warning（修正を推奨）・Suggestion（検討事項）に分けて提示してください。

frontmatter で使う主な項目は次のとおりです。

項目	必須	内容
name	必須	サブエージェントの名前、呼び出すときに使います
description	必須	どういうときに使うか、Claude Code が委譲を判断する材料になります
tools	任意	使えるツールを限定します、省略すると、すべてのツールを引き継ぎます
model	任意	使用するモデル、inherit で元の会話と同じモデルになります

上の例では tools に Write や Edit を含めていません。レビュー担当がファイルを書き換えてしまうことを、設定として防いでいます。役割に必要なツールだけを渡せる点は、サブエージェントの利点の 1 つです。

置き場所は、スキルと同じ考え方です。

置き場所	使える範囲
.claude/agents/	そのプロジェクトのみ
~/.claude/agents/	自分のすべてのプロジェクト

呼び出すときは、「code-reviewer で認証まわりの変更を確認して」のように名前を挙げて依頼します。

スキルとの使い分け

スキルとサブエージェントは、どちらも「作業をまとめておくもの」に見えるため迷いやすい部分です。違いはどこで実行されるかにあります。

	スキル	サブエージェント
実体	再利用する指示・知識	独立したコンテキストを持つ作業者
実行される場所	今の会話の中	別のコンテキスト
会話に残るもの	読み込んだ内容すべて	結果の要約のみ
向いていること	参照資料、呼び出したい手順	大量のファイルを読む作業、並行して進めたい作業

出力量が多く、途中経過を見返さない作業はサブエージェントに向いています。逆に、対話しながら少しずつ進めたい作業は、元の会話で進めたほうがスムーズです。

困りごと 4：毎回やってほしいのに、実行されないことがある ― フックにする

4 つ目は、指示したはずのことが、実行される時と実行されない時があるという困りごとです。

「ファイルを編集したらフォーマッターを実行して」と CLAUDE.md に書いたのに、実行される時と実行されない時があります。

これは書き方の問題ではなく、仕組みの問題です。CLAUDE.md やスキルの内容は、Claude Code が読んで従う「指示」であって、実行を保証する設定ではありません。公式ドキュメントでも、必ず守らせたいものは指示ではなくフックにするよう案内されています。

フックは、Claude Code のライフサイクル上の決まったタイミングで、指定したコマンドを実行する仕組みです。Claude Code の判断を介さないため、条件に合致すれば必ず実行されます。

編集後にフォーマッターを実行する

例えば、コードの整形を毎回実行してほしい場合は、ファイルの編集後に Prettier を実行するフックをプロジェクトの .claude/settings.json に設定します。

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"
          }
        ]
      }
    ]
  }
}

設定の読み方は次のとおりです。

• PostToolUse：ツールの実行後に発火するイベントです。他にも、ツールの実行前に発火する PreToolUse、入力待ちになったときに発火する Notification などがあります。
• matcher：対象のツールを絞り込む条件です。Edit|Write と書くと、ファイルを編集する 2 つのツールのときだけ実行されます。
• command：実行するコマンドです。フックには、実行されたツールの情報が JSON で標準入力から渡されます。この例では jq でファイルパスだけを取り出し、Prettier に渡しています。

この例では JSON の解析に jq を使うため、あらかじめインストールしておきます（macOS は brew install jq、Debian や Ubuntu は apt-get install jq）。

設定ファイルに既に hooks の記述がある場合は、hooks オブジェクト全体を置き換えずに、イベント名を並列のキーとして追加します。

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{ "type": "command", "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write" }]
      }
    ],
    "Notification": [
      {
        "matcher": "",
        "hooks": [{ "type": "command", "command": "echo 'Claude Code が入力を待っています'" }]
      }
    ]
  }
}

スキルとの使い分け

フックとスキルは、確実性で使い分けます。

	フック	スキル
実行されるもの	シェルコマンドなど	Claude Code が読んで従う指示
きっかけ	ライフサイクルイベント	/名前 での呼び出し、または Claude Code の判断
確実性	条件に合致すれば必ず実行される	Claude Code の解釈によって変わる
向いていること	整形、危険な操作の拒否、通知、記録	判断を伴う手順、参照資料

判断が要らず、毎回同じように実行してほしいことはフックに向いています。逆に、状況に応じて進め方を変えてほしいことは、フックでは表現できません。

足しすぎないための目安

ここまで 4 つの機能を見てきました。最後に、足しすぎたときに何が起きるかを押さえておきます。

拡張機能は、それぞれ違うタイミングで読み込まれ、消費する量も異なります。

機能	読み込まれるタイミング	読み込まれるもの	コンテキストの消費
CLAUDE.md	セッション開始時	全文	毎回のリクエストで消費する
スキル	セッション開始時と使用時	開始時は説明文のみ、使うときに全文	低い
MCP サーバー	セッション開始時	ツール名（詳細な定義は必要になったとき）	使うまでは低い
サブエージェント	起動されたとき	独立したコンテキスト	元の会話とは分離される
フック	発火したとき	なし（Claude Code の外で実行される）	ゼロ（出力を返す場合を除く）

注目したいのは、CLAUDE.md だけが「毎回のリクエストで全文を消費する」点です。スキルや MCP サーバーは、使うまでのコストが小さく設計されています。

読み込む情報が増えすぎると、コンテキストの上限に近づくだけでなく、情報が増えたことでスキルが正しく選ばれない、書いたはずの規約が守られにくくなるといった影響も出ます。

現在のセッションで何がどれだけ読み込まれているかは、/context コマンドで以下のように確認できます。

増やしすぎを防ぐための目安をまとめます。

• CLAUDE.md は 200 行以内を目安にする。長くなったら、手順はスキルに移す。
• 使っていない MCP サーバーは、/mcp から切断する。
• 自分だけが呼び出したいスキルは、frontmatter に disable-model-invocation: true を設定する。Claude Code の判断では読み込まれなくなり、説明文の分の消費もなくなる。

まとめ

本記事では、CLAUDE.md の次に何を足すかを、困りごと起点で選ぶ方法を紹介しました。要点を振り返ります。

• 同じ指示を毎回打っている → スキルにする。SKILL.md を置き、/名前 で呼び出す。
• 他のツールの画面をコピーしている → MCP でつなぐ。チーム共有は project スコープを使う。
• 会話が調査の出力で埋まる → サブエージェントに逃がす。要約だけが会話に返る。
• 毎回やってほしいのに実行されないことがある → フックにする。指示ではなく設定として確実に実行させる。
• 足しすぎない → /context で消費量を確認し、CLAUDE.md は 200 行以内を目安にする。

拡張機能は、そろえること自体が目的ではありません。困りごとが起きたときが、その機能を足す適切なタイミングです。今の自分に当てはまる困りごとが 1 つ見つかったなら、まずそこから始めるのが確実です。

作った設定を複数のリポジトリで使い回したくなったときは、次の段階としてプラグインにまとめる方法があります。プラグインは、スキル・フック・サブエージェント・MCP サーバーの設定を 1 つのまとまりとして配布できる仕組みです。本記事では扱っていないため、別記事で紹介する予定です。

参考URL

• Claude Code Overview — 製品全体の概要と機能の全体像
• Extend Claude Code — 機能の使い分けと「Build your setup over time」の考え方
• How Claude remembers your project — CLAUDE.md の置き場所と書き方
• Extend Claude with skills — スキルの作成方法と frontmatter の一覧
• Connect Claude Code to tools via MCP — MCP サーバーの追加方法とスコープ
• Subagents — サブエージェントの定義方法と呼び出し方
• Automate actions with hooks — フックの設定例とイベントの種類
• Claude Code settings — 設定ファイルの階層と優先順位

執筆担当者プロフィール

近藤 充朗（日本ビジネスシステムズ株式会社）

クラウドビジネスサービス事業本部所属、アプリケーション開発を行っています。

担当記事一覧