【2026年版】Claude CodeのSkillsとSubagentsの使い分け｜判断基準はコンテキスト

2026年8月24日

当ページのリンクには広告が含まれています。

🤖 Claude Code日常利用🔧 MCP連携でツール自動化☁️ AWS実務3年目

SkillsとSubagentsの使い分けは「試行錯誤の過程をメインの会話に残したいかどうか」で決まります。Subagentは独立したコンテキストで動き、結果の要約だけを親に返す——だから探索の過程で会話が汚れません。Skillsは手順や規約を再利用可能な形で持たせる仕組みで、役割が違います。

どちらも「Claudeに専門性を持たせる」機能なので混同されがちですが、解決している問題が別です。この記事では違いを整理したうえで、実際の作り方と併用の方法までまとめます。

SubagentsとSkillsは何が違う？

	Subagents	Skills
解決すること	コンテキストの分離	手順・知識の再利用
コンテキスト	独立。要約だけ親に返る	メインと同じ
定義	YAMLフロントマター（name/description/model/ツール許可）	SKILL.md
向く場面	大量の探索、並列作業	毎回同じ手順を踏む作業

判断基準はシンプルです。その作業の試行錯誤をメインセッションに残したくないならSubagent。「20ファイル読んで該当箇所を探す」ような作業をメインで走らせると、その全部が会話に積み上がります。Subagentなら結果だけが返ってきます。

Subagentはどう作る？

1 セッション内で /agents を実行する

対話形式で作成できます。最初はこれが一番早いです。

2 役割を description に書く

ここが最重要です。Claudeは description を見て「この作業はこのSubagentに投げるべきか」を判断します。何をするかだけでなくいつ呼ぶべきかを書いてください。

3 ツールの許可・不許可を絞る

allowed／disallowed でツールを制限できます。調査専用のSubagentに書き込み系ツールを渡さない、といった設計が可能です。

4 モデルを指定する

Subagentごとにモデルを選べます。単純な探索タスクなら軽いモデルに寄せてコストを抑える、という使い方ができます。

descriptionの書き方で呼ばれるかが決まる

「コードを調査します」だけだと呼ばれません。「複数ファイルにまたがる実装箇所を特定したいときに使う」のように発動条件を書くと、意図したタイミングで呼ばれるようになります。

Skillsはどう作る？

SKILL.md に手順や規約を書きます。frontmatter で挙動を調整でき、実務で効くのが effort フィールドです。

effort	向く作業
`low`	機械的な定型作業（フォーマット変換、決まった手順の実行）
`high`	設計レビューなど、高い精度が要る判断

推論の深さを作業ごとに変えられるので、定型作業を low に落とすだけでトークン消費が目に見えて減ります。全部を high で回す必要はありません。

併用するとどうなる？

2026年7月時点では、SkillsとSubagentsは組み合わせて使えます。設定として次のようなことができます。

Subagent内でSkillを実行する（context: fork）——手順を持たせたうえで、コンテキストは分離する
Subagentにあらかじめスキルをプリロードする——毎回読み込ませる手間が省ける

「規約に従って調べてほしいが、調べる過程は見せなくていい」という要求は実務でよく出ます。この組み合わせがちょうどそこに当たります。

使いどころを間違えないために

何でもSubagentにしない

Subagentは起動のたびにコンテキストを再構築するため、数回のツール呼び出しで終わる作業には割に合いません。1ファイル読んで直す程度なら、メインでやったほうが速く安く済みます。効くのは、探索が広い・並列に走らせられる・過程が長い、のいずれかに当てはまる場合です。

逆にSkillsは軽いので、迷ったら作っておいて損はありません。ただし数が増えると「どれが呼ばれるべきか」が曖昧になるので、description は具体的に書いてください。

ローカルLLMで代替できるか

コスト面からローカルLLMでの置き換えを検討する人もいますが、SubagentsやSkillsのようなエージェント機能は、モデルの指示追従性能に強く依存します。ローカルで動く規模のモデルだと、複雑な委譲判断は現状かなり厳しいのが実情です。

用途を分けて、定型のコード補完はローカル、設計や横断的な調査はクラウド、という併用が現実的です。ローカル側の構成はローカルLLMのモデル選びにまとめました。

UdemyでAIコーディングの講座を探す※ 単品購入した講座は条件を満たせば30日以内に返金可・購入前に一部レクチャーを無料プレビューできます

まとめ

コンテキストを汚したくないならSubagent、手順を再利用したいならSkills。この一文で使い分けは足ります。

そして併用が可能なので、「Skillで手順を定義し、Subagent内で実行してコンテキストを分離する」という組み方が実務では強力です。まずは /agents で1つ作ってみて、感触を掴むのが早道だと思います。

SubagentsとSkills、どちらを使えばいいですか？

その作業の試行錯誤をメインセッションに残したくないならSubagentです。Subagentは独立したコンテキストで動き、結果の要約だけを親の会話に返します。手順や規約を再利用したいだけならSkillsが適切です。解決している問題が別なので、両方使うのが本来の形です。

Subagentが呼ばれません。

descriptionの書き方が原因であることがほとんどです。Claudeはdescriptionを見て呼ぶかどうかを判断するため、「何をするか」だけでなく「いつ呼ぶべきか」という発動条件を明記してください。「コードを調査します」ではなく「複数ファイルにまたがる実装箇所を特定したいときに使う」のように書きます。

SKILL.mdのeffortは何に効きますか？

推論の深さを調整します。フォーマット変換のような機械的な定型作業はlow、設計レビューなど高い精度が必要な判断はhighが目安です。定型作業をlowに落とすだけでトークン消費が目に見えて減るため、全てをhighで回す必要はありません。

SkillsとSubagentsは併用できますか？

できます。2026年7月時点で、Subagent内でSkillを実行する設定（context: fork）や、Subagentにスキルをあらかじめプリロードする設定が利用できます。「規約に従って調べるが、調べる過程はメインに残さない」という組み方が可能です。