AIがプログラム（コード）を書く場面が増え、そのコードの点検（コードレビュー）にもAIを使う会社が出てきました。ただ、AIのレビューは、指摘が多く出るぶん、どれが本当でどれが思い違いかを見分ける手間がかかります。指摘をそのまま信じて直すと、かえって新しい不具合を生むこともあります。この記事では、当社の開発で使っているAIのコードレビューの進め方、つまり観点の違う4つのレビュー役、重大な指摘を確かめる別の役、直したあとのテストの確かめ方を、つまずいた所とあわせて紹介します。外に開発を頼むときに、相手の点検の進め方を聞く材料にもなるはずです。
AIの書くコードは「ほぼ合っている」のが厄介
AIの出すものは、明らかに間違っているより「ほぼ合っている」ことのほうが多く、そこに手間がかかります。プログラマー向けの質問サイトStack Overflowが2025年に行った開発者調査では、開発でAIの出すものの正確さをどれくらい信頼しているかという問い（回答33,244件）に対し、「とても信頼している」は3.1%、「ある程度信頼している」は29.6%でした。「やや信頼していない」は26.1%、「まったく信頼していない」は19.6%です[1]。同じ調査で、AIを使っていて困ったことを複数選ぶ問い（回答31,476件）では、「ほぼ正しいが、少し違う答え」が66%で最も多く挙がっています[1]。
点検する側にAIを使っても、事情は同じです。GitHubの公式ドキュメントは、自社のAIによるコードレビュー機能について、すべての問題を見つけられるとは限らず、間違えることもあると書いたうえで、AIの指摘は必ず注意深く確かめ、人のレビューで補うよう求めています[2]。
つまり、AIのレビューを入れるときに考えるべきなのは、「どのAIを使うか」より、「AIの指摘をどう確かめるか」です。
🛠 この記事のようなプロダクト開発の課題は、ご相談ください。何をつくるかの整理から、開発、反応を見た手直しまで一緒に進めます（相談は無料）。
Overview
当社の進め方：観点の違う4つのレビュー役
当社の開発では、AIが書いたコードを、4つのAIのレビュー役が同時に点検します。観点は次の4つです。
- セキュリティ
- データ
- ロジック（処理の正しさ）
- 既存の機能への影響
それぞれの観点で一般的に見る中身は、次のとおりです。
| 観点 | 一般的に見ること | 見落とすと起こりうること |
|---|---|---|
| セキュリティ | ログインや権限の確かめ、外から入ってくる値の扱い | 見てはいけない人がデータを見られる、何度でもログインを試せる |
| データ | 保存の形、消す・書き換えるときの扱い、日付や時刻 | 記録が消える、二重に登録される、日付がずれる |
| ロジック（処理の正しさ） | 条件分け、境目の値、失敗したときの動き | 特定の条件のときだけ計算や判定を間違える |
| 既存の機能への影響 | 今回の変更が、ほかの画面や処理を壊していないか | 直した所とは別の所が動かなくなる |
一般に、1つのレビューに全部を見させると、目立つ問題に引っぱられて、ほかの観点が手薄になりやすいと言われます。これは人のレビューでも同じです。観点を分けておけば、それぞれの役が自分の観点だけに集中できます。
そして当社では、レビューは人が始め、結果を見て直すかどうかを人が決めます。人が関わるのは、レビューを始めることと、確かめた結果を見て直すかを決めることの2か所です。
Verify
重大な指摘は、別のAIが1件ずつ確かめる
当社では、レビュー役から「重大」と報告された指摘を、レビュー役とは別のAIが1件ずつ実際のコードで確かめます。判定は、「本当」「格下げ」「却下」のどれかです。
確かめ役のAIには、指摘の中身と実際のコードだけが渡り、だれが報告したかやほかの指摘の数は渡らない形にしています。一般に、「どの担当が言ったか」「ほかにいくつ問題が出ているか」といった情報は、中身と関係なく判断をゆがめることがあります。
どの指摘を「重大」とするかの線引きも、先に決めておくと迷いません。一般的には、見てはいけない人がデータを見られる、記録が消える、お金や請求の計算を間違える、といった「起きたら取り返しにくいこと」が重大に当たります。見た目や書き方の好みに近い指摘は、急いで直す対象から外しておくと、確かめる手間を重大なものに集められます。
一般に、「見つける」仕事と「本当かを決める」仕事を分けておくと、見つける側は多めに挙げても困りません。直す前に、別の目で本当かどうかを確かめる段があるからです。
Test
直したら「戻すと失敗する」テストで確かめる
当社では、指摘を受けて直したら、その不具合を再現するテスト（自動で動きを確かめるプログラム）を足します。そして、「修正を一時的に元に戻すと、テストが失敗する」ことを実際に確かめます。失敗しないテストは意味がないためです。
テストは、書いただけでは何も確かめていないことがあります。たとえば、直す前のコードでも通ってしまうテストは、不具合が戻ってきても気づけません。修正を戻して失敗することを一度見ておけば、そのテストが本当にその不具合を見張っていると分かります。
例を挙げます。「確認の数字を決まった回数まちがえたら、しばらく試せなくする」という修正をしたとします。テストは「決まった回数まちがえたあと、正しい数字を入れても入れない」ことを確かめるものになります。ここで修正を一時的に外すと、まちがえたあとでも入れてしまうので、テストは失敗するはずです。もし外しても通るなら、そのテストは別のことを確かめているか、何も確かめていません。この一手間で、「テストを足しました」という報告が本物かどうかが分かります。
AIを使った開発でも、点検とテストの段取りまで含めて進めます。開発の進め方を確かめたい段階からご相談ください。
無料で相談するCase
2段階認証のレビューで起きたこと
当社が、ある開発で2段階認証（パスワードのほかに、もう一つの確かめを求める仕組み）のレビューをしたときの記録です。重大な指摘4件をすべて確かめてその場で直し、足したテスト11件は全部「戻すと失敗する」ことを確かめました。
ところが、その修正そのものが、新しい重大な不具合を1件生んでいました。一定時間たつと、何回でも試せてしまう、というものです。直した箇所に絞ってもう一度レビューを回したことで見つかりました。
ログインの試行回数を抑えることは、認証の基本的な守りの一つです。ウェブの安全性の国際的な指針であるOWASP Top 10の2025年版は、総当たりなどの自動化された攻撃をすぐに止められない状態を認証の弱点の例に挙げ、失敗したログインの回数を制限するか、だんだん待ち時間を長くするよう勧めています[3]。米国国立標準技術研究所（NIST）の認証の指針SP 800-63Bも、1つのアカウントで続けて失敗できる回数を100回以下に制限するよう定めています[4]。
この記録から言えるのは、修正もまた新しいコードだということです。一度レビューを通ったからといって、直した所が安全とは限りません。直した所に絞ってもう一度点検する段取りを入れておくと、こうした「直したことで生まれた不具合」を拾えます。
Lessons
つまずいた所：指摘の「事実」を確かめずに直した
当社では、レビューが挙げた「事実」を確かめずに直し、使われないコードと、何も確かめていないテストが残ったことがあります。そこで、指摘は鵜呑みにせず確かめる決まりにしました。
AIのレビューは、「この関数はここから呼ばれている」「この値は空になることがある」といった前提を、もっともらしく書きます。その前提が違っていれば、直したコードは使われず、足したテストは何も見張っていないことになります。見た目は「指摘に対応済み」でも、中身は増えたコードだけが残ります。
確かめ役による判定、戻すと失敗するテスト、直した所に絞った再レビューは、どれも「確かめずに直す」ことへの歯止めとして働きます。
Human
人が決めること：どこで「通す」か
AIのレビューを入れても、最後に決めるのは人です。当社でも、レビューは人が始め、結果を見て直すかどうかを人が決めます。
何をもって「通す」とするかは、人が持つ物差しです。Googleが公開しているコードレビューの指針は、変更が完璧でなくても、システム全体のコードの健全さを確実に良くする状態になっていれば、レビューする人は承認する方向で考えるべきだ、としています[5]。AIは、細かい指摘をいくらでも挙げられます。その全部に応えようとすると、いつまでも終わりません。一般には、重大なものを確かめて直し、細かいものは次に回す、という判断を人がします。
レビューのやり方を比べると、次のようになります。
| レビューのやり方 | よい所 | 気をつける所 |
|---|---|---|
| 人だけで見る | 業務の事情や設計の意図まで分かったうえで判断できる | 量が多いと見る時間が足りず、観点が偏りやすい |
| AIのレビューを1つ使う | 手早く、たくさんの指摘が出る | 思い違いの指摘も混ざる。全部を信じて直すと新しい不具合を生むことがある |
| 観点を分けた複数のAI＋確かめ役＋人（当社の進め方） | 観点ごとに点検でき、重大な指摘は直す前に確かめられる | 段取りが増える。最後の判断と、通す物差しは人が持つ必要がある |
| 開発会社に任せる | 点検とテストの段取りごと任せられる | 相手がどう点検しているかを、頼む前に聞いておく必要がある |
Checklist
外に開発を頼むときに聞いておきたい5つのこと
エンジニアでなくても、次の5つを開発会社に聞けば、点検の進め方の様子が分かります。
- AIが書いたコードを、だれが、どの観点で点検していますか。
- AIのレビューの指摘が本当かどうかを、どう確かめていますか。
- 直したとき、そのテストが本当に効いていることをどう確かめていますか。
- 直した所を、もう一度点検していますか。
- 直すかどうか、通すかどうかは、だれが決めていますか。
答えが「AIがやっています」だけなら、もう一歩聞いてみてください。確かめる段取りと、決める人がはっきりしているかどうかが見るべき所です。
Sources
参考にした資料
- Stack Overflow「2025 Developer Survey」AIの章（2025年）
- GitHub Docs「About GitHub Copilot code review」
- OWASP Foundation「OWASP Top 10:2025 A07 Authentication Failures」（2025年）
- 米国国立標準技術研究所（NIST）「SP 800-63B Authentication and Authenticator Management」（2025年8月）
- Google「Engineering Practices: The Standard of Code Review」
FAQ
AIのコードレビューについてよくある質問
AIのコードレビューだけで、人のレビューは要らなくなりますか？
要らなくはなりません。GitHubの公式ドキュメントも、AIのレビューは間違えることがあるとして、人のレビューで補うよう求めています。当社でも、レビューは人が始め、直すかどうかは人が決めています。
なぜレビュー役を4つに分けるのですか？
セキュリティ、データ、ロジック（処理の正しさ）、既存の機能への影響と観点を分けておくと、1つのレビューで目立つ問題に引っぱられて、ほかの観点が手薄になるのを防ぎやすくなります。
「戻すと失敗するテスト」とは何ですか？
不具合を直したあと、その修正を一時的に元に戻すと失敗するテストのことです。戻しても通ってしまうテストは、その不具合を見張れていません。当社では、戻すと失敗することを実際に確かめています。
エンジニアでなくても、開発会社の点検の進め方を見分けられますか？
上のチェックリストの5つを聞いてみてください。指摘の確かめ方、テストの確かめ方、決める人がはっきり答えられるかどうかで、様子が分かります。
AIのコードレビューは、指摘を出す力が強いぶん、その指摘を確かめる段取りが欠かせません。観点を分けて点検し、重大な指摘は別の目で確かめ、直したら戻すと失敗するテストで確かめ、直した所をもう一度見る。そして、始めることと決めることは人が持つ。当社では、AIを使ったプロダクトの開発を、こうした点検の段取りを含めて進め、開発後の運用保守や機能の追加まで続けてご相談いただけます。
