Claude Codeのサブエージェント活用術｜個人開発を調査・実装・レビューの並列化で効率化する
結論：個人開発でこそサブエージェントは効く
Claude Codeのサブエージェントは、1人体制の個人開発と相性がいい。理由はシンプルで、チーム開発なら別の人がやる「調査」「レビュー」を、自分のコンテキストを汚さずに肩代わりさせられるからだ。
筆者は個人でモバイルアプリとWebサービスを運用しているが、サブエージェントを導入して変わったのは以下の3点だ。
- メインの会話が「実装の判断」だけに集中できる
- 調査結果が要約で返るのでコンテキスト消費が減る
- 実装直後に第三者視点のレビューが入る
逆に、単発の質問や1ファイルの修正では効果がない。むしろ起動オーバーヘッドの分だけ遅くなる。
サブエージェントとは何か
サブエージェントは、独立したコンテキストを持つ子エージェントだ。メインの会話とは別の文脈で動き、最終的な結論だけを親に返す。
ここが重要で、たとえば「この機能がどのファイルで実装されているか調べて」と頼むと、通常なら大量のファイル内容がメインのコンテキストに流れ込む。サブエージェントに委譲すれば、返ってくるのは「src/auth/session.ts:42 で管理されている」という結論だけになる。
定義は Markdown ファイルで行う。プロジェクト単位なら .claude/agents/、全プロジェクト共通なら ~/.claude/agents/ に置く。
---
name: scout
description: コード検索・構造把握を行う読み取り専用エージェント。ファイル内容ではなく結論だけを返す。
tools: Read, Grep, Glob, Bash
model: haiku
---
あなたはコードベース調査の専門家である。
## 厳守事項
- ファイルの中身を大量に貼り付けない
- 結論と file:line 参照のみを返す
- 実装・編集は一切行わないdescription は呼び出し判断に使われるので、「いつ使うか」を具体的に書く。ここが曖昧だと自動で呼ばれない。
個人開発向けの最小構成は3体
全部を作り込む必要はない。まずはこの3体で十分だ。
| エージェント | 役割 | 推奨モデル | 権限 |
|---|---|---|---|
| scout | コード検索・構造把握 | 軽量モデル | 読み取りのみ |
| fact-checker | 仕様・APIの裏取り | 中量モデル | 読み取り＋Web |
| reviewer | 差分の敵対的レビュー | 高性能モデル | 読み取りのみ |
ポイントはモデルを役割ごとに固定することだ。フロントマターに model を書かないと、親のモデルをそのまま継承する。調査タスクに高価なモデルが5体走ると、コストが跳ね上がる。
なお料金体系やモデルIDは変わりやすいので、導入前にAnthropic公式の最新情報を確認してほしい。
並列化の実践手順
1. 調査フェーズを先に投げる
新機能を作るとき、着手前に独立した調査を並列で走らせる。
以下を並列で調べてほしい。
- 既存の課金処理がどこに実装されているか（scout）
- StoreKit 2 のトランザクション検証の推奨手順（fact-checker）独立したタスクは1メッセージにまとめて依頼する。順番に投げると待ち時間が積算する。
2. 実装は親（自分の会話）で行う
設計判断とトレードオフ評価は委譲しない。ここを丸投げすると、意図と違う実装が返ってきて手戻りする。委譲していいのは「判断が不要な作業」だけだと考えるといい。
3. 完了前にレビューを必ず1回通す
直前の差分を reviewer でレビューして。バグ・エッジケース・型の抜けを反証ベースで指摘してほしい。1人開発では他人の目が入らない。ここが一番の効果だった。レビュー観点そのものを鍛えたいなら
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
参考価格￥2,640（税込）
レビュー指摘の言語化に使える定番書
Amazonで最新価格をチェックのような本を一冊読んでおくと、エージェントへの指示も具体的になる。
正直に書く注意点
サブエージェントの報告は「主張」であって事実ではない。
実際に何度か経験したが、「修正済みです」と返ってきたのに該当ファイルが変わっていなかったことがある。重要な判断の根拠にする前に、自分で git diff を開いて確認したほうがいい。
その他の注意点は以下のとおり。
- 親の文脈が伝わらない：会話の経緯を知らないので、指示は自己完結させる必要がある
- 小タスクでは遅くなる：1ファイルの修正なら直接やったほうが速い
- 設計判断は委譲に向かない：トレードオフ評価は自分でやる
- 権限は最小に：調査系に Write を与えない。事故防止として実効性がある
導入は1体ずつ試すのが安全
いきなり5体作ると、どれが効いているのか分からなくなる。まず scout を1体だけ作り、1週間使ってみる。コンテキストの消費が明らかに減る感触があれば、次に reviewer を足す。この順番が失敗しにくい。
それでも実装リソースが足りないと感じたら、UIデザインやアイコンなど自分の専門外の部分だけ外注するのも手だ。
のようなスキルマーケットなら単発で依頼できるので、開発以外の工程を切り出しやすい。
AIエージェントの並列化と外注の使い分け、この2つが個人開発のボトルネックを一番現実的に押し広げてくれる。