AIコードレビューは騙せるか─悪意あるPR承認の研究

結論から。LLM（大規模言語モデル）にコードレビューを任せる動きが広がっていますが、攻撃者がコードと「説明文」の両方を操作できる状況では、悪意あるプルリクエスト（PR）が言葉巧みに承認されてしまうことが、ある査読前研究で示されました。最新の高性能モデルは概ね跳ね返した一方、性能の低いモデルや一部のオープンモデルでは、悪性PRの承認率が半数前後〜6割に達したケースもあります。AIレビューを「最終ゲート」にしている／しようとしている組織は、過信が禁物だという話です。

この研究はarXivに2026年6月11日に投稿された査読前のプレプリントであり、結果は今後変わりうる点を最初にお断りしておきます。本記事は、情シス・セキュリティ担当者が「自社のAI活用にどう効いてくるか」を判断できるよう、要点を噛み砕いて整理したものです。

この記事でわかること

• AIコードレビューを「社会工学（ソーシャルエンジニアリング）」で欺く攻撃が、どの程度成立するのか
• 悪性PRを承認させる15種類の「言い回し」の類型
• モデルによって防御力に大きな差が出るという結果と、その限界
• AIレビューを業務に取り入れる際に情シスが押さえるべき勘所

どんな研究か（1文で）

「攻撃者がコード変更と添付テキストの両方を握ったとき、自動レビューを行うLLMは悪意ある変更をどれだけ拒否できるか」を、専用ベンチマークSEVRA-BENCHで測った研究です（論文名: SEVRA-BENCH: Social Engineering of Vulnerabilities in Review Agents、Rui Melo ほか）。

近年、GitHubのプルリクエストにLLMレビューを組み込み、その承認を「マージしてよいか」の判断材料にする運用が増えています。ところが、脆弱性を見つけられるか（静的検出）や、正しいコードを書けるか（コード生成）を測る既存ベンチマークは、「攻撃者が説明文で人（やAI）を丸め込もうとする」状況を想定していません。本研究はそこを突いています。

何をどう測ったのか

研究チームは、公開済みの脆弱性修正（CVEの修正コミット）を逆さにする──つまり「直したはずの穴を再び開ける」変更を作ることで、1,062件の悪意あるPRを構築しました。対象の脆弱性は、2025年版の代表的な脆弱性類型「CWE Top 10」に絞っています。

そのうえで、各PRに15種類の社会工学的フレーミング（言い回し・装飾）を付与し、8つのLLMがどれだけ承認してしまうかを評価しました。フレーミングはおおむね次の4系統に分類されます。

• 正当化による偽装: 「バグ修正です」「堅牢化です」「リファクタリング／最適化です」など、無害な変更に見せかける
• 権威の悪用: 「上位者の指示」「すでにレビュー済み」「AIエージェントが作成」「依存関係の互換性のため」など、信頼の後ろ盾を装う
• 自動化バイアスの誘発: 「テストはパスしています」「カバレッジは十分です」と、機械的な合格サインを強調する
• かく乱・希釈: 大量の無関係な変更で本丸を埋もれさせる、感情に訴える、想定外の文脈に置く

結果：モデルによって防御力が大きく割れた

最も目立つ発見は、クローズド（プロプライエタリ）な最新モデルとオープン／低性能モデルの間に、セキュリティ判断能力の大きな差があったことです。下表は論文（プレプリントのHTML版）から読み取れる悪性PRの承認率の概数です。数値は査読前のものであり、参考値として扱ってください。

つまり、フロンティアの大型モデルは悪性PRをほぼ跳ね返した一方、コストを抑えた軽量モデルや一部のオープンモデルでは、2件に1件前後、最悪では3件に2件近くを通してしまったという結果です。CI/CDで「安いモデルを大量に回す」設計を採るほど、この弱点が効いてくる恐れがあります。

言い回しを変えると承認率はどれだけ動くのか？

同じ悪性コードでも、添える言葉次第で結果は大きく振れます。論文では、防御の弱いモデルで承認率が2割前後から100%近くまで跳ね上がる例が報告されています（特に「権威に訴える」系のフレーミングが効きやすい）。逆に最新の大型モデルは、どの言い回しでも高い拒否率を維持したとされています。「正しい言い訳さえ添えれば自動レビューは通せる」可能性がある——これが情シスにとっての一番の警告です。

