図解
はじめに
Claude Code の拡張機構が、選べないほど増えました。
CLAUDE.md、Skills、MCP、サブエージェント、Hooks、Plugins。名前は聞いたことがあっても、どれをいつ使うのかで迷って、結局 CLAUDE.md に全部書いている。そういう状態の人は多いと思います。
2025年12月に、こういう記事が出ていました。
2025年12月版: MCP、Subagent、Skills… エージェント拡張技術が次々出てきて追いきれない人のためのガイド
— @jugyo（246 LGTM）
タイトルが当時の空気をよく表しています。そしてその後の8ヶ月で、さらに増えました。
公式ドキュメントは、拡張機構をこう位置づけています。
Extensions plug into different parts of the agentic loop.
（拡張機構は、エージェントのループのそれぞれ違う場所に差し込まれる）
差し込まれる場所が違う。だから並べて比べても選べません。
この図の横から刺さっている矢印が、それぞれ違う段に入っているのが分かります。同じ土俵に並んでいないものを、比べようとしていたわけです。
この記事では、2026年8月時点で公式が挙げている拡張機構を並べ直し、選ぶ基準を1つに絞って整理します。結論を先に言うと、基準は「いつ読まれるか」だけです。機能の多さではありません。
この記事で扱うこと
- いま公式が挙げている拡張機構9つ
- 拡張機構だけを抜き出した5ヶ月の時系列
- コンテキストコストという唯一の選択基準
- 「毎回」と「たまに」の間にある第3の選択肢
- 「お願い」と「強制」の区別
- 道具の並びが意味しているもの
🗺️ いま何があるのか — 公式が挙げる9つ
まず、いま何が存在するのかを確認します。名前だけでも把握しておくと、記事を読む速度が変わります。
公式ドキュメントの Extend Claude Code が挙げている拡張機構を、そのまま並べます。
この図の縦の並びが、そのまま「何を足したいのか」の分類になっています。文脈を足すのか、外とつなぐのか、仕事を分けるのか、自動で効かせるのか、配るのか。
9つのうち、公式が特別扱いしている機構が1つあります。
Skills are the most flexible extension. A skill is a markdown file containing knowledge, workflows, or instructions.
（Skills は最も柔軟な拡張である。スキルとは、知識・ワークフロー・指示を書いたマークダウンファイルである）
マークダウン1枚に知識でも手順でも書けて、/名前 で呼び出せるうえ、Claude が自動で読み込むこともできる。迷ったら Skills と覚えておいて、ほぼ外しません。
Plugins だけ役割が違う
そして Plugins は、他の8つと役割が違います。
A plugin bundles skills, hooks, subagents, and MCP servers into a single installable unit.
（プラグインは、スキル・フック・サブエージェント・MCPサーバーを、インストール可能な1つの単位に束ねる）
Plugins は機能ではなく、包装です。 同じ設定を複数のリポジトリで使い回したいとき、あるいは他人に配りたいときに初めて必要になります。
📈 なぜ追いきれないのか — 拡張機構だけの時系列
9つという数だけ見ると、覚えられそうに思えます。問題は数ではなく速度でした。
公式の What's new から、拡張機構に関わるものだけを抜き出します。機能追加は他にも多数ありますが、それを混ぜると話がぼやけるので外しました。
| 週 | 拡張機構に起きたこと |
|---|---|
| Week 13（3/23） | 条件付き if フック（Hooks の表現力が上がる） |
| Week 22（5/25） | Dynamic workflows 登場 |
| Week 25（6/15） | Artifacts 登場 |
| Week 27（6/29） | サブエージェントが既定で背景実行に |
| Week 32（8/3） | Cross-session messaging 登場 |
この図の橙3つが新しく増えた機構で、青1つは既存機構の中身が変わった地点です。
太字の3つは、2025年12月時点では存在しなかった機構です。あの記事が「追いきれない」と書いた3つ（MCP・Subagent・Skills）に、その後さらに積み上がっています。
そして残りの2行は、新機構ではなく既存機構の性質が変わったものです。フックに条件分岐が入り、サブエージェントの既定動作が変わった。新しく覚え直す対象は、増えた数より多いことになります。
ここで大事なのは、増えた数ではありません。増える速度が落ちる気配がないことです。たとえば8月に入った Cross-session messaging は、こういう機能です。
your Claude Code sessions can now message each other, so Claude passes a finding or a decision from one session to another instead of you re-explaining it
（セッション同士がメッセージを送り合えるようになった。あなたが説明し直す代わりに、Claude が発見や判断を別のセッションへ渡す）
去年の時点では、そもそも「複数セッションを同時に走らせる」という前提がありませんでした。土台のほうが動いているわけです。
なお、この5行の外側では、Auto mode・Computer use・Routines・iOS Simulator ペインといった機能追加が並行して入っています。拡張機構だけに絞ってもこの速度、という読み方をしてください。
だから「全部覚える」という戦略は最初から成立しません。覚えるのをやめて、選ぶ基準を1つ持つ。それが現実的な対処になります。
⚖️ 選ぶ基準は「いつ読まれるか」
公式ドキュメントに、機能比較とは別の表があります。コンテキストコストの表です。ここが選択の実質的な基準になります。
| 機構 | 読み込まれるタイミング | コンテキストコスト |
|---|---|---|
| CLAUDE.md | セッション開始 | 毎リクエスト |
| Skills | 開始時に説明文、使用時に本文 | 低 |
| MCP | 開始時にツール名のみ | 低 |
| Code intelligence | 編集後・参照時 | 低（ファイル読みを減らす） |
| Subagents | 起動時 | 本体から隔離 |
| Hooks | イベント発火時 | ゼロ（出力を返さない限り） |
この図で赤くなっている経路が1つだけあります。CLAUDE.md だけが、使っても使わなくても毎回コストを払います。
200行という閾値
だから公式はこう釘を刺しています。
Keep CLAUDE.md under 200 lines. If it's growing, move reference content to skills or split into
.claude/rules/files.（CLAUDE.md は200行以内に保つこと。膨らんできたら、参照用の内容は Skills に移すか、
.claude/rules/に分割する）
200行。 これが具体的な閾値です。手元の CLAUDE.md がこれを超えているなら、超えている分は移せる可能性が高いということになります。
ここで、引用文の後半に見慣れない言葉が入っていることに気づいたでしょうか。.claude/rules/ です。
第3の選択肢 — .claude/rules/
「毎回必要なら CLAUDE.md、たまになら Skills」。これで綺麗に分かれるように見えますが、実際に手元の CLAUDE.md を開くと、どちらとも言い切れない行が出てきます。
たとえば、こういうケースです。TypeScript と Python を1つのリポジトリで扱っていて、CLAUDE.md に両方のコーディング規約を書いている。TypeScript のファイルだけを触っている間も、Python の規約が毎リクエスト読まれ続けます。
「毎回必要」ではない。かといって、規約は Claude に自動で守ってほしいので、呼び出し式の Skills でもない。この中間に、第3の選択肢があります。
Use rules to keep CLAUDE.md focused. Rules with
pathsfrontmatter only load when Claude works with matching files, saving context.（CLAUDE.md を絞った状態に保つには rules を使う。
pathsフロントマターを持つ rules は、Claude がマッチするファイルを扱うときにだけ読み込まれ、コンテキストを節約する）
.claude/rules/ に置いたファイルに paths を書くと、そのパスに触ったときだけ読まれます。TypeScript の規約は .ts を触ったときだけ、Python の規約は .py を触ったときだけ。
この図の真ん中が、これまで見落とされがちだった段です。「常に」と「必要なときだけ」の間に、「関係するときだけ」がある。
公式は3つをこう整理しています。
| CLAUDE.md | .claude/rules/ |
Skills | |
|---|---|---|---|
| いつ読まれるか | 毎セッション | 毎セッション、またはマッチするファイルを開いたとき | 呼び出したとき、または関連するとき |
| 範囲 | プロジェクト全体 | ファイルパスで絞れる | タスク単位 |
| 向いているもの | 中核の規約とビルドコマンド | 言語別・ディレクトリ別の指針 | 参照資料、繰り返す手順 |
言語別・ディレクトリ別の指針は rules へ。この1行だけでも、CLAUDE.md はかなり痩せます。
Skills のコストを下げる2つの逃げ道
Skills にも、さらにコストを下げる仕組みが2つあります。どちらも「いつ読まれるか」を操作するものです。
1つ目は、説明文すら読ませない指定です。
Set
disable-model-invocation: truein a skill's frontmatter to hide it from Claude entirely until you invoke it manually.（スキルのフロントマターに
disable-model-invocation: trueを書くと、手動で呼び出すまで Claude からは完全に隠れる）
既定では、Skills は説明文だけが毎リクエスト読まれます。数が増えるとこれも積み上がります。自分でしか呼ばないスキルなら、この1行でコストがゼロになります。 公式は、副作用のあるスキルにこれを推奨しています。
2つ目は、隔離した文脈で走らせる指定です。スキルのフロントマターに context: fork を書くと、本体の会話とは別の文脈で実行され、結果だけが返ります。長い出力を出すスキルで効きます。
判断そのものは単純です。毎回必要か、関係するときだけか、たまに必要か。 そのうえで公式は、追加するタイミングを「きっかけ」で示しています。この表が実務では一番使えます。
| きっかけ | 足すもの |
|---|---|
| Claude が同じ規約を2回間違えた | CLAUDE.md |
| 同じプロンプトを毎回打っている | 呼び出せる Skill |
| 同じ手順書を3回目チャットに貼った | Skill |
| ブラウザからデータをコピーし続けている | MCP サーバー |
| 定義や参照を探して大量のファイルを読んでいる | code intelligence プラグイン |
| 脇の作業で会話が出力に埋まる | サブエージェント |
| 頼まなくても毎回やってほしい | Hook |
| 2つ目のリポジトリで同じ設定が要る | Plugin |
2回間違えたら CLAUDE.md、3回貼ったら Skill。 回数で決められるのが良いところです。
🔒 お願いと強制 — Hook と Skill の決定的な違い
ここが、この記事で一番書きたかった部分です。
CLAUDE.md に「.env は絶対に編集するな」と書く。よくある対処ですが、公式はそれを明確に否定しています。
An instruction like "never edit
.env" in CLAUDE.md or a skill is a request, not a guarantee. APreToolUsehook that blocks the edit is enforcement.（CLAUDE.md やスキルに書いた「
.envを編集するな」という指示はお願いであって、保証ではない。編集をブロックするPreToolUseフックが強制である）
この図の分岐が、Hook と Skill を分ける唯一の質問です。ばらついていいのか、ばらついては困るのか。
たとえば、こういうケースがあります。CLAUDE.md に「本番の DB には触るな」と書いてある。ほとんどの場合は守られます。ですが「ほとんど」で困る種類のルールなら、そもそも置き場所が間違っていることになります。
フックの出力は、そのまま会話に戻ってきます。
Hook output lands in context. A
PostToolUsehook that runs your linter feeds results back as text Claude reads; a/fix-lintskill tells Claude how to resolve them.（フックの出力はコンテキストに着地する。リンタを走らせる
PostToolUseフックは結果を Claude が読むテキストとして返し、/fix-lintスキルはその直し方を Claude に伝える）
つまり Hook は、止めるだけの仕組みではありません。結果を Claude に読ませる入口にもなります。そしてこの引用が示しているとおり、Hook と Skill は組み合わせて使うものでもあります。検知は Hook、直し方は Skill。
この図の緑と橙の役割分担が、「必ず動く部分」と「考えてほしい部分」の切れ目です。
公式の比較表でも、この違いは「決定性（Determinism）」として整理されています。
| Hook | Skill | |
|---|---|---|
| 何が動くか | シェルコマンド・HTTPリクエスト・MCPツール呼び出し・プロンプト・サブエージェント | Claude が読んで従う指示 |
| 何で起動するか |
PostToolUse などのライフサイクルイベント |
/名前 の入力、または説明文との一致 |
| 決定性 | 必ず発火する。トリガーが保証される | Claude が解釈する。結果はばらつく |
| コンテキストコスト | 出力を返さない限りゼロ | 説明文が毎回、本文は使用時 |
ガードレールは Hook に置く
つまり、ガードレールは Hook に置く。これが結論になります。「絶対に」「必ず」と書きたくなったら、それは CLAUDE.md ではなく Hook に書くべきサインです。
逆に、Claude に考えてほしいことは Skill に書きます。リリース手順のチェックリスト、API のスタイルガイド、デバッグの進め方。判断が要るものは、判断できる場所に置く。
🪜 道具の並びは、関心が上流へ移動する階段だった
ここまで9つを見てきて、気づいたことがあります。
この並びは、機能の一覧ではありません。エンジニアの関心が上流へ移動していく階段です。
この図の右へ進むほど、書いているものが「指示」から「仕組み」に変わります。
CLAUDE.md を書いているとき、やっていることはプロンプトの延長です。「こう書いてほしい」を伝えている。ですが Skills とサブエージェントを使い始めると、やっていることが変わります。
Subagents run their own loops in isolated context, returning summaries.
（サブエージェントは隔離された文脈で自分のループを回し、要約を返す）
仕事を分解して、どれを誰に渡すかを決めている。 これは設計です。
Hooks と Workflows まで来ると、さらに変わります。
Dynamic workflows run many subagents from a script Claude writes, returning one result.
（動的ワークフローは、Claude が書いたスクリプトから多数のサブエージェントを走らせ、1つの結果を返す）
何が起きても壊れないように、保証と検証を先に置いている。 これはアーキテクチャの仕事です。
どの段にいるかが分かる
だから「どの拡張機構を使っているか」は、その人がいまどの高さで考えているかをかなり正確に表しています。道具を増やす話ではなく、関心の置き場所を上げる話だったわけです。
追いきれないと感じたときは、全部を追わなくていい。いま自分がいる段の1つ上に何があるかだけ見ればいい。
📝 まとめ
拡張機構は9つあり、まだ増えます。全部を覚える戦略は成立しません。
代わりに、基準を2つだけ持っておけば足ります。1つ目。いつ読まれてほしいか。 常になら CLAUDE.md、関係するファイルを触ったときだけなら .claude/rules/、必要になったときだけなら Skills。CLAUDE.md は200行を超えたら移す。
2つ目。ばらついていいのか、困るのか。 困るなら Hook。「絶対に」と書きたくなった時点で、それは指示ではなく強制の対象です。
この図の2つの分岐だけで、大半の選択は決まります。機構の数を覚える必要はありません。
この記事を読んでまず試すことは、手元の CLAUDE.md の行数を数えることをおすすめします。200行を超えていたら、超えた分を3つに仕分けてみてください。全ファイルで要るもの、特定の言語やディレクトリでだけ要るもの、たまにしか要らないもの。2つ目が .claude/rules/、3つ目が Skills に移せる部分です。
道具はこれからも増えます。ただ、増えるたびに階段が1段伸びているだけだと分かっていれば、落ち着いて読めるはずです。
📚 参考
公式ドキュメント（すべて2026年8月28日に確認）
- Extend Claude Code — 9機構の一覧、比較表、コンテキストコスト表、Hook と Skill の違い、CLAUDE.md / rules / Skills の3分類。この記事の主要な出典
- What's new — Week 13〜34 の週次まとめ。時系列はここから
- Claude Code Documentation index — 機械可読な全ページ索引
先行する整理記事
- 2025年12月版: MCP、Subagent、Skills… エージェント拡張技術が次々出てきて追いきれない人のためのガイド — @jugyo。この記事の出発点
- 役割が混在してきたので「CLAUDE.md / サブエージェント / スラッシュコマンド / エージェントスキル」を改めてまとめてみた — @fujisho1216
💡 この記事について
本記事は2026年8月28日時点の公式ドキュメントをもとにまとめています。内容は公開情報の整理であり、本文中の「こういうケース」は実在の案件ではなく、判断の分かれ目を示すための想定例です。公式ドキュメントの URL は
docs.claude.com/en/docs/claude-code/*からcode.claude.com/docs/en/*へ301リダイレクトされます。本文中のリンクはすべて移転後のものです。「9つ」という数は
features-overviewの Overview 節の記載に従っています。同ページの別表に載っている Artifacts は、Overview の箇条書きに含まれていないため9つの外に置きました。分類の切り方によって数は変わります。時系列の表は、公式の What's new から拡張機構に関わるものだけを抜き出したものです。同期間には他にも多数の機能追加があります。
「関心が上流へ移動する階段」という読み方は筆者の解釈であり、公式ドキュメントにその記述はありません。
道具が増えるたびに、エンジニアの関心は一段上へ動いていきます。
上流はさらに上へ。下流は上流へ。その一段ごとに何が変わるのかを、書いていきます。