GitHubへのコミットの51%がAI生成またはAI支援。 もはやコードの半分はAIが書いている時代だ。
でも一方で、開発者のAIへの信頼度はたった29%。 Stack Overflow 2025調査で、前年の40%からさらに下がった。
使ってるけど信じてない。
この矛盾、まじで考えさせられるんだよね。
前回の記事ではAIコーディングツールの「生産性パラドックス」について書いた。 速くなったはずなのに成果が出ない問題だ。
今回は、その続編として**「品質」にフォーカスする。 CodeRabbitが470のPRを分析した大規模調査で、AI生成コードの問題発生率が人間の1.7倍**であることが明らかになった。
この数字とどう向き合うか。 僕が実践しているレビュー戦略について書いてみる。
AI生成コードの品質、数字で見ると
まずデータを見よう。
2025年12月、AIコードレビューツールのCodeRabbitが「State of AI vs Human Code Generation」レポートを公開した。 470の実世界オープンソースPR（AI共著320件、人間のみ150件）を分析した結果だ。
AI生成PRの問題発生率は平均10.83件/PR。人間PRは6.45件/PR。
約1.7倍。 しかもこれ、全カテゴリで一貫して高い。
- 論理・正確性エラー: 1.75倍
- コード品質・保守性: 1.64倍
- セキュリティ問題: 1.57倍
- パフォーマンス問題: 1.42倍
特にセキュリティは深刻だ。 XSS脆弱性は2.74倍、不適切なパスワード処理は1.88倍、安全でないデシリアライゼーションは1.82倍。 AIが書くコードは、人間が書くコードよりも多くの穴を開ける。
Veracodeの調査では、AI生成コードの45%にセキュリティ欠陥が見つかっている。 2026年3月だけでも、AI生成コードに直接起因するCVEが35件以上開示された。 推定では実際には400〜700件に上るという。
さらにGitGuardianの2026年レポートでは、AI支援コードのシークレット漏洩率がGitHub全体の基準の約2倍と報告されている。 2,865万件の新しいハードコードされたシークレットがGitHub公開コミットに追加された。 APIキーやパスワードがそのままコードに埋め込まれている状態だ。
数字を並べると正直怖い。 でも「AI使うのやめよう」とはならない。 コミットの51%がAI支援の時代に、使わないという選択肢は現実的じゃないと思う。
問題はAIそのものじゃなく、レビュー体制がAI時代に追いついていないことだ。
なぜAI生成コードの品質が低いのか
原因はシンプルだ。 レビューをスキップしているから。
「Vibe Coding」という言葉を知っている人も多いと思う。 AIの出力をほぼ確認せずに受け入れて、コンパイルが通ればOKとする開発スタイルだ。 2025年にAndrej Karpathyが提唱して一気に広まった。
でもそのKarpathy自身が、2026年2月に方針転換している。 「Agentic Engineering」という、より規律あるアプローチへの移行を提案した。
なぜか。 Vibe Codingはプロトタイプや個人ツールなら問題ない。 でも本番環境に入った瞬間、設計・レビュー・テストをスキップしたツケが回ってくるからだ。
GoogleのAddy Osmani氏はこう言っている。 「CTOに『あなたの決済システムをvibe engineeringしてます』と言ってみてください。その顔を見ればわかります」
Stack Overflowの2025年調査では、66%の開発者が「ほぼ正しいがわずかに間違っている」AI生成コードの修正に追加時間を費やしている。
これが前回の記事で書いた「生産性パラドックス」の品質版なんだよね。
AIが大量のコードを一瞬で生成する。 でもその「ほぼ正しい」コードを検証するのは人間だ。 そして84%が使っているのに、信頼度は29%しかない。
信頼していないのにチェックもしない。 この矛盾が品質危機の本質だと思う。
実践レビュー戦略: AIの手綱を握る
じゃあ具体的にどうするか。
僕が実践しているのは、3段階のレビューフレームワークだ。
第1段階: AIによるファーストパス
まずAIレビューツールで機械的なチェックを通す。
- 構文エラー、コードスタイルの不統一
- 既知のセキュリティパターン（SQLインジェクション、XSS等）
- 重複コード、未使用変数、命名規則の違反
CodeRabbitのようなツールを使えば、PRごとに自動で40以上のリンターとセキュリティスキャナを走らせてくれる。 人間がやると見落としやすい「機械的に検出できる問題」を先に潰す。
第2段階: 人間によるロジック・設計レビュー
AIが見つけられないのは「文脈に依存する問題」だ。
- ビジネスロジックが仕様と一致しているか
- アーキテクチャの設計判断が妥当か
- エッジケースの処理が漏れていないか
- そもそもこの変更が本当に必要か
ここは人間が責任を持つ。 Addy Osmaniが言う「AIが実装し、人間がアーキテクチャ・品質・正確性を担う」という分業だ。
前回の記事で書いた「ゴールを一文で書けるか」テストがここでも効く。 そのPRのゴールを一文で説明できないなら、レビュー以前にPR自体を分割すべきだ。
第3段階: セキュリティ重点チェック
AI生成コードはセキュリティに穴を開けやすい。 CodeRabbitのデータが示す通りだ。
特に注意するポイントを絞っておく。
- ハードコードされたシークレット（APIキー、パスワード）
- 入力バリデーションの欠如
- 認証・認可チェックの漏れ
- エラーメッセージからの情報漏洩
GitGuardianの調査にある通り、AI支援コードのシークレット漏洩率は2倍だ。 「AIが書いたから大丈夫」は完全に間違い。 むしろAIが書いたからこそ、セキュリティは人間が目を光らせる必要がある。
僕がClaude Codeで実践していること
ここからは僕自身の話。
僕は2026年に入ってから、「まずClaude Codeにやらせてみよう」が口癖になった。 Claude Codeをメインの開発スタイルにしていて、コードの大部分をAIに書かせている。 4月からは生成AI専任の役割にもなった。
だからこそ、品質問題は他人事じゃない。
僕がやっている具体的な対策を書いておく。
仕様を先に書く
以前、OCR+LLMで請求書読み取りの精度改善に取り組んだことがある。 従来のMLモデルでは正解率が約1割だった読み取り精度が、AIの組み合わせ方を変えたことで劇的に向上した。
この経験で学んだのは、AIは使い方次第で品質が激変するということだ。 「とりあえずAIに投げる」と「ゴールと制約を明確にしてからAIに渡す」では、出力品質がまるで違う。
だから今は、Claude Codeに実装を頼む前に必ず仕様を書く。 何を実現したいのか、入出力は何か、制約条件は何か。 ゴールが曖昧なときは、先にClaudeと壁打ちして整理してから始める。
すべてのdiffを読む
これは覚悟の問題だ。 AIが書いたコードのdiffは必ず全部読む。
正直、面倒だ。 AIが大量のコードを一瞬で生成してくれるのに、レビューに時間をかけるのは矛盾しているように感じるかもしれない。。 でもAddy Osmaniが言う通り、「説明できないコードは出荷しない」を徹底するしかない。
2026年は「ハーネスエンジニアリング」という言葉も出てきた。 AIエージェントの「手綱」を握る技術だ。 馬に乗るのは速い。でも手綱を離したら暴走する。 AIも同じなんだよね。
エンジニアとしての生存戦略を考えたとき、AIにコードを書かせる能力よりも、AIが書いたコードの品質を担保する能力のほうが希少価値が高くなる。 僕自身、他部署への越境も含めてAIの活用範囲を広げているけれど、「品質の番人」としてのスキルが今後ますます重要になると感じている。
テストを先に書く（またはAIに書かせる）
Agentic Engineeringの核心は「テストの徹底」にある。 テストスイートがあれば、AIに何度でも実装をやり直させて、テストが通るまで繰り返せる。
テストこそ人間がAIをコントロールするための最強のツールだと思う。 テストが通らない実装は、どんなに速く生成されても価値がない。
まとめ: 速さから品質へのシフト
CodeRabbitは「2025年はAIの速度の年、2026年はAIの品質の年」と言っている。 まさにその通りだと思う。
AI生成コードのバグ率1.7倍は事実だ。 でもそれは「AIを使うな」ではなく、「レビューの仕方を変えろ」というメッセージだ。
明日からできる3つのことをまとめておく。
- AIレビューツールを入れる: CodeRabbitのようなツールで機械的チェックを自動化する。人間の目は設計判断とセキュリティに集中させる
- diffは必ず自分の目で読む: AIが書いたコードの全行を確認する。説明できないコードは出荷しない
- 仕様を先に書いてからAIに渡す: ゴールが曖昧なまま「とりあえず書いて」は品質問題の元。壁打ちでもいいから、先に整理する
AIの手綱を握る技術。 それが2026年のエンジニアに求められるスキルだと思う。 前回の記事で書いた「使いこなす技術」の、さらに具体的な一歩として、ぜひ試してみて。
