はじめに
「またPR書くのか…」
これは、私が日々の開発で何度も感じていたことでした。
PRを書くたびに、変更内容を整理して、テンプレートを探して貼り付けて、テスト項目を書いて…と、正直かなり時間と集中力を消耗していました。
さらにレビューでは、人によって指摘内容が違うため、
「テストコード消し忘れてるよ」
「例外処理が抜けてるかも」
など、後から指摘が出ることも少なくありません。
そんな中でふと、
「これ、CursorのCommandで自動化できるのでは？」
と思い立ちました。
別記事にてNakashimaさんが、同じ Cursor の Commands を使って単体テストを自動生成するワークフローを紹介しています。
業務効率化に悩むエンジニアにぴったりの内容なので、こちらの記事もぜひご覧ください。
今回の記事は、その延長線上の取り組みとして、レビューとPR作成まわりの自動化についてご紹介します。
実際に自作Commandを作ってみたところ、PR作成の手間を大幅に減らせただけでなく、レビューの精度が上がりました。
取り組みの背景
今回の目的はシンプルです。
- レビューの品質をできるだけ均一にしたい
- PR作成を短時間で終わらせたい
Cursor には、開発作業を自動化できる Commands 機能 があります。
この Commands 機能を、自分の開発フローに合わせて使うことで、レビューとPR作成をまとめて楽にできないか試してみました。
使用する機能とそのメリット
今回の自動化で活用したのは、Cursorの Commandsファイル機能 です。
.cursor/commands/ ディレクトリに md 形式の設定ファイルを配置し、そこに統一されたプロンプトを記述しておくことで、チーム全体が 同じ条件・同じ基準で コマンドを実行できるようにしています。
たとえば、次のようにファイルを分けています。
- review.md：レビュー観点や出力フォーマットを定義
- pr.md：PR本文テンプレートやチェックリストを定義
このように Commands の中身をファイルとして管理しておくことで、
- Commands の内容そのものをバージョン管理できる
- プロジェクトごとに必要な観点を柔軟に足し引きできる
というメリットがあります。
実際、今回のプロジェクトでは GraphQL API を利用していたため、review.md に GraphQLの型チェック項目 を追加しました。
これにより、プロジェクト固有の開発ルールも自動レビューに反映できるようになりました。
また、公式ドキュメントの Pull Request Command を参考にしながら、自分の開発フローに合わせてプロンプト内容をカスタマイズしています。
自動化の全体像
作成したCommandsは次の2つです。
/review：差分を解析してコード品質や例外処理を自動チェックする/pr：Draft PRを自動生成し、安全にプッシュまで行う
この2つを連続で使うことで、「レビュー → PR作成」までの一連の流れ を完全自動化できます。
Review Command：コード品質チェックの自動化
/review Commands では、現在のブランチと main（または develop） の差分をCursorが解析し、以下の観点でレビュー結果を生成します。
- 機能面：新機能追加や動作の妥当性
- エラーハンドリング：例外処理・fallback対応
- コード品質：命名・責務分離・重複コード・any使用
- セキュリティ：トークン・バリデーション・シークレット管理
- パフォーマンス：再レンダリング・リスト最適化・画像キャッシュ
- UI/UX：SafeArea・アクセシビリティ
- GraphQL：型生成・loading/error/data処理
- テスト：フォーム・主要ロジックの網羅性
- 残留チェック：console.log / it.only / 不要mock削除漏れ
出力例
PR Commands：安全で統一されたPR作成
/pr Commands は、レビュー後の変更を反映しながら、GitHubにDraft PRを自動生成します。
実行時のチェック内容
実行時には、たとえば次のようなチェックを行います。
- 未コミットの変更がないか
- GitHub CLI（gh）が存在するか
- 現在のブランチとマージ先のブランチの差分を確認すること
- PRは必ずDraftとして作成すること
実行コマンド例や、実際に生成されたPR画面のイメージは、スクリーンショット付きで記事中に貼っていますが、ざっくり言うと「/pr を叩くと Draft PR が生え、説明もテンプレートに沿って埋まる」という状態です。
実行コマンド例：
実行時には、たとえば次のようなチェックを行います。
実際の効果
実際に運用してみた結果をBefore/Afterでまとめると、このようなイメージです。
| 項目 | Before | After |
| PR作成時間 | 約5分 | 約15秒 |
| チェック漏れ | よくあった | ほぼゼロ |
| レビュー観点 | 人によって違う | Commandsで統一 |
特にインパクトが大きかったのは、「自分のコードを第三者視点で見直すプロセス」が自然に組み込まれたことです。
まとめ
この取り組みを通じて実感したのは、AIをうまく使うことで「チームの開発文化」をコード化できる ということです。
Cursorの自作Commandsは、単なる効率化ツールではなく、チームの考え方や品質基準を自動化できる仕組みです。
前回の記事では、同じ Commands を使って単体テストの自動生成にフォーカスしました。
今回のレビュー / PR作成用の Commands と組み合わせることで、
実装 → テスト → レビュー → PR作成
という一連の流れを、少しずつ Commands ベースのワークフローに乗せていくことができます。
毎回のPR作成やレビューに負担を感じている方は、ぜひ自分たちの開発フローに合ったCommandsを試してみてください。
付録：Commandsの全プロンプト
- review.md：コード品質・セキュリティ・パフォーマンスなどを網羅チェック
- pr.md：Draft PRを自動生成し、GitHub CLIで安全に作成
詳細な実装手順やサンプルは、.cursor/commands/ ディレクトリに保存しています。
# PR作成 ## 概要 レビュー済みの変更内容をもとに、GitHub PR用の説明文を生成し、ドラフトPRを作成します。 ## 実行前チェック ### 1. マージ先ブランチの確認 - マージ先の既定は `main` ブランチ - ユーザーがチャットで別のブランチを指定した場合はそちらを優先 ### 2. ブランチ確認 - 現在のブランチがマージ先ブランチでないことを確認 - もし該当する場合は処理を中止し、理由を説明 ### 3. GitHub CLI確認 - `gh` コマンドがインストールされているか確認 - インストールされていない場合は処理を中止し、以下を説明: - GitHub CLIが必要な理由 - インストール方法（`brew install gh`） - 認証が必要な場合は `gh auth login` の実行を案内 ### 4. 未コミット変更の確認 - `git status` でステージングされていない変更やステージング済みの変更がないか確認 - 未コミットの変更がある場合は処理を中止し、まだ未コミットの差分があることを通知する - コミットは実行せず、ユーザーに状態を知らせるのみ ### 5. 未プッシュ変更の確認と処理 - 現在のブランチに未プッシュのコミットがあるか確認 - 未プッシュのコミットがある場合は自動的に `git push` を実行 - リモートブランチが存在しない場合は `git push -u origin <branch-name>` を実行 ### 6. 差分確認 - 現在のブランチとマージ先ブランチの差分を確認 - 変更内容を分析 ## PR作成手順 ### GitHub CLIの使用 - `gh` コマンドを使用してPRを作成 - すべてのgitコマンドに `GIT_EDITOR=true` を前置して実行 （エディタブロックを回避） - **必ず `--draft` オプションを使用してドラフトPRとして作成** ### PR説明文フォーマット ```markdown <機能エリア>: <タイトル>（80文字以内） <要約>（2文以内で簡潔に） <詳細説明> ## 変更内容 - <変更点1> - <変更点2> - <変更点3> ## 影響範囲 - <影響を受ける機能や画面> ## テスト - [ ] 動作確認（iOS実機） - [ ] 動作確認（シミュレーター） - [ ] エッジケースの確認 - [ ] パフォーマンステスト ### 動作確認 1. 前提（テスト用アカウント / Feature Flag / Remote Config） 2. 手順（再現 / 確認） 3. 期待結果 / 実際結果 4. 端末・OS（実機/シミュレータ、iOS バージョン） ### チェックリスト - [ ] 実機（iOS）/ シミュレータで確認 - [ ] スクショ/動画を添付（UI 変更時） - [ ] 破壊的変更がある場合、移行手順を記載 ### スクリーンショット / 動画（UI 変更がある場合） - Before / After を添付 ### 関連 - Issue / チケット: # - 参考 PR / 仕様 / 設計資料 ``` ## 出力 - PR作成後、PRのURLを必ずレスポンスに含める - ユーザーが簡単にクリックできるように表示 ## 実行例 ```bash # 1. 現在のブランチを確認 git branch --show-current # 2. 未コミット変更を確認（変更がある場合は処理を中止） git status # 3. 未プッシュのコミットを確認 git log origin/HEAD..HEAD --oneline # 4. 未プッシュのコミットがある場合はプッシュ GIT_EDITOR=true git push # または、リモートブランチが存在しない場合 GIT_EDITOR=true git push -u origin $(git branch --show-current) # 5. マージ先ブランチとの差分を確認 git diff main...HEAD # 6. PRを作成（必ずドラフトとして作成） gh pr create --draft --title "機能: タイトル" --body "説明文" --base main # 7. PRのURLを表示 https://github.com/owner/repo/pull/123 ``` ## 注意事項 - **PRは必ずドラフトとして作成する** - マージ先ブランチは既定で `main`（ユーザー指定があればそちらを優先） - 未コミットの変更がある場合は処理を中止し、先にコミットすること - 未プッシュのコミットがある場合は自動的にプッシュする - Issue番号がある場合は必ず含める（例: Closes #123） - UIの変更がある場合はスクリーンショットを促す - 技術的な詳細も含める - 日本語で簡潔に書く - PRリンクは必ず最後に表示する
# コードレビュー ## 概要 品質・セキュリティ・保守性を確保するための徹底的なコードレビューを実施し、レビュー結果をまとめて出力します。 ## 実行前チェック ### 1. 対象ブランチの確認 - 比較元の既定は `main` ブランチ - ユーザーがチャットで別のブランチを指定した場合はそちらを優先 ### 2. 差分の確認 - 現在のブランチと比較元ブランチの差分を取得 - 変更ファイルのリストを確認 - 変更内容を分析 ### 3. Lintエラーの確認 - 変更されたファイルに対してLintエラーがないか確認 - エラーがある場合はレビュー結果に含める ## レビュー手順 ### 1. 変更ファイルの分析 - 変更されたファイルを種類ごとに分類 - UI コンポーネント - ビジネスロジック - ユーティリティ - 型定義 - テスト - 設定ファイル ### 2. チェックリストに基づくレビュー #### 機能 - [ ] コードが意図どおりに動作している - [ ] 例外的なケースまで考慮されている - [ ] エラーハンドリングが適切 - [ ] 明らかなバグやロジックエラーがない #### コード品質 - [ ] 読みやすく、構造が明確 - [ ] 関数が小さく、責務が明確 - [ ] 変数名がわかりやすい - [ ] 重複コードがない - [ ] プロジェクトの規約に従っている - [ ] `@/` エイリアスを使用している（相対パス禁止） - [ ] 型安全性が保たれている（`any` の使用がない） - [ ] enumではなくmapを使用している #### セキュリティ - [ ] 明らかなセキュリティ上の脆弱性がない - [ ] 入力バリデーションが実装されている - [ ] 機微なデータが適切に扱われている - [ ] シークレットがハードコードされていない - [ ] 認証トークンがSecureStorageで管理されている #### パフォーマンス（React Native） - [ ] 不要な再レンダリングがない（useMemo, useCallback, React.memo） - [ ] FlatList/SectionListの最適化設定がされている - keyExtractor が設定されている - initialNumToRender が適切 - windowSize が考慮されている - [ ] メモリリークの可能性がない - [ ] 画像の最適化がされている（expo-image使用） - [ ] 複雑なstate管理はzustandストアに移動されている #### UI/UX（iOS） - [ ] iOS Human Interface Guidelinesに準拠している - [ ] アクセシビリティ対応がされている（accessibilityLabel等） - [ ] SafeAreaViewを適切に使用している #### GraphQL - [ ] GraphQL操作が `src/graphql/documents/` に定義されている - [ ] 生成された型を使用している - [ ] loading, error, dataの状態を適切に処理している #### テスト - [ ] ユーティリティ関数にテストが追加されている - [ ] 重要なビジネスロジックにテストがある - [ ] フォームバリデーションのテストがある ### 3. レビュー結果のまとめ ## 出力フォーマット ```markdown # レビュー結果 ## 変更サマリー - 変更ファイル数: X件 - 追加行数: +XXX - 削除行数: -XXX ## 変更ファイル ### UIコンポーネント - `path/to/component.tsx`: 説明 ### ビジネスロジック - `path/to/logic.ts`: 説明 ## レビュー評価 ### ✅ 良い点 - 具体的な良い点1 - 具体的な良い点2 ### ⚠️ 改善が必要な点 - 具体的な改善点1（優先度: 高/中/低） - 具体的な改善点2（優先度: 高/中/低） ### 🔍 確認事項 - 確認が必要な点1 - 確認が必要な点2 ### 📋 チェックリスト結果 - ✅ 機能: 問題なし - ✅ コード品質: 問題なし - ⚠️ セキュリティ: 要確認 - ✅ パフォーマンス: 問題なし - ✅ UI/UX: 問題なし ## 総合評価 [承認可能 / 修正推奨 / 修正必須] ## コメント 全体的な所感やアドバイスを記載 ``` ## 実行例 ```bash # 1. 現在のブランチを確認 git branch --show-current # 2. マージ先ブランチとの差分を確認 git diff main...HEAD --stat # 3. 変更されたファイルのリストを取得 git diff main...HEAD --name-only # 4. 各ファイルの差分を確認 git diff main...HEAD # 5. Lintエラーを確認（変更されたファイルのみ） # read_lints ツールを使用 ``` ## 注意事項 - 比較元ブランチは既定で `main`（ユーザー指定があればそちらを優先） - プロジェクトの規約（`.cursor/rules/`）に準拠しているか確認 - React Native / Expo / iOS特有の考慮事項を重視 - 批判的ではなく建設的なフィードバックを心がける - 優先度を明確にする（高/中/低） - 具体的な改善案を提示する - 変更の意図を理解した上でレビューする - 日本語で簡潔に書く
