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

AIが書いたコードの6割が「Fランク」——あなたの会社、大丈夫か? AIにコードを書かせる。もう当たり前になりつつある。特に中小企業では「エンジニアを雇えないから、AIで」という判断が増えている。月額数千円のCopilotやCursorで

By Kai

|

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つのステップを挟む会社。半年後にセキュリティインシデントが起きる確率は、まったく違うものになる。

「作れる」時代に価値があるのは、「安全に使える」仕組みを持っているかどうかだ。

POPULAR ARTICLES

Related Articles

POPULAR ARTICLES

JP JA US EN