Claude CodeのSubagentsとは？Agent Skillsとの違いと設計パターンを解説

Anthropicは、Claude CodeやClaude Agent SDK向けの機能として、1つのタスクを複数の専門エージェントに分担させる「Subagents（サブエージェント）」を提供しています。
これは、メインエージェントがユーザーの窓口となり、配下の「レビュー担当」「テスト担当」といった子エージェントにタスクを振り分けることで、コンテキストの肥大化を防ぎつつ、複雑なワークフローを効率的に処理する仕組みです。

本記事では、Subagentsの基本的な仕組みから、手順書であるAgent Skillsとの役割分担、そして実装担当やレビュー担当などにロールを分ける具体的な設計パターンまでを体系的に解説します。

ClaudeのSubagentsとは？

Subagents（サブエージェント）は、1つのメインエージェントの配下に、目的別・役割別の「子エージェント」をぶら下げて動かす仕組みです。
Claude CodeやClaude Agent SDKから利用でき、メインエージェントがユーザーのリクエストを受け取り、必要に応じて複数のサブエージェントにタスクを振り分けます。

ここではまず、「なぜ単一エージェントでは足りないのか」「Subagentsを使うと何が変わるのか」を整理していきます。

単一エージェントとSubagentsの違い

従来の「単一エージェント」構成では、1つのエージェントがすべての役割を背負うため、次のような課題が出やすくなります。

• 会話コンテキストがどんどん肥大化し、過去の情報でノイズだらけになる
• 「リサーチ」「設計」「レビュー」など性質の異なるタスクが混ざり、プロンプトが複雑になる
• セキュリティ上、あまり強い権限を持たせづらい（「何でもできる」状態になりやすい）

Subagentsを使うと、これらを役割ごとに小さなエージェントへ分割し、メインエージェントがまとめ役になる構成にできます。

• メインエージェント
  ユーザーとの対話、タスク全体のプランニング、サブエージェントの呼び分けを担当。
  
  

• サブエージェント
  「コードレビュー」「テストランナー」「リサーチャー」など、特定の役割に特化したエージェントとして作動。
  それぞれが独立したコンテキスト・システムプロンプト・ツール権限を持つ。

このようにロールを切り分けることで、コンテキスト管理・並列化・ロール分離がしやすくなり、大規模なワークフローでも破綻しにくい構成を取りやすくなります。

Agent Skillsとの関係（「スキル」と「役割」の分担）

Subagentsとよくセットで語られるのが「Agent Skills（Claude Skills）」です。両者は、次のように役割が分かれています。

• Agent Skills
  「 **この仕事はこういう手順で進める **」という手順書・テンプレ・スクリプトの束
  「SKILL.md」とテンプレート、スクリプト、参考資料をまとめたフォルダ構成で管理する
  
  

• Subagents
  「 誰がその仕事を担当するか」という役割の定義
  それぞれに専用のシステムプロンプトとツール権限を与えた「専門エージェント」として設計する

イメージしやすいように、営業レポートを例にすると次のような分担になります。

• 「営業レポート作成スキル」：Agent Skills側の資産
• 「売上レポート担当サブエージェント」：Subagents側の役割

実務では、「Subagents（役割） × Agent Skills（手順書）」の掛け合わせで設計するケースが多くなります。
この「役割」と「手順」を分離しておくことで、後からの再利用や変更にも強い構成を取りやすくなります。

Subagentsの基本的な仕組み

Subagentsを理解するうえでは、親エージェント（メイン）と子エージェント（サブ）の関係、そしてタスクをどう分割し、どのように受け渡すか（ハンドオフ）をイメージしておくことが重要です。

ここでは、実装のイメージも含めて基本的な仕組みを整理します。

親エージェントと子エージェント（subagent）の関係

Claude CodeのSubagentsは、内部的にはClaude Agent SDKと共通の仕組みで、サブエージェントをメインエージェントに「ぶら下がる」形で定義します。

ここでは構造をイメージしやすいように、「Claude Agent SDKのコード例」で見ていきます。

