3行でいうと

  • 数字を読むときは、モデル・パソコン・入力の長さ・比べた相手の4つをそろえる。
  • 誰が測ったかも見る。開発側の自社測定だけで「勝った」と判断しない。
  • 会話の点が高くても、道具を呼ぶ力は別。ある個人の測定では、国産8Bモデルが1回で正しく呼べた率は16.7％だった。
  • 量子化した版や設定で点は変わる。元のモデルの点がそのまま当てはまるとは限らない。

AIの記事には、数字がたくさん出てきます。「7.82点」「88.9％」「約2倍」。どれも立派に見えますが、何と何を、どんな条件で比べた数字なのかを読まないと、意味が変わります。指標の中身を公式の論文やページで確かめて、読み方をまとめます。

先に結論

数字を読むときは、次の4つをそろえます。

  1. モデル：同じモデルか。大きさ、版、量子化（数字を粗く丸めて小さくすること）の違いはないか
  2. パソコン：同じ機械か。GPUやメモリ、ソフトの版は同じか
  3. 入力の長さ：短い質問か、長い文書か
  4. 比べた相手：何と比べての「倍」や「勝ち」か

加えて、誰が測ったのか（ベンダー自身か、独立した第三者か）と、その試験が自分の仕事に似ているかを見ます。最後にチェックリストを付けました。

指標が何を測っているか

公式の論文やページで読めた範囲だけを書きます。

指標 何を測るか 読み取れた特徴
MMLU 57の分野の選択式の知識問題。数学、歴史、法律など 論文の概要に、得意不得意の偏りが大きく、道徳や法律では偶然に近い正答率のモデルもあった、とあります
JMMLU 日本語の知識問題。MMLUの一部の翻訳と、日本の学校科目から作った問題の組み合わせ Hugging Faceのデータの説明では、7,536問、56の課題。翻訳は機械翻訳のあと人が確認しています
MT-Bench 複数回のやりとりの自由な質問。採点は別のAI（GPT-4など）が行う 論文は、AIの採点者が人間の好みと8割超で一致した一方、位置・長さ・自己びいきなどの偏りがあると述べています
Nejumi リーダーボード 日本語のAIを、複数の試験で総合して並べる 運営はWeights & Biases Japan。報道によれば、第4版は知識、コード、ツール呼び出し、安全性などを含みます。総合点の計算式は、読めた記事には載っていませんでした
τ-bench AIが利用者と会話しながら、決められたルールのもとで道具を使う作業 会話の最後に、データベースの状態が正解と合うかで採点します
パープレキシティ 文章を、モデルがどれだけ予測できるか。小さいほどよい 文字の切り分け方が違うモデルどうしは、直接比べられません

補足を2つだけ書きます。Nejumi 4を紹介した報道には、従来のJMMLUでは多くのモデルが90％近くに達して差がつきにくく、より難しい版（JMMLU-Pro）を加えた、とあります（二次情報です）。試験は、モデルが賢くなると古くなります。また、Nejumiは1つの試験ではなく「試験の束」です。ページの本文は開けず、報道の説明にとどめます。総合点が高くても、自分に必要な試験の点が低いことがあります。

τ-benchは、1回成功したかだけでなく、同じ課題を何度やっても成功するか（pass^k）を見ます。論文によると、GPT-4oは課題の半分未満しか成功せず、小売の課題で8回続けて成功する率は25％を下回りました。

4つをそろえる：Splashの「倍率」

以前の記事（Splash）で、「倍率は比べる相手で変わる」と書きました。ここで中身を整理します。

Inco AIの自社の測定です。機械はM5 Pro（メモリ48GB）、モデルはQwen3.8-27B。公式ページでは、倍率は「測定した中で2番目に速かったエンジン」との比です。

条件 数字 倍率の相手
短い入力、生成の速さ 毎秒74トークン 次点の約2.0倍
32K入力、生成の速さ 毎秒54トークン 報道（Hack-Log）によれば、Ollamaの約2.8倍、oMLXの約1.9倍
4件を同時に処理 合計で毎秒170トークン 次点の約3.9倍
32Kの続きを再開、最初の1文字まで 282ミリ秒 報道によれば、oMLXの約7.3倍

同じ「Splashが速い」という話でも、2.0倍、2.8倍、1.9倍、3.9倍、7.3倍と、数字が並びます。入力の長さも、同時に処理する数も、相手も違うからです。

さらに、ネットで広まった「毎秒144トークン」は、27Bではなく別のモデル（35B-A3B）の数字でした。

そして、M6 Mac mini（メモリ32GB）の動画の実例では、毎秒25から15トークンでした。公式の毎秒74と、機械もモデルの状態（メモリや文脈）も違います。どちらかが間違っているのではなく、並べて比べてはいけない数字です。

:::

自社の測定と、独立した測定

LLM-jp-4のモデルカードには、日本語のMT-Benchの表があります。

モデル MT-Bench 日本語（10点満点）
LLM-jp-4 32B-A3B（thinking） 7.82
gpt-oss-20b 7.33
GPT-4o（2024年8月版） 7.29

モデルカードによると、採点役はgpt-5.4で、3回の推論と評価の平均です。つまり、開発した側（LLM-jp）が、自分で測った数字です。

言えること。この条件では、LLM-jp-4の点が、GPT-4oより0.5点ほど高い、ということ。

言えないこと。「LLM-jp-4はGPT-4oより賢い」とまでは言えません。理由は3つあります。

  • 採点役のAIの癖が点に混ざります（MT-Benchの論文が認める偏りです）。
  • 同じ表の別の試験（指示追従）では、前の記事のとおり、GPT-4oのほうが上でした。
  • GPT-4oは2024年の版です。比べる相手を、有利に選べてしまいます。

自社の測定が悪い、という話ではありません。再現できるように条件を公開していて、読む側が確かめられるのは、むしろ誠実です。ただ、それだけで「勝った」と判断しないほうがよい、ということです。

独立した測定の例は、SwallowプロジェクトのLLMリーダーボードです。自分たちで測り、reasoningモデルの設定（on/high/medium）も表示しています。ただし、僕らが読んだ説明ページに、LLM-jp-4は載っていませんでした。更新で変わっているかもしれません。

もう1つ、開発元の「自己申告」の例です。Qwen3.8-27Bのモデルページには、SWE-bench Pro 61.7など、たくさんの数字が出ています。ページには、温度などの設定や、256Kの文脈で測ったことが書かれています。これは4ビットに縮めて、家庭のMacで動かした数字ではありません。

ベンチマークと、実際の仕事のずれ

もっとも大きな落とし穴は、試験が、自分の仕事とずれていることです。

前の記事（ローカルのコーディングエージェント、gpt-oss）で、日本語のツール呼び出しの実測を紹介しました。ai-local-labという個人メディアの測定です。

モデル 1回で正しく呼べた率 続けて呼べた率
gpt-oss 20B 88.9％ 44.4％
Swallow 8B 16.7％ 0％
LLM-jp-4 8B（thinking） 16.7％ 0％

LLM-jp-4（32B-A3B）は、MT-Benchで高得点でした。一方、道具を呼ぶ試験では、8B版が16.7％でした。モデルの大きさが違うので、直接の矛盾ではありません。それでも、会話がうまいことと、道具を正しく呼べることは、別の力だと分かります。

ただし、この数字にも読み方の注意があります。

  • 試行は、1回で呼ぶ試験が6種類を3回ずつ、計18回です。16.7％は3回の成功、88.9％は16回の成功です（筆者の計算です）。1回の成功が約5.6ポイントに当たります。
  • 測定はRTX A6000（NVIDIA）、Ollama 0.31.1、4ビット、温度0.7です。Macでの数字ではありません。
  • 20Bと8Bの比較です。国産か米国製かの差とは言い切れません。
  • 筆者自身が、小規模で方向を見る目安だと書き、チャットの形式（テンプレート）の実装に左右される、とも断っています。
  • 名前が似ていても、τ-benchの点数ではありません。独自の小さな試験です。

つまり、「国産は道具を呼べない」と読むのではなく、「この条件では、8Bの国産モデルは、ほとんど道具を呼べなかった」という1件の測定と読みます。それでも、自分の仕事がエージェント（道具を使う作業）なら、MT-Benchの7.82より、この16.7％のほうが関係の深い数字です。

試験の作り方の問題もあります。Shisaのブログは、日本語の評価ツール（llm-jp-eval）で、日本語で答えただけで0点になる例を挙げています。点の低さが、能力ではなく採点の仕組みのせいのこともあります。別の開発者の指摘で、古い版の話かもしれません。

同じモデルでも、量子化や設定で変わる

家庭のパソコンで動かすモデルは、多くが量子化された版です。元のモデルの点が、そのまま当てはまるとは限りません。

量子化の影響を測るのが、パープレキシティです。llama.cppの導入時の測定（7Bのモデル、wikitext）です。

形式 パープレキシティ 元との差（筆者の計算）
元（F16） 5.9066 －
Q4_K_S 6.0215 約+1.9％
Q2_K 6.7764 約+14.7％

4ビットなら、約2％の悪化です。2ビットで約15％悪化しました。

ただし、この数字は、「元のモデルとの近さ」を見るものです。コードや道具の呼び出しで困るかどうかは別の話です。量子化版を配るUnslothも、パープレキシティやKLDは調整用のデータの影響を強く受けるので、誤解を招きうる、と書いています。小さいほうが、パープレキシティが悪くても、実際の課題では勝った例を挙げています。これは自社の測定です。

設定でも変わります。Qwen3.8-27Bのモデルページは、思考モードでは温度1.0などの設定で測った、と書いています。ふだんの会話で同じ設定とは限りません。

点が動く場所は、モデルの形（量子化）、温度、思考モード、入力の長さ、チャットの形式です。パープレキシティが良くても、自分の課題で良いとは限りません。

記事の数字を見たときの5つの問い

ここからは見立てです。僕らが、数字を読むときに使う問いです。

  1. 何のモデルで、どんな形で動かした数字か。元の16ビットか、量子化版か。大きさと版は同じか。
  2. どのパソコン、どんな入力の長さか。自分の機械と違えば、並べて比べない。
  3. 誰が測ったか。比べた相手は何か。自社の測定か、独立した測定か。「倍」は、何に対する倍か。
  4. 何を測った試験か。自分の仕事に似ているか。知識の問題、会話の採点、道具の呼び出しは、別の力。
  5. 何回測ったか。再現できる条件が書かれているか。18回なら、1回の成功が5ポイント以上動く。

この5つを、記事の数字に当てはめてみてください。多くの数字は、「この条件では、こうだった」という1件の観測に変わります。それは、価値がないという意味ではありません。使い道が、はっきりするということです。

この記事の数字は、この記事は、測ったものではありません。M6 Mac miniでの実測は、これから足していきます。

出典

更新履歴

  • 2026年10月25日 書き方を直しました。
    • 前：運営者がやっていないと読める書き方 → いま：主語を記事にして、「この記事は、実際にやって確かめた記録ではありません」と書きました。運営者が使っているものを、使っていないと読ませないための直しで、内容や数字は変えていません。