この記事は 食べログアドベントカレンダー2025 の5日目の記事です🎅🎄
はじめに
こんにちは。食べログでWebエンジニアをしている@xi10onです。
主に、他社とのシステム連携や広告系の業務を中心に扱っています。
当社では、AIを活用したサービス開発が主流となっています。
この変化に伴い、コードレビューで指摘する内容も大きく変わりました。
技術的な指摘が減った今、コードレビューを単なる品質確認の場として終わらせるのではなく、ナレッジを蓄積し、チームおよび個人の能力を向上させるための貴重な機会として捉え直すことが、今後さらに重要になると考えています。
本記事では、このような観点からコードレビューを実践するために、最近意識していることや、考え方を変えたことについて紹介します。
同じような状況変化に直面している方々にとって、何かしらのヒントやインスピレーションを提供できれば幸いです。
コードレビューの指摘が最近減っている
AIツールを活用したコーディングが主流になるにつれ、コードレビューでの技術的な指摘が大幅に減りました。
AIを活用したサービス開発では、従来のコーディング手法と比べて、エラーやパフォーマンスの問題が少なくなっています。
これは、AIがプログラマーとしての役割を担い、人間がコードレビューする側の役割を担うという、新しい分担が生まれているためです。
コードレビューを依頼する段階で、すでに一次的なコードレビューが行われている状態なので、技術的に問題があるものが出されにくくなっています。
この変化は、単にレビューの負担が減ったというだけでなく、コードレビューの時間をより価値のある活動に使えるようになったという考え方もできます。
技術的な指摘に時間を割かなくなった分、チームのナレッジを蓄積し、個人のスキルを向上させる機会とすることができるようになりました。
この変化を受けて、私たちはレビューにおいて何を重視すべきなのかを考えています。
AI時代のコードレビューで意識すべき2つのシフト
コードそのものに対するレビューから、以下の2点にシフトする必要があると考えています。
- 『生成されたコード』だけでなく『プロンプト』のレビュー
- 実装意図と背景の明確化
それぞれについて、レビューを依頼する側と実施する側それぞれの立場で意識すべきと考えていることを整理してみます。
『生成されたコード』だけでなく『プロンプト』のレビュー
AIとGitHub上で対話/指示をしている場合のように、レビュアーもプロンプトを見ることができる状態の場合、プロンプトをレビューするのが効果的ではないかと考えます。
レビューを依頼する側としては、可能であればプロンプトを公開できる環境で作業することで、レビュアーがプロンプトの品質を確認できるようにすることが重要です。
一方、レビューを実施する側としては、コードだけでなくプロンプトやAIとの対話履歴も確認し、より良いプロンプトの書き方や対話の進め方についてフィードバックを提供することが効果的です。
AIとのやりとりそのものをレビューすることで、AIとの対話スキルの向上・生成コード品質の向上・再現性の向上を目指せます。
例えばAIが意図とは異なるコードを生成し何度も修正した際や、関係ないコードに対して変更をしてしまった等見直せるシーンは数多くあります。このような事象の発生を防ぐだけでも、業務の効率の改善/質の向上に結びつくでしょう。
また、改善のやり取りを元のプロンプトと合わせて残すことにより、レビューを受けた当人だけでなく、チームとしてのナレッジの積み重ねにもなります。
実装意図と背景の明確化
当たり前のことですが、なぜその実装方法を選んだのか、どのような意図でそのコードを書いたのかが分からないと、後からコードを読んだ人に不親切です。
特定のビジネスロジックに依存する処理をAIで生成した場合において、意図や注意点などをコメントで残す意識が希薄になりがちな傾向があると感じているため、今後の改修のためにもきちんと意図を示しておくことが大切かと思います。
レビューを依頼する側としては、AIで生成したコードであっても、ビジネスロジックや設計判断が含まれる部分については、その意図や背景を説明できるようにしておくことが求められます。
レビューを実施する側としては、コードだけを見て判断せず、「なぜこの実装方法を選んだのか」「この処理の意図は何か」といった点を積極的に質問し、不明瞭な部分を明確化する役割を担うことが重要です。
レビュー時に意識する具体的な方法として、「自分がこのコードの改修を依頼された」と想定し、その際に引っ掛かりを感じる点を質問するようにするのが良い形かと思います。
指摘のあった内容に関しては、大事なことであればコード内のコメントに残し、重要性の低いものであればGitHub上でのレビューのコメントやりとりとして残しておくだけで十分でしょう。とにかく文字の媒体として情報を残しておくようにしましょう。
ツールの選択
ここで、取り違えたくないのはツール選定の際にレビューのことを過度に重視する必要はないということです。
先述の通り、プロンプトの改善をレビューでしたい場合、例えばDevinやClaude CodeのGitHub Actionのように、GitHubのようなオープンな場でAIとのやり取りを行うことが有効です。
これにより過去のプロンプトや対話を参照しやすくなり、チーム全体でナレッジを共有でき、後から学びやすい環境が整います。
一方で、エディター上で対話するツールの場合、他人からAIとのやりとりを見ることができないため、プロンプトレビューやナレッジの共有という観点では不向きです。
しかし、大規模な機能追加や複雑な設計などの場合は、エディター上での対話で細部を詰めながら作業する方が効率的な場合もあるでしょう。
レビューのためにツールを選ぶのではなく、効率的に作業可能なツールを選定した上で、その作業形態に合わせてレビューの観点を変えるべきです。
その前提の上で、どちらのやり方でも取り組めそうな場合に、プロンプト改善やナレッジの集積を目的にGitHub上でやりとりをするツールを選択する価値はあると思います。
まとめ
AIを活用したサービス開発が主流になった今、コードレビューの焦点は技術的な指摘から、プロンプトの品質向上と意図の明確化にシフトする必要があります。
実際にこのような観点でレビューを試してみたところ、まだ試行数は十分ではないためナレッジの積み重ねとまでは至っていないものの、プロンプトの品質や対話の進め方について考える機会が増えている実感があります。
また、実装意図を明確にするための質問を増やすことで、コードの背景や判断理由が可視化され、後からコードを読む際の理解が深まっていると感じています。
こうした取り組みを続けることで、チーム全体でナレッジが蓄積され、個人のスキルが向上し、組織としての学習サイクルが回り始めるという長期的な価値が生まれると考えています。
コードレビューはチームの能力向上を支援する貴重な機会なので、コードの品質を確認するだけでなく、ナレッジの蓄積とチーム及び個人の成長のための時間にしていくことが今後さらに大事になっていくのではないでしょうか。
ここまで読んでいただきありがとうございます！
明日は SREチームの浅野さん@atponsの「入社3ヶ月で見えた、食べログSREの大規模インフラ改善の最前線」です。お楽しみに!
食べログでは、20年の歴史を未来へ繋いでいく仲間を募集しています！
ご興味のある方は、ぜひこちらもチェックしてみてください。
