GitHub MCPを使って、PR作成を半自動化するCopilotプロンプトを作ってみた

普段の開発で、コードを書くのは楽しいけど、その後のプルリクエスト(PR)作成って地味に面倒だったりしませんか? 「やったこと」や「背景」を思い出して、フォーマットに合わせて埋めていく作業。あれ、意外と脳のリソースを持っていかれるんですよね。

そこで今回、GitHub MCP(Model Context Protocol) を活用して、現在のブランチの変更内容からいい感じにPRを作成(または更新)してくれるGitHub Copilot用のプロンプトを作ってみました。

作成した背景

これを作ろうと思った理由は、大きく2つあります。

  1. 業務でのPR作成負荷の低減 仕事だとどうしてもPRの記述ルールがしっかりしている分、作成コストがかかります。ここを自動化して、「PR作成ダルいから後回し」みたいな状況を減らしたかったんです。
  2. 個人開発でのアップデート管理 個人開発だと逆に適当になりがちなんですが、後で見返したときに「これ何だっけ?」となるのを防ぎたい。実際、個人開発ではこのプロンプトをかなりヘビーユーズしてます。

作成したプロンプト

実際に使用しているプロンプトがこちらです。 自分の場合は、例えばリポジトリの .github/prompts/pr-generator.prompt.md というパスに配置して、必要な時に呼び出せるようにしています。 GitHub MCPサーバーが有効になっている環境(VS CodeのCopilot Chatなど)で使っています。

下記はそのまま使用できます。

---
description: GitHub MCPを使用して、現在のブランチの変更内容に基づきPull Requestを作成または更新するためのプロンプト
---

## ユーザー入力

```
$ARGUMENTS
```

**重要:**

1. 処理を開始する前に、上記のユーザー入力(特記事項やフォーカスしてほしい点など)を確認し、反映してください。

2. **関連資料(SpeckitのURL、仕様書のファイルパス、または要件テキスト)** が入力に含まれている場合は、その内容を優先的に参照してください。

## 概要

現在のブランチの変更内容および関連する仕様書・資料を解析し、Pull Request (PR) の内容を提案・作成、または既存のPRを更新します。

# 実行フロー

## 0. 関連資料の事前確認(対話ステップ)

**ユーザー入力 `$ARGUMENTS` に、仕様書や関連資料(SpeckitのURL等)が含まれているか確認してください。**

* **含まれている場合:** そのまま「ステップ1」へ進んでください。

* **含まれていない場合:** ユーザーに以下の確認を行ってください。

  > 「PR作成にあたり、参照すべき仕様書や資料(SpeckitのURL、Markdownファイル等)はありますか? なければ、コミットログと差分から内容を推測して作成します。」

  * ユーザーから資料が提示された場合 $\rightarrow$ 資料を読み込み、「ステップ1」へ。

  * ユーザーから「ない」「そのまま進めて」と返答があった場合 $\rightarrow$ 資料なしで「ステップ1」へ。

## 1. 状況確認とブランチ情報の取得

以下の情報を取得・確認してください。

1. **リポジトリ情報 (`owner`, `repo`)**: 現在のリポジトリの所有者名とリポジトリ名。

2. **現在のブランチ名 (`current_branch`)**: 現在チェックアウトしているブランチ。

3. **ベースブランチ (`base_branch`)**: `main` または `master` (リポジトリのデフォルトブランチ)。

4. **既存PRの確認**: GitHub MCPの `list_pull_requests` (または検索機能) を使用し、`head:current_branch` に一致するOpenなPRが既に存在するか確認してください。

   * 存在する場合: `pull_request_number` を取得し、**更新モード** で進めます。

   * 存在しない場合: **新規作成モード** で進めます。

## 2. 関連資料・仕様書の読み込み

**初期入力、またはステップ0で提示された関連資料(Speckitのリンク、Markdownファイル、Issue番号など)**がある場合、その内容を取得してください。

* **ファイルパスが指定された場合:** そのファイルの内容を読み込んでください(例: `read_file` や `get_file_content` を使用)。

* **テキストとして入力された場合:** そのテキストを「仕様要件」としてコンテキストに含めてください。

* **特に指定がない場合:** コードの変更内容から仕様を推測して進めます。

## 3. 変更差分の取得と解析

以下の手順で変更内容を把握してください。

1. **コミットログの取得**:

   ```
   git log base_branch..HEAD --oneline
   ```

