Jevとは何か：話すAIではなく、ソフトウェアの中で決めるAI

一般的なLLMは、質問に対して文字列を生成する。人との対話や説明文の作成には柔軟だが、業務ソフトウェアが必要とするものは、しばしば文章ではない。たとえば顧客から届いた問い合わせを「営業・サポート・請求」のどこへ送るか、優先度を何段階にするか、自動処理を続けてよいか、といった小さな判断である。

この問い合わせ振り分けを記事全体の例にする。一般的なLLMに任せる場合、入力文を読み、指定したJSONなどを生成させ、プログラム側で形式を検査する。余計な説明が混じったり、指定した形から外れたりすれば、修正や再試行が必要になる。自由文を生成できる能力を使いながら、最終的には三つの候補のどれかだけを取り出していることになる。Jevが問題にするのは、この回り道である。

既存の構造化出力は、汎用LLMの文字列生成に形式上の制約を加える考え方である。答えを機械が読みやすい形にできても、基礎には文章を順番に生成する仕組みが残る。Jevは、最初から文字列生成器ではなく、型付きの質問に確率で答える評価モデルとして設計された、とTypeSafe AIは説明する。

問い合わせの例なら、モデルに回答文を書かせるのではなく、三つの部署をChoiceとして宣言する。Jevは選んだ部署と確率を返す。優先度はScore、自動処理を続けるかはBooleanとして同時に尋ねられる。差は単に出力の見た目をJSONに整えることではない。モデルに許す出力空間そのものを、事前に定義した判断へ狭める点にある。

この設計が有効なのは、仕事をあらかじめ定義できる判断へ分解できる場合だ。分類、ルーティング、リスクや優先度の採点、処理の継続・停止、大量データに対する反復的な確認は候補になりうる。一方、自由な文章、長い説明や創作、未知の候補を見つける仕事には向かない。

重要なのは、形式の正しさと内容の正しさを分けることだ。「営業・サポート・請求」以外の値を返さないことは保証しやすい。しかし、本来は請求へ送る問い合わせをサポートへ送る誤りまでは防げない。現実の用件が三分類のどれにも当てはまらないなら、候補設計そのものが不足している。型付きであることは、判断が事実として正しいことや、候補集合が完全であることの保証ではない。

Jevは入力された状態と、型を指定した複数の質問を受け取る。問い合わせの本文を共有状態とし、「担当部署はどこか」「優先度はいくつか」「自動処理を続けてよいか」をまとめて評価するイメージである。それぞれの答えはChoice、Score、Booleanとして返され、候補には確率が伴う。

TypeSafe AIは、新しいアーキテクチャ、parallel sampler、RLCDを構成要素として挙げている。parallel samplerは、複数の判断を文字列のように一語ずつ順番に生成せず、並列に評価する仕組みと説明される。RLCDは、校正された意思決定を学ぶための手法という位置づけである。ただし、ネットワーク構造、学習目的、報酬の作り方、学習手順の詳細は公開されていないため、各要素が具体的にどう働くかは検証できない。

確率が付く意義は、答えを並べることだけではない。ソフトウェア側で基準を設け、十分に確からしい判断だけを自動実行し、不確かなものを人へ回せる。問い合わせの振り分けなら、高い確率で請求と判断したものだけ自動転送し、判断が割れたものは担当者が確認する、という使い方になる。

ただし、ここで必要なのは確率校正である。モデルが90%と答えても、そのような事例の約90%が正しいとは限らない。過信するモデルでは、確率による振り分けがかえって危険になる。TypeSafe AIは校正を設計目標に掲げるが、一般的な公開ベンチマークや、独立した校正評価は示していない。したがって、確率を返せることと、その数値を運用上信頼できることは、現在の証拠では別の主張である。

TypeSafe AIのworkflow evalは、複数の判断を含む同じ処理の流れをJevと外部モデルに実行させる。LLM側には、Jevと同様の型付き判断を返すためのラッパーを用いる。比較対象に同じ仕事をさせ、処理全体の遅延と費用を見る考え方は、単一の質問だけを比べるより実際の利用場面に近い。

一方、判断品質の基準には、人が確認した正解ラベルではなく、二つの大型外部モデルによる平均予測が使われた。したがって測っているのは、現実の正解や業務上の価値そのものではなく、参照モデルの予測へどれだけ近いかである。参照モデルにも共通の偏りや誤りがあれば、それに近いモデルが高く評価されうる。この評価から、問い合わせが正しい部署へ届く割合を直接読み取ることはできない。

