Elastic Securityで使うLLMはどう選ぶ？性能表の正しい読み方

Elastic Securityで生成AIを使うとき、どのLLMを選べばよいのでしょうか。

Elasticは、複数のLLMをElastic Securityのタスクで評価した「Large language model performance matrix」を公開しています。モデルを比較できる便利な資料ですが、Overall Score（総合点）の順位だけで選ぶと、使いたい機能に合わないモデルを選ぶ可能性があります。

本記事で使うモデル名、スコア、集計方法、「5以下はそのタスクに非推奨」という基準は、特記がない限り2026年8月26日時点のElastic公式性能表に基づきます。^{[^1]}

モデルや評価値は更新される可能性があるため、導入時には最新の公式表をご確認ください。

先に結論：モデル名ではなく、使いたい機能から選ぶ
性能表が評価する3つの能力
Overall Scoreだけでは判断できない
「自己デプロイ可能なモデルは使えない」は正確ではない
なぜ一般的なLLMランキングと結果が違うのか
1. Agent Builderは「実際に作業したか」も評価する
2. Attack Discoveryは「攻撃を正しくまとめられるか」を評価する
自己デプロイ可能なモデルは、同じモデル名でも結果が変わる
1. モデルファイルの容量と、実行に必要なメモリは同じではない
実際の選定手順
まとめ
補足：性能表の集計値を資料へ転記するときの注意
参考資料

先に結論：モデル名ではなく、使いたい機能から選ぶ

LLMは、すべての仕事で同じ性能を発揮するわけではありません。

たとえば、あるモデルがAttack Discoveryに向かなくても、Automatic Migrationでは高い性能を示すことがあります。「このモデルは使える／使えない」と一括りにせず、どの仕事に使えるかを見る必要があります。

性能表が評価する3つの能力

性能表の上位項目は、次の3つです。

能力	Elastic Securityで行う仕事	確認する場面
Agent Builder	アラート分析、脅威ハンティング、検知ルールやワークフローの作成など	SOC業務をAIエージェントに支援させたい
Attack Discovery	複数のアラートを関連付け、攻撃のまとまりや流れとして示す	大量のアラートから優先調査対象を見つけたい
Automatic Migration	他社SIEMの検知ルールをElastic向けに変換する	Splunkなどからルールを移行したい

Agent Builderは、さらに7つのサブ能力に分かれています。

Alert Analysis（アラート分析）
Entity Analytics（ホストやユーザーの分析）
Threat Hunting（脅威ハンティング）
Detection Rules（検知ルール作成）
Workflow Authoring（ワークフロー作成）
Triggering Workflows（ワークフロー実行）
Multi-Step Executions（複数ステップの実行）

Agent Builderの平均点が高くても、自分が使いたいサブ能力の点が低い場合があります。用途が決まっているなら、平均点より個別のスコアを優先します。

Overall Scoreだけでは判断できない

Overall Scoreは、次の3スコアの平均です。

Overall Agent Builder Score
Attack Discovery
Automatic Migration

この数値は、Elastic SecurityのAI機能全体で広く高い性能を持つかを見るには便利です。しかし、異なる仕事の平均なので、特定機能への適性は隠れてしまいます。

参照日時点の主なモデルを例に見てみます。比較の基準として表全体でOverall Scoreが最も高いClaude Opus 4.7と、Overall Scoreが高くても機能ごとに差がある例としてGemini 2.5 Flashを掲載しました。

公式表は、利用者が自分でデプロイできるモデルを「Open-source models」に分類しています。ただし、各モデルのライセンス条件は同じではありません。そのため、本記事では誤解を避けるために自己デプロイ可能なモデルと呼びます。下表の3モデルは、この分類でOverall Scoreが高い上位3件です。

モデル	Agent Builder	Attack Discovery	Automatic Migration	Overall
Anthropic Claude Opus 4.7	8.29	9.70	9.70	9.23
Google Gemini 2.5 Flash	5.86	9.50	9.81	8.39
OpenAI GPT-OSS 120B	5.14	3.00	9.40	5.85
Gemma 4 31B IT	7.00	2.80	7.50	5.77
DeepSeek V4 Pro	5.86	8.30	3.10	5.75

Gemini 2.5 FlashはOverall Scoreが8.39と高い一方、Agent Builderは5.86です。さらにサブ能力を見ると、Alert AnalysisとDetection Rulesはどちらも5.00で、Elasticの基準ではそのタスクに非推奨です。Overall Scoreが個別の弱点を隠す問題は、モデルの提供形態に関係なく起こります。

