この記事は CAMPFIRE Advent Calendar 2025 10 日目の記事です。
はじめに
CAMPFIRE では、 Ruby on Rails で実装されたアプリケーションから、フロントエンド部分を SvelteKit で分離する取り組みを進めています。
参考: https://note.com/tkhs0813/n/n93f7affdddd3
この取り組みによりパフォーマンス向上などの効果が出てきていますが、FE エンジニア以外も FE リポジトリを触る機会が増えてきており、FE エンジニアのレビューコスト増加が課題となっています。
そこで、過去の PR コメントの内容を分析し、コードレビュー用の Cursor Rules を自動生成することで、コードレビューの効率化を図りました。本記事ではその内容を紹介します。
コードレビュー用 Cursor Rules の自動生成
以下に添付したスクリプトを実行することで、Cursor Rules を自動生成することができます。
内容はとてもシンプルで、以下の流れで実行し、スクリプト化することで GitHub Actions 等で継続的に更新できるようにしています。
- GitHub CLI で PR コメントの収集
- 収集した PR コメントを Cursor CLI で分析し、コードレビュー用の Cursor Rules を生成/更新
スクリプト
#!/bin/bash
# require: cursor-cli, github cli, jq
OUTPUT_FILE="${1:-pr-comments.json}"
echo "PRコメントからコードレビューチェックリストを更新します..."
echo "📥 PRコメントを収集中..."
# すべてのPRコメント（行コメント）を取得（ボットを除外）
gh api repos/:owner/:repo/pulls/comments \
--paginate \
--jq ".[] | select(.user.login | test(\"copilot|bot\"; \"i\") | not) | {
pr_number: (.pull_request_url | split(\"/\") | .[-1]),
author: .user.login,
body: .body,
path: .path,
created_at: .created_at
}" | \
jq -s "sort_by(.created_at) | reverse" \
> "$OUTPUT_FILE"
echo "🤖 AIによるルール生成中..."
cursor-agent -p --force --model "claude-4.5-sonnet" "タスク: PRコメント（${OUTPUT_FILE}）を分析し、./.cursor/rules/code-review.mdcを更新してください。
【重要な指示】
1. 頻出する指摘パターンを特定し、カテゴリ別に整理してください
2. 各ルールには必ず「❌問題例」と「✅推奨例」の両方を含めてください
3. 抽象的な説明ではなく、コピペで使える具体的なコード例を提供してください
4. [must]タグや具体的な修正提案があるコメントを優先してください
5. 単なる進捗報告や質問だけのコメントは除外してください
6. 同じパターンが複数回指摘されている場合は、そのパターンを優先してください
【出力形式】
各項目は以下の形式で記述してください：
[なぜ重要かの説明]
\`\`\`typescript
// ❌ 非推奨
[悪い例のコード]
// ✅ 推奨
[良い例のコード]
\`\`\`
[補足説明があれば記載]
【カテゴリ】
以下のカテゴリで整理してください：
1. Svelte 5 Runes 関連
2. 型定義・TypeScript関連
3. コンポーネント設計
4. アクセシビリティ
5. イベント処理・クリーンアップ
6. スタイリング（CSS/SCSS）
7. API連携・データ処理
8. パフォーマンス最適化
9. コード品質（命名規則、デバッグコード、コメント等）
10. プロジェクト固有の注意事項
既存のcode-review.mdcも参照し、重複を避けつつ、より充実した内容に更新してください。"
echo "✅ コードレビューチェックリストを更新しました。"
生成された Cursor Rules の例
生成されたルールの一部を以下に示します。
過去に指摘があったものをルールとして整理できています。
### 3.1 コンポーネントの外側向き margin を避ける
コンポーネント間のスペースは親コンポーネントで制御してください。
子コンポーネントが外側向きの margin を持つと、再利用性が低下します。
```scss
// ❌ 非推奨: コンポーネント自身が margin を持つ
.hoge-component {
margin-top: 24px;
margin-bottom: 24px;
}
// ✅ 推奨: 親コンポーネントで gap や margin を制御
// 親コンポーネント側
.container {
display: flex;
flex-direction: column;
gap: 24px;
}
活用方法
生成されたチェックリストは、以下のような方法で活用しています。
- Cursor でのセルフレビュー
- PR を出す前に、自身の環境でセルフレビューを行うことができます。
- Devin でのレビュー
- Devin Knowledge に、コードレビュー時にチェックリストを参照するように設定することで、Devin が参照してレビューを行うことができます。
- GitHub Copilot Review
-
.github/copilot-instructions.mdに チェックリストのリンクを記載することで、PR 上でルールを参照して自動レビューを行えます。
-
実装のポイント
PR コメントのフィルタリング
PR コメントの質が全てなので、フィルタリングを行っています。
具体的には、GitHub Copilot Review 等の Bot コメントを除外しています。
GitHub Copilot Review 導入当初は、ルールの整備が不十分だったため適切でないコメントが多く、ノイズとなってしまったため除外しています。
プロンプト
Cursor CLI に与えるプロンプトに、出力形式、カテゴリ、コード例を含めるように指定しています。
このようにすることで、Cursor CLI が適切なチェックリストを生成できるようにしています。
導入後の効果
正直なところ、AI モデル自体の進歩もあり、この仕組み単体での効果を定量的に計測できてはいないです。
ただ、体感ベースでは以下のような変化を感じています
- 過去何度もコメントしているような定番の指摘を人間が書く機会が減った
- セルフレビュー時に「前にも指摘されたことあるやつだ」と気づけるようになった
- コードレベルの指摘は AI に任せ、設計やビジネスロジックのレビューに集中できるようになった
今後の課題
現時点でいくつか課題も見えています。
- PR コメント取得に時間がかかる
- 全期間のコメントを取得しているのでかなり時間がかかってしまいます。
PR コメントは増え続けるので期間を指定するなどの対策が必要になってくるかもしれません。
- 全期間のコメントを取得しているのでかなり時間がかかってしまいます。
- PR コメントの質によっては、適切なチェックリストが生成されない可能性
- 生成されたチェックリストを目視で確認し、不適切な内容がないことは確認していますが、常に適切な内容が生成されるとは限らないため、何らかの対策が必要だと考えています。
最後に
PR コメントから Cursor Rules を自動生成する仕組みを紹介しました。
この仕組みにより、過去の知見を効率的にルール化し、レビューの質を担保しながら効率化を図ることができています。
PR コメントには、チームの暗黙知やベストプラクティスが詰まっており、活用しない手はありません。ぜひ皆さんのチームでも試してみてください。