サブエージェントを効果的に使う

You know how to create sub agents and design them well. sub agentの作り方と設計方法はすでに習得しています。 Now, let's cover when they actually help and when they get in the way. 次は、実際に役立つ場面と逆効果になる場面を解説します。 Simply put, the difference comes down to whether the intermediate work matters to your main thread. 端的に言えば、中間作業の結果がメインスレッドにとって重要かどうかが分岐点です。 When exploration is separate from execution, sub agents shine. 探索と実行が分離されているとき、sub agentは真価を発揮します。 When each step depends on what the previous step discovered, well, information gets lost in the handoff process. 各ステップが前のステップの発見に依存する場合、情報は引き継ぎの過程で失われます。 Sub agents excel at research tasks where you just need an answer, not the journey. sub agentは調査タスクが得意です。旅路ではなく答えだけが必要な場合に向いています。 Consider investigating how authentication works in an unfamiliar code base. 例えば、不慣れなコードベースで認証の仕組みを調べる場合を考えてみてください。 Well, the main thread might need to know where is the JWT validated, but doesn't need to see every file that was searched. メインスレッドが必要なのはJWT検証がどこで行われているかであり、検索したすべてのファイルを見る必要はありません。 A research sub agent can read dozens of files, trace through function calls, and explore different code paths. 調査用sub agentは数十ファイルを読み込み、関数呼び出しを追跡し、異なるコードパスを探索できます。 All that exploration stays in the sub agent's context. その探索はすべてsub agentのコンテキスト内に留まります。 Your main thread receives JWT validation happens in middleware/auth.js at line 42, called from the Express router and route/api.js, or something like that. メインスレッドが受け取るのは「JWTの検証はmiddleware/auth.jsの42行目で行われ、Expressルーターとroute/api.jsから呼び出されています」といった情報です。 Claude reviews work more effectively when the code is presented as being authored by someone else. コードが他者が書いたものとして提示されると、Claudeのレビューはより効果的になります。 If you build a feature over many turns with your main thread, asking the main thread to then review it often doesn't give the best feedback. メインスレッドで長い会話の末に機能を構築し、そのまま同じスレッドにレビューを依頼しても、最善のフィードバックは得られないことが多いです。 Claude was involved in creating it, so it has trouble seeing it with fresh eyes. Claudeが作成に関わっているため、新鮮な目で見直すことが難しくなります。 A reviewer sub agent sees the changes in a separate context. レビュー用sub agentは別のコンテキストで変更を確認します。 It runs get diff, reads the modified files, and applies its specialized review criteria without the history of how the code was written. git diffを実行し、変更ファイルを読み込み、コードの作成経緯を知らない状態で専門的なレビュー基準を適用します。 And this separation also lets you encode project-specific review standards in the sub agent system prompt, ensuring consistent review criteria across the team. この分離により、sub agentのsystem promptにプロジェクト固有のレビュー基準を組み込み、チーム全体で一貫したレビューを実現できます。 Claude Code's default system prompt emphasizes concise, code-focused response. Claude Codeのデフォルトsystem promptは、簡潔でコード中心の応答を重視しています。 And this works great for coding, but not for everything. コーディングには最適ですが、すべての用途に適しているわけではありません。 So, one is a copywriting sub-agent with instructions about tone, audience, and style. 例えば、トーン・対象読者・スタイルに関する指示を持つコピーライティングsub agentを使う場合があります。 This will produce better marketing text than the main thread would. これにより、メインスレッドよりも優れたマーケティングテキストが生成されます。 Claude Code's default prompt tends towards concise, technical writing, which really isn't what you want for a landing page or email campaign, unless you want to put your customers to sleep. Claude Codeのデフォルトプロンプトは簡潔な技術的文章に偏っており、ランディングページやメールキャンペーンには向いていません。顧客を眠らせたいのでなければ。 A copywriting sub-agent can have completely different instructions about voice and structure. コピーライティングsub agentは、表現と構成について全く異なる指示を持てます。 A styling sub-agent that at mentions your design system files will apply consistent CSS patterns. デザインシステムのファイルを参照するスタイリングsub agentは、一貫したCSSパターンを適用します。 When the sub-agent runs, those files load into the context automatically, so it knows your color variables, spacing conventions, and component patterns before it even starts writing any CSS. sub agentが起動すると、それらのファイルはコンテキストに自動的に読み込まれるため、CSSを書き始める前から色変数・余白規則・コンポーネントパターンを把握しています。 Sub-agents that claim expertise rarely help. 専門性を主張するsub agentはほとんど役に立ちません。 Prompts like, "You are a Python expert." or "You are a Kubernetes specialist." add no value because Claude already has that knowledge. 「あなたはPythonの専門家です」「あなたはKubernetesのスペシャリストです」といったプロンプトは無意味です。Claudeはすでにその知識を持っているからです。 The overhead of launching a sub-agent, losing visibility into its work, and compressing its findings into a summary only makes sense when the sub-agent does something that the main thread can't. sub agentを起動するコスト、つまり可視性の喪失と発見のサマリー圧縮が正当化されるのは、メインスレッドにできないことをする場合だけです。 Like applying a custom system prompt or keeping exploratory work isolated. カスタムsystem promptの適用や、探索的作業の隔離などがその例です。 Sequential sub-agent pipelines create problems. 順次実行のsub agentパイプラインは問題を引き起こします。 Consider a three-agent flow. 3つのsub agentフローを考えてみましょう。 One to reproduce a bug, one to debug it, and one to fix it. 1つ目がバグの再現、2つ目がデバッグ、3つ目が修正を担当します。 Pipelines work when tasks are truly independent. パイプラインはタスクが真に独立しているときに機能します。 They fail when each step depends on discoveries from the previous step. 各ステップが前のステップの発見に依存する場合、パイプラインは機能しません。 Test runner sub-agents tend to hide information you need. テストランナーsub agentは必要な情報を隠しがちです。 When tests fail, you want the full output to diagnose issues. テストが失敗したとき、問題を診断するには完全な出力が必要です。 A sub-agent that returns a test failed forces you to create additional debug scripts to get details that would have been visible in direct output. 「テスト失敗」とだけ返すsub agentは、直接の出力なら見えていたはずの詳細を得るために、追加のデバッグスクリプトを書くことを強います。 Testing has showed that the test runner pattern performed worse among all configurations. テストにより、テストランナーパターンはすべての構成の中で最も成績が悪いことが示されています。 Across the series, we covered how sub-agents work as isolated threads that return summaries. このシリーズでは、sub agentが独立したスレッドとしてサマリーを返す仕組みを解説しました。 How to create them with the /agents command, and how to design them with structured outputs and specific descriptions. /agentsコマンドでの作成方法と、構造化された出力と明確な説明を使った設計方法も取り上げました。 Use them for research, reviews, and tasks needing custom system prompts. 調査・レビュー・カスタムsystem promptが必要なタスクにsub agentを活用してください。 But, avoid them for expert claims, multi-step pipelines, and test runners. ただし、専門性の主張・多段階パイプライン・テストランナーへの使用は避けてください。 The key question, does the intermediate work matter? 核心的な問いは、中間作業の結果が重要かどうかです。 If not, then delegate it. 重要でなければ、委任してください。