Claude Code を拡張する4つのメカニズムは、本質的に異なる課題を解決します。Skill は Claude に特定の方法で作業を実行したいことを教えます。Hook はモデルが何を決定しようと、何かが確実に起こることを保証します。Subagent はメインの会話コンテキストを保護し、フォーカスされた作業をクリーンな別プロセスに委譲します。MCP サーバーは Claude にそれなしでは到達不可能なシステムへのアクセスを提供します。間違ったものを選ぶと、モデルが静かに無視できる「ルール」か、プレーンな指示で十分な箇所に無理やり付けられた MCP 依存関係のいずれかに陥ります。
ジョブ別にメカニズムを選ぶ
1つの診断質問から始めてください。実際に何が不足していますか？
答えが「Claude はこれをどのような方法で実行したいのかを知らない」場合、それは skill です。コミットメッセージ形式、PR 説明テンプレート、Lint ポリシー、レビューチェックリスト。これらはすべてパッケージ化された知識であり、関連するときにオンデマンドで読み込まれ、外部依存関係なしに既存セッション内で実行されます。
答えが「固定ポイントで何かが起こる必要があり、モデルが覚えていることを信頼できない」場合、それは hook です。Hook は PreToolUse や PostToolUse などのライフサイクルイベントで発火し、Claude のコンテキスト外で実行されます。モデルはそれをオーバーライドできません。CodingNomads はこれをよく説明しています。Hook は LLM の関与がゼロ、コンテキストコストがゼロで決定論的に実行されます。
答えが「このサブタスクは 40 個のファイル読み取りをメインスレッドに引き込むだろう」場合、それは subagent です。セパレートコンテキストウィンドウ、独自のトークン予算、サマリーを報告します。静かでフォーカスされています。
答えが「Claude は実際に到達不可能なシステムにアクセスする必要がある」場合、それは MCP サーバーです。データベース読み取り、Slack 投稿、内部 API、Notion ページ。これらは知識の問題ではなく、接続の問題であり、MCP だけがそれを解決します。
そして CLAUDE.md はこれら全体の上にある常時オンレイヤーとして機能します。すべてのセッションが自動的に読み込みます。Anthropic 独自のガイダンスに従い 200 行以下に保ってください。そうしないと重要な制約が埋もれて無視されます。
指示、ツールアクセス、イベント、隔離コンテキスト
各メカニズムが実際に制御するもの：
- Skills：指示およびコンテキスト。現在の会話にオンデマンドで読み込まれます。外部呼び出しなし。イベントトリガーなし。モデルはフロントマターの説明に基づいて、skill が関連するタイミングを決定します。
- MCP サーバー：ツールアクセス。Claude は MCP ツールを他のツールと同じ方法で呼び出しますが、実行は JSON-RPC を経由して別プロセスで行われます。MCP サーバーは Claude を外部システムに接続します。Skill は接続後、それらを適切に使用する方法を指示します。
- Hooks：ライフサイクルイベント。SessionStart、PreToolUse、PostToolUse、PreCompact。これらは決定論的に実行されます。破壊的なコマンドをブロックする Hook は、Claude がそれが良い考えだと思ったかどうかにかかわらず、毎回ブロックします。
- Subagents：隔離コンテキスト。Subagent にブリーフを渡すと、独立して作業し、結果を返します。テスト作成 Subagent はデプロイメントパイプラインについて知る必要はありません。ドキュメント Subagent はデータベーススキーマについて知る必要はありません。その分離が全ポイントです。
Skills とコマンドはここで簡潔に説明する価値があります。混同しやすいからです。公式 Skills ドキュメントに従うと、カスタムコマンドは separate な 6 番目のシステムではなく、Skills に折り込まれます。同じ SKILL.md オーサリングモデルを共有しています。詳細は次のセクションで説明します。
Inventive HQ の分析は明確に述べています。「Skill は動作を変更し、Subagent はコンテキストを保護し、MCP サーバーは機能を追加し、Hook はモデルが何を決定するかにかかわらず、イベント上で決定論的にアクションが実行されることを保証します。」
スラッシュコマンドがスキルの中で果たす役割
カスタムスラッシュコマンドはスキルと並行して存在する独立したメカニズムではありません。それらはスキルを呼び出すためのインターフェースです。/deployや/reviewと入力すると、名前でスキルをトリガーしています。そのスキルには、指示、リンクされた参照ファイル、およびClaudeがそのタスクをどう処理するかのコンテキストが含まれています。
オーサリングタスク（良いフロントマター説明を含むSKILL.mdを書く）、コマンド検索タスク（公開するコマンド名を決める）、メカニズム比較タスク（スキルとフックの間で選択する）は、3つの異なる読者の関心事です。これらは偶然ファイル形式を共有しており、その混乱が続く理由の一部です。
そもそもスキルを使うべきかを判断する場合、質問は常に同じです。これは通常は何度も入力し直す知識ですか、それとも入力に関係なくイベント時に発火する必要があるものですか？前者はスキル、おそらくコマンドとして公開されます。後者はフックです。
CLAUDE.mdがプロジェクトコンテキストをすべてのセッションに供給する方法をより深く理解するには、エージェンシー向けCLAUDE.mdガイドがスコーピングとファイル構造を詳しく説明しています。
1つのリポジトリタスク向けのメカニズム構成
ほとんどの現実世界のセットアップは、1つのメカニズムを選んで終わりにすることはありません。2つまたは3つを組み合わせます。PR워크플로우でそれがどう機能するかを示す例シナリオです。
| タスク | メカニズム | 理由 |
|---|---|---|
| PR説明形式を強制する | スキル | パッケージ化された知見。Claudeが PR を書くときにロードされる |
| Linearからチケットコンテキストを取得する | MCPサーバー | Claudeがネイティブでは到達できない外部システム |
| 20ファイル以上をスキャンして影響分析を行う | サブエージェント | メインスレッドを整理された状態に保つ。焦点を絞った概要を返す |
| テスト失敗時にコミットをブロックする | フック | 決定論的保証。モデルによって異議を唱えられない |
| 常に有効なブランチネーミング規則 | CLAUDE.md | 条件付きではない。各セッションで必須 |
| ファイル書き込み前に自動でリンターを実行 | PreToolUseで起動 | Claudeの判断ではなく、イベント発火で動作する必要がある |
リンターの例は立ち止まる価値がある。Moeedの説明はそれをきっぱり表現している。「リンターを実行する部分はスキルで、Claudeにはできる。ただ一貫性が必要なだけ。パスした場合のみコミットするという部分はフック、それは保証であってガイドラインではない。これらは組み合わさる。」
これが実践的なメンタルモデルだ。スキルとフックは同じタスクに対して異なる角度から機能することが多い。
よくある間違った選択と修正方法
いくつかのパターンが繰り返し現れる：
- 単なる知識だったものをMCPサーバーにする。スタイルガイドにClaudeが「アクセス」するためにMCPサーバーを立ち上げようとしているなら止めよう。それはスキルだ。MCPは生きているシステムへの接続性のためのもので、マークダウンドキュメントを読み込むためではない。
- 実はフックだったCLAUDE.mdルール。「rm -rfを実行するな」をCLAUDE.mdに入れるのは、モデルが技術的に回避できる提案にすぎない。PreToolUseフックでそのパターンのBashツールをブロックするのは硬い制止だ。ルールが保証される必要があるなら、それはコンテキストではなくフックに属する。
- 独自のコンテキスト予算が必要なタスク用スキル。その仕事に数十個のファイルを読み込むことが含まれるなら、トークン流出があなたのメインセッションに複合的に影響する。サブエージェントを起動しよう。焦点を絞ったプロンプトを与え、サブエージェントが仕事をして要約を返す。メインコンテキストは一貫性を保つ。
- 単に指示が必要だったものをサブエージェントにする。サブエージェントにはオーバーヘッドがある。Claudeが単にマイグレーション規則を知る必要があるだけなら、スキルを書こう。知識の問題のために隔離されたワーカーを立ち上げるな。
- 過負荷なCLAUDE.md。200行を超えると、Anthropic自身のガイダンスは重要な制約が失われると言う。参考コンテンツをスキルに移すか、パスマッチングに基づいて条件付きで読み込まれる
.claude/rules/ファイルに分割しよう。
ゼロから Claude Code ワークフローを構築していて構造化されたスタートポイントが必要なら、Claude Code ワークフローガイドは実際のリポジトリ設定のためにこれらのレイヤーをどのようにシーケンスするかを説明している。
関連する実装ガイドに従う
正しいメカニズムを特定したら、実装パスはきっぱり分かれる。このポストはナビゲーションと比較層であり、セットアップチュートリアルではない。メカニズム別に次はここへ：
- フック設定：Claude Code フックガイドはライフサイクルイベント、ハンドラータイプ、そして決定論的に実行されるシェルおよびHTTPハンドラーを書く方法をカバーしている。
- サブエージェント：Claude Code サブエージェントガイドはサブエージェントへの指示方法、ツール権限のスコープ、そしてペアレントセッションで結果を処理する方法を説明している。
- MCP サーバー：本番スタック向けにMCPサーバーを構築または統合する場合、MCP サーバー本番ガイドはサーバータイプ、トランスポート、および信頼性パターンをカバーしている。
- スキル：公式スキルドキュメンテーションから始めよう。SKILL.md構造、フロントマター説明、そしてカスタムコマンドがスキルファイルにどのようにマップするかをカバーしている。
4つ全部を同時に読もうとしないでください。どのメカニズムを選ぶか決める前に読むと、2行で済むスキルが必要なのに、フック設定に3時間も費やすことになります。
FAQ
CLAUDE.mdはこの判断に含めるべきメカニズムですか？
はい、ただし異なる判断です。CLAUDE.mdはタスク実行時に選択されません。毎セッション自動的に読み込まれます。CLAUDE.mdに対する問いは「Claudeはこの情報を無条件で毎回必要とするか？」です。イエスなら、そこに置いてください。その指示が特定のタスクにのみ該当する場合は、具体的なフロントマター説明を持つスキルに属します。
スキルはMCPサーバーの呼び出しをトリガーできますか？
はい。スキルはワークフローの一部として、利用可能なMCPツールを使用するようClaudeに指示できます。スキルが「どのように実行するか」（何を求めるか、どの順序で、どのようなフォーマット期待で）を提供し、MCPサーバーがアクセスを提供します。競合ではなく補完的です。
サブエージェントとエージェントチームの違いは何ですか？
サブエージェントは、限定的なサブタスク処理のためにメインセッションからディスパッチするワーカーです。エージェントチームは、相互に直接通信でき、本当の並列協調作業に適したピアセッションの集合です。ほとんどのリポジトリタスクにはサブエージェントが適切です。エージェントチームは、複数の独立したワークストリームが単一セッションの委譲ではなく調整する必要があるときに有効です。
フックはClaudeのコンテキストにアクセスできますか？
いいえ。それが狙いです。フックはClaudeのコンテキスト外で実行され、モデルはそれらをオーバーライドできません。これにより、セキュリティチェック、必須のリント実行、ブロック対象ファイルパターンなどの厳密な保証に適したツールになります。トレードオフとして、フックはClaudeがタスクについて理解していることに基づいて微妙な判断を下せません。イベント上で発火してハンドラーを実行します。
4つのメカニズムすべてを一緒に使用するのが理にかなうのはいつですか？
複数の異なる障害モードを持つワークフローがある場合：知識ギャップ（スキル）、接続要件（MCP）、コンテキストブリード（サブエージェント）、モデルの判断に関わらず保証される必要がある少なくとも1つのアクション（フック）。ほとんどの単純なタスクには1つまたは2つのメカニズムが必要です。毎回すべて4つに手を伸ばすと、利益なしのオーバーヘッドが加わります。
この全体的な比較における最も鋭い区別：スキルはClaudeが読んで従う提案です。フックはClaudeが同意するかどうかに関わらず、ハーネスが強制するルールです。この1つを誤ると、「安全ルール」は単なる丁寧なリクエストになります。