Claude Codeにはスキル、サブエージェント、スラッシュコマンド、CLAUDE.md、Hooksなど、多くの機能があります。中には似たようなものもあり、その使い分けがわからなくなることも多々あります。この記事では各機能の概要及び使い分けについて、特にコンテキストの観点で考察します。
先に結論
CLAUDE.md
もはや説明する必要はないかもしれませんが、Claude Codeが作業するにあたり必要な知識（コンテキスト）を与えるための仕組みです。言うなればClaude Code向けのREADME.mdと言ったところでしょうか。例えば、コーディングガイドラインやツールの使い方を教えることで、Claude Codeがそれらに従って作業してくれるようになります。
## リポジトリ概要
...
## ビルド方法、ツール
...
## プロジェクト構成と主要なファイル
...
## コーディングガイドライン
...
CLAUDE.mdが充実していれば、それだけユーザーの意図に沿った振る舞いになり、Claude Codeの品質向上に繋がります。しかし、闇雲にコンテキストを与えれば良いわけではなく、LLMの記憶力には限界があります。例えば、Claude Sonnet 4.5では原則200Kトークンまでとなっています。
コンテキストの限界に近づいたとき、LLMではLost in the Middleといって途中の情報を見落しやすくなることが知られており、Claude Codeでも、これまでのコンテキストを圧縮する機構が働き、必要な情報が抜け落ちて精度が劣化する、といった問題が起こります。
したがって、Claude Codeの品質を上げるためには「情報を沢山与えること」と「情報を沢山与えないこと」、一見矛盾したこの2つを両立させる必要があります。
スキル（Skills）
スキルは.claude/skills/{skill-name}/SKILLS.mdにあるnameやdescriptionといったfront matterのみをClaude Codeが起動時に読み込み、作業過程で必要に応じてClaude CodeがSKILLS.md全体を読み込み、知識として活用する機能です。
例として、コードレビューのスキルを紹介します。
---
name: code-review
description: コードレビューを実行します。diffやコミット、PRをレビューする際に使用してください。
---
コードレビュー時は以下に従ってください
- 日本語で応答すること
- 重大な問題にフォーカスし、軽微なリファクタリングは提案しないこと
- PR内でコード修正を提案する場合、suggestionブロックを使用すること
- ...
一見するとCLAUDE.mdに記載しても良さそうですが、大きな違いは必要に応じて本文が読み込まれる、という点です。コードレビューの知識はコードを書いているタイミングでは必要ないので、CLAUDE.mdに記載した場合、無駄にコンテキストを肥大化させてしまいます。スキルに記載した場合はコードレビューが必要になったタイミングでこのルールを読み込むため、コンテキストを節約することができます。
スラッシュコマンド（Slash commands）
スラッシュコマンドはClaude Codeの組み込みコマンドのように、/command-name と入力することで、.claude/commands/{command-name.md}に書かれた内容を実行する機能です。
Claude Code内で/contextコマンドを実行すると、スラッシュコマンドはスキルの一部として読み込まれていることが確認できます。ほぼスキルと同じと考えていいのかもしれません。
事実、v2.1.3からはスキルとスラッシュコマンドを統合するような変更が入っています。
スラッシュコマンドの特徴は、手動で明示的に呼び出す点です。
例として、PRを作るコマンドを紹介します。
---
allowed-tools: Bash(git add:*), Bash(git status:*), ...
description: 必要に応じてコミットを作成し、ブランチをプッシュした上で、PRを作成します。
---
## 1. 対象ブランチの確認
...
## 2. 変更があればコミット
...
## 3. ブランチをプッシュ
...
## 4. PRを作成
...
Claude Code内で/pr と叩くと、これを読み込み、実行されます。
このコマンドのユースケースを考えると、コーディングの最中というよりは、毎回コーディングが終わったあと、必要に応じて実行したくなる気がします。このように
- 明示的に実行したいタイミングが存在し
- 定期的に使用しうる
場合にはスラッシュコマンドの出番と言えるでしょう。
ちなみに、 pr.md の中身を直接プロンプトに貼り付けて実行しても、ほぼ同等な処理が実現できます。スラッシュコマンドの利点は詠唱破棄（プロンプトをショートカット）して簡単に呼び出せる点にあるとも言えます。
サブエージェント（Subagents）
サブエージェントは、.claude/agents/{agent-name}.mdに定義したエージェントを子のエージェントとして作業中に起動する機能です。
巨大な作業の中で、小タスクに分解したものを実行させるイメージですが、必要に応じて実行される点ではスキルと似ていますし、明示的に「fooエージェントでbarを実装して」といったスラッシュコマンド的な使い方もできます。どう使い分ければいんでしょうか？
使い分けのポイントは 「独立したタスクで、作業過程を忘れた方が良く、結果だけが必要」 であるかどうかだと思っています。キングクリムゾンみたいでよくわからないですね。
例で説明します。以下は翻訳を担当させるサブエージェントです。
---
name: translator
description: 既存の翻訳との整合性を保ちながら、与えられた日本語を英語に翻訳します。日英翻訳を依頼されたときには、このエージェントを使用して英訳を生成してください。
...
---
あなたは翻訳の専門家です。以下の手順に従って適切な英訳を生成してください。
英訳は既存の翻訳との整合性を保つ必要があります。
1. 翻訳対象を解析する
- 同じ訳や似たような文章が既に存在しないか、他のファイルを調査してください。
- 翻訳対象がどのような文脈で使用されているのか、関連する実装を調査してください。
...
2. 翻訳する
...
3. 翻訳結果の妥当性を検証する
...
このサブエージェントでは、日本語を英語に翻訳するにあたり、事前に関連するファイルを調査させています。この調査が膨大なファイルに及んだ場合、ただの1文を翻訳するためだけに、エージェントがコンテキストを大量に消費してしまい、その後のコーディング作業は大量の翻訳調査結果を頭に抱えながらエージェントが動作することになってしまいます。サブエージェントを定義することで、この翻訳過程はサブエージェントだけが観測した問題になり、Claude Code本体ではサブエージェントが翻訳結果を考えてくれた、という結果だけを観測、記憶することになります。
このように、サブエージェントの使い分けはコンテキストの忘却が焦点にあるかどうかを考えると判断しやすいと思っています。例えば、先程挙げたコードレビューのスキルはサブエージェントでも成立するかもしれません。
---
name: code-review
description: コードレビューを実行します。diffやコミット、PRをレビューする際に使用してください。
---
コードレビュー時は以下に従ってください
- 日本語で応答すること
- 重大な問題にフォーカスし、軽微なリファクタリングは提案しないこと
- PR内でコード修正を提案する場合、suggestionブロックを使用すること
- ...
しかしコードレビューした結果、なぜそう判断したのか、どこのコードを調査したのか、といった過程の知識が後続の命令で必要になるのであれば、これはサブエージェントでやるべきではない、ということになります。
Hooks
Hooksはこれまで紹介した機能とは少し毛色が違う機能です。.claude/settings.json に書かれた設定を元に「Aが起こったらBする」といった処理を実行します。ファイルを直接するほか、Claude Codeの /hooks コマンドからも設定することができます。
以下はClaude Codeが何かを通知した際にPCで音を鳴らすHooksの例です。
{
"hooks": {
"Notification": [
{
"matcher": "",
"hooks": [
{
"type": "command",
"command": "afplay /path/.../Ping.aiff &"
}
]
}
],
...
}
}
見てわかる通り、自然言語ではなく、JSONによる設定ファイルになっています。
自然言語の曖昧さを排除しているがゆえに、Hooksは特定のタイミングで確実に処理を実行したい場合に有効です。例えば「Claude Codeがコードに変更を加えたときにフォーマッタを実行する」などです。
その他
MCP
MCPはClaude Codeに限った話ではなく、AIアプリケーション全般を対象としたプロトコルです。Claude Codeに設定したMCPは /mcp で確認できる他、 /context でMCPが占有するコンテキストを確認することができます。
MCPの利用時の注意点は、設定するとそのMCPサーバーが提供する全てのツールがロードされる、という点です。例えば、Figma MCPをUIモックの取得目的で設定した場合、Figma上でコメントをつけたり消したりするツールも（必要なかったとしても）読み込まれ、コンテキストを消費します。
こうした事情もあってか、最近ではMCPの設定を動的に読み込む機能が追加されました。
MCPは便利ですが、コンテキストの観点からは必要なものだけに絞るに越したことはないかもしれません。
プラグイン（Plugins）
プラグインは今まで紹介した機能と比較する何かではなく、今まで紹介した機能（スキル、サブエージェント、プラグイン、MCPなど）を共有・配布するための手段です。.claudeフォルダとはリポジトリを横断して組織やチームに配布できる点が異なります。スラッシュコマンドでは /plugin-name:command のように、プラグイン間の衝突を避けるためのprefixが入る点に注意が必要です。
Discussion