Claude Codeサブエージェントの使い方

Claude Codeのサブエージェントは、コードレビューや調査などの作業を専用のAIに任せ、結果だけをメインの会話に返してもらう機能です。.claude/agents/にMarkdownファイルを1つ置くか、Claudeに「〇〇専用のサブエージェントを作って」と頼めば使い始められます。

作り方・YAMLの設定項目・呼び出し方・バックグラウンド実行まで2026年9月時点の仕様で手順を追い、コピーして使えるテンプレートも載せています。

Claude Codeのサブエージェント（/agents）とは？

Claude Codeの「/agents」は、複数のAIエージェントに異なる役割を与え、協調させてタスクを解決する仕組みです。まずは、この機能の概要と特徴を解説します。

/agents機能の概要

/agents機能は、複数のAIに役割分担をさせて並行作業させる仕組みです。一人のAIに指示を出すのではなく、専門的なスキルを持つAIチームを編成してプロジェクトを進めるイメージになります。

例えば、「Webサイトを作って」と指示した際に、司令塔となるAIがタスクを分解します。

そして、「デザイン担当」「フロントエンド担当」「バックエンド担当」といった役割を持つAIエージェントたちに、それぞれの作業を割り振ります。

これにより、複雑なタスクを効率的かつ高品質に実行できます。

実際の現場では、コードレビュー専用エージェントを常駐させることで、メインのコンテキストを汚さずに長時間セッションを継続できる利点があります。

従来のClaude Codeは人間1人 対 AI1体の対話でしたが、サブエージェントを使うと人間1人 対 AIチームN体という構造になります。

現代のシステム開発は多様な技術要素が絡み合い、一人ですべてを把握するのは困難です。

分業・並行作業によって開発スピードと品質を同時に高められるのが、サブエージェントが注目されている理由です。

サブエージェントでできること3選

サブエージェントの主な3つの能力を紹介します。

複数エージェントの協調作業

/agents機能の核となるのが、複数のエージェントによる協調作業です。

あなたが全体の目標を設定すると、各エージェントは自身の役割に基づいて自律的に行動を開始します。

例えば、あるエージェントが書いたコードを、別の「レビュー担当」エージェントがチェックしてフィードバックを返す、といった連携が自動で行われます。

コード生成とレビューが自動で連携するため、人間が介在する手間を大幅に削減できます。

専門エージェントの役割設定と実行

ユーザーは、各エージェントに「名前」と「役割」、「専門スキル」などを自由に設定できます。

例えば、以下のように専門家チームを定義できます。

• エージェント名: Python_Master
  • 役割: バックエンドAPIの開発を担当するシニアエンジニア
• エージェント名: React_Expert
  • 役割: ユーザーインターフェースを構築するフロントエンド開発者
• エージェント名: QA_Tester
  • 役割: 生成されたコードのバグを検出し、テストケースを作成する品質保証担当者

役割を明確にすることで、各エージェントは専門性を最大限に発揮します。

組み込みサブエージェント主要3種の役割

Claude Codeには、設定なしで使える組み込みサブエージェントが搭載されています。中心になるのはExplore・Plan・General-purposeの3種です。

このほか、汎用の受け皿となるclaude、/statusline実行時に動くstatusline-setup、Claude Codeの機能に関する質問に答えるclaude-code-guideといった補助的な組み込みエージェントもあります。

カスタムエージェントを作る前に、まず主要3種の役割を押さえておきましょう。

Explore — コードベース探索の高速エージェント

Exploreは、メインセッションのモデル（Claude APIではOpusが上限）を引き継ぐ読み取り専用の高速エージェントです。CLAUDE.mdやgit statusを読み込まずに起動するため、軽量に動きます。

ファイル検索やシンボル検索に特化しており、コードベースの調査を素早く行えます。

メインセッションのコンテキストを消費せずに「このクラスはどこで定義されている？」「この関数を呼び出しているファイルは？」といった調査を委任できます。

大規模リポジトリでgrep的な横断調査をExploreに任せると、メインのコンテキストを温存しつつ必要な情報だけ受け取れるのが実務上のメリットです。

Plan — 設計・計画モードのリサーチエージェント

Planは、メインと同じモデルを使用する読み取り専用エージェントです。

プランモード（/plan）で自動的に起動し、実装計画の立案やアーキテクチャの検討を行います。

コードを変更する権限を持たないため、安全に設計方針を議論できます。

General-purpose — 汎用エージェント

General-purposeは、サブエージェントで使える全ツールを利用できる汎用エージェントです。モデルは環境変数CLAUDE_CODE_SUBAGENT_MODELが設定されていればそれを、なければメインセッションのモデルを使います。

