GitHub MCPを使ってissue作成と実装とプルリク作成を自動化する
なにこれ
Claude Code に指示を出すときにプロンプトを入力するのがめんどくさくなった.issue に書いてあるからよしなに実装してプルリク作成までやってくれると大変楽.そして issue を書くのもめんどくさいので AI にやってほしい.
GitHub と連携するために MCP を使う.Claude Desktop に issue を書かせて Claude Code に一言指示するだけでプルリクが上がってくる状態になった.
AI と人間の分担
だいたい以下のようになった.だいぶ人間が考えることに集中できるようになった.
- 人間: 要件の検討,タスク分解のレビュー,issue のレビュー,プルリクのレビュー,マージ
- AI(Claude Desktop): タスク分解,issue 作成
- AI(Claude Code): 実装,プルリク作成
設定の流れ
GitHub PAT の設定
現状(2025 年 08 月時点) Claude Desktop の設定のときと Claude Code に mcp add
するときに GitHub の Personal Access Token が必要になるので,事前に GitHub の設定をしておく.ググるか AI に訊けばできる.
Claude Desktop の設定
npx のパスを設定する必要があるので確認しておく.
which npx
Settings -> Developer -> Edit Config から JSON を編集する.
{
"mcpServers": {
"github": {
"command": "which npxの結果を入力",
"args": [
"-y",
"@modelcontextprotocol/server-github"
],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "取得したGitHubのPAT"
}
}
}
}
Claude Code の設定
OAuth 経由だとうまくいかないっぽいので PAT を追加する(2025 年 8 月時点)
claude mcp add --transport http github-server https://api.githubcopilot.com/mcp -H "Authorization: Bearer 取得したGitHubのPAT"
開発の流れ
前提
- 全体のドキュメントは作成しておく.
- Claude.md に必ず開発ルールを書いておく.書いていないとスパゲッティコードが爆誕する.
実際の作業
- Claude Desktop で要件など議論しつつタスク分解を行う.
- タスクの粒度がいい感じになったら Claude Desktop に issue を作成させる(MCP 経由).人間は issue をレビューする.
- Claude Code に「issue#00 を確認して実装してプルリクを作成して」みたいに指示して実装とプルリク作成を行う(MCP 経由).
- 人間がプルリクの内容をレビューしてマージする.必要ならローカルで動作確認を行う.マージしたら Claude Code は/clear しておく.
- Claude Desktop に完了した issue とプルリクを参照させ,次の issue を作成させる.
- 以降繰り返し.
コツ
- Claude.md を必ず書く.
- 開発ルールや注意点を記載しておく.
- コーディング規約
- テストの書き方
- 動作確認時の手順・コマンド
- セキュリティに関する注意点
- デバッグ方法
- 開発ルールや注意点を記載しておく.
- issue やプルリクの粒度を小さくする.
- 1 つの issue で 1 つの機能を実装する.
- 複数の機能をまとめて実装しない.
- 複雑になるほどクソデカプルリクになってコードは悲惨になりレビュアー(人間)は死ぬ.
- Claude Desktop の時点で issue の単位に注意して作成させる.
- Claude Code はプルリク作成したら
/clear
する.- issue 単位ごとにクリーンな状態からスタートして余計な情報を持たないようにする.
- 情報が残っているとコンテキストが長くなり,要約されておかしくなる.要約自体の精度がイマイチなので要約された時点で敗北.
- コンテキストが長い場合は issue の粒度が大きすぎる(2 回目).粒度を見直して一撃で実装完了できるようにする.
- プルリクのルールも定めておく.
- テストなどは CI で自動化する.
- 問題のあるコードはこの時点で弾けるように.
- 必ずレビューを行う
- 生成されたコードに絶対はない
- レビューしやすいように issue の粒度を小さくしておく(3 回目)
所感とまとめ
ほぼエディタ開かずに開発が完結するのはとても楽.issue の粒度を細かくしておけばレビューする範囲が少ないので GitHub 上で十分できる.E2E テストも自動化できればローカルの動作確認も減らせそう.
様々な AI が登場しても,人間が開発するときに大事となること(issue の粒度・内容・開発ルールの整備)を行っていけば OK だと感じた.全体の開発自体は変わらず,途中部分を適切に AI に任せることでとても高速かつ楽になるので,今後も新しい活用方法を試していきたい.
AI 時代の人間に求められるのはタスク整理とタスク分割能力.
以上だ( `・ω・)b
Discussion