Claudeサブエージェントとは？作り方と使い分けを解説

Claude Codeを使っていて「サブエージェント」という言葉を目にしたものの、公式ドキュメントだけでは仕組みや実践イメージがつかめず、もやもやしていないでしょうか。本記事では、サブエージェントの基本的な仕組みから、組み込みエージェントの種類、/agentsコマンドを使った作成手順、そしてAnthropicが公式に示す「使うべき場面・避けるべき場面」までを整理します。さらに、2026年に登場したAgent Teamsとの違いや、プロンプトキャッシュTTLを使ったコスト最適化といった実践的な内容にも踏み込み、自分の開発フローに無理なく組み込めるレベルまで解説していきます。

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

Claudeのサブエージェントとは、Claude Codeが特定のタスクを処理するために呼び出す、専門特化型の「もう一人のClaude」のような存在です。単なるプロンプトのテンプレートではなく、独立した環境で動作する点が最大の特徴です。まずは、その仕組みと役割分担を整理しておきましょう。

サブエージェントの基本的な仕組み

サブエージェントは、独立したコンテキストウィンドウ上で動作する専門特化型のClaudeインスタンスです。Tembo.ioの解説によると、サブエージェントはそれぞれ以下の3つの要素を独自に持っています。

独立したコンテキストウィンドウ：メインの会話履歴とは切り離された領域で処理を行います
カスタムのシステムプロンプト：役割に応じた振る舞いをあらかじめ定義できます
スコープされたツールリスト・権限：使えるツールや操作範囲を必要最小限に絞り込めます

この「独立したコンテキストで動く」という性質が、通常の会話継続とは決定的に異なるポイントです。メインの会話が長くなるとコンテキストが圧迫され、Claudeの応答精度が落ちることがありますが、サブエージェントに調査や検証を任せることで、メインの会話のコンテキストを汚さずに済みます。

メインエージェントとの役割分担

サブエージェントとメインエージェントの関係は、上司と専門スタッフの関係に近いイメージです。サーバーワークスエンジニアブログの解説では、メインの会話がサブエージェントにタスクを委譲すると、サブエージェントは独自のコンテキストの中で処理を進め、その結果だけをメインの会話に返す、という流れが説明されています。

つまりメインエージェント（メインの会話）は、次のような役割を担います。

ユーザーとの対話全体の進行管理
どのタスクをどのサブエージェントに委譲するかの判断
サブエージェントから返ってきた結果の統合と最終的な回答生成

一方サブエージェントは、委譲された個別タスクの実行に専念し、途中経過の細かいやり取りをメインの会話に持ち込みません。この役割分担によって、メインエージェントは「全体の見通し」を保ったまま、細部の調査や検証は専門のサブエージェントに任せる、という分業体制が実現します。次のセクションでは、Claude Codeに標準搭載されている組み込みサブエージェントの具体的な種類を見ていきます。

組み込みサブエージェントの種類（Explore・Plan・General-purpose）

Claude Codeには、自分でカスタム作成しなくても最初から使える組み込みサブエージェントが用意されています。代表的なのがExplore・Plan・General-purposeの3種類で、これらはどれを使うかをClaudeが状況に応じて自動的に判断し、使い分けてくれます。まずはこの3つの特徴を押さえておきましょう。

Explore（コードベース探索用）

Exploreは、コードベースの調査・探索に特化したサブエージェントです。「このファイルはどこにあるか」「この機能を実装している箇所はどこか」といった調べものを、メインの会話のコンテキストを圧迫せずに実行できる点が特徴です。調査結果だけがメインの会話に返されるため、大規模なリポジトリを読み込んでもメインのコンテキストウィンドウが消費されにくくなります。

Plan（計画モード用の調査エージェント）

Planは、計画モード（Plan Mode）でClaudeが利用する読み取り専用の調査エージェントです。実装を進める前の設計・調査フェーズで使われ、ファイルの変更は行わずに情報収集に徹する点がポイントです。また、Planは親のモデルをそのまま引き継ぐ仕様になっているため、メインエージェントで高性能なモデルを使っていれば、計画段階の調査も同じ精度で行われます。

General-purpose（汎用エージェント）

General-purposeは、あらゆるツールを親から引き継ぐ汎用型のサブエージェントです。Explore・Planのように役割が限定されておらず、専門特化型のエージェントでは対応しきれない、複数ステップにまたがる複雑な調査や修正作業を任せたいときに使われます。いわば「専用エージェントが当てはまらないタスクの受け皿」としての位置づけです。