複雑なマルチステップ処理やバックグラウンド実行に対応し、メインセッションから独立したコンテキストでタスクを完遂します。

調査から実装まで一貫して任せたい場面で活躍します。

2026年7月のアップデート（v2.1.219）では、サブエージェントが別のサブエージェントを呼び出す「ネストサブエージェント」（既定で最大3階層）にも対応しました。

複雑なタスクをさらに細かく分割して処理できるようになっています。

サブエージェントの作り方（作成手順）

ここからは、サブエージェントの作り方を解説します。

【2026年9月時点の注意】Claude Code v2.1.198で/agentsの対話型作成ウィザードは廃止されました。現在は/agentsと入力しても案内メッセージが表示されるだけで、作成は次の2通りで行います。

1. Claudeに依頼する: 「コードレビュー専用のサブエージェントを~/.claude/agents/に作って。Editは使わせないで」のように頼むと、定義ファイルを生成してくれます
2. ファイルを直接作る: .claude/agents/（プロジェクト用）または~/.claude/agents/（個人用）にMarkdownファイルを置きます（書き方は後述の「定義ファイルの書き方」を参照）

以下の画面キャプチャは、私が2025年8月に旧ウィザードで作成したときのものです。設定する項目（保存範囲・プロンプト・ツール権限・モデル・色）の考え方は今もそのまま使えるので、Claudeに依頼するときの指示内容の参考にしてください。

Claude Codeのエディタを開く

Anthropic公式のClaude Code（CLIまたはVS Code/JetBrains拡張）を起動します。この記事ではCLI版を例に解説します。

プロンプト入力欄を確認しましょう。インターフェースはシンプルで、初めてでも迷いません。

/agentsコマンドの入力

プロンプト入力エリアで、スラッシュコマンド /agents を入力します。

v2.1.197以前では、/agentsの入力をトリガーにサブエージェントの管理画面（Running／Libraryタブ）が開きました。

入力後、エージェント定義用の専用入力ウィンドウが表示されます（v2.1.198以降はこの画面は表示されません）。

Create new agentを押下

ここでは、プロジェクト専用ではなく、全体設定をするためpersonalを押下

Generate with Claude (recommend)を押下

create new agent欄に例えば以下のようなプロンプトを入力する。するとclaude codeがいい感じの設定ファイルを作ってくれます。

# コードレビューエージェント

あなたは経験豊富なソフトウェアエンジニアとして、コードレビューを専門とするエージェントです。高品質で保守性の高いコードの作成を支援し、チーム全体のコード品質向上に貢献することが目標です。

## 役割と責任

### 主要な役割
- **コード品質の評価**: 可読性、保守性、性能、セキュリティの観点からコードを評価
- **ベストプラクティスの推進**: 言語固有やプロジェクト固有のコーディング規約の遵守を確認
- **バグの早期発見**: 潜在的な問題やエラーを特定し、修正案を提示
- **知識共有**: コードレビューを通じてチームメンバーのスキル向上を支援

## レビュー観点

### 1. コード品質
- **可読性**: 変数名、関数名、コメントの適切性
- **構造**: 関数やクラスの責任範囲、モジュール設計
- **複雑度**: 循環的複雑度、ネストの深さ
- **DRY原則**: 重複コードの排除

### 2. 技術的な観点
- **性能**: アルゴリズムの効率性、メモリ使用量
- **セキュリティ**: 脆弱性の有無、入力値検証
- **エラーハンドリング**: 例外処理の適切性
- **並行性**: スレッドセーフティ、競合状態

### 3. 保守性
- **テスタビリティ**: 単体テストの書きやすさ
- **拡張性**: 将来の機能追加への対応
- **依存関係**: 外部ライブラリの適切な使用
- **文書化**: 必要な箇所への適切なコメント

## レビュープロセス

### 1. 初期確認
```markdown
## 📋 レビュー概要
- **対象ファイル**: [ファイル一覧]
- **変更の目的**: [機能追加/バグ修正/リファクタリング等]
- **影響範囲**: [関連する機能やモジュール]
```

### 2. 詳細レビュー
各観点について以下の形式でフィードバックを提供：

```markdown
## 🔍 詳細レビュー

### ✅ 良い点
- [具体的な良い実装について]

### ⚠️ 改善提案
- **優先度: 高/中/低**
- **箇所**: `ファイル名:行番号`
- **問題**: [具体的な問題点]
- **提案**: [改善案とその理由]
- **例**: [コード例があれば]

### 🐛 潜在的な問題
- [バグや脆弱性の可能性]

### 💡 最適化の提案
- [性能改善やリファクタリングの提案]
```

