🚀 GitHubコードレビューアシスタントMCPサーバー
GitHubのプルリクエストのコードレビューに役立つ高度なツールを提供する、包括的なMCP(Model Context Protocol)サーバーです。このサーバーを使用すると、AIアシスタントがPRを分析し、改善案を提案し、パターンをチェックし、チームの標準に沿った一貫性を確保することができます。
✨ 主な機能
- 包括的なPR分析 - コードのパターン、複雑性、潜在的な問題を分析します。
- レビュー管理 - コメントを作成し、レビューを提出し、フィードバックを管理します。
- スマートな提案 - ベストプラクティスに基づいたAIによるレビュー提案を提供します。
- 標準準拠チェック - チームのコーディング標準に沿ってPRをチェックします。
- ファイルと差分分析 - 変更内容とその影響を詳細に調査します。
- ワークフロー統合 - 完全なレビューワークフローに対応したツールです。
📦 インストール
前提条件
- Python 3.8以上
repoスコープを持つGitHubパーソナルアクセストークン
- MCP互換クライアント(例:Claude Desktop、または任意のMCPクライアント)
セットアップ
- 依存関係をインストールする:
pip install mcp httpx pydantic
- GitHubトークンを設定する:
- GitHubの設定 → 開発者設定 → パーソナルアクセストークンに移動します。
repoスコープを持つ新しいトークンを生成します。
- トークンを安全に保存します。
- サーバーを起動する:
python github_code_review_mcp.py
Claude Desktopの設定
Claude Desktopの設定ファイルに以下を追加します:
{
"mcpServers": {
"github-code-review": {
"command": "python",
"args": ["/path/to/server.py"]
}
}
}
💻 使用例
利用可能なツール
1. github_list_pull_requests
リポジトリ内のプルリクエストを包括的なフィルタリングオプションで一覧表示します。
パラメータ:
owner:リポジトリの所有者(必須)
repo:リポジトリ名(必須)
github_token:GitHubアクセストークン(必須)
state:状態でフィルタリング(open/closed/all)
sort:並べ替え基準(created/updated/popularity/long-running)
direction:並べ替え方向(asc/desc)
base:ベースブランチでフィルタリング
head:ヘッドブランチでフィルタリング
limit:最大結果数(1-100)
page:ページネーションのページ番号
response_format:出力形式(markdown/json)
使用例:
facebook/reactリポジトリ内のすべてのオープンPRを一覧表示する
2. github_get_pr_details
特定のプルリクエストに関する包括的な詳細情報を取得します。
パラメータ:
owner:リポジトリの所有者(必須)
repo:リポジトリ名(必須)
github_token:GitHubアクセストークン(必須)
pr_number:プルリクエスト番号(必須)
include_reviews:レビュー情報を含める(デフォルト: true)
include_checks:ステータスチェックを含める(デフォルト: true)
response_format:出力形式(markdown/json)
使用例:
レビューとチェックを含めて、PR #123に関する詳細情報を取得する
3. github_get_pr_files
プルリクエストで変更されたすべてのファイルを統計情報とともに一覧表示します。
パラメータ:
owner:リポジトリの所有者(必須)
repo:リポジトリ名(必須)
github_token:GitHubアクセストークン(必須)
pr_number:プルリクエスト番号(必須)
limit:ページあたりの最大結果数
page:ページ番号
response_format:出力形式(markdown/json)
使用例:
PR #456で変更されたすべてのファイルを表示する
4. github_get_pr_diff
プルリクエストの統合差分を取得します。
パラメータ:
owner:リポジトリの所有者(必須)
repo:リポジトリ名(必須)
github_token:GitHubアクセストークン(必須)
pr_number:プルリクエスト番号(必須)
file_path:特定のファイルでフィルタリング(オプション)
context_lines:コンテキスト行数(0-10)
使用例:
PR #789の差分を取得し、src/main.jsに焦点を当てる
5. github_analyze_pr
プルリクエストのコード品質に関する包括的な分析を実行します。
パラメータ:
owner:リポジトリの所有者(必須)
repo:リポジトリ名(必須)
github_token:GitHubアクセストークン(必須)
pr_number:プルリクエスト番号(必須)
check_patterns:コードパターンをチェックする(デフォルト: true)
check_complexity:複雑性を分析する(デフォルト: true)
check_security:基本的なセキュリティチェックを行う(デフォルト: true)
response_format:出力形式(markdown/json)
使用例:
PR #234のコードパターン、複雑性、セキュリティ問題を分析する
6. github_get_pr_comments
プルリクエストに関するすべてのコメントを取得します。
パラメータ:
owner:リポジトリの所有者(必須)
repo:リポジトリ名(必須)
github_token:GitHubアクセストークン(必須)
pr_number:プルリクエスト番号(必須)
comment_type:コメントの種類(all/issue/review)
limit:最大結果数
page:ページ番号
response_format:出力形式(markdown/json)
使用例:
PR #567のすべてのレビューコメントを取得する
7. github_create_review_comment
プルリクエストにコメントを作成します(一般的またはインライン)。
パラメータ:
owner:リポジトリの所有者(必須)
repo:リポジトリ名(必須)
github_token:GitHubアクセストークン(必須)
pr_number:プルリクエスト番号(必須)
body:Markdownをサポートするコメントテキスト(必須)
commit_id:コメントするコミットのSHA(オプション)
path:インラインコメントのファイルパス(オプション)
line:インラインコメントの行番号(オプション)
side:差分の側(LEFT/RIGHT)
使用例:
src/utils.jsの42行目にパフォーマンス改善の提案コメントを追加する
8. github_create_pr_review
プルリクエストに正式なレビューを提出します。
パラメータ:
owner:リポジトリの所有者(必須)
repo:リポジトリ名(必須)
github_token:GitHubアクセストークン(必須)
pr_number:プルリクエスト番号(必須)
body:レビューの要約テキスト(オプション)
event:レビューアクション(APPROVE/REQUEST_CHANGES/COMMENT)
comments:インラインレビューコメントの配列(オプション)
使用例:
良好なテストカバレッジについてコメントしながら、PR #890を承認する
9. github_get_review_suggestions
プルリクエストに対するAIによるレビュー提案を生成します。
パラメータ:
owner:リポジトリの所有者(必須)
repo:リポジトリ名(必須)
github_token:GitHubアクセストークン(必須)
pr_number:プルリクエスト番号(必須)
focus_areas:焦点を当てる領域(performance/security/readability/tests/documentation)
response_format:出力形式(markdown/json)
使用例:
セキュリティとパフォーマンスに焦点を当てて、PR #345のレビュー提案を生成する
10. github_check_team_standards
PRがチームのコーディング標準に準拠しているかをチェックします。
パラメータ:
owner:リポジトリの所有者(必須)
repo:リポジトリ名(必須)
github_token:GitHubアクセストークン(必須)
pr_number:プルリクエスト番号(必須)
standards_file:リポジトリ内の標準ファイルのパス(デフォルト: .github/CODING_STANDARDS.md)
response_format:出力形式(markdown/json)
使用例:
PR #678がチームのコーディング標準を満たしているかをチェックする
具体的な使用例
例1:完全なPRレビューワークフロー
github_list_pull_requests(
owner="myorg",
repo="myrepo",
github_token="ghp_xxx",
state="open",
sort="created"
)
github_get_pr_details(
owner="myorg",
repo="myrepo",
github_token="ghp_xxx",
pr_number=123
)
github_analyze_pr(
owner="myorg",
repo="myrepo",
github_token="ghp_xxx",
pr_number=123
)
github_get_review_suggestions(
owner="myorg",
repo="myrepo",
github_token="ghp_xxx",
pr_number=123,
focus_areas=["security", "performance"]
)
github_check_team_standards(
owner="myorg",
repo="myrepo",
github_token="ghp_xxx",
pr_number=123
)
github_create_pr_review(
owner="myorg",
repo="myrepo",
github_token="ghp_xxx",
pr_number=123,
body="Great work! A few suggestions for improvement...",
event="APPROVE"
)
例2:焦点を絞ったコードパターン分析
files = github_get_pr_files(
owner="myorg",
repo="myrepo",
github_token="ghp_xxx",
pr_number=456
)
diff = github_get_pr_diff(
owner="myorg",
repo="myrepo",
github_token="ghp_xxx",
pr_number=456,
file_path="src/api/handler.js"
)
analysis = github_analyze_pr(
owner="myorg",
repo="myrepo",
github_token="ghp_xxx",
pr_number=456,
check_patterns=True,
check_security=True
)
📚 ドキュメント
レビュアー向けベストプラクティス
- 全体像から始める:
github_get_pr_detailsを使用してPRのコンテキストを理解します。
- 最初に分析する:手動レビューの前に
github_analyze_prを実行します。
- 標準をチェックする:一貫性を確保するために
github_check_team_standardsを使用します。
- 提案を取得する:包括的なフィードバックを得るために
github_get_review_suggestionsを使用します。
- 建設的なコメントをする:コメントを作成する際には、具体的で改善案を提案するようにします。
PR作成者向けベストプラクティス
- 自己レビューを行う:レビューを依頼する前に、自分のPRに対して分析ツールを使用します。
- 標準準拠を確認する:提出する前に標準準拠をチェックします。
- PRを集中的にする:分析ツールは、小規模で集中的な変更に対してより効果的に機能します。
- テストを含める:ツールはテストカバレッジをチェックします。
- 良い説明を書く:ツールはPRの説明をコンテキストとして分析します。
セキュリティに関する考慮事項
- トークンのセキュリティ:GitHubトークンをハードコードしないでください。環境変数または安全な資格情報ストレージを使用します。
- 権限:トークンが適切なスコープを持っていることを確認します(通常は
repoで十分です)。
- レート制限:GitHub APIにはレート制限があります。ツールはこれを適切に処理しますが、制限に注意してください。
- プライベートリポジトリ:必要に応じて、トークンがプライベートリポジトリにアクセスできることを確認します。
パターン検出
分析ツールは、以下を含むさまざまなコードパターンを検出します。
- セキュリティ問題:ハードコードされたシークレット、SQLインジェクションのリスク、XSS脆弱性
- パフォーマンス問題:ネストされたループ、SELECT *、非同期コード内の同期操作
- コード品質:コンソールログ、コメントアウトされたコード、空のcatchブロック
- ベストプラクティス:欠落したテスト、大きなファイル、欠落したドキュメント
チーム標準の統合
リポジトリ内に.github/CODING_STANDARDS.mdファイルを作成し、チームの標準を記述します。ツールは自動的にこれを準拠チェックに使用します。例の形式は以下の通りです。
# コーディング標準
## 一般的なルール
- max_file_length: 500
- max_pr_size: 1000
- require_tests: true
- require_documentation: true
## ブランチ命名
- パターン: (feature|bugfix|hotfix|release)/description
## コミットメッセージ
- 形式: type(scope): description
- タイプ: feat, fix, docs, style, refactor, test, chore
トラブルシューティング
一般的な問題
- 認証失敗
- GitHubトークンが有効であることを確認します。
- トークンが必要なスコープを持っていることを確認します。
- トークンが期限切れになっていないことを確認します。
- レート制限
- GitHubは認証済みリクエストのAPI呼び出しを1時間あたり5000回に制限しています。
- ツールはレート制限エラーを報告します。
- 頻繁にアクセスするデータにキャッシュを実装することを検討してください。
- 大規模なPR
- 非常に大きなPRはレスポンスサイズの制限に達する可能性があります。
- ページネーションパラメータを使用します。
- 可能な場合は特定のファイルにフィルタリングします。
- ネットワークエラー
- インターネット接続を確認します。
- GitHub APIにアクセスできることを確認します。
- プロキシ/ファイアウォールの問題を確認します。
コントリビューション
コントリビューションは歓迎されます!改善の余地がある領域は以下の通りです。
- 追加のパターン検出ルール
- GitLab/Bitbucketのサポート
- 強化されたセキュリティスキャニング
- より多くのCI/CDシステムとの統合
- カスタムルールの定義
- パフォーマンス向上のためのキャッシュレイヤー
📄 ライセンス
MITライセンス - 詳細についてはLICENSEファイルを参照してください。
謝辞
以下を使用して構築されています。
サポート
問題、質問、または提案については、以下の方法で対応します。
- GitHubで問題を開く
- ドキュメントを確認する
- トラブルシューティングガイドを確認する
⚠️ 重要提示
このツールはコードレビューを支援するために設計されていますが、人間の判断を置き換えるものではありません。コードをレビューする際には、常にコンテキストとドメイン知識を適用してください。