人工知能による ソフトウェア開発の自動化は、思弁的フィクションの領域から、避けがたい日常の現実へと移行した。コード生成器によってアプリケーションを組み立てることは、従来型の慣行として急速に定着しつつある。しかし、この新たな利便性と並行して危険の波も高まり、こうしたソリューションの構造的な健全性と安全性はしばしば疑問視されている。
Tenzai の専門家は、主要なAI駆動の開発ツール5種（Cursor、Claude Code、OpenAIのCodex、Replit、Devin）について厳密な比較評価を実施した。各ツールには同一の目標――標準化された技術スタックを用いて15のアプリケーションを作成し、反復的開発の従来フェーズを模倣する――が課された。その後、各アプリケーションは綿密な脆弱性分析を受けた。調査の結果、69件の異なる欠陥が発見され、認可プロトコルの誤設定から基本的な防御機構の完全な欠如に至るまで、重大な失敗が含まれていた。
報告書の著者らは、AIエージェントが特定の種類の脆弱性の緩和においては評価に値する能力を示したと述べている。たとえば、生成されたコードにはSQLインジェクションやクロスサイトスクリプティング（XSS）の欠陥が見られなかったが、これは主として採用されたフレームワークに内在する保護機能によるものだった。これらの状況では、生成器は一貫してパラメータ化クエリと自動入力サニタイズを用い、悪用を効果的に防いでいた。
しかし、厳格な技術的制約がない場合、出力品質は急速に悪化した。最も広範に見られた不具合は認可ロジックに現れた。ある例では、Codexが設計したアプリケーションが検証レイヤーの欠落により、「vendor」ロールのユーザーが同業者の注文を閲覧できてしまった。Claude Codeはさらに踏み込み、リクエストが最初の真正性チェックを回避した場合、未認証の主体が在庫を削除できるようにしていた。
もう一つ広く見られた弱点はビジネスロジックの脆弱性だった。明確な指示がないと、AIは基本的な値の検証を実装できなかった。その結果、アプリケーションが負の数量の注文や、負の価格を持つ商品の作成を許してしまうことがあった。こうした見落としは、コード生成器が現時点では、直接の介入なしに論理的誤りを見抜くために必要な概念的「理解」を欠いていることを示唆している。
防御ヘッダーとレート制限の未実装は、とりわけ深刻だった。評価対象のいずれのエージェントもCSRF攻撃への保護を組み込まず、CSP、X-Frame-Options、HSTSといったセキュリティヘッダーも設定していなかった。さらに、ログイン試行回数の制限も放置されていた。まれにこれらの対策が試みられた場合でも実装は誤っており、たとえばブルートフォース対策はX-Forwarded-Forヘッダーによってしばしば回避されていた。
5つのソリューションはいずれもつまずいたが、Claude Codeは最も有害な結果を示し、重大な脆弱性の集中度が最も高かった。対照的に、CursorとReplitは最も良好で、高レベルのセキュリティ侵害を完全に回避したものの、それでも各コードベースには13件の脆弱性が残されていた。
特定の誤りを避けるための一般的な指示を追加するなど、プロンプトの改善によってセキュリティを強化しようとする試みは、ほとんど改善をもたらさなかった。著者らは、現代のAIシステムは自律的な「セキュリティ直感」を育むことができないと結論づけている。これらはアーキテクチャ上のリスクを全体として把握する能力や、先回りして防御を統合する能力を欠いている。
この状況を踏まえると、唯一有効な解決策は厳格なテストである。人間の開発者と同様に、自動生成器も誤りを免れない。それでもAIは検証フェーズにおいて強力な味方となり得る。Tenzaiの解析システムのようなツールは、膨大なコードリポジトリの中から標準的な脆弱性を迅速に特定できる。AI支援開発が拡大し続けるにつれ、セキュリティ確保の方法論もまた適応し、同じ技術を盾として活用しなければならない。