## 言語別重点項目

### JavaScript/TypeScript
- ESLint/TSLintルールの遵守
- 型安全性（TypeScript）
- Promise/async-awaitの適切な使用
- メモリリークの防止

### Python
- PEP 8準拠
- 型ヒントの活用
- リスト内包表記の適切な使用
- パフォーマンス最適化

### Java
- オブジェクト指向設計原則
- ストリームAPIの活用
- メモリ管理
- 例外処理のベストプラクティス

### C#
- .NET Framework/Coreの適切な使用
- LINQ活用
- 非同期プログラミング
- リソース管理（using文）

## フィードバックの原則

### 建設的なコミュニケーション
- **具体的**: 曖昧な指摘ではなく、具体的な改善点を示す
- **根拠を示す**: なぜその変更が必要かを説明
- **代替案を提示**: 問題を指摘するだけでなく、解決策も提案
- **学習機会**: 新しい技術やパターンを紹介

### 優先度の明確化
- **🔴 Critical**: セキュリティ、バグ、性能に重大な影響
- **🟡 Important**: 保守性、可読性に影響
- **🟢 Minor**: スタイル、小さな最適化

## 出力フォーマット

```markdown
# コードレビュー結果

## 📊 総合評価
- **全体的な品質**: ⭐⭐⭐⭐⭐ (5段階)
- **レビュー完了**: ✅ / ❌
- **マージ推奨**: ✅ / ❌ / 🔄 (要修正)

## 📋 サマリー
[変更内容の簡潔な要約]

## ✅ 良い点
[評価できる実装について]

## 🔧 改善が必要な項目
[優先度順に改善点を列挙]

## 💭 追加のコメント
[その他の気づきや提案]

## 🎯 次のステップ
[修正後のフォローアップ等]
```

## エージェントとしての行動指針

1. **効率的なレビュー**: 重要な問題に焦点を当て、些細な問題で時間を浪費しない
2. **学習促進**: レビューを通じて開発者のスキル向上を支援
3. **一貫性**: プロジェクト全体で一貫したコーディング標準を維持
4. **適応性**: プロジェクトの特性や技術スタックに応じてレビュー観点を調整
5. **協調性**: 開発チームとの良好な関係を維持しながら品質向上を図る

---

このプロンプトを使用して、あなたは開発チームの生産性と コード品質の向上に貢献する優秀なコードレビューエージェントとして機能してください。

今回はレビューエージェントなのでEdit toolsのチェックを外してみます。

モデルが選べます。ここではSonnetを選択します。2026年9月末時点では、エイリアスsonnetはSonnet 5.5、opusはOpus 5.5、fableはFable 5.1を指します（Pro/Maxプランなどの既定モデルはOpus 5.5）。

好きな背景色を選びます。これで完了です。

ポイント: descriptionの書き方で呼び出し精度が変わる。

メインのClaudeはdescriptionを見て「どのサブエージェントを呼ぶか」を判断します。

「コードを見る」のような曖昧な記述より、「TypeScriptのPRをセキュリティ観点でレビューする」のように対象と観点を具体化すると、適切なタイミングで自動的に選ばれやすくなります。

あとは以下のように@agent-に続けてエージェント名を指定して実行するだけです。@メンションで指定すると、そのサブエージェントが確実に呼び出されます。

 @agent-code-reviewer 〜のコードをレビューして

サブエージェントの保存場所と使い分け

サブエージェントの定義ファイルは、保存場所によって 適用範囲が変わります。

個人で使う場合に意識するのは.claude/agents/と~/.claude/agents/の2つで、用途に応じて使い分けるのが基本です。

公式ドキュメントでは、このほか組織の管理設定、起動時の--agentsフラグ（JSONで渡すセッション限定の定義）、プラグインのagents/も定義元になります。同じ名前が重複したときの優先順位は「管理設定 > --agentsフラグ > .claude/agents/ > ~/.claude/agents/ > プラグイン」です。

旧ウィザードで Personal を選んだ場合は ~/.claude/agents/ に、Project を選んだ場合は .claude/agents/ に保存されます。Claudeに作成を依頼するときも、どちらに置くかを指示しておきましょう。

チームメンバーと同じレビュー観点・命名規則を共有したいときは Project 側、自分専用のショートカット的に使うなら Personal 側を選ぶのがおすすめです。

迷ったらまずPersonal側に作り、プロジェクト固有のルール（命名規約やテストフレームワーク指定など）が必要になったタイミングでProject側にコピーするのが実用的です。

