背景

この連載では、Claude Codeの公式ドキュメントを1ページずつ読み解いていきます。公式ドキュメントは情報が網羅されている分、「結局どの機能を、どんな場面で使えばいいのか」は自分で考える必要があり、読むのに意外と時間がかかります。そこで、私が実務で使うために読み込んだ内容を「使う場面→実例コード」の順に整理して残していくことにしました。専門家の解説というより、一次情報を読んだ記録です。推測や動作を確認していない部分には、その都度そう書きます。

1. これは一言でいうと何か

Claude Code は、コードについて推論するモデルと、ファイル操作・検索・実行・ウェブアクセスの組み込みツールを組み合わせたものです。公式ドキュメントによれば、組み込みツールだけでほとんどのコーディングタスクはカバーできます。このページが扱うのはその上に足す「拡張レイヤー」——Claude が何を知るかをカスタマイズし、外部サービスに接続し、ワークフローを自動化するための機能群です。

用語を先に押さえます（いずれも初出）。

• CLAUDE.md：すべての会話で読み込まれる永続的なコンテキスト。プロジェクト規約や「常に X を実行する」ルールを置きます。
• Skill：知識・ワークフロー・指示を含むマークダウンファイル。/deploy のようなコマンドで呼び出すか、関連する場合に Claude が自動でロードします。拡張機能の中で最も柔軟だとされています。
• Subagent：独立したコンテキストで独自のループを実行し、サマリーだけを返すワーカー。
• MCP：Claude を外部サービスやツールに接続するプロトコル。
• Hook：ライフサイクルイベントで発火し、スクリプト・HTTP リクエスト・プロンプト・subagent を実行できる仕組み。
• Plugin：上記をひとつのインストール可能な単位にまとめて配布するパッケージングレイヤー。

2. どういう場面で役立つか

このページの要点は「最初から全部そろえるな」です。各機能には認識可能なトリガーがあり、それが起きてから足す——という順序が示されています。具体的には次のような場面です。

• レビュー指摘や規約違反が繰り返されるとき：Claude が規約やコマンドを 2 回間違えたら、CLAUDE.md に追記します。例として挙げられているのは「pnpm を使用し、npm は使用しない。コミット前にテストを実行する。」といったルールです。チャットでその都度直すか、CLAUDE.md の編集にするかが分かれ目です。
• 同じ手順を何度も貼り付けているとき：同じプロンプトを繰り返し入力している、あるいは同じプレイブックをチャットに 3 回目に貼っているなら、それは Skill にします。デプロイメントチェックリストを走らせる /deploy が例です。
• 複数リポジトリに同じ環境を横展開したいとき：2 番目のリポジトリが同じセットアップを必要とし始めたら、plugin としてパッケージ化します。プラグインのスキルは /my-plugin:review のように名前空間化され、複数のプラグインが共存できます。
• Claude に見えないデータを手で運んでいるとき：ブラウザタブからデータをコピーし続けているなら、そのシステムを MCP サーバーとして接続します。
• 毎回確認なしで実行してほしいことがあるとき：すべてのファイル編集後に ESLint を走らせる、といった自動化は hook です。

逆に向かないケース・不要なケース：拡張機能を「とりあえず入れておく」ことです。追加する各機能は Claude のコンテキストを消費し、多すぎるとコンテキストウィンドウが埋まるだけでなく、Claude の効果を下げるノイズになるとページは明記しています。スキルが正しくトリガーされない、Claude が規約を見失う、といった劣化が起きます。初めてなら CLAUDE.md から始め、他はトリガーが発生してから追加するのが公式の推奨です。

3. 機能の選び分け

このページは実行例ではなく比較表で構成されています。混同しやすい対比のうち、実務で判断が必要になる 4 つを取り上げます。

CLAUDE.md か Skill か。 違いはロードのタイミングです。CLAUDE.md はすべてのセッションで自動的に読み込まれ、Skill はオンデマンドです。ワークフローをトリガーできるのは Skill だけ（/<name> で呼び出す）で、CLAUDE.md にはできません。Claude が常に知っておくべきこと（コーディング規約、ビルドコマンド、「X を実行しない」ルール）は CLAUDE.md、時々必要なリファレンス（API ドキュメント、スタイルガイド）や呼び出すワークフローは Skill です。経験則として、CLAUDE.md は 200 行以下に保ち、増えてきたらリファレンスをスキルに移すか .claude/rules/ に分割することが挙げられています。

Skill か Subagent か。 Skill は「再利用可能なコンテンツ」、Subagent は「独立して走るワーカー」です。Skill はメインのコンテキストウィンドウに加算されますが、Subagent は別のウィンドウを使い、サマリーだけを返します。多数のファイルを読むが主要な結果しか要らない調査タスクや並列作業に向きます。コンテキストが埋まってきたときの逃がし先だと考えてください。

Hook か Skill か。 ここは決定論性の差です。CLAUDE.md やスキルに書いた「.env を編集しない」という指示はリクエストであって保証ではない、とページははっきり書いています。対して、編集をブロックする PreToolUse フックは強制です。毎回必ず守られる必要があるルール——ガードレール——は、プロンプト指示ではなくフックに置きます。

MCP か Skill か。 これは二者択一ではなく組み合わせです。MCP がなければ Claude はデータベースをクエリしたり Slack に投稿したりできません。一方スキルは、そのツールを効果的に使う方法（スキーマ、クエリパターン、投稿フォーマット）を Claude に与えます。MCP が接続を、スキルが使い方を担当します。

コンテキストコストの目安も表になっています。CLAUDE.md は全文がすべてのリクエストに乗り続けます。Skills は開始時に説明だけ、使用時に全文（低コスト）。MCP サーバーはツール名のみで、完全なスキーマはオンデマンド。Hooks は外部で実行されるためゼロ（出力を返さない限り）。常時オンで最も高くつくのが CLAUDE.md だという点は、覚えておく価値があります。

4. まとめと次回予告

• 組み込みツールでほとんどのタスクは足ります。拡張はトリガーが起きてから足すもので、事前に全部そろえる必要はありません。
• 選び分けの軸は「いつロードされるか」と「保証されるか」。常時必要なら CLAUDE.md、時々なら Skill、必ず守らせたいなら Hook、外部接続が要るなら MCP です。
• 拡張はタダではありません。コンテキストを食い、多すぎればノイズになります。

次回予告：拡張の出発点である CLAUDE.md を扱う「メモリ」ページを取り上げます。

関連ページ（本記事で触れた概念の詳細）：agentic ループ →「Claude Code の仕組み」、CLAUDE.md・.claude/rules/ →「メモリ」、Skill →「Skills」、Subagent →「サブエージェント」、Agent teams（実験的機能。デフォルトで無効）→「Agent teams」、MCP →「MCP」、Hook →「Hooks」、Plugin と配布 →「Plugins」「Marketplaces」、コンテキスト消費の内訳 →「コンテキストウィンドウ」。

---

本記事は執筆時点の公式ドキュメント（Claude Code を拡張する）に基づきます。最新の情報は公式ドキュメントをご確認ください。