なお、この3つ以外にも「Claude Code Guide」や「statusline-setup」といった組み込みサブエージェントが用意されており、Claude Code自体の使い方案内やステータスライン設定といった補助的な役割を担っています。これらの組み込みエージェントの使い分けを理解しておくと、次に紹介するカスタムサブエージェントを作成する際にも、「どこまでを組み込みに任せ、どこからを自作するか」の判断がしやすくなります。

カスタムサブエージェントの作り方

組み込みサブエージェントだけでなく、自分のプロジェクトに特化したカスタムサブエージェントを作成することもできます。作成方法は「対話型コマンドで作る方法」と「Markdownファイルを手動で作る方法」の2種類です。

/agentsコマンドで作成する手順

もっとも手軽な方法は、Claude Codeのセッション内で/agentsと入力することです。これによりサブエージェントを管理する対話型インターフェイスが開きます。

具体的な作成ステップは次のとおりです。

保存場所を選択します（プロジェクト用の.claude/agents/、または個人用の~/.claude/agents/）
作成方法を選択します（「Claudeで生成（推奨）」または手動設定）
エージェントの説明（役割や使う場面）を入力します
識別用の背景色を選択します

「Claudeで生成（推奨）」を選ぶと、入力した説明をもとにClaude自身がシステムプロンプトやツール構成の草案を作ってくれるため、フロントマターの書式を覚えていなくても迷わず作成できます。まず動くものを作ってみたい場合は、この/agentsコマンドから始めるのがおすすめです。

Markdownファイルで手動作成する方法

もう一つの方法は、.claude/agents/配下にYAML frontmatter付きのMarkdownファイルを直接配置することです。ファイルを置くだけでClaude Codeがそのままサブエージェントとして認識してくれます。

基本的なファイル構造は次のようなイメージです。

---
name: code-reviewer
description: プルリクエストのコードレビューを行う
tools: Read, Glob, Grep
model: sonnet
---

あなたはコードレビューの専門家です。
diffを分析し、重大度別に指摘してください。

/agentsコマンドが生成したファイルも内部的には同じ形式なので、既存のファイルを複製・編集して独自のエージェントを増やしていく使い方も可能です。細かい挙動までコントロールしたい場合は、手動作成のほうが調整の自由度は高くなります。

フロントマターの主要フィールド

フロントマターで必須なのはnameとdescriptionの2つだけです。toolsやmodelを含む残りの項目はすべてオプションとして扱われます。

主なフィールドは以下のとおりです。

name：エージェントを識別する名前（必須）
description：どんな場面で使うエージェントかを示す説明（必須）
tools：利用を許可するツールのリスト（省略時は全ツールを引き継ぎます）
model：使用するモデル（sonnet、haiku、opusなど）
maxTurns：やり取りの上限回数
skills：割り当てるスキル
mcpServers：連携するMCPサーバー
hooks：処理前後に挟むフック処理
memory：記憶させる情報

必須項目が2つしかないため最小構成での作成は容易ですが、toolsを明示的に絞ることで、そのサブエージェントに不要な権限を渡さずに済むという安全面のメリットもあります。用途が明確なエージェントほど、ツールを絞り込んだ設計にしておくとよいでしょう。

保存場所とスコープ（プロジェクト・個人・一時的）

サブエージェントの保存場所は、誰と共有したいかによって選び分けます。

プロジェクト用（.claude/agents/）：チームで共有する場合に配置します。Gitでバージョン管理できるため、チームメンバー全員が同じサブエージェントを使える状態を保てるのが利点です。この運用は公式でも推奨されています。
個人用（~/.claude/agents/）：自分専用のサブエージェントを置く場所です。プロジェクトを横断して使いたい個人的な便利エージェントに向いています。
一時的な定義：--agentsCLIフラグを使うと、ファイルとして保存せずJSON形式でその場限りのサブエージェントを定義することもできます。試験的に動作を確認したいときに便利です。

チームの標準ワークフローに組み込むならプロジェクト用、自分だけの作業効率化ならホームディレクトリ配下、一度だけ試したいならCLIフラグ、という3段階で使い分けるとスムーズです。

サブエージェントを使うべき場面・避けるべき場面

