Claude Codeサブエージェントの設定と使い方｜モデル指定でコストを下げる個人開発の並列化パターン

結論：サブエージェントの本命は「並列化」ではなく「モデル指定」

Claude Code のサブエージェントで個人開発のコストが最も下がるのは、タスクを並列で走らせたときではない。定義ファイルに model を書き、調査系タスクを安価なモデルへ固定したときである。

理由は2つある。

1. コード検索やファイル横断調査は、読み込む入力トークンが膨らむわりに、必要なのは結論の数行だけ
2. その生データを主コンテキストに入れずに済むと、以降の全ターンの再送コストが軽くなる

並列実行はあくまで待ち時間の短縮策だ。並べれば並べるほどトークンの総量はむしろ増える。効くのは「どのモデルに、どの粒度の仕事を渡すか」の設計のほうである。

サブエージェント定義ファイルの置き場所と書き方

サブエージェントは Markdown ファイル1枚で定義する。置き場所は2種類ある。

• プロジェクト単位: .claude/agents/<name>.md
• ユーザー単位（全プロジェクト共通）: ~/.claude/agents/<name>.md

同名なら通常はプロジェクト側が優先される。個人開発なら、汎用の調査役はユーザー単位、リポジトリ固有の規約チェック役はプロジェクト単位、という分け方が管理しやすい。

最小構成はこうなる。

---
name: scout
description: コード検索・構造把握・複数ファイル横断調査を行う読み取り専用エージェント。生のファイル内容ではなく結論だけを返す。実装前の調査で使う。
tools: Read, Grep, Glob, Bash
model: haiku
---

あなたは読み取り専用の調査エージェントです。

## 厳守事項
- ファイルの変更・作成は一切しない
- ファイル内容をそのまま貼り付けない
- 出力は「結論 + 根拠となる file:line」の形式に限る
- 200行を超える報告を書かない

ポイントは4つ。

description は呼び出しトリガーそのもの。 Claude Code はこの文面を読んで自動委譲を判断する。「〜のときに使う」まで書いておくと発火精度が上がる。手動で呼びたいときは「scout で調べて」と名前を出せばよい。

tools は省略すると全ツールを継承する。 調査役に Edit や Write が渡っていると、意図しない変更が入る余地が残る。読み取り専用にしたいなら明示的に絞る。

model を省略すると親のモデルを継承する。 ここが最大の落とし穴で、書き忘れると高コストモデルのままサブエージェントが動き、委譲した意味が消える。

本文（システムプロンプト）に出力形式の制約を書く。 「結論だけ返す」「ファイル内容を貼らない」を明記しないと、報告が長文化して節約分を食い潰す。

作成・編集は /agents コマンドからでもできる。手書きが面倒ならそちらが早い。

モデル指定のルーティング表

実運用で使っている振り分けはこの形だ。

タスク種別	委譲先モデル	判断基準
コード検索・構造把握・横断調査	Haiku	判断不要。探して要約するだけ
ドキュメント・仕様の裏取り	Sonnet	読解と統合が少し要る
パターンが確定した機械的実装（リネーム、定型追加）	Sonnet	手本があり判断が挟まらない
差分レビュー・バグ検出	Opus 相当	見逃しが致命傷。ここはケチらない
要件解釈・設計判断・難バグの原因分析	委譲しない（自分でやる）	文脈の総量がものを言う

迷ったときの基準は単純で、「探す・写す」は安いモデル、「決める」は自分である。設計判断を Haiku に投げると、もっともらしいが的外れな結論が返ってきて、検証コストのほうが高くつく。

モデルの選び分けという発想自体は Claude Code に限らない。他ツールでの考え方はAIコーディングのコスト爆増を防ぐ：Cline・Copilotのモデル選び方と月額上限設定にまとめている。

実運用パターン：調査を並列で投げて、実装は自分でやる

個人開発で効く型はこの3段だ。

1. 調査を並列で投げる

独立した調査は1つのメッセージにまとめて依頼すると同時に走る。

scout を3つ使って並列で調べて。
1. 認証まわりの実装がどのファイルにあるか
2. 既存のエラーハンドリングの共通パターン
3. テストの命名規約と配置ルール
それぞれ結論と file:line だけ返して。

返ってくるのは要約だけで、読み込まれた大量のソースは各サブエージェントのコンテキストに閉じたまま消える。ここが節約の実体だ。

2. 実装は主エージェントで行う

調査結果を踏まえた設計判断と実装は、文脈を持っている主エージェントが担当する。ここを委譲すると、前提の再説明コストで元が取れない。

3. レビューだけ独立視点に投げる

実装後、差分レビュー専門のサブエージェントに投げる。自分の書いたコードを自分で見るより、まっさらな文脈で「反証してみろ」と指示したほうが指摘が出る。ただしレビューは推論力に直結するので、ここだけは安いモデルにしない。

並列化の全体像はClaude Codeのサブエージェント活用術でも扱っている。

正直に言うデメリットと注意点

万能ではない。使う前に知っておくべき弱点がある。

• 並列数はコストに直結する。 安いモデルでも本数分は課金される。5本投げれば5本分だ。「とりあえず並列」は節約ではなく浪費になる
• サブエージェントは会話履歴を共有しない。 毎回ゼロから前提を渡す必要があり、文脈依存の強いタスクでは説明コストのほうが高くつく
• 報告は主張であって事実ではない。 「修正済み」「確認した」という報告を鵜呑みにせず、該当ファイルや diff は自分で開いて確かめる。ここを飛ばすと、誤報告を土台にした修正が実行時に崩れる
• 細分化しすぎると管理不能になる。 最初は調査役・レビュー役の2つで十分。増やすのは不足を感じてからでいい
• description が曖昧だと発火しない。 自動委譲されないときは、たいてい定義側の記述不足が原因

なお、利用可能なモデル名・料金体系・サブエージェントの仕様は変更されることがある。導入前に Anthropic の公式ドキュメントで最新情報を確認してほしい。

まとめ

サブエージェントの導入手順は3ステップに要約できる。

1. .claude/agents/scout.md を作り、model: haiku と tools を明示する
2. システムプロンプトに「結論だけ返す・ファイル内容を貼らない」と書く
3. 調査は並列で委譲し、設計判断と実装は自分の文脈で行う

まずは調査役1つから始めるのが現実的だ。定義ファイル1枚で、調査のたびに主コンテキストへ流れ込んでいた生ソースが止まる。効果はトークン消費の数字にすぐ出る。

エージェント設計の考え方をもう少し体系立てて学びたいなら、

のような書籍を一冊挟むと、自作エージェントの粒度設計で迷いにくくなる。