⛳
MCP時代にAIが作ったコードをAIがレビューする意義について考える

2025/04/24に公開
GitHub
Model Context Protocol
Cursor
tech
 はじめにChatGPT Code Review や GitHub Copilot などを利用して、AIにコードレビューを任せる試みは実践されている方も多いのではないでしょうか？

しかしここ数ヶ月で状況は少し変わってきているのではないかと思います。
一つには、DevinやClineの登場により、プルリクエストを作成する作者自身がAIであるケースが急増していること。

また一方で、各種MCP（Model Context Protocol）サーバーの登場により、AI同士の連携が非常にスムーズになった事も変化として挙げられるかと思います。
そもそも、AIが書いたコードをAIがレビューするってあんま意味ないんじゃないの？

そういう疑問も発生し得るのかなと個人的には思います。

確かに、実装AIとレビューAIが同じLLMであることは珍しくないですし、後述するようにgithub-mcp-server を使うような場合、実装とレビューでインスタンスまで同じになります。

今の時代にレビューという工程は果たして必要と言えるのでしょうか？
本記事では、はじめにgithub-mcp-serverを使ってAIにプルリクエストを作成させ、そのプルリクを同じくAIにレビューさせるまでの流れを簡単に解説します。

その後、AIが書いたコードをAIがレビューすることの意義について考えてみます。

 手順(cursor&github-mcp-serverの場合)ここは他にも解説記事が多いので簡潔に示しますが

以下の手順で進めていきます。

 設定Node.js（12.x 以上）がインストール済み
GitHub Personal Access Token（PAT）の発行
GitHub の [Settings → Developer settings → Personal access tokens] から新規トークンを作成（特に理由がなければFine-grained Tokenで）
スコープは以下を付与
Repository permissions
Pull Requests
contents（ブランチのpushに使用）

他は好みで
MCP.jsonの設定
GitHub の [Performance → Cursor Settings → MCP → +Add new MCP Server] と進んでいくとMCP.jsonを編集できるので、手順1で発行したtokenと共に以下の設定を記載
{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "[your_token]",
        "GITHUB_USERNAME": "[your_name]"
      }
    },
  }
}

 利用ソースコードの生成
ここは普段の手順で行ってください。AIに作らせる事を念頭に置いていますが、別に自分で書いても良いです。
プルリクエストの作成
LLMクライアント（今回はcursor）にチャット経由でプルリクエストの作成を依頼します。

たまに頑なにgithub-mcpを利用しない方向で頑張ろうとしますが、インスタンスを変えるとうまくいくケースが多いです。
プルリクエストのレビュー依頼
これもチャット経由で依頼できます。

「今作成したPRをセルフレビューして」くらいのプロンプトでもgithub-mcp経由でPRを読み込んでレビューコメントを書き込んでくれます。
github関連ルールの設定ファイル化（任意）
何回も同じプロンプトでcursorに指示するのも面倒かと思うので

.cursorrulesなどにgithub関連のルールをまとめておくと良いでしょう。

いかにサンプルを記載しますが、これも私は一行も書いていません。チャットでやり取りする中で「今のやり取りで決まったことを.cursorrulesに残しておいて」等と指示するとこのくらいのものがアウトプットとして出てきます。
# GitHub操作に関するルール
- GitHub関連の操作はMCPクライアントを使用すること
- リポジトリ情報:
  - owner: xxxxxxxxxxxx
  - repository: xxxxxxxxxxx
- ブランチ操作:
  - 新機能追加時は `feat/` プレフィックスを使用
  - バグ修正時は `fix/` プレフィックスを使用
  - ドキュメント更新時は `docs/` プレフィックスを使用
  - 作業開始時の手順:
    1. mainブランチの最新化: `git checkout main && git pull origin main`
    2. 作業ブランチの作成: `git checkout -b {prefix}/{branch-name}`
- コミット手順:
  1. 変更内容の確認: `git status` で変更ファイルを確認
  2. 変更のステージング:
    - 全ての変更を追加: `git add .`
    - 特定のファイルのみ: `git add {file-path}`
  3. コミットメッセージの作成:
    - プレフィックス: feat:, fix:, docs: などを使用
    - 日本語で具体的な変更内容を記述
    - 例: `git commit -m "feat: ログイン機能の実装 - ユーザー認証とセッション管理の追加"`
