全部LLMにしない判断設計 — ハッカソンでJevを選んだ理由

Posted at 2026-09-20

はじめに

2026年9月、TypeSafe AI が Jev を公開しました。
文章を生成せず、型付きの判断と確率を返すモデルです。公式はこれを System One モデルと呼んでいます。

機械学習を学習している側から見ると、気になるのは速さの宣伝より次の整理です。

ルールベースとの境界はどこか
ラベル付きデータがあるときの古典的な分類器と何が違うか
LLM の structured output / logprobs と何が同じで、何が違うか
そのうえで、短時間のエージェント開発に載せる意味があるか

この記事では、その使い分けを自分の前提で書き、大阪の Zenn Agentic AI ミニハッカソンで Choice / Noul を判定レイヤーに入れた理由を残します (｡･ω･｡)

想定読者

分類・キャリブレーションの話として Jev を見たい方
ルール / 古典ML / LLM のどれに寄せるか迷っている方
短時間開発で「判定だけ切り出す」必要がある方

私の属性

30代女性・事務職（エンジニアへの転職希望中）
データ分析・Kaggle を学習中（Competitions Expert）
生成AI・エージェント系のハッカソンに複数回参加
今回は Gemini（見る・書く）と Jev（判定）を分けた

結論（先に）

条件	自分の選択
if で書ける	ルール／コード
教師データが十分ある	古典的な機械学習
候補が決まっていて、意味判断が必要、学習データは無い	Jev
自由文・要約・画像理解・複雑な推論	LLM

短時間ハッカソンでは、真ん中の「候補は決まっているが、意味判断が要る／ラベルは無い」部分があったので、そこに Jev を載せました。
加えて、ハッカソン特有の制約（学習時間が無い・コスト・発表で見せるコア体験）とも噛み合いました。

同種の使い分けを表にしている記事:

Jev とは何か（一次情報）

公式発表:

押さえる点だけ書きます。

入力は state + questions。出力は型付きの判断と確率・confidence
主な型は Choice / Score / Noul
学習手法として RLCD（Reinforcement Learning for Calibrated Decisions）を挙げている
文章生成はしない。画像入力も現状は対象外
Choice の候補数には上限があり（公式まわりでは 255 の記述が多い）、それを超えると二段の選び方になる、と説明されている
速度・費用の数字は、公式の workflow evals に基づくベンダー公表値

「幻覚しない」の言い方も、型が外れないことと、判断そのものが正しいこと は別問題です。
制約された選択肢の中で間違えることはあり得ます。キャリブレーションの主張は、自分のラベルで測る前提で見ています。

ルール・古典ML・Jev・LLM

Kaggler として日常的に見る軸で並べます。

	ルール	古典ML	Jev	LLM
学習データ	不要	必要	その場の問い（ドメインFTなし）	不要（または別途FT）
出力	決定論的	ほぼ決定論的	確率的・型は固定	自由文も可
向く入力	明確な条件	十分なラベル	テキストの意味判断	生成・推論・画像など
評価で見たいもの	仕様どおりか	accuracy / F1 / calibration	同上＋閾値設計	タスク依存

ルールは書けるなら書きます。古典MLはラベルが揃っている分類の本命です。
LLM は生成と広い推論が要るときに使います。判定だけなら structured output でも近いことはできますが、毎回のゲートにフル生成を載せるのはレイテンシとパースが重いです。logit / logprobs での再現実験もありますが、API 制約や 校正されていない確率 の話は別途ついてきます。

Jev を置く隙間は、自分にとっては次だけです。

ラベルは無い／ルールでは脆い／出力候補は先に決められる／欲しいのは生成ではなく判断と確率

「数百の分類」と「十数個の判定タスク」は別物

ここを混ぜると、評価も設計もずれます。

	パターンA: クラス数が多い分類	パターンB: 判定タスクが十数個
