Cursor でコードレビューする方法

Posted at 2025-04-01

話題の AI コーディングツール「Cursor」を使って、コードレビューのプロセスを効率化できるか試してみました。
本記事では、実際の使い方や使用感を簡単に紹介します。

ルールを書く

Cursor Setting > Rules > Project Rules からファイルを追加し、コードレビュー用のルールを記載します。

今回記載したルールは、Cursorに以下のようにプロンプトを投げて生成してもらいました。

XXX 配下でコードレビュー用の Cursor rules を作りたい。

作成物

# AI Chat App コードレビューガイドライン

## アーキテクチャとディレクトリ構造
- `src/` - アプリケーションのコアロジック
- `components/` - 再利用可能なVueコンポーネント
- `pages/` - ルーティング用のページコンポーネント
- `server/` - バックエンドAPIエンドポイント
- `plugins/` - Nuxt.jsプラグイン
- `constants/` - 定数定義
- `public/` - 静的アセット

## コーディング規約
1. コンポーネント命名規則
   - PascalCaseを使用（例：`ChatMessage.vue`）
   - コンポーネントファイルは単数形
   - ディレクトリは複数形

2. TypeScript
   - 型定義を必ず行う
   - `any`型の使用は避ける
   - インターフェースは`I`プレフィックスを使用（例：`IChatMessage`）
   - `console.log`を入れないこと

3. Vue.js
   - Composition APIを使用
   - コンポーネントは単一責任の原則に従う
   - Propsは型定義を必須とする

4. スタイリング
   - Tailwind CSSのユーティリティクラスを優先
   - カスタムCSSは`<style scoped>`を使用
   - グローバルスタイルは`assets/`に配置

## セキュリティ
- 環境変数は`.env`で管理
- APIキーはサーバーサイドでのみ使用
- ユーザー入力は必ずバリデーション

## パフォーマンス
- 画像は最適化して使用
- コンポーネントは必要に応じて遅延ロード
- バンドルサイズの最適化

## テスト
- ユニットテストは`__tests__`ディレクトリに配置
- コンポーネントテストは`__tests__/components`に配置
- E2Eテストは`__tests__/e2e`に配置

## ドキュメント
- 複雑なロジックにはコメントを追加
- READMEは最新の状態に保つ
- APIエンドポイントはOpenAPI/Swaggerで文書化

## レビューチェックリスト
- [ ] コードはコーディング規約に準拠しているか
- [ ] 型定義は適切か
- [ ] エラーハンドリングは適切か
- [ ] パフォーマンスへの影響は考慮されているか
- [ ] セキュリティリスクはないか
- [ ] テストは適切に書かれているか
- [ ] ドキュメントは更新されているか

本来であれば、ここで自分のプロジェクトに合わせて手直しをすると思いますが、今回は割愛します。

コードレビューをする。

@ を押して Git から @PR (Diff with Main Branch) を選択すると、PR の diff を Cursor でレビューできます。

さらに、先ほど作ったコードレビュー用のルールである .mdc ファイルを追加しておくと、ルールに沿ったレビューが可能です。

上記のように記載し、実行してみるとこのようなレビューが返ってきました。

Apply をすることでコード修正も同時に可能です。

全量

PRのコードレビューを行います。主な変更点はVuetifyの導入とUIの改善に関するものですね。

主な変更点の分析

Vuetifyの導入

✅ 適切なバージョン（3.8.0）が選択されています
✅ 必要な依存関係（@mdi/font, sass）が追加されています
✅ プラグインの設定が適切に行われています

UIコンポーネントの改善

✅ Vuetifyのコンポーネントを使用して、より洗練されたUIに
✅ レスポンシブデザインの実装
✅ アクセシビリティの向上（ラベル、バリアントの適切な使用）

スタイリング

✅ スコープ付きCSSの使用
✅ Vuetifyのテーマ設定の実装
✅ カラーパレットの定義

改善提案

パフォーマンス最適化

// vite.config.tsに以下を追加することを推奨
export default defineConfig({
  // ... 既存の設定
  build: {
    rollupOptions: {
      output: {
        manualChunks: {
          'vuetify': ['vuetify']
        }
      }
    }
  }
});

エラーハンドリング

// ChatInterface.vueにエラー状態の表示を追加
<v-alert
  v-if="error"
  type="error"
  class="mb-4"
>
  {{ error }}
</v-alert>

アクセシビリティのさらなる改善

// キーボードナビゲーションのサポート
<v-textarea
  @keydown.enter.prevent="sendMessage"
  @keydown.ctrl.enter="newLine"
  // ... 既存のprops
></v-textarea>

セキュリティチェック