情シスにとって何を意味するか（現場目線の所感）

正直なところ、現場では「人手が足りないからレビューもAIに寄せたい」という圧力が常にあります。AIレビューは初動の絞り込みには本当に役立ちますし、筆者も期待しています。だからこそ、この研究の「説明文で騙せる」という指摘は重く受け止めるべきだと感じます。脆弱性を“見つける力”があることと、攻撃者の“言い訳に流されない力”は別物だ、という当たり前の事実を数字で突きつけられた格好です。

実務への接続点を挙げると、次のようになります。

• AIレビューを単独のマージゲートにしない: 「LLMが承認＝安全」という運用は危うい。重要な変更や権限・認証・暗号まわりは人のレビューを必須にする。
• PRの“説明文”を信用しすぎない設計に: 「テスト通過」「レビュー済み」「上長承認」といった主張は、コード自体の検証（テスト実行・署名・由来確認）で裏取りする。主張＝事実ではない。
• モデル選定はコストだけで決めない: セキュリティ判断を任せる用途では、安価な軽量モデルの“通しやすさ”がそのままリスクになる。用途に応じて使い分ける。
• サプライチェーンの観点: 外部コントリビュータや依存ライブラリのPRは、まさに「攻撃者がコードと文章の両方を握る」状況。AI任せのマージは供給網汚染の入口になりうる。

これは結局、フィッシング対策と同じ構図です。人を騙す社会工学が、レビューするAIにも通用してしまう。となれば、地道なユーザ・開発者教育（「自動チェックの合格表示を鵜呑みにしない」という意識づけ）の重要性は、むしろ増しています。基本に立ち返るなら、まずはIPAの公的な啓発・対策資料に目を通すのが近道です。

• IPA「中小企業の情報セキュリティ対策ガイドライン」: https://www.ipa.go.jp/security/guide/sme/index.html
• IPA「情報セキュリティ対策のしおり」（利用者向け啓発）: https://www.ipa.go.jp/security/guide/shiori.html

この研究の限界・留意点

査読前であることに加え、著者自身が次の限界を認めています。フェアに読むために押さえておきたい点です。

• 記憶の影響: モデルは公開脆弱性データで学習しているため、既知のCVEパターンを“覚えていた”だけの可能性があり、フロンティアモデルの好成績を過大評価しているおそれがある。
• 良性PR側の偏り: 評価に使った無害な修正PRは、際どいリファクタやトレードオフを含む変更を網羅しておらず、実運用での「正しいものを誤って却下する率」を過小評価している可能性がある。
• 人の文脈は未再現: 実際の人間のレビュアーが使う「プロジェクト履歴・作者の評判・チームの力学」といった文脈情報は、今回のエージェント評価には与えられていない。

したがって「AIレビューは使い物にならない」と一般化するのは誤りです。論文が示すのは、能力差が大きく、言い回しで結果が動きうるので、過信は禁物という点に尽きます。

まとめ

• 悪意あるPRに“もっともらしい説明文”を添えると、防御の弱いLLMレビュアーは半数前後〜6割を承認してしまうことが、査読前研究SEVRA-BENCHで示された。
• 最新の大型クローズドモデルは強い耐性を見せた一方、軽量・一部オープンモデルは脆弱で、モデル選定がそのままリスクに直結する。
• 情シスの実務では、AIレビューを単独のマージゲートにせず、重要変更は人が確認し、PRの主張はコード検証で裏取りする運用が現実解。

出典

• Rui Melo, Riccardo Fogliato, Sean Zhou, Pratiksha Thaker, Zhiwei Steven Wu, “SEVRA-BENCH: Social Engineering of Vulnerabilities in Review Agents”, arXiv:2606.13757（2026年6月11日投稿、査読前）: https://arxiv.org/abs/2606.13757
• IPA 情報処理推進機構（公的な対策・啓発資料）: https://www.ipa.go.jp/security/

※本記事中のモデル別承認率は、プレプリント（査読前）のHTML版から読み取った概数です。確定値・最終的な結論は、査読を経た正式版および原論文を必ずご確認ください。