Prime Style MCP

ダークモード

実践: コードレビューをMCPで効率化する ​

コードレビューはソフトウェア品質の要ですが、レビュアーの負担は大きく、観点の抜け漏れも発生しがちです。このチュートリアルでは、MCPの品質レビュープロンプトを使い、コードレビューをより体系的かつ効率的に進める方法を学びます。

🎯 このチュートリアルのゴール ​

  • 品質レビュープロンプトの基本的な使い方を理解する。
  • review_focusを切り替えることで、多角的なレビューを行う方法を学ぶ。
  • MCPからの応答を、実際のレビューコメントに活かす方法を習得する。

fictional シナリオ設定 ​

あなたは、同僚が作成したPull Request (PR) をレビューすることになりました。PRの内容は「ユーザー情報を取得するための新しいAPIエンドポイント(/users/{userId})の追加」です。

あなたはレビュアーとして、この変更がプロジェクト全体の品質基準を満たしているかを確認する必要があります。

Step 1: レビューの準備 ​

まず、MCPに渡す情報を整理します。品質レビュープロンプトは、主にpr_descriptionとchanged_files_summaryの2つの情報を必要とします。

  • pr_description: PRの概要説明をそのまま使います。
  • changed_files_summary: 変更されたファイルの概要を渡します。git diff --statの結果や、GitHubが生成するファイルリストなどを要約して使うと良いでしょう。
text:PRの情報
【pr_description】
ユーザー情報を取得するためのGET /users/{userId} エンドポイントを追加しました。
- `user_service.py`に`get_user_by_id`メソッドを実装。
- `main.py`にエンドポイントのルーティングを追加。
- `test_users.py`にテストケースを追加。

【changed_files_summary】
- src/main.py | 15 ++
- src/services/user_service.py | 30 +++++
- tests/test_users.py | 50 +++++++++

Step 2: 観点を変えてプロンプトを実行する ​

MCPの品質レビュープロンプトは、review_focusパラメータで観点を切り替えられるのが特徴です。Claude Codeからこのプロンプトを呼び出してみましょう。

方法1: スラッシュコマンド (推奨) ​

review_focusパラメータの値を "設計" や "セキュリティ" に変えて、複数回スラッシュコマンドを実行します。

観点1: 「設計」のレビュー ​

/mcp__psm__code_review_framework pr_description="ユーザー情報を取得するためのGET /users/{userId} エンドポイントを追加しました..." changed_files_summary="src/main.py | 15 ++\nsrc/services/user_service.py | 30 +++++..." review_focus="設計"

観点2: 「セキュリティ」のレビュー ​

/mcp__psm__code_review_framework pr_description="ユーザー情報を取得するためのGET /users/{userId} エンドポイントを追加しました..." changed_files_summary="src/main.py | 15 ++\nsrc/services/user_service.py | 30 +++++..." review_focus="セキュリティ"

MCPは、それぞれの観点に特化したレビューポイントを返却します。

方法2: メンション ​

対話形式で、より自然にレビューを進めることもできます。

観点1: 「設計」のレビュー ​

@psm 品質レビュープロンプトを使って、このPRを「設計」の観点でレビューしてください。

PR説明:
ユーザー情報を取得するためのGET /users/{userId} エンドポイントを追加しました。
- `user_service.py`に`get_user_by_id`メソッドを実装。
- `main.py`にエンドポイントのルーティングを追加。

変更ファイル概要:
- src/main.py | 15 ++
- src/services/user_service.py | 30 +++++

観点2: 「セキュリティ」のレビュー ​

続いて、同じスレッド（文脈）でセキュリティ観点のレビューを依頼します。

ありがとう。次は同じPRを「セキュリティ」の観点でレビューしてください。

Claude Codeが文脈を記憶していれば、再度PRの説明などを入力する必要はありません。

参考: curl を使ってAPIを直接呼び出す場合

curlを使ってAPIを直接呼び出すこともできます。

bash
# 観点1: 「設計」のレビュー
# 環境変数 MCP_SERVER_URL と MCP_API_KEY が設定されている必要があります
curl -X POST "$MCP_SERVER_URL/prompts/code_review_framework" \
  -H "Authorization: Bearer $MCP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "pr_description": "ユーザー情報を取得するためのGET /users/{userId} エンドポイントを追加しました...",
    "changed_files_summary": "src/main.py | 15 ++\nsrc/services/user_service.py | 30 +++++...",
    "review_focus": "設計"
  }'

# 観点2: 「セキュリティ」のレビュー
curl -X POST "$MCP_SERVER_URL/prompts/code_review_framework" \
  -H "Authorization: Bearer $MCP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "pr_description": "ユーザー情報を取得するためのGET /users/{userId} エンドポイントを追加しました...",
    "changed_files_summary": "src/main.py | 15 ++\nsrc/services/user_service.py | 30 +++++...",
    "review_focus": "セキュリティ"
  }'

Step 3: 結果をレビューコメントに活用する ​

MCPからの応答は、レビュアーであるあなたの思考を補助するためのものです。応答をそのままコピー＆ペーストするのではなく、内容を吟味し、自分の言葉でPRにコメントしましょう。

MCPからの応答（設計レビューのサンプル）

json
{
  "review_type": "設計",
  "checkpoints": [
    {
      "point": "エンドポイントの命名規則",
      "status": "OK",
      "comment": "GET /users/{userId} はRESTfulな命名規則に準拠しています。"
    },
    {
      "point": "責務分離",
      "status": "SUGGESTION",
      "comment": "ビジネスロジックが`main.py`のルーティング層に漏れ出していませんか？ `user_service.py`に完全に移譲されているか確認してください。"
    },
    {
      "point": "エラーハンドリング",
      "status": "CONFIRM_REQUIRED",
      "comment": "ユーザーが存在しない場合、適切なHTTPステータスコード（例: 404 Not Found）が返却される設計になっていますか？"
    }
  ]
}

あなたが書くレビューコメントの例

設計の観点でレビューしました。

  • user_serviceへの責務分離は良さそうですね！
  • 1点確認ですが、ユーザーが見つからなかった場合の404エラーのハンドリングは実装されていますか？テストケースにもその観点を追加すると、より堅牢になるかと思います。

まとめ ​

このチュートリアルでは、品質レビュープロンプトを使い、多角的な視点から効率的にコードレビューを行う方法を学びました。

MCPをレビュープロセスに組み込むことで、レビュアーは定型的なチェックをMCPに任せ、より本質的な議論に集中できます。これにより、チーム全体のレビュー品質と開発速度の向上が期待できます。

MIT License

Copyright © 2024-present Prime Style