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