System One モデルとは何か、そして何ではないのか

System One モデルとは、テキストではなく判断を返すために作られたモデルです。 state と、あらかじめ取りうる答えを定義しておいた質問を送ると、確率付きの型付きの値が返ってきます。引用すべきは TypeSafe 自身の定義です。「System One モデルは、ソフトウェアがそのまま利用できる、高速で構造化された判断を行うために作られた AI モデルの一群です。」

Jev はその最初のモデルです。以下では、それによって何が変わり、何が変わらないのかを正確に述べることを試みます。Jev について出回っている情報の多くはベンダーの主張であり、一部には異論もあるため、各主張には出典を明記しています。

名前はあえて扱いにくいものになっている

「System One」は Kahneman の Thinking, Fast and Slow に由来します。System 1 は速く直感的、System 2 は遅く熟慮的な思考です。TypeSafe はこの名前に潜む落とし穴も認めています。「System 1 思考」という言葉には誤りやすいという含意もあるからです。それでも、深さよりも速さと再現性が求められる判断にとっては、このトレードオフには価値があると主張しています。

そこから導かれる枠組みが 「非構造化の state を入力し、型付きの確率的な判断を出力する」 です。この一文がプロダクトの主張のすべてであり、Jev に関するあらゆる主張はこの一文に照らして検証する価値があります。

学習方法：RLCD

TypeSafe は事後学習の道筋を 3 つ挙げ、自社の手法を 3 番目に位置づけています。

RLCD は Reinforcement Learning for Calibrated Decisions の略です。学習目標は「人が気に入る答えを出す」ことではなく、「言葉どおりの意味を持つ確率を返す」ことです。つまり、0.2 を割り当てた結果はおよそ 20% の頻度で起こり、0.8 を割り当てた結果はおよそ 80% の頻度で起こるべきだ、ということです。

この主張について、注目すべき点が 2 つあります。

• キャリブレーションは集団の性質であり、個々の回答に対する保証ではありません。 TypeSafe 自身もこの注意書きを述べています。これらの比率は予測の集団を表すものであり、個々の回答を表すものではありません。よくキャリブレーションされた 0.9 でも、目の前の事例では外れることがあります。
• 動機は RLHF への批判です。 TypeSafe は、選好の最適化が迎合や自信ありげな作り話に報酬を与えうること、そして mode dropping ——モデルが特定のスタイルを好み、他の妥当な出力の確率を押し下げてしまう現象——を引き起こすことを主張しています。そこから、出力が人にとって説得力があっても、無人の自動化に使えるほど信頼できるとは限らない、という枠組みが生まれています。

運用上重要なベンダーの主張がさらに 2 つあります。Jev は顧客ごとにファインチューニングされません。同じ重みがすべてのアカウントに提供され、ドメイン固有の振る舞いはアカウントごとの重みではなくリクエスト（state、指示、基準）から生まれます。そして、顧客データは学習に使われません。

言語モデルとの違い

ベンチマークの取り方ではなく、構築の仕方を変える違いは次のとおりです。

ここから直接 2 つの帰結が導かれます。

質問を追加してもレイテンシはほとんど増えません。 質問は同じ state に対して並列に評価されるため、質問を 1 つから 12 に増やしても応答時間はほとんど変わりません。これは 1 回の呼び出しで 1 つの判断を行う LLM の習慣とは正反対であり、その上に何かを構築する人にとって最大の構造的な違いです。

信頼度の値こそが要点です。 言語モデルに信頼度スコアを求めることはできますが、自分が生成していない分布からそれを導き出すことはできません。ここでは、その数値はあなたが宣言した選択肢全体にわたる実際の確率質量から得られます。だからこそ、しきい値を設定できる値になるのです。

何ではないのか

ほとんどの解説が省略する部分ですが、Jev があなたに適しているかどうかを決めるのはこの部分です。

