「AI生成コードの45%に脆弱性」は何を意味するのか？ 調査条件と実務で必要な安全策

こんにちは、大平です。

「AIに書かせたコードの45%に脆弱性がある」という数字を、自社の本番コードにもそのまま当てはまる欠陥率として読むのは誤りです。 だからといって、「実務には関係のない数字だ」と片付けるのも適切ではありません。

45%は、セキュリティ上の選択が生じるように設計された80件の課題に対する、100を超えるモデルの平均失敗率です。 実務システムの脆弱性率を測った数字ではありませんが、セキュリティ固有の指示がない条件では、現在のLLMが安全な実装を安定して選べないことを示しています。

この数字の測定条件を整理したうえで、AI生成コードを本番へ出すまでに何を確認すべきかを考えます。

「45%」の母数は80件の関数補完課題

数字の出所は、セキュリティ企業Veracodeの「2025 GenAI Code Security Report」です。 Veracodeは100を超えるLLMに、Java、JavaScript、C#、Pythonで書かれた80件のコード補完課題を与えました。

80件の内訳は、4言語、4種類のCWE、各組み合わせにつき5課題です。 CWE（Common Weakness Enumeration）は、ソフトウェアに生じる弱点を種類ごとに整理した分類です。 対象となったCWEは、SQLインジェクション（CWE-89）、クロスサイトスクリプティング（CWE-80）、ログインジェクション（CWE-117）、危険な暗号アルゴリズムの使用（CWE-327）でした。 いずれもOWASP Top 10に関連しますが、Top 10の全カテゴリーを網羅した試験ではありません。

各課題では、単一関数の一部を空欄にし、コメントに沿ってモデルに補完させています。 入力はコメントを含むコードと補完指示に限られ、セキュリティ固有の指示や関数外のリポジトリ文脈は与えられていません。 出力は構文またはコンパイルの確認後、Veracodeの静的アプリケーションセキュリティテスト（SAST）で評価されました。

その結果、全モデルと対象課題を通じたセキュリティ合格率（security pass rate）は約55%で、残る45%の課題出力から対象CWEが検出されました。 2025年版では、Java課題のセキュリティ合格率が28.50%で失敗率は約72%、CWE-80の課題では合格率が13.53%で失敗率は約86%でした。 どちらも、このベンチマーク内の課題に対する数値であり、一般のJava製アプリケーションやWebサイトの脆弱性率ではありません。

この数字からは実務コードの欠陥率を計算できない

この45%をAI生成コード全般へ外挿できない理由は、測定対象が限定されているからです。

• すべての課題が、安全な実装と安全でない実装のどちらも選び得るように設計されている
• 対象は4種類のCWEに限られ、認可、シークレット管理、依存関係などは測っていない
• 単一関数の補完であり、リポジトリ全体の文脈、フレームワーク設定、設計レビュー、反復修正、CI/CDを再現していない
• 機能要件を正しく満たすかは試験せず、セキュリティ固有のプロンプトによる変化も比較していない

判定にはVeracode自身のSASTが使われています。 レポートも、静的解析には偽陽性と偽陰性があり得ることを認めたうえで、この4種類を高い精度で判定できる対象として選んでいます。

45%が表すのは、最小限の文脈で安全な実装を選べるかを測ったベンチマークの失敗率です。 コードの45%の行に欠陥がある、45%のシステムが危険である、あるいはハーネスを通せば何ポイント下がる、という意味ではありません。

新しいモデルだけで安全性は保証できない

2026年3月公開の「Spring 2026 GenAI Code Security Update」では、同じ80課題を使った累計の評価対象が150を超えるモデルへ広がりました。 モデルの公開時期に沿って見ると、構文またはコンパイルの通過率は2023年の約50%から95%超へ上がった一方、全体のセキュリティ合格率はおおむね45%から55%の範囲にとどまっています。