サブエージェントは強力な機能ですが、常に使うのが正解というわけではありません。Anthropicは、サブエージェントが独自のコンテキストを立ち上げることでトークンを消費し、開発者と作業の間に「間接層」を追加するというオーバーヘッドを伴うことを明確に注意しています（＠IT）。つまり、便利だからといって何でもサブエージェントに投げると、コストと応答の複雑さがかえって増してしまうリスクがあります。ここでは「使うべき場面」と「避けるべき場面」を判断基準として整理します。

使うべき5つの場面

上位記事の見出し構成からも整理されている、サブエージェントが力を発揮しやすい5つの場面は次の通りです。

調査が多いタスク：コードベース全体を横断的に読み込んで情報を集める必要がある場合、メインの会話のコンテキストを消費せずに調査結果だけを受け取れます。
複数の独立したタスク：互いに依存しない作業を並行して進めたいとき、それぞれを専用のサブエージェントに任せることで、メインの会話をシンプルに保てます。
新鮮な視点が必要なとき：メインの会話が長く続いて文脈が固定化してしまった場合、独立したコンテキストを持つサブエージェントに任せることで、思い込みに縛られない検証ができます。
コミット前の検証：コードレビューやテストの実行など、実装作業とは別の視点でチェックを挟みたい場面に向いています。
パイプラインワークフロー：計画→実装→検証のように工程がはっきり分かれている作業では、各工程を専用のサブエージェントに担わせることで役割分担が明確になります。

これらはいずれも、「メインの会話のコンテキストを汚さずに済むかどうか」という一点に集約される判断基準です。作業の性質上、結果だけを受け取れば十分なタスクほど、サブエージェントとの相性は良いといえます。

使うべきでない5つの場面

一方で、＠ITの解説によれば、Anthropicはメインの会話にとどまる方が望ましい場面として、以下のようなケースを挙げています。

逐次的な連鎖処理：各ステップが前のステップの完全な出力を必要とする場合、サブエージェントに委譲すると情報が要約・欠落してしまい、後続の処理に支障が出やすくなります。
同一ファイルへの並列編集：複数のサブエージェントが同じファイルを同時に編集しようとすると、コンフリクトが発生するリスクが高まります。
簡単な修正や集中的な質問：委任のオーバーヘッド（独立したコンテキスト立ち上げやトークン消費）が、得られるメリットを上回ってしまうケースです。単純な一言修正であれば、メインの会話で直接対応した方が速く、コストも抑えられます。
選択肢が多すぎる自動委任：カスタムサブエージェントを増やし過ぎると、Claudeがどのエージェントに委任すべきか判断しづらくなり、自動委任の信頼性そのものが下がってしまいます。
間接層が不要な単純作業：開発者と作業の間にレイヤーを一枚挟むこと自体がデメリットになる場面では、サブエージェントを使わずメインの会話で完結させる方が合理的です。

これらの共通点は、「タスクの分割によって情報が失われる」「委任コストが作業内容に対して重すぎる」という2つのリスクです。サブエージェントを設計・運用する際は、便利な機能だからこそ「本当にコンテキストを分離する必要があるか」を毎回問い直す姿勢が、トークン浪費を防ぐ最も確実な方法といえます。

サブエージェントとAgent Teamsの違い

Claude Codeには、サブエージェントと似た響きを持つ「Agent Teams」という機能も存在します。2026年5月時点では実験的機能(experimental)として位置づけられており、デフォルトでは無効になっていますが、両者は構造そのものが異なるため、混同すると使い分けを誤ってしまいます。ここでは構造の違いと選択基準を整理します。

構造の違い：親子構造とチーム構造

サブエージェントは、メインエージェントを「親」、呼び出されたサブエージェントを「子」とする親子構造・タスク分割型の仕組みです。親であるメインエージェントがタスクを分割し、それぞれのサブエージェントに委譲、各サブエージェントは独立したコンテキストで作業を終えると結果だけを親に返します。サブエージェント同士が直接やり取りすることはなく、あくまで親を経由した一方向的な指揮系統です。

これに対してAgent Teamsは、1つのClaude Codeセッションを「チームリーダー」とし、複数のClaude Codeインスタンスを「チームメンバー(teammates)」として並列稼働させる、チーム構造・協働型の仕組みです。従来のサブエージェントとの決定的な違いは次の2点にあります。

メンバー同士が直接メッセージをやり取りできる点。サブエージェントのようにリーダーを経由する必要がありません。
共有タスクリストをメンバーが自らclaim(取得)して進める、自己調整型の進行方式である点。

