LLMを導入しても、何を基準に良し悪しを判断すればよいか迷う場面は少なくありません。

この記事では、InfoWorldが2026年6月に公開した解説をもとに、LLMとエージェントの評価に使える33の指標とベンチマークを整理します。性能・品質・エージェント運用・安全性・汎用ベンチマークの5領域に分け、実務で何を測る指標かを解説します。

この記事でわかること

  • LLMの応答速度やコストを測る9つの運用指標
  • 幻覚やバイアスなど品質・信頼性を見る指標
  • エージェント評価と安全性テストの見方
  • GSM8KやSWE-benchなど主要ベンチマークの位置づけ

なぜ評価指標が必要か

「測れないものは管理できない」という考え方は、LLM運用にも当てはまります。モデル選定、本番投入、エージェント設計のいずれでも、数値やベンチマークがなければ改善の方向が定まりません。

InfoWorldのPeter Wayner氏は、LLMとエージェント向けの統計的指標はまだ発展途上だとしつつ、設計者や利用者が実際に参照する指標を33個に整理しています(参考)。単一スコアで判断するのではなく、用途に応じて複数の軸を組み合わせることが前提です。

応答速度とコストを測る9指標

リアルタイム対話や大量リクエストを扱う場合、まず速度とコストの指標を確認します。

Time to first token(最初のトークンまでの時間)は、応答が始まるまでの待ち時間です。UI設計の知見どおり、数秒の遅延でも利用者の注意は別タスクに移りやすく、対話型アプリでは重要な指標になります。

Time per output token(出力トークンあたりの時間)は、応答全体の所要時間をトークン数で割った平均速度です。プレフィル(入力処理)後のデコード段階では一定のペースで出力されることが多い一方、エージェントが計画やツール呼び出しを挟むと速度は変動します。

Tokens per secondはその逆数で、パイプラインの段階ごとに別々に報告されることもあります。Throughput(requests per minute)は同時利用環境向けで、複数プロンプトを並列処理する新しいパイプラインの効率測定に使われます。

Error rateはレート制限、タイムアウト、モデルの拒否応答など、回答に至らなかった割合です。カテゴリ別に集計すると、障害の原因切り分けに役立ちます。

Token efficiencyは、最終出力に現れない内部トークンも含め、結果を得るまでに消費したトークン量を測ります。エージェントの推論や計画が増えるほど効率は下がり、ランニングコストの目安になります。

Tail latencyは平均応答時間だけでは見えない「たまに極端に遅い」ケースを追います。自律走行の制御指令のように、たまの遅延が致命的な用途では必須の指標です。

Total cost of ownership(TCO)は、API利用料だけでなく、自前GPU・電力・減価償却を含むトークン単価の試算です。需要とGPU利用率で大きく変わります。

Parameters(パラメータ数)はモデル名の「70B」のように、学習済み変数の規模を示すおおよその目安です。大きいほど表現力は増えやすい一方、推論に必要なGPUメモリも増えます。ただしアーキテクチャの進化により、少ないパラメータで高い性能を出すモデルも増えています。

品質と信頼性を測る指標

速度だけでは不十分です。出力の正確さとリスク管理の指標を並行して見ます。

Hallucination rate(幻覚率)は、要約が元文書とどれだけ乖離するかを別モデルで採点する方法や、TruthfulQA・HaluEval・QAFactEval・VectaraのHHEMなどのベンチマークで測ります。

Toxicity and bias scoresは、有害表現や偏りの検出です。定義が難しい領域ですが、Granica ScreenやPerspective APIなどのツールで明らかな問題を拾います。

PII leakageは、クレジットカード番号のような個人識別情報が出力に漏れるリスクを測ります。学習データからPIIを除去する前処理も、モデル提供者の基本対策です。

Semantic similarity and concisenessは、正解例とベクトル埋め込みで比較し、回答の簡潔さやばらつきを評価します。BERTScoreが代表例です。

Grounding scoreはRAG(検索拡張生成)で、検索結果にどれだけ忠実に答えているかを測ります。RAGAS、TruLens、ARES、RGB、HaluEval、HalluHardなどが使われ、「context adherence」「faithfulness」など別名で呼ばれることもあります。

