Claude Codeのサブエージェント5人を整理する——スキルとの違いと仕事の分け方

はじめに——英語名だけでは、役割が見えにくい

Claude Codeに「このコードを調べて」と頼むと、画面上ではClaudeが一人で作業しているように見えます。しかし内部では、調査や計画などの仕事を別のサブエージェントへ委譲することがあります。

サブエージェントには general-purpose、Explore、Plan などの名前があります。ただ、英語名だけを見ても、誰に何を頼めばよいか直感的に思い出せないことがあります。

そこで今回の動画では、5つの組み込みサブエージェントに「万能職人」「見つけ屋」「絵図描き」といった日本語の呼び名を付け、役割を整理しました。

サムネイルをクリックすると、YouTubeで動画を再生できます。

この記事では動画の内容を出発点に、Claude Codeの公式ドキュメントで現在の役割を確認しながら、スキルとの違い、委譲の考え方、権限とコンテキストを分ける意味まで掘り下げます。

動画で紹介した「5人」の役割

動画では、組み込みサブエージェントを次のように整理しました。

日本語の呼び名	公式名	主な役割
万能職人	`general-purpose`	調査と変更の両方を含む、複雑な複数ステップの仕事を進める
見つけ屋	`Explore`	ファイル探索やコード検索など、変更を伴わない読み取り専用の調査を行う
絵図描き	`Plan`	Plan modeで実装前の情報を集め、計画に必要なコンテキストを整理する
案内人	`claude-code-guide`	Claude Codeの機能について質問されたとき、使い方を案内する
表示屋	`statusline-setup`	`/statusline`を実行したとき、ステータスラインの設定を支援する

日本語の呼び名は、公式名称を置き換える設定ではありません。人間が役割を思い出し、明示的に頼みやすくするための理解補助です。また、組み込みエージェントの名称、モデル、ツール構成はClaude Codeのバージョンによって変わる可能性があります。

重要なのは5つの名前を暗記することよりも、仕事の種類に応じて担当者と使える道具が分かれていると理解することです。

私たちは、イシューや受け入れ条件を起点に開発する「AI仕様駆動開発」を実践しています。そこで大切なのは、AIに任せる仕事の範囲を先に決め、その範囲の中で再現性のあるやり方を使うことです。

この視点から、スキルとサブエージェントを一言で分けると、次のようになります。

スキルは「やり方」の資産。サブエージェントは「実行者」の資産です。

スキルとサブエージェントの違い

Claude Codeのスキルは、SKILL.mdを中心にした手順・知識・ワークフローです。Claudeが作業内容に合うスキルを読み込むと、その作業の進め方が会話に加わります。ユーザーが /skill-name で明示的に呼び出すこともできます。

一方、サブエージェントは、独自のコンテキスト、指示、ツール、権限を持って仕事をする独立した実行単位です。メインの会話に大量の探索結果やログを残したくないとき、特定の役割だけに絞って調査したいときに向いています。

観点	スキル	サブエージェント
正体	`SKILL.md`にまとめた手順・知識・ワークフロー	独立したコンテキストで動く実行者
主な役割	何をどう進めるかを再利用する	誰が、どの権限・モデル・ツールで実行するかを分ける
コンテキスト	通常は現在の会話に読み込む	自分のコンテキストで処理し、要約を返す
制御	`description`、呼び出し方法、`disable-model-invocation` など	モデル、ツール、権限、最大ターン数など
移植性	Agent Skillsの共通仕様を土台にできる	定義方法や拡張項目はツールごとに異なる

料理にたとえるなら、スキルはレシピ、サブエージェントは料理人です。レシピだけでは料理は始まりません。料理人がレシピを手に取り、必要な道具と時間を使って実行したときに、はじめて成果物になります。

発動を決めるのは名前ではなくdescription

ここは、今回の違和感を解く重要なポイントです。

Claude Codeは、スキルの description を見て、そのスキルを適用するかどうかを判断します。サブエージェントも同じく、定義に書かれた description をもとに、タスクを委譲するか判断します。

つまり、日本語の名前を付けたこと自体が自動発動の条件になるわけではありません。

日本語名に変えて動くようになったように見えたなら、考えられるのは次のような変化です。

人間が名前を覚え、明示的に指名しやすくなった
名前の変更と同時に、descriptionや指示文も改善された
そのときのタスクが、たまたま委譲条件に合っていた

名前は、人間が呼ぶときの入口です。自動発動の精度を左右するのは、何ができ、いつ使うものなのかを具体的に書いた description です。

サブエージェントが呼ばれないのは異常ではない

Claude Codeには、コードベース探索や計画などを担当する組み込みサブエージェントがあります。代表的なものにExploreやPlanがありますが、利用できる種類や表示はバージョンによって変わり得ます。

サブエージェントが呼ばれるのは、たとえば次のような場合です。

メインの会話にまだない情報を、大量のファイルから調べる
調査ログをメインコンテキストに残さず、要約だけ受け取りたい
読み取り専用の調査や、特定のツールだけを使う作業に分けたい
複数の独立した論点を並行して処理したい

逆に、すでに必要な情報がメインの会話に揃っているなら、再び探索エージェントを呼ぶ理由はありません。呼ばれないことは「機能が使えていない」証拠ではなく、「今回は委譲する必要がない」という判断の結果かもしれません。

この違いを見落とすと、サブエージェントが呼ばれた回数を、AI活用の質を測る指標にしてしまいます。大事なのは回数ではなく、仕事の分け方が成果に合っているかです。

`context: fork`——スキルと実行者を組み合わせる