• メインエージェント
  ユーザーからの入力を受ける窓口として振る舞う
  タスクを読み解き、「どのサブエージェントを使うべきか」を判断する
  
  

• サブエージェント
  独立したシステムプロンプトとツールセットを持ち、特定のサブタスクを担当する
  自分専用のコンテキストを維持し、メインエージェントの会話コンテキストを汚さない

コード上は、「agents」パラメータでサブエージェント群をまとめて定義し、メインエージェントから参照するイメージです。

import { query } from '@anthropic-ai/agents';

const result = query({
  prompt: '認証モジュールのセキュリティ問題をレビューしてください',
  options: {
    allowedTools: ['Read', 'Grep', 'Glob', 'Bash', 'Task'],
    agents: {
      'code-reviewer': {
        description: 'セキュリティと品質にフォーカスしたコードレビュー担当',
        prompt: `あなたはセキュリティ・品質に詳しいコードレビュアーです。...`,
        tools: ['Read', 'Grep', 'Glob'],
        model: 'sonnet',
      },
      'test-runner': {
        description: 'テスト実行と結果分析を担当するサブエージェント',
        prompt: `あなたはテスト実行の専門家です。...`,
        tools: ['Bash', 'Read', 'Grep'],
      },
    },
  },
});

ここで重要なのは、Claude Agent SDK経由でSubagentsを利用する場合、メインエージェント側のツールセットに「Task」を含めておく必要があるという点です。

一方で、サブエージェントの「tools」に「Task」を含めることはできません。SubagentがさらにSubagentを起動することはできないため、タスクの割り振りはあくまでメインエージェント（親）の責務になります。

タスク分割とハンドオフの流れ

Subagentsの動きを具体的にイメージするには、「1つのタスクがどのように分割され、どのサブエージェントに渡っていくか」を流れで見るのが分かりやすいです。

典型的なフローは次のようになります。

1. ユーザーがメインエージェントに「このPRをレビューして」と依頼する。
2. メインエージェントがタスクを解析し、「コードレビュー」と「テスト実行」が必要と判断する。
3. 「code-reviewer」「test-runner」など、対応するサブエージェントを呼び出す。
4. 各サブエージェントが自分のコンテキスト内で作業し、結果だけをメインエージェントに返す。
5. メインエージェントが結果を統合し、ユーザー向けにわかりやすく要約・提案を返す。

このとき、サブエージェント同士は直接会話せず、常にメインエージェントがハブになるのが基本です（プロンプトの工夫により、メイン側で「擬似的に会話させる」ような演出は可能です）。

どこまで自動でやってくれるのか（思考＋ツール呼び出し）

Subagentsを定義しておくと、Claude CodeやClaude Agent SDKの内部で、次のような処理が自動で行われます。

• タスク内容と各エージェントの「description」に基づき、どのサブエージェントを呼ぶべきかを自動判断する
• サブエージェントごとに許可されたツールだけを使うように制御する
• 各サブエージェントのコンテキストを分離しつつ、結果だけをメインエージェントに返却する

一方で、次のようなポイントは開発者側の設計が必要です。

• どんなサブエージェントを用意するか
• どのツールをどのサブエージェントに許可するか
• どの粒度でタスクを分割するか

つまり、「SubagentsをONにすれば、すべて自動で最適なチーム編成になる」というものではありません。

人間が用意した役割・制約の中で、Claudeがよしなにタスクを振り分けてくれるイメージを持っておくと、期待値を合わせやすくなります。

Subagentsの設計パターン

Subagentsは、ただ闇雲に増やしていくとすぐにカオスになります。
そのため、あらかじめいくつかの設計パターンを決めておくと運用が楽になります。

ここでは、代表的な3つのパターンを紹介します。

パターン1：役割ベース（プランナー／リサーチャー／ライター など）

もっとも分かりやすいのが「ロール別」の分割です。コンテンツ制作やレポート作成を例にすると、次のように分けられます。

