Cursor AgentでPRのdescription作成を自動化する

モチベーション

「PRのdescription（説明文）作成」は、レビューする側にとっても、される側にとっても悩みのタネではないでしょうか。
コードは「施策の意図」や「周囲のコードの状況」など、さまざまなコンテキストを踏まえて書かれています。しかし、これらはファイルの変更差分を眺めているだけではなかなか把握しづらいものです。レビュー中に「なぜこのような実装になっているのだろう？」と疑問を抱き、実装者に確認した経験をお持ちの方も多いのではないでしょうか。

コードから読み取れない部分は、PRのdescriptionやコメントで適宜補足する必要があります。ところが、そのようなコンテキストを適切に伝える文章を書くのは手間がかかるものです。特に弊社のようにスピードが求められる成長段階の企業では、descriptionをほとんど書かずにPRを出してしまうことも珍しくありません。

そこで今回は、弊社で採用しているAI Coding Editor「Cursor」のAgent機能を活用し、PR descriptionの自動生成に挑戦しました。この取り組みにより、レビューする側・される側双方の負担を軽減し、課題を解消することを目指しています。

前提

以下のようにな「PRのURL + 簡単な指示文」をAgentに渡すだけでpr descriptionが生成される状態を目指します。

https://github.com/hoge/huga/pull/1118
このprのdescriptionを作成

CursorのAgentでgithubからの情報を読み取るには、github MCPを使う必要があります。（Cursorのgithub connectだけだと、僕の場合はうまく読み取りをしてくれませんでした。）
具体的な設定方法に関しては、以下のgithub公式のrepositoryも参照して下さい。
https://github.com/github/github-mcp-server

また意図しない挙動を防ぐため、PRの読み込み関連以外のtoolはoffにしておくことをおすすめします。

実際のCursor Rule

Agentが吐き出すPR descriptionのフォーマットを指定するため、PR description作成用のCursor Rulesを作成します。Rule fileを作成しておくことで、作業中にAgentが適宜Rule参照し、そのフォーマットに則った出力をしてくれるようになります。

今回、コード外のコンテキストとして、以下の4点を説明させることにしました。

1. 施策概要
2. ドメイン（新規に作成したschemaとその意図）
3. コーディングポイント（特に書き方が難解な部分）
4. 本施策に関連する以外に影響が出そうな箇所

実際に作成したCursor Rulesが以下です。

---
description: PRのdescription作成の際に適用するルールです
globs:
alwaysApply: false
---

このruleを読み込んだ時は「バックエンドPR作成のルールに則って発言します」と発言してから思考を開始します

# 情報の収集
- バックエンドはrepsitory名 hogeのことです
- このrepositoryのPRのdescription作成を要求されたら、まずその指示にgithubのPRのリンクがあるかを確認します
- githubのPRリンクをMCP(get_pull_request)経由で読み取り、施策の内容を概要とコードの両面から理解します

# まとめ
- 本PRに対してのまとめを、markdown形式で出力します。ユーザーがそのままgithubのdescriptionに貼り付けができるように、インラインでコピー可能な形式で出力してください
- 出力は以下のようなフォーマットにします

## チケット概要
## DB変更
## 技術的ポイント
## 本番反映時作業
## 周辺影響
## テスト

## チケット概要
変更内容から、本施策の内容を読み取り、できるだけ簡潔に、ただし漏れなく記載をします

## DB変更
新規作成したカラムやDBに関しての説明を記載します
説明は以下のような形式でで記載します

### table
table description
|column name|column type|option|column description|
|---|---|---|---|
|hoge|string|null: false|これはhogeのためのカラムです|

テーブルを作成している場合は、周辺テーブルを含めたER図も添付します

## 技術的ポイント
- 説明がないと読めないポイント（可読性が悪い・特定のライブラリ仕様に依存している etc）に対して言及します
- 具体的なコードを貼り、その部分に対して、前提必要な知識、変更内容、特に複雑な部分への詳細解説をできるだけ簡潔に説明します
- 関数の利用法などが変更になる場合、以前との使い方の変化をbefore => afterで比較して載せてあげると親切です
- 全体として見通しが良い場合は、このポイントを省いても構いません

## 本番反映時作業
「※ 本番反映の作業が必要な際はこちらに記載してください」と記述します

## 周辺影響・テスト
- 本PRによって、該当機能および、その他周辺部分で影響が出ると考えられ、テストをした方がいいと考えられる部分を、網羅的かつ簡潔に記載します
- 例えば、commonなlib関数の変更を行った場合、その関数を利用しているその他のコードにも影響が出る可能性があります

実際にやってみた結果

良かったこと

PRにdescriptionを付ける運用を始めてから、レビューの効率が格段に上がったと感じています。
施策の意図や技術的なポイントを事前に把握したうえでコード全体を読むことで、各所の意図をより理解しやすくなりました。
特に規模の大きい施策では、レビューに臨む心理的ハードルが下がった点も大きな効果です。

改善したいこと

一方で、記述する側からは次のような声もあります。
「PRを作成 → 該当PRのURLをCursorに貼る → 生成されたdescriptionをコピーしてPRに反映」という流れが手間に感じられる、というものです。
（PR自体をAgentに作らせればこの手間は省けますが、そこまでを自動化するのは現時点ではリスクが高いと感じています。）
そこで現在は、PR作成をトリガーに、自動でdescriptionを生成しコメントとして投稿する仕組みの実現可能性を調査しています。