また、3つの自己デプロイ可能なモデルは、Overall Scoreだけを見ると5.75〜5.85と近い値です。一方、得意分野は大きく異なります。

GPT-OSS 120BはAutomatic Migrationが9.40ですが、Attack Discoveryは3.00です。
Gemma 4 31B ITはAgent Builderが7.00、Automatic Migrationが7.50です。
DeepSeek V4 ProはAttack Discoveryが8.30ですが、Automatic Migrationは3.10です。

つまり、「自己デプロイ可能なモデルの中でOverall Scoreが最も高いもの」を選ぶ方法は適切ではありません。Attack Discoveryを使うならAttack Discoveryの列、SIEM移行ならAutomatic Migrationの列を見るのが基本です。

「自己デプロイ可能なモデルは使えない」は正確ではない

性能表から読み取れるのは、「すべての主要機能で安定して高得点を取る自己デプロイ可能なモデルは、掲載モデルの中には見当たらない」ということです。

一方で、用途別には有力な候補があります。

Automatic Migration：GPT-OSS 120Bは9.40
Agent Builder：Gemma 4 31B ITは7.00
Attack Discovery：DeepSeek V4 Proは8.30

そのため、「自己デプロイ可能なモデルは使い物にならない」ではなく、用途による性能差が大きいため、機能ごとの選定が特に重要と表現するほうが正確です。

なお、Elasticの基準は「5以下はそのタスクに非推奨」です。「絶対に動かない」「利用価値がない」という意味ではありません。原文は「5 or below」なので、5.0ちょうども非推奨に含まれます。

なぜ一般的なLLMランキングと結果が違うのか

この性能表は、一般的な知識や文章作成能力を比べるLLMランキングではありません。Elasticは、模擬した侵入シナリオ、正解データ、ツール呼び出しを含む実行過程、モデル名を伏せたブラインド評価などを使い、Elastic Securityの業務における性能を評価しています。^{[^2]}

Agent Builderは「実際に作業したか」も評価する

Agent Builderの評価には「No tool call, no credit」という考え方があります。必要なツールを呼ばず、もっともらしい文章だけを返した場合は、根拠のない回答として10点中6点が上限になります。

たとえば、検知ルールやワークフローを作成するタスクでは、文面が正しそうかだけではなく、実際に作成、有効化、実行できたかまで確認します。

Attack Discoveryは「攻撃を正しくまとめられるか」を評価する

Attack Discoveryは、関連するアラートを一つの攻撃ストーリーとしてまとめ、関係するユーザーやホスト、MITRE ATT&CKとの対応などを示す機能です。^{[^3]}

評価では、各モデルに同じ約95件のアラートを渡し、その中に含まれる8つの独立した侵入を発見できるかを確認します。主な評価軸は次の4つです。

網羅性：8つの侵入をどこまで見つけられたか
正確性：ホスト、マルウェア、攻撃の流れなどを正しく説明したか
相関の品質：関連するアラートを正しくまとめたか
実用性：調査に使えるタイトル、概要、優先度を示せたか

Agent Builderとはタスクが異なるため、Attack Discoveryの評価ではツールを使いません。この違いも、同じモデルのスコアが機能ごとに大きく変わる理由の一つです。

自己デプロイ可能なモデルは、同じモデル名でも結果が変わる

性能表では、DeepSeek V4 ProがAttack Discoveryで8.30を記録しています。しかし、同じモデルを用意すれば、自社環境でも8.30を再現できるとは限りません。

結果には、次の条件も影響します。

確認項目	意味	結果への影響
モデルの配布形式	どの形式・精度でモデルを用意するか	精度、必要メモリ、対応ソフトウェアが変わる
量子化	重みを低い数値精度で保持する方法	必要メモリを減らせる一方、性能に影響する可能性がある
推論エンジン	LLMの回答生成を実行するソフトウェア	応答速度、同時実行数、GPUメモリの使い方が変わる
コンテキストウィンドウ	一度に扱える入力と出力の範囲	長いアラート情報を扱えるかが変わる
生成パラメーター	temperatureやmax tokensなど	出力のばらつきや、回答が途中で切れる可能性が変わる
ハードウェア	GPU、VRAM、RAMなど	実行の可否、速度、同時実行数が変わる

生成パラメーターの仕組みはHugging Face Transformersの公式ドキュメント、推論時の調整はvLLMの公式ドキュメントで確認できます。^{[^4][^5]}

量子化の方式と対応ハードウェアはさまざまで、方式によって圧縮率や精度への影響が異なります。^{[^6]}

