そのAI生成コード、全部レビューしますか？全部信じますか？
初めまして、kagayaです。
AIネイティブなプロダクト開発を頑張っています。最近の事業・プロダクト関係のトピックは、山登りというタスクがプロダクトの実証実験・PoCのために発生したことです。
共訳した「AIエンジニアリング（オライリー・ジャパン）」が11/28に発売です。よろしくお願いいたします。
世はAIコーディングエージェント時代。
圧倒的に手数は多くなり、自動でPRを生成する取り組みも見かけるようになりました。
かくいう私も、Claude Code Actionを夜間に動かしてGitHub Issueを自動解決する実験をし、朝に作成されているPRを眺めて、「これが不労コード生活か」と思うなどしていました。
そんな中で、新しく生まれた悩みの一つは、このコード、どこまでレビューすればいいんだ？ です。
全部読んでたら、自分で書いた方が早くない？でも全部信じるのも怖い。
バイブに身を任せた結果として生まれた数千行のPRを前に、途方に暮れた経験がある人もいるのではないでしょうか。
ThoughtworksのTo Vibe or Not Vibeという記事を元ネタに考えてみます。
AI生成コードをどこまでレビューするのか？
結論、「全部見る」でも「全部信じる」でもないのだろうと感じています
そして先の未来も考えると、人間がプロダクションコードの大半を書き、レビューする世界は確実に変わっていく（変わっている）はずです。
コードレビュー自体にAIの介在が増えていくのも自明です。実際にOpenAIやAnthropicは、自社のコーディングエージェントをレビューに活用していると何度も言及しています。
（私も今は一人で開発しているので、AIをレビュワー、もはやコードオーナーとして頼っている・扱っています）
OpenAI社内では、AIコードレビューが生産性を10倍向上させると感じられたことから「10X」と呼ばれ、開発のボトルネックを解消する切り札に
このツールは90%を超える正しさでコードの深い問題を指摘するため、開発者にとって不可欠な「安全網（セーフティネット）」となり、レビューのボトルネックを解消
とはいえ、AIにコードレビューしてもらうか、人間がレビューするかを問わず、判断基準やどのように向き合うかを言語化したいと考えていました。
そんな時に見つけたのが、"To Vibe or Not Vibe"という記事です。
この記事では、確率・影響・検知性の3軸でVibe Codeに向き合うことを述べています。
リスク評価=確率・影響・検知性
簡単に述べると「AIが間違う確率 × ミスがあった時のヤバさ × ミスに気づけるか」の3軸でリスクを評価しよう というシンプルなフレームワークです。
| 判断基準 | 問いかけ・観点 |
|---|---|
|
確率 (AIが間違う可能性) |
・コードベースはAIフレンドリーか？ ・既存コードは良い手本か？ ・タスクは明確で定型的か？ |
|
影響 (ミスした時の被害) |
・今夜オンコール担当ならデプロイできるか？ ・バグがビジネスや顧客に与える損害は？ ・影響範囲は限定的か、広範囲か？ |
|
検知性 (ミスに気づけるか) |
・あなたの技術スタックへの習熟度は十分か？ ・十分なテストや型システムで保護されているか？ ・結果はすぐに見て確認できるか？ |
確率（Probability）： AIが間違う可能性
「このタスクで、AIはどれぐらいミスしそうか？」
この軸では、AIがコードを間違える可能性を評価します。
例えば、TypeScriptでReactの簡単なフォームを作るのと、Rustで複雑なマルチスレッドコードを書くのでは、AIの間違う確率が全然違います（多分）
要因はタスクの複雑さか、コードベースのコンテキスト量、そもそも技術スタックがトレーニングデータにどれだけ含まれているかによるかもしれません。
影響（Impact）： ミスがあった時のヤバさ
「このコードが壊れたら、どれぐらいヤバい？」
AI生成コードに限らない観点ではありますが、影響度に応じて求められる品質保証も変わります。
社内ツールのプロトタイプと、金融系の決済システムでは、求められる品質が桁違いです。
深刻なのは、構文的にも機能的にも正しく見えて、セキュリティに問題があるケースです
- Veracode社の調査では、テストされたコードサンプルのうち45%が、OWASP Top 10に含まれるような重大なセキュリティ脆弱性を含む
- 言語によってリスクは異なる。Javaで生成されたコードは、防御失敗率が72%に達したが、Pythonが38%、JavaScriptが43%、C#が45%
- クロスサイトスクリプティング（XSS）は苦手、関連コードサンプルの86%で防御に失敗
hallucinateを悪用したSlopsquattingなる攻撃もあるので、鵜呑みにするのはリスクがあります。
検知性（Detectability）： ミスに気づけるか
「このコードが間違ってたら、気づける？」
これもAI生成コードに限りませんが、ミスにどうやって気づくか？の仕組みは重要です。
検知性を高める取り組みは、テストカバレッジを上げることかもしれませんし、型システムや静的解析ツールかもしれません。
https://speakerdeck.com/rkaga/agentic-coding-starts-with-testing?slide=18
この検知性は一番重要で、かつ一番コントロールしやすい軸だと捉えています。
Simon Willisonも指摘するように、「コードのhallucinationは比較的安全なミス」なのです。
なぜなら、実行すれば即座にエラーに気付くことができるから（型やユニットテスト等で検知性があれば） です。存在しないメソッドを呼び出せば、すぐにクラッシュします。それをLLMにフィードバックすれば、修正されたコードが返ってきます。
それと比べると、テキストや医療・法律分野でのhallucinationは、間違いに気づくのが困難です。
コード生成においては、コンパイラやテストはファクトチェック機構としても機能します。
各軸に対して出来ること
ここからは各軸に対して、何が出来るのか？を簡単に考えてみます。
AIが間違う確率を下げる
いわゆるAIコーディングエージェントのtipsとして一番盛んにシェアされているのはこの軸です。
コンテキスト分離・圧縮をする、タスクを細分化する、ツールの使い分けを考えるなどなどです。
最近ではAIコーディングエージェントの文脈でもコンテキストエンジニアリングのワードが飛び交うことが増えましたが、LangChainの公式ブログで提唱されている4つの基本要素、「書き込み（Write）」「選択（Select）」「圧縮（Compress）」「分離（Isolate）」は、AIコーディングエージェントの活用でも参考になります。
Context Engineering for Multi-Agent LLM Code Assistants Using Elicit, NotebookLM, ChatGPT, and Claude Codeでは、典型的なOrchestrator・マルチステップ構成で、必要な情報を複数のステップで体系的に構築し、構造化してAIエージェントに供給する仕組みが取り上げられています。
| 工夫 (Technique) | 役割と具体的な効果 (Role & Specific Effect) |
|---|---|
| 意図翻訳 (Intent Translation) |
開発者の曖昧な指示を、AIが迷わず実行できる具体的なタスク仕様書に変換する役割。これにより、要件の誤解釈に起因する手戻りを防止を目指す。 |
| 外部知識の獲得と要約 (Knowledge R&S) |
LLMの事前知識を補うため、Webから最新・最適な専門知識（ドキュメント等）を動的に収集・要約し、コンテキストとして注入。これにより、AIの知識不足による性能低下やHallucinationを減らす |
| コンテキストの階層化 (Context Layering) |
目的、知識、ルールといった性質の異なる情報を論理的な「層」として構造化し、整理された形でAIに提供する。これにより、AIが思考の優先順位をつけやすくなり、複雑な状況でも安定した判断を下せるようになる。 |
| 役割ごとのコンテキスト分離 (Role-Specific Context) |
各専門エージェントに自身の役割遂行に必要な情報だけを限定的に与え、責任範囲を明確にする。これにより、各AIがタスクに集中し、情報汚染のない安定した動作を実現する。 |
影響を見極める
影響度の判断は、プロジェクトの性質によって大きく変わります。ここはAIコーディングエージェント登場は関係なく、今までと最も変わらない軸だと捉えています。
認証・認可のロジックや決済処理は、たとえAIが間違う確率が低くても、人間による徹底的なレビューが欲しいです。
（あまり書けることありませんでした。色んなガイドラインやチェックリスト等を読んだり、一番経験や直感が生きる感覚）
検知性を最大化する
検知性を高めることは、他の2軸のリスクを緩和することにもつながります。
冒頭で紹介したYoutube動画のように、AIコードレビューの活用もこの領域に寄与します。
わかりやすいのは、ユニットテストや型システムです。たとえ、AIがhallucinateしたメソッドやプロパティを生成しても、コンパイル・テスト実行時に即座にエラーとなり、エラーメッセージがAIへのフィードバック情報として修正をかけられます。
最近だとこの文脈でもガードレールとか呼ばれていたり、TDDやBDDに言及してる例も多い印象です。
AIコーディングエージェントありきのアプローチ
また、AIコーディングエージェントありきで考えたら、検知性への取り組みも新しいアプローチが考えられます。
2025年現在、テスト生成に特化したAIツールも充実してきていて、AI生成コードをAIが生成したテストで検証し、AIがコードレビューするという、AI同士の相互チェック（コード領域におけるLLM as a Judge）を実現できます。
例えば、Meta社のTestGen-LLMも、LLMを使って既存のテストを自動改善するツールで、検知性を高める実践例として注目に値します
- 既存の人間が書いたユニットテストをLLMが自動改善
- カバレッジを基準にしたリトライループで、テストの品質を段階的に向上
- LLMのhallucinationを排除する仕組みを組み込み
他にもTesting Trophy、従来の「大量のユニットテスト、少しの統合テスト、ごく僅かのE2Eテスト」というピラミッド型から、より統合的なテストに重点を置くにシフトするアイディアです。
引用: https://kentcdodds.com/blog/the-testing-trophy-and-testing-classifications
このように、AIコーディングエージェントありきで考えたら、検知性への取り組みも新しいアプローチが考えられます。
とりあえず私は下記書籍を読みます。
まとめ：AIをいつ信じ、いつ疑うか
どんどんコードレビューから話がそれましたが、AI生成コードに対する向き合い方について書いてきました。
AI生成コードが一般化した結果 「誰が・どのようにコードに責任を持つのか という問いへの答えも変わりつつあります。
それこそ、実装の詳細より、仕様と振る舞いの保証へと力点は少しずつ移っていると感じます。
紹介した3軸で捉え、確率や検知性を改善するHowを磨く、影響を見極める直感を養っていくのは一つのアプローチとなりそうです。
元記事でも、「The goal is not to slow yourself down with checklists, but to grow intuitive habits」（チェックリストで遅くなるのではなく、直感的な習慣を養うこと）と強調されている通り、「いつAIを信じて、いつ疑うか」の勘所/審美眼を養うことが、求められています。
皆さんはどんな基準でAI生成コードをレビューしていますか？
今回は以上です！次はAIに孤独を癒してもらっている話を書きたい。
Discussion