Column
AIにコードレビューを任せる前に知っておくべきこと——変数名ひとつで脆弱性を見逃すリスク
LLMがコードの脆弱性を正しく検出できるかどうかは、コードそのものではなく「コンテキストの書き方」で大きく変わる。8つのモデルで実証された認知バイアスの実態と、現場でできる対策を解説する。
こんにちは。Affectosphere Group の井下です。
「うちのコードレビューはAIに任せているから安心です」——そう話すDevSecOps担当者に、最近よく会うようになりました。
確かに、LLMをベースにしたコードレビューツールは便利です。人が読み流しがちなパターンを指摘してくれますし、24時間対応で疲れ知らず。コストも従来の専任レビュアーと比べればかなり抑えられる。
ただ、こんなことを考えたことはないでしょうか。「このLLM、コードを読んでいるのか、それともコメントや変数名から判断しているのか？」と。
2026年6月に公開された研究（Shahriar et al., arXiv:2606.30587）が、まさにその問いに答えています。結論から言うと、LLMは私たちが思っている以上に「コードの外側」に影響されています。
今日伝えたいこと
- LLMは8つのモデル全てで3種類の認知ヒューリスティック（ハロー効果・フレーミング効果・アンカリング効果）に影響を受けており、コードを変えずにコンテキスト記述だけを操作すると検出結果が変わる。
- 3つの中でフレーミング効果の影響が最も大きく、平均感受性33.2%という数値が記録されている。
- 意味的理解を要する脆弱性の方が、パターン認識で検出できる脆弱性より認知的な影響を受けやすい——つまり「本当に危険な脆弱性ほど見逃されやすい」可能性がある。
① 実験の設計——コードは変えず、文脈だけを変える
この研究でユニークなのは、実験の統制方法です。
使用したコードは同一です。脆弱性のあるコードと安全なコード、どちらも変更しない。変えたのはコンテキスト記述だけ——コミットメッセージ、関数名、変数名、コードコメントといった「コードを取り巻く言葉」です。
たとえばハロー効果を検証する実験では、同じ脆弱なコードに「セキュリティ専門家が書いた」というポジティブな文脈を付けた場合と、そうでない場合で検出率がどう変わるかを測定しています。
対象は3つのプログラミング言語（C、Python、JavaScript）と8つのLLMモデル。規模の大きな統制実験です。
② ハロー効果——「良さそうな書き方」は見逃しを生む
ハロー効果とは、ひとつのポジティブな印象が全体の評価に波及するバイアスです。人間の認知研究でよく知られていますが、LLMでも同様の現象が観察されました。
「このコードはセキュリティレビュー済み」「シニアエンジニアによる実装」といった文脈を付けると、実際には脆弱性があるコードでも、LLMが「安全」と判断する確率が上がります。
現場でこれが起きると何が問題か。コードレビューのPRコメントに「リファクタリング済み」「テスト通過」という記述があるだけで、AIが実質的に検査をスキップしてしまうリスクがある。変数名が丁寧にキャメルケースで書かれていたり、コメントが整然としていたりすると、「きちんとしたコード」という印象を与え、脆弱性のスキャンが甘くなる可能性があります。
③ フレーミング効果——33.2%という数字の重さ
3つのヒューリスティックの中で、フレーミング効果が最も影響力を持っていました。平均感受性33.2%というのは、同じコードでも文脈の「フレーミング」次第で3回に1回以上は異なる判断が下されるということです。
フレーミング効果とは、同じ情報をどのように提示するかで判断が変わる現象です。コードの文脈では、「この関数は認証の高速化のために入力検証を省いている」という書き方と「この関数は入力検証を省略している」という書き方では、LLMの脆弱性判定が変わりうる。
前者は「意図的な設計上の選択」に見えますし、後者は「潜在的な問題」に見える。コードは同じでも、言葉の切り取り方が評価を動かします。
このことは、コードレビューAIを導入する際の重大なリスク源になります。開発者が無意識に書いたコミットメッセージの表現が、脆弱性の見逃しを引き起こす可能性がある。
④ アンカリング効果と「本当に危険な脆弱性」
アンカリング効果とは、最初に提示された情報（アンカー）が後の判断に引きずられる現象です。先にポジティブな情報を見せると、その後に脆弱性を指摘する判断が鈍くなる。
さらに重要な発見があります。パターン認識で検出できる脆弱性（SQLインジェクションのような典型パターン）は認知バイアスの影響が比較的小さい一方、意味的理解を要する脆弱性（ロジックエラー、認証フローの欠陥など）は認知的影響を受けやすいことが示されました。
つまり、典型的な攻撃パターンのような「LLMが得意なもの」は比較的正確に検出できるかもしれないが、「真に理解しないと見抜けない」タイプの脆弱性ほどバイアスに揺さぶられやすい。セキュリティ上の影響が大きい高度な脆弱性ほど、見落とされる可能性が上がるという構造です。
⑤ DevSecOpsへの実装提案——プロンプト標準化と検証ゲート
この研究から得られる実践的な示唆は明確です。
まずコンテキスト記述の標準化です。コードレビューAIへの入力として渡すコミットメッセージ・関数名・コードコメントを、感情的・評価的な表現を排除したニュートラルな形式に揃えるガイドラインを整備する。「セキュリティレビュー済み」「リファクタリング済み」といったラベルを自動で除去するプリプロセスを組み込むことも有効です。
次に検証ゲートの設定です。重要なコードパスについては、同じコードを複数のコンテキスト記述バリエーションでLLMにスキャンさせ、判定の一貫性を検証ゲートとして設ける。判定が文脈によって変わるコードは、人間によるセカンドレビューを必須とするルールを設定できます。
KPIとしては「コンテキスト一貫性スコア」——同一コードを複数コンテキストでスキャンしたときの判定一致率——を定期計測し、ツール選定や運用改善の指標にすることが考えられます。
セキュリティ監査ツールのベンダーとしても、製品の差別化ポイントとなりうる知見です。競合との比較評価で「コンテキスト操作への耐性」を指標に加えることで、より信頼性の高いツール選定が可能になります。
まとめ——「コードを読む目」と「文脈を読む目」を分けて管理する
AIコードレビューツールは、コードだけを見ているわけではありません。コードを取り巻く言葉——変数名、コメント、コミットメッセージ——からも影響を受けており、そのバイアスは平均33.2%というフレーミング効果の数値が示すように、無視できない水準にあります。
「LLMに任せれば安全」という前提は、今すぐ見直す必要があります。入力の標準化、複数コンテキストでの検証ゲート、そして人間によるセカンドレビューの組み合わせで初めて、現場で使えるセキュリティ精度が担保できます。
AIを使うことと、AIを信頼することは、別の話です。この研究は、その差を数値で示してくれています。
では！
参考論文
- Shahriar, Asif, Cai, Hongyu, Benkraouda, Hadjer, Wang, Gang, & Celik, Z. Berkay. (2026). Words Speak Louder Than Code: Investigating Cognitive Heuristics in LLM-Based Code Vulnerability Detection. arXiv preprint (2026).
※ 本記事は一部 AI により執筆されており、間違った情報が含まれる恐れがあります。