判定だけのAIは公称200倍速い
第三者の実測は2.5〜14倍です

「LLMより200倍速い判定AI」の話を聞いた方へ

業務システムにLLMを組み込む見積もりを見ていて、ベンダーや技術記事から「文章を書かない、判定だけのAIなら200倍速くて安い」と聞いた情シス・DX推進の方に向けて書いています。

判定特化モデルとは、文章を生成せず、あらかじめ決めた選択肢への確率だけを返すモデルです。2026年9月15日にTypeSafe AIが「System Oneモデル」という分類とその最初のモデル「Jev」を公開し、9月中旬から日本の技術者の間で検証記事が続きました。

速さと単価の差は、第三者の実測でもはっきり出ました。ただし比べた相手が違い、第三者の倍率は開発元の数字より1桁小さく出ています。正解率は上がるとは限りません。そして手放すものが2つあります。

公式の数字は、公式が慎重に書いています

開発元の発表は、フロンティアLLMの応答時間が3〜329秒に対して70〜500ミリ秒で、フロンティアLLMと同じ水準の知能でSystem One型の問いなら40〜200倍速い、と書き（要旨）、自社サイトの見出しには193.6倍速い・444.6倍安いという数字を掲げています。

同じ文書に、次のことも書かれています。

• 公開した評価は、サービスの拠点がある米西海岸の自社のラップトップからおおむね実行した
• 見出しの193.6倍・444.6倍はワークフロー評価から来た数字で、実際に得られる効果の上限寄りだと考えている
• 評価に使った4本のワークフローは、モデルに有利になるよう選んだわけではないが自社の能力チームの個人が作ったもので、偏りが残りうる
• 価格が補助されていないことは証明できない。持続性は長期で示す
• 参照解をGPT-6 AstraとFable 5.1の平均にしたため、自社モデルの相対性能を過小評価している可能性もある
• 並べて見せるデモの入力は短く密な1段落で、相対的に短い入力はモデルを有利に見せる

見出しの倍率と本文の条件は、同じ発表の中でも別の情報です。生産性200倍の回で書いた「何を測った数字か」を、そのまま当てられます。

同じ「速い」で、比べた相手が違います

9月中旬に日本語で公開された実測を2本、開発元の数字と並べます。各行の太字が測った人です。

第三者A自身は、倍率の差を比べた相手の違いで説明しています。開発元はフロンティアモデルを相手に測り、第三者Aは推論を切った小型モデルを相手に測っています。相手が小さく速いほど倍率は縮みます。第三者Aはこう書いています。「TypeSafe は「LLM より 40〜200 倍速い」と主張しているが、本検証の条件（推論なしの小型 LLM）では 2.5〜13.8 倍だった。比較相手の LLM の大きさや推論の有無によって、倍率は大きく変わる」。

ただし、今回参照した第三者の検証は、開発元の公称値を同じ条件で再現したものではありません。フロンティアモデルを相手に測った第三者の記録は、今回確認した資料にはありません。

ローカル実験では、文章を書かせない分だけ短くなりました

第三者Aの計測で目を引くのは、倍率より応答時間の安定です。Jevの応答は入力の長さにも問いの数にもほとんど左右されませんでした。1問ずつのデータセットでは約240ミリ秒、5問をまとめた難問セットでも247ミリ秒です。比較した gpt-4.1-mini は、問いが増えて出力が長くなるほど遅くなり、1問で約800ミリ秒だったものが5問で1,528ミリ秒になっています。

Jevを使わずに、同じ方式だけを手元で試した記事もあります。手元のGPUで、既存の推論エンジンに標準で付いている機能だけを使い、文章を書かせる代わりに選択肢だけを選ばせたところ、2,963ミリ秒が146ミリ秒になり、確かめた6問では答えが同じでした。この筆者は「あの待ち時間の大半は、文章に起こしている時間だったということです」と書いています。この実験はJevを動かしておらず、別のモデルで各1回測ったものです。Jevの速さの内訳を分けて測った実験ではありませんが、文章を書く工程を省くだけで待ち時間が縮む、という向きは一致しています。

正解率が上がるとは限りません

第三者Aは正解率も測っています。77クラスの意図分類ではJevが最も高く0.790でしたが、英語ツイートの皮肉判定ではローカルの27Bモデル（qwen3.8）の0.870がJevの0.805を上回りました。日本語レビューの感情分類と英語レビューの星評価では、Jev・gpt-4.1-mini・qwen3.8の差は誤差の範囲で、12組の比較に多重比較の補正をかけると有意な差はどれも残らなかったと書いています。

第三者Bの振り分けでは、従来の判定役が39件中36件、Jevが39件中39件で期待と一致しました。件数が少ないので参考値です。

第三者Aは、Jevを「LLM より常に賢い分類器」ではなく、「LLM と同等の判断を、数倍速く、数分の一から十数分の一の費用で、較正された確率付きで返す部品」と位置づけました。Jevを使わずに同じ方式を試した筆者も、同じことを1行で書いています。「速くなっても、当たるようにはなりません」。自社の用途で正解率が保てるかは、置き換えの前に自社のデータで測る必要があります。

代わりに手放すものが2つあります

第三者Bは、Slack常駐エージェントの前段にあるルーターの判定役を、事後学習した生成モデルからJevに置き換えました。13場面×3回、計39件の振り分けはすべて期待どおりで、判定と変換の時間は中央値で1.55秒から0.27〜0.42秒になっています。

