複雑な開発タスクをClaude Codeに頼んでいて、会話が長くなるほど話が噛み合わなくなってきた……そんな経験はありませんか？コードレビュー、テスト実行、ドキュメント作成など、毎回似たような作業を頼んでいるなら、それぞれ専用の「サブエージェント」を用意するだけで、会話の質も作業スピードも大きく変わります。この記事では、業務で実際に役立つサブエージェントを5つ厳選し、設定例つきで紹介します。

結論：業務で頻発する「決まった作業」はサブエージェント化すると効率が跳ねます

結論から言うと、コードレビューやテスト実行のように「毎回同じような依頼を繰り返している作業」は、専用のサブエージェントとして.claude/agents/に定義しておくのが一番効果的です。一度作っておけば、Claudeが依頼内容を見て自動的にそのサブエージェントへ振り分けてくれるので、毎回同じ指示文を書く手間も省けます。同じような依頼を毎回書き直していませんか？その手間、5つのサブエージェントでかなり減らせます。

なぜサブエージェントが業務効率化に効くのか

理由は大きく2つあります。1つは、サブエージェントが独立したコンテキストウィンドウで動くため、テストの詳細な出力やログの全文といった「ノイズ」がメイン会話に流れ込まず、結果だけが返ってくる点です。もう1つは、サブエージェントごとに使えるツールやモデルを制限できるため、レビュー専用なら読み取りだけ許可する、探索系なら安いモデルに任せる、といったコスト管理がしやすくなる点です。私はこの仕組みを知ってから、メイン会話がログだらけで読みにくくなる問題がかなり減ったと感じました。

エンジニアなら読むべき本を30冊以上紹介しています。
正直、私の仕事のやり方をガラッと変えた神本やSQLのチューニングに悩んだ時にめちゃくちゃ役に立ったもあります👇
→記事を読む

業務に役立つサブエージェント厳選5選

まずは全体像を表で確認してください。それぞれ「どんな業務課題を解決するか」を軸に選んでいます。

No	サブエージェント名	解決する業務課題	主なツール権限
1	code-reviewer	コードレビューの抜け漏れ・属人化	Read, Glob, Grep
2	security-reviewer	セキュリティチェックの形骸化	Read, Grep, Bash
3	test-runner	テスト結果確認の手間	Read, Bash
4	docs-writer	ドキュメント整備の後回し	Read, Write, Edit
5	log-investigator	障害調査・ログ確認の長時間化	Read, Grep, Bash

サブエージェントは.claude/agents/（プロジェクト単位）または~/.claude/agents/（ユーザー単位）にMarkdownファイルとして定義します。/agentsコマンドを使えば対話形式で作成できますし、手書きでも問題ありません。

1. code-reviewer：コードレビュー専用サブエージェント

レビューの観点を毎回口頭で説明するのは大変です。観点を固定したサブエージェントを作っておけば、コミットごとに同じ基準でチェックしてもらえます。

---
name: code-reviewer
description: 直近の差分に対してコード品質・命名・設計観点でレビューする。コミット前やPR作成前に使う。
tools: Read, Glob, Grep
model: sonnet
---

あなたはコードレビュー担当です。`git diff`の内容を確認し、可読性・命名規則・重複コード・設計の一貫性の観点で指摘してください。修正コードは書かず、指摘内容と理由だけを返してください。

❌ 「コードレビューして」と毎回ゼロから指示する
✅ レビュー観点を固定したサブエージェントに任せる

2. security-reviewer：セキュリティレビュー専用サブエージェント

認証・決済・個人情報を扱う部分の変更は、見落としが起きやすいポイントです。専用のサブエージェントに「使うべきタイミング」まで書いておくと、Claudeが自動的に呼び出してくれるようになります。

---
name: security-reviewer
description: 認証・決済・個人情報に関わる変更がある場合に、必ず使う。SQLインジェクション・認可漏れ・機密情報の埋め込みをチェックする。
tools: Read, Grep, Bash
model: sonnet
---