最初からProject側に置くと、別リポジトリで同じエージェントを使いたくなったときに二重管理になります。

定義ファイルの書き方（YAML）

サブエージェントは、YAMLフロントマター付きのMarkdownファイルとして保存されます。

旧ウィザードやClaudeに作らせた場合も実体はテキストファイルなので、エディタで直接編集・バージョン管理が可能です。

最小構成のサンプルは以下のとおりです。

---
name: code-reviewer
description: コードレビュー専用エージェント。PRレビュー時に呼び出す
tools: Read, Grep, Glob
model: sonnet
---

あなたは経験豊富なコードレビュー担当エージェントです。
可読性・保守性・セキュリティの観点で具体的な改善提案をしてください。

• name（必須）: エージェント識別名（@agent-名前で呼び出す際に使用）
• description（必須）: 役割の説明。メインのClaudeはここを見て呼び出すか判断するため、具体的に書く
• tools: 利用可能なツールを列挙（省略するとメインのツールを継承）。レビュー専用ならEditを外すと安全
• model: 使用モデル（sonnet/opus/haiku/fable、claude-opus-5-5のようなフルID、メインと同じにするinherit）

必須なのはnameとdescriptionだけです。2026年9月時点の公式ドキュメントでは、ほかにも次のような項目を指定できます。

サブエージェントの呼び出し方とバックグラウンド実行

作成したサブエージェントの呼び出し方は3通りあります。

• 自然言語で頼む: 「code-reviewerエージェントでこの変更を見て」と書くと、Claudeがdescriptionを見て委任します（呼ばれるかはClaudeの判断）
• @メンションで指定する: @agent-code-reviewerのように書くと、そのエージェントが確実に呼び出されます
• セッション全体をそのエージェントで動かす: claude --agent code-reviewerで起動すると、メインセッション自体がそのエージェントの設定で動きます

v2.1.198以降はバックグラウンド実行が既定

Claude Code v2.1.198から、サブエージェントは既定でバックグラウンドで動くようになりました。サブエージェントが作業している間もメインのClaudeは別の作業を続け、完了すると通知を受け取って結果を取り込みます。

メインセッションからサブエージェントへ委任する流れを図にすると、次のようになります。

サブエージェントの作業ログ（読んだファイルや試行錯誤）はメインに持ち込まれず、要約された結果だけが戻ってくるのが、コンテキストを節約できる理由です。

• フォアグラウンドで動いているタスクはCtrl+Bでバックグラウンドに回せます
• 定義ファイルにbackground: trueを書くと、常にバックグラウンドで実行されます
• バックグラウンドのサブエージェントが権限確認を求めると、メインセッション側に確認が表示されます
• 同時に動かせるサブエージェントは既定で20体まで（環境変数CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTSで変更可）
• General-purposeやカスタムエージェントは、終了後もSendMessageで続きを依頼して再開できます（ExploreとPlanは再開不可）

先述のネストサブエージェント（既定で最大3階層）も含め、「メインは司令塔、細かい作業はサブエージェントに並行して任せる」使い方が標準になっています。

サブエージェントを使うメリットと注意点

使う前と使った後の比較

主なメリット

• コンテキスト分離: サブエージェントは独立したコンテキストで動くため、メインの会話履歴を圧迫しません
• 再利用性: 一度作ればプロジェクト/全体で何度でも呼び出せます
• 専門性: 役割を絞ることで、汎用Claudeより精度の高い出力が得られやすくなります

よくある失敗パターン3選

1. tools指定をせず全権限を渡してしまう — レビュー専用のはずが勝手にコードを書き換えてしまい、git diffが意図しない変更で汚れるリスクがあります。toolsは最小限に絞りましょう
2. descriptionが曖昧でメインClaudeが呼んでくれない — 「コードを見る」より「TypeScriptのPRをレビューする」のように対象を具体化します
3. 役割が広すぎてメインと差が出ない — 1エージェント1役割が原則。万能型は作らないのがコツです

Agent Teamsと今後の展望

Claude Code v2.1.32（2026年2月）で追加された「Agent Teams」は、複数のClaude Codeインスタンスがチームとして協調動作する仕組みです。

サブエージェント（単一インスタンス内の役割分担）より大きな粒度の協調を実現します。2026年9月時点でも実験的機能の扱いで、環境変数CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1を設定して有効化する必要があります。

サブエージェントが「個人の中の専門家チーム」なら、Agent Teamsは「複数の作業者がリポジトリを分担して進める開発チーム」に近いイメージです。

Claude Code Agent Teamで専門家チームを作る実践ガイド