• LLM のそのままの代替ではありません。 ファーストパーティの統合を提供した LangChain ははっきりと述べています。Jev はテキストを生成せず、エージェントを動かしている既存のモデルの代わりではなく、それを補完するものとして理解するのが最善だ、と。
• 何も書けません。 返信の下書きも、コード生成も、文章による要約も、会話もできません。
• 選択肢を列挙できない質問には答えられません。 取りうる答えを列挙できないなら、立てるべき Choice の質問がなく、そのタスクは Jev のタスクではありません。
• 精度は互角であって、優位ではありません。 TypeSafe 自身のワークフロー評価では、Jev は 67.8%、GPT-5.6 Terra は 67.9% で、統計的には引き分けです。1 サンプルあたりの所要時間は約 0.4 秒 対 10.1 秒で、コストはごく一部です。同じハーネスで、より強力なフロンティアモデルは 74.1% を記録しました。Jev を選ぶ理由は、同等の精度でのコストと速度であって、精度そのものではありません。

独立した検証が乏しいところ

キャリブレーションは中心的な主張であり、だからこそ最も懐疑的に見るべきです。正直に言えば、独立したテストはまだ初期段階で、結果は実際にまちまちです。

• ある 事前登録された研究 では、Jev は 2 つのデータセットで強くキャリブレーションされていた一方、3 つ目のデータセットではキャリブレーションが悪い という結果でした。Brier スコアは比較対象の 0.668 に対して 0.846 で、16% の事例では正解ラベルに確率 0 を割り当てていました。
• LessWrong の AI コントロールのパイロット では、Jev はバックドアをうまく順位付けできた（AUROC 0.976、偽陽性率 2% で 90% を検出）一方、明らかに過小な信頼度を示しました。つまり、生のスコアは優れた 順位 ではあっても、優れた 確率 ではありません。このパイロットの詳細は Jev as a Judge で解説しています。
• ベンダー自身のベンチマークの一致度の測り方も批判されています。独立した正解データとの比較ではなく、他のフロンティアモデルとの一致を測っているからです。

実務的な読み方は次のとおりです。生の信頼度はまず順位付けのシグナルとして扱い、しきい値は自分のデータに対してのみキャリブレーションしてください。 他人のワークロードから写したしきい値は推測にすぎません。JevStation のプレイグラウンド が勝った答えだけでなく確率分布全体を表示しているのもこのためです。数値そのものよりも、分布の形のほうが多くを語ります。

タスクが適しているかを判断する方法

次の 3 つの条件がすべて満たされている必要があります。

1. 答えの空間を事前に列挙できること。 選択肢を列挙できなければ、型付けすべき質問がありません。質問の書き方は Jev が答えられる質問の設計 で解説しています。
2. 同じ判断を繰り返し行うこと。 一度きりの判断では、調整可能なしきい値の恩恵を受けられません。
3. 信頼度スコアに基づいて行動できること。 高い帯では自動で実行し、それ未満は人に回す。これが価値のすべてです。すべての回答を結局人が見るのなら、ボトルネックは安いモデルではありませんでした。

3 つすべてが満たされるなら、コスト面の主張は強力です。計測した評価 は $0.000012 から $0.000377 で、それぞれがコードで直接分岐できる値を返します。いずれかが満たされないなら、汎用モデルや別の分類器 のほうが適したツールであり、レイテンシ上の優位がいくらあってもそれは変わりません。

出典

ベンダーの主張と独立した検証を照らし合わせられるよう、主張ごとに出典を示します。

• 定義、RLCD、RLHF/RLVR の区別、キャリブレーションの注意書き、学習データのポリシー — TypeSafe の機械学習入門 と ローンチ記事 （ベンダー）
• 「そのままの代替ではない」、並列評価、統合の形 — LangChain （第三者、ただし統合の作者）
• 比較表、70〜500 ms のレイテンシ、精度の数値 — TypeSafe の ローンチ記事 と dev.to の評価 （それぞれベンダーと独立）
• キャリブレーションの結果 — jev-benchmarks と LessWrong （独立）
• モデルの識別情報と API の形 — TypeSafe のドキュメント