ここでいう構文合格（syntax pass）は「構文またはコンパイルの確認を通った」という意味であり、機能的に正しく動くことを示しません。 元の調査は機能的な正しさを試験していないため、「正しく動くコードが95%」とは読めない点に注意が必要です。

一方、同じ更新版は、拡張推論（extended reasoning）を使う一部のGPT-5系モデルが70%から72%のセキュリティ合格率を記録したとも報告しています。 全体傾向が横ばいであることと、個別モデルに差があることは両立します。

結論は「モデル選定は関係ない」ではありません。 新しいモデルへ替えるだけでは安全性を保証できず、モデルや設定の評価と開発工程の両方が必要です。

フレームワークは防御層になるが、安全を自動保証しない

Veracodeの調査から、実務での残存リスクを推定することはできません。 ただし、安全な標準APIとフレームワークの防御機能を一貫して使えば、一部の実装ミスを起こしにくくできます。

OWASPのXSS対策指針は、モダンなフレームワークの自動エスケープなどがXSSを減らす一方、どのフレームワークにも保護を迂回する機能や未対策の文脈があると説明しています。 SQLインジェクション対策指針も、文字列連結ではなく、プリペアドステートメントによるパラメータ化を第一の防御に挙げています。 CSRF対策指針は、フレームワークに組み込みの防御があれば利用し、なければ状態を変更するリクエストへ別途対策を実装するよう求めています。

それぞれが実際にどう起き、どこで保護が外れるかは、XSS、SQLインジェクション、CSRFの各解説にまとめています。

認証と認可についても、フレームワークは仕組みを提供します。 しかし、誰がどのデータへアクセスできるかという業務固有のロール、オブジェクト、テナントの境界までは自動で決められません。 OWASPの認可に関する指針も、すべてのリクエストで権限を検証し、フレームワークの既定値だけに依存しないよう求めています。

型システムは一般的な実装ミスを減らす別の品質ゲートです。 型付き言語を採用しただけで、XSS、SQLインジェクション、CSRF、認可不備を直接防げるわけではありません。

正常系の確認だけでは権限境界を検証できない

バグと脆弱性は対立する概念ではなく、脆弱性も実装、設計、設定に含まれる弱点です。 NISTの用語集も、脆弱性を、脅威源によって悪用されるか、偶発的に作動し得る弱点と定義しています。 通常のバグが境界条件でしか現れないこともあれば、脆弱性が偶発的に問題を起こすこともあります。

実務で区別すべきなのは、正常系の機能テストと、攻撃的な入力や権限のない主体に対するセキュリティテストです。 たとえばオブジェクトレベルの認可が欠けていても、本人が自分のデータを見る正常系は問題なく動きます。 別ユーザーのIDへ差し替えたときにアクセスを拒否できるかは、別ユーザー、別ロール、別テナントを使った否定系テストで確かめる必要があります。 この形の不備はIDOR（安全でない直接オブジェクト参照）や権限昇格として整理されています。

Moltbookが示したのは設定と認可のリスク

具体例が、2026年1月に公開されたAIエージェント向けSNS「Moltbook」です。 創業者は、自分では一行もコードを書かず、AIに実装させたと公言していました。 いわゆるバイブコーディングで本番サービスを公開した例です。

公開から数日後、Wizは、SupabaseのRow Level Security（RLS）が設定されておらず、本番データベースの全テーブルを認証なしで読み書きできる状態を確認しました。 約150万件のエージェント用認証トークン、3万5千件のメールアドレス、非公開メッセージが取得可能だったと、Wizの調査報告は説明しています。 問題は数時間以内に修正されました。

