Claude Code Subagents

Claude Code のサブエージェントを“使い分ける”。

メインの文脈を汚さずに、調査・実装・レビューを別コンテキストの専門担当に分業する。作り方と、任せどころの設計をまとめます。

AI 駆動開発の相談をする

Challenges

こんな場面に向いています

1 体の AI に何でも任せていると、文脈が膨らみ、視点もひとつに偏ります。役割で分けると、その状態を整理できます。

  • 1 体の AI に全部やらせて、会話の文脈が膨らんでしまう
  • 実装する視点とレビューする視点が同じになり、見落としを見落とす
  • どこまでをエージェントに任せ、どこを人が持つかが決まっていない

What Is a Subagent

サブエージェントという考え方

サブエージェントは、メインの会話とは別のコンテキストで走る、特定タスクに特化した担当です。大きな調査や実装を、メインの文脈を膨らませずに分業でき、結果だけを受け取れます。Claude Code では .claude/agents 配下に Markdown で定義します。1 体に全部を背負わせるのではなく、役割ごとに分けることで、それぞれの視点を独立させられます。

AI ツールの利用は広く普及した一方、AI エージェントを定常的に使う開発者はまだ少数にとどまり、業務での利用はこれから本格化する段階にあると報告されています。

出典: Stack Overflow Developer Survey 2025(調査の論旨)

権限を絞り、作る役とレビュー役を分ける。任せられる範囲は、確認の型が決まった分だけ広がっていく。

出典: Livune AI 駆動開発メソッド(一次情報)

Background Data

AI エージェント活用をめぐる動向

AI を開発に取り入れる動きと、その「任せ方」の課題は、公開・検証可能な調査で継続的に扱われています。下記は外部調査の数値で、サブエージェントの設計(権限を絞る・レビュー役を分ける)が要る理由の背景データです。

※ 下記は外部の公開調査の数値です(一次ソースを 2026 年 6 月時点で確認)。Livune の主張ではなく、業界全体の動向データを参照しています。

84%

開発者を対象とした年次調査(2025 年)では、回答者の 84% が AI ツールを利用、または利用予定と回答したと報告されています(前年は 76%)。

出典: Stack Overflow Developer Survey 2025
survey.stackoverflow.co/2025/ai

51%

同じ調査では、プロの開発者の 51% が AI ツールを毎日利用していると報告されています。

出典: Stack Overflow Developer Survey 2025
survey.stackoverflow.co/2025/ai

23%

一方で、AI エージェントを週 1 回以上の頻度で使う開発者は 23% にとどまると報告されています。ツールの利用は普及しても、"エージェントに任せる" はこれからの段階です。

出典: Stack Overflow Developer Survey 2025(The New Stack による集計)
thenewstack.io

約70%

AI エージェントを業務で使った開発者の約 7 割(生産性向上 69%、特定タスクの所要時間短縮 約 70%)が効果を実感したと報告されています。

出典: Stack Overflow Developer Survey 2025
survey.stackoverflow.co/2025/ai

87% / 81%

同時に 87% が回答の精度を、81% がデータのプライバシー・セキュリティを懸念しています。だからこそ「権限を絞る」「レビュー役を分ける」設計が要る、という論拠になります。

出典: Stack Overflow Developer Survey 2025
survey.stackoverflow.co/2025/ai

How to Build

作り方の 3 ステップ

作り方の核は 3 つです。役割・権限・人格(手順)を順番に決めると、迷いません。定義ファイルの先頭(frontmatter)には name(識別子)・description(どんな依頼のとき呼ぶか)・tools(使える道具)・model(任意)を書き、本文に役割と手順を書きます。

01

役割を決める(description)

「どんな依頼のとき委譲すべきか」を description に書きます。親はここを読んで委譲先を選ぶため、最も重要な項目です。

02

権限を絞る(tools)

その役割に必要な道具だけを許可します。たとえばレビュー役は読み取り専用にすると、誤編集が原理的に起きません。

03

人格と手順を書く(system prompt)

定義ファイルの本文に、役割・進め方・禁止事項を書きます。ここがエージェントの判断基準になります。

Design

使い分けの設計

サブエージェントの価値は「分けること」から生まれます。作る役とレビュー役、読み取りと書き込み、文脈を継ぐか新規で始めるか。この 3 つの軸で設計すると、任せどころが定まります。

分業