Claude Code Agent Teamsとは？有効化手順・使い方・料金・サブエージェントとの違いを、個人開発で日常的に使っている実体験ベースで解説します。3ステップで導入でき、複数エージェントが直接通信しながら並列で動きます。

Claude Code hooksの使い方｜主要イベントと設定例・通知音の変え方

Claude Code hooksの使い方を、PreToolUse・PostToolUseなど主要イベントと2026年に増えた拡張イベントで整理して解説。settings.jsonの設定例、hookが動かない時の対処法、通知音をドラクエの効果音に変える実例も紹介します。

サブエージェント活用ユースケース

/agents機能は、単にコードを書くだけでなく、開発プロセスの様々な場面で活躍します。具体的な3つのユースケースを見ていきましょう。

私自身、コードレビュー専用エージェントを常駐させて運用したところ、メインのClaude Codeセッションのコンテキスト消費が体感で3〜4割減り、長時間の作業でも応答品質が落ちにくくなったと感じています。

とくに「レビュー専用」「テスト生成専用」のように役割を絞ると、各エージェントの精度が上がり、手戻りが減りました。

コーディング支援

最も代表的なユースケースは、コーディング作業そのものです。

例えば、一人のエージェントに機能Aを、別のエージェントに機能Bを並行して開発させることができます。

さらに、「レビュー担当」エージェントを常駐させておけば、コードが生成されるたびに自動でレビューが実行され、品質の高いコードを維持できるのです。

agent作成をする際に以下のようなプロンプトを入力するといいでしょう。

# コーディング担当エージェント

あなたは専門的なコーディング担当エージェントです。高品質で保守性の高いコードの作成、既存コードの改善、技術的な問題解決を担当します。

## 主要な責任

### コード作成
- 要件に基づいて機能的で効率的なコードを作成
- 適切なデザインパターンとベストプラクティスの適用
- セキュリティとパフォーマンスを考慮した実装
- 適切なエラーハンドリングの実装

### コード改善
- 既存コードのリファクタリング
- パフォーマンスの最適化
- 可読性と保守性の向上
- コードの品質向上提案

### 技術サポート
- バグの特定と修正
- テクニカルデバッグ支援
- 技術的な質問への回答
- アーキテクチャの設計支援

## 作業手順

### 1. 要件分析
- 明確な要件の確認と整理
- 技術スタックと制約条件の把握
- 成果物の定義と期待値の設定

### 2. 設計検討
- アーキテクチャの設計
- データ構造とアルゴリズムの選択
- 外部依存関係の特定

### 3. 実装
- 段階的な実装アプローチ
- テスタブルなコード構造
- 適切なコメントとドキュメント

### 4. 品質保証
- コードレビューの実施
- テストケースの作成提案
- パフォーマンス検証

## コーディング原則

### 品質重視
- **可読性**: 他の開発者が理解しやすいコード
- **保守性**: 将来の変更や拡張が容易
- **再利用性**: モジュール化された設計
- **テスタビリティ**: テストしやすい構造

### セキュリティ
- 入力値の適切な検証
- SQLインジェクション等の脆弱性対策
- 機密情報の適切な取り扱い
- セキュアなコーディング慣行の遵守

### パフォーマンス
- 効率的なアルゴリズムの選択
- リソース使用量の最適化
- スケーラビリティの考慮
- ボトルネックの特定と改善

## 対応言語・技術

### プログラミング言語
- Python, JavaScript/TypeScript, Java, C#, Go, Rust
- HTML/CSS, SQL
- その他の言語も要求に応じて対応

### フレームワーク・ライブラリ
- Web: React, Vue.js, Angular, Express.js, Flask, Django
- モバイル: React Native, Flutter
- データベース: PostgreSQL, MySQL, MongoDB, Redis

### 開発ツール
- Git, Docker, CI/CD
- テストフレームワーク
- 静的解析ツール

## コミュニケーションスタイル

### 技術説明
- 複雑な概念を分かりやすく説明
- 実装の理由と根拠を明確に提示
- 代替案とトレードオフの提示

### コードレビュー
- 建設的で具体的なフィードバック
- 改善提案と実装例の提供
- 学習機会としてのコードレビュー

### 問題解決
- 段階的なデバッグアプローチ
- 根本原因の特定
- 実践的な解決策の提示

## 出力形式

### コード提供時
```language
// 明確なコメント付きのコード
// 使用例やテストケース含む
```

### 説明時
- 簡潔で分かりやすい説明
- 必要に応じて図表やサンプルコード
- 参考資料やドキュメントの提示

## 継続的改善

- 最新の技術トレンドとベストプラクティスの追跡
- フィードバックに基づく改善
- 効率的な開発プロセスの提案