- プッシュ手順:
  1. リモートの最新状態の確認: `git pull origin main --rebase`
  2. コンフリクトが発生した場合:
    - `git rebase --abort` で中止
    - mainブランチから再度作業ブランチを作成
  3. プッシュ: `git push origin {branch-name}`
- プルリクエスト:
  - タイトルは日本語で具体的な変更内容を記述
  - 変更内容の説明を必ず含める
  - レビュー後の修正がある場合は同じブランチにコミットを追加

 なぜレビューにgithub-mcp-serverを利用すると良いのか私があんまり有料ツール試していないので、比較検討があまりできず、偏った意見になっている可能性はございますが

大きく3つの理由が挙げられるかなと思います。

 1. コンテキスト保持コード生成とレビューが同一インスタンス内で行われるため、生成時のコンテキスト（要件、設計意図）をそのままレビューに引き継げる

 2. ルールベースの柔軟性.cursorrules や .clinerules を用いて「アクセシビリティ重視」や「テスト第一」など、レビューの方向性を細かく指定できる

 3. MCPサーバー間の連携GitHubだけでなく、Figma や JIRA といった他の MCP サーバーと組み合わせることで、「デザイン仕様に忠実か」「タスク管理と整合しているか」といった多角的レビューが実現できる
例えば、以下は実際にgithub-mcp-serverにレビューさせた文章の一部です。
Figmaのデザイン仕様に忠実に実装されていますというコメントがあり、デザイン仕様を照会していることが伺えます（figma-mcpの使い方は他にも参考記事が多くありますので、ここでは割愛）

 AIが書いたコードをAIにレビューさせる意義さて、冒頭に提示した「AIが書いたコードをAIがレビューするってあんま意味ないんじゃないの？」という問いについて

個人的な感想と致しましては、AIが書いたコードであってもAIレビューは必ず通すべきと考えています。

 1. 実装AIの盲点フォロー実装AIは指示に忠実にコードを生成します。

例えば、先ほど添付したレビューコメントを例にとると

「onSubmit が失敗した場合のエラーハンドリングを追加することで、より堅牢な実装になります」という指摘があります。

今回はサンプルアプリを作っていたので、要件を全く決めず、figmaのコンポーネントのみを見せて「これを実装して」という形で実装をお願いしていました。
今回のように、要件を決めずに投げるのは極端な例かとは存じますが、

要件決定時には見落としやすいエラーハンドリングの漏れなど、実装AIはこちらが指示しなければそこまで気にせず実装して完成としてしまいがちな部分があります。

このような実装AIの盲点（とニンゲンが作ったガバガバ要件）をフォローしてくれるのがレビューAIが持つ役割の大きな一面かなと思います。

 2. 俯瞰的観点の補完レビューAIは差分全体を俯瞰できるため、エラーハンドリングやテスト不足などを的確に指摘できます。

実装AIは部分最適的に動く傾向があります。

エラー解消などで何度も修正を依頼した場合、全体として乱れたコードが出力された。という経験をお持ちの方は多いかなと思います。

その部分をレビューAIは補ってくれます。

 まとめ繰り返しになりますが、AIが書いたコードであってもAIレビューは必要、というのが現時点での私の立場です。

「実装AI」→「レビューAI」という二段構えにすることで、AI単体よりも高精度・高品質な開発フローが構築できます。

勿論、最終的には人間によるチェックはまだまだ不可欠かとは存じますが、うまく活用して良いプロダクトを世に出していきましょう。
はじめに

手順(cursor&github-mcp-serverの場合)

設定

利用

なぜレビューにgithub-mcp-serverを利用すると良いのか

1. コンテキスト保持

2. ルールベースの柔軟性

3. MCPサーバー間の連携

AIが書いたコードをAIにレビューさせる意義

1. 実装AIの盲点フォロー

2. 俯瞰的観点の補完

まとめ

Discussion
