AIによるコード生成が普及しました。
しかし、多くのエンジニアが気づいていない問題があります。
ClaudeやChatGPTが生成するコードは、一見すると完璧に見えます。
動きます。
テストも通ります。
ところが、本番環境にデプロイした途端に問題が発覚する。
そんな経験をした人は少なくないでしょう。
本記事では、海外のRedditコミュニティで話題になったテクニックを紹介します。
シンプルなプロンプトの工夫で、見落としがちなバグやエッジケースを浮き彫りにできるのです。
「見た目は正しい」と「本当に正しい」の差
AIにコードを書かせると、多くの場合、すぐに動くものが出てきます。
構文エラーもなく、主要な機能は期待通りに動作する。
そのため、そのままマージしてしまいがちです。
ところが、Redditのあるユーザーが興味深い発見をしました。
AIが生成したコードを、同じAIに「批判的な立場で」レビューさせる。
すると、驚くほど多くの問題点が浮かび上がってくるというのです。
彼が使ったプロンプトは非常にシンプルでした。
git diffを確認して、このコードを嫌っているシニア開発者のふりをしてコードレビューしてください。 何を批判しますか？ どんなエッジケースを見落としていますか？
結果は衝撃的だったようです。
「最初のパスで生成されたコードには、マージするのが恥ずかしいレベルの問題が含まれていた」と彼は報告しています。
見逃されていたエッジケース、微妙なバグ、その他諸々。
次々と明らかになったのです。
なぜ敵対的プロンプトが効くのか
通常、AIにコードレビューを依頼すると、比較的穏当なフィードバックが返ってきます。
「このコードは概ね良好です。いくつか改善点を挙げると…」といった具合です。
しかし、「このコードを嫌っている」という設定を加えると、AIの振る舞いが変わります。
普段なら見逃すような細かい問題点まで、徹底的に指摘するようになるのです。
ある開発者はこう表現しました。
友好的なモードではロジックエラーや明らかなエッジケースを見つける。 敵対的なモードでは、アーキテクチャ上の問題点が見えてくる。 気づかなかった密結合、欠けている抽象化、どこにも繋がっていないエラーパスなど
この違いは重要です。
同じコードでも、レビューする「姿勢」によって発見できる問題の種類が異なるのです。
実践的な使い方と注意点
このテクニックを使う際には、いくつかの注意点があります。
まず、レビューの回数についてです。
多くのユーザーの経験によると、2〜3回のレビューで本当に重要な問題のほとんどを捕捉できます。
それ以上繰り返すと、実用性のない仮説的な問題を指摘し始めます。
「ユーザーがデータベースのトランザクション中に日食が起きている最中に負の数を入力したらどうなるか」といった具合に。
次に、トークン消費の問題があります。
複数回のレビューを行うと、当然ながら大量のトークンを消費します。
APIの利用料金が気になる場合は、重要な機能のコードに絞って適用するのが賢明でしょう。
さらに、AIが指摘した内容をそのまま鵜呑みにしない姿勢も大切です。
経験豊富なエンジニアであれば、本当に修正すべき問題と過剰な心配を区別できます。
この判断力は人間側に求められるスキルです。
より高度なアプローチ
Redditのスレッドでは、さらに発展的な手法も議論されていました。
一つは、複数のAIモデルを組み合わせる方法です。
コードを書いたモデルとは別のモデルにレビューさせる。
そうすることで、より客観的な視点を得られます。
Claudeで書いてCodexでレビューする。
そんな組み合わせを試している開発者もいました。
もう一つは、レビュー用のペルソナを工夫する方法です。
「Linus Torvaldsのつもりでレビューして」と指示すると、厳しいながらも的確なフィードバックが得られるという報告もありました。
他にも「仕事を失いたくないスタッフエンジニア」というペルソナで効果を上げている人もいます。
また、Anthropicが公式に提供しているcode-reviewプラグインについても言及がありました。
このプラグインでは、5つのエージェントが並列でコードレビューを行います。
その結果をさらに別のエージェントが評価して、重要度の高い問題だけをフィルタリングする仕組みです。
人間のスキル開発への影響
興味深い議論として、若手エンジニアのスキル開発への影響も指摘されていました。
AIにすべてを任せていたら、次世代のシニアエンジニアは育たない
この懸念は、ある程度もっともです。
自分でコードを批判的に読み、問題点を見つける能力。
これはエンジニアとして成長する上で欠かせないスキルだからです。
一方で、別の意見もあります。
「AIのレビュー結果を読むことで学習できる。人間のレビュアーから学ぶのと同じだ」という考え方です。
AIが指摘した問題点を理解し、なぜそれが問題なのかを考える。
そうすることで、自分自身の批判的思考力も磨かれるという見方です。
結局のところ、AIをツールとして賢く使いつつ、自分自身の能力向上も怠らない。
そのバランスが求められるのでしょう。
同じAIが書いて同じAIがレビューする矛盾
根本的な疑問を呈する人もいました。
欠陥のあるコードを書いたのと同じ確率的知性が、同様に欠陥のあるレビューを行うのではないか
目の見えない人が目の見えない人を案内するようなものではないか、と。
この懸念には一理あります。
しかし、実際に試してみると、コードを「書くモード」とコードを「批判するモード」では、AIの挙動が明らかに異なります。
書く際には最短経路で動くコードを目指す。
批判する際には意図的に粗探しをする。
このモードの切り替えが、異なる結果を生むのです。
もちろん、AIによるレビューが完璧というわけではありません。
最終的な判断は人間が行うべきです。
静的解析ツールやテストなど、他の品質保証手法と組み合わせて使うのが理想的でしょう。
まとめ
AIが生成したコードを、同じAIに敵対的な立場でレビューさせる。
このシンプルなテクニックが、コード品質の向上に大きく貢献する可能性があります。
ポイントを整理します。
- 「このコードを嫌っているシニア開発者」というペルソナを設定する
- 通常のレビューでは見逃す問題を発見できるようになる
- レビューは2〜3回が目安で、それ以上は過剰な指摘が増える
- AIの指摘を鵜呑みにせず、本当に修正すべき問題を見極める判断力が必要
「見た目は正しい」コードと「本当に正しい」コードの間には、思った以上の差があります。
AIという強力なツールを使いこなすには、その限界も理解した上で、適切に活用する知恵が求められます。
敵対的プロンプトによるコードレビュー。
一度試してみると、AIに対する信頼の仕方が変わるかもしれません。