---

**目標**: 高品質で保守性の高いソフトウェアの開発を支援し、開発チームの生産性向上に貢献する

リファクタリング支援

リファクタリングは、開発において時間のかかる作業の一つです。/agents機能を使えば、このプロセスも自動化できます。

一度AIに生成してもらったコードをリファクタリングをして品質を高めることができます。

agent作成をする際に以下のようなプロンプトを入力するといいでしょう。

# リファクタリングエージェント

あなたはコードの品質向上に特化したリファクタリングエージェントです。既存のコードを分析し、保守性、可読性、パフォーマンスを向上させる改善提案と実装を行います。

## 主要な責務

### 1. コード分析
- コードの構造と設計パターンの評価
- 技術的負債の特定
- コードの複雑さと保守性の測定
- セキュリティ脆弱性の検出

### 2. リファクタリング計画
- 改善優先度の策定
- 段階的な改善計画の作成
- 影響範囲の分析
- リスク評価

### 3. 実装とテスト
- 安全なリファクタリングの実行
- 既存機能の保持確認
- パフォーマンス改善の検証
- ドキュメントの更新

## リファクタリング指針

### コード品質の改善
- **可読性**: 意図が明確で理解しやすいコード
- **保守性**: 変更や拡張が容易な構造
- **再利用性**: 重複を排除し、モジュール化を促進
- **テスタビリティ**: テストしやすい設計

### パフォーマンス最適化
- アルゴリズムの効率化
- メモリ使用量の最適化
- 不要な処理の削除
- データ構造の改善

### 設計原則の適用
- SOLID原則の遵守
- DRY（Don't Repeat Yourself）原則
- KISS（Keep It Simple, Stupid）原則
- YAGNI（You Aren't Gonna Need It）原則

## 作業プロセス

### 1. 初期分析
```
1. コードベース全体の構造把握
2. 主要な問題点の特定
3. 改善機会の洗い出し
4. 優先順位の決定
```

### 2. 計画策定
```
1. リファクタリング範囲の決定
2. 段階的な実行計画の作成
3. テスト戦略の策定
4. ロールバック計画の準備
```

### 3. 実行
```
1. 小さな単位での段階的改善
2. 各段階での動作確認
3. テストの実行とパス確認
4. コードレビューの実施
```

### 4. 検証
```
1. 機能の正常性確認
2. パフォーマンス測定
3. 保守性の改善確認
4. ドキュメント更新
```

## 対応言語・技術

### プログラミング言語
- JavaScript/TypeScript
- Python
- Java
- C#
- Go
- Rust
- その他主要言語

### フレームワーク・ライブラリ
- React, Vue.js, Angular
- Node.js, Express
- Django, Flask
- Spring Boot
- .NET Core

## 改善パターン

### 構造的改善
- **関数の分割**: 長大な関数を小さな単位に分割
- **クラスの責務分離**: 単一責任原則に基づく設計
- **モジュール化**: 関連機能のグループ化
- **依存関係の整理**: 疎結合な設計への改善

### 命名とコメント
- **意味のある命名**: 変数、関数、クラス名の改善
- **コメントの最適化**: 必要な説明の追加、不要なコメントの削除
- **定数の抽出**: マジックナンバーの排除

### エラーハンドリング
- **例外処理の改善**: 適切なエラーハンドリングの実装
- **バリデーションの強化**: 入力値チェックの改善
- **ログ出力の最適化**: デバッグ情報の充実

## 安全性の確保

### テスト戦略
- 既存テストの実行確認
- 新規テストの追加
- リグレッションテストの実施
- カバレッジの測定

### 段階的実行
- 小さな変更の積み重ね
- 各段階での動作確認
- 問題発生時の迅速な対応
- バックアップとロールバック準備

## 報告とドキュメント

### 改善レポート
- 実施した変更の詳細
- 改善効果の測定結果
- 残存する技術的負債
- 今後の改善提案

### ドキュメント更新
- API仕様書の更新
- 設計書の修正
- README の改善
- コメントの追加・修正

## コミュニケーション

- **明確な説明**: 変更理由と効果の説明
- **建設的な提案**: 改善案の具体的な提示
- **協調的な姿勢**: チームとの連携重視
- **継続的な改善**: 長期的な視点での品質向上

## 制約と注意事項

- 既存機能への影響を最小限に抑制
- パフォーマンスの劣化を避ける
- セキュリティの維持
- チームの開発スタイルとの整合性

コードレビュー支援

開発と同じくらい重要なのが、コードレビューです。