例	数百部門への振り分け、巨大ジャンルツリー	主対象はどれか、枠を出すか、出典は妥当か
見るもの	ラベル量・クラス定義・誤分類コスト	ゲートの定義・閾値・デモで破綻しないか
本命になりやすいもの	古典ML（データがあるとき）	Jev や小さなルール＋市販判断
ハッカソン向き	弱い（学習時間が無い）	強い（候補が小さくすぐ載せる）

候補が数百あってもラベルが無ければ Jev の Choice にもできますが、候補設計と評価のコストが跳ねます。Choice のカーディナリティ上限もこの近傍で効いてきます。

自分の用途は パターンB でした。

なぜハッカソンで Jev が選択肢になるか

参加イベント:

作ったもの: 絵描きが写真資料を物体の層と関節に分け、選んだ部分を出典付きで調べるアプリ。

ハッカソン側の前提

前提	含意
ミニハッカソンは短期開発	学習時間がない。古典ML用のラベル収集・学習ループは組めない
オンラインの本戦系ではコストも評価対象になりやすい	全部を高額 LLM に載せると不利になりうる
発表ではコア体験を見せることが重要	特殊ドメインの最高精度より、一般的な判断・分類が動くデモの方が効く

この3つが揃うと、パターンBの「小さな判定ゲート」に市販の判断モデルを載せる動機が出ます。

コスト: 処理を分けて、モデルを分ける

寄せ方	判定ゲート	生成・画像理解	トークン費用の感覚
全部 LLM	LLM	LLM	ゲート回数ぶん高くなりやすい
分割	Jev（＋コード）	LLM	判定を軽い側に寄せて抑えやすい