✅ 環境変数の適切な管理
✅ ユーザー入力のバリデーション
✅ XSS対策（Vueのテンプレート構文による自動エスケープ）

テスト推奨事項

コンポーネントテストの追加

// __tests__/components/ChatInterface.spec.ts
describe('ChatInterface', () => {
  test('メッセージ送信機能', () => {
    // テストコード
  });
});

E2Eテストの追加

// __tests__/e2e/chat.spec.ts
describe('チャット機能', () => {
  test('メッセージの送受信', () => {
    // テストコード
  });
});

総評

このPRは全体的に良く実装されており、以下の点が特に評価できます：

モダンなUIフレームワークの適切な導入
コードの可読性と保守性の向上
アクセシビリティへの配慮
パフォーマンスへの考慮

推奨される改善点を実装することで、さらに品質の高いコードになると考えられます。

レビューチェックリストの結果：

コードはコーディング規約に準拠
型定義は適切
エラーハンドリングは基本的に実装済み
パフォーマンスへの影響は考慮されている
セキュリティリスクは最小限
テストの追加が必要
ドキュメントは更新されている

今回のPRにはテストが含まれていなかったため、このチェックリスト結果も納得感があります。

実験

さて、ちょっと試しにコードを修正してみましょう。
console.log を追加し、any 型を無理やり入れてみました。

すると…

詳細

コードレビューを行います。主な変更点を分析し、コーディング規約に基づいて評価していきます。

主な変更点の概要

Vuetifyの導入とUIコンポーネントの実装
スタイリングの改善
プロジェクト設定の更新

詳細なレビュー

1. アーキテクチャとディレクトリ構造

✅ コーディング規約に準拠しています：

plugins/ディレクトリにVuetifyの設定を適切に配置
コンポーネントはcomponents/ディレクトリに配置
スタイルはsrc/styles/に配置

2. TypeScript

⚠️ 改善が必要な点：

server/api/chat.post.tsでany型の使用が見られます：

const body: any = await readBody(event);

インターフェースの定義が不足しています

3. Vue.js

✅ 良い点：

Composition APIを使用
コンポーネントの単一責任の原則を遵守
Vuetifyコンポーネントを適切に使用

4. スタイリング

✅ コーディング規約に準拠：

Vuetifyのユーティリティクラスを活用
スコープ付きスタイルを使用
グローバルスタイルはsrc/styles/に配置

5. セキュリティ

⚠️ 改善が必要な点：

server/api/chat.post.tsにconsole.logが残っています：

console.log(123123);

6. パフォーマンス

✅ 良い点：

Vuetifyの最適化設定が適切に行われています
コンポーネントの遅延ロードが可能な構造

推奨される改善点

TypeScriptの型定義の改善：

interface ChatRequest {
  message: string;
  model: string;
}

const body: ChatRequest = await readBody(event);

デバッグ用のconsole.logの削除
エラーハンドリングの強化：

APIキーのバリデーション
エラーメッセージの国際化対応

総合評価

全体的にコーディング規約に準拠しており、UIの改善が適切に行われています。TypeScriptの型安全性とセキュリティ面で若干の改善が必要ですが、大きな問題は見られません。

レビューチェックリストの評価：

コードはコーディング規約に準拠しているか
型定義は適切か
エラーハンドリングは適切か
パフォーマンスへの影響は考慮されているか
セキュリティリスクはないか
テストは適切に書かれているか
ドキュメントは更新されているか

これらの改善点を修正することで、より堅牢なコードベースになると考えられます。

以下抜粋

⚠️ 改善が必要な点：

server/api/chat.post.tsにconsole.logが残っています：

⚠️ 改善が必要な点：

server/api/chat.post.tsでany型の使用が見られます：
const body: any = await readBody(event);

おおー！ちゃんと見てくれてますね。

レビューチェックリストの評価：

コードはコーディング規約に準拠しているか

型定義は適切か

エラーハンドリングは適切か

パフォーマンスへの影響は考慮されているか

セキュリティリスクはないか

テストは適切に書かれているか

ドキュメントは更新されているか

ちゃんと最後のチェックリストにもチェックが入っていなかったです。

総評

いかがでしたでしょうか。
Cursor を使ってコードレビューすると、ちゃんとレビューしてくれます。

セルフレビュー代わりとして使うだけでも、かなり有用だと感じました。
もちろん、途中にも書いた通り、チームや会社独自のコーディングルールに合わせてルールを作成しておくことで、プロジェクト固有のコンテキストに沿ったコードレビューが可能になると思います。
そのため、より的確で実用的なフィードバックが得られるようになり、実務でもかなり役立つと感じました。

最後に

まだ Cursor を使い始めて日が浅いので、もっといいやり方があるなどあれば積極的にご意見いただけたら幸いです！！

参考

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up