AIで書きまくる時代、コード検査が先に折れる — 『量を減らす』が AppSec の正解になる

WaveMaker の共同創業者兼 CTO ディーパック・アヌパリ氏が IT 専門メディア InfoWorld に寄稿し、AI 生成コードの本当の課題は「どう検査するか」ではなく そもそも生成する量をどう減らすか だと指摘した。Copilot や Cursor が日産数千行のコードを吐き出す現場で、SAST・SCA・コードレビューがことごとく追いつかなくなっているという警鐘だ。

"AI で生成 → AI で監査" の堂々巡り #

問題は単純な処理速度差ではない。AI が書いたコードを別の AI に検査させても、両者は同じ統計的バイアスを共有しているため、人間なら即気付くロジック欠陥や暗黙の信頼境界の踏み越えを 平然と素通り させる。実際、LLM が幻覚で作り出した「存在しない依存パッケージ名」をそのまま import するコードが多発し、攻撃者がその名前で悪性パッケージを先回り公開する slopsquatting が現実の脅威になっている。

"Less code is more security" を AI 時代に #

セキュリティの古い格言に「書かなかったコードはバグらない」がある。アヌパリ氏の主張は、この原則を AI 時代に適用し直したものだ。ライブラリで済む処理を AI に自力実装させない、既存関数を再利用する、不要な抽象化レイヤを作らない — こうした 設計判断 こそが AI の出力量を抑え、結果として AppSec チームに余裕を生む。

ハッカー視点では、攻撃面を能動的に削るアーキテクチャ判断 (attack surface reduction) は、SAST や SCA では絶対に検知できない上流の防御策だ。AI 補完を導入した組織は、生産性 KPI と並んで「コード差分の純増量」を観測すべき段階に来ている。

まとめ #

• AI 生成コードは検査コストを指数関数的に押し上げる
• AI ↔ AI 監査ループは構造的に脆弱性を素通りさせる
• 守る側の解は「書かせない・書かない」設計判断
• 生産性 KPI に 削減指標 を組み込めるかが分水嶺になる