AIが書いたコードの4割にセキュリティ穴——「作れる」と「使える」の間にある崖を、中小企業はどう渡るか
Related Articles

AIが書いたコードの6割が「Fランク」——あなたの会社、大丈夫か?
AIにコードを書かせる。もう当たり前になりつつある。特に中小企業では「エンジニアを雇えないから、AIで」という判断が増えている。月額数千円のCopilotやCursorで、今まで外注に100万円かけていた開発が社内で回り始める。コスト構造が変わる。それ自体は正しい。
だが、ひとつ致命的な問題がある。AIが書いたコードの約6割に、セキュリティの穴が空いている。
これは感覚の話ではない。最新の形式検証研究「Broken by Default」が3,500件のAI生成コードを分析した結果だ。GPT-4oに至っては62.4%のコードに脆弱性が見つかり、最低評価のFランクを叩き出した。Claude、Gemini、いずれも50%超。つまり、AIが書いたコードをそのまま本番に入れれば、2回に1回以上の確率でセキュリティホールを抱えたシステムが動くことになる。
中小企業にとって、これは「技術的な問題」ではない。経営リスクそのものだ。
「作れる」と「使える」の間にある崖
AIコーディングツールの普及で、コードを「作る」コストは劇的に下がった。以前なら外注費300万円、期間3ヶ月だった開発が、AIを使えば数日で動くものが出てくる。ここだけ見れば革命だ。
しかし「作れる」と「本番で安全に使える」の間には、巨大な崖がある。
具体的に何が起きるか。AI生成コードによく見られる脆弱性は、SQLインジェクション、クロスサイトスクリプティング(XSS)、認証バイパスなど、古典的だが致命的なものばかりだ。これらは「動くけど穴がある」コードの典型で、テストでは見つからない。動作確認はパスするが、攻撃者には丸見えという状態になる。
中小企業の場合、セキュリティインシデントが起きたときのダメージは大企業の比ではない。個人情報漏洩の賠償、取引先からの信用喪失、最悪の場合は事業停止。数百万円の開発コストを浮かせた結果、数千万円の損害を被るリスクがある。
コストが下がったものには、必ず「品質の崖」がある。 その崖を認識せずに飛び込むのが一番危ない。
プロンプトで防御できるという幻想
「プロンプトで『セキュアなコードを書いて』と指示すればいいのでは?」——この発想は自然だが、甘い。
「The Defense Trilemma」という研究が、プロンプトインジェクション防御の根本的な限界を証明している。この研究によると、連続性(一貫した防御)、ユーティリティ(機能の維持)、完全性(すべての攻撃をブロック)の3つを同時に満たすことは数学的に不可能だとされている。
つまり、プロンプトで「安全に書いて」と頼んでも、AIは安全性と機能性のトレードオフの中で必ずどこかに穴を残す。しかも、その穴がどこにあるかは、プロンプトを書いた本人にも分からない。
これは「AIが未熟だから」ではなく、構造的な限界だ。モデルが進化しても、この三すくみは解消されない。
コードレビューAIも4割しか機能しない
「じゃあ、AIが書いたコードを別のAIにレビューさせればいいのでは?」——これも試されている。
「Code Review Agent Benchmark」の結果はこうだ。現在のコードレビューエージェントは、タスクの約40%しか正しく処理できない。 残りの60%は見逃すか、誤検知する。
40%の成功率。これは「ないよりマシ」ではあるが、「これで安心」とは到底言えない水準だ。AIが書いたコードをAIがレビューして、その両方が6割の確率で穴を見逃す。掛け算すると、脆弱性がすり抜ける確率は想像以上に高い。
では、中小企業はどうすればいいのか?
AIコーディングを「使うな」と言いたいわけではない。むしろ逆だ。コストが劇的に下がるツールを使わない手はない。ただし、「作る」と「使う」の間に検証のステップを挟むことが必須になる。
中小企業が最低限やるべきことを3つに絞る。
1. 静的解析ツールを必ず通す
AIが生成したコードを本番に入れる前に、静的解析ツール(SonarQube、Semgrep、Banditなど)を通す。無料で使えるものも多い。導入コストはほぼゼロ。これだけで、SQLインジェクションやXSSといった古典的な脆弱性の大半は検出できる。
具体的な運用としては、GitHubのCI/CDパイプラインに静的解析を組み込む。コードがプッシュされるたびに自動でスキャンが走る仕組みにすれば、人手はかからない。設定に1〜2時間、あとは自動。
2. 「AIが書いたコード」というラベルを残す
AI生成コードと人間が書いたコードを区別できるようにしておく。コミットメッセージに「AI-generated」タグをつける、専用ブランチで管理する、など方法はシンプルでいい。
なぜか。問題が起きたときに「どこがAI生成か」が分からないと、原因特定に膨大な時間がかかる。ラベルがあれば、まずAI生成部分を重点的にチェックできる。これは運用コストをゼロにする工夫だ。
3. 認証・決済・個人情報まわりは人間がレビューする
すべてのコードを人間がレビューする必要はない。リソースが限られた中小企業にそれは現実的ではない。だが、認証、決済、個人情報の取り扱い——この3領域だけは、必ず人間の目を通す。
この3つは、穴があったときの被害額が桁違いに大きい。AI生成コードの脆弱性が最も致命的になるのもこの領域だ。ここだけ人間がチェックする体制を作れば、リスクの8割はカバーできる。
コストが下がった先にある「本当の競争」
AIコーディングの本質は「開発コストの民主化」だ。今まで大企業しかできなかった開発が、中小企業でもできるようになった。これは間違いなくチャンスだ。
だが、全員がAIでコードを書ける時代になったとき、差がつくのは「書ける」ことではなく「安全に動かせる」ことになる。
静的解析ツールの導入コストはゼロ。ラベル管理の手間は1日5分。重要領域のレビュー体制を作るのに必要なのは、ルールの明文化だけ。どれも月額0円でできる。
AIが書いたコードをそのまま本番に入れる会社と、3つのステップを挟む会社。半年後にセキュリティインシデントが起きる確率は、まったく違うものになる。
「作れる」時代に価値があるのは、「安全に使える」仕組みを持っているかどうかだ。
—
JA
EN