そのうえで、速さ以外に変わった点を3つ挙げています。

• 判定の入力が外へ出る。以前は判定役だけが全リクエストの中身を読むため、判定役を手元のGPUに置いていた。Jevは外部のAPIなので、判定に使う文章が開発元へ送られる。実行役の生成モデルは最初から外部サービスにあったため、出る情報の種類は増えないが、出る先が1つ増える
• 判定の根拠が読めない。以前の判定役は「この依頼で一番難しい要件」を書いて返していた。Jevが返すのはラベルと確信度と選択肢ごとの確率だけ
• 判定の基準を、学習ではなく文章で持つ。選択肢ごとの説明文がそのまま基準になり、基準を変えたいときは設定ファイルの文章を書き換える

この記事では、3つ目を利点、1つ目と2つ目を代償と見ます。第三者Bは「判定の速さと、入力を DGX の外に出さないことは、今回の構成では両立しません」と締めています。

見積もりで「判定」の行を探してください

発注側が持ち帰れるのは、次の3点です。

生成の行と判定の行を分ける

LLMを組み込む見積もりには、生成の行と判定の行が混ざっています。問い合わせを要約するのは生成、どの部署へ回すかは判定です。承認してよいかを決めるのも、規約に触れるかを見るのも判定です。1800万円のエージェントの回で、LLMが担う範囲は全体の一部だと書きました。その一部をさらに割ると、判定の部分は待ち時間と利用料が下がりうる、というのが今回の材料です。

下がるのは判定APIの応答時間と利用料で、開発・評価・運用の費用ではありません。第三者Aの実測では速度が数倍、費用が数分の一から十数分の一でした。見積もり全体が10分の1になる、という前提で予算を組む数字ではありません。

判定の送り先を、生成とは別に確かめる

判定の入力が外へ出ます。データの境界の回で分けた「学習に使うか」「どれだけ保持するか」「どこに保存するか」の3層を、判定の送り先について、生成の送り先とは別に確かめる必要があります。判定役だけ手元のGPUに置き、生成は外に出す、という第三者Bの元の構成は、その答えの1つです。

失敗したときの流し先と記録を要件に書く

判定を外部のAPIに寄せるなら、LLMのAPIは週に数回止まるの回で書いた「止まった後の動き」を判定にも書いておく必要があります。第三者Bは、判定に失敗したら強い側のモデルへ流す設定にしました。安い側へ流すと失敗が利用者から見えなくなる、という理由です。ただし強い側へ流すだけでは、利用者には失敗が見えません。流したことを記録し、誰かに知らせる仕組みは別に要り、流し先とあわせて発注側が要件として書けます。

数字の出どころと限界

この記事の内容は、次の資料を2026年9月23日に確認したものに基づきます。

開発元の数字

TypeSafe AIの発表「Introducing System One Models and Jev」（ページの日付表記は2026年9月15日）の記載です。70〜500ミリ秒、3〜329秒、40〜200倍、193.6倍、444.6倍、入力100万トークン0.042ドル、出力無料、ワークフロー4本という数字と、自社ラップトップからおおむね実行したこと、見出しの数字が実際の効果の上限寄りだという見方、ワークフローを自社の能力チームの個人が作ったこと、価格の持続性を証明できないこと、短い入力がモデルを有利に見せること、参照解の選び方で自社モデルを過小評価している可能性があることの6つの留保は、いずれも同文書にあります。

第三者の実測

第三者Aの数字はQiitaの記事「Jevは構造化出力LLMの代わりになるか：821件で速度、費用、確率を比較した」（2026年9月19日）の記載です。公開データ4種×200件と難問21件、約240ミリ秒と247ミリ秒、約800ミリ秒と1,528ミリ秒、2.5〜3.7倍、6.2〜8.5倍、4.2〜13.8倍、1/3.9〜1/12.7、0.790、0.870と0.805、多重比較の補正、位置づけの引用はこの記事によります。比較したLLMは推論を切った設定で、筆者自身が「推論を有効にすれば LLM の正解率は上がる可能性があるが、応答時間と費用はさらに増える。本検証はその条件を扱っていない」と書いています。

第三者Bの数字はDevelopersIOの記事（2026年9月20日）の記載です。1.55秒と0.27〜0.42秒、39件中36件と39件、約0.000023ドルと0.003ドル、判定の入力が外へ出ること、根拠が読めないこと、基準を文章で持つこと、失敗時に強い側へ流す設定と「失敗が利用者から見えなくなります」という理由はこの記事によります。ルーターの実装は執筆時点で未マージのプルリクエストのブランチをビルドしたものです。

手元のGPUで同じ方式を試した実験（2,963ミリ秒→146ミリ秒、「速くなっても、当たるようにはなりません」）は個人ブログの記事（2026年9月20日）によるもので、筆者自身が、問題20件は自作で現場のログではないこと、各モデル1回ずつの測定であること、Jevそのものは動かしていないことを書いています。

限界

いずれも公開から1週間前後の時点の値です。Jevは執筆時点で早期アクセスの段階で、開発元は評価を米西海岸のラップトップからおおむね実行したと書いており、価格は変わりうるとも書いています。私たちはJevそのものを動かしていません。

異常を見つける部分にAIを使わないという構成は運用監視の回に、ローカルLLMの入口に認証・記録・切り替えを置く考え方はゲートウェイの回に書いています。自社の処理のうち何が生成で何が判定かを一緒に洗い出すご相談は、お問い合わせからお送りください。