Claude Code サブエージェントの作り方・使い方｜.claude/agents で専門エージェントに分担させる【2026年版】

結論：サブエージェントは「別コンテキストの専門AI」を1ファイルで作れる

Claude Code のサブエージェントは、独立したコンテキストウィンドウを持つ専門AIです。本体（メインの会話）とは別の文脈で動くので、大量のファイル探索やログ解析をさせても本体の会話履歴を圧迫しません。役割特化のシステムプロンプトを与えられるため、レビュー・デバッグ・調査などの精度も上がります。

作り方はシンプルで、.claude/agents/<名前>.md に frontmatter とシステムプロンプトを書くだけ。この記事では、作り方・呼び出し方・設計の勘所・よくある失敗を、実例つきで解説します。

サブエージェント・スキル・スラッシュコマンドの違い

混同しやすいので最初に整理します。

「本体を汚したくないほど大量」「並列にできる」「専門プロンプトで精度が変わる」作業はサブエージェント、「手順を本体に教えたいだけ」ならスキル、という切り分けが基本です（スキルは Claude Code Skills の使い方 で詳説）。

作り方：最小サブエージェント

.claude/agents/code-reviewer.md を作ります。

---
name: code-reviewer
description: コードの変更をコミット前にレビューする専門エージェント。バグ・セキュリティ・可読性の観点で指摘する。「レビューして」「コミット前に確認」などで使う。
tools: Read, Grep, Glob
model: sonnet
---

あなたはシニアコードレビュアーです。与えられた差分やファイルを読み、
次の観点で具体的に指摘してください。

1. バグ・ロジックの誤り（再現条件を添える）
2. セキュリティ（入力検証・権限・秘密情報の扱い）
3. 可読性・命名・重複
4. テストの不足

指摘は「該当箇所 → 問題 → 修正案」の形式で、重要度順に並べてください。
問題がなければ「問題なし」と明言してください。コードの変更は行わず、レビューに徹します。

これだけで code-reviewer サブエージェントが使えます。要素を分解すると：

• name：識別子。呼び出しの目印になります。
• description（最重要）：いつこのエージェントを使うかを書きます。ここが自動委譲のトリガーになるので、「何をする/どんな指示で呼ぶか」まで具体的に書くほど適切に呼ばれます。
• tools：使えるツールの allowlist（カンマ区切り）。省略すると本体の全ツールを継承します。レビュー専用なら読み取り系（Read/Grep/Glob）に絞るのが安全。
• model：sonnet / opus / haiku / inherit。作業の重さに合わせて選びます。
• 本文：そのエージェント専用のシステムプロンプト。役割・手順・出力形式・禁止事項を具体的に書きます。

/agents コマンドで作るのが安全

手書きで frontmatter を間違えると認識されないことがあります。Claude Code 内で /agents を実行すると、対話式でサブエージェントを作成・編集でき、雛形が正しく生成されます。最初はこちらを使うのが確実です。

使い方：自動委譲と明示呼び出し

サブエージェントの呼ばれ方は2通りあります。

自動委譲：タスクが description に合致すると Claude が自動的に委譲します。上の例なら「この変更をレビューして」と言うだけで code-reviewer が動きます。

明示呼び出し：「code-reviewer エージェントを使ってこの差分を見て」のように名前で指定すれば確実に呼べます。

自動委譲を効かせる鍵は、繰り返しになりますが description の具体性です。「コードを見る」ではなく「コミット前にバグ・セキュリティ・可読性をレビューする。『レビューして』で使う」のように、役割とトリガーを両方書きます。

配置場所：プロジェクト用とユーザー用

同名があればプロジェクト側が優先されます。チームで揃えたいものはプロジェクト、自分用はユーザー、と使い分けます。

設計の勘所：何を分担させると効くか

サブエージェントが効くのは次の3パターンです。

1. コンテキスト分離：「このリポジトリ全体から認証処理を探して」のような大量探索を別コンテキストで行い、結果の要約だけ本体に返す。本体の会話履歴を消費しません。
2. 専門化：レビュー専用・デバッグ専用・調査専用など、役割特化のシステムプロンプトを与えると、汎用プロンプトより精度が上がります。
3. 並列：読み取り専用の調査を複数同時に走らせて速くする（例：3つのモジュールを別々のエージェントが同時に調査）。

逆に効かないのは、「1ファイルを読んで1箇所直す」のような本体で完結する逐次作業です。委譲には別コンテキスト起動と結果受け渡しのオーバーヘッドがあるので、軽い作業は本体で直接やる方が速い。何でも委譲すると逆に遅くなるのが最大の落とし穴です。

よくある失敗と対処

• 呼ばれない：description が曖昧。「何をする/いつ使う」を具体化し、トリガーになる言い回しを入れる。
• 権限が広すぎる：tools 省略で全ツール継承。読み取り専用エージェントには書き込み系を渡さない。
• モデルがミスマッチ：単純調査に opus は過剰、複雑設計に haiku は不足。責務に合わせて選ぶ。
• 責務が大きすぎる：1エージェント=1責務。レビューと実装を1つに詰め込まない。役割ごとに分ける。

チーム運用：レビューを後段に挟む

実務で効果が高いのは、実装→レビューのパイプラインです。実装系エージェントの出力を、コミット前に必ずレビュー専用エージェント（上の code-reviewer）に通す運用を決めると、品質が安定します。.claude/agents/ に置いてGit管理し、チーム全員が同じエージェント構成を使えるようにします。

まとめ

• サブエージェント=独立コンテキストの専門AI。.claude/agents/<name>.md で作る
• frontmatter は name / description（自動委譲のトリガー、最重要）/ 任意で tools / model、本文がシステムプロンプト
• /agents コマンドで作ると frontmatter の漏れがなく安全
• 効くのは「コンテキスト分離・専門化・並列」。逐次の軽作業は委譲しない
• プロジェクト用とユーザー用を使い分け、tools は最小権限、1エージェント=1責務

手を動かして定着させる：サブエージェント設計は実際のリポジトリで試すと一気に腑に落ちます。当サイトの「バイブコーディング実践編」では Claude Code を業務コードに使う際の安全設定・許可コマンド・レビュー文化を、提出物テンプレ + 採点ルーブリック付きの演習で扱います。4週間限定で無料公開中。

関連ガイド：

• Claude Code Skills とは・使い方・作り方 — サブエージェントと並ぶ拡張機能
• Claude Code 入門 — CLI の環境構築と基本
• Claude Code チュートリアル — 実例タスクで使い方を学ぶ
• Claude Agent SDK 入門 — 自前アプリにエージェントを組み込む
• Claude Code セキュリティガイド — エージェント運用のツール権限統制