3つの拡張機構は何が違うのか
Claude Codeには2026年現在、Skills・Hooks・Subagentsという3つの拡張機構が存在する。これらはしばしば混同されるが、設計思想と責務が明確に異なる。Skillsは「手続き知識のオンデマンド注入」、Hooksは「ライフサイクルイベントへの外部プロセス介入」、Subagentsは「独立コンテキストを持つ自律ワーカー」である。
混乱の原因は、いずれも「Claudeの挙動を変える」という点では共通することだ。しかし誰が、いつ、何のコンテキストで動くかが全く違う。この区別が曖昧なまま設計すると、Hookに詰め込みすぎてデバッグ不能になったり、Subagentで済む処理をSkillで無理やり表現したりする失敗に陥る。
Skills: 必要なときだけ引き出される専門知識
Skillsは .claude/skills/<name>/SKILL.md というMarkdownファイルで定義される。ファイル冒頭のYAMLフロントマターに name と description を書き、本文に手順を記述する。Claudeは対話中にユーザー意図を解析し、descriptionに合致するSkillを自動で読み込む。重要なのは「常駐しない」点で、システムプロンプトには名前とdescriptionだけが載り、本文はトリガー時に初めてコンテキストに注入される。
この遅延読み込み設計のおかげで、100個のSkillsを持っていてもコンテキストは汚染されない。手続きが冗長なもの、特定ドメインでしか使わないもの、稀に参照する規約集などに最適だ。弊社KGA ITでは「Rails7アップグレード手順」「GDPR削除要請対応」「PCI-DSSログ監査」といった「滅多に使わないが使うときは厳密に」な知識をすべてSkills化している。
Skillsが苦手なのは「毎回実行したい自動処理」である。ユーザーがトリガーしないと動かないため、gitコミット前の自動フォーマットのようなユースケースには向かない。これはHooksの領域である。
Hooks: 決定論的な外部プロセス介入
Hooksは .claude/settings.json の hooks セクションに登録される、特定イベントで起動する外部コマンドだ。イベントはPreToolUse、PostToolUse、UserPromptSubmit、Stop、SessionStart、Notificationなどで、matcher（ツール名の正規表現）とcommand（実行シェル）の組で定義する。重要な点として、HooksはClaudeの意思と無関係に、ハーネスが決定論的に実行する。
典型例はPreToolUseで走るlintチェックや、PostToolUseでのテスト自動実行、Stopフックでの未完了TODO検査である。決定論的なので、セキュリティやコンプライアンス用途に最適だ。「Edit後は必ずtrivyを走らせる」「git commit前には必ずsecret scannerを通す」といった規約の強制はHooksでしか実現できない。
反面、Hooksは「賢い判断」ができない。shell実行結果のexit codeとstdout/stderrで合否を返すだけで、複雑な文脈判断を伴う処理には不向きだ。そこで登場するのが「HookからSkillを起動する」複合パターンである。
Subagents: 独立コンテキストを持つ自律ワーカー
Subagentsは親Claudeから起動される、独立したコンテキストウィンドウを持つサブプロセスである。Task toolや@-mention構文（@researcher 〇〇を調べて）で呼び出され、結果テキストだけが親に返る。これは単なる並列化ではなく「コンテキスト分離」が本質的価値だ。
長尺の調査タスク、大量ファイルのgrep横断、複数候補のコード生成比較など、親のコンテキストを汚染したくない処理に最適である。例えば「このモノリポの認証実装を全部洗い出して」と頼むと、親コンテキストに数万トークンのコードが流入してしまうが、Subagentに委譲すれば要約だけが返る。
- 年時点で人気のSubagent定義集はwshobson/agentsで、code-reviewer、security-auditor、debugger、data-scientistなど30種類以上のプロフェッショナル人格が含まれる。各Subagentは専用のシステムプロンプトと許可ツールセットを持ち、親とは独立して振る舞う。
決定マトリクス
| 条件 | Skills | Hooks | Subagents | |---|---|---|---| | トリガー | Claudeが判断 | ハーネスが決定論的に | 親Claudeが明示委譲 | | コンテキスト | 親に注入 | 分離（shell） | 完全分離 | | 戻り値 | 手順テキスト | exit code + stdout | 要約テキスト | | 適した用途 | 手続き知識・規約 | 強制実行・検査 | 長尺調査・並列処理 | | 不適な用途 | 毎回必須の処理 | 判断を伴う処理 | 小さな即応処理 | | デバッグ難度 | 低 | 中 | 高 | | トークン効率 | 高 | 最高 | 高（要約で圧縮） |
複合パターン: pre-commit × security-review
最も強力なのはHookとSkillの組み合わせだ。PreToolUseでBashツールのgit commit matcherを登録し、claude -p "/security-review" を呼ぶ。security-reviewスキル自体はMarkdownで手順が書かれているだけだが、Hook経由で強制起動することで「コミット前に必ずセキュリティレビューが走る」規約が成立する。
弊社フェニックス・ソーシャル案件では、このパターンで本番デプロイ前に必ず143テスト + CSPチェック + UploadGuard検査を走らせている。Skillsだけでは「ユーザーが呼ばないと動かない」、Hooksだけでは「複雑な判断ができない」という双方の弱点を相互補完する設計だ。
複合パターン: リサーチSubagent + ドメインSkill
調査系タスクでは、Subagentを起動しつつ、そのSubagentに特定Skillを持たせる構成が有効である。例えばlegal-researcher Subagentに「日本個人情報保護法対応」Skillを付与し、親Claudeが長文の法務質問を丸ごと委譲する。返ってくるのは3段落の要約で、親コンテキストは無傷のまま高品質な回答が得られる。
- 年4月のAnthropic公式ブログでも、この「Subagent + Skill」構成が推奨アーキテクチャとして紹介されており、今後のClaude Code拡張の主流パターンになりつつある。
選択の指針
迷ったときの判断基準はシンプルだ。「毎回走らせたいか？」がYesならHook、「Claudeに判断させたいか？」がYesでコンテキスト節約が重要ならSubagent、それ以外の手続き知識や規約はSkill。この順で考えれば8割の設計判断は正解に辿り着く。残り2割は複合パターンで解く、というのが実務での鉄則である。