Jev の代わりにローカル LLM は使えるか — Ollama 0.35 の判断モデル（nimble・tev1）を日本語で測った。判別の力は Jev とほぼ同じで課金 0。ただし合格線には届かず、配布のままでは長い文章を断る

CONTENTS目次（11）

1. Ollama 0.35 の判断モデルとは
2. 測った環境
3. 結果 1: 題材選びでは、判別の力が Jev とほぼ同じだった
4. 結果 2: 日本語の校閲では、本物の指摘の取りこぼしが多い
5. 配布のままでは長い文章を断る。上限は配布元の既定値だった
6. 使用量は問いの数だけ数えるが、計算は共有されている
7. 4 ビット版: NVFP4 は Windows では使えず、q4_K_M は判定が 4 件に 1 件変わった
8. いまの Ollama を上げずに 0.35 を試す
9. 測っていないこと
10. まとめ
11. 出典

Ollama 0.35 の判断モデルとは

2026年9月29日（日本時間）に出た Ollama 0.35.0 で、「判断モデル」を動かす API（/v1/systemone）が入った。文章を書かせるのではなく、文章（state）と問い（questions）を渡すと、選択肢の確率・はい／いいえの確率・段階の点数を返す。TypeSafe AI の Jev と同じ形で、Jev は API でしか使えないのに対し、こちらは手元の GPU で動く。

9月に Jev を、IVYXON の記事の校閲と記事の題材選びの 2 つの仕事で測っていた。どちらも「その後ろの LLM の審判を呼ぶ回数を減らす前段の門」として採るかを決めるためで、Jev は採らなかった。今回は、同じデータ・同じ合格線のまま、相手だけをローカルの判断モデルに替えた。

測った環境

結果 1: 題材選びでは、判別の力が Jev とほぼ同じだった

記事の題材を探すために集めたニュースの見出し 9,543 本に、「題材にする価値があるか」を確率で答えさせた。正解は、そのうち実際に人に回す候補に残った 330 本（3.5%）。合格線（取りこぼしを 5% 以内にしたまま 7 割以上を減らせること）は、Jev を測る前に決めたもの。

nimble は Jev とほぼ同じ判別の力を、課金 0 で出した。それでも減らせる量は線に届かず、前段の門としては Jev と同じく採れない。小さいモデルほど弱く、tev1 0.8B は、見出しを細かく見る別の問い（数えられるか・反証できるかなど）の答えがほぼ全部「当てはまらない」に倒れた。使えたのは「記事をどの棚に置くか」の 5 択で、nimble は Jev と同じ水準だった。

9,543 本を同時 4 本で流すと 43 分で終わり、9,543 本すべてに確率の答えが返った（エラーは 0 件）。時間の Jev は東京から API で測った値。

結果 2: 日本語の校閲では、本物の指摘の取りこぼしが多い

IVYXON の記事 164 本に、6 つの観点（通じない専門語・売買を勧めるような書き方・係り受け・直訳調・表記のゆれ・定義の無い略語）で「直すべき所があるか」を確率で答えさせた。正解は、既存の LLM の審判と Jev の判定が食い違った所から 60 件を抜いて人が裁定し、全体に戻したもの。配布のままのモデルは長い記事を断る（下の節）ので、表はローカルの 3 本とも上限を 32,768 トークンにした版で、164 本すべてを測った値。

4 本とも、事前に決めた線のうち 3 つ以上を欠いた。nimble は本物の指摘を拾う率が Jev より 27 ポイント低い。tev1 0.8B の 98.6% は、ほぼすべてに「直すべき」と答えた結果で、出した指摘のうち本物は 21.3%（判定全体に占める本物の割合とほぼ同じ）しかない。

表の指標の意味: 「審判を呼ばずに済んだ記事の割合」は、取りこぼしを 5% 以内に抑えたまま、6 観点すべてで「直す所なし」と言えた記事の割合（その記事は後ろの審判を呼ばずに済む）。ECE は、既存の LLM の審判の判定を基準にした確率のずれで、「0.7 と答えたものの 7 割が直すべき所だったか」を見る（Jev のときと同じ測り方。小さいほどよい）。「直す前と直した後」は、人が実際に直した 15 か所で、直す前を「直すべき」、直した後を「問題なし」と言えた組の数。判定の時間の Jev は東京から API で測った値。

配布のままの nimble が受け付けた 125 本だけで比べても、本物の指摘を拾えた率は 59.3%（同じ 125 本の Jev は 80.0%）で、結論は変わらない。上限を上げた版と配布の版は、同じ 125 本でも確率がわずかに違った（750 の判定で差は平均 0.008、判定が入れ替わったのは 12 件）。配布の版が断った長い 39 本に限ると、上限を上げた nimble は 51.4%（Jev は 91.2%）。短い 125 本の 58.7% より低いが、本数が少なく、長さのせいとまでは言えない。上限を上げた nimble で 164 本を 1 本ずつ回すと、1 本（6 問）の時間は中央値 2.9 秒、最長 9.3 秒だった。

正解の作り方には偏りがありうる。人が裁定したのは Jev と既存の審判が食い違った所だけで、両者が一致した判定は正しいとみなしている。両者がそろって見逃した所をローカルのモデルだけが拾っても、誤りとして数えられる。ただし nimble と Jev の差（取りこぼし 91 件と 35 件）をこれだけで説明するには、両者がそろって誤った判定が 50 件以上要る。食い違いの裁定では 60 件中 52 件で既存の審判が正しかったので、偏りだけでは説明しにくい。測る前の取り決めでは、差が大きいときは食い違った判定を人が裁定し直すことにしていたが、今回はしていない。

配布のままでは長い文章を断る。上限は配布元の既定値だった

校閲の記事を配布のままのモデルに渡すと、長いものは次のように断られた。

HTTP 400  {"error":"prompt 0 has 8551 tokens; expected 1–8194 (input is never truncated)"}

この上限はモデルの作りではなく、配布元がモデルに付けた既定値（num_ctx）だった。/api/show で見ると nimble は num_ctx 8194、tev1 は num_ctx 2050 で、モデル自体が扱える長さ（qwen35.context_length）はどちらも 262,144 トークンある。Ollama のモデルのページも、どのタグにも「256K context window」と書いている（2026年10月2日時点）。数えられるのは文章だけでなく、文章とすべての問いを合わせた長さだった。同じ 10,600 字の記事でも、問い 1 つなら 7,970 トークンで通り、問い 6 つでは 8,551 トークンで断られた。

リクエストに "options": {"num_ctx": 32768} を足しても効かず、同じ 400 が返った。上限を上げるには、既定値を書き換えた派生モデルを作る。次の 2 行を Modelfile として保存し、ollama create nimble-32k -f Modelfile とする。

FROM nimble
PARAMETER num_ctx 32768

派生モデルは重み（9.5GB）を元のモデルと共有し、違うのは設定だけなので、ディスクはほとんど増えない。nimble を 32,768 にした版も、VRAM 9.3GB にすべて載った。配布元が短い値を付けた理由は書かれていない。学習した長さに合わせた可能性もあるので、長い記事での成績は、上の校閲の節で分けて示した。

使用量は問いの数だけ数えるが、計算は共有されている

応答の usage.input_tokens は、問いの数だけ文章を数える。10,600 字の記事（上限を上げた nimble）で、問いの数だけを変えて 2 回ずつ測った。先頭に毎回ちがう 8 文字を入れて、前のリクエストの計算を使い回せないようにした。

数えられる入力は問いの数にほぼ比例して増えるが、時間は 6 問でも 1 問の 1.4 倍だった。文章とすべての問いを合わせた前置きを、問いごとに計算し直してはいないとみられる。校閲では usage の入力が Jev の約 4 倍に数えられたが、手元の GPU の時間をこの数から見積もると大きく外れる。

4 ビット版: NVFP4 は Windows では使えず、q4_K_M は判定が 4 件に 1 件変わった

nimble には q8_0 のほかに 4 ビットの版がある。NVFP4 版（nimble:9b-nvfp4・6.9GB）は Apple の MLX 用の版で、Windows の Ollama 0.35 では判断の API が「not supported by System One; use a local Nimble or Tev GGUF model」と断った。モデルのページの一覧には無いが、nimble:9b-q4_K_M（GGUF）は取り込めて動いたので、配布のままの q8_0 が受け付けた 125 本（750 の判定）で比べた。時間は 1 本（6 問）を 1 本ずつ回した中央値。

同じ q8_0 をもう 1 回回すと、750 の確率がすべて 1 回目とまったく同じ値で返った。q4_K_M は判定の 24% が q8_0 と変わり、確率は平均 0.10 低く出た。「直すべき」と言う回数が減ったので、判定が正しかった割合は上がったが、本物の指摘を拾う率は 59.3% から 44.0% に下がった。速さは変わらなかった。取りこぼしを減らしたい前段の門に使うなら、q4_K_M にする理由は無い。上限を 32,768 にしただけの版も 750 のうち 12 の判定が変わった。同じ版の揺れは 0 だったので、これは設定を変えたこと自体による差になる。

いまの Ollama を上げずに 0.35 を試す

Ollama は版を上げると、それまで測った速さの基準が変わる。今回は Windows 用の zip（ollama-windows-amd64.zip）を別のフォルダに展開し、別のポートで立てた。

set OLLAMA_HOST=127.0.0.1:11435
set OLLAMA_MODELS=D:\ollama035\models
set OLLAMA_NUM_PARALLEL=4
D:\ollama035\bin\ollama.exe serve

モデルは別の窓で set OLLAMA_HOST=127.0.0.1:11435 としてから D:\ollama035\bin\ollama.exe pull nimble。OLLAMA_NUM_PARALLEL=4 は、見出しを同時 4 本で流すため。GPU は 1 枚なので、本体の Ollama にモデルが載っていないことを確かめてから測った。

測っていないこと

• ほかの判断モデル（shisa-de-1・Kev・Laya など）。日本語向けの shisa-de-1 は、Ollama の公式の一覧には無い（2026年10月2日時点）
• 英語の文章。今回は日本語だけ
• 食い違った判定の人による裁定のやり直し（上の「正解の偏り」を確かめるもの）

まとめ

• Ollama 0.35 の判断モデル nimble 9B は、日本語の題材選びで Jev とほぼ同じ判別の力（AUC 0.758 対 0.759）を、課金 0・1 件 0.29 秒で出した（2026年10月2日時点）
• それでも、前段の門として事前に決めた線（減らせる量 70%・本物の指摘を拾う率 95%）には、Jev と同じく届かなかった
• 配布のままでは入力の上限が短い（nimble 8,194・tev1 2,050 トークン。文章とすべての問いの合計）。上限は配布元の既定値で、Modelfile の PARAMETER num_ctx で上げられる。リクエストの options では変わらない
• usage の入力は問いの数だけ数えられるが、時間は 6 問で 1 問の 1.4 倍だった。GPU の時間を usage から見積もると大きく外れる

出典

• Ollama 0.35.0（判断モデルと /v1/systemone）: https://github.com/ollama/ollama/releases/tag/v0.35.0
• Ollama の発表（Jev と同じ形の判断モデル）: https://ollama.com/blog/ollama-now-supports-jev-style-decision-models
• nimble（Bespoke Labs）: https://ollama.com/library/nimble
• tev1（Together AI）: https://ollama.com/library/tev1
• Jev（TypeSafe AI）: https://typesafe.ai

← 検証ノートの一覧へ

この記事は、手元の機材で行った測定をもとにした一般的な技術情報の提供を目的としており、特定の製品・ソフトウェアの購入や利用を推奨・勧誘するものではありません。数値は 2026年10月2日（Jev は 2026年9月19日・21日）の測定で、モデル・ソフトの版・設定・機材・データによって変わることがあります。