はじめに
Claude Codeでは、作業を役割ごとに分けたサブエージェントに振り分けて進めています。
今回、それぞれのサブエージェントにどのモデルを割り当てるかを、Claude Code自身と相談しながら決めました。
決める過程で、自分が立てた仮説と実測値がずれる場面が何度かあり、今のところ「これが正解」とは言い切れない状態のまま運用を始めています。
この記事はその決め方の記録です。
Claudeの契約プランはProで、Fableを使っていません
使えたらもっと幅が広がりそう
サブエージェントを8種に分けている理由
自分の~/.claude/CLAUDE.mdには、作業を次の8つの役割に分けて進めるというルールを書いています。
- memory-lookup: 事実確認をメモリ本体から行う(読み取り専用)
- memory-writer: 新しい学びやプロジェクト状況をメモリに保存する
- planner: 非自明な実装・企画の方針を設計する(読み取り専用)
- coder: 実装・編集・テスト実行を担当する
- watchdog: 他エージェントの成果物を事後レビューし、問題があれば差し戻す
- session-boot: セッション冒頭に関連メモリ・ルールを読み込んで要約する
- security-reviewer: 実装差分をセキュリティ観点でレビューする
- simplifier: 実装差分を簡素化の観点でレビューする
役割を分けている理由は単純です。
1つのエージェントに全部やらせると、事実確認が甘いまま実装が進んだり、実装した本人がそのままレビューまで済ませてしまったりします。
役割を割ると、後から見返す自分の負担が減ります。
負担だけでなく、トークン効率、速度の面でも効果はありそう
各エージェントの定義は~/.claude/agents/以下に1ファイルずつ置いていて、frontmatterにname・description・toolsを書く形です。plannerの定義はこうなっています。
---
name: planner
description: 非自明な実装・企画タスクの方針・手順を設計する。読み取り専用で、コードやファイルの変更は行わない。
tools: Read, Grep, Glob, Bash
---
モデルを固定する前の状態
つい最近まで、8種類のどの定義ファイルにもmodelの指定がありませんでした。
呼び出し元がmodelを明示しない限り、サブエージェントは呼び出し元のセッションと同じモデルを引き継ぎます。
自分のメインセッションはClaude Sonnet 5なので、8種類すべてがSonnet 5で動いていたことになります。
どの役割に強いモデルを当てるかを相談した
最初に立てた仮説は2つでした。
1つ目はplannerです。
plannerの出力の質は、後続のcoderやwatchdogの作業すべてに影響します。
呼び出し回数はそれほど多くないはずなので、コストを気にせず一番強いモデルを当てられるのではないかと考え、Opus 5を割り当てることにしました。
理想は、ここにFable 5.1を割り当てたい！
2つ目はmemory-lookupとmemory-writerです。
どちらも事実確認とメモリの読み書きが中心で、1回あたりの出力は短いはずです。
呼び出し回数が多い分、軽いモデルの方がコスト効率がよいのではないかと考え、Haiku 4.5を割り当てました。
session-bootも同じ理由でHaiku 4.5にしています。
coderは実装を担う分、Haiku 4.5にすると手戻りが増えると考え、デフォルト(呼び出し元と同じモデル)のままにしました。
watchdog・security-reviewer・simplifierも同様にモデル固定を見送っています。
呼び出し回数を数えてみる
仮説の裏付けとして、実際の呼び出し回数を数えることにしました。
最初は手元のセッションログをgrepで雑に数え、その時点では「memory-writerが一番多く呼ばれている」「plannerは思ったより少ない」ということしか分かりませんでした。
数え方によって値が変わった
その後、planner自身に方針設計を依頼したところ、この回数をもう一度数え直す作業から始まりました。同じログを3通りの方法で数えると、3通りとも違う値が出てきました。
| 数え方 | memory-writer | coder | memory-lookup | watchdog | planner | session-boot |
|---|---|---|---|---|---|---|
| 生grepの出現数 | 133 | 100 | 63 | 60 | 35 | 19 |
| tool_use idで重複排除 | 102 | 77 | 46 | 44 | 25 | 13 |
| 実行時のメタファイル数 | 102 | 85 | 47 | 44 | 25 | 13 |
生grepはログの再出力分を二重に数えてしまいます。
tool_use id方式とメタファイル方式でcoderの値がずれるのは、watchdogが差し戻しでcoderを呼んだ分(孫呼び出し)がメインセッション側のログに残らないためです。
最終的に、実行時に残るメタファイルを数える方式を採用しました。
記事を書くタイミングでもう一度数え直した値は、次の節の表にまとめています。
現時点のモデル割り当て
回数の実測を踏まえて、次のとおりモデルを割り当てています。
| エージェント | 実行回数 | 固定モデル |
|---|---|---|
| memory-writer | 102 | claude-haiku-4-5-20251001 |
| coder | 86 | 未固定(呼び出し元と同じ) |
| memory-lookup | 48 | claude-haiku-4-5-20251001 |
| watchdog | 44 | 未固定(呼び出し元と同じ) |
| planner | 25 | claude-opus-5 |
| session-boot | 13 | claude-haiku-4-5-20251001 |
| security-reviewer | 7 | 未固定(呼び出し元と同じ) |
| simplifier | 7 | 未固定(呼び出し元と同じ) |
coderについては、軽い作業(単純なリネームや定型ファイル生成)のときだけ、呼び出し時にmodel: haikuを指定する運用にしています。
回数だけでは決められなかった部分
ここまでは「呼び出し回数が多い役割を軽くする」という軸で決めていました。
実際にトークン消費(出力トークン数とキャッシュ読み込みトークン数)まで集計すると、この軸だけでは説明がつかない分布が出てきました。
| エージェント | 実行回数 | 1回あたり出力トークン | キャッシュ読み込みに占める割合 |
|---|---|---|---|
| coder | 86 | 28,296 | 88.44% |
| watchdog | 44 | 11,860 | 5.07% |
| memory-writer | 102 | 3,884 | 2.46% |
| planner | 25 | 12,488 | 1.43% |
| security-reviewer | 7 | 23,877 | 1.38% |
| simplifier | 7 | 12,582 | 0.70% |
| memory-lookup | 48 | 2,842 | 0.40% |
| session-boot | 13 | 3,696 | 0.13% |
呼び出し回数だけ見るとmemory-writerが102回で最多ですが、全体のキャッシュ読み込みトークンに占める割合は2.46%にとどまります。
coderは86回とmemory-writerより少ないのに、全体の88.44%を占めています。
1回あたりの出力トークンも平均28,296と、他のどの役割よりも多い数値です。
理由ははっきりしています。coderは実装のたびにファイル全体やビルドログ、テスト結果を読み込むため、1回あたりに扱う文脈量が他の役割より一桁多くなります。
memory-lookupやsession-bootは特定のメモリファイル数枚を読むだけなので、回数を重ねても総量は増えません。
「呼び出し回数が多い役割を軽くする」という判断軸は、回数の多い役割自体は正しく拾えていましたが、コストの主因が回数ではなく1回あたりの文脈量だった役割については機能していませんでした。
coderのモデルを固定しなかったのは、結果的にこの点で理にかなっていたことになります。
固定してから1日しか経っていない
modelの指定を各定義ファイルに追加したのは2026年9月21日です。この記事を書いている時点で、固定後にHaiku 4.5で動いたやり取りはmemory-writerが56件、memory-lookupが38件、session-bootが25件、Opus 5で動いたplannerが89件です。それぞれの総メッセージ数(1,158件/448件/178件/423件)に対して、まだ一部でしかありません。この割り当てで手戻りが増えたか、レビュー負荷が下がったかは、もう少し使ってみないと分かりません。
定義ファイルをどう書き換えたか
実際の変更は、各定義ファイルのfrontmatterにmodelを1行足すだけです。
---
name: memory-lookup
description: 事実に関わる主張を書く前に、メモリ索引だけでなく該当ファイル本体を読んで正確な一次情報を返す。読み取り専用。
tools: Read, Grep, Glob
model: claude-haiku-4-5-20251001
---
modelを省略すると、そのサブエージェントは呼び出し元のセッションと同じモデルを引き継ぎます。今回はplanner・memory-lookup・memory-writer・session-bootの4つだけ固定し、残り4つ(coder・watchdog・security-reviewer・simplifier)はこの挙動のままにしています。
まだまだ改善の余地はありそうですが、やってみて、改善すべきところが出てきたら都度改善していきます。
最後まで読んでいただきありがとうございました。