• 「プランナー」サブエージェント
  ゴール設定、アウトライン設計、必要な調査項目の洗い出しを担当する。

  
  

• 「リサーチャー」サブエージェント
  Web検索ツールやナレッジベースを使い、情報収集・要約を担当する。

  
  

• 「ライター」サブエージェント
  プランとリサーチ結果をもとに本文の執筆・リライトを担当する。

この構成にしておくと、「プランだけ見直し」「リサーチだけやり直し」といった差し替えがしやすくなります。

長期的には、「どのロールを改善するべきか」「どこに新しいSkillを足すべきか」といった保守・改善の単位も明確になります。

パターン2：アプリケーション層ごとの分割（フロント／バックエンド／インフラ）

開発案件では、アプリケーションのレイヤ構造に合わせてサブエージェントを分割するパターンも有効です。

• 「フロントエンド」サブエージェント
  React / Next.js など、フロント側の実装・UIまわりを担当する。

  
  

• 「バックエンド」サブエージェント
  API、DBアクセス、ビジネスロジックなど、サーバーサイドの実装を担当する。

  
  

• 「インフラ／DevOps」サブエージェント
  IaC（Terraform 等）、CI/CD、モニタリング設定などを担当する。

それぞれのサブエージェントに対して、扱うべきディレクトリや使用可能なツールを限定しておくと、誤ったレイヤへの変更を防ぎつつ、並列作業を行いやすくなります。

パターン3：ワークフロー段階ごとの分割（要件定義 → 実装 → テスト → ドキュメント）

もう1つの典型例が、「開発プロセスの段階」に応じてサブエージェントを分けるパターンです。

• 「要件定義・設計」サブエージェント
  ユースケース整理、API仕様ドラフト、テーブル設計レビューなどを担当する。

  
  

• 「実装担当」サブエージェント
  既存設計を前提にしたコード記述・改修を担当する。

  
  

• 「テスト・品質保証」サブエージェント
  テストケース生成、テスト実行、カバレッジ分析などを担当する。

  
  

• 「ドキュメント」サブエージェント
  リリースノート、設計書の更新、README整備などを担当する。

この分割にしておくと、「まず設計サブエージェントで方針を固めてから、実装サブエージェントに渡す」といった段階的なハンドオフを設計しやすくなります。

事業部・バックオフィスでのSubagents活用イメージ（軽く）

Subagentsは開発以外の領域でも活用できます。
たとえば、事業企画やバックオフィス業務で「役割を分けたい」ケースでも応用可能です。

• 「リサーチ担当」サブエージェント：
  法令・市場データ・競合事例を収集して要約する。

  
  

• 「ドラフト作成」サブエージェント：
  リサーチ結果をもとに企画書・稟議ドラフトを作成する。

  
  

• 「チェックリスト担当」サブエージェント：
  社内ルールやチェック項目に沿って抜け漏れを確認する。

たとえば「新サービスの企画〜稟議」のようなフローでは、

1. リサーチ担当サブエージェントで情報を集める。
2. ドラフト作成サブエージェントで企画書案を作成する。
3. チェックリスト担当サブエージェントで要件漏れを確認する。

といった形で、1つの業務フローを複数の役割に分割してエージェント化できます。

Agent Skillsとの違いと組み合わせ方

ここからは、SubagentsとAgent Skillsの違いをもう少し掘り下げつつ、どのように組み合わせると設計しやすいかを整理します。

「手順書としてのSkill」「実行者としてのSubagent」

役割分担をあらためて整理すると、次のようなイメージになります。

• Agent Skills
  「この業務は、こういう入力を受けて、こういう手順で、こういう成果物を出す」という業務フロー＋テンプレートのパッケージ

• Subagents
  「この業務を担当するのは誰か」「どんな視点・制約で考えるか」という役割・視点の定義

四半期営業レポートの作成を例にすると、次のような分担になります。

• 「四半期営業レポート作成スキル」：Agent Skills側に定義（SKILL.md＋テンプレート＋スクリプト）
• 「営業レポート担当サブエージェント」：Subagents側に定義（description＋prompt＋tools）