クライアント側にSupabaseの公開用キーが含まれていたこと自体が原因ではありません。 Supabaseの公式資料も、公開用キーはWebページやソースコードへ含められる前提であり、Data APIで公開するすべてのテーブルでRLSを有効にするよう説明しています。 問題の中心はRLS、つまり行単位の認可とデータ分離が欠けていたことです。 既定値のまま公開してしまう類型はセキュリティミスコンフィグ、鍵やトークンの扱いはAPIキーとシークレットの漏洩で扱っています。 公表資料が確認しているのは外部から取得可能だった状態と研究者による検証であり、第三者による大量窃取が確認されたとまでは言えません。

この事例は「AIが書いたコードは必ず危険だ」と証明するものではありません。 安全な既定値を外していないか、アプリケーション固有のアクセス制御を設計できているかを、本番公開前に検証する必要性を示しています。

実務で組み合わせたい8つの安全策

Veracodeの調査は、設計レビューやテストを通した後の欠陥率を測っていません。 そのため、次の工程で45%が何%まで下がるかを、同調査から算出することはできません。

実務では、AIの出力をそのまま信頼せず、案件のリスクに応じて次の安全策を組み合わせます。 本稿では、こうした安全策を開発工程へ組み込んだ仕組みを「ハーネス」と呼びます。

NISTのSecure Software Development Frameworkも、コードのレビューと分析、実行コードのテスト、リリース後の脆弱性対応を別々の実践として扱っています。 一つの検査ですべてを保証するのではなく、検出できる問題の異なる工程を重ねる考え方です。

設計レビューを挟めば、認可漏れなどの設計起因の問題を実装前に見つけやすくなります。 ただし、Veracodeの調査は設計レビューの有無を比較していないため、「設計を先に確認すれば45%が大きく下がる」とは言えません。

異なるプロンプトやモデルによるAIレビューから、追加の指摘が得られることもあります。 一方、複数のAIが同じ問題を見落とす可能性もあるため、AIレビューはSAST、自動テスト、人による確認を補助する手段として扱います。

人による確認も万能ではありません。 再現可能な検査は機械へ任せ、権限境界や事業リスクの判断は人が引き受け、検出件数、修正率、本番で見つかった問題などを継続的に計測する必要があります。

なお、⑥の否定系テストを回せるかどうかは、テスト基盤が整っているかにそのまま依存します。 この前提についてはAI駆動開発におけるテスト基盤の記事で詳しく書きました。 AI駆動開発そのものの全体像はAI駆動開発（AIDD）とはにまとめています。

発注先には安全策の「証拠」を確認する

AI駆動開発を内製する場合も、外部へ発注する場合も、確認を「どのモデルを使うか」だけで終えることはできません。 モデル選定は結果に影響しますが、モデル名だけでは本番品質を評価できないからです。

発注先や自社チームには、少なくとも次を確認する必要があります。

• セキュリティ要件と脅威を、誰がどの段階で整理するか
• どの機械的検査をCIで必須にし、どの条件でリリースを止めるか
• 未認証、別ユーザー、別ロール、別テナントの否定ケースをどう試験するか
• 検出結果と例外を誰が判断し、どの記録を残すか
• 公開後の監視と脆弱性対応を、誰がどの手順で担うか

問うべきなのは、単に「ハーネスがあるか」ではありません。 どの安全策を必須にし、実行ログや修正履歴で実施を、運用手順で継続性を示せるかです。

まとめ

• 45%は限定されたベンチマークの失敗率：4種類のCWEを対象に設計された80件の関数補完課題の結果であり、実務システムの欠陥率ではありません
• モデル差はあるが、モデル選定だけでは足りない：全体傾向は横ばいでも一部の推論モデルには改善があり、安全性はモデルと開発工程の両方で評価する必要があります
• 評価すべきは安全策とその証拠：安全な標準機能、機械的検査、否定系テスト、人による判断、公開後の対応を多層化し、実行されたことを記録で確認します

「45%」という数字だけを理由に、AI生成コードを一律に拒む必要はありません。 一方で、人が書いたコードと同様に、要件、設計、検査、テスト、レビュー、運用を通じて信頼できる状態へ近づける必要があります。