Cursor × GitHub MCPによる開発生産性向上の実践知

サムネイル

はじめに
背景
Cursor Rules / Command を活用したコマンド作成
今後の展望
- Cursor CLI を使用した AI 活用
- 他チームへの展開
まとめ

はじめに

こんにちは。DMMユーザーレビューグループ（URG）の大野です。

本記事では、Cursor と GitHub MCP（Model Context Protocol）を組み合わせて実現した開発効率化の取り組みについて紹介します。

背景

昨今、生成 AI を活用した開発ツールが急速に発展しており、開発プロセスの各段階で効率化を図ることが可能になってきました。

私たちのチームでも、AI を活用した開発効率化に取り組んでいます。
AI 活用を進める中で、開発プロセスには以下のような課題があることに気づきました。

PR 作成時の説明内容のばらつき：メンバーによって PR の説明内容に差があり、背景が不明確な PR や実装内容の説明が不足している PR があると、レビュアーが変更内容を理解するのに時間がかかり、レビュー工数が増えてしまう
レビューコメント対応の手間：チームの大半が Cursor で開発をしているが、レビューコメントに対応する際、GitHub（Web）からコメントをコピーして Cursor の AI エージェントに貼り付けるという手間があった
リリース作業の煩雑さ：複数のツール（GitHub、Slack、Google カレンダーなど）を行き来しながら手動で作業する必要があった

これらの課題を解決するため、Cursor と GitHub MCP を組み合わせたコマンドを作成しました。

特に、Cursor のような AI 統合型エディタと MCP サーバーを組み合わせることで、従来手作業で行っていた作業を自動化し、開発者の生産性を大幅に向上させることができます。

本記事では、以下の取り組みについて詳しく解説します。

Cursor Rules / Command を活用したカスタムコマンドの作成
- PR 作成コマンド（ブランチ差分からの自動概要生成）
- レビューコメント取得コマンド（CodeRabbit などの指摘を迅速に確認）
- リリース用 make コマンド（複数のツールで行う作業を一括実行）
効果測定と実際の成果

なお、GitHub MCP サーバーは、Cursor の AI エージェントが GitHub API を使えるようにする仕組みです。

用語説明

GitHub MCP（Model Context Protocol）
GitHub MCP は、AI エージェントが GitHub API を安全に利用できるようにするための仕組みです。
Cursor などの AI エディタから、PR 作成・コメント取得・Issue 参照といった GitHub 操作を、自然言語ベースで実行できるようになります。

Cursor Rules / Command
Cursor Rules は、AI エージェントの振る舞い（コーディング規約や出力形式など）を定義する仕組みです。
Command は、特定のタスク（PR 作成、レビューコメント取得など）を実行するためのカスタムコマンドです。

CodeRabbit
CodeRabbit は、PR に対して自動でコードレビューを行う AI レビューツールです。
PR 作成直後に指摘コメントを返してくれるため、人手レビュー前の早期フィードバックが可能になります

Cursor Rules / Command を活用したコマンド作成

Cursor には、AI エージェントの動作を制御するための「Rules」と、カスタムコマンドを定義するための「Command」という機能があります。

Rules は AI の動作方針を定義する機能（コーディング規約、スタイルガイドなど）で、Command は特定のタスクを実行する機能（PR 作成、レビューコメント取得など）です。

PR 作成コマンド

課題

チーム内で PR を作成する際、メンバーによって説明内容にばらつきがありました。

背景が不明確な場合や実装内容の説明が不足している場合、レビュアーが変更内容を理解するのに時間がかかり、レビューにかかる工数が増えてしまいます。
実装の説明粒度を統一し、背景整理やレビュー工数を削減する仕組みが必要でした。

施策

ブランチの差分を分析し、PR の概要、背景、実施内容を自動生成して PR を作成するコマンドを実装しました。

実装の詳細

PR 作成コマンドは、Cursor Command として実装しています。

PR 作成コマンドの実装の詳細

以下の流れで動作します。

ブランチ差分の取得：git diff を使用して、現在のブランチとベースブランチ（通常は main や develop）の差分を取得
変更ファイルの分析：変更されたファイルの一覧と、各ファイルの変更内容を分析
コード差分の抽出：追加・削除・変更されたコードを抽出
PR 情報の自動生成：取得した情報を基に、以下の項目を自動生成
- 背景：なぜこの変更が必要だったのか
- 概要：この PR で何を実現するのか
- 実施内容：具体的にどのような変更をしたか
PR の作成：生成した情報を GitHub MCP サーバー経由で GitHub API を呼び出し、PR として作成