Claude Codeでは、スキルのfrontmatterに context: fork を指定すると、スキルの手順を独立したサブエージェントのコンテキストで実行できます。

---
name: deep-research
description: Research a topic thoroughly
context: fork
agent: Explore
---
指定されたテーマを調査し、根拠とともに要約を返す。

この仕組みを使うと、「何をするか」と「誰がどの環境で実行するか」を一つの単位にできます。

forkするスキル：タスクが固定され、実行者を選べる。 サブエージェント：実行者の役割・権限が固定され、依頼するタスクを変えられる。

逆方向の組み合わせもあります。サブエージェント側の skills フィールドでスキルをあらかじめ読み込ませれば、専門の実行者に必要な手順を持たせて起動できます。

ただし、context: fork はClaude Codeの拡張機能です。Agent Skillsの共通仕様に乗る部分と、各ツールが独自に提供する実行機能は分けて考える必要があります。

いくつかのツールで同じ構造が見えてくる

スキルとエージェントの名前やファイル形式は、すべてのツールで同じではありません。それでも、共通する分離は見えてきます。

ツール	公式情報から確認できること
Claude Code	スキルはAgent Skillsのオープン仕様を土台にし、サブエージェントは独立コンテキストで動く。Claude Code固有のforkや呼び出し制御もある
Codex	OpenAIは、複数チームが再利用できる社内Skillsを整備し、定義しにくい仕事を委譲していると説明している
GitHub Copilot / VS Code	`SKILL.md`を使うAgent Skillsと、役割・ツールを設定するカスタムエージェントを提供している
Gemini CLI	独立コンテキストのサブエージェントを、自動委譲または明示指定で使える。並列実行にも対応する

Agent Skillsの仕様では、必須ファイルを SKILL.md とし、必要に応じて scripts/、references/、assets/ などを組み合わせます。まず名前と説明だけを見せ、必要になったときに本文や参考資料を読む「段階的開示」の考え方も、コンテキストを守るうえで重要です。

ここで移植できるのは、主にスキルの知識や手順です。エージェントの権限、モデル、隔離方法、委譲の仕組みはツール固有の部分が残ります。

AI仕様駆動開発では、what・how・whoを分ける

AI仕様駆動開発の視点で整理すると、役割は次のように分かれます。

問い	担当するもの	例
何を達成するのか（what）	イシュー、仕様、受け入れ条件	「記事をProductionで公開する」
どう進めるのか（how）	スキル	frontmatter、執筆ルール、検証コマンド
誰がどの条件で実行するのか（who）	サブエージェント	公式情報を調べる読み取り専用の調査役
どこで止めるのか	人間の確認、権限、フック	外部公開や本番デプロイの承認

この分離ができていると、スキルが自動で読み込まれても、目的そのものが勝手に広がりにくくなります。スキルは「やり方」を補いますが、イシューにない仕事を追加する許可ではありません。

一方で、deploy のように副作用を伴う行動系スキルを自動発動させると、スコープ外の作業まで進める危険があります。私たちの運用では、次の二種類を分けるのが現実的だと考えています。

行動系スキル：デプロイ、公開、マージなど。disable-model-invocation: true を使い、人間の明示指示をゲートにする。
規律系スキル：記事の文体、Issueの受け入れ条件、検証観点など。関連する作業で自動適用させ、スコープを守る方向に働かせる。

これは、AIに自由に仕事をさせるか、すべてを人間が手で操作するか、という二択ではありません。何を自動化し、どこに人間のゲートを置くかを、仕様として設計する考え方です。

コンテキストを「常駐・オンデマンド・隔離」で設計する

この整理を、Claude Codeの周辺機能にも広げてみます。

CLAUDE.md：毎回知っていてほしい、プロジェクトの前提や規律
スキル：必要な仕事のときだけ読み込む、再利用可能な手順や知識
参考資料・スクリプト：スキルの実行時に必要なときだけ読む・使う部品
サブエージェント：大量の探索や専門作業を隔離して実行する場所

つまり、コンテキスト設計の問題は「全部を詰め込むか、何も渡さないか」ではありません。

何を常駐させ、何をオンデマンドにし、何を隔離するか。

この三つの判断ができれば、スキルが増えたときのコンテキスト肥大化と、サブエージェントを増やしすぎたときの分断を、同じ設計問題として扱えます。

まとめ

Claude Codeのスキルとサブエージェントは、競合する機能ではありません。

スキルは、手順・知識・ワークフローを再利用する仕組み。
サブエージェントは、独立したコンテキストと権限で仕事を分ける実行者。
自動発動の判断材料は名前ではなく、スキルやエージェントの description。
サブエージェントが呼ばれないことは、必要な情報がすでに揃っている場合など、正常な判断の結果になり得る。
AI仕様駆動開発では、イシューがwhat、スキルがhow、サブエージェントがwhoを担当する。
公開・マージ・デプロイのような副作用のある行動には、人間の明示的なゲートを残す。

「スキルが使われたか」「サブエージェントが呼ばれたか」だけを追いかけると、手段が目的になってしまいます。見るべきなのは、仕様に沿って仕事が進み、必要なときに必要な知識と実行環境が選ばれているかです。

AIエージェントが会社の仕事に入ってくるほど、知識を保存するだけでは足りなくなります。判断基準や検証方法をスキルにし、実行者の権限とコンテキストを設計する。そうして初めて、過去の知見が、次の仕事で使える実務の部品になります。

参考資料

※ Claude Codeの組み込みエージェントや利用できるfrontmatterは、バージョンによって変わる可能性があります。本記事は2026年8月4日に確認した公式ドキュメントをもとに整理しています。