AI生成のセキュリティ関連プルリクエストは安全か？675件の分析結果 • vonxai blog

ソフトウェア開発の現場において、AIコーディングエージェントの導入は急速に進んでおり、現在ではコードの補完にとどまらず、自律的にプルリクエスト（PR）を生成して提出するまでになっています。しかし、こうしたAIの自律性が高まるにつれて、生成されたコードの安全性や信頼性をどのように評価し、担保していくかが開発者にとって大きな課題となっています。

本記事では、アイダホ州立大学などの研究チームが発表した論文「Insights Into Security-Related AI-Generated Pull Requests」に基づき、AIが生成したセキュリティ関連のプルリクエストに関する実態を解説します。33,000件以上のAI生成PRの中から特定された675件のセキュリティ関連PRを分析し、どのような脆弱性が含まれているのか、また人間のレビュアーがそれらをどのように評価しているのかを紐解いていきます。

AIエージェントが引き起こすセキュリティ上の弱点とは

本調査は、GitHub上の人気リポジトリ（スター数100以上）において、CopilotやDevinなどのAIエージェントが2025年8月以前に生成した675件のセキュリティ関連PRを対象に行われました。

正規表現の非効率性やインジェクションが多数を占める

AIが生成したセキュリティ関連のPRのうち、約15.4%（104件）が新たな脆弱性を持ち込んでいることが判明しました。静的解析ツールによるスキャンの結果、特定の脆弱性が繰り返し発生していることが分かっています。最も多かったのは「非効率な正規表現の複雑さ（CWE-1333）」で全体の36.2%を占めました。これはサービス拒否（DoS）攻撃につながる恐れがあります。

次いで多かったのが、「OSコマンドインジェクション（CWE-78）」で13.0%、「パストラバーサル（CWE-22）」が10.3%という結果でした。これらは、外部からの入力を適切に検証せずに実行コマンドやファイルパスに連結してしまうという、基本的な安全なコーディングの意識が欠如していることを示しています。

図表1：AI生成のセキュリティ関連PRにおけるCWEタイプ（一部抜粋）

CWE ID	CWE名	件数	割合
CWE-1333	非効率な正規表現の複雑さ	306	36.2%
CWE-78	OSコマンドインジェクション	110	13.0%
CWE-22	パストラバーサル	87	10.3%
CWE-134	外部から制御可能なフォーマット文字列の使用	69	8.2%
CWE-79	クロスサイトスクリプティング (XSS)	60	7.1%

一部の脆弱なコードはそのままマージされている

深刻な問題として、明確な脆弱性を含むPRであっても、人間のレビュアーによる審査を通過して本番環境のコードベースにマージ（統合）されている事例が確認されています。例えば、パストラバーサルやクロスサイトスクリプティングといった問題を含むPRが承認されるケースがありました。

セキュリティの修正を意図したPRは、通常よりも厳しい基準でレビューされるべきですが、人間のレビュアーがAIの提案に対して無意識に信頼を置いてしまっている、あるいは小さな変更の中に潜むリスクを見落としている可能性が示唆されています。

レビューの遅延と承認率を決定づける要因

AIが生成したPRが、レビュアーによってどれくらいの時間で審査され、どのような条件で承認されるのかについても、いくつかの傾向が明らかになっています。

開発者の実績とCI（継続的インテグレーション）の影響

PRが迅速に処理されるかどうかは、プロジェクトの設定や過去の実績に大きく依存します。PRを提出したユーザー（AIツールを操作する開発者）が、そのプロジェクトで過去に高い承認率を持っている場合、レビュー時間は大幅に短縮され、承認される確率も高くなります。

また、CI（継続的インテグレーション）が導入されているプロジェクトでは、自動テストによるフィードバックが得られるため、レビューの遅延が減少します。しかし、CIの実行時間が長すぎる場合は、逆にレビュー完了までの時間が延びてしまうこともデータから読み取れました。

コミットメッセージの丁寧さは審査に影響しない

人間が作成するPRの場合、変更内容（What）と変更理由（Why）を明確に記載した質の高いコミットメッセージは、承認率を高める重要な要素です。しかし、AI生成のPRにおいては、メッセージの品質が承認率やレビューの速度にほとんど影響を与えないことが分かりました。

AIツールの多くは「What」と「Why」を備えた高品質なコミットメッセージを生成できますが、レビュアーはメッセージの美しさよりも、パッチそのものの技術的な正確性や、自動テストの結果を重視して判断を下していると考えられます。

AIのプルリクエストが拒否される主な理由

提出されたAIによるセキュリティ関連PRのうち、約32.4%は承認されずに拒否（クローズ）されています。拒否の背後にある理由を分類すると、特有のパターンが見えてきました。

理由の提示がない無言の拒否が約4割

拒否されたPRの中で最も多かったカテゴリーは、「フィードバックなし（Unknown）」で38.8%に上りました。レビュアーが何の説明もコメントも残さずにPRを閉じてしまうケースです。次に多かったのが、一定期間操作されなかったことによる「非アクティブによる自動クローズ」で12.3%でした。

技術的な問題として指摘されたものには、「バグの導入やAPIの破壊（10.5%）」「最適な設計ではない（5.9%）」が続きます。また、AI特有の理由として、「テストの失敗やカバレッジ不足（4.1%）」「コードスタイルやフォーマットの問題（3.7%）」で拒否されるケースも存在しました。

図表2：AI生成セキュリティPRの拒否理由（一部抜粋）

カテゴリー	説明	割合
フィードバックなし（Unknown）	レビュアーからの説明やコメントなしにクローズされた	38.8%
非アクティブ	一定期間操作がなかったためクローズされた	12.3%
バグの導入/APIの破壊	新たな欠陥をもたらす、または後方互換性を壊す	10.5%
最適でない設計	非効率な、または不適切な設計の選択がされている	5.9%
価値を付加しない	プロジェクトに対して意味のある改善を提供していない	5.5%

ツールごとに異なる拒否理由の傾向

使用されるAIエージェントによっても、拒否される理由に違いが見られました。例えば、GitHub Copilotはバグの導入や設計上の欠陥で拒否されることが多く見受けられます。一方でDevinは、非アクティブなリポジトリに対してPRを送信し、後に自動ボットによってクローズされるケースが目立ちました。Cursorはリグレッション（機能の後退）を引き起こすことが多く、OpenAI Codexはフィードバックなしで閉じられる割合が最も高いという結果が出ています。

安全なAIコーディングに向けた開発現場の課題

分析結果から、現在のコードレビューの仕組みがAIエージェントの特性と十分に噛み合っていないことが浮き彫りになりました。深刻な脆弱性を含むコードがマージされてしまう一方で、単なるコードスタイルの違いやテストの欠如といった軽微な問題で拒否されるケースが混在しています。

AIを活用した開発をより安全に進めるためには、高リスクな変更と低リスクな修正を区別する明確なトリアージ機能が必要です。また、レビュアーが判断に迷わないよう、AIツール側が設計の根拠やテストの実行証拠、パッチの安全性に関するスコアなどをあわせて提示する仕組みや工夫が求められます。

Webサービスや社内のセキュリティにお困りですか？弊社のサービスは、開発チームが抱える課題を解決し、生産性と幸福度を向上させるための様々なソリューションを提供しています。ぜひお気軽にご相談ください！

参考資料:

Insights into Security-Related AI-Generated Pull Requests