この記事でやること
Claude Code の Agent tool を使って、メインセッション(Opus)はそのままに、定型的なコード生成だけサブエージェント(Sonnet)に委譲する実装方法をまとめます。
- Agent tool の
modelパラメータでモデルを切り替える具体的な書き方 - サブエージェントに渡すプロンプトの自己完結ルール
- どんなタスクが Sonnet 委譲の対象として適切か
- 実運用での注意点(context 非共有・失敗時のリカバリ)
読者が手元で試せる形で、コード例を中心に解説します。
前提
- Claude Code がインストール済み
- Agent tool(サブエージェント機能)が利用できる環境
- Opus / Sonnet の両方にアクセス可能(プランによる)
問題意識: Opus 単独だとトークンコストが重い
Claude Code のメインセッションを Opus 固定で運用すると、判断精度は高いがトークン単価が高いという悩みが出てきます。
一方で、全部を Sonnet に切り替えると精度不足で失敗・やり直しが増え、結局トータルで高くつくケースが少なくありません。
そこで使えるのが Agent tool の model パラメータです。メインの判断は Opus、コード生成はサブエージェント側で Sonnet、という役割分担ができます。
実装: Agent tool での model 指定
Agent tool 呼び出し時に model: "sonnet" を明示すると、そのサブエージェントだけ Sonnet で実行されます。
Agent({
description: "UserList コンポーネントの新規作成",
subagent_type: "general-purpose",
model: "sonnet",
prompt: `
src/components/UserList.tsx を新規作成してください。
【要件】
- props: { users: User[] } を受け取る
- 各ユーザーを Card コンポーネントでグリッド表示
- Card は src/components/ui/Card.tsx に既存
- TailwindCSS で 3 列グリッド(sm:grid-cols-2, md:grid-cols-3)
- 型定義は src/types/user.ts の User 型を import
【完了条件】
- TypeScript エラー 0
- ESLint 警告 0
- ファイル 100 行以内
`
})
ポイントは 3 つです。
model: "sonnet"を明示-
descriptionは簡潔に(ログ用途、実行内容を 1 行で表現) -
promptは自己完結させる(詳細は後述)
サブエージェントは context を共有しない
ここが一番ハマりやすいポイントです。
サブエージェントは メイン会話の履歴を一切見ていません。だから次のようなプロンプトは高確率で失敗します。
// 失敗例: メイン会話に依存した指示
Agent({
description: "さっきのコンポーネントを修正",
subagent_type: "general-purpose",
model: "sonnet",
prompt: "先ほど作ったコンポーネントの className を修正してください"
})
サブエージェントは「先ほど」を知らないので、どのファイルを触ればいいか判断できません。
自己完結させた良い例
Agent({
description: "Header.tsx の className 修正",
subagent_type: "general-purpose",
model: "sonnet",
prompt: `
src/components/Header.tsx を開いてください。
【変更内容】
- 42 行目の <nav className="flex gap-4"> を
- <nav className="grid grid-cols-3 gap-4"> に変更
【完了条件】
- TypeScript エラーが出ないこと
- 他の箇所は一切変更しないこと
`
})
ファイルパス・行番号・変更内容・完了条件をすべて明記します。
委譲に向くタスクの 3 条件
実運用でわかってきたのは、Sonnet 委譲が黒字になるのは次の 3 条件がすべて揃ったときだけ、ということです。
| 条件 | 内容 |
|---|---|
| 指示が明確 | ファイルパス・変更内容・完了条件が言語化できる |
| 出力量が大きい | 100 行以上の生成、または複数ファイルへの機械的な置換 |
| 判断が不要 | 仕様のグレーゾーンが無く、選択肢が残っていない |
逆に、次のようなタスクは Sonnet 委譲に向きません。
- 設計判断を含むリファクタ
- バグの原因調査
- コードレビュー
- 数行の小さな編集(委譲オーバーヘッドの方が重い)
コードレベルでの分岐判断サンプル
「どういうときに Agent 委譲を使うか」を関数化するとしたら、以下のような判定ロジックになります。
type TaskType =
| "design" // 設計判断
| "debug" // バグ調査
| "review" // レビュー
| "small-edit" // 数行編集
| "bulk-impl" // 大量定型実装
| "bulk-replace" // 機械的置換
type DelegationDecision = {
readonly shouldDelegate: boolean
readonly model: "opus" | "sonnet"
readonly reason: string
}
function decideDelegation(task: TaskType): DelegationDecision {
switch (task) {
case "design":
case "debug":
case "review":
return {
shouldDelegate: false,
model: "opus",
reason: "判断が必要なタスクは Opus 単独が総コストで安い"
}
case "small-edit":
return {
shouldDelegate: false,
model: "opus",
reason: "委譲オーバーヘッドが実装コストを上回る"
}
case "bulk-impl":
case "bulk-replace":
return {
shouldDelegate: true,
model: "sonnet",
reason: "定型大量タスクは Sonnet 委譲で 30〜50% 削減可能"
}
}
}
「迷ったら Opus に倒す」というデフォルト設計にしておくと、誤爆リスクを抑えられます。
失敗時のリカバリ
Sonnet サブエージェントが期待通りに動かなかったときのリカバリ手順です。
- 結果を Opus(メイン)がレビュー: 差分を読み、合否を判定する
-
不合格なら再委譲 or 自力実装:
- プロンプトの不備が原因 → プロンプトを直して再委譲
- タスクが Sonnet に向いていない → メイン(Opus)で実装し直す
- 2 回目も外したら即 Opus に切り戻す: 同じ委譲を 3 回繰り返すのは時間とトークンの無駄
委譲はあくまで「早くて安い最適化手段」であって、必須ではありません。判断ミスを感じたらすぐ Opus に戻すのが安全です。
まとめ
- Agent tool の
model: "sonnet"でサブエージェントのモデルを切り替えられる - サブエージェントは context を共有しないので、プロンプトは自己完結必須
- 委譲に向くのは「明確・大量・定型」の 3 条件が揃ったときだけ
- 判断タスク・小さな編集は Opus 単独の方が総コストで安い
- 迷ったら Opus に倒す
Claude Code のコストを下げたいなら、モデル単価ではなくタスクあたりの総トークン量と一撃精度で評価するのがポイントです。
SEOスコアチェックツール: SEO_CHECK — RINIAディレクターツール。
Web制作・SEO関連の技術情報サイト: CodeQuest.work