ルールサンプル

現在のブランチの差分情報を取得し、GitHub に Pull Request を作成してください。
以下の手順と制約を必ず守ってください。
 
1. 引数として説明文が指定されている場合はそれを使用し、なければ変更点から自動生成する
  ```bash
  # 現在のブランチと変更点を確認（ワンライナーで実施すること）
  branch=$(git branch --show-current); git diff origin/main "$branch" --name-status; git diff origin/main "$branch" --stat
  ```
 
2. 以下のフォーマットに従ってPRを構成する：
  ```markdown
  ## 背景
  この変更が必要になった理由や課題

  ## 概要
  この PR で実現することの要約

  ## 実施内容
  - 具体的な変更点を箇条書きで記載
  - ファイル単位または機能単位で整理する

  ## 参考
  - 関連する Issue、PR、ドキュメント（あれば）
  ```

3. 作成内容をユーザーに提示し、確認を求める：
  - タイトル：[生成されたタイトル]
  - 説明文：[生成された説明文]
4. ユーザーから「OK」「Yes」「はい」など明確な承認を得た場合のみPRを作成する

※全てのルールについて具体的に記載すると長くなってしまうため、簡単な説明に留めさせていただきます。

効果

PR 作成コマンドを使用することで、以下の効果が得られました。

PR 内容の自動生成：ブランチの差分から、背景、概要、実施内容が自動的に生成されるため、PR の説明文を手動で書く必要がなくなりました
PR 説明文の作成時間
- 導入前：1 PR あたり約 10〜15 分
- 導入後：1 PR あたり約 2〜3 分
- → 約 80% の工数削減
品質向上：自動生成される PR の概要説明が詳細かつ一貫性のあるものになり、レビュアーが変更内容を迅速に把握できるようになりました
背景の明確化：なぜこの変更が必要だったのかという背景が自動的に記載されるため、後から見返した際にも理解しやすくなりました
レビュー開始までのリードタイム
- 説明不足による差し戻しや確認コメントが減少
- レビュー開始までの待ち時間が平均で 約 20〜30% 短縮

特に、複数のファイルにまたがる変更や、大きな機能追加の際には、手動で説明文を書くよりも、AI が生成した説明は網羅的で分かりやすいことが多々ありました。
また、「背景が不明確でレビューできない」ケースはほぼ発生しなくなりました。

レビューコメント取得コマンド

課題

チームのメンバーの大半が Cursor で開発をしています。レビューコメントに対応する際、GitHub（Web）からコメントをコピーして Cursor の AI エージェントに貼り付けるという手間がありました。
この手間を削減し、Cursor 内で完結できるようにする必要がありました。

施策

指定した PR 番号のレビューコメントを一覧取得し、Cursor で修正するためのコマンドを実装しました。このコマンドも Cursor Command として実装しています。

実装の詳細

レビューコメント取得コマンドは、以下の流れで動作します。

PR 番号の指定：ユーザーが PR 番号を指定
レビューコメントの取得：GitHub API 経由で、その PR のレビューコメントを取得
フィルタリング：解決済みのコメントを除外（オプション）
コメントの表示：取得したコメントを Cursor エディタ上に表示
修正の実行：Cursor の AI エージェントにコメントの内容を伝え、修正を依頼

ルールサンプル

## GitHub MCP PRレビューコメント機能 使用ガイド
 
##### 実行フロー
1. PR番号の抽出・検証
2. GitHub APIを使用したコメント取得
3. 解決状況の判定・フィルタリング
4. 指定フォーマットでの表示
 
#### 基本的な使い方
指定されたPRのレビューコメント一覧を表示します。
未解決のコメントのみを表示し、解決済みのものは除外されます。

#### 利用可能なコマンド例

##### 基本的なPRレビューコメント取得
- 「#1111 のレビューコメント一覧は？」
- 「PR #1397 のレビューコメントを確認したい」
- 「PR #1402 の未解決コメントを表示して」
 
#### 出力される情報
 
##### レビューコメント表示項目
- **ファイル名**: コメント対象のファイルパス
- **行番号**: コメントが付いた行
- **作成者**: レビュアーのGitHubユーザー名
- **作成日時**: コメント投稿日時
- **コメント内容**: レビューコメントの本文
- **解決状況**: 解決済み/未解決の状態
 
#### 出力フォーマット（必須遵守）
 
**重要**: PRレビューコメント一覧を表示する際は、以下のフォーマットを必ず使用してください。
 
