はじめに
2025年後半から2026年にかけて、Linuxカーネルや広く使われているOSSのコードベースから、これまで長年見逃されていた脆弱性が次々と発見されています。そのきっかけの多くが AIを活用したコードレビュー です。
「AIがコードを読んで脆弱性を見つける」という話は数年前からありましたが、実際に CVE が割り当てられるレベルの脆弱性が量産されるようになったのはここ最近のことです。何が変わったのか、そしてエンジニアとしてどう向き合えばいいのか、まとめてみました。
最近 AI によって発見された主な脆弱性
CrackArmor（2026年3月）：AppArmor の複数脆弱性
セキュリティ企業 Qualys のリサーチャーが AI を活用しながら発見した、Linux カーネルの AppArmor（Linux Security Module）に潜む脆弱性群です。CVE が 11件割り当てられ（CVE-2026-23268〜CVE-2026-23411）、影響範囲は Ubuntu・Debian・SUSE・Proxmox など AppArmor を採用するほぼすべてのディストリビューションに及びます。
最も根本的な脆弱性は「Confused Deputy 問題」と呼ばれるもので、AppArmor のプロファイル管理用疑似ファイルへの書き込み権限チェックのタイミングに設計上の隙がありました。非特権ユーザーが su コマンドの PTY モードを経由して任意のセキュリティプロファイルを書き込める状態で、これを起点に Use-After-Free や Double-Free といったカーネルメモリの脆弱性へとエスカレーションし、最終的に root への権限昇格が実証されました。このコードは長年メンテナンスされ続けていたにもかかわらず、問題は発見されていませんでした。
ZeroPath が発見した sudo の脆弱性（2025年11月）
AI セキュリティエンジニアリング企業 ZeroPath が、sudo の exec_mailer() 関数に「fail-open」な実装上のバグを発見しました。メールエージェントを起動する際に権限降格（setuid）が失敗した場合でも、後続の execv() がそのまま root 権限で呼び出されてしまう問題です。
この問題単体では通常は悪用できないものの、CrackArmor の AppArmor 脆弱性と組み合わせることで Postfix がインストールされた環境での root 権限奪取が実証されました。ZeroPath はこの発見を「AI Security Engineer による自動コードレビュー」として公表しており、AI が能動的にコードの意味的な危険性を指摘した事例として注目されています。
CVE-2024-50264 および類似の Linux カーネルメモリ管理の脆弱性
Alexander Popov 氏らによる研究で、Linux カーネルのメモリ管理・ネットワークスタック周辺に存在する Use-After-Free 系の脆弱性が AI を補助ツールとして使いながら複数発見されています。これらは個別の脆弱性としては地味に見えますが、組み合わせることでカーネル権限への昇格チェーンが成立するものです。コードが数万行規模の巨大なサブシステムにまたがって存在しており、人間が手作業でパターンを追うことが現実的でないケースがほとんどでした。
curl / libcurl の長期潜伏バグ（2025年）
HTTP クライアントライブラリとして世界中のシステムに組み込まれている curl でも、AI コードレビューをきっかけに複数の脆弱性が発見されました。いずれも数年から10年以上潜伏していたバグで、特定のプロトコル処理における境界チェックの欠如やメモリの二重解放が含まれます。curl のメンテナーである Daniel Stenberg 氏は「AI ツールの助けがなければ発見にさらに数年かかっていた可能性がある」とコメントしています。
なぜ今、これほど多くの脆弱性が発見されているのか
1. LLM のコード理解能力が実用レベルに到達した
以前の静的解析ツールは主に「パターンマッチング」でした。既知の危険なコードパターン（strcpy の無制限使用など）を検索するイメージです。これに対して、大規模言語モデル（LLM）はコードの意味を理解した上でレビューできます。
「この関数はここで失敗したときに呼び出し元がどう処理するか？」「この参照カウントは本当にすべてのパスで正しくインクリメントされているか？」といった、文脈をまたいだ推論が得意です。こうした「意味的な危険性の発見」は、従来の静的解析が苦手としていた領域です。
2. 処理できるコンテキストの量が桁違いに増えた
カーネルのような巨大なコードベースでは、脆弱性が単一の関数内に完結していることは稀です。A ファイルでメモリを確保し、B ファイルで参照し、C ファイルで解放する——というように複数ファイル・複数モジュールにまたがる問題が多くあります。
最新の LLM は数万〜数十万トークンのコンテキストを一度に処理できるようになり、こうした「広範囲にわたるデータフローの追跡」が現実的になりました。
3. セキュリティ研究者が AI をツールとして積極的に使い始めた
Qualys・ZeroPath・Google Project Zero をはじめとするセキュリティリサーチチームが、AI を「脆弱性ハンティングのアシスタント」として日常的に活用するようになっています。人間の勘や仮説検証のスピードが AI によって大幅に上がり、「怪しい」と感じたコードを素早く深堀りできるようになりました。
4. 長年メンテナンスされたコードへの初めての大規模レビュー
Linuxカーネルや curl のような歴史のあるコードベースは、当時の慣習で書かれた部分が多数あります。当時は問題なかったコードが、カーネルの他の部分の変更によって後から脆弱になるケースもあります。こうした「時間をかけて脆弱になったコード」を、AI はコンテキストなしに機械的にフラットに読めるため、人間が持ちがちな「このコードは昔からあるから大丈夫だろう」というバイアスなしに評価できます。
AI と人間のコードレビューの違い
AI と人間はコードレビューにおいてそれぞれ得意なことが異なります。どちらが優れているかではなく、補完関係にあると考えるのが正確です。
AI が得意なこと
網羅性と一貫性
コードの量や時間帯に関わらず、すべての行を同じ品質で確認します。「今日は疲れているから見落とした」「このファイルは読むのが大変だから流した」ということがありません。
広範囲なデータフロー・制御フローの追跡
複数ファイルにまたがる変数の参照・解放・上書きのパターンを機械的にトレースします。人間がホワイトボードに図を書きながら追うような作業を、高速かつ大規模に行えます。
既知の脆弱性パターンとの照合
CVE データベースや過去の脆弱性レポートで学習した「危険なコードパターン」を大量に記憶しており、類似パターンの検出が得意です。
ドキュメントとコードの整合性チェック
「仕様書にはこう書いてあるが、実装はこうなっている」という乖離を指摘するのも得意です。
人間が得意なこと
ビジネスロジック・設計意図の評価
「このコードが正しく動くか」ではなく「このコードがやるべきことをやっているか」を判断するには、要件や背景の理解が必要です。AI は仕様を知らなければ「設計上の誤り」と「意図的な実装」を区別できません。
優先度の判断
技術的に問題があっても、現実のリスクとして重大かどうかを判断するには、攻撃者の視点・運用環境の理解・ビジネスインパクトの評価が必要です。AI は「危険かもしれない」と指摘はしますが、「今すぐ修正すべきか」の優先順位は人間が判断する必要があります。
新しい攻撃手法への対応
AI は学習データに存在しないまったく新しいタイプの攻撃手法に気づくことは苦手です。既知のパターンの延長線上での発見は得意ですが、未知の脆弱性クラスの発見は依然として人間の創造性が重要です。
コードのコンテキストと歴史の理解
「なぜこういう実装になっているのか」という背景を理解した上で、リファクタリングのリスクを評価したり、意図的なトレードオフを見抜いたりするのは人間の得意領域です。
AI と上手く付き合うことで仕事の質が上がります
AIコードレビューは「人間のエンジニアを不要にするもの」ではなく、エンジニアの能力を拡張するツールです。以下のような付き合い方を意識すると、実際の業務での効果が高まります。
AI を「最初のレビュアー」として使う
プルリクエストを出す前に、まず AI にコードレビューさせる習慣をつけると、ケアレスミスや典型的なバグを事前につぶせます。人間のレビュアーは AI が見つけられなかった「意図や設計の問題」に集中できるようになり、レビューの質が上がります。
AI の指摘を「ヒント」として扱う
AI の指摘がすべて正しいわけではありません。False Positive（誤検知）も多数あります。「AI がこう言ったから修正する」ではなく、「AI がこう指摘した、なぜそうなのか自分で確認する」というプロセスを踏むことで、自分自身のセキュリティ知識も同時に深まります。
大量のコードの「予備スクリーニング」に使う
OSS のコードレビューや依存ライブラリの安全性評価など、量が多すぎて人間だけでは網羅しきれない作業に AI を使うのは非常に有効です。AI が「ここが怪しい」と絞り込んだ箇所に人間の目を集中させることで、限られたリソースを効率よく使えます。
AI との「対話」でコードの理解を深める
「このコードに脆弱性はあるか？」と問うだけでなく、「このコードが攻撃者にどう悪用されうるか、シナリオを考えてほしい」「このパターンが危険な理由を詳しく説明してほしい」という使い方も有効です。AI との対話を通じて、自分自身のセキュリティレビュースキルが向上します。
まとめ
AI によるコードレビューは、長年見逃されてきたカーネルレベルの脆弱性を次々と発掘するほどの実力を持ち始めています。これはセキュリティの世界が大きく変わるターニングポイントです。
ただし、AI は万能ではありません。設計の意図・ビジネスロジック・優先度の判断は依然として人間の領域です。AI が「量と網羅性」を担い、人間が「判断と創造性」を担う——この役割分担を意識することで、セキュリティレビューの質を大幅に底上げできます。
「AI に仕事を奪われる」ではなく「AI と一緒に仕事の質を上げる」という視点で、まずは日々のコードレビューに AI ツールを取り入れてみることから始めてみてください。
参考リンク
