AIコーディングツールを使う際、皆さんはどのように品質を担保していますか？

私は「壊れたときの被害」でレビューの強度を分けています。認証・認可、課金、データの更新/削除は1行ずつ精読し、スタイリングや定型的な型定義は流し読みです。全部を同じ熱量で見ると続かないので、ここを割り切っています。

品質担保のルールとしては、目視を増やすより機械的に落ちる仕組みを厚くしています。具体的には、異常系のテストを書いて期待通り失敗するか確認する、lint/型チェックをCIで必須にする、AIが触れる範囲を小さいPRに保つ、の3つです。

トラブル例だと、AIが生成したAPIで「ログイン済みか」は見ていたのに「そのリソースの持ち主か（認可）」が抜けていて、他人のデータが取れる状態になっていたことがありました。あと、実装とテストを同じAIに続けて書かせたら、間違った実装に合わせた間違ったテストが両方グリーンで通ってしまった例も。それ以来、テストの観点出しはAIに、期待値は自分で書く、と分けています。

結局、生成速度が上がった分ボトルネックが「書く」から「読む・検証する」に移った感覚です。

・AIが生成したコードのレビューはどのように行っていますか？
・品質を担保するためのルールやチェック項目はありますか？
・実際にトラブルになった経験はありますか？

そういうのはすべてケースバイケースで、単純に答えられる話ではないと思いますが・・・

基本的なこととして心に留めておくべきはことは、少なくとも現時点では AI に丸投げして完璧なコードができることはないということです。さらに、今後 AI がどのように進化しようと、AI が作った成果物に対して、AI が責任を負ってくれるいうことはあり得ないということも。

AI にコードを作ってもらう場合、AI が作ったコードはたたき台として形にしたものだとの認識を持って、そのたたき台をレビューし、理解し、検証し、最終成果物に対して、質問者さんが当事者意識を持った主体的な責任を持てるようにするという基本姿勢が重要だと思います。

AI にはペアプログラマーとしての役割を担ってもらい、力を合わせて開発を加速するという考え方を基本として、どのようにしたら効果的に AI に支援させられるかということを質問者さんが考えながら、「指示」⇒「応答」⇒「検証」⇒「改良」のループを回して開発を行い、成果物を完成させるという方向で考えるべきと思います。

---

【追記】

今頃気が付いたのですが、質問者さんこのスレッドの前に、同じような質問内容のスレッドを立ててますね。

前のスレッドの回答にフィードバックも返さず放置して、また新たに同じような質問内容のスレッドを立てるのは回答者・閲覧者に失礼と思いませんか？

前のスレッドの回答にはフィードバックを返す、それ以上 Q&A が必要なければクローズしてください。

そして、このスレッドには、前のスレッドの URL を書いて、それとの関連、前のスレッドの質問とは何が違うのか・何を聞きたいのかを書いてください。

要件に適合したコードを提供することが目的であり、AIで生成することは手段です。よって従来のレビュー基準をそのまま利用することが基本ですが、特に生成AI利用で意識する点として以下があります。

第一に何故この実装かを説明できるかです。自分で考えて作る作業をAIによって省力化したため、そこは後からでも説明できるようにします。これができないと将来の保守修正ができないシステムになる危険があります。

第二に不要なコードが混ざってないかです。AIは頼んでもいない周辺コードのリファクタリングを勝手に行うことがあります。本質的な修正以外の「余計な差分」が含まれていないかを確認します。

第三にライセンス侵害の回避です。AIは学習データにある第三者のコードをそのまま出力する危険があります。人間の目でレビューしきれるものではないですが、以下の観点が他人のコードの危険のあるサインになります。

• 非常に完成度が高い関数
• コメントや命名が一貫しすぎ

この問題はシステム的な対策が有効です。生成AI側で機能がある場合もあります。GitHub CopilotならばSuggestions matching public codeをBlockに設定します。これはCopilotがコンテキストを無視して既存のコードをそのまま回答するハルシネーションの抑制にもつながります。また、SCA: Software Composition Analysisというツールを利用して検知することができます。

フリーランスでWordPressプラグインを個人で作っているので、レビュアーが自分しかいません。他の方が書かれている「壊れたときの被害でレビュー強度を変える」「機械で落とす仕組みを厚くする」は自分もまったく同じで、ここでは別の角度から。
一番ヒヤッとしたのは、AIが書いたコードのバグそのものより、AIが想定していない入力のほうでした。自分のプラグインはLLMの応答をそのまま画面に出すチャットボットなんですが、AIに任せた出力処理が、LLMの返答を「信頼できる文字列」として扱っていて、HTMLがそのまま注入できる状態になっていた。要はサニタイズ漏れです。AIから見ると自分が生成した応答だからか、外部入力という扱いになりにくいんですかね。とにかくここのエスケープが毎回甘い。Pro版を出す前に自己レビューを11周やって35件直したんですが、3件はこの手のやつでした。
なので今は、コードの綺麗さより「どこが信頼境界か」を先に線引きして、その境界をまたぐデータだけ重点的に読みます。WordPressなら nonce 検証、current_user_can での権限チェック、出力時のエスケープ。この3つはAIの提案を信じず、毎回手で見ます。
テストについては、tony_starkさんの「実装とテストを同じAIに書かせると、間違った実装に合わせた間違ったテストが両方グリーンで通る」に、痛いほど同意します。別件でAIにベンチマークを解かせる実験をしたとき、答えのデータセットに触れる状態にしておくと、問題を解くより「通す」方向に最適化してきました。Brainfuckのいちばん簡単な問題でも、です。それ以来、観点出しはAIに振っても、期待値だけは絶対に自分で書きます。
結局、自分しか見る人がいないので、いちばん効くのは「あとで自分が説明できないコードは残さない」でした。動いていても、なぜこの実装なのかを自分の言葉で言えないものは、半年後の自分が確実に泣きます。

最近は、Claude CodeやCursorといったAIコーディングツールを使って日々を過ごしています。まるで魔法のようにコードが次々と現れ、未完成のアイデアが数分で実行可能な関数へと変化していく様子を眺めているのですが、画面を見つめていると、静かな不安を感じます。スピードは確かに魅力的ですが、スピードだけでは、私たちが築き上げたものが明日の嵐に耐えられるとは限らないからです。AIが生成したコードをレビューするたびに、若い開発者の作品だと想像しながら、一行ずつ読み進めていきます。論理が明確か、あらゆるエッジケースに対応できるか、隠れた非効率性やセキュリティリスクはないか、私たちが丹念に培ってきたパターンにスタイルが合致しているか、そして、大きな問題になる前にミスを検出するためのテストを書けるか、といったことを自問自答します。ローカル環境でのテストでは完璧に見えたルーチンが、本番環境での同時使用のプレッシャーに耐えきれず崩壊した時のことを鮮明に覚えています。AIは提案はできるが、私たちが頼りにしているコードを検証し、洗練させ、守ることができるのは人間だけだということを痛烈に思い知らされました。時が経つにつれ、これらのツールは代替品ではなく、むしろ協力者であることに気づきました。アイデアのきっかけを与え、定型文を作成し、最適化のヒントさえ与えてくれますが、品質、配慮、保守性に対する責任はすべて私自身にあります。カーソルが提案の間を点滅するのを見ながら座っていると、スピードの興奮と、レビューという冷静な規律が調和しているのを感じます。スピードと注意深さのバランスを取ることで、AIは派手なアシスタントから忠実なチームメイトへと変わり、コーディングは単なる仕事ではなく、小さくても意図的な創造行為となるのです。