あなたはセキュリティレビュー担当です。差分の中から認証処理・SQL生成・外部入力の扱いを確認し、重大度（CRITICAL/HIGH/MEDIUM/LOW）付きで報告してください。修正は提案のみで、ファイルは変更しないでください。

3. test-runner：テスト実行＆失敗レポート専用サブエージェント

テストの全文出力をメイン会話に流すと、それだけで文脈が埋まってしまいます。失敗したテストだけ抜き出して報告してもらいましょう。

---
name: test-runner
description: テストスイートを実行し、失敗したテストとエラーメッセージだけを要約して報告する。
tools: Read, Bash
model: haiku
---

テストコマンドを実行し、失敗したテストケース名とエラーメッセージのみを抜き出して報告してください。成功したテストの詳細は出力しないでください。

◎ 探索系・実行系の作業は、コストを抑えるためHaikuのような軽量モデルに任せるのもおすすめです。

4. docs-writer：ドキュメント作成・校正専用サブエージェント

「あとでまとめて書こう」と後回しにされがちなドキュメント作業も、専用サブエージェントに任せれば実装と同じ流れで進められます。

---
name: docs-writer
description: 実装が完了した機能のREADMEやAPIドキュメントを作成・更新する。
tools: Read, Write, Edit
model: sonnet
---

実装内容を読み取り、READMEまたはドキュメントファイルを更新してください。です・ます調ではなく簡潔な技術文書の文体で、使用例を含めて記述してください。

5. log-investigator：障害調査・ログ確認専用サブエージェント

障害対応のたびにログを延々と読み込むのは時間がかかります。調査専用のサブエージェントに切り出すことで、メイン会話は「結論を聞く」だけの状態を保てます。

---
name: log-investigator
description: エラーログや障害report調査が必要なときに使う。原因の候補と発生箇所を要約して返す。
tools: Read, Grep, Bash
model: sonnet
---

指定されたログファイルを調査し、エラーの発生時刻・頻度・関連するスタックトレースを要約してください。原因の候補を優先度順に提示し、ログの全文はそのまま出力しないでください。

さらに深掘り：サブエージェント運用でつまずきやすいポイント

5つのサブエージェントを作って終わり、ではありません。実際に運用してみると、いくつか共通のつまずきポイントがあります。

つまずきポイント	原因	対策
ファイルを編集したのに反映されない	サブエージェントはセッション開始時に読み込まれる	ファイルを直接編集した場合はセッションを再起動する
自動で呼ばれない	descriptionが曖昧で、Claudeが使うタイミングを判断できない	「〜のときに必ず使う」のように条件を明確に書く
名前が衝突して片方しか使われない	同じスコープ内に同名のファイルがある	プロジェクト用・ユーザー用でも名前は一意にする
コストがかさむ	すべてSonnetやOpusで動かしている	探索・実行系はHaikuなど軽量モデルに任せる

私自身、最初はdescriptionを「コードをレビューする」のように短く書いてしまい、Claudeが自動で呼んでくれないことがよくありました。今は「〜の変更があったときに必ず使う」というように、トリガーとなる条件を一文目に書くよう意識しています。この書き方に変えてから、自動delegationの精度がはっきり上がったと感じます。

名前付きで明示的に呼び出すこともできる

自動delegationに任せず、「code-reviewerサブエージェントで最新のコミットを見て」のように名前を指定して呼び出すこともできます。チームメンバーに使い方を共有するときは、この明示呼び出しのほうが伝わりやすい場合もあります。

まとめ

✅ 毎回同じような依頼を繰り返す作業は、専用サブエージェントに切り出すと効率が上がる
✅ code-reviewer／security-reviewer／test-runner／docs-writer／log-investigatorの5つは特に業務で出番が多い
◎ descriptionには「使うべきタイミング」を条件文として明記する
✅ 探索・実行系のサブエージェントは、軽量モデルにルーティングしてコストを抑える
◎ ファイルを直接編集したときは、セッションを再起動して反映を確認する

エンジニアなら読むべき本を30冊以上紹介しています。
正直、私の仕事のやり方をガラッと変えた神本やSQLのチューニングに悩んだ時にめちゃくちゃ役に立ったもあります👇
→記事を読む