0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

あなたはもう試した？判断特化AI「Jev」で遊ぼう！
@ys_dirard(dirard)

Jev とは何か。Jevもどき(Open Weight の代替 14 構成)を比較というか調査してみた。

0
Posted at

Claude CodeでFable5.1に調べてもらった内容をもとにしているので参考程度で見てください。
Jevのことは知りたい、クラウドAPIはセキュリティ的に微妙だしローカルでやりたいし…というモチベーションです。
主に私が忘れないための備忘目的になります。

2026 年 9 月に TypeSafe AI が公開した Jev は、「文章を生成しない AI モデル」として話題になりました。公開から 3 週間で Jev 互換の Open Weight モデルが数十種類登場し、独立ベンチマークも 2 つ立ち上がっています。

この記事では、Jev が何をするものか、入力と出力、使い方を整理したうえで、Open Weight の代替モデルがどういう作りになっているかを 3 つの方式に分けて説明します。後半では、Jev 形式の共通サンプル 76 問を自作し、手元の RTX 4090 で 14 構成を動かした結果を載せます。

情報は 2026 年 10 月 9 日時点のものです。各モデルの性能数値の多くは開発元の自己申告で、独立計測は Benchmark Heaven の JevBench と、手元で動かした結果だけです。

Jev とは

一言でいうと「判断だけを返す関数」

Jev は、入力 (state) と型付きの質問を渡すと、テキストではなく選択肢ごとの確率分布を返すモデルです。分類、ルーティング、採点、真偽判定、ガードレールなど「コードが直接消費する判断」に特化していて、チャットやコード生成には使えません。

TypeSafe AI はこれを "System One model" という新カテゴリの第 1 号と位置づけています。名前の由来は Kahneman『ファスト&スロー』の「速い直感的思考 = System 1」です。CEO の Diogo Almeida は元 OpenAI で RLHF や InstructGPT に関わった人物で、「チャットは超人的になったのに、なぜ自動化は進まないのか」という問いからこのモデルを作ったと説明しています。

項目 内容
公開 2026-09-15 (早期アクセス)。同時に $40M のシード調達
現行版 jev-1.13.0
ライセンス プロプライエタリ。重み、アーキテクチャ、論文とも非公開
学習法 RLCD (Reinforcement Learning for Calibrated Decisions) と呼ぶ独自手法。合成データのみ
価格 入力 $0.042 / 100 万トークン。出力トークンは無料
コンテキスト 1 リクエスト 64k トークン (state + 最長の質問は 32k 以内)
入力 テキストのみ (文字列 / JSON / 配列)。画像や音声は不可
レイテンシ 公称 70〜500 ms。第三者計測では p50 で 236〜301 ms
言語 英語が主。CJK は「扱えるが精度は劣る」と公式に注記
カスタマイズ ファインチューニングの提供なし。state と質問文で制御する

入力と出力

エンドポイントは 1 つだけです。

POST https://api.typesafe.ai/v1/systemone

{
  "state": "Help! My payouts have been failing for 3 days.",
  "model": "jev-latest",
  "questions": {
    "is_urgent": {
      "type": "noul",
      "instructions": "Does this convey urgency?"
    },
    "department": {
      "type": "choice",
      "instructions": "Which team should handle this?",
      "criteria": {
        "billing": "Payments, invoicing, refunds",
        "technical": "Bugs, outages, integrations",
        "sales": "Pricing, upgrades, new accounts"
      }
    },
    "frustration": {
      "type": "score",
      "instructions": "How frustrated is the customer?",
      "criteria": ["Calm", "Frustrated", "Very angry"]
    }
  }
}

質問のタイプは 3 つしかありません。

タイプ 意味 制約 返り値
noul Yes/No 命題の真偽 なし noul (0〜1、Yes の確率)
choice 順序のない選択肢から 1 つ選ぶ 最大 255 選択肢 choice、probabilities、confidence
score 順序付きルーブリックで採点 2〜10 段階 score (期待値)、legend、probabilities、confidence

レスポンスはこうなります。

{
  "model": "jev-1.13.0",
  "answers": {
    "is_urgent": { "type": "noul", "noul": 0.95 },
    "department": {
      "type": "choice",
      "choice": "billing",
      "probabilities": { "billing": 0.88, "technical": 0.12, "sales": 0.0 },
      "confidence": 0.81
    },
    "frustration": {
      "type": "score",
      "score": 1.05,
      "legend": { "0": "Calm", "1": "Frustrated", "2": "Very angry" },
      "probabilities": { "0": 0.0, "1": 0.95, "2": 0.05 },
      "confidence": 0.92
    }
  },
  "usage": { "input_tokens": 296, "output_tokens": 20 }
}