Agent Teamsのこうした協働構造は、根本原因が不明確な調査タスクで特に力を発揮するとされています。公式ドキュメントでは、単一のエージェントだけに任せると一つのもっともらしい説明を見つけた時点で探索を止めてしまいがちですが、複数の独立した調査者が互いの仮説を反証しようと試みる環境では、最後まで残った仮説の方が実際の根本原因である可能性がはるかに高くなる、という趣旨の説明がなされています。サブエージェントの「親が振り分けて子が黙々とこなす」構造とは、狙っている効果そのものが異なることがわかります。

どちらを選ぶべきか

両者はどちらが上位互換というものではなく、タスクの性質によって向き不向きが分かれます。

サブエージェントが向くケース：コードレビューやコードベース探索など、タスクの境界がはっきりしていて、親から子への一方向の委譲だけで完結する作業。専用のシステムプロンプトやツール権限を持たせて役割を固定したい場合にも適しています。
Agent Teamsが向くケース：原因不明のバグ調査のように、複数の視点から仮説をぶつけ合い、生き残った説を採用したいような探索的タスク。メンバー間の直接的な情報交換が価値を生む場面です。

なお、Agent Teamsは2026年8月時点でも実験的機能の位置づけであり、本番の開発フローに組み込む際は、まずサブエージェントの親子構造で要件を満たせないかを検討し、それでも足りない協働性が必要な場合にAgent Teamsの導入を検討する、という順序で考えるのが現実的です。

サブエージェントのコストとキャッシュを最適化する

サブエージェントは独立したコンテキストウィンドウを持つ分、メインエージェントとは別にトークンを消費します。便利さと引き換えに発生するこのコストをどう抑えるかは、実運用のフェーズで必ず意識したいポイントです。ここでは2026年8月のアップデートで追加されたキャッシュ設定と、モデル選択によるコスト最適化の考え方を紹介します。

サブエージェントのプロンプトキャッシュTTL設定

Claude Codeにはプロンプトキャッシングという仕組みがあり、既に処理した内容を再利用することで、変更された部分にだけ新しい処理を行い、高速かつ費用効率的に動作させることができます（Claude Code公式ドキュメント）。

これまでサブエージェントは、サブスクリプションプランであってもキャッシュTTL（キャッシュの有効期限）が常に5分固定でした。しかし、Claude Code v2.1.243（2026年8月25日リリース）でpromptCacheTtl／subagentPromptCacheTtlという設定項目が追加され、以下のように指定することでTTLを最大1時間まで延長できるようになりました（サーバーワークスエンジニアブログ）。

subagentPromptCacheTtl: "1h"

同じサブエージェントを短時間のうちに繰り返し呼び出すようなワークフローでは、TTLを延ばすことでキャッシュヒット率が上がり、再計算にかかるコストと待ち時間の両方を削減できます。

ただし、注意点もあります。サブエージェントの呼び出し頻度がそれほど高くない場合、TTLを1時間に延長しても、キャッシュの書き込み単価の増加分がキャッシュヒットによる節約分を上回ってしまう可能性がある、と指摘されています（サーバーワークスエンジニアブログ）。つまり、TTL延長は「常に得」というわけではなく、そのサブエージェントがどれくらいの頻度・間隔で呼び出されるかを見極めたうえで設定するのが賢明です。頻繁に呼び出す専門エージェントには1時間TTLを、たまにしか使わないエージェントにはデフォルトの5分のままにしておく、といった使い分けが基本になります。

モデルの使い分けでコストを抑える

もう一つのコスト最適化の軸は、サブエージェントごとに割り当てるモデルの選択です。フロントマターのmodelフィールドで指定できるモデルには価格差があり、Haikuのコストはおよそ Sonnet の1/4、Opus の1/20とされています（Zenn/kei_concierge）。この差は、サブエージェントを複数並列で動かす場面ほど効いてきます。

考え方としては、タスクの複雑さに応じてモデルを割り当てることが重要です。

単純な検索・要約・フォーマット確認：Haikuで十分なケースが多く、コストを大きく抑えられます
設計判断や複雑なコード生成を伴う調査：Sonnetなど中位モデルが安定した選択になります
最終的な意思決定や難易度の高い推論：Opusを使うべき場面を限定的に残しておきます

