ある開発者が、AIにコードを読ませる抽象的なレビューより、実行による確認や形式検証を重視したいとXに投稿した。コードを読んで指摘を重ねるAIレビューについて、自身の経験から費用対効果に疑問を示している。

たしかAGIラボで紹介されていた話だったと思う。気になって見てみたけれど、私にはなかなか難しかった。

私はコードの読み書きができない素人エンジニアだ。AI（Artificial Intelligence、人工知能）に助けてもらいながら開発しているが、出来上がったコードを読んで、自分で正しさを判断することはできない。別のAIに確認してもらうことに頼りたくなる。

その確認にも、間違いや見逃しがある。頼っていたレビューがうまく働かないこともあると知って、結構、衝撃だった。

考えてみれば、作るAIが間違えるなら、確認するAIも間違える。当たり前かもしれない。でも、自分では代わりに見抜けない。それならどうすればいいのか。非常に困ったな、と思った。

投稿が疑問を向けたのは、実行せずに重ねるAIの批評だった

コードレビューは、作られたプログラムの中身を見て、問題や改善点を探すこと。AIに作らせたものを別のAIに読ませることも、その一つだ。

元の投稿者が問題にしていたのは、AIにコードを読ませて指摘を重ねる一方で、実際に動かしたり、決められた基準で確かめたりしないレビューだった。細かな指摘に時間や、AIが文章などを処理する単位である「トークン」を使い続けるより、動作確認や形式検証に使いたい、という意見だ。

これは投稿者自身の開発経験にもとづく判断だ。人間を含めたあらゆるコードレビューが無駄だと証明した研究結果ではない。元の投稿の範囲を、そこまで広げて受け取らないようにしたい。

「テストがなければ無価値？」とAIに聞いてみた

読んだだけではよく分からなかったので、AIに説明してもらい、自分の理解を言葉にして何度か確かめた。

途中では、テストを伴わないコードレビューは無価値で、場合によってはマイナスなのか、と聞いている。頼っていたものに限界があると知って、今度は全部だめなのか、と考えかけた。

調べた資料には、正しい実装に対してAIが誤った指摘をするという研究［1］があった。一方、AIレビューが実際の欠陥を見つける例も報告されている［2］。

前者は特定のモデルと課題を使った研究で、後者は査読前の論文だ。二つだけで、あらゆるAIレビューの価値や私自身の開発での効果は決まらない。それでも、私には大事な整理ができた。

レビューには、問題を見つける価値がある。同時に、間違った指摘も、見逃しもあり得る。 だから指摘をそのまま正解と思い込まず、できるだけ確かめたい。

レビューの「問題かも」を、動かして確かめる

例えば、メモを保存するアプリを作るとする。これは説明のための架空例で、私が実際に発見した不具合ではない。

AIによるコードレビューは、保存処理を読んで「ここで文章が消えるかもしれない」と問題の手がかりを探す。実行テストは、メモを書き、保存し、画面を閉じてもう一度開き、書いた文章が残っているかを確かめる。

「保存ボタンが表示された」「押しても落ちなかった」だけでは、文章を後から読めるかは分からない。レビューが見つけた懸念から試す条件を増やすことも、テストで失敗した原因をコードに戻って探すこともできる。

これから大事にしたい確かめ方
  1. 目的を決める

    どの操作のあと、どうなれば成功かを先に言葉にする。

  2. 動かす

    通常の操作と失敗しそうな条件を試す。レビューの懸念も検証へ。

  3. 結果を見る

    期待と実際を比べ、未確認の範囲も知る。自分でも使ってみる。

  4. 直して再確認

    問題があれば修正し、同じ条件と必要な関連テストを再実行する。

この違いを聞いて、私は、目的の機能が実際に動くかをもっと大事にしたいと思った。レビューを組み合わせながら、実行テストを品質評価の中心に置きたい。 これは今回の私の判断で、どんな開発にも同じ割合の検証が最適だと分かったわけではない。

テストに合格しても、目的を確かめたとは限らない

もう一つ、AIに教わって気になったことがある。テストを重視しても、何を合格にするかが間違っていれば、欲しかったものができたとは言えない。

例えば「ボタンを押しても落ちなかった」を合格条件にしたら、メモが消えていても、そのテストは通るかもしれない。実装とテストを作るAIが、同じ勘違いをすることも考えられる。別のAIに確認してもらう方法もあるが、別のAIなら自動的に正解になるわけではない。

だから、最初に何をしたいのか、どの操作のあとに何が起きれば成功なのかを伝える。失敗したときに、合格するよう条件を勝手に緩めるのではなく、何が起きたかを説明してもらう。

まずは「期待した結果と実際」をAIに示してもらう

今回の学びを、これからの依頼に入れてみたい。下の［ ］を、自分が作っている機能に置き換える。

目的：［利用者ができるようにしたいこと］
成功条件：［どの操作のあと、どうなれば成功か］

コードレビューに加えて、可能な範囲で実行テストをしてください。
通常の操作と失敗しそうな条件について、
期待した結果と実際の結果を対応させて示してください。
実行できなかった確認と、未確認の範囲も教えてください。
指摘は、再現した不具合・未確認の懸念・任意の改善案に分けてください。
問題を直したら再テストしてください。
成功条件を変更する必要があるときは、理由を説明して私に確認してください。

これは、これから試したい依頼例だ。この方法で品質が上がったり、時間が減ったりしたと、私自身が実証したわけではない。

結果を見るときは「何を試し、何を期待し、実際にどうなったか」を知りたい。そして、自分でも完成品を使って、やりたかったことができるかを確かめる。

ファイル削除、機密情報、認証や決済のような重大な処理では、一度普通に動くだけでは足りない。権限の制限や隔離した環境での検証など、追加の対策も考える必要がある。

元の投稿にあった形式検証は、守りたいルールを数学的なモデルなどで確かめる方法だと教わった。詳しい仕組みは私にはまだ難しい。モデルの条件と現実が合っているかという限界も含め、これから理解したい。AWSの形式手法の活用報告［3］

全部分かったわけではない。それでも読んでよかった

今回調べても、コードレビューや品質保証のすべてが分かったわけではない。技術的な判断を自分でできるようになったわけでもない。

それでも、「別のAIが問題ないと言った」から一歩進んで、実際に動かした証拠を見る。 レビューの価値は残しつつ、テストをもっと大事にしよう。その考えを持てたことが、今回の収穫だった。

自分には難しい話だったけれど、読んでよかったと思っている。

参考文献

  1. Jin, Haolin; Chen, Huaming. “Are LLMs reliable code reviewers? systematic overcorrection in requirement conformance judgement.” Automated Software Engineering, 33, article 90, 2026. DOI: 10.1007/s10515-026-00638-5
  2. Pereira, Kristen; Sinha, Neelabh; Ghosh, Rajat; Dutta, Debojyoti. “CR-Bench-v2: Evaluating the Real-World Utility of AI Code Review Agents.” arXiv:2611.02566v2, 2026. プレプリント（査読前）。論文
  3. Newcombe, Chris; Rath, Tim; Zhang, Fan; Munteanu, Bogdan; Brooker, Marc; Deardeuff, Michael. “How Amazon Web Services uses formal methods.” Communications of the ACM, 58(4), 66–73, 2015. DOI: 10.1145/2699417