ここ数年、AIモデルを選ぶ際には、ベンチマークスコアの高いものを探したり、なじみのあるプロバイダーを選んだりするのが一般的でした。
どのAIモデルが「最良」かという議論は、AIセキュリティ研究者の間でSNS上の定番の話題になりました。しかし、脆弱性検出にAIを活用しようとするセキュリティチームにとって、そうした指標だけではもはや不十分です。
モデルの素の性能は、判断材料の一部にすぎません。チームが知るべきなのは、アナリストをノイズで埋もれさせることなく、実際の脆弱性を見つけられるかどうかです。
大規模なコードベース全体でセキュリティテストを実施する場合は、コストも重要になります。
機密性の高いコードがどこで処理されるのか、プロバイダーのポリシー変更によって継続利用に支障が出ないかも、組織は考慮しなければなりません。
そうなると、より有益な問いは、汎用リーダーボードで首位に立つモデルはどれかではありません。アプローチ全体が、組織にとって信頼できる結果を出せるかどうかです。
つまり、モデル単体ではなく周辺のワークフローも含めて評価し、その結果できあがるシステムが組織のセキュリティ要件に合致するかを見極める必要があります。
モデルの利用料が安くても、総コストが低いとは限らない
安全でない直接オブジェクト参照（IDOR）の脆弱性を例に考えてみましょう。このアクセス制御の欠陥により、ユーザーは本来アクセスや変更が許されていないリソースを操作できてしまいます。IDORは、新人のペネトレーションテスターが最初に見抜き方を学ぶ脆弱性の一つであることが多いものの、一見単純に見えるぶん、誤解を招きやすい面があります。
IDORの検出には、明らかに危険な関数を見つけるのではなく、文脈を踏まえた推論が必要です。モデルは、誰がそのリソースにアクセスすべきかを理解したうえで、必要な認可チェックが欠けていないかを判断しなければなりません。
SemgrepのIDOR脆弱性検出ベンチマークは、オープンソースのコードベースに存在する実際の脆弱性を対象に、各モデルをテストするものです。検出性能は適合率（precision）と再現率（recall）で測定され、両者のバランスをとったF1スコアが総合的な品質の指標となります。Semgrepは、確認された脆弱性1件あたりのコストも追跡しています。
最近のある実行では、中国のZ.aiが開発したGLM-5.3は、F1スコア23.8%を、真陽性1件あたり0.15ドルで達成しました。Claude Opus 4.8のF1スコアは23.6%とほぼ同じでしたが、真陽性1件あたりのコストは1.04ドルでした。このテストでは、総合的な検出品質が同程度であるにもかかわらず、コストには大きな差が出たことになります。
この差は、アプリケーションセキュリティチームが大規模なコードベースをレビューする場合や、新しい変更を頻繁にテストする場合には、無視できないものになり得ます。ただし、価格だけでGLM-5.3が優れた選択肢になるわけではありません。同じテストでの再現率はわずか13.9%で、データセットに含まれる既知のIDORの大半を見逃していました。
GLM-5.3は、前世代のGLM-5.2よりも成績が悪化しました。Semgrepの研究者は、この差が実際の性能低下なのか通常のテストのばらつきなのかを判断するには、追加の実行が必要だと注意を促しています。
結局のところ、真陽性1件あたりのコストが意味を持つのは、組織が求める検出性能を満たしている場合に限られます。脆弱性の見逃しが多すぎたり、モデルの限界を補うためにアナリストが大幅に多くの時間を費やしたりするのであれば、推論コストが安くてもほとんど意味がありません。
総コストには人間によるレビューも含まれる
誤検知は、もう一つの問題を浮き彫りにします。総合スコアが似たモデルでも、検出結果を検証するエンジニアにかかる作業負荷は大きく異なる場合があります。
Semgrepによる別の Kimi K3のベンチマークは、このトレードオフを示しました。同じガイド付きプロンプト設定を用いた場合、KimiのF1スコアは34.0%で、GLM-5.2の34.5%、Claude Opus 4.8の34.3%に近い数値でした。しかし、適合率はGLM-5.2が86.3%、Claude Opus 4.8が91.0%だったのに対し、Kimiは68.4%でした。その結果、エンジニアはKimiの検出結果のうち、より多くを調査したうえで誤検知として退けなければなりませんでした。
リポジトリ単位の結果からは、別の懸念も浮かび上がりました。ベンチマーク内で最大のエンタープライズ型リポジトリでは、KimiのF1スコアは平均でおよそ6%にとどまり、GLMや最先端モデルは平均約20%でした。単一のリポジトリだけでは、コードベースの規模が成績低下の原因だとは断定できません。それでもこの結果は、総合スコアだけに頼らず、自組織に近い環境でモデルをテストすべき理由を示しています。
AI支援型セキュリティの真のコストは、モデルの利用料にとどまりません。システムの運用に必要なインフラや、それを支えるエンジニアリングの工数も見込む必要があります。
脆弱性の見逃しも潜在的なコストとなりますが、これはプロバイダーの料金表には載りません。こうした要素を合わせて初めて、そのシステムが実用に耐えるかどうかが決まります。
モデルは構成要素の一つにすぎません。モデルへの情報の渡し方や分析の進め方を左右する周辺のハーネスも、セキュリティ性能に大きく影響します。
同じベンチマークセットでは、GPT-5.6 Solの再現率が、ガイド付きプロンプトでは25%だったのに対し、Semgrepのマルチモーダルハーネスでは73%に上昇しました。基盤となるモデルは同じでも、周辺のシステムが変わるだけで結果は大きく変わったのです。
セキュリティ責任者にとって、この違いは評価プロセスそのものを変えるものです。製品がどのモデルを使っているかを知るより、代表的なコードに対してシステム全体がどう機能するか、そしてその出力がセキュリティチームにどれだけの作業を生むかを把握するほうが、はるかに有益です。
地理的要因が判断を変える
ここにはもう一つ注目すべき点があります。有力な選択肢は、米国の最先端ラボだけから生まれているわけではありません。
たとえばGLM-5.2はオープンウェイトで、組織がダウンロードして自社のインフラ上で運用できます。SemgrepのテストではIDORベンチマークでClaudeを上回り、検出した脆弱性1件あたりのコストは約0.17ドルでした。
機密性の高い知的財産を扱う組織や、厳格なデータ要件のもとで運用する組織にとっては、コードがどこで処理されるかが、ベンチマークの性能と同じくらい重要になる場合があります。自社環境内で動作するオープンウェイトモデルは、外部プロバイダー経由で利用するクローズドモデルとは、セキュリティやガバナンスの面で異なる選択肢となります。
レジリエンス（回復力）も重要です。プロバイダーはモデルの提供状況や価格を変更でき、顧客にはほとんど制御できません。アクセスに関する方針も、時間とともに変わる可能性があります。重要なセキュリティワークフローを単一のプロバイダーに依存して構築することは、その外部依存を受け入れることを意味します。
だからといって、海外製モデルやオープンウェイトモデルを無条件に認めてよいわけではありません。組織は、モデルの出自や、その挙動がセキュリティ業務に使えるほど信頼できるかを、引き続き評価する必要があります。導入方式が自社のセキュリティ要件を満たすかどうかも見極めなければなりません。原産国は能力を判断する便利な目安にはなりません。これは、知名度のある米国ブランドだからといって、そのモデルが適切だとは限らないのと同じです。
GLMやKimiのようなモデルの品質向上は、セキュリティチームに貴重なものをもたらします。交渉力と選択肢です。
ブランドではなく、実際の業務をベンチマークせよ
あらゆるアプリケーションセキュリティプログラムに通用する、唯一の最良AIモデルが存在する可能性は低いでしょう。
幅広い脆弱性の発見を重視するチームは、再現率により重きを置くかもしれません。アラートの量に悩むチームであれば、適合率を優先する場合もあります。
厳格なデータレジデンシー要件を抱える組織は、セルフホスティングを優先する可能性があります。一方、大量のコードをレビューするチームは、確認された検出結果1件あたりのコストを重視するでしょう。
有効な評価は、代表的なコードベースから始まります。システムが扱うと想定される最大規模のリポジトリも含めるべきです。チームは適合率と再現率を測定し、どの脆弱性が見逃されているかも調べる必要があります。コストの算出にあたっては、システムの運用に必要なリソースに加えて、検出結果のレビューにかかる工数も考慮しなければなりません。
テストでは、モデル単体で評価するのではなく、モデルを取り巻く実際の環境を反映させることも欠かせません。こうした評価は、技術やプロバイダーの提供内容が変わるたびに繰り返す必要があります。
アプリケーションセキュリティの責任者にとって、モデル選定はリーダーボードで決めるものではなく、エンジニアリングとしての評価に近いものであるべきです。
最も知名度の高いモデルが、結果的に正解となることもあるでしょう。ただしそれは、他者のベンチマークの上位に名前が載っているからではなく、組織の制約の下で最良のセキュリティ成果を出せるからであるべきです。
AIモデルは、コードやインフラのセキュリティ上の弱点を見つける手段の一つにすぎません。脆弱性検出のほかのアプローチを比較するには、 おすすめの脆弱性スキャンツールのガイドをご覧ください。
翻訳元: https://www.esecurityplanet.com/news/defining-best-ai-model/