モデル本体が返すのは質問ごとの確率分布だけで、choice は argmax、score は確率加重平均、confidence は分布の集中度から固定式で計算される派生値です。

設計上の重要な性質が 2 つあります。

  • 全質問は並列かつ独立に評価されます。質問 A の答えに質問 B は依存できません。依存がある場合は 2 回に分けて呼びます。
  • state は 1 回だけ読まれるので、質問を増やしてもレイテンシはほぼ増えません。公式クックブックでは、13 問を 1 リクエストにまとめると 12.2 倍安く 10 倍速いと報告されています。

このため公式ガイドは「1 つの質問には 1 つの判断だけ」を推奨しています。「ピッチを採点」ではなく「市場規模」「技術的実現性」「差別化」を別々に score し、重みはコードで管理する、という使い方です。

使い方

Python SDK ではこう書きます。

from typesafe_sdk import TypeSafeClient, Noul, Choice, Score

client = TypeSafeClient(model="jev-1.13")   # 環境変数 TYPESAFE_API_KEY を読む

result = client.system_one(
    {"ticket": "I was charged twice for order A-104. Please refund the duplicate."},
    {
        "refund_requested": Noul(instructions="Does `ticket` request a refund?"),
        "department": Choice(
            instructions="Which team should handle this?",
            criteria={"billing": "Payments, refunds", "technical": "Bugs, outages", "other": None},
        ),
    },
)
if result.nouls["refund_requested"].noul > 0.5:
    ...

TypeSafe 直接のほか、Vercel AI Gateway (typesafe-ai/jev)、Cloudflare Workers AI (typesafe/jev)、OpenRouter、Requesty からも呼べます。

公式が推奨するパターンは次の 5 つです。

パターン 内容
Speculative fan-out 必要になりそうな質問をまとめて 1 回で投げ、コード側で必要なものだけ使う
Confidence-gated routing 答えと confidence を分け、低 confidence は人間レビューや上位 LLM へ
Composite scoring 複合判断を原子的な score に分解し、重みはコードで持つ
Intent routing 入力を分類し、決定論的ハンドラ / 専門 LLM / 人間に振り分ける
Hybrid agent 難しい判断は LLM、定型的な判断は Jev に任せてコストとレイテンシを下げる

公式が認めている弱点

TypeSafe は jev-1.13 の弱点リストを公開しています。要約すると「意味的な判断は得意だが、計算と推論はコードに任せろ」です。

  • 文字どおりに読む。意図を汲まない
  • 算術、カウント、日付の比較は不得意
  • 多段の間接参照や二重否定で精度が落ちる
  • 無関係な情報が多い大きな state で精度が落ちる
  • プロンプトインジェクションの影響を受ける。セキュリティ境界として使ってはいけない
  • choice の選択肢順序に依存することがある (先頭に寄りやすい)

第三者評価も、この見立てと整合しています。Banking77 (77 クラス) では Gemini 3.8 Flash 83.6% に対して Jev 79.5% で、Jev は約 6.7 倍安く約 6 倍速い、というのが典型的な結果です。「ハルシネーション 0%」という宣伝文句は「スキーマ違反が構造的に起きない」という意味で、「整形された間違い」は起きます。

Open Weight の代替モデルと 3 つの方式

Jev の重みは非公開ですが、「state と型付き質問を受け、選択肢の確率分布を返す」という外形は簡単に真似できます。実際、公開から数週間で Jev 互換のモデルが数十種類登場しました。大半は既存の Open LLM (Qwen3.5 / Gemma 4) のトルソを流用し、生成ヘッドの代わりに「選択肢の確率を読み出す部分」を載せたものです。作りは 3 種類に分かれます。

方式 仕組み 例
A. 読み出しヘッド置換 LM ヘッドを捨て、<answer> 位置と各選択肢位置の hidden state を照合する小さなヘッドを学習 (LoRA 併用) Strands Decider 2B、Kev、Imajev、NeoHorse、JEV-27B、Clef、d1-3B
B. 選択肢文字のロジット読み出し プロンプトに A/B/C... を並べ、次トークンのロジットを softmax。LoRA 微調整 + 温度キャリブレーション JevK5、Quyet、H2O-Lightning、open-alternative-jev (学習なし)
C. エンコーダ + 決定ヘッド ModernBERT 等の双方向エンコーダに決定ヘッドを付けて学習 Laya、Quyet-Small、d1-omni-600M