特にAgent Teamsのように複数のteammateを並列オーケストレーションする構成では、teammateの定義が~/.claude/agents/配下の設定から再利用されるため、1箇所でモデルとツールを固定しておけば、5並列で起動しても全て同じ設定（たとえばmodel: haikuかつ読み取り専用ツール）で動作させることができます（iret.media）。並列数が増えるほどモデル単価の差がコスト全体に大きく反映されるため、「並列で動かす軽量タスクは軽量モデルに固定する」という設計は、コスト最適化の基本方針として押さえておく価値があります。

サブエージェントの実践的な活用例

ここまでサブエージェントの仕組みや作り方、使うべき場面の判断基準を見てきました。最後に、実際の開発フローに落とし込みやすい3つの活用例を紹介します。どれも既存のフロントマター設計をベースに応用できるので、自分のプロジェクトに合わせてカスタマイズする際の参考にしてください。

コードレビュー用エージェント

もっとも導入しやすいのが、コードレビュー専用のサブエージェントです。実装例として紹介されているのは、tools: Read, Glob, Grepという読み取り専用の権限設定にmodel: sonnetを組み合わせた構成です。書き込み系のツールを一切持たせないことで、レビュー対象のコードを誤って変更してしまうリスクを構造的に排除できます。

役割としては、diffを分析して以下のように重大度別にフィードバックを返す形が典型的です。

Critical：セキュリティ上の欠陥やデータ破損につながる問題
Major：バグや設計上の重大な懸念
Minor：命名規則や可読性など軽微な改善提案

コミット前やプルリクエスト作成時に呼び出す運用にしておけば、「使うべき場面」として挙げた検証系タスクの受け皿としても機能します。読み取り専用というスコープの狭さが、そのままレビューの信頼性につながる点がこのユースケースの肝です。

並列調査・並列実行エージェント

複数の独立したタスクを同時にこなしたいときは、サブエージェントを並列に立ち上げる構成が有効です。特にAgent Teamsと組み合わせる場合、teammateの定義は通常のサブエージェントと同じ~/.claude/agents/配下のファイルを再利用する仕組みになっています。つまり、モデルやツールの設定を1箇所で固定しておけば、5並列で起動しても全てのteammateが同じ設定で動作します。

例えばmodel: haikuと読み取り専用ツールをあらかじめ定義しておけば、複数の調査エージェントを一斉に走らせてもコストを予測しやすくなります。調査系タスクは並列化との相性がよく、独立性の高い探索を同時に走らせることで、単一のエージェントが陥りがちな「最初にもっともらしい仮説を見つけて探索を止めてしまう」状態を避けやすくなる点もメリットです。

ただし、同一ファイルを複数のエージェントが同時に編集するような処理は、コンフリクトの原因になるため向いていません。並列化は「調査」や「独立した検証」に限定して使うのが安全です。

パイプライン型（計画→実装→検証）エージェント

3つ目は、計画・実装・検証という工程を複数のサブエージェントにリレー形式で担わせるパイプライン型の構成です。組み込みのPlanエージェントで読み取り専用の調査を行い、その結果を受けてGeneral-purposeエージェントなどが実装を進め、最後にコードレビュー用エージェントが検証を行う、という流れをイメージすると分かりやすいでしょう。

この構成は「使うべき5つの場面」で触れたパイプラインワークフローそのものであり、各工程の担当範囲を明確に分けられる点が強みです。一方で、各ステップが前工程の完全な出力を必要とする逐次処理の場合は、委譲によるオーバーヘッドがかえって足かせになることもあるため、工程間の依存度が高すぎるタスクには不向きです。自分の開発フローのどこが「独立して切り出せる工程」なのかを見極めることが、パイプライン型を成功させるポイントになります。

まとめ

Claudeのサブエージェントは、独立したコンテキストで動く専門特化型のエージェントであり、メインの会話を汚さずに調査や検証を任せられる点が最大の価値です。組み込みのExplore・Plan・General-purposeを使い分けつつ、/agentsコマンドやMarkdownファイルでカスタムエージェントを作成すれば、自分のプロジェクトに合わせた運用が可能になります。ただしAnthropicが指摘するように、逐次処理や簡単な修正には向かず、使い過ぎるとかえってコストと複雑さが増す点には注意が必要です。協働的な調査にはAgent Teams、コスト面ではsubagentPromptCacheTtlやモデルの使い分けも活用しながら、まずは自分のプロジェクトで一つカスタムサブエージェントを作ってみることをおすすめします。