本プロジェクトでは、毎週の定例に合わせてアジェンダを作成し、その内容について会話していくサイクルを回しています。
しかし、毎回進捗を確認してアジェンダを作成するという作業は面倒くさいもので、口頭での説明をメインにして準備作業を簡略化してしまいがちでした。
そこで今回 Cursor と GitHub MCP を活用して、これらの作業を自動化・効率化する仕組みを作ってみたところ、非常に実用的だったのでご紹介します。
前提
本プロジェクトでは、以下の情報をすべて GitHub で一元管理しています。
弊社で標準的に使われているのは Backlog ですが、今回のような AI 活用を行う上では GitHub を Single Source of Truth とした方が精度が高いと判断しました。
- スケジュール (Project)
- 課題管理（Issues）
- ドキュメント・ソースコード（Repository）
- アジェンダ (Wiki)
課題と解決策
【課題】
- 準備作業を簡略化してしまうことで、本来可視化すべき進捗の細かいニュアンスが抜け落ちたり、「何がどこまで進んでいるか」の解像度が下がってしまったりしていた
- 振り返る際もわかりづらく、あれはいつどこで決めたっけ？といった状況が発生し、見つけるのに時間がかかっていた
【解決策】
- 既に本プロジェクトで利用していた Cursor を軸に考え、その MCP 機能 を利用した
- Cursor 上の AI が GitHub の Issue・プルリクエスト・コミット履歴を直接読みに行き、一次情報を踏まえて要約してくれるため、手作業による準備なしで「進捗の解像度」を高く保てるようになった
- 過去の経緯も AI が文脈を理解して検索・回答してくれるため、「いつどこで決めたか」を即座に特定でき、振り返りの時間が大幅に短縮された
実際に作成したアジェンダ例
## サマリ
- 機能要件・技術スタックまわりの仕様アップデート（構成図・Webhook 方式の見直し）について PR ベースで議論を進行中（PR #52）。
- 画面遷移図・画面設計書・コンポーネント設計書のドラフトが出揃い、UI/UX と機能要件のすり合わせフェーズに入る準備が整っている（PR #51）。
- 1 月以降に着手予定のインフラ設計・CI/CD・テスト実装などの Issue 群が整理され、開発スコープと優先度を再確認するタイミング。
## 定例アジェンダ
- Webhook → ポーリング変更の方針確認
- PR #52 の内容レビュー
- 機能要件に過不足がないか
- 構成図・技術スタックの変更点の妥当性
- 画面設計・画面遷移のレビュー
- PR #51 の画面遷移図・画面設計書・コンポーネント設計書の確認
- 利用シナリオと画面遷移の整合性チェック
- 追加・削除が必要な画面／コンポーネントの洗い出し
- 今後の開発スケジュールとタスク分解
- インフラ設計（Issue #34, #31）と CI/CD（Issue #49）、テスト実装（Issue #30, #50）の進め方
- 課題・オープンクエスチョンの確認
- 時間同期の扱い（Issue #45）
- 追加機能（要検討）の優先度（Issue #43）
## 進捗詳細
- PR・Issue 状況
- PR #52:
- 構成図から API Gateway / GCS（静的バケット）を削除し、Cloud Run 周りを具体化
- 技術スタックの修正および Webhook 方式をポーリングに変更
- PR #51:
- 画面遷移図・画面設計書・コンポーネント設計書のドラフト作成済み
- 今週はレビュー観点の整理と、要修正点の洗い出しが主なターゲット
- 中長期タスク
- Issue #31: 開発 – 1/13〜2/18 で本格着手予定
- Issue #34: インフラ設計・開発・テスト – 同上期間で進行予定
- Issue #30: システムテスト – 1/29〜2/18
- Issue #33: リリース – 2/24〜2/27
- Issue #49: CI/CD、Issue #50: テスト実装 – 1/5〜1/30 の期間で準備・設計を進行予定
この内容は後述のプロンプトに依存するため、そのプロジェクトに合った出力へ調整できます。
設定方法
設定手順は非常に簡単です。
1. GitHub MCPサーバーの設定
Cursor Settings > Tools & MCP を開き、+ Add New MCP Server ボタンをクリックして設定します。
私の場合は既に他の MCP サーバーを設定していたため、直接 JSON ファイルを編集する形で設定しました。
{
"mcpServers": {
"github": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-github"
],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "xxxxxxxxxxxx",
"GITHUB_ORGANIZATION": "YOUR_ORGANIZATION_NAME",
"GITHUB_REPOSITORY": "YOUR_REPOSITORY_NAME",
"GITHUB_USERNAME": "YOUR_USERNAME"
}
}
}
}
なお、GITHUB_ORGANIZATION、GITHUB_REPOSITORY、GITHUB_USERNAME は必須ではありませんが、精度向上やセキュリティの観点から設定しています。
2. アジェンダ作成プロンプト
設定が完了すると、Cursorのチャット欄で MCP を利用するような指示を出せば、リポジトリ内の情報を検索・参照できるようになります。
今回は、以下のようなプロンプトを Cursor Rules に設定しておき、「今週のアジェンダを作成して」と言うだけでアジェンダの作成、および GitHub Wiki へのコミットまで行うようにしました。
---
description:
globs:
alwaysApply: true
---
あなたは `YOUR_ORGANIZATION_NAME/YOUR_REPOSITORY_NAME` の専任PMです。
以下のフローに従い、アジェンダの作成からWikiへの反映までを遂行してください。
# Context
- **ソースリポジトリ**: `YOUR_ORGANIZATION_NAME/YOUR_REPOSITORY_NAME` (MCPで情報取得)
- **Wikiローカルパス**: `git/YOUR_REPOSITORY_NAME.wiki` (ファイル操作/Git操作用)
- **対象期間**: 直近1週間
- **ファイル名日付**: 定例の日付（例: 今日が1/9(金)なら `20260109`）
# Workflow
## Phase 1: ドラフト作成と確認
1. ソースリポジトリからMCPで今週のコミット・PR・Issueを取得・分析します。
2. 以下のフォーマットでアジェンダのMarkdownを作成し、提示してください。
- ファイル名: `YYYYMMDD.md`
- 内容: サマリ、定例アジェンダ、進捗詳細、来週のタスク
3. **ここで一旦停止し、ユーザー（私）に内容の確認を求めてください。**
## Phase 2: Wikiへの反映（承認後）
私が「OK」「反映して」と指示したら、以下のコマンド/ファイル操作をツールを使って直接実行してください。
1. **ファイル作成**: Wikiローカルパスに `YYYYMMDD.md` を作成し、アジェンダ内容を書き込む。
2. **インデックス更新**: 同ディレクトリの `アジェンダ.md` の末尾に `- [[{YYYYMMDD}]]` を追記する。
3. **Git反映**:
```bash
cd git/YOUR_REPOSITORY_NAME.wiki
git add YYYYMMDD.md アジェンダ.md
git commit -m "docs: 週次アジェンダ追加 ({YYYY-MM-DD})"
git push origin main
導入後の効果
1. 課題の詳細まで踏み込んだ「質の高い」アジェンダ
従来の課題管理ツールから CSV エクスポートして加工する方法では、タイトルやステータスといった表面的な情報しか抽出できませんでした。
しかし、MCP 経由で LLM に読ませることで、Issue の中での議論の流れや、プルリクエストでの修正内容といった「コンテキスト」 まで含めた要約が可能になります。
これにより、「進捗あり」の一言では片付けられない、質の高いアジェンダが自動生成されるようになりました。
2. 実用レベルの精度
正直なところ、「MCP で外部ツールと連携できる」というのは知識として知っていましたが、実際に試してみるまでは「まあ、補助にはなるかな？」程度の期待値でした。
しかし実際に使ってみると、必要な情報を過不足なく拾ってきてくれるため、十分実務で使えるレベルとなっています。
3. 意思決定プロセスの資産化（今後の展望）
作成されたアジェンダを NotebookLM や Gemini Enterprise に連携させることで、「あの件、いつどういう経緯で決まったっけ？」と自然言語で質問すれば即座に回答が得られるデータベースが構築できると考えています。
また、Google Meet などの文字起こし機能などで定例の議事録も自動化させれば、さらに精度が高まるのかなと思いました。
別途連携する仕組みが必要ですが、ここまで自動化できればプロジェクト管理の負担はさらに下がると思います。
終わりに
今回の取り組みで、進捗確認の工数を減らしつつ、プロジェクトの状況をより高い解像度で可視化できるようになりました。
ぜひ皆さんのチームやプロジェクトでも導入を検討してみてください。
簡単30秒