方式 A は、ヘッドが選択肢ごとのパラメータを持たないので選択肢数に上限がなく、「1 番目を選びやすい」バイアスを学習しにくいのが利点です。方式 B は構造変更ゼロなので vLLM などの標準推論基盤がそのまま使えますが、選択肢が文字ラベルに縛られます (JevK5 は 16、Quyet は 10 まで)。方式 C は数億パラメータで圧倒的に速い一方、世界知識と推論力が乏しくなります。

主なモデル

モデル 開発元 ベース / サイズ ライセンス 特徴
Strands Decider 2B AWS strands-labs Qwen3.5-2B-Base + LoRA + pointer head、1.9B Apache-2.0 学習データとスクリプトまで全公開。Strands Agents のツール呼び出しゲートに統合済み
Kev jaredpalmer Qwen3.5 0.8B / 4B / 9B、Qwen3.8-27B Apache-2.0 GitHub 8.7k スター。TypeSafe の Python SDK をそのまま流用できる
JevK5 allebee Qwen3.5-4B / 9B + 蒸留 LoRA Apache-2.0 GGUF 版があり llama.cpp で CPU でも動く
Imajev-4B mohit67890 Qwen3.5-4B + アダプタ Apache-2.0 写真 + アプリ状態 + 型付き質問を入力できる
NeoHorse-Jev-4B TokenRhythm NeoHorse-1-4B Apache-2.0 prefill-only。テキスト + 画像 1 枚
H2O-Lightning-4B H2O.ai Qwen3.5-4B 微調整 Apache-2.0 JevBench v1.6.1 の公式 1 位。vLLM + shim で動く
Quyet 1.0 Chinh Nguyen Gemma-4-31B-it + LoRA (Large) から 153M のエンコーダ (Small-EN) まで 5 サイズ Apache-2.0 Large は JevBench の Intelligence で Jev を上回る。1 問 10 択まで
Laya Convai Innovations ModernBERT-large 421M、多言語版は mmBERT-base 322M Apache-2.0 33 ms。Jev と同じ RLCD で学習したと説明。ゼロショット性能は低く微調整前提
LiquidAI d1 Liquid AI LFM2.5-VL-3B (d1-3B)、LFM2.5-Encoder-350M + 視覚/音声 (d1-omni-600M) LFM 1.0 (独自) エッジ向け。RTX 4090 で 1 問 8 ms、Jetson AGX Thor で 16 ms
Clef / Clef-Flash Cloudflare Qwen3.8-27B / Qwen3.5-9B + joint schema head Apache-2.0 全質問の全選択肢を一括スコア。テキスト、JSON、画像、動画を入力できる
JEV-27B AutoTrust Qwen3.8-27B + 109M の System 1 ブロック Apache-2.0 Jev の出力分布を蒸留。KL 0.017 で「区別不能」と主張
open-alternative-jev ikermoel 任意の Open LLM (ライブラリ) Apache-2.0 学習なしで確率を取り出す。選択肢順序に敏感

同名の別プロジェクトが多いので注意してください。「OpenJev」と名の付くものは 5 つ以上あり、kyegomez/open-jev はランダム重みの研究実装で実用できません。openjev/openjev は CC-BY-NC で商用不可です。

独立ベンチマーク JevBench の見方

Benchmark Heaven が運営する JevBench は、Jev クラスのモデルを自前のハードウェアで動かして測る独立ベンチマークです (TypeSafe とは無関係)。Intelligence (チャンス補正精度)、Calibration、Speed、Cost の 4 軸の等重み調和平均が公式スコアで、Cost は「1,000 判断あたりの USD」です。

システム 公式順位 JevBench Score Intelligence Calibration $/1k 判断 p50
Jev 1.13.0 (参照) - 71.5 64 91 $0.032 0.24 s
H2O-Lightning-4B v1.1 1 72.5 60 90 $0.021 0.2 s
decisio v0.8.0 (gemma-4-31B-it) 2 71.7 70 89 $0.041 0.2 s
Quyet-1.0-Large 3 71.4 73 90 $0.045 0.4 s
JevK5 v0.3 35 37.4 39 90 $0.017 0.2 s
JEV-27B 56 21.3 57 91 $0.199 0.36 s
Laya 120 0.0 2 63 $0.003 1.8 s