Model variabilityは温度(temperature)設定による回答のばらつきです。雑談ボットでは自然さに寄与しますが、医療や法務では信頼を損ないます。

Format compliance rateはJSONやCSVなど、厳密な形式出力の成功率です。複数LLMを連携するエージェント基盤では欠かせません。

Instruction followingは「300語ちょうど」「韻を踏む詩」など、検証しやすい指示への従順度です。IFEval、FollowBench、BFCL(Berkeley Function Calling Leaderboard)が該当します。

Prompt sensitivityは、意味が同じ別表現のプロンプトで結果がどれだけ変わるかを測ります。PromptSEやProSAが代表例です。

エージェント運用を測る指標

ツール呼び出しや計画を行うエージェントでは、単発の回答品質に加え、行動全体の指標が必要です。

Tool-calling accuracyは、MCP(Model Context Protocol)ゲートウェイなど外部ツールを正しく選べるかを測ります。BFCLが代表的なベンチマークです。

Subgoal success rateは、エージェントの計画を部分目標ごとに分解し、各ステップの成功率を追跡します。

Plan stabilityは、実行中に計画を変更する頻度です。高い変更率は柔軟性の表れにも、計画力不足の表れにもなり得ます。

Self-correction scoreは、誤りを自ら認識して修正できるか、「本当に正しいですか?」と促された後の訂正も含めて測ります。

安全性を測る指標

本番投入前に、悪用耐性とコンプライアンスリスクを確認します。

Jailbreak resistanceは、物語設定などで制限を回避させる攻撃への耐性です。JailbreakBench、AgentHarm、Tele-AI-Safetyが評価に使われます。

Prompt injection vulnerabilityは、外部データやスキル経由で悪意ある指示を混入させる攻撃への脆弱性です。Skill-InjectやSPIKEEが既知の攻撃ベクトルでテストします。

Copyright infringement scoreは、学習データの文言をそのまま再現するリスクを測ります。CopyrightCatcherやDE-COPが検出ツールとして挙げられています。

汎用ベンチマークと価格

特定機能ではなく、総合能力を比較するベンチマークも7つ掲載されています。

RULERは長文コンテキストから情報を取り出す能力を測り、針の数や干し草の山のサイズを変えたNIAH(needle-in-a-haystack)テストを拡張したものです。

GSM8Kは小学校レベルの多段階算数問題8,500問で、推論チェーンの構築力を評価します。

GPQAは大学院レベルの科学問題で、非専門家が誤答しやすい「Google-proof」な設問を集めています。

MMLU-Proは生物学・化学・経済・法学など12,000問超の科学知識を横断的にテストします。

MBPPはGoogleが作成したPython入門問題集で、問題文・正解コード・テストケースのセットで実装力を測ります。

SWE-benchは実在するPythonプロジェクトのIssueとPull Requestから数千件の課題を抽出し、ソフトウェア工学の実務力を評価します。SWE-Bench+、SWE-Bench Verified、SWE-Bench Proへと拡張されています。

LMSYS Chatbot Arenaは固定テストセットではなく、同一プロンプトを複数モデルに渡し人間が勝敗を選ぶ動的評価です。対戦結果からチェスのEloレーティングに似た順位が算出されます。

最後にPrice(価格)です。InfoWorldの記事は「不動産で立地・立地・立地と言われるように、AIでも価格は極めて重要」と述べています。安価なモデルでも幻覚が多ければ逆効果です。用途に合った「雰囲気」や品質を満たすモデルに、適切なコストを払う判断が求められます。

実務での使い方

33指標を一度に追う必要はありません。チャットボットならTime to first tokenとHallucination rate、RAGアプリならGrounding scoreとPrompt sensitivity、コーディングエージェントならSWE-benchとTool-calling accuracyを優先する、といった選び方が現実的です。

ベンチマークスコアはリーダーボードの数字だけで決めず、自社のユースケースに近いプロンプトで再評価してください。エージェント運用では、Subgoal success rateやPlan stabilityを本番ログから継続計測し、単発ベンチマークとのギャップを埋めるのが定着への近道です。