Claude Codeのサブエージェントを6体作って役割を分けた｜モデルより「ツール権限」で分けるのが正解だった
設計・実装・レビュー・実行・雑務・執筆で6体に分けています。分けてみて分かったのは、効いているのはモデルの使い分けよりも「何を触らせないか」の設定でした。実際の構成をそのまま公開します。
結論：効くのはモデルの使い分けより「ツール権限」
サブエージェントというと「重い作業は上位モデル、軽い作業は下位モデル」というコスト最適化の話になりがちです。
実際に6体を運用してみて、もっと効いたのは「そのエージェントに何を触らせないか」でした。
たとえばレビュー担当には、ファイルを書き換える権限を与えていません。 読むことしかできません。これだけで、レビューを頼んだのに勝手に直され始める、という事故が消えます。
実際の構成
~/.claude/agents/ に6体置いています。全部の設定を出します。
| 役割 | モデル | 使えるツール | 何をさせるか |
|---|---|---|---|
| architect | Fable | Read, Glob, Grep, WebSearch, WebFetch | 設計・技術選定・方針判断 |
| builder | Opus | Read, Write, Edit, Glob, Grep, Bash | 実装 |
| writer | Opus | Read, Write, Glob, Grep, WebSearch, WebFetch | 長文執筆 |
| runner | Sonnet | Read, Edit, Write, Glob, Grep, Bash | 定型作業・動作確認 |
| reviewer | Fable | Read, Glob, Grep, WebFetch | 公開前チェック |
| sorter | Haiku | Read, Glob, Grep, Write | 要約・分類・整形 |
考える役（architect / reviewer）にはFable、作る役にはOpus、回す役にはSonnet、さばく役にはHaikuという割り当てです。
権限で分けた具体例
reviewer に Write と Edit を持たせない
これが一番効いた判断でした。
レビューを頼むと、指摘するだけでなくその場で直し始めることがあります。それ自体は親切なのですが、公開前の最終チェックでそれをやられると困ります。何を指摘されたのかが、修正の中に埋もれてしまうからです。
ツールから Write と Edit を外すと、指摘のリストを返すことしかできなくなります。 直すかどうかは人間が決める、という順序が固定されます。
architect にも書き込み権限を与えない
設計を相談したら、勝手に実装が始まっていた——を防ぎます。
Read と検索系、それに WebSearch / WebFetch だけを持たせています。調べて考えて、案を返すところまでが仕事です。
技術選定は、実装より前に人間が判断すべきことです。ここを分けておくと「気づいたら決まっていた」がなくなります。
sorter に Bash を持たせない
要約・分類・整形といった軽い仕事の担当です。ファイルの読み書きはしますが、コマンドは実行できません。
大量の単純作業を任せる相手ほど、できることを絞っておくほうが安全でした。
モデルの割り当てについて
こちらは権限ほど厳密ではありません。目安としてこう分けています。
- 考える仕事（設計・レビュー）→ 深く考えるモデル
- 作る仕事（実装・執筆）→ 出力の質が要るモデル
- 回す仕事（定型作業）→ 中間のモデル
- さばく仕事（要約・分類）→ 軽いモデル
実感として、モデルを変えて明確に体感が変わったのは「さばく仕事」でした。 大量の分類や要約は軽いモデルで十分で、上位モデルを使っても結果はほぼ同じです。ここを軽くすると、その分を実装や執筆に回せます。
逆に設計とレビューは、モデルを落とすと分かりやすく質が落ちます。 見落としが増えます。
つまずきやすい点
分けすぎると呼ぶのが面倒になる
最初はもっと細かく分けようとしました。「テスト専門」「ドキュメント専門」といった具合です。
結果、どれを呼べばいいか分からなくなりました。 呼び分けを考える時間のほうが、作業時間より長くなっては本末転倒です。
いまの6体は、自分の仕事の種類に対応しています。 設計する / 作る / 書く / 回す / 見る / さばく。これ以上細かくしても、自分の頭の中の分類と合いません。
説明文（description）を具体的に書く
エージェントを呼び分けるとき、判断材料になるのが description です。
「コードを書きます」では選べません。「HTML/CSSのサイト制作、Apps Script修正、複雑な機能実装」のように、実際に自分が頼む作業名を書くほうが機能します。
自分の仕事に出てくる固有名詞を入れておくのがコツでした。
権限を絞りすぎると仕事が止まる
reviewer から書き込み権限を外したのは正解でしたが、runner から Bash を外したときは失敗しました。
定型作業の実行担当なのに、コマンドが打てないと何もできません。「何をさせたいか」から必要な権限を決める必要があります。安全側に倒しすぎると、ただ使えないエージェントができあがります。
よくある質問
サブエージェントは何体くらいに分けるべきですか？
自分の仕事の種類に合わせるのが目安です。細かく分けすぎると、どれを呼べばいいか判断する時間のほうが長くなります。設計・実装・執筆・定型作業・レビュー・雑務といった単位で6体程度が扱いやすい規模でした。
レビュー用のエージェントに書き込み権限を与えないのはなぜですか？
指摘と修正が混ざるのを防ぐためです。書き込み権限があると、レビューを頼んだのにその場で修正が始まり、何を指摘されたのかが分からなくなります。読み取り専用にすると、指摘のリストを返すことしかできなくなり、修正するかどうかを人間が判断できます。
モデルの使い分けはどれくらい効果がありますか？
要約や分類といった軽い作業では、上位モデルを使っても結果はほとんど変わりませんでした。逆に設計やレビューでモデルを落とすと、見落としが増えて質が下がります。軽い作業を軽いモデルに回すことで、重い作業にリソースを配分できます。
まとめ
サブエージェントを分ける目的は、コストの最適化だけではありませんでした。
- 何を触らせないかを決めると、事故が構造的に起きなくなる
- レビュー役と設計役から書き込み権限を外すのが、一番効いた
- モデルの使い分けは、軽い作業を軽くする方向で効く
- 分けすぎると呼ぶのが面倒になるので、自分の仕事の分類に合わせる
権限設計は、人に仕事を任せるときの考え方と同じでした。「できること」より「あえてできなくすること」を決めるほうが、結果的にうまく回ります。