Claude Code の Skill / Subagent / Hook / Plugin、結局何が違うの？— 自作して分かった4つの拡張ポイントの使い分け

「Claude Code を自分用に育てたい。でも `.claude/` フォルダの中身が増えてきて、何を `skills/` に置いて、何を `agents/` に置いて、何を `hooks` で動かすのか、毎回迷う。」

これは2026年5月時点の Claude Code 中級者の共通の悩みです。
公式ドキュメントは整っているのですが、それぞれを別ページで読むので「全体の中での位置づけ」が見えにくい。
結果、Skill にも書けるし Subagent にも書ける、どっちでも動く、というケースで判断に時間がかかります。

私自身、AIエコシステムの管理運用で4つ全部を自作してきて、ようやく「これはこっち、あれはあっち」と判断できる軸が見えてきました。
この記事では、その使い分けの軸を整理します。

結論を先に言うと、選び方は「文脈をどこに置くか」と「いつ動くか」の2軸で決まります。
ここを掴めば、4つの拡張ポイントは一気に整理されます。

1. 4つの拡張ポイントの全体像

Claude Code を拡張するには、現時点で4つの主な手段があります。

• Skill — Claude の手元に置く「手順書つき知識」。スラッシュコマンドで呼び出すと、メインの会話に内容が読み込まれる

• Subagent — 専用の別 Claude に分離した文脈で任せる「下請け」。本体の会話を汚さずに作業させる

• Hook — 決まったタイミングで自動実行されるシェルコマンド。Claude の判断に関係なく機械的に動く

• Plugin — 上記をまとめて他人に配布できる「箱」。1つの Plugin が複数の Skill / Subagent / Hook を内包できる

ここで重要なのは、Plugin は配布の箱であって、Skill や Subagent と並ぶ選択肢ではないということです。
「Plugin を使う」というのは「他の誰かが作った Skill / Subagent / Hook を一括で取り込む」という意味になります。

公式の OpenAI Codex 連携プラグイン `codex-plugin-cc` が分かりやすい例で、これを入れると `/codex:review` 等の 7つの Skill 相当の機能 + Subagent + Hook が一括で導入されます。

2. それぞれの本質を1行で

軸を理解するために、4つを「動くタイミング」と「文脈の置き場所」で並べます。

Skill: 「メインの会話に手順書を持ち込む」

• スラッシュコマンドで呼び出した瞬間、その内容がメインの文脈に読み込まれる

• Claude は手順書を見ながら作業する

• 文脈は共有（メイン会話と一緒）

Subagent: 「専用の下請けに別文脈で任せる」

• 別の Claude インスタンスが、独立した文脈で作業する

• メイン会話には結果サマリだけ返ってくる

• 文脈は分離（メインと別）

Hook: 「ある瞬間を捕まえて機械的に動かす」

• Claude がツールを使う前後など、決まった瞬間にシェルコマンドが走る

• Claude の判断は介在しない、確定的な実行

• タイミング駆動

Plugin: 「上の3つを束ねて配る」

• 自分の作った Skill / Subagent / Hook を `.zip` や Git リポジトリで配布できる

• 他人の Plugin を取り込むこともできる

• 配布の単位

3. 使い分けの判断基準（実用フロー）

次の質問に順番に答えると、どれを使うべきか決まります。

Q1: メインの会話の文脈を汚したくない？

• Yes → Subagent

  • 例: 大量のログ調査、長文ドキュメント要約、複数ファイル横断のリファクタリング下調べ

  • 終わった後に「結論だけ」返ってくるので本体の会話がすっきりする

• No → Q2へ

Q2: 自分が指示して動かしたい？（明示的な呼び出し）

• Yes → Skill

  • 例: 記事執筆のフロー、コードレビューのチェックリスト、特定タスク用の指示書

  • スラッシュコマンドで呼んだ時だけ動く

• No → Q3へ

Q3: 決まったタイミングで自動的に動かしたい？（Claude の判断に依存させたくない）

• Yes → Hook

  • 例: ファイル保存時にフォーマッタを走らせる、コミット前に lint をかける、Claude の応答完了時に通知する

  • 機械的なので、Claude が「忘れた」場合でも確実に動く

• No → そもそも拡張する必要があるか再考

Q4: これを他人にも使ってもらいたい？配布したい？

• Yes → Plugin にまとめる

  • 1つの Plugin に複数の Skill / Subagent / Hook を入れて配布

つまり、ほとんどのケースで答えは「Skill か Subagent」になります。
Hook は「機械的な強制」が要る時だけ、Plugin は「配布する時だけ」というのが実態です。

4. 実体験ベースの使い分け例

私が運用しているAIエコシステムで、実際にどう使い分けているかを共有します。
名前は伏せて構造だけ書きますが、参考になるはずです。

Skill にしているもの

• 記事執筆フロー — テーマ選定から保存までの10フェーズが書かれた手順書。`/note-write-article` で呼び出す

• 週次トレンドリサーチ — 調査カテゴリと検索クエリのテンプレが入った手順書。`/trend-research` で呼び出す

• AIモデル別の質問 — 別AI（Codex や Gemini）への質問テンプレ。スラッシュコマンドで使う

→ 共通点: 「自分が能動的に呼び出して、メインの会話の中で進めたい作業」。手順書を見ながら段階的に進める用途。

Subagent にしているもの

• Web検索の大量実行 — 1回の作業で20件くらいページを読み込ませる必要がある時、メインの会話を汚したくないので別文脈で

