AIコーディングでサブエージェントを分ける意味はある？
目次
AIコーディングでサブエージェントを分ける意味はある？役割分担を考えてみた
AIにコードを書いてもらうのが普通になってくると、次に気になってくるのが**「AIも役割分担した方がいいのか？」**です。
自分も個人開発でAIを使う中で、
実装するAI
QA・レビューを見るAI
デザインを見るAI
のように分けた方がいいのでは、と考えるようになりました。
最初は単純に、
専門のAIを何人か用意した方が強そう。
くらいの感覚でした。
ただ、少し掘ってみると、サブエージェントは「AIを増やせば増やすほど便利」という話ではなさそうです。
むしろ大事なのは、何を分離したいのかでした。
サブエージェントは「別の専門担当」を作る仕組み
Claude Codeの公式ドキュメントでは、サブエージェントは特定の種類のタスクを担当する専門的なAIとして説明されています。
メインの会話とは別のコンテキストで動き、専用のシステムプロンプトや利用できるツール、権限などを設定できます。
自分がここで一番大事だと思ったのは、単に「別人格を作れる」ことではありません。
作業の文脈を分けられることです。
たとえばコードベースを大量に探索した結果や、長いログ、テスト結果などを全部メインの会話へ流し込むと、本来考えたい設計や実装の話まで埋もれていきます。
サブエージェント側で調査して、必要な結果だけ返してもらえば、メイン側のコンテキストをかなり整理できます。
Claude Code公式でも、探索や実装を別コンテキストへ逃がしてメイン会話を保つことが、サブエージェントの利点として挙げられています。
参考: https://code.claude.com/docs/en/sub-agents（外部サイト）
自分が分けたいと思ったのは「コーディング・QA・デザイン」
自分の場合、最初に考えたのはこの3つです。
コーディング
要件を受け取って、実際にコードを変更する役割。
ここはファイルの読み書きやコマンド実行など、かなり広い権限が必要になります。
QA・レビュー
実装されたものを見て、
要件どおりか
明らかなバグがないか
既存機能を壊していないか
テストが足りているか
を確認する役割です。
この担当は、むしろ自分で実装を直さず、まず問題を見つける方が役割として分かりやすい場合があります。
デザイン
画面を見て、
余白が不自然ではないか
PCとスマホで崩れていないか
UIの統一感があるか
「AIが作った感じ」が強くなっていないか
を確認する役割です。
実装担当と同じAIにそのままレビューさせると、自分で書いたものを自分で正しいと判断してしまうような流れになりやすい。
だから、見る観点そのものを分けたいと思いました。
分けるメリットは「専門性」より「責任範囲がはっきりすること」
サブエージェントというと、「専門家AIを作る」というイメージが強いです。
もちろんそれもあります。
ただ、自分が実際の開発フローを考えていて、より重要だと思ったのは責任範囲を狭くできることでした。
一つのAIに、
実装して、テストして、デザインも見て、セキュリティも確認して、最後にレビューして。
と頼むことはできます。
でも、タスクが大きくなるほど「結局どこまでちゃんと確認した？」が分かりにくくなります。
それなら、
実装担当は実装する。
QA担当は壊れていないかを見る。
デザイン担当は画面を見る。
と分けた方が、自分も結果を確認しやすい。
人間のチーム開発とまったく同じではありませんが、役割の境界を作ることでレビューしやすくなるという部分はかなり近い気がしています。
ツールや権限を分けられるのも大きい
Claude Codeのカスタムサブエージェントでは、使えるツールや権限を絞ることができます。
たとえばレビュー担当なら、コードを読むことはできても、変更まではできないようにする。
一方、実装担当には編集やコマンド実行を許可する。
こうすると、
「レビューだけしてほしいのに、勝手に直し始めた」
みたいなズレを減らせます。
AIへの指示は文章だけでもできますが、仕組みとして権限を制限できるのはかなり大きいです。
役割を分ける意味は、プロンプトを変えるだけではなく、そのAIが何をしてよいかまで変えられることにあります。
じゃあ全部サブエージェントに分ければいいのか
ここは逆でした。
細かく分けすぎると、今度は管理する側が大変になります。
たとえば、
HTML担当
CSS担当
TypeScript担当
テスト担当
アクセシビリティ担当
SEO担当
パフォーマンス担当
まで全部別にしたら、たしかに専門っぽくは見えます。
でも小さな個人開発でそこまで分けると、誰に何を頼むか考えるだけで面倒です。
エージェント間で同じ説明を何度も渡す必要も出てきます。
自分は今のところ、
「その役割だけ別コンテキストにしたい理由があるか？」
で考えるのが分かりやすいと思っています。
理由がないなら、メインのAIにそのまま頼めばいい。
分けた方がよさそうな作業
自分なりに整理すると、サブエージェント化しやすいのはこんな作業です。
大量の調査
コードベース探索、ログ確認、依存関係の調査など。
途中経過をメインに全部残す必要がなく、最後に結果だけ欲しい作業です。
観点を変えたいレビュー
実装者とは別の視点で、QA、セキュリティ、UIなどを確認したいとき。
同じ役割を何度も繰り返す作業
毎回ほぼ同じ指示でレビューしているなら、役割として定義しておく意味があります。
逆に、数分で終わる単発の修正まで毎回サブエージェントに渡す必要はなさそうです。
「サブエージェント」と「複数AIを並列で動かす」は少し違う
ここはOrcaを触っていても混ざりやすかった部分です。
Claude Codeのサブエージェントは、基本的には一つのセッションの中で専門タスクを別コンテキストへ委任する仕組みです。
一方で、複数の独立したセッションを同時に走らせたり、worktreeを分けて並列実装したりするのは、もう少し大きな単位の話です。
Claude Codeの公式ドキュメントでも、サブエージェントとAgent Teamsは別の仕組みとして整理されています。
つまり、
「レビューだけ別担当へ渡す」
と
「機能Aと機能Bを別々のAIに同時実装させる」
は似ているようで、目的が違います。
自分はここを分けて考えるようになってから、エージェント構成を考えやすくなりました。
今は「AIを何人使うか」より「どこを分けるか」を考えたい
AIコーディングを使い始めた頃は、一つのAIにどこまでうまく指示するかを考えていました。
でも最近は、その先に、
どの作業を同じコンテキストで続けるのか。
どの作業は別の担当へ渡すのか。
どこから人間が確認するのか。
という設計があると感じています。
自分もまだ、コーディング・QA・デザインの分け方を試している途中です。
なので現時点では「この構成が正解」とまでは言えません。
ただ、少なくとも、
サブエージェントはAIを増やすためではなく、仕事とコンテキストを分けるために使う。
と考えると、かなり分かりやすくなりました。
AIに全部やらせるほど、人間側には「どう仕事を分けるか」が必要になる。
そのあたりは、これから実際の個人開発でももう少し詰めていきたいところです。