v1.6.1 (2026-10-06) の値です。読むときの注意が 3 つあります。

  • 4 軸の等重み平均なので、27B クラスは Intelligence が高くても Cost で大きく減点されます (JEV-27B の Capability は 73.9 で Jev の 77.1 に迫るのに公式 56 位)。
  • 問題プールと採点法がバージョンごとに変わり、順位が大きく入れ替わります。Imajev-4B は v1.4.2.2 で 1 位、v1.6.1 で 47 位でした。
  • 別に Decision Index (Cloudflare がリーダーボードを運営) もあり、こちらでは Clef 61.21、Jev 57.91 と各社が自己申告しています。2 つのベンチの順位は一致しません。

手元で 14 構成を同じ 76 問で動かした

公開されている数字はほぼ自己申告なので、Jev 形式の共通サンプルを自作して、手元で動く Open Weight モデルに同じリクエストを投げました。

サンプルの設計

46 item、76 問 (noul 38、choice 21、score 17)、うち日本語 9 問です。Jev の得意分野 (サポート振り分け、返金ポリシー照合、含意判定、12 択の意図分類、感情スコア、モデレーション、エージェントのツール呼び出しゲート) に加えて、公式の弱点リスト (無関係な長文、プロンプトインジェクション、算術、日付) を試す item を少数入れました。choice を含む item は選択肢を逆順にしたリクエストも投げて、順序感度を測ります。

{
  "state": {
    "policy": "Refund policy: a refund is allowed only if (1) the purchase was made within the last 30 days AND (2) the customer has a receipt. Digital goods are never refundable.",
    "case": "E-book (digital download) bought 3 days ago, receipt attached."
  },
  "questions": {
    "refund_allowed": {
      "type": "noul",
      "instructions": "According to `policy`, is a refund allowed for `case`?"
    }
  }
}

環境

CPU 32 コア、RAM 62 GB、RTX 4090 です。まず CPU で全構成を測り、GPU が空いた後に同じ構成を GPU で再計測しました。正答率は Kev-0.8B と so1 の各 1 問を除いて CPU と GPU で一致したので、以下の正答率は CPU 計測、レイテンシは GPU 計測 (bf16、item 単位の中央値) の値です。Jev 本家は API キーが無いため未計測です。

結果

モデル (方式) 正答率 noul choice Brier ECE 順序反転で答え変化 日本語 9 問 p50 GPU (ms)
Imajev-4B (A) 92.1% 94.7% 95.2% 0.112 0.066 0% 88.9% 40
Clef-Flash 9B (A 変種) 90.8% 92.1% 100% 0.099 0.078 0% 77.8% 45
JevK5-4B (B 学習済み) 90.8% 94.7% 100% 0.128 0.083 0% 88.9% 29
Kev-4B (A) 89.5% 89.5% 100% 0.101 0.048 0% 88.9% 30
NeoHorse-Jev-4B (A) 89.5% 89.5% 100% 0.095 0.027 0% 88.9% 24
d1-3B (A 相当) 88.2% 89.5% 100% 0.121 0.054 0% 66.7% 11
Strands Decider 2B (A) 84.2% 84.2% 100% 0.174 0.109 0% 77.8% 25
Quyet-Medium 4B (B 学習済み) 81.6% 89.5% 71.4% 0.104 0.083 0% 88.9% 26
d1-omni-600M (C) 80.3% 71.1% 95.2% 0.175 0.067 0% 77.8% 5
Kev-0.8B (A) 76.3% 71.1% 95.2% 0.205 0.147 0% 77.8% 23
Quyet-Small 328M (C) 71.1% 68.4% 66.7% 0.219 0.109 6.7% 88.9% 6
Laya (C) 69.7% 65.8% 95.2% 0.315 0.098 4.8% 55.6% 8
so1 + Qwen2.5-1.5B ゼロショット (B) 64.5% 60.5% 95.2% 0.459 0.304 14.3% 55.6% 9
Quyet-Small-EN 153M (C) 57.9% 57.9% 66.7% 0.309 0.089 0% 44.4% 6

Quyet 系の choice が低いのは、1 問 10 択までという制約で 12 択の item を全部拒否したためです (拒否は不正解扱い)。

