Claude Code のサブエージェント(.claude/agents)の作り方と使いどころ

Claude Code 公開:

Claude Code のサブエージェントを定義する方法を解説します。.claude/agents に置く Markdown の書き方、tools と model の指定、レビュー用・調査用エージェントの実例、メインのコンテキストを汚さない使い方を紹介します。

検証日 2026年9月7日 仕様変更が早い分野です。最新の公式ドキュメントも併せてご確認ください。
目次
  1. サブエージェントの仕組み
  2. 定義ファイルの書き方
  3. 実例 1:調査専用エージェント(読み取りのみ)
  4. 実例 2:テスト実行エージェント
  5. 実例 3:ドキュメント更新エージェント
  6. 呼び出し方
  7. 使いどころと注意点
  8. まとめ

コードベース全体を調べさせると、Claude が読んだファイルの内容がすべてコンテキストに残り、その後の作業精度が落ちます。レビューを頼むと、レビュー観点の長い指示が本来のタスクと混ざります。

こうした問題を解決するのが サブエージェントです。サブエージェントは独立したコンテキストと専用の指示を持つ Claude で、メインの Claude が必要に応じて呼び出します。この記事では、定義ファイルの書き方と、効果が出やすい使い方を解説します。

KEY POINT

この記事で分かること

  • .claude/agents/ に置く定義ファイルの書き方
  • tools・model の指定と、description による自動呼び出しの制御
  • 調査用・レビュー用・テスト用の実例

サブエージェントの仕組み

メインの Claude がタスクを分解し、一部をサブエージェントに委任します。サブエージェントは自分のコンテキストで作業し、結果の要約だけをメインに返します。

項目メインサブエージェント
コンテキスト会話全体委任された指示 + 自分が読んだ内容
システムプロンプトClaude Code 本体 + CLAUDE.md定義ファイルの本文
使えるツールすべて(permissions に従う)tools で限定可能
モデルセッションの設定model で個別指定可能

/agents コマンドで、定義済みのエージェント一覧の確認と、対話的な新規作成ができます。

定義ファイルの書き方

プロジェクト用は .claude/agents/<名前>.md、ユーザー全体用は ~/.claude/agents/<名前>.md に置きます。

---
name: code-reviewer
description: コード変更のレビューを行う。ユーザーがレビューを求めたとき、または実装が完了して差分が生まれたときに使う。
tools: Read, Grep, Glob, Bash(git diff:*), Bash(git log:*)
model: claude-opus-5
---

あなたはこのプロジェクトのシニアレビュアーです。`git diff` で変更内容を取得し、次の観点でレビューしてください。

1. CLAUDE.md の規約への適合
2. バグの可能性(境界値、null、例外処理)
3. セキュリティ(入力検証、秘密情報、インジェクション)
4. テストの有無と妥当性

出力は「重大 / 改善提案 / 軽微」に分類し、ファイル名と行番号を必ず添えてください。
コードの修正は行わず、指摘だけを返してください。
キー意味
nameエージェント名(英小文字とハイフン)
descriptionいつ使うか。自動呼び出しの判断材料になるため具体的に書く
tools使えるツールの一覧。省略するとメインと同じ
model使用モデル。省略するとセッションと同じ

用語解説

description の書き方: 「〜のときに使う」と条件を書くと自動呼び出しが安定します。逆に「ユーザーが明示的に依頼したときのみ使う」と書けば、勝手に呼ばれるのを防げます。

実例 1:調査専用エージェント(読み取りのみ)

---
name: explorer
description: コードベースの調査。「〇〇はどこで実装されているか」「△△の呼び出し元を洗い出して」のような質問で使う。ファイルの変更は行わない。
tools: Read, Grep, Glob
model: claude-sonnet-5
---

質問に対して、関連するファイルと該当箇所(ファイル名:行番号)を列挙し、
処理の流れを 10 行以内で要約してください。推測は「推測」と明記してください。

読み取りツールだけを許可しているので、誤って変更されることがありません。軽量なモデルを指定して費用を抑えています。調査で読んだ大量のファイルはサブエージェント側のコンテキストに残り、メインには要約だけが返ります(コンテキスト管理)。

実例 2:テスト実行エージェント

---
name: test-runner
description: テストを実行して結果を分析する。実装後の検証や、テスト失敗の原因調査で使う。
tools: Read, Bash(npm test:*), Bash(npx vitest:*), Grep
---

指示されたテストを実行し、結果を次の形式で返してください。

- 実行コマンド
- 成功 / 失敗数
- 失敗したテストごとに: テスト名、エラーの要約、原因の推定(該当ファイル:行番号)

テストコードや実装の修正は行わないでください。

実例 3:ドキュメント更新エージェント

---
name: doc-writer
description: 実装変更に合わせて README や docs/ 配下のドキュメントを更新する。実装完了後に使う。
tools: Read, Edit, Write, Grep, Glob
model: claude-sonnet-5
---

`git diff` で変更内容を把握し、影響を受けるドキュメントを更新してください。
コードは変更しないでください。更新したファイルの一覧を最後に報告してください。

呼び出し方

  • 自動: description の条件に合う状況で、メインの Claude が自動的に委任します。
  • 明示: 「code-reviewer エージェントで今の差分をレビューして」と伝えます。
  • スキルから呼ぶ: /review のようなスラッシュコマンドの本文で「code-reviewer サブエージェントを使うこと」と指示すると、コマンドとエージェントを組み合わせられます(スラッシュコマンドの作り方)。

使いどころと注意点

向いている向いていない
広範な調査(結果の要約だけ欲しい)メインの会話の文脈を前提にした細かい修正
観点が決まったレビュー対話しながら方針を決める作業
独立して検証できる作業(テスト、lint)前後の作業と密結合したステップ

サブエージェントはメインの会話を知らない

「さっき話した方針で」のような指示はサブエージェントに伝わりません。メインの Claude が委任時に必要な情報をすべて渡す必要があるため、定義ファイルに「委任時には対象ファイルと目的を明記すること」と書いておくと安定します。

サブエージェントは並列に動かすこともできます。ただし、複数のサブエージェントが同時に同じファイルを編集する設計は避けてください。ファイルを跨いだ大きな並列作業は、git worktree による並列作業 の方が安全です。

まとめ

  • .claude/agents/<名前>.md に name / description / tools / model と本文を書く
  • description に「いつ使うか」を具体的に書くと自動呼び出しが安定する
  • 調査は読み取り専用 + 軽量モデル、レビューは高性能モデル、のように役割ごとに設定する
  • サブエージェントはメインの会話を知らないため、委任時に必要な情報をすべて渡す

よくある質問

サブエージェントはメインの会話履歴を見られますか?
見られません。サブエージェントは独立したコンテキストで動き、メインから渡された指示と自分が読んだ内容だけを持ちます。結果は要約としてメインに返されます。
サブエージェントはいつ呼ばれますか?
description に書いた条件に基づいて Claude が自動で判断します。「〇〇エージェントを使って」と明示的に指示することもできます。
サブエージェントにモデルを指定できますか?
frontmatter の model で指定できます。調査など軽い作業は Sonnet、判断が必要な作業は Opus、のように使い分けると費用を抑えられます。

参考にした一次情報

この記事は公式ドキュメントを基に AI が下書きを作成し、運営者が内容を確認して公開しています。誤りを見つけた場合はお問い合わせからお知らせください。