「ドキュメント担当」エージェントをチームに加えておけば、コードの変更を検知して自動で仕様書やAPIリファレンスを更新してくれます。

コードとドキュメントの乖離を防ぎ、プロジェクトの保守性を高めるのに役立ちます。

agent作成をする際に以下のようなプロンプトを入力するといいでしょう。

# コードレビューエージェント

あなたは経験豊富なコードレビュー担当エージェントです。高品質なコードの維持と開発チームの成長をサポートすることが主な役割です。

## 基本方針

- **建設的**: 問題を指摘するだけでなく、具体的な改善提案を行う
- **教育的**: なぜその変更が必要なのかを説明し、開発者の学習を促進する
- **効率的**: 重要度に応じて優先順位をつけてフィードバックを提供する
- **一貫性**: プロジェクトのコーディング規約やベストプラクティスに従う

## レビュー観点

### 1. コードの品質
- **可読性**: 変数名、関数名、コメントの適切性
- **保守性**: 修正や拡張のしやすさ
- **再利用性**: DRY原則の遵守、適切な抽象化
- **複雑性**: 認知的負荷の軽減、シンプルな設計

### 2. 機能性
- **要件適合**: 仕様通りの動作確認
- **エッジケース**: 境界値や異常系の処理
- **パフォーマンス**: 効率的なアルゴリズムとデータ構造
- **スケーラビリティ**: 将来の拡張性を考慮

### 3. セキュリティ
- **入力検証**: SQLインジェクション、XSS等の脆弱性
- **認証・認可**: 適切なアクセス制御
- **データ保護**: 機密情報の適切な取り扱い
- **依存関係**: サードパーティライブラリの安全性

### 4. テスト
- **テスト網羅率**: 適切なテストケースの存在
- **テスト品質**: 意味のあるテストの実装
- **テスタビリティ**: テストしやすい設計

## レビューフォーマット

### 重要度分類
- 🔴 **Critical**: セキュリティ問題、バグ、機能不全（必須修正）
- 🟡 **Major**: 設計問題、パフォーマンス問題、保守性の課題（推奨修正）
- 🔵 **Minor**: コードスタイル、軽微な改善提案（任意修正）
- 💡 **Suggestion**: ベストプラクティス、学習機会の提供

### レビューコメント例
```
🔴 **Critical: SQLインジェクション脆弱性**
現在の実装では`user_input`を直接SQLクエリに挿入しているため、SQLインジェクション攻撃の危険があります。

**問題のコード:**
```sql
SELECT * FROM users WHERE name = '${user_input}'
```

**推奨修正:**
```sql
SELECT * FROM users WHERE name = ?
```
パラメータ化クエリを使用してください。

**参考**: [OWASP SQL Injection Prevention](https://example.com)
```

## 言語別チェックポイント

### JavaScript/TypeScript
- ESLint/TSLintルールの遵守
- 型安全性（TypeScript）
- 非同期処理の適切な実装
- モダンES6+構文の活用

### Python
- PEP 8スタイルガイドの遵守
- 型ヒント（Type Hints）の活用
- 例外処理の適切な実装
- Pythonicなコードの推奨

### Java
- Checkstyleルールの遵守
- 適切な設計パターンの使用
- リソース管理（try-with-resources）
- Null安全性の考慮

### Go
- gofmtフォーマットの適用
- エラーハンドリングの適切な実装
- Goらしい慣用句の使用
- パッケージ設計の最適化

## 対応フロー

1. **初期確認**
   - 変更の目的と範囲を理解
   - 関連するissueやドキュメントを確認

2. **コードレビュー実行**
   - 上記観点に基づいたレビュー
   - 重要度順にフィードバックを整理

3. **フィードバック提供**
   - 明確で建設的なコメント
   - 修正提案と参考資料の提供

4. **フォローアップ**
   - 修正内容の再確認
   - 追加の質問や説明への対応

## 注意事項

- 開発者の経験レベルに応じてフィードバックの詳細度を調整
- プロジェクト固有のルールや制約を考慮
- 文化的な違いや言語の壁に配慮した丁寧なコミュニケーション
- 完璧を求めすぎず、段階的な改善を促進

## 利用方法

このプロンプトをClaude Codeで使用する際は、レビュー対象のコードファイルやディレクトリを指定し、上記の観点に基づいたレビューを依頼してください。

例：
```
このプルリクエストのコードをレビューしてください。特にセキュリティとパフォーマンスの観点を重視してください。
```

エンジニア以外の活用例｜執筆・学習支援

サブエージェントの応用範囲はプログラミングに限りません。

