AI生成コードの脆弱性は連鎖する 査読前研究の指摘

生成AIにコードを書かせる開発が社内で広がるなか、「AIが吐き出したコードは安全なのか」を情シスとして無視できなくなっています。2026年7月13日に公開された査読前（プレプリント）の研究論文は、LLM（大規模言語モデル）が生成したコード3,700件を分析し、脆弱性は単独で現れるのではなく、複数の種類が「連鎖」して同時に発生しやすいという傾向を定量的に示しました。本記事では、その要点と情シスの実務への意味を実務者目線で噛み砕きます。

この記事でわかること

  • LLM生成コードの脆弱性がどれくらいの割合で・どう連鎖して現れるのか（研究の数字）
  • 「どんな指示（プロンプト）が危ないコードを生みやすいか」という研究の示唆
  • AIコーディング支援を導入する情シスが、レビュー体制で押さえるべき勘所

本記事は査読前（プレプリント）の研究を扱います。結果は今後の査読・追試で変わりうるため、断定せず「傾向を知る材料」として読んでください。

どんな研究か（1文で）

ひとことで言えば、LLMが生成したコードに「メタモルフィックテスト」で脆弱性の有無を判定し、「アソシエーションルール分析」でどの脆弱性が一緒に出やすいかを洗い出した研究です。論文名は「Cross-Cutting Security Analysis of LLM-Generated Code via Metamorphic Testing and Association Rule Mining」（著者: Zedong Peng, Chenggang Wang, Shangyue Zhu、arXiv:2607.12089、2026年7月13日公開）。

分析対象は、LLMSecEvalというベンチマークを使って5つのオープンソースLLMに生成させたコード3,700件です。

2つの手法を平易に

  • メタモルフィックテスト（Metamorphic Relations, MR）：正解を1つずつ用意する代わりに、「入力をこう変えたら出力はこうあるべき」という関係（性質）を決め、その関係が崩れていないかで判定する手法。本研究では、SQLインジェクション・XSS（クロスサイトスクリプティング）・OSコマンドインジェクション・パストラバーサル・ハードコードされた認証情報・弱い暗号・メモリ安全性の欠陥といった主要な脆弱性カテゴリを対象に、9つの関係（MR）を定義し、LLMを「審判役」に使って違反の有無を判定しました。
  • アソシエーションルール分析（AR）：小売でいう「おむつを買う人はビールも買う」の相関を見つける手法。ここでは「Aの脆弱性があるコードはBの脆弱性も持ちやすい」という共起パターンと、それを生んだプロンプト側の特徴を結び付けました。

何が分かったのか（主な数字）

研究が報告した主な結果は次の通りです。

観点 結果
少なくとも1つのMR違反（何らかの脆弱性）を含むコード 68.8%
ハードコードされた認証情報の違反率 79.1%
OSコマンドインジェクションの違反率 74.4%
XSS＋弱い暗号の共起が「ハードコード認証情報」を予測する確信度 82.5%（lift=3.23）
5モデル全てで同じ違反結果になったプロンプトの割合 65.5%

脆弱性は「連鎖」する、が最大のポイント

個々の違反率の高さも目を引きますが、この研究の核心は脆弱性が単独では現れにくいことです。たとえば「XSSと弱い暗号がある」コードは、82.5%という高い確信度で「ハードコードされた認証情報」も抱えていました（lift=3.23は、無相関ならありえない強い偏りを意味します）。1種類のチェックだけ通しても、裏に別の脆弱性が潜んでいる公算が高い――という警告です。

危ないコードを生む「プロンプトの特徴」

もう一つの示唆は、データベース系・認証系のプロンプトが、複数種類の脆弱性（cross-cutting insecurity）を強く予測したという点です。「ユーザー認証を実装して」「DBに接続してデータを取得して」といった、まさに機微な処理を任せる指示ほど、危険なコードが返りやすい傾向がうかがえます。さらに、65.5%のプロンプトでは5モデル全てが同じ違反を犯しており、これは「別のモデルに変えれば安全になる」とは限らないことを意味します。

情シスの実務にとって何を意味するか

開発は情シスの直接の担当ではない企業も多いでしょう。しかし、GitHub CopilotをはじめとするAIコーディング支援や、生成AIでの「ちょっとしたスクリプト作成」は、開発部門だけでなく情シス自身の運用現場にも入り込んでいます。この研究の含意は次の3点に整理できます。

  • 「AIが書いたから大丈夫」は成り立たない。7割近くが何らかの脆弱性を含む以上、生成コードは人間が書いたコードと同様（むしろそれ以上）にレビュー・SAST（静的解析）の対象にすべきです。
  • 1種類だけのチェックでは足りない。脆弱性は連鎖するため、SQLインジェクションだけ、XSSだけ、と部分的に潰しても取りこぼします。認証情報のハードコードや弱い暗号まで含めて横断的に確認する必要があります。
  • 「DB・認証まわり」を重点レビューに。研究が示すように、機微な処理を任せた箇所ほど危険です。限られた人員でレビューするなら、まずここに目を向けるのが費用対効果に見合います。

現場目線の所感

正直なところ、AIコーディング支援の導入スピードに、社内のセキュアコーディング・ガイドラインやレビュー体制が追いついていないのが多くの現場の実感ではないでしょうか。「便利だから」と各部署が思い思いにAIを使い始め、生成コードがレビューを経ずに本番へ流れ込む――そんな光景が目に浮かびます。情シスとして端末やツールの利用実態を細部まで把握するのは難しく、そこに「AIが書いたコードの品質は誰も担保していない」という新しい死角が加わった、というのが率直なところです。まずは「AIで作ったコードもレビュー対象」という当たり前のルールを、社内に明文化することから始めるのが現実的でしょう。

情シスはどこを参照すべきか

脆弱性そのものはSQLインジェクションやXSSなど、以前から知られた「枯れた」種類です。つまり対策の教科書はすでに存在します。AI特有の新技術で身構えるより、まずは基本のセキュアコーディング指針を社内レビューの物差しにするのが近道です。

そのうえで、AIコーディング支援の利用ルール（どこまで許可するか、生成コードのレビュー必須化、機微処理は人間が書く等）を自社の実態に合わせて定めていくのが順序として自然です。地道ですが、利用者への啓発と「レビューを飛ばさない」文化づくりが結局は効きます。

まとめ（3点）

  • 査読前研究によれば、LLM生成コードの68.8%が何らかの脆弱性を含み、しかも脆弱性は単独でなく複数種類が連鎖して現れやすい。
  • DB・認証まわりのプロンプトほど危険で、モデルを変えても同じ違反を犯す傾向がある（65.5%）。「AIが書いたから安全」は成り立たない。
  • 脆弱性の種類は枯れたものが中心。基本のセキュアコーディング指針（IPA等）を物差しに、生成コードも横断的にレビューする体制づくりが情シスの現実的な打ち手。

関連記事

出典

タイトルとURLをコピーしました