```markdown
## 🔍 **PR #番号 レビューコメント一覧**
 
### ⚠️ **未解決コメント**
 
#### **コメント #ID** - ファイル名:行番号
- **作成者**: GitHubユーザー名
- **作成日**: YYYY-MM-DD HH:MM
- **ファイル**: ファイルパス
- **行番号**: 行数
- **内容**: コメント本文
- **状態**: 未解決
 
### ✅ **解決済みコメント** (オプション)
 
#### **コメント #ID** - ファイル名:行番号 
- **作成者**: GitHubユーザー名
- **作成日**: YYYY-MM-DD HH:MM
- **解決日**: YYYY-MM-DD HH:MM
- **内容**: コメント本文
- **状態**: 解決済み
```

※全てのルールについて具体的に記載すると長くなってしまうため、簡単な説明に留めさせていただきます。

レビューコメント取得コマンドの実装の詳細

CodeRabbit、GitHub Copilot との連携

CodeRabbit、GitHub Copilot 等のAIコードレビューツールの特徴は、PR を作成するとすぐにレビューコメントを返してくれることです。
人間のレビュアーによるレビューは時間がかかりますが、AIコードレビューツールは PR を出した直後にフィードバックを提供してくれるため、早期のフィードバック対応が可能になります。

効果

レビューコメント取得コマンドの導入により、以下の効果が得られました。

Cursor 内での完結：GitHub（Web）からコメントをコピーして Cursor に貼り付ける手間がなくなり、Cursor 内で完結できるようになりました
早期対応：AIコードレビューツールの指摘を迅速に取得し、対応できるようになりました
修正の自動化：軽微な指摘については、Cursor の AI エージェントが自動的に修正するため、開発者の負担が軽減されました
対応漏れの防止：解決済みコメントを除外する機能により、未対応のコメントに集中できるようになりました
初回フィードバック対応までの時間
- AIコードレビューツールの指摘を PR 作成直後に即取得
- 指摘対応開始までの時間が平均で 10 分以上短縮

リリース自動化コマンド

課題

リリース作業の際に、以下の作業に時間がかかっていました。

複数のツール（GitHub、Slack、Google カレンダーなど）を行き来しながら手動で作業する必要があった
手順が統一されておらず、メンバーによって作業内容にばらつきがあった
通知漏れやカレンダー登録漏れなどの人的ミスが発生していた

これらの課題を解決するため、リリース作業を自動化する仕組みが必要でした。

施策

リリース作業を自動化するため、複数のツールで行う作業を一括で実行する make コマンドを実装しました。

実装の詳細

リリース用 make コマンドは、以下のステップを順次実行します。

タグの作成：指定されたバージョン番号で Git タグを作成
リリースノートの作成：前回のリリース以降の変更内容を集計し、リリースノートを自動生成（gh release create を使用）
Slack 通知：リリース情報をチームの Slack チャンネルに通知（Webhook URL を使用）
Google カレンダー登録：リリース日時を Google カレンダーに登録（Google Calendar のテンプレート URL を組み立て、登録 URL を作成）

各ステップは独立したスクリプトとして実装されており、エラーハンドリングも含まれています。

リリース用 make コマンドのリリースフロー

script 実装にした理由

当初は、リリース用 make コマンドを Cursor Command として実装することを検討しました。
しかし、Cursor Command は sandbox 環境で実行されるため、以下の制約があり実装できませんでした。

外部 API（Slack、Google Calendar など）へのネットワークアクセスが制限される
ファイルシステムへの書き込みが制限される
GitHub で設定した環境変数の取得が制限される

これらの制約により、Slack 通知や Google カレンダー登録などの外部 API 呼び出しが必要な処理を Cursor Command で実装できませんでした。
そのため、従来の script 実装を採用し、make コマンドとして実装しています。

効果

リリース用 make コマンドの導入により、以下の効果が得られました。

作業の一元化：複数のツールで行う作業を 1 つのコマンドで実行できるようになり、複数のツール（GitHub、Slack、Google カレンダー）を行き来する必要がなくなりました
手順の統一：チーム全員が同じ手順でリリース作業を行えるようになり、ミスの削減につながりました
リリース作業の簡素化：コマンド 1 回の実行でリリース作業が完了するため、作業の負担が大幅に軽減されました
- 導入前：30〜40 分（複数ツールを横断）
- 導入後：5〜10 分（コマンド 1 回）
- → 約 70% 以上の工数削減
人的ミスの削減：Slack 通知漏れ、カレンダー登録漏れなどがほぼゼロになりました