Elasticは、自己デプロイ可能なモデルを運用する接続先として、本番環境またはエアギャップ環境ではvLLM、テスト環境ではLM Studioの手順を案内しています。エアギャップ環境とは、インターネットなどの外部ネットワークから分離した環境です。また、Attack Discoveryでは性能表に掲載されたモデルの利用を推奨しています。^{[^7]}

モデルファイルの容量と、実行に必要なメモリは同じではない

LLMは、学習で得た数値を「重み」としてモデルファイルに保持しています。モデルファイルの容量は、主に保存やダウンロードに必要なディスク容量を示します。

一方、実行時にはモデルの重みだけでなく、入力の長さや処理中のデータにもメモリを使います。そのため、「ファイルを保存できる」ことと「実用的な速度で安定して動かせる」ことは別です。モデルメモリの主な構成要素は、Hugging Faceの解説で確認できます。^{[^8]}

たとえば、量子化モデルを公開しているUnslothのDeepSeek-V4-Pro-0813-GGUFでは、Unsloth Dynamic 2.0の4-bit量子化UD-Q4_K_XLが850GBです。GGUFは、モデルの重みや設定情報をまとめ、配布・実行しやすくするファイル形式です。^{[^9]}

このモデルは総パラメーター数1.57兆で、1トークンの処理に使われるアクティブパラメーターは48B（480億）です。処理ごとに使う部分は一部でも、モデル全体の重みをファイルに保持するため、4-bitでも850GBになります。これは「850GBのディスクがあれば、そのまま実用的に動かせる」という意味ではありません。

Elasticの評価記事には、同じデータ、プロンプト、エージェント、スキル、ツールを使い、変更する変数をモデルだけにしたと説明されています。一方、モデルの数値精度、推論エンジン、ハードウェア、コンテキストウィンドウ、temperatureなど、各社の環境で結果を再現するための実行条件は記載されていません。

したがって、性能表のスコアは有力な候補を絞るために使い、最終的な判断は自社の実行構成とデータを使ったPoCで行います。

実際の選定手順

1. 使いたい機能を1つ決める

「Elastic SecurityでAIを使いたい」ではまだ広すぎます。まずは、次のように対象を1つに絞ります。

アラート分析を支援したい
Attack Discoveryで優先調査対象を見つけたい
Splunkの検知ルールをElasticに移行したい

2. 対応するスコアを見る

Attack DiscoveryならAttack Discoveryの列、検知ルール移行ならAutomatic Migrationの列を見ます。Agent Builderを使う場合は、必要なサブ能力まで確認します。

3. 5以下を非推奨の目安にする

これはモデル全体への評価ではなく、選んだタスクに対する目安です。別の機能で高得点なら、そちらの用途では候補に残せます。

4. 自己デプロイ可能なモデルでは実行条件を記録する

モデル名だけでなく、配布形式、量子化、推論エンジン、コンテキストウィンドウ、生成パラメーター、ハードウェアを記録します。再テストやモデル間の公平な比較がしやすくなります。

5. 自社に近いデータでPoCする

たとえばAttack Discoveryなら、関連するアラートと無関係なアラートを混ぜ、次の点を確認します。

関連するアラートを一つの攻撃としてまとめられるか
無関係なアラートを混ぜないか
攻撃の流れを正しく説明できるか
存在しない事実を追加しないか
同じテストを繰り返しても結果が安定するか

スコアは「絶対的な正解」ではなく、候補を絞るための手がかりです。最終判断には、本番に近い入力、データ量、失敗パターンを使った確認が必要です。

まとめ

Elastic SecurityのLLM性能表で最も大切なのは、ランキングではなく、自分が使う機能の列を見ることです。

Overall Scoreは全体像をつかむ参考値ですが、特定タスクの最終判断には向きません。自己デプロイ可能なモデルでは、モデル名が同じでも実行条件によって結果が変わるため、構成を記録したうえでPoCを行います。

最初に、次の一文を決めると選定しやすくなります。

Elastic Securityのどの機能を、どのようなデータで使いたいのか。

この問いを決めてから、該当スコアと自社PoCの結果を確認することが、失敗の少ないLLM選定につながります。

補足：性能表の集計値を資料へ転記するときの注意

参照日時点の表には、集計方法の説明と一部の記載値が一致しないように見える行があります。

公式説明ではOverall Agent Builder Scoreは7つのサブ能力の平均です。しかし、表示されたサブスコアを単純平均すると、次の3モデルでは掲載値と一致しません。サブスコアの並びは、Alert Analysis / Entity Analytics / Threat Hunting / Detection Rules / Workflow Authoring / Triggering Workflows / Multi-Step Executionsの順です。