作る役 / レビュー役

実装した本人の文脈は実装を肯定しやすい。別コンテキストの初見レビュアーを立てると独立性が出ます。

権限

read-only / 書き込み

調べる・確認するだけの役は読み取り専用に。触る役だけに書き込み権を渡します。

文脈

継続 / 新規

直前の文脈が要るなら同じエージェントに継続依頼。白紙の初見が欲しいなら新規で始めます。

任せる ≠ 投げっぱなしです。最終差分の確認と実動作確認は、人(またはオーケストレータ)が持ちます。

FAQ

よくある質問

Claude Code のサブエージェント(subagent)とは何か?

メインの会話とは別のコンテキストで走る、専門タスク特化の担当です。

大きな調査や実装をメイン文脈を膨らませずに分業でき、結果だけを受け取れるためです。

.claude/agents に Markdown で定義します。

subagent はどう作る? 定義ファイルには何を書く?

frontmatter に name(識別子)・description(いつ呼ぶか)・tools(使える道具)・model(任意)を書き、本文に system prompt(役割・手順・禁止事項)を書きます。

description がオーケストレータの「呼ぶ判断」を決めるので最重要です。

tools を絞ると事故が減ります。

description には何を書くと呼ばれやすい?

「どんな依頼のとき委譲すべきか」を具体的なトリガー語で書きます。

親エージェントは description を読んで自動委譲先を選ぶためです。

「〜と言われたら」「〜の作業時」の形が効きます。

subagent の tools(権限)はどう絞る?

その役割に必要な道具だけを許可します。

書き込み権を渡さなければ誤編集が原理的に起きないためです。

read-only と write を役割で分けるのが定石です。

「作る人」と「レビューする人」はなぜ分ける?

実装した本人の文脈は実装を肯定しやすく、見落としを見落とすからです。別コンテキストの初見レビュアーを立てると独立性が出ます。

同一視点の自己レビューは盲点が残ります。

レビュア側にセキュリティ観点(OWASP 等)を持たせると守備範囲が広がります。

subagent と「メインで全部やる」はどう使い分ける?

単発の事実確認や既知ファイルの小編集はメインで直接、横断調査・並列作業・別視点が要る検証は subagent に委譲します。

委譲はコンテキスト分離の利得と引き換えに往復コストがかかるためです。

「結論だけ欲しい/文脈を汚したくない」が委譲の判断軸になります。

複数の subagent を並列で動かすには?

独立したタスクは同時に投げ、それぞれの結論だけを集約します。

依存のない作業を直列にすると待ち時間が無駄になるためです。

依存がある作業はパイプライン(前段の出力を次段へ)で繋ぎます。

同じ subagent に作業を続けさせる(文脈を継ぐ)か、新規で始めるか?

直前の文脈が必要なら同じエージェントに継続依頼、白紙の初見が欲しいなら新規で始めます。

レビューや検証は「初見」であることが価値になる場面が多いためです。

目的(継続性 vs 独立性)で選びます。

subagent に任せたあと、人は何を確認すればいい?

最終差分の確認と実動作確認は人(またはオーケストレータ)が持ちます。

エージェントの自己申告「できました」と実際の動作は別物だからです。

「任せる ≠ 責任放棄」です。

subagent を業務で使うと本当に速くなる?

AI エージェント利用者の約 7 割が生産性向上・時間短縮を実感したと報告されています(Stack Overflow Developer Survey 2025)。ただし精度懸念も 8 割を超えます。

効きますが、検証なしの丸投げは事故るためです。

だから権限分離とレビュー分離が前提になります。

subagent 運用でありがちな失敗は?

権限を絞らず誤編集 / レビュー役を立てず盲点が残る / description が曖昧で呼ばれない、の 3 つです。

いずれも「役割・権限・トリガー」の設計不足が原因です。

作り方 3 ステップに戻ると防げます。

AI 駆動開発を社内で型にするにはどこから始める?

まず「作る/レビューする」を分け、権限を役割で絞るところから始めます。

小さく安全な分業が定着の入口だからです。

体系的に学ぶなら Livune の AI 駆動開発研修・本番運用支援をご利用ください。

Contact

AI 駆動開発について相談する

サブエージェントの設計や、AI に任せる開発の進め方について、お気軽にご相談ください。

メールで相談する

お問い合わせは [email protected] までお気軽にどうぞ。