• コードベース全体の調査 — 大量のファイルを読み込んでから「ここが怪しい」と教えてもらう用途

• 過去の議論ログの要約 — 長い履歴を読み込ませて、メインには結論だけ返してもらう

→ 共通点: 「大量の中間処理が発生するが、最終的に欲しいのは結論だけ」。本体の文脈を圧迫しない用途。

Hook を入れる予定のもの（まだ運用には入れていない）

• 記事保存時にフォーマット制約（テーブル禁止、特定キーワード混入禁止）を機械チェック

• コミット前に lint と型チェック

• 特定のファイルが編集されたら通知

→ 共通点: 「私や Claude が忘れても、確実に動いてほしい守りのルール」。

Plugin として取り込んでいるもの

• `codex-plugin-cc`（OpenAI 公式）— Codex を Claude Code から呼ぶための一式

• 数個の MCP サーバー — ファイルシステム操作、Obsidian 連携など

→ 共通点: 「自分で作るより誰かが作ったものを使った方が早い領域」。

5. 「文脈どこに置くか」と「いつ動くか」で2軸整理

判断軸をまとめるとこうなります。

「文脈をどこに置くか」軸:

• メインの会話の中 → Skill

• 別の文脈で分離 → Subagent

「いつ動くか」軸:

• 自分が明示的に呼び出した時 → Skill or Subagent

• 決まったタイミングで自動 → Hook

そして「配布したいか」軸が独立して存在し、配布の単位が Plugin です。

この3軸を意識して書き出すと、迷ったときの判断が速くなります。

例えば「コードレビューのチェックリストを毎回適用したい」という要件なら:

• 文脈: メインに置いて参照しながら進めたい → Skill寄り

• いつ: 自分でレビューしたい時に呼びたい → Skillの方向で確定

• 配布: チームに配りたいなら Plugin にまとめる

逆に「ファイル保存時に必ず lint を走らせたい」なら:

• 文脈: そもそも Claude の文脈に入れる必要なし

• いつ: 保存という決まったタイミング → Hook 一択

6. 最初に自作するならどれ？

Claude Code を拡張したい人がまず作るべきは、Skill です。

理由:

• 最も作りやすい（マークダウンファイル1個でOK）

• 最も使いやすい（スラッシュコマンドで呼ぶだけ）

• 効果が分かりやすい（自分が日々使う作業を手順化できる）

最小構成はこうです。

.claude/skills/
└── my-skill/
    └── SKILL.md

`SKILL.md` の中身は次のように書きます。

---
name: my-skill
description: 何のスキルか1行で説明
user-invocable: true
---

# /my-skill — スキル名

## 概要
このスキルが何をやるか

## 使い方
`/my-skill` と入力すると、以下の手順で作業を進める

## 手順
1. ファイルAを読む
2. ファイルBを参照する
3. 結果をユーザーに提示する

これだけで `/my-skill` というスラッシュコマンドが使えるようになります。

そこから慣れてきたら、Subagent → Hook → Plugin の順に手を広げるのが自然な道筋です。

7. ハマりどころ・落とし穴

自作運用で実際にハマったポイントを共有します。

Skill に何でも詰め込みすぎる

• スキル1つに大量の手順を書きすぎると、Claude が混乱する

• 1つのスキルは「1つの目的」に絞る

• 大きい作業はフェーズで切って、それぞれを別スキルにする選択肢もある

Subagent と Skill のどっちでも書けてしまう問題

• 「文脈を汚したくないか？」で判断する

• 答えがNoなら Skill、Yesなら Subagent

• 迷ったら Skill で書いて、文脈圧迫が問題になったら Subagent に切り出す

Hook を入れすぎて開発体験が悪化

• 全ファイル保存時に Hook を走らせると、試行錯誤が窮屈になる

• Hook は「絶対に違反したくないルール」のみに絞る

• 範囲を `channels/note/articles/**/*.md` のように狭く限定する

Plugin にする前に手元で運用する

• 配布前に自分で2〜3週間使ってみる

• 使い込まないと「他人にとって使いやすいか」は分からない

• いきなり Plugin 化しない

まとめ — 拡張ポイントは「文脈」と「タイミング」で選ぶ

整理すると、4つの拡張ポイントの違いは次の通りです。

• Skill: メイン会話に手順書を読み込む。自分で呼び出す

• Subagent: 別文脈で下請けに任せる。結論だけ返ってくる

• Hook: タイミングで機械的に動く。Claude の判断は介在しない

• Plugin: 上記を束ねて配布する箱

判断軸は2つだけ覚えればOKです。

• 文脈をどこに置くか → メイン会話なら Skill、分離なら Subagent

• いつ動くか → 明示呼び出しなら Skill / Subagent、決まったタイミングなら Hook

そして、自作するならまずは Skill から。
マークダウンファイル1つで `/my-skill` というスラッシュコマンドが手に入ります。
そこからメインの会話を汚さない作業を Subagent に切り出し、絶対に違反したくないルールを Hook に固める、というのが自然な拡張順序です。

公式ドキュメントだけ読むと「Plugin と Skill はどっちを選べばいいの」と混乱しますが、Plugin は配布の単位、Skill は機能の単位と覚えれば一気にスッキリします。

次に書きたいテーマがあれば、私が運用している自作 Skill の中身を5つほど共有する続編記事も予定しています。
気になる方はフォローしておくと、続編が出たときに通知されます。

この記事が参考になったら、「スキ」を押していただけると励みになります。
Claude Code 関連の実践記事を書いていますので、フォローもぜひ！