ContactX無料相談

Technical Feasibility / Local LLM

JevはLocal LLMで
再現できるか？

型が必ず正しい判断、低遅延、確率つきの回答は、公開モデルとMLXでどこまで再現できるのか。公開実装の測定結果を比較し、電話業務で採用判断するための検証条件を整理します。

執筆・監修：　公開：　更新：

結論から読むJev公式の型を見る

TL;DR

結論：インターフェースと速度は再現可能。品質と確率校正は別問題です。

再現しやすい

許可された選択肢だけを返すこと、JSONを必ず正しい型にすること、自由文を生成せず100〜数百ms台で判断することは、複数のローカル公開実装で確認されています。

検証が必要

Jevと同等の意味精度、確率校正、未知業務への汎化、日本語音声認識後の揺れ、同時通話時のp95は、モデルを置くだけでは得られません。

調査時点：2026年9月19日。Jevと周辺実装は公開直後で、各リポジトリの速度値は原則として作者による自己測定です。機器、入力長、質問数、精度条件が異なるため横並びのランキングには使えません。

OFFICIAL AGENT SKILL

まず既存プロジェクトの置換候補を棚卸しする

TypeSafe公式は、Claude Code、Codexなどのエージェント向けスキルを公開しています。API実装から始める前に、遅い・高価なLLM呼び出しや、文章生成後のJSONパースを探し、Choice・Score・Noulへ分解できる箇所を洗い出せます。

1. プロジェクトへインストール

npx skills add typesafe-ai/skills --skill typesafe-ai

2. エージェントへ依頼

use /typesafe-ai to see how Jev can be used to replace slow, expensive LLM usage and find possible new features it would enable for users.

skills.sh経由の導入はプロジェクトローカルが既定です。呼び出し方は環境で異なり、どのエージェントでも「use the TypeSafe skill」と明示できます。Claude Codeプラグインでは /typesafe:typesafe-ai を使います。出典：TypeSafe「Agent skill」、公式GitHubリポジトリ。

What Jev Changes

文章を生成するのではなく、型のある判断を返す

TypeSafe AIの公開仕様では、Jevは同じstateに対して複数の質問を受け、Choice、Score、Noulのいずれかを返します。Choiceは候補ごとの確率分布、Scoreは段階ごとの分布と加重値、Noulはyesの確率です。

CHOICE

どの候補か

部署、意図、商品、次の処理など、順序のない有限候補から1つを選び、全候補の確率を返します。

SCORE

どの段階か

緊急度や感情など、順序のある基準を段階として定義し、段階間を含む加重スコアを返します。

NOUL

条件に当てはまるか

返金要求があるか、確認が必要か、といったyes/no判断を0〜1で返します。

一次情報

TypeSafe AI「Primitives (Questions)」、API reference

公式サイトは「calibrated probabilities」と説明していますが、本記事では公式の宣伝表現と第三者・コミュニティ測定を分けて扱います。

Public Implementations

実際にLocal LLMで試している公開実装

共通しているのは、モデルに完成したJSONを書かせず、候補のスコアを直接読む設計です。

実装モデル・実行環境公開された測定技術的な読み方
typesafe-localQwen3 0.6B / 1.7B・MLXM4 Proで、1文書に対する4質問を約200msと報告文書を一度だけ符号化し、回答位置のlogitだけを読みます。生の確率が不正確であること、選択肢順序の影響も明記しています。
open-jevGemma 3 4B・MLXApple Siliconで選択肢スコアリングを約90ms/要求と報告文脈のKVキャッシュを候補ごとに展開し、候補文の尤度を一度に計算します。自由文やJSONは生成しません。
jev-on-a-laptopQwen 1.5B / 7B / 8B・MLXM5 MacBook Airで28項目410ms（1.5B）、3項目611〜646ms（7B/8B）1.5Bは高速でも判断品質が弱く、公開Jev問題ではローカル7BがJevより約13ポイント低い結果でした。
System One LiteQwen3 1.7B / 4B・MLXChoice・Score・Noul型のJev互換APIを公開回答候補をA・B・Cなどの単一トークンに写し、候補以外を出力不能にします。確率は校正済み確率ではないと明記しています。
Verdict OpenJevModernBERT 151M・WebGPU/WASM単一スレッドのp50 35.58msを報告固定業務には高速ですが、TypeSafe公開評価への外部適用は48.07%で、汎化性能の限界も示しています。

別の比較実験では、M4 Pro上のローカルツール呼び出しモデルが442件中327件のみ有効、成功要求のp50が403msでした。対して、直接型付き判断を返す設計ではなく通常のツール呼び出しを使うだけでは、安定性が自動的に得られないことを示す一例です。出典：typesafe-ai-benchmark。

Architecture

構造化出力を安定させる鍵は「生成しない」こと

  1. 01
    状態を短く整える

    確定済みの顧客・商品・配送条件と、最新発話を構造化したstateにします。

  2. 02
    許可候補を定義する

    注文、変更、キャンセル、商品案内、その他など、アプリが実行できる候補だけを渡します。

  3. 03
    候補logitを読む

    モデルが文章やJSONを生成する前のスコアから、候補間の分布を計算します。

  4. 04
    コードで型を組み立てる

    選択結果、確率、モデル版、しきい値判定をアプリ側でJSONへ変換します。

  5. 05
    低信頼を戻す

    判断不能、候補差が小さい、重要操作に該当する場合は追加質問または人の確認へ回します。

