はじめに
流行りに乗るのが遅く今更ですが、コーディングやコードレビューをClaude Code先生に委託しました。ある程度要件を整理すれば、Claude Code先生がさくさくとプロジェクトの作成からコーディング、そしてコードレビューまでしてくれるため負担が減りましたが、何の考えもなしに先生に頼ってしまうとコストや質としてよろしくないので、今回コードレビューでAgentを導入してみました。
Claude CodeにおけるコードレビューAgent
今回導入したものは、レビューから最終的に修正、テストまでを実行するためのAgentにしています。
また、レビューの品質は保ちつつコストを抑えるため、エージェントで利用するモデルは操作ごとに変えています。
- レビュー本体では Sonnet
-
前処理・修正・テストでは Haiku
を利用する
Claude.md
レビューの方針や出力形式等を記載します。今回のAgentでのClaude.mdは以下のように記載しています。
また、Agentが毎回読み込むので必要事項を記載しつつ行数は抑えめにしています。(とはいっても、140行くらいありますが。。。)
Claude.md
## 1. エージェント構成
- **code_find（Haiku）**：差分となるコードの探索
- **code_review（Sonnet）**：コードレビュー・修正案作成
- **code_fix（Haiku）**：パッチ生成
- **code_test（Haiku）**：テスト実行・要点報告
### モデル利用
- **Haiku**：差分取得 / git 操作 / 軽量処理 / パッチ生成 / テスト
- **Sonnet**：コード精査 / 修正案コード例
---
## 2. 基本ルール
- 対象は「差分」または指定ファイルのみ
- 不要な探索禁止（Read/Grep/Glob/Run は最小限）
- 出力は簡潔・具体的
- 曖昧表現・冗長説明禁止
- 大規模リファクタリング禁止
- 依頼されていないファイル操作禁止
---
## 3. ワークフロー
1. Haiku：差分取得・前処理
2. Sonnet：レビュー・修正案
3. Haiku：最小限パッチ生成
4. Haiku：テスト実行・要点報告
---
## 4. レビュー基準（code_review）
- バグの可能性
- セキュリティリスク
- パフォーマンス
- コーディング規約違反
- テストの妥当性・不足
- 設計意図との整合性
### レビュー保存
- `.claude/reviews/review-{timestamp}.md` に保存
---
## 5. 修正パッチ（code_fix）
- 必要最小限
- 大規模変更禁止
- Unified Diff 形式
- 出力は短く
---
## 6. テスト（code_test + 共通）
- 指定テストコマンドのみ実行
- 成功/失敗を簡潔に要約
- 失敗原因を短く提示
- 新規コードには必ずテスト
- カバレッジ 80% 推奨
- モックは最小限
---
## 7. コーディング規約（共通）
- camelCase / PascalCase
- コメントは「意図」のみ
- 不要コード禁止
- 例外は必ずキャッチし、機密情報を含めない
- 外部 API はタイムアウト・リトライ必須
---
## 8. フロントエンド（TS + React）
### TypeScript
- strict 必須
- any 禁止（例外は理由コメント）
- 型は明示
### React
- useMemo/useCallback で再レンダリング最適化
- カスタムフック活用
- Props 型定義必須
- 副作用は useEffect に閉じ込める
- ステートは最小限
### UI/UX
- a11y
- フォームバリデーション
- ローディング・エラー状態必須
---
## 9. バックエンド（Python）
- PEP8
- 型ヒント必須
- 具体的な例外クラスを使用
- 入力値バリデーション
- 外部 API：タイムアウト・リトライ
- SQL インジェクション対策
- 個人情報をログに含めない
- パフォーマンス（ループ削減・ジェネレータ・キャッシュ）
---
## 10. セキュリティ基準（共通）
- SQL インジェクション対策
- XSS 対策（dangerouslySetInnerHTML 禁止）
- CSRF 対策
- 認証・認可の適切な実装
- 秘密情報は環境変数で管理
- 外部 API のエラーハンドリング
---
## 11. Claude のレビュー手順
1. 差分を読み意図を推測
2. 正しさを確認
3. セキュリティリスク確認（最優先）
4. パフォーマンス確認
5. 規約違反確認
6. テスト妥当性・不足確認（不足は必ず指摘）
7. 必要なら具体的な修正案・最小パッチ提示
8. 総評を簡潔にまとめる
---
agents.json
1. code_find: レビュー対象のコード探索
{
"name": "code_find",
"description": "Executes git commands, runs diffs, and performs file operations",
"model": "haiku",
"tools": ["Read", "Write", "ExecuteCommand", "Glob", "Grep"],
"instructions": "git diff の取得\n- コマンド実行\n- ファイル操作\n- ディレクトリ探索\n\n# Rules\n- 危険なコマンドは実行しない\n- 必要な場合は確認を求める\n- 出力は.claude/diff.txtに\n"
}
2. code_review: コードレビュー
{
"name": "code-reviewer",
"description": "Provides concise code review focusing on correctness, security, and quality",
"model": "sonnet,
"tools": ["Read", "Glob"],
"instructions": "方針に従ってコードレビューをする。"
}
3. code_fix: レビュー後の修正
{
"name": "code_fix",
"description": "Applies minimal, safe, and precise code fixes based on user instructions",
"model": "haiku",
"tools": ["Read", "Glob", "Grep"],
"instructions": "レビュー結果で提案された修正案に基づき、必要最小限のパッチを Haiku で生成する。パッチは Unified Diff 形式で、過剰な変更は禁止。"
}
4. code_test: 修正後のテスト
{
"name": "code_test",
"description": "Executes tests, analyzes failures, and provides actionable fixes",
"model": "haiku",
"tools": ["Run", "Read", "Glob"],
"instructions": "レビューや大規模修正は行わず、以下のルールに従ってテストの実行と結果分析のみを行ってください。\n\n# Test Execution Rules\n- 必ずユーザーが指定したテストコマンドのみを実行する（例: `npm test`, `vitest`, `pytest`）\n- プロジェクト全体の探索は禁止\n- テスト結果の要約は簡潔に（成功数・失敗数・エラー内容）\n- 失敗したテストがある場合は、原因を特定し、最小限の修正案を提示する\n- 修正パッチは生成しない（code_fix エージェントに任せる）\n\n# Output Format\n## Test Summary\n- 成功数 / 失敗数 / 実行時間\n\n## Failure Analysis\n- 失敗したテスト名\n- エラーメッセージの要点\n- 原因の推測（1〜2 行）\n- 修正案（必要最小限）"
}
コスト削減の更なるコツ
「.claude/settings.json」の「permissions.deny」や「respectGitignore」を設定することで、不要なファイルの読み込みを抑え、コードレビューの質を上げつつ、トークン数消費を減らしコスト削減につなげることができます。
まとめ
今回、構築したコードレビュー自動化では、コストを気にしつつレビュー品質を保つことができるので、結構利用しています。
とはいえ、運用的にも改善は必要そうなので、今後そのあたりも改良しておこうと思います。