【Claude Code】Skillsとサブエージェントの違いと使い分け

Claude CodeのSkills（スキル）とは

Skillsは、ひとことで言うとClaudeに渡す「手順書」です。

SKILL.mdというファイルにやり方やルールを書いておくと、Claudeが必要になったタイミングでその内容を読み込んで、指示に従って作業してくれます。

ポイントは、スキルの中身は必要になるまで読み込まれないことです。CLAUDE.mdは書いた内容が毎回すべて読み込まれるのに対して、スキルで毎回読み込まれるのは名前と短い説明文だけ。本文が読み込まれるのは、実際にそのスキルを使うときだけです。

そのため、長い手順書を何個ストックしても、コンテキスト（Claudeが一度の会話で扱える情報量）をほとんど消費しません。手順書を書き足すほどCLAUDE.mdが肥大化していく、という悩みを避けられる仕組みです。

スキルの呼び出し方は2通り

スキルの置き場所と最小の例

スキルは1つのフォルダにSKILL.mdを入れた形で作ります。置き場所によって使える範囲が変わります。

中身はこれだけで動きます。---で挟んだ部分（フロントマター）に説明文を書き、その下に指示を書くだけです。フォルダ名がそのまま/スキル名のコマンド名になります。

なお、以前あった「カスタムスラッシュコマンド」（.claude/commands/）は、現在はSkillsに統合されています。昔のファイルもそのまま動きますが、これから作るならスキル形式がおすすめです。

Skillsの詳しい作り方は以下の記事で解説しています。

Claude Codeのサブエージェントとは

サブエージェントは、ひとことで言うと仕事を任せられる「別の作業者」です。

メインの会話とは完全に別の作業スペース（コンテキスト）で動くのが最大の特徴です。サブエージェントは指示を受けると独立して調査や作業を進め、終わったら結果の要約だけをメインの会話に持ち帰ります。

「コンテキスト」とは、Claudeが会話中に覚えている内容のことです。大量のファイルを読むような調査をメインの会話でやると、読んだ内容が全部会話に残ってどんどん重くなります。サブエージェントに任せれば、その作業はメインの会話の外で行われるので、会話が重くならずに済みます。

サブエージェントの定義ファイル

サブエージェントは、フロントマター付きのMarkdownファイル1つで定義します。プロジェクト用は.claude/agents/、全プロジェクト共通なら~/.claude/agents/に置きます。

フロントマターで必須なのはnameとdescriptionの2つだけです。この例のようにtoolsで使えるツールを絞ったり（読み取り専用にするなど）、modelで安いモデルを指定してコストを抑えたりもできます。

呼び出し方は3通りあります。依頼内容がdescriptionに合っていれば、Claudeが判断して自動でサブエージェントに作業を振ります。「reviewerエージェントを使って、直近の変更をレビューして」のように名前を指定して頼むか、入力欄で@を入力して一覧から選ぶこともできます。

ちなみにClaude Codeには、コードベースの調査に特化したExploreなど、最初から組み込みのサブエージェントがいくつか入っています。自分で定義しなくても、実はすでにサブエージェントのお世話になっているかもしれません。

サブエージェントの詳しい作り方は以下の記事で解説しています。

Skillsとサブエージェントの違いを比較

2つの機能の違いを表にまとめました。

いちばん大きな違いは、作業がメインの会話の中で行われるか、独立したコンテキストで行われるかです。

Skillsは手順書をClaudeが読むだけなので、今までの会話の流れを引き継いだまま作業できます。一方サブエージェントは仕事を任せる仕組みなので、メインの会話を汚さない代わりに、会話の流れは引き継がれません。この違いさえ押さえれば、使い分けはほぼ迷わなくなります。

もう1つ、見落としやすい違いがあります。同じ名前の定義が個人用とプロジェクトの両方にあるときの優先順位は、2つの機能で逆です。スキルでは個人用（~/.claude/skills/）の定義が、サブエージェントではプロジェクト用（.claude/agents/）の定義が優先されます。「同じ名前で作ったのに、思っていたほうと違う定義が動く」ときは、この優先順位が原因かもしれません。