JSON Schemaや文法制約による生成も有効です。JSONSchemaBenchは、Outlines、llama.cpp、XGrammarなどの制約付き生成を評価しています。ただし有限候補だけなら、生成ループ自体をなくす方が出力が短く、構造違反も起こりません。

Three Different Guarantees

「安定した出力」を3つに分けて評価する

観点保証できること保証できないこと
構造

キー、型、enum、値域をコードで固定できる

選ばれた値が業務的に正しいこと

意味

正解データに対する精度を測定できる

未知の言い換えや対象外入力で同じ精度が続くこと

確率

検証データ上で校正し、しきい値を設定できる

生のsoftmax 0.9が90%の正解率を意味すること

`jev-on-a-laptop`の小規模評価では、Qwen 7Bが誤った20項目のうち13項目で0.90を超える確信を返しました。型が常に正しくても、誤答を自信高く返す問題は残ります。

Contact Center Fit

電話注文では、判断モデルに業務ルールを任せない

電話業務は候補が有限で、Jev風の判断を使いやすい領域です。一方、金額や確定操作まで意味判断だけで進めるべきではありません。

Local LLMに向く

注文意図、商品名の言い換え、問い合わせ種別、候補商品の順位、聞き直しが必要か、人へ渡すべきか。

決定的コードに向く

必須項目、在庫、価格、数量、配送可能地域、住所形式、支払条件、注文確定、CRMへ書き込む値。

商品数が多い場合は、全商品をChoiceに入れず、商品マスタ検索で候補を絞ってからLocal LLMで再順位付けします。会話全文ではなく、確定済み状態と直近発話を渡すことで入力処理時間も抑えます。

Evaluation Plan

PoCで測る6項目

01

構造の安定性

JSON Schema適合率ではなく、欠落キー、許可外の値、途中終了を含めて100%かを確認します。直接logit方式では、アプリ側がJSONを組み立てるため構造違反を設計上なくせます。

02

判断精度

意図、商品候補、確認要否ごとにAccuracy、Macro F1、重要クラスのRecallを測ります。全体平均だけで、キャンセルや住所曖昧の見逃しを隠さないようにします。

03

確率校正

Brier score、ECE、reliability diagramで、0.9という値が実際の正解率と対応するかを測ります。必要なら温度スケーリングを、学習とは分けた検証データで行います。

04

選択的自動化

信頼度しきい値以上だけ自動処理したときのcoverageとselective riskを測ります。重要操作は精度より、誤った自動処理を何件まで許容するかから決めます。

05

レイテンシ

モデル読込後のp50だけでなく、p95・p99、初回、入力長別、同時実行1・4・8本を測ります。モデルがメモリに載ることと、同時通話で速いことは別です。

06

頑健性

選択肢の順序入れ替え、紛らわしい候補の追加、言い換え、ASR誤認識、対象外発話で結果がどう変わるかを確認します。必ず「その他・判断不能」を用意します。

暫定の合格条件例

構造適合100%、判断単体p95 300ms以内、重要クラスRecall 99%以上、しきい値以上の自動処理でselective risk 1%未満、対象外入力は必ず判断不能または人へ返す。

数値は製品保証ではなくPoC開始時の仮説です。誤処理の影響と必要な自動化率に応じて、業務ごとに決めます。

FAQ

よくある質問

Jevと同じモデルをローカルで動かせますか？

2026年9月19日時点で、Jevの学習済み重みや完全なモデル構造が公開されていることは確認できません。本記事で扱うのは、公開モデルでChoice・Score・Noulに近い型付き判断インターフェースを再現する方法です。

JSON Schemaを指定すれば十分ですか？

複雑な抽出や文章を含む出力には有効ですが、数個の選択肢を返すリアルタイム判断では余分なトークン生成が発生します。候補が有限なら、候補logitを直接読み、アプリ側でJSONを組み立てる方が速く、構造違反も防げます。

Local LLMが返すconfidenceは、そのまま正解確率にできますか？

できません。候補間のsoftmaxは相対的な選好であり、業務上の正解率と一致する保証はありません。独立した正解データで校正し、モデル・プロンプト・候補集合を変更したら再評価します。

電話応対で300ms以内を狙えますか？

短い状態と少数の判断を、1〜4B級モデルの直接logit方式または専用分類器で処理するなら候補になります。ただしASR、ネットワーク、業務API、TTSを含む会話全体の遅延とは分け、同時通話数を含めて実機で測る必要があります。

Sources

確認に使った仕様・研究・公開実装

速度・精度値はリンク先の測定条件と制約を併せて確認してください。

Local LLM PoC

モデル名ではなく、実際の電話業務で比較します。

対象発話、許可する処理、誤りを許容できない項目を整理し、Local LLM、決定的ルール、有人確認の境界を設計します。

Local LLM構成を相談するセキュリティ構成を見る
AI導入とPoC設計CRM・CTI連携ボイスボットとの使い分けLocal LLM・データ境界