同じSkillを複数のSubagentから呼び出せるため、「業務フローは共通、アウトプットの粒度や視点だけ変える」といった設計がしやすいのがポイントです。

同じSkillを複数Subagentで共有するパターン

実務では、1つのSkillを複数のサブエージェントで共有するケースがよくあります。

• 「**マネジメント向けダイジェスト」サブエージェント
  同じレポート生成スキルを使いつつ、出力を経営層向けの要約に絞る。

  
  

• 「現場リーダー向け詳細版」サブエージェント
  同じスキルを使い、より細かい指標やTODOを含んだレポートを生成する。

このように、「Skill＝業務フロー」「Subagent＝解釈とアウトプットのスタイル」として切り分けておくと、後からの再利用・拡張がしやすくなります。

Skills無しでSubagentだけ使うとき／その逆

すべてのケースでSubagentsとSkillsの両方を使う必要はありません。

フェーズや規模に応じて、どちらか一方から始めるのも現実的です。

• Skills無し＋Subagentsのみ
  「まずはロール分離だけ試したい」PoCフェーズに向く。
  「コードレビュー担当」「テスト担当」など、役割の切り分けを優先したいときに採用しやすい。

• Subagents無し＋Skillsのみ
  「1エージェント＋Agent Skillsで十分」な小さめワークフローに向く。
  まずSKILL.mdベースで業務フローを固め、その後にSubagentsでロール分離する、というステップも取りやすい。

導入初期は、SkillsかSubagentsのどちらか一方から始め、必要に応じてもう一方を足していくくらいのスタンスがちょうどよいバランスです。

Claude CodeでのSubagents活用イメージ

続いて、Claude CodeとSubagentsを組み合わせた場合の利用イメージを整理します。

ここでは、コーディングタスクを複数のサブエージェントに分担させるパターンを中心に見ていきます。

コーディングタスクをSubagentに分担させる（実装担当／レビュアーなど）

Claude Codeと組み合わせると、Subagentsは**「コードベースを扱う複数の専門エージェント」をまとめるハブ**として機能します。

たとえば、次のような構成を取ることができます。

• 「**実装サブエージェント」
  既存設計に沿ってコードを書き足す／リファクタリングする役割を担当する。
  
  
• 「コードレビュアーサブエージェント」
  変更差分を読み、セキュリティ・パフォーマンス・可読性の観点でレビューする役割を担当する。
  
  
• 「テストランナーサブエージェント」
  テストを実行し、失敗ケースの原因を特定・要約する役割を担当する。

リポジトリ側にSubagents定義を「.claude/agents/」として置いておくと、

• 「この変更を、まず実装 → 次にレビュー → 最後にテストまで回して」と1回依頼するだけで、
• 裏側では複数のサブエージェントが、それぞれのツール権限の範囲で作業を進める

といったワークフローを構成できます。
SDKからの呼び出しとClaude Code側の体験を揃えた**「標準エージェントセット」**を作れる点もメリットです。

SKILL.md＋Subagent構成で、リポジトリ標準フローを作る

さらに一歩進めると、Agent SkillsとSubagentsを両方使った構成も強力です。

• リポジトリ側
  「リリースノート作成スキル」「API仕様テンプレートスキル」などをAgent Skillsとして用意する。
  
  
• Claude Code側
  「リリース担当サブエージェント」「APIドキュメント担当サブエージェント」をSubagentsとして定義する。

この構成にしておけば、「このPRをマージする前に、いつものリリースフロー一式を回して」と依頼するだけで、

1. Subagentsがリリース用Skillを呼び出す
2. コード変更からリリースノート・設計書更新までを一気通貫

といったリポジトリ標準フローをClaude Code側に実装しやすくなります。

Subagentsの導入ステップとアンチパターン

最後に、Subagents導入時の現実的なステップと、避けたいアンチパターンを整理します。

「まずどこから始めるか」「どこで止めておくか」を決めておくと、運用トラブルを減らせます。