オンラインハッカソンでコストが採点に入るなら、この分割自体が設計の一部になります ((_๑òωó)_ﾊﾞﾝ

精度: 「一般的な判断」で足りるか

発表で見るべきは「特殊作業で SOTA か」より、コア体験が通るか、判定が破綻せず説明できるか、一般的な判断としてデモに耐えるか、です。

特殊ドメインで高い精度が必須なら、自前学習（古典MLやFT）が必要になります。
一方、同じ市販モデル同士で「生成は LLM」「判定は Jev」を比べる なら、速さ・安さが実装のハードルを下げてくれます。

当日の振り分け

ルール: 座標下限や文字列一致だけでは足りないゲートがあった
古典ML: 短期では学習時間が無い
LLM: 写真理解と文章は Gemini。判定まで全部寄せるとコストとパースが重い
Jev: 候補の小さい一般判断（パターンB）に置いた

本音

理屈は上のとおりです。
ただ本音を書くと、ハッカソン直前に Jev が出てきて、使ってみたかった、もあります (´﹃｀)

流行に乗るだけ、ではなく、短期・コスト・発表という制約の中で載せる理由はあった、という整理です ((( _(　'ω')　ｺｿｺｿ

AIエージェントでの使い道

自分のアプリでは、次の三層でした（コスト節の分割と同じ考えです）。

レイヤー	担当	例
見る・書く	LLM（Gemini）	物体ラベル、まとめ文、検索回答
判定	Jev	主対象 Choice / 枠・出典の Noul
副作用	コード	閾値未満なら枠を消す、％表示、未設定ならスキップ

Jev に写真は送りません。画像理解は LLM、Jev はテキスト化した材料だけを見ます。

問いの書き方: state と questions を分ける

実装でいちばん効いたのは、材料と問いを混ぜない ことです。

置き場	入れるもの	入れないもの
`state`	判断材料（物体ラベル、枠、出典テキスト、資料区分など）	「〜してよいか」という問いそのもの
`questions`	Choice / Noul の指示と候補	長い本文のコピペ（それは state 側）

LLM の癖だと、材料と質問を1本のプロンプトにまとめたくなります。
Jev では、問いを state に書いてしまうと「判断対象の文章」として読まれやすい、という注意があります（Pydantic AI の TypeSafe 連携などでも同趣旨の説明があります）。

自分の場合も、

state … Gemini が出した JSON や、出典から抜いたスパン
questions … 「主対象はどれか」「この枠は描いてよいか」「このスパンは権利として妥当か」

と分けました。候補一覧も questions 側（Choice の criteria）に置き、コードが先に列挙します。

閾値はコード側＋フォールバック

Jev は確率を返します。何度以上なら採用するか はアプリ側の定数にしました（自分の実装では 0.7）。

Noul が閾値未満 → 枠や関節を出さない、権利スパンを採用しない、など
「0.7 未満なら却下して」を自然言語で Jev に書かせない（比較はコード）

あわせて、ハッカソン向けに フォールバック を先に用意しました。

状況	動き
`TYPESAFE_API_KEY` が無い	Jev を呼ばず、Gemini 結果や「未確認」で画面を落とさない
SDK 失敗・API 失敗	同上。デモが死なない経路を残す

判定モデルを足すほど依存が増えるので、「無いとき・落ちたとき」を先に決めておくと、短期開発では安心です。

エージェント harness でよく挙がる置き場

周辺の整理を読むと、置き場はだいたい次に収束します。

置き場	何を決めるか	型のイメージ
モデル／ルート振り分け	安いモデルか強いモデルか、人に渡すか	Choice / Score
ツール選択	既知のツール一覧からどれを呼ぶか	Choice
実行前ガード	危険な tool call を止めるか	Noul
出力・取得物の検査	RAG の出典が質問に答えているか、など	Noul
エージェント評価	LLM-as-judge の代わりにスコアする	Score / Noul

共通しているのは、プランナーでもライターでもなく、答えの集合が先に決まっている判断層 だという点です。
副作用（実行・課金・権限）はコードが持ち、Jev は確率と型付き答えまで、です。

自分の整理（分類タスクとして）

見方	要点
識別モデルとして	質問と候補を固定すれば分類器。自然言語で基準を渡せる（タスク専用再学習なし）
評価	accuracy だけでなく、確率帯ごとの正答率・閾値・レビュー費用を自分のデータで見る
ラベルがあるとき	数百クラスなら古典MLが本命。Jev はラベル無し・すぐ要る・候補が小さい側
セキュリティ	ガードレールは追加層。唯一の境界にしない

LLM-as-judge との差も表にすると、こうです。

	LLM-as-judge	Jev
返すもの	判定＋（多くの場合）理由文	型付き判断＋確率
速さ・費用	重くなりやすい	判定用途では軽く寄せやすい
改善ループ	理由文を次のプロンプトに使える	確率と閾値の設計が中心
向く場面	「なぜ」が欲しい評価・デバッグ	ゲート・振り分け・コスト制約

要するに、エージェント本体を置き換える話ではなく、ループのまわりの制御層（振り分け・検査・評価） に載せる話、という理解が自分にはしっくり来ています ψ(｀∇´)ψ

参照リンク

一次情報・製品側

何が主張で、何が未検証か

エージェント・評価・識別モデル

使い分け・実装検証・背景研究

自分の文脈

公式の「何十倍速い・安い」は、System One 向け判断タスクと、ベンダー側 workflow evals が前提です。自分のラベル・自分の遅延で測る必要があります。

まとめ

Jev は生成の代替ではなく、型付きの意味判断用。ルール／古典ML／LLM との隙間に置く
パターンA（大規模分類） と パターンB（十数個のゲート） は別問題。ハッカソン向きは後者
短期・コスト評価・発表で見せる一般判断、という軸で Jev が選択肢になる。処理分割で全部 LLM より費用を抑えやすい
エージェントでは本体ではなく、振り分け・検査・評価などの制御層。ラベルがあるなら古典ML、理由文が要る評価なら LLM judge
実装では state と questions を分け、閾値（例: 0.7）とフォールバックはコード側に置く
自分はミニハッカソンで Choice / Noul を載せた。本音としては、直前に出た Jev を触ってみたかった、もある (ﾉ´∀｀*)

m(_ _)m 読んでくれてありがとうございました (´▽｀)

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up