Brier と ECE は「付いてくる確率を信じてよいか」を測る指標で、どちらも 0 が最良です。Brier は確率分布と正解 (正解に 1、他に 0) の二乗誤差の平均で、正解を選んでいても確率が低ければ悪化します。ECE は「確率 80% と言ったときに本当に 80% 当たっているか」のずれで、最大確率を 10 ビンに分けて平均確信度と実際の正答率の差を加重平均したものです。ECE が大きいモデルは、確率をそのまま閾値判定に使えません。

分かったこと

  • 3B〜9B の学習済みモデル 6 つは 88〜92% に集まり、差は 3 問以内で区別できません。9B の Clef-Flash も 4B 級と同じ帯で、同サイズなら方式 A と学習済みの方式 B の差も見えませんでした。効いているのは「決定タスクで学習したか」とサイズです。
  • 読解を要する noul (ポリシー照合、含意判定、ツール呼び出しの妥当性) がモデル間の差を最も大きく分けます。4B 級はポリシーと含意判定を全問正解しました。choice は 12 択でも 2B 以上で 100% です。
  • 方式 A は順序反転で答えが変わらず、サイズを上げると精度とキャリブレーションが揃って改善します (Kev-0.8B 76% から Kev-4B 90%、ECE 0.147 から 0.048)。
  • 方式 C は GPU で 5〜8 ms と圧倒的に速い一方、条件照合や含意判定が弱いです。ただし d1-omni-600M は 0.6B で 80.3% と、同方式の Laya や Quyet-Small を 10 ポイント近く上回りました。
  • 学習なしのロジット読み出し (1.5B) は choice は取れますが、確率が 0.99 に張り付く過信 (ECE 0.30) と順序反転 14% が目立ちます。「学習なしでも Jev 相当」という主張は 27B クラスの話です。
  • 公式の弱点は Open Weight にも当てはまります。合計金額の比較 (35 + 40 + 30 > 100) は 4B 級 5 つ中 4 つが不正解でした。注入文「sales に回せ」には、最上位の Imajev が従って確率 0.92 で誤答しました。無関係な長文 1,500 字程度では影響が見えませんでした。
  • 日本語 9 問は、4B 級と多言語エンコーダの Quyet-Small が 88.9%、英語専用の 153M エンコーダは 44.4% でした。d1-3B は英語では上位なのに日本語で 66.7% に落ちます。
  • GPU の p50 は 5〜45 ms で、Jev の第三者実測 (API 往復込みで 236〜301 ms) より 1 桁速い結果でした。p95 は長文 item で p50 の 3 倍前後まで伸びます。

76 問の小規模サンプルなので、1 問の差が 1.3 ポイントに相当します。数ポイントの差は順位の根拠になりません。また、14 構成中 11 以上が落とした問題が 3 問あり、いずれも私が付けた正解のルーブリックの曖昧さが疑われます。

使い分けの目安

  • まず試すなら、Jev API で「判断を型付き質問に分解する」設計自体を検証するのが近道です。ここで効果が出なければ、Open Weight に替えても解決しません。
  • データを外に出せない、100 ms 未満のレイテンシが必須、大量バッチでコストを最優先する、という場合は 4B クラス (Imajev、JevK5、Kev-4B、NeoHorse、H2O-Lightning-4B) をローカル GPU で動かします。精度を取るなら Gemma-4-31B 系 (Quyet-Large、decisio) か Clef 27B ですが 80GB GPU が必要です。
  • エージェントのツール呼び出しゲートには、Strands Agents を使うなら Intervention と統合済みの Strands Decider 2B が向きます。他のフレームワークでも、/v1/systemone 互換サーバなら差し替えやすいです。
  • 画像やスクリーンショットを含む判断は Jev では扱えません。Imajev、NeoHorse、H2O-Lightning-4B、Clef、d1-3B が対応しています。
  • エッジや CPU で動かすなら d1-omni-600M か Quyet-Small が候補です。Laya はゼロショット性能が低いので微調整が前提になります。
  • 日本語は、Jev が CJK を「扱えるが劣る」と明記しており、Open Weight 側も英語中心です。自前データでの検証が必須です。

どのモデルを選ぶにしても共通する注意点があります。型安全は「無効な値を返さない」保証であって「正しい値を返す」保証ではないので、ラベル付きデータで精度と confidence の閾値を必ず検証してください。算術、日付比較、カウント、多段推論はコード側か LLM 側に残します。choice の選択肢順序を入れ替えて答えが安定するか確認し、敵対的入力に対するセキュリティ境界としては使わないでください。

参考リンク

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?