Claude Code SkillsとMCPの違い — サブエージェント・hooksを含む4機構の使い分け
Claude Codeの拡張機構Skills・MCP・サブエージェント・hooksは同じ目的を別の形で実装できてしまい、選択に迷いやすい部分です。責務境界と判断フロー、組み合わせの定石を公式ドキュメントから確認します。
Claude Codeの拡張機構は、知識と手順を足すならSkills、外部システムへの接続ならMCP、コンテキストの隔離ならサブエージェント、毎回確実に実行させたい処理ならhooksという責務分担で選ぶと迷いません。4つはどれも「Claudeの振る舞いを変える」機構なので、同じ目的を別の機構で実装できてしまうことがあり、そこが混乱の根源になっています。公式ドキュメントは各機構を別ページで解説していますが、この記事では横断して比較し、どれで作るべきかを1つの判断フローに落とします。
4つの拡張機構は何が違うのか
Skillsとは、Claudeが読み込んで従う知識・手順・参照資料をMarkdownファイルとして再利用可能にする機構です。MCP(Model Context Protocol)は外部サービスへの接続をツールとして提供するプロトコル、サブエージェントは独立したコンテキストウィンドウで動く隔離ワーカー、hooksはツール実行やセッション開始などのライフサイクルイベントで自動実行される処理です。
| 機構 | 実体 | 起動のきっかけ | 得意なこと |
|---|---|---|---|
| Skills | 実体Markdownの指示・知識 | 起動のきっかけ/名前 での呼び出し、またはClaudeが自動選択 | 得意なこと繰り返す手順、参照資料 |
| MCP | 実体外部サービスへの接続 | 起動のきっかけClaudeがツールとして呼ぶ | 得意なことデータベース照会、Slack投稿など外部の操作 |
| サブエージェント | 実体隔離されたワーカー | 起動のきっかけClaudeまたはユーザーが起動 | 得意なこと大量のファイル読み込み、並列作業 |
| hooks | 実体イベントで走る処理 | 起動のきっかけライフサイクルイベントで必ず発火 | 得意なこと編集後のlint、危険コマンドの遮断 |
この表で最初に見るのは「起動のきっかけ」の列です。Skillsはあくまで指示であり、Claudeが解釈して従います。結果は毎回同じとは限りません。一方hooksはイベントに対して必ず発火します。公式ドキュメントはこの差を決定性(determinism)と呼び、毎回同じ動きが必要なものはhooksへ、判断や推論が要るものはSkillsへ、という線を引いています。
どれで作るべきか — 4つの質問で決まる
作りたいものを思い浮かべて、上から順に問いを当てるだけで行き先が決まります。
- 外部システムのデータや操作が必要か — 必要ならMCP。データベース、Slack、ブラウザー操作など、Claude Codeの組み込みツールで届かない相手への接続はMCPの領分です
- 毎回・確実に実行される必要があるか — あるならhooks。「編集のたびにフォーマッタを走らせる」「
.envへの書き込みを止める」のような、1回でも抜けたら困る処理は指示ではなく強制にします - メインの会話を汚したくない作業か — そうならサブエージェント。数十ファイルを読む調査でも、返ってくるのは要約だけなので、メインのコンテキストウィンドウを消費しません
- どれでもない — 残りはほぼSkillsです。繰り返し打っているプロンプト、貼り付けている手順書、参照させたいAPI仕様はすべてSkillに置けます
この順番に意味があります。MCPとhooksは「Skillsでは原理的に代替できないもの」から先に拾う設問で、逆にSkillsは適用範囲が広いぶん最後の受け皿に置いています。公式の機能一覧でもSkillsは「最も柔軟な拡張」と位置付けられており、迷ったらSkillから始めて、足りない性質が見えたら他へ移すのが低コストです。
Skillとサブエージェントの境界 — 中身か、置き場所か
この2つは比較の軸がずれています。Skillは「何を知っているか」、サブエージェントは「どこで作業するか」の機構です。Skillの内容はメインの会話に読み込まれてコンテキストを消費しますが、サブエージェントは自分専用のコンテキストウィンドウを持ち、メイン側には結果の要約だけが返ります。
だから排他ではなく組み合わせられます。サブエージェントの定義にskillsフィールドを書けば、指定したSkillの全文を起動時に読み込んだ専門ワーカーになります。逆にSkill側にcontext: forkを指定して、Skill自体を隔離コンテキストで走らせることもできます。詳細な設計判断はClaude Code Sub-agents完全ガイドで扱っています。
使い分けの目安は読み込む量です。参照資料として会話の中で使い続けたい知識はSkill、途中経過を見る必要がない大量読み込みはサブエージェント。コンテキストウィンドウの残量が心細くなってきたら、それはサブエージェントへ切り出す合図です。
MCPとSkillの境界 — 接続と、使いこなしの知識
MCPは接続そのものを提供し、Skillはその接続をうまく使う知識を提供します。公式ドキュメントが挙げる例が端的で、MCPでデータベースにつなぎ、Skillに自チームのスキーマとクエリーパターンを書いておく、という分担です。接続だけあっても「どのテーブルをどう読むべきか」はClaudeに伝わらず、知識だけあっても実際のデータには触れません。
「外部システム」の判定で迷うケースはほぼありません。認証が要る、ネットワークの向こうにある、Claude Codeの組み込みツール(ファイル操作・検索・シェル実行・Web取得)で届かない。どれかに当てはまればMCPです。接続の設定手順はClaude Code MCP設定ガイドにまとまっています。
hooksとSkill・CLAUDE.mdの境界 — お願いか、強制か
CLAUDE.mdやSkillに「.envは編集しない」と書いても、それは依頼であって保証ではありません。Claudeは指示に従おうとしますが、従うことが構造的に保証されているわけではないからです。公式ドキュメントはこれを明確に区別し、毎回成立しなければならないルールはプロンプトの指示ではなくhookにすることを推奨しています。PreToolUseフックで該当の編集をブロックすれば、Claudeの判断と無関係に止まります。
コストの性質も対照的です。Skillは説明文がセッション開始時に読み込まれ、使うと全文がコンテキストに載ります。hooksは会話の外で実行されるため、出力を返さない限りコンテキスト消費はゼロです。lintやログ記録のような「Claudeが考える必要のない副作用」をhooksに寄せると、コンテキストを一切使わずに品質を担保できます。イベントの種類や設定方法はClaude Code Hooks完全ガイドを参照してください。
CLAUDE.mdとプラグインはどこに入るのか
4機構の手前と後ろに、それぞれ隣接する仕組みがあります。手前にあるのがCLAUDE.mdで、毎セッション自動で読み込まれる常時オンの指示です。「pnpmを使う、npmは使わない」のような毎回必要な規約はCLAUDE.mdに、ときどき必要な参照資料はSkillに、という分担になります。公式はCLAUDE.mdを200行以下に保ち、あふれた参照資料をSkillsへ移すことを推奨しています。CLAUDE.mdの階層と読み込み順はClaude Code memoryの三層構造で詳しく解説しています。
後ろにあるのがプラグインです。プラグインは機構ではなく包装で、Skills・hooks・サブエージェント・MCPサーバーを1つの配布単位に束ねます。同じ構成を複数リポジトリで使い回すとき、また他者に配布するときに初めて必要になるもので、最初の1つを作る段階では考えなくて構いません。
同じ名前・同じイベントが重なったときの挙動
複数のレベル(ユーザー・プロジェクト・プラグイン・組織の管理ポリシー)に同じ定義があるときの解決規則は、機構ごとに違います。
| 機構 | 重複時の挙動 |
|---|---|
| CLAUDE.md | 重複時の挙動全レベルの内容が加算的に読み込まれる |
| Skills | 重複時の挙動名前で上書き(管理ポリシー > ユーザー > プロジェクト) |
| サブエージェント | 重複時の挙動名前で上書き(管理ポリシー > CLIフラグ > プロジェクト > ユーザー > プラグイン) |
| MCPサーバー | 重複時の挙動名前で上書き(local > project > user) |
| hooks | 重複時の挙動上書きされず、登録された全hookが発火する |
hooksだけが「全部走る」点は運用上の注意点です。プロジェクトとユーザーの両方に同種のhookを置くと二重に実行されます。逆に言えば、組織が配布したhookを個人設定で無効化することはできない、という統制側の性質でもあります。
組み合わせの定石
実際の構成は単独選択ではなく組み合わせになります。公式ドキュメントに載っている型は次の4つです。
| 組み合わせ | 分担 |
|---|---|
| Skill + MCP | 分担MCPが接続を持ち、Skillが使い方(スキーマ、クエリーパターン)を教える |
| Skill + サブエージェント | 分担/auditのようなSkillが、観点別のサブエージェントを並列起動する |
| CLAUDE.md + Skills | 分担常時オンの規約はCLAUDE.md、オンデマンドの資料はSkills |
| hooks + MCP | 分担編集後のhookがMCP経由でSlack通知などの外部アクションを起こす |
どの型も「1機構に全部を担わせない」方向で揃っています。たとえばデプロイ手順をSkillに書き、実行前の検証はhookで強制し、デプロイ先の状態確認はMCPで取る、と分ければ、それぞれの変更が他に波及しません。
よくある質問
SkillsとMCPはどちらか一方を選ぶものですか
いいえ、解決する問題が違うので併用が前提です。MCPは外部サービスへの接続、Skillsはその接続を含む作業の知識を担当します。公式ドキュメントも両者を「よく一緒に機能する」組み合わせとして例示しています。
サブエージェントは親のSkillsやCLAUDE.mdを読めますか
サブエージェントはskillsフィールドに列挙されたSkillの全文を起動時に読み込み、列挙していないプロジェクト・ユーザー・プラグインのSkillもSkillツール経由で呼び出せます。CLAUDE.mdとgitの状態も読み込まれますが、組み込みのExploreエージェントとPlanエージェントは例外的にどちらも読み込みません。
hooksを増やすとコンテキストを圧迫しませんか
しません。hooksは会話の外で実行され、既定ではコンテキスト消費ゼロです。ただしhookが出力を返す設定の場合、その出力はメッセージとして会話に追加されるので、返す内容は短く保つ意味があります。
Skillを自分だけが起動できるようにできますか
できます。Skillのfrontmatterにdisable-model-invocation: trueを書くと、Claudeからは見えなくなり、/名前での手動起動だけが残ります。副作用のあるSkill(デプロイなど)や、説明文のコンテキスト消費すら省きたいSkillに向いた設定です。
エージェントチームとサブエージェントはどう違いますか
サブエージェントはセッション内のワーカーで、結果をメインの会話へ要約して返します。エージェントチームは独立したセッション同士が直接メッセージを交換する仕組みで、トークンコストも高くなります。並列サブエージェントでコンテキスト上限に当たる、ワーカー同士の対話が必要になる、のどちらかが移行の合図です。なおエージェントチームは実験的機能で、既定では無効です。
まとめ
Skills・MCP・サブエージェント・hooksの4機構は、知識、接続、隔離、強制という別々の責務を持ちます。判定は「外部システムか→MCP」「毎回確実か→hooks」「会話を汚すか→サブエージェント」「それ以外→Skills」の順で当てれば決まり、CLAUDE.mdが常時オンの土台、プラグインが配布の包装として前後に付きます。同じ目的を複数の機構で書けてしまうときこそ、決定性とコンテキストコストという2軸に立ち返ると、機構の選択は責務の宣言になります。