評価では、Jevと一般的なLLMに同じ型付きworkflowを処理させるため、自由生成を必要としない仕事における効率差を見ることができる。しかし、その差が新しい学習法によるものか、問題を閉じた分類へ狭めた効果か、文字列出力をなくした効果か、サービス提供の最適化かは分離されていない。

また、課題を作ったチームとJevを開発した組織は同じである。TypeSafe AI自身も、最大の速度・費用差は実運用で得られる改善の高い側だと説明している。モデル構造、規模、学習データ、学習計算量、詳細な比較条件が公開されておらず、第三者が同じ評価一式を再現できる状態ではない。比較は有望な製品仮説を示すが、一般的な優位を確立するものではない。

公開情報には、RLCD、新しいアーキテクチャ、並列処理、出力範囲の制限が、それぞれ結果へどれだけ寄与したかを分けるアブレーションがない。Jevの利点がモデル自体の判断能力から来るのか、用途に合わせて不要な生成処理を外したことから来るのかは判別できない。

これは設計の価値を否定する話ではない。問い合わせ振り分けのような仕事で、狭い出力が十分なら、問題を狭めたこと自体が有用な設計判断になりうる。ただし研究上の説明としては、専用の分類モデル、構造化出力を使うLLM、Jevを同等の条件で比べ、判断品質、確率校正、遅延、費用を同時に見る必要が残る。現在の資料だけでは、その比較を再構成できない。

TypeSafe AIは、workflow evalの一部で、Jevが外部モデルを使うSystem One LLM wrapperより最大193.6倍高速、444.6倍安価だったと報告している。応答時間は70〜500ミリ秒で、System One型の問い合わせでは40〜200倍高速になりうるとも説明する。いずれも開発元による測定であり、独立して再現された結果ではない。

数字を読むときは「最大」に注意したい。全条件の平均的な改善を意味せず、発表者も実運用利得の高い側だとしている。さらに、比較は自由文を必要としない型付きworkflowで行われている。したがって、この倍率を一般的な文章生成や、あらゆるLLM利用へ広げることはできない。確認されている外部の事実は、Vercel AI GatewayからChoice、Score、Booleanの評価モデルとして利用できることまでであり、性能差の独立検証ではない。

第一の境界は、選択肢を事前に定義できるかである。問い合わせの種類が安定しており、部署や優先度を列挙できるならJevの形式と合う。新しい相談内容を発見したい場合や、相手へ詳しい説明を書きたい場合は合わない。第二の境界は、判断の誤りをどこまで許容できるかである。低リスクな振り分けでは人への差し戻しを組み合わせられるが、根拠の追跡が必要な高リスク判断には不向きとされる。

候補の作り方にも失敗がありうる。現実の問い合わせに「該当なし」があるのに三部署しか用意しなければ、モデルは不適切な候補から選ばざるをえない。出力形式が壊れないことは、この欠落を知らせてくれない。適用可能性はモデルの速さだけでなく、業務を閉じた選択肢として妥当に表現できるかに左右される。

査読論文または技術報告、モデル重み、学習データ、学習計算量は公開されていない。一般的な公開ベンチマーク、独立した確率校正評価、各構成要素のアブレーションもない。このため、別の業種や入力分布でも判断品質と確率が保たれるかは分からない。型違反が起きないという性質から、意味上の正確さや過信の少なさを導くこともできない。

評価課題が提供者自身によって作られ、正解の代わりに特定の外部モデルの平均予測を使う点も、結論の範囲を狭める。Jevが参照モデルに似た予測を効率よく返す可能性は示せても、人間が確認した正解、業務損失、利用者への影響において優れるとはまだ言えない。発表段階では「高速で安価な判断モデル」という主張と、「正しく信頼できる判断モデル」という主張を分けて扱う必要がある。

次の焦点は、異なる組織の実データでも確率が校正されるか、入力の傾向が変わったときに自信が適切に下がるか、候補集合に答えがない場合を検知できるかである。問い合わせの例なら、部署の正解率だけでなく、高い確率で誤送信した件数、判断を人へ戻した割合、確認を含む処理全体の費用を見る必要がある。

同じ業務ログと比較条件を使い、構造化出力を行うLLM、専用分類モデル、Jevを測れば、速さと判断品質の交換関係が見えやすくなる。さらに、モデル構造、学習方法、評価手順が公開されれば、報告された差の原因を切り分けられる。それまでは、Jevは利用可能な型付き判断サービスであり、興味深い設計提案ではあるが、一般的な性能優位が確立した研究成果としてではなく、独立検証を待つClosed Researchとして読むのが妥当である。