いきなりサブエージェントを増やしすぎない

Subagentsは便利ですが、最初から細かく分割しすぎると運用が破綻しがちです。

• どのサブエージェントが何をしているのか分からなくなる
• descriptionやシステムプロンプトが中途半端になり、タスクマッチングが安定しない
• ログを見ても、どのエージェントが原因なのか追いづらい

このため、初期フェーズでは次のようなステップをおすすめします。

1. 「メインエージェント＋2〜3個のサブエージェント」程度の小さな構成から始める。
2. ログと実務の感触を見ながら、分割・統合の単位を少しずつ調整する。

この漸進的な設計をとることで、現場の負担を抑えつつ品質を上げやすくなります。

SkillsとSubagentsの境界が曖昧なまま増やさない

Skills側とSubagents側の役割分担が曖昧なまま両方を増やしていくと、次のような問題が起きがちです。

• 「これはSkillに寄せるべきか、Subagentのプロンプトに書くべきか」がブレる
• 同じロジックがSKILL.mdとSubagentのsystem promptに重複し、二重管理になる

こうしたメンテ不能な状態を避けるために、あらかじめ次のようなルールを決めておくと安心です。

• 業務フロー・手順・テンプレート：Agent Skills側に寄せる
• 視点・ロール・権限の違い：Subagent側で表現する

この方針をチーム内で共有しておくと、後からSubagentsの数が増えても整理しやすくなります。

「人間側の責任範囲」をどこに残すか

Subagentsを増やしていくと、「このまま全部自動化できそう」に見えてしまうことがあります。

しかし、人間側の責任範囲をどこに残すかは必ず意識しておくべきポイントです。

• セキュリティレビュー
  Subagentsは一次チェックや観点の標準化に留め、最終承認は人間のセキュリティ担当が行う。

  
  

• 法務レビュー
  条件分岐やリスク洗い出しをSubagentsに任せつつ、最終判断は法務部門に残す。

  
  

• 大規模リファクタリング
  Subagentsで候補案と差分パッチを出させ、人間が「どこまで適用するか」を判断する。

このように、「どの段階で人間がレビューするか」「AIが越えてはいけないラインはどこか」を事前に決めておくことで、運用トラブルを減らせます。

ログ・振る舞いの検証ポイント

Subagents構成では、動作が複雑になりやすい分、ログとトレースの設計が重要になります。

具体的には、次のような観点を確認できるようにしておくと安心です。

• どのサブエージェントが、どのツールをどのくらい使っているか
• タスクごとに、どのサブエージェントがどのような出力を返したか
• 意図しない振る舞いがあった場合、それがメインなのかサブなのか、どのロールに起因するのか

このために、

• Claude CodeやAgent SDK側のログ出力・トレース機能を活用する
• サブエージェントごとに識別しやすい名前・descriptionを付ける
• 本番導入前に、代表的なシナリオで動作検証を行う

といった観測性の設計もセットで進めておくとよいでしょう。

まとめ

Subagentsは、Claude CodeおよびClaude Agent SDKにおける「複雑なタスクを、複数の専門エージェントで分担させる」ための中核機能です。

• 単一エージェントでは扱いにくい、大規模・長時間のワークフローを整理できる
• コンテキストを役割ごとに分離し、並列化と安全性を両立しやすくなる
• Agent Skillsと組み合わせることで、「手順書×専門エージェント」の構成を取りやすくなる

一方で、「どんな役割をどのレベルで分けるか」「人間がどこでレビューするか」を決めるのは開発者側の仕事でもあります。

まずは、

• 2〜3個のサブエージェントを定義した小さめのワークフローから試す
• Claude Codeや既存のAgent Skillsと組み合わせて、身近な業務を少しずつ自動化してみる

といったステップから始めてみてください。
そのうえで、PoC → 部門展開 → 全社標準フローと段階的に広げていけば、Subagentsのメリットとクセをうまく活かしながら、自社なりのエージェントアーキテクチャを育てていけるはずです。