⚡
ClaudeカスタムコマンドでPR作業が爆速になった話
忙しい人へのまとめ
- ClaudeのカスタムコマンドでPRのサマリーとセルフレビューが自動生成できるように
- 自分で確認すべきポイントが一目で分かり、ミスや漏れの早期発見につながった
- テストレビューの自動化で、テスト品質向上とレビュー工数の削減を実感
なぜカスタムコマンドを作ったのか
普段の開発では、PRを出す前に変更点をまとめたり、自分でレビューしたり、テストの確認を行ったりと、意外と手間がかかります。特に大きな変更では、内容を丁寧に整理するだけでも結構な時間がかかっていました。そこで、LLMにお願いしてこれらの作業を自動化できないかと考え、Claude用のカスタムコマンドを作成しました。
設定の仕方
~/.claude/commands 配下にマークダウンをコマンドごと置くことで設定することができます。
マークダウンファイルの名前がコマンドになります
詳しくは公式ドキュメント参照
コマンド1: PRサマリー生成
まず導入したのが、現在のブランチとmainブランチの差分から自動でPRのタイトルとサマリーを作成してくれるコマンドです。動作確認の表まで生成されるので、確認漏れがないか一目でチェックできます。実際に2度ほど、意図しない変更をこのサマリーで気付くことができました。
---
allowed_tools: Read(*), write(*.md)
description: "現状のPRのサマリを作成します。"
---
## 実行指示
現在のブランチとmainブランチとの差分を確認し、下記を生成してください。
### 書式
タイトル: 差分内容から端的にタイトルを設定
サマリー:
## 概要
差分内容から端的に概要を作成。
### 変更内容
変更内容を箇条書きで列挙
### 期待すること
この変更に期待することを記載
### 動作確認
項目 | 証憑(スクショなど) | 備考
-- | -- | --
考えられるシナリオテストケース(システムテスト)で行を追加
↑のように権限を限定したYAMLと指示文を用意しておくだけで、毎回詳細なサマリーを出力してくれます。
コマンド2: レビュー依頼前のセルフレビュー
次に作成したのが、レビュー前のセルフチェック用コマンドです。
reviewコマンド自体は公式であるのですが、出力や、気にして欲しい点など細かく指定したかったので個別に作っています。
こちらはgit diffを実行して差分の統計を確認しつつ、アーキテクチャ・設計品質やセキュリティの観点から総合的な評価を行ってくれるようにしました。
コードの変更が複雑になってきた時も、このコマンドを実行するだけで改善点を洗い出せます。特に、依存関係の見直しや循環依存の可能性を指摘してくれるのがありがたいポイントです。
---
allowed_tools: Bash(git:*), Read(*)
description: "mainブランチとの差分を包括的にレビューし、品質・セキュリティ・保守性の観点から詳細な評価と改善提案を提供します。"
---
あなたは卓越したシニアアーキテクト兼セキュリティエンジニアです。
## 事前分析
まず以下のコマンドで差分の全体像を把握してください：
1. 差分ファイル一覧と変更統計
git diff --name-status main
git diff --stat main
2. 詳細な差分内容
git diff main
## レビュー観点
### 1. アーキテクチャ・設計品質（重要度：最高）
- **SOLID原則**: 単一責任、開放閉鎖、リスコフ置換、インターフェース分離、依存性逆転
- **DRY原則**: 重複コードの排除
- **YAGNI原則**: 不要な複雑性の回避
- **関心の分離**: ビジネスロジック、プレゼンテーション、データアクセスの分離
- **依存関係**: 循環依存や不適切な依存の有無
### 2. コード品質（重要度：高）
- **可読性**: 命名規則、コメント、コードの自己説明性
- **保守性**: メソッドの長さ、クラスの責任範囲、複雑度
- **一貫性**: コーディングスタイル、パターンの統一
- **エラーハンドリング**: 例外処理の適切性
- **パフォーマンス**: 明らかな非効率性やボトルネック
### 3. セキュリティ（重要度：高）
- **入力検証**: SQLインジェクション、XSS対策
- **認証・認可**: アクセス制御の適切性
- **機密情報**: ハードコーディングされたパスワード等
- **ログ出力**: 機密情報の漏洩リスク
### 4. 技術的負債とリスク（重要度：中）
- **デッドコード**: 使用されていないメソッド、クラス、変数
- **TODO/FIXME**: 未完了タスクの確認
- **廃止予定API**: 非推奨機能の使用
- **互換性**: 既存機能への影響
### 5. テスタビリティ（重要度：中）
- **テストの追加**: 新機能に対するテストの有無
- **テストの修正**: 既存テストの適切な更新
- **テスト容易性**: モック化可能性、依存注入
### 6. 構文・基本品質（重要度：低）
- **構文エラー**: コンパイル・実行時エラー
- **警告**: リンター、IDEからの警告
- **フォーマット**: コードフォーマットの統一
## 出力形式
### 📊 変更サマリー
- 変更ファイル数: X件
- 追加行数: +XXX行
- 削除行数: -XXX行
- 影響範囲: [フロントエンド/バックエンド/データベース/設定等]
### 🎯 総合評価
**評点**: [S/A+/A/B+/B/C+/C/D] (Sが最高評価)
**マージ推奨度**: [即座にマージ可能/軽微な修正後マージ/修正必須/大幅な見直し必要]
### 📋 詳細レビュー結果
#### ✅ 優秀な実装
- [具体的なファイル名と良い実装例]
#### 🚨 クリティカル（マージ前に必須修正）
- [セキュリティリスクや重大なバグ]
#### ⚠️ 重要（できるだけ早期に修正）
- [設計上の問題やパフォーマンス課題]
#### 💡 改善提案（今後の課題）
- [リファクタリング提案や設計改善案]
#### 🔍 要確認事項
- [レビュワーによる追加確認が必要な箇所]
### 🛠️ 推奨アクション
1. **即座に対応**: [クリティカルな問題の対処法]
2. **短期対応**: [重要な改善項目]
3. **中長期対応**: [技術的負債解消や設計改善]
### 📈 品質メトリクス
- 循環複雑度: [高/中/低]
- 技術的負債レベル: [高/中/低]
- セキュリティリスク: [高/中/低/なし]
- テストカバレッジ影響: [向上/維持/低下]
### 🎉 開発者へのフィードバック
[建設的で具体的なフィードバック]
## 特別な考慮事項
### 破壊的変更の検出
- APIの変更、データベーススキーマ変更等の影響を評価
### パフォーマンス影響
- 大量データ処理、ネットワーク呼び出し等の性能影響を分析
### チーム開発への配慮
- コードレビューの負荷、他開発者への影響を考慮
## 注意事項
- 変更の文脈と意図を推測しながらレビューを行う
- 言語・フレームワーク固有のベストプラクティスを適用
- 建設的で学習につながるフィードバックを心がける
- 重要度に応じてメリハリのあるレビューを実施
コマンド3: テストのレビュー
テストコードに対しても専用のレビューコマンドを用意しました。対象のディレクトリを指定するだけで、機能カバレッジやテスト設計の品質、モックの適切さなどをチェックしてくれます。テストコードが疎かになりがちなタイミングでも、このコマンドを走らせておくと抜け漏れを防げますし、モックの過不足もすぐに分かります。
---
allowed_tools: Bash(git:*), Read(*)
description: "引数で指定したテストファイル・ディレクトリの包括的なレビューを行い、品質評価と具体的な改善提案を提供します。"
---
あなたは卓越したテストエンジニア・品質保証の専門家です。
## 対象の特定と分析
まず $ARGUMENTS で指定されたファイル・ディレクトリを読み込み、以下を特定してください：
- テスト対象のプロダクションコード
- テストフレームワークと言語
- プロジェクトの構造とテスト戦略
## レビュー観点
### 1. テストカバレッジ（重要度：高）
- **機能カバレッジ**: 全ての公開メソッド・関数がテストされているか
- **分岐カバレッジ**: if文、switch文、例外処理などの分岐が網羅されているか
- **境界値テスト**: エッジケース（null、空文字、最大値/最小値）のテスト
- **エラーケース**: 異常系・例外系のテスト
### 2. テスト設計の品質（重要度：高）
- **単一責任**: 1つのテストが1つの機能のみをテストしているか
- **独立性**: テスト間の依存関係がないか
- **可読性**: テスト名と内容が分かりやすいか
- **AAA原則**: Arrange（準備）、Act（実行）、Assert（検証）が明確か
- **正確性**: テストを通すために、mockなどで必ずPASSするテストになるようなズルがないか
### 3. モック・スタブの適切性（重要度：中）
- **適切な粒度**: テスト対象に集中するための適切なモック
- **過度なモック**: 実装の詳細に依存しすぎていないか
- **モックの検証**: モックへの呼び出しが適切に検証されているか
### 4. テストの保守性（重要度：中）
- **テストデータ**: ハードコーディングされた値の妥当性
- **重複コード**: テストコードの重複とリファクタリング余地
- **ヘルパーメソッド**: 共通処理の適切な抽象化
### 5. パフォーマンスと実行速度（重要度：低）
- **テスト実行時間**: 過度に重いテストがないか
- **外部依存**: データベースやAPIへの不要な依存
## 出力形式
### 総合評価
**評点**: [A+/A/B+/B/C+/C/D] (A+が最高評価)
### 詳細レビュー結果
#### ✅ 良い点
- [具体的な良い実装例を挙げる]
#### ⚠️ 改善点（優先度別）
**優先度：高**
- [具体的な問題点と改善提案]
**優先度：中**
- [具体的な問題点と改善提案]
**優先度：低**
- [具体的な問題点と改善提案]
#### 📝 具体的な改善コード例
必要に応じて、改善後のコード例を提示してください。
#### 📊 メトリクス
- テストケース数: X件
- カバレッジ推定: XX%
- 検出された問題: X件（高:X, 中:X, 低:X）
#### 💡 追加推奨事項
- [テスト戦略や今後の改善方向性]
## 注意事項
- プロダクションコードも参照して、テストの妥当性を総合的に判断する
- 言語・フレームワークのベストプラクティスに従った評価を行う
- 抽象的な指摘ではなく、具体的で実行可能な改善提案を行う
実際に使ってみて感じた効果
- レビュー依頼までの準備が短縮：サマリー作成やセルフレビューを自動化したことで、PR作成にかかる時間がぐっと減りました
- コードの品質向上：自動レビューの指摘をもとにリファクタリングを進めることで、より読みやすく安全なコードになりました
- コミュニケーションコストの削減：PRに載せる情報が整理されているので、レビュワーからの質問も減りスムーズにマージされるようになりました
おわりに
LLMの力を借りてPR作業を自動化することで、思った以上に開発効率が上がりました。今後も改善を重ねて、より質の高いレビューを短時間で行えるようにしていきたいです。みなさんもぜひ、自分のフローに合わせたカスタムコマンドを試してみてください！
Discussion