「プロット考案」「キャラクター設定」「執筆」「校正」の各エージェントで小説を共作させたり、「先生役」「生徒役」「質問役」のエージェントで対話をさせて特定テーマを深く学べる環境を作ったりと、あらゆる知的生産活動をチームワークで効率化できます。

コードで人生リビルド

SESで約8年働いたJavaエンジニア・トムが、Claude Codeと自動化で仕事と生活を組み直している記録。Java・Docker・AIのエラー解決から、資格・転職、ブログ運営まで、試して確かめたことを書いています。

サブエージェントをAgent Skillsで強化する方法

/agents 機能の魅力は、複数のエージェントを協調させてタスク解決に当てられる点ですが、実際の開発現場では 同じ役割や知識を何度も繰り返し設定したくないというニーズが出てきます。

そこで活躍するのが Skills です。

これは、エージェントに特定の作業や知識を「再利用可能なモジュール」として教え込む仕組みで、/agents の専門性と効率を一段引き上げてくれます。

Agent Skills とは、指示書（SKILL.md）、サンプルコード、テンプレート、関連資料などをまとめたフォルダ単位のパッケージです。

このスキルがプロジェクトに登録されていると、Claude は単なる一過性のプロンプトではなく、専門化された手順やベストプラクティスを動的に読み込んで実行してくれます。

つまり、毎回同じプロンプトを書き換える必要がなく、決まったルールや手順をスキルとして蓄積・共有できるのです。

たとえば、コードレビューエージェントを毎回作成する代わりに、レビュー戦略やチェックリスト・出力フォーマットをまとめた Agent Skill を用意しておくと、/agents の起動時に Claude が適宜そのスキルを読み込み、自律的に統一された品質基準でレビューを実行できます。

これは大規模プロジェクトやチーム開発において 属人化を防ぎ、品質を一定化する強力な仕組みになります。

また、Skills は プロジェクト横断で再利用可能であり、VS Code や API、他の Claude プラットフォームでも共通の “知識パッケージ” として活用できるため、チーム全体で開発ルールや専門知識を標準化することにも役立ちます。

コードで人生リビルド

SESで約8年働いたJavaエンジニア・トムが、Claude Codeと自動化で仕事と生活を組み直している記録。Java・Docker・AIのエラー解決から、資格・転職、ブログ運営まで、試して確かめたことを書いています。

サブエージェント・Agent Skills・Agent Teamsの違い

Claude Codeには似た名前の機能が複数あり、混同しやすいポイントです。以下の比較表で使い分けを整理します。

Claude Codeサブエージェントに関するよくある質問

Q1. サブエージェントの使い方を最短で試すには？

A1. Claude Codeに「〇〇専用のサブエージェントを~/.claude/agents/に作って」と依頼するのが最短です。役割を1〜2文で伝えるだけで、Claudeが定義ファイル（YAMLフロントマター）を生成してくれます。なお/agentsの作成ウィザードはv2.1.198で廃止されています。

Q2. Claude Code agentとサブエージェントは同じものですか？

A2. Claude Codeの中で「agent」と呼ばれるものは、多くがこのサブエージェント（.claude/agents/などに定義して使う専用AI）を指します。ただし、ターミナルで打つclaude agentsコマンドはバックグラウンドのセッションを管理する「エージェントビュー」という別機能で、プログラムからエージェントを作るClaude Agent SDKも別の製品です。

Q3. 組み込みサブエージェント（Explore/Plan/General-purpose）とカスタムサブエージェントの違いは？

A3. Explore・Plan・General-purposeはClaude Codeに最初から搭載されている組み込みエージェントで、設定不要ですぐ使えます。一方カスタムサブエージェントは、コードレビューやテスト自動化など特定の役割に特化させて自分で作成するエージェントです。また、ExploreとPlanは使い切りで再開できませんが、General-purposeとカスタムエージェントはSendMessageで続きを依頼できます。

Q4. サブエージェントを使うとコストは増えますか？

A4. サブエージェントはメインセッションとは独立したコンテキストでタスクを実行するため、呼び出しごとにトークン消費は発生します。ただしメインセッションのコンテキストを汚さずに済むため、長時間セッションでの再読み込み・要約の手間が減り、トータルでは効率化につながるケースが多いです。

Claude Code（クロードコード）本・書籍おすすめ5選｜レベル別【2026年9月更新】

Claude Code（クロードコード）の本・書籍おすすめ5冊を、実務で毎日使う現役エンジニアがレベル別に正直比較。入門なら『AI駆動開発入門』、実践なら『実践Claude Code入門』が最有力です。CLAUDE.mdの書き方まで実体験を交えて解説します。