2. **差分の取得**:
   変更の全体像を把握するために、以下のコマンドで差分を取得してください。

   ```
   git diff base_branch...HEAD
   ```

   *※差分が巨大すぎてコンテキストに収まらない場合は、ファイル名リスト (`git diff --name-only`) とコミットメッセージを中心に構成してください。*

## 4. タイトルと本文の作成

取得した **「差分(実装内容)」** と **「関連資料(仕様要件)」** を照らし合わせ、整合性が取れたPRのタイトルと本文を作成します。以下の標準構成に従って作成してください。

**作成時のポイント:**

* 仕様書(関連資料)がある場合、その要件がどのように実装されたかを「HOW」や「ストーリー」に記述してください。

* 仕様と実装に乖離がある場合は、「要確認項目」に注記を追加してください。

**標準構成:**

```
## ストーリー
- 変更の背景と目的
- 関連するユーザーストーリーや要件番号(SpeckitやIssueへのリンクがあればここに記載)
## WHY
- なぜこの変更が必要なのか(仕様書に基づき説明)
## WHAT
- 具体的な変更内容のリスト
## HOW
- 変更をどのように実装したか
## テスト
- 実施したテスト内容と結果
## 修正ファイルの影響箇所
- 変更が影響を与える可能性のある他のモジュールやコンポーネント
## 要確認項目
- レビューアに特に確認してほしいポイント
```

**確認アクション:**
作成した「タイトル」と「本文」を以下の形式で出力し、ユーザーに最終確認を求めてください。

```
タイトル:
{{ 作成したタイトル }}

本文:
{{ 作成した本文 }} 
```

## 5. GitHub MCPによる実行

ユーザーが内容を承認したら、ステップ1で判定したモードに従って GitHub MCP ツールを実行してください。

### ケースA: 新規作成モード

* **使用ツール:** `create_pull_request`

* **引数:**

  * `owner`: {{ owner }}

  * `repo`: {{ repo }}

  * `title`: {{ タイトル }}

  * `body`: {{ 本文 }}

  * `head`: {{ current_branch }}

  * `base`: {{ base_branch }}

### ケースB: 更新モード

* **使用ツール:** `update_pull_request`

* **引数:**

  * `pull_number`: {{ pull_request_number }}

  * `owner`: {{ owner }}

  * `repo`: {{ repo }}

  * `title`: {{ タイトル }} (変更が必要な場合)

  * `body`: {{ 本文 }} (既存の本文に追加するか、置き換えるかはユーザーの指示または文脈に従う)

## エラーハンドリング

* MCPツールの実行に失敗した場合は、エラー内容を表示し、修正案(引数の不足など)を提示してください。

工夫したポイント

個人的にこだわったのは以下の点です。

1. 仕様書や関連資料の確認フロー(ステップ0)

いきなりコードだけを見てPRを作るのではなく、「何か参照する資料ある?」と聞いてくるステップを入れました。 業務ではGitHub Speckitと組み合わせているので、ここで資料のURLを渡すことで、実際のPRにもそのURLが自動的に添付されるようにしています。仕様書やIssueのURLを渡すだけで、実装と仕様を照らし合わせた精度の高いPR本文を書いてくれるようになります。もちろん、資料がない場合はコミットログから推測してくれます。

2. 新規作成と更新の自動判定

GitHub MCPのツールを使って、今いるブランチのPRが既に存在するかを確認させています。 これによって、「まだPRがないなら create_pull_request」「既にあるなら update_pull_request」という使い分けを意識しなくて済みます。

3. 標準構成の定義

「ストーリー」「WHY」「WHAT」「HOW」といった項目をあらかじめ指定しています。 これを指定しておかないと、AIがその時の気分でフォーマットを変えてしまうことがあるので、業務で使うならフォーマット統一は重要ですね。

使ってみた感触

今のところ、このプロンプトのおかげで、コマンドラインやブラウザを行き来する手間はかなり減りました。 特に「差分から勝手に推測してドラフトを書いてくれる」というのは、書き始めのハードルをグッと下げてくれます。 それに加えて、資料(Speckitなど)を渡してあげると、生成されるPRの解像度が段違いに良くなります。自分が実現したかったことが書かれてあって、確認しないといけないことが明確になることが嬉しいポイントです。

個人開発では、とりあえずこのプロンプトを投げてサクッとマージする、というサイクルが定着してきました。