AIにお願いするコードレビュー


このたった数ヶ月で、わたしたちの世界は大きな大きな変化を迎えています。AI技術の台頭と普及で仕事の仕方が数ヶ月前まではまるで予想出来ていなかったレベルまで変性しました。インターネット黎明期以来のパラダイムシフトといっても大袈裟ではないと感じています。

Gaji-Labo でもAI活用を大きく推進させて、よりスピード感をもって、より大きな力を成果に結びつけられるように工夫を重ねています。

業務のさまざまな場面でAIとコラボレーションする事が増えてきた昨今ですが、特にAI活用のファーストステップとして効果的だと感じたのが、コードレビューです。この記事では、コードレビューをきっかけとしてAI技術のさらなる活用を想像していきたいと思います。

なぜコードレビューが効果的だと考えるか

AIの活用方法はいろいろあります。壁打ち相手になってもらったり、わからないことを質問したり、アイデアを集めるのに役立てたりなど、はやくも働く上でのパートナーとしての地位を確立しつつあります。

なかでも特に注目を集めているのが何かを生成すること、開発の文脈であればプログラムコードを書いてもらうことです。アプリケーション開発においては、すでに生成AIが自律的にコードを書く世界へとシフトしつつあります。

そういった創造的なアクティビティに比べると、コードレビューはいささか地味に思われるかもしれません。しかし、AIに何か思い通りのものを創造してもらうにあたり、コンテキストの整備やプロンプトの工夫など、AIを制御するためにある程度の慣熟を必要とします。

一方でコードレビューはとても小さなアクションで大きな成果が得られます。AI活用の第一歩として、クイックウィンであると言えるのではないでしょうか。

ニンゲンはセルフレビューが苦手である

それに加えて、ニンゲンがセルフレビューが苦手だということも理由のひとつです。

ニンゲンは客観的な視点を持つことが得意ではないです。自分自身はそれが正しいものとして書いていて、その記憶をコンテキストに残留させたままコードを読んでもバイアスがかかってミスに気付きづらいのです。

対してAIは完全な他者であって、コンテキスト単位でゼロベースで思考します。レビュー範囲を渡すだけで、簡単に客観的視点を手に入れることができるのです。

この記事の中では、AIにコードレビューを依頼した場合も「セルフレビュー」と呼びます。厳密にはAIにお願いしているのでセルフではないのですが、他メンバーにレビューを依頼する前段階のローカルな世界でのレビューなので、これはセルフレビューに分類したいと思います。

AIレビューのファーストステップ

はじめの一歩は、とても小さくて簡単なものが良いです。小さな粒度のコードレビューを軽い気持ちで依頼してみましょう。

作業中のブランチで、現在ステージにある差分に対してコードレビューを依頼します。これが最も簡単で下準備もいらず、最少の手間で最大の効果が得られるセルフレビューです。たとえエージェントがまったくカスタマイズされていなくても期待にこたえてくれます。

現在ステージされている変更に対してコードレビューをおこなってください。

これだけで、大抵のモデルはわたしたちが期待する通りの良い仕事をしてくれるでしょう。エージェントは git コマンドを使って現在のステージに乗っている差分を取得し、それに対してレビューをしてくれます。

ただ、時折彼らは差分の取得の仕方を知らない振りをしたり、さぼったりします。そんなときは git コマンドを使うように指摘しましょう。

差分の取得には git コマンドを使用してください。

AIはどんなレビューをしてくれるのか

AIのレビューの質は、当然AIが何を知っているかに依存するはずです。

AIは、プログラミング原則について知っています。コードの保守性を高めるための書き方を知っているし、Reactのパフォーマンス向上についての知見を持っています。そういった普遍的な視点からレビューをしてくれます。

  • プログラミング原則に則った実装がなされているか(複雑すぎないか、など)
  • メンテナビリティ・リーダビリティを損ねていないか
  • スペルミスがないか
  • 公式で推奨されている実装方法か

これらはほんの一例にすぎません。様々な角度の視点からレビューをし、多くの場合、改善案をセットで提示してくれます。

AIは何を知らないのか

AIはプロジェクトそのものについてはあまりよく知りません。知っているのはコードベースから知り得ることだけです。AIはプロジェクトの歴史や経緯、ドメイン知識や今後の計画を知りません。初期状態ではその視点からのレビューをしてくれません。

そういったコードベースの外の文脈についても考慮してほしければ、コーディングルールやディレクトリ構成、ドメイン知識や開発計画など、そのほか言語化可能なプロジェクトの情報をコンテキストとして渡してあげましょう。そうすることで、エージェントはさらに解像度の高いレビューをしてくれるようになるでしょう。

ただし、AIのために情報を整理して渡すことは手間です。ある程度のオーバーヘッドを覚悟しなければなりません。今この記事ではスモールでクイックなレビュープラクティスについて話をしているので、追加のコンテキストについてはあえて触れないことにします。

レビュー範囲をひろげてみる

ステージのコードレビューに慣れてきたら、レビュー範囲を広げてみましょう。次はプルリクエスト、すなわちブランチの変更に対してコードレビューを依頼します。AIレビューのセカンドステップです。

ブランチの差分を取得する

まず、ブランチをリモートにプッシュして、いつものようにプルリクエストを建てましょう。

それから変更の差分を取得する必要がありますが、エージェントにブランチの差分を取得させようとすると、git コマンドを駆使して頑張り始めるかもしれません。それは正しい行動ではあるのですが、GitHub MCP サーバーを活用した方がきっと効率的です。GitHub MCP サーバーを使うことで、GitHub のプルリクエストページにある Files Changed と同じ情報を直接取得することができます。

現在のブランチの差分に対してコードレビューをおこなってください。
差分の取得には GitHub MCP の get_pull_request_files を使用してください。

このようにAIにお願いすると、次のような順序で処理をしていきます。

  1. git status で現在のブランチを取得
  2. GitHub MCP の list_pull_request などでプルリクエストの情報を取得
  3. GitHub MCP の get_pull_request_files で差分を取得
  4. 取得した差分に対してコードレビューをおこなう

エージェントにブランチ差分のようにある程度のサイズのコードレビューを依頼すると、まずそのブランチがどのような機能を実装しようとしているのかを解析してくれます。そしてブランチの内容を俯瞰してレビューをしてくれます。

例えばこんな感じに項目立てしてコメントをくれるかもしれません :

  • 実装概要(差分から推論した実装機能の概要)
  • 良かったポイント
  • 良くないポイントと改善案

もちろん、ルール設定などをしていなければ書式や項目に再現性はないですが、適切な粒度のコードレビューを依頼すると、想像以上に解像度の高い結果を返してくれました。

気をつけたいポイントは、「適切な粒度」という基準が定量的でないことです。それはモデルの性能によるもので、当然性能は時を経てどんどん向上していくものです。その閾値を超えた粒度で情報を渡した場合、AIは期待された性能を発揮できないかもしれません。ニンゲンと同様に、AIでも大きすぎる差分をレビューするのはつらいということですね。

MCPが使えないケース

なんらかの事情で GitHub MCP サーバーが使用できない場合は、 git コマンドを駆使して差分を取得する必要があります。

例えばこのように :

  1. git merge-base でベースブランチからの分岐点を取得する
  2. git diff でその分岐点からの差分を取得する

この手順をAIに踏んでもらう必要がありますが、その時AIはベースブランチを知りたがるでしょう。(ブランチ自体にはベースブランチの情報は記録されていません)ベースブランチをAIに探ってもらう手もありますが、やや冗長なコマンドを実行させることになり、しかも精度は完全ではありません。ですから、はじめにニンゲンから情報を渡してあげる方がより安全かつ効率的だと考えます。

現在のブランチと master との差分に対してコードレビューをおこなってください

ただし、このケースに限らずAIにコマンドを実行させることは出来るだけ減らすべきだと考えています。(この考えはじきに古くなるかもしれませんが)

理由としては、彼らが破壊的なコマンドを実行しないと言い切れるほど、まだわたしたちの間では信頼関係が成熟していないからです。「実行前に承認を求めるルールにすれば良い」という考えがあるかもしれません。しかし、危険なコマンドを見過ごしてうっかり手を滑らして承認してしまわないと断言できるほど、わたしたちは自分たちを信用していません。

必ずしもAIに全て任せることが効率的・効果的とは限らないということ、そして、渡す情報によってAIの動きは大きく変化するということを肝に銘じておきたいです。

おわりに

この記事では、AI活用のファーストステップとしてコードレビューを提案しました。

次のステップでは役割を逆転させて、AIにコードを書かせてニンゲンがレビューをするという、多くの人が頭に思い描くAI活用へのチャレンジになると思います。AIがコードを書くのだからニンゲンが考えることは減るだろうと考えるかもしれませんが、そういうわけでもないということにすぐに気づくことになるでしょう。

今後、関わる場面がどんどん増えていくAIという新しいパートナーとうまく協働できるように、AIが生み出す成果を最大化できるように、コミュニケーションの術を磨いていきたいですね。

Gaji-Labo は Next.js, React, TypeScript 開発の実績と知見があります

フロントエンド開発の専門家である私たちが御社の開発チームに入ることで、バックエンドも含めた全体の開発効率が上がります。

「既存のサイトを Next.js に移行したい」
「人手が足りず信頼できるエンジニアを探している」
「自分たちで手を付けてみたがいまいち上手くいかない」

フロントエンド開発に関わるお困りごとがあれば、まずは一度お気軽に Gaji-Labo にご相談ください。

オンラインでのヒアリングとフルリモートでのプロセス支援にも対応しています。

Next.js, React, TypeScript の相談をする!

Gaji-Labo Culture Deck

Gaji-Labo は Next.js, React, TypeScript 開発の実績と知見があります

フロントエンド開発の専門家である私たちが御社の開発チームに入ることで、バックエンドも含めた全体の開発効率が上がります。

「既存のサイトを Next.js に移行したい」
「人手が足りず信頼できるエンジニアを探している」
「自分たちで手を付けてみたがいまいち上手くいかない」

フロントエンド開発に関わるお困りごとがあれば、まずは一度お気軽に Gaji-Labo にご相談ください。

オンラインでのヒアリングとフルリモートでのプロセス支援にも対応しています。

Next.js, React, TypeScript の相談をする!

投稿者 Oikawa Hisashi

フロントエンドエンジニア。モダンなJavaScript開発に関心があります。 デザインからバックエンドまで網羅的にこなすマルチデザイナーとして長く活動してきた経験を活かして、これから関わる様々なものをデザインしていきたいです。チームもコミュニケーションもデザインするもの。ライフワークはピアノと水泳。