Ollamaの–askは速い？〜3種の判定にかかる時間をRTX 3090で測った

2026年11月7日

問い合わせを「返金」「担当者へ回す」のどれかに仕分けたい。文章を書かせずに、選択肢から1つ選ばせるだけでよい。そんな「判定AI」（文章を生成せず、決めた選択肢から答えを選ぶモデル）を、自分のPCで使えるのでしょうか？

結論から書くと、Ollama（ローカルでAIを動かすソフト）の標準機能で使えるようになりました。0.40.4から、ollama run に --ask を付けるだけで、はい/いいえ・選択肢・点数の3種の判定ができます。当ブログは9月に、専用の呼び出し口が無い状態で、文章生成の仕組みを使って判定AIを再現していました（仕組みからの再現、Jevと同じ型のモデルをRTX 3090で測った記事）。本記事はその続報です。

Ollamaの公式ドキュメントとモデルの配布ページを読み、RTX 3090（VRAM 24GB）のPCで、9月と同じ場面の問いを新しく作って測りました。2026年11月7日時点の内容です。

何が変わったのか〜専用の口と、コマンド1行

9月に測ったとき、Ollamaには判定AI専用の呼び出し口がありませんでした。そこで、文章生成用の generate で1トークンだけ出させ、候補の確率（logprobs）から選択肢ごとの確率を計算していました。問いの組み立ても、確率の計算し直しも、自分で書いたプログラムが担っていました。

その後、Ollamaには2段階で専用の仕組みが入りました。

• 0.35.0：判定AI専用の呼び出し口 /v1/systemone が入りました。公式ドキュメントは、判定AIの利用に0.35.0以降を求めています。Clef系のモデルは0.35.1以降です。
• 0.40.4：GitHubのリリースノートに「判定AIを、ターミナルから ollama run で直接使えるようになった」と書かれています。同じ版で、Apple Silicon向けのMLX実行環境でも判定AIが動くようになりました。
• 0.40.5：判定AIを、ollama.comのクラウドで動かせるようになりました。クラウドは入力トークンごとの課金で、有料プランか購入したクレジットが要ります。手元で動かすだけなら、APIキーは要りません。

0.40.4の公開日は、GitHubのリリースページでは「10月12日」と表示されています。一方、コマンドの変更（プルリクエスト #18962）が取り込まれた日は10月13日と表示されています。時差による表示の違いかどうかは【未確認】です。

–ask・–choice・–level の使い方

判定する対象の文章を、公式ドキュメントでは「state（状態）」と呼びます。state は、標準入力から流し込むか、モデル名の後ろに書きます。JSONも渡せます。そのうえで、問いを --ask で書きます。

• はい/いいえ：--ask だけを書くと、はい/いいえで答えます。例は ollama run nimble --ask "Is a refund being requested?" < ticket.txt です。
• 選択肢から選ぶ：--ask の後ろに --choice billing="Payments and refunds" のように、ラベルと説明を並べます。
• 点数を付ける：--ask の後ろに --level "Routine" --level "Soon" --level "Immediate" のように、低い順に段階を並べます。

--ask は1回の実行で何個でも書けます。--choice と --level は、直前の --ask に付きます。答えは問いごとに1行で、公式の例では「yes 97%」のように、答えと確率が並びます。点数の問いは、いちばん確率の高い段階と、その確率と、点数（例：1.2 / 2）が出ます。

点数の計算方法も公式に書かれています。段階に0から番号を振り、番号と確率を掛けて足した値です。3段階なら、0×P(Routine)＋1×P(Soon)＋2×P(Immediate) です。9月の記事で自分で計算していた「選択肢どうしで確率を足して1にする」作業を、Ollamaが代わりにしてくれる形です。

上限もあります。公式ドキュメントの表では、選択肢は2〜26個、点数の段階は2〜10個です。9月の記事で測った16択は範囲内ですが、Jev本体の「最大255個」のような使い方はできません。判定AIでないモデルに --ask を付けるとエラーになり、逆に判定AIに普通の文章で話しかけても答えません。

公式ドキュメントは、確信度（confidence）について「高くても正しいとは限らない」と書いています。9月の記事でも、確率の高さと当たりやすさの関係は、モデルによって大きく違いました。

対応モデルは24GBに載るか

2026年10月31日に、Ollamaのモデル一覧で「decision（判定）」の印が付いたモデルを確認しました。手元のRTX 3090（24GB）で動かす候補は次のとおりです。容量は配布ページに書かれたダウンロードの大きさで、実際に使うVRAMはこれより増えます。

一番大きいclef（27B）は、q4_K_M（4ビット前後に圧縮した版）で20GBです。24GBのVRAMには、ぎりぎり収まる計算です。ただ、配布ページの文脈長（一度に読める長さ）は256Kと書かれていて、文脈長を長く取るほどVRAMは増えます。既定の設定で動かしたところ、24GBには収まりませんでした（表のとおり）。18GBのnvfp4版は、Apple Silicon向けのMLX形式です。

nimbleは、9月に測ったAPUS-OpenJev-v1-9Bと同じQwen3.5-9Bを土台にしています。大きさが同じなので、速さを比べる相手として選びました。ただ、学習のさせ方が違うため、同じモデルの比較ではありません。

9月と同じ場面の問いで、1回の判断を測った

問いは、9月の記事と同じサポート窓口の場面です。注文が2日遅れ、商品が壊れていたが、少額の値引きなら客は納得する、という書き込みを state にしました。問いはすべて英語です。

• 測った問い：3択、8択、16択、はい/いいえ、長い文章（約1,600トークン）の3択の5種と、今回加えた3段階の点数（緊急度）の1種です。
• 機材：RTX 3090（24GB）のデスクトップPC、Ubuntu、Ollama 0.40.13（GitHubの最新版を、既存のOllamaとは別の場所・別のポートで動かしました）。
• 回数：各問いを5回測り、最速と最遅を除いた3回の中央値です。9月の記事は7回測り、5回の中央値でした。数え方が違うので、下の比較は目安です。
• 時間の取り方：2通り測りました。1つは --ask に --verbose を付けたときに表示される時間です。もう1つは、9月と同じくPythonから /v1/systemone に送り、返事を受け取るまでの時間です。コマンドの起動にかかる時間は、後者には含まれません。
• モデルの読み込み：最初の1回は読み込みの時間が入るので、表の値は読み込み後です。

9月の欄は、毎回入力を変えた場合の値です。clef 27B の列は、24GBに載らず約15%がCPUで動いた状態の値です。–ask の列は nimble だけ測りました。tev1（4B）とd1（3B）の3択は、それぞれ 33.2 ms、14.8 ms でした。

9月の記事では、同じ入力を繰り返すと、入力の長さに関係なく約0.45秒で止まりました。呼び出しごとの固定の手間が原因ではないかと書き、小さいモデルで確かめる宿題を残していました。今回、専用の口と小さいモデル（tev1・d1）で、同じ入力を繰り返したときの下限は 3択でそれぞれ58.7ミリ秒・34.0ミリ秒・16.2ミリ秒（5回の中央3点） でした。下限は約0.45秒に止まらず、モデルが小さいほど下がりました。9月の約0.45秒は、呼び出しごとの固定の手間ではなく、9月の測り方（generate 代用）か9Bモデルの処理に由来する可能性が高いです。ただし、今回は呼び出し口も版も違うため、原因の切り分けまではできていません【未確認】。また、同じ入力の繰り返しと毎回変えた場合の差はほぼなく（例：nimble の3択は58.7と57.1ミリ秒）、今回の呼び出し口では前置キャッシュの効き目は見えませんでした。

選ばれた答えが9月と同じかどうかも見ました。今回の問いは9月と同じ場面（注文が2日遅れ・商品が壊れていた・少額の値引きなら納得する）で作り直したもので、文面と選択肢の名前は9月と同一ではありません。そのため答えの一致は比べられません【未確認】。今回は、nimble・tev1・d1・clef（27B）は3択で「少額の値引き」を選び、確率は0.94〜0.98でした。clef-flash は3択では同じ答え（0.96）でしたが、長い文章の3択だけ「担当者へ回す」（0.67）を選びました。はい/いいえは全モデルが「いいえ」寄り（返金の要求あり=0.01〜0.02）でした。正解率は今回も測っていません。

分かったこと

• Ollama 0.40.4以降は、ollama run モデル名 --ask "問い" の1行で、はい/いいえ・選択肢・点数の判定ができます。9月のように、確率を自分で計算するプログラムは要りません。
• 選択肢は2〜26個、点数の段階は2〜10個までです。数百の選択肢から選ぶ使い方には向きません。
• RTX 3090（24GB）では、9Bのnimble・clef-flashと、4B・3Bの小さいモデルは余裕で載りました。27Bのclefは 載らず、約15%がCPUにはみ出しました でした。
• 1回の判断は、nimbleの専用の口で 3択・はい/いいえ・点数の約50〜65ミリ秒から、長い文章（約1,700トークン）の約370ミリ秒まで で、9月のgenerate代用の0.55〜0.98秒と比べて 大幅に速い（約0.55〜0.98秒に対し、およそ10分の1〜3分の1） でした。
• 日本語の対応がはっきり書かれている判定AIは、今回の候補ではd1だけでした。nimbleとclefの配布ページには、日本語の記載がありませんでした。

Ollama 0.40.4以降を使っている人は、まず nimble で ollama run nimble --ask "問い" を1回試すのが最初の一歩です。判定の正しさは測っていないので、実際の仕事に使う前に、自分の問いで正解率を確かめてください。日本語で使うなら、日本語の記載があった d1 から試すのが安全です。

今回確かめていないこと

判定の正しさ（賢さ）は評価していません。測ったのは1回の判断にかかる時間 [ms] だけです。RTX 3090以外のGPU、24GBに載らないモデル、長い入力、複数の判定を同時に走らせたときの速さも確かめていません。今回の問いの文面は9月と同一ではなく、1つの場面（問い合わせ文1種）だけを測りました。clef（27B）は24GBに載らず、一部がCPUで動いた状態の値です。–ask（コマンド）の時間は nimble だけ測りました。

出典

• Ollama公式ドキュメント「Decision」 https://docs.ollama.com/capabilities/decision （2026年10月31日確認）
• Ollama公式ドキュメント「CLI Reference」 https://docs.ollama.com/cli （2026年10月31日確認）
• Ollama v0.40.4 リリースノート https://github.com/ollama/ollama/releases/tag/v0.40.4 （2026年10月31日確認）
• Ollama v0.40.5 リリースノート https://github.com/ollama/ollama/releases/tag/v0.40.5 （2026年10月31日確認）
• プルリクエスト #18962「cli: add decision model support to ollama run」 https://github.com/ollama/ollama/pull/18962 （2026年10月31日確認）
• Ollamaのモデル配布ページ（nimble・clef・clef-flash・tev1・d1） https://ollama.com/library/nimble ほか （2026年10月31日確認）