10月23日、Thoughtbotが「Who's reading the code your AI writes?」と題した記事を公開した。AIが生成するコードの品質・セキュリティリスクと、それを見極める人間の判断力の重要性を論じた内容だ。
AIが書いたコードを、誰がレビューしているか
AIによるコーディング支援の生産性向上は数字でも裏付けられている。Stanfordの研究者が10万人以上のエンジニアを対象に調査したところ、AIによってグリーンフィールド開発（既存コードベースに縛られない、まっさらな状態からの新規開発）では30〜40%の生産性向上が確認された。PythonとTypeScriptで効果が最も大きく、これはモデルが学習できるコードが豊富なためとみられる。
一方、複雑な既存コードベースでの効果は10%以下にとどまることも同じ研究は示している。10年間育ち続けたRailsアプリのような環境では、AIも新人エンジニアと同じ壁にぶつかる。意思決定が文書化されておらず、テストが薄く、なぜそのアーキテクチャになったかの文脈が一部の人の頭の中にしかない、という状態だ。
44%のAIタスクがセキュリティ脆弱性を生んでいる
記事の核心はここにある。**Veracodeの調査によれば、AIを使ったコーディングタスクの44%でセキュリティ脆弱性が混入していた。コードが正常に動作していても、だ。**
Thoughtbot自身も、規制業界（医療・金融など）向けにリリースされようとしているバイブコーディング（vibe-coded：AIに大まかな方向性だけ与えてコードを生成させる開発手法）アプリのほぼすべてで、深刻な欠陥を発見したと報告している。
具体的な問題として挙げられているのは以下のようなものだ。
- 権限チェックが機能しなくなっていても誰も気づかない
- 患者データがログファイルに出力されてしまう
- 決済処理の丸め誤差が監査まで発覚しない
こうしたアプリの多くはTypeScriptとReactで書かれており、Lovableなどのツールがデフォルトで生成するスタックだ。見た目は完成しているが、本番リリースに耐えられる安全性には達していないことが多い、と記事は指摘する。
経験豊富なエンジニアがバイブコーディングしたアプリは相対的に品質が保たれていた、とも述べている。ツールは同じでも、何を確認すべきかを知っているかどうかが差を生む。
なお、Veracodeの調査における「44%」という数字は記事タイトルにも引用されており、著者がこの統計をAIコード品質問題の象徴として中心に据えていることが記事全体の構成からも読み取れる。
経営層とエンジニアの認識ギャップ
Atlassianの2026年版開発者体験調査では、経営層の64%が「AIをより使えばより良いアウトカムが得られる」と回答した一方、エンジニアの41%が「期待されているから仕方なくAIを使っている」と回答している。
Robby RussellのRailsコミュニティサーベイ（2026年版）では、51%のRails開発者がAIの進化ペースに対してスキルの長期的価値について不安を感じており、3人に1人は使用を強いられることへの不満を示している。
記事はどちらの立場も否定しない。「AIが定着するという経営層の判断は正しい。そしてAIが出力したものを最終的に誰かが責任を持たなければならないというエンジニアの主張も正しい」というのが著者の立場だ。
現場で実践すべきこと
記事が提示するガイドラインは実践的だ。
- PRは小さく保つ。誰もレビューできないサイズのPRは「完了」ではない
- 基準をコードで書く。テスト、リンター、エージェントへのルールという形で標準を明文化する
- 患者データ・決済・権限まわりには最も経験豊富な人間を配置する
規制業界での開発案件では、コンサルタントが1日の約80%を仕様（SPEC）の精緻化と関係者との調整に費やすケースもあったという。それが完成すれば、Claudeが実装を担えるが、その前提となる仕様の品質が全体の品質を決める。
結論
AIをフル活用することと、生成されたコードに対して人間の判断を介在させることは矛盾しない。問題は速度ではなく、誰がそのコードを読み、責任を持つかだ。AIが「動くコード」を書ける時代だからこそ、「安全なコード」を判断できる人間の役割はむしろ重くなっている。
詳細はWho's reading the code your AI writes?を参照していただきたい。