どっちを使う？使い分けの判断基準

結論はシンプルで、「毎回守ってほしいやり方・手順がある」ならSkills、「切り離して任せたい作業がある」ならサブエージェントです。もう少し具体的に見てみましょう。

Skillsが向いているケース

サブエージェントが向いているケース

実例：私の開発での使い分け

私はエンジニアとして普段の開発でClaude Codeを使っていて、両方を実際に使い分けています。

たとえばプロジェクトのコーディング規約や、コミット前の確認手順のような「毎回守ってほしいルール・手順」は、Skills・CLAUDE.md側に持たせています。実装のたびに口頭で伝え直さなくても、同じ品質を保ってほしいからです。

一方、書き上がったコードのレビューは、先ほど例に挙げたreviewerのようなサブエージェントに任せています。ここでサブエージェントを選んだ理由がまさに「コンテキストの分離」です。コードを実装した本人（メインの会話）は、自分の書いたコードを「正しいはず」と思い込んでいるので、チェックが甘くなります。まっさらな別コンテキストのサブエージェントに読ませると、実装中の事情を知らない「初見のレビュアー」としてバグや考慮漏れを見つけてくれるわけです。

注意点もあります。サブエージェントは毎回まっさらな状態から始まるぶん、プロジェクトの把握をやり直すのでトークン消費が増えやすく、時間も少しかかります。何でもサブエージェントに任せればいいわけではなく、軽い作業はメインの会話＋Skillsで済ませるほうが効率的です。

なお、2つは対立する機能ではなく併用できます。2026年7月時点では、スキルをサブエージェント内で実行させる設定（context: fork）や、サブエージェントにスキルをあらかじめ読み込ませる設定（skillsフィールド）も用意されています。まずは基本の使い分けに慣れてから試してみてください。

よくある質問

Q. スラッシュコマンド（カスタムコマンド）とSkillsは何が違う？

A. 現在は同じものに統合されています。以前は.claude/commands/に置くカスタムコマンドが別機能としてありましたが、Skillsにマージされました。古いコマンドファイルもそのまま動きます。Skillsのほうが補助ファイルを同梱できるなど機能が多いので、これから作る場合はスキル形式（SKILL.md）がおすすめです。

Q. CLAUDE.mdとSkillsはどう使い分ける？

A. CLAUDE.mdは毎回すべて読み込まれるのに対し、Skillsは必要なときだけ読み込まれます。プロジェクトの前提や短いルールはCLAUDE.mdに、長い手順書や特定の場面でしか使わない知識はSkillsに分けると、会話のムダな消費を抑えられます。公式ドキュメントでも、CLAUDE.mdの中身が「事実の説明」から「作業の手順」に変わってきたら、スキルに切り出すタイミングだとされています。イメージとしては、「このプロジェクトではReactを使う」のような事実はCLAUDE.md向きで、「リリースはこの手順で行う」のような作業手順はスキル向きです。

Q. サブエージェントを使うとトークン消費（料金）は増える？

A. 増えやすいです。独立したコンテキストで毎回ゼロからプロジェクトを把握し直すためです。ただし、大量の調査結果がメインの会話に残り続けるのを防げるので、長いセッションではかえって効率が良くなる場合もあります。「重い調査は任せる、軽い作業は任せない」くらいの感覚で使うのがおすすめです。

まとめ

Claude CodeのSkillsとサブエージェントの違いを整理しました。

どちらも数分で試せる機能なので、まずは小さな手順書スキルを1つ作ってみるのがおすすめです。細かい仕様は更新されることがあるので、最新の情報は以下の公式ドキュメントで確認してください。

• スキルで Claude を拡張する - Claude Code 公式ドキュメント
• カスタムサブエージェントの作成 - Claude Code 公式ドキュメント

ターミナルで使うClaude Codeとは別に、普段の調べ物にはデスクトップアプリ版のClaudeが便利です。インストール手順は以下の記事で解説しています。

両方を組み合わせると何ができるのかは、PM役のスキルとサブエージェント6人で記事作成を分担させた実例が参考になります。