システム1モデルとは何か｜JEVがLLMと根本的に違う理由
この記事の要点
- JEVは文章を生成しません。チャットもできず、理由の説明もできません。TypeSafe AIはこれをLLMの改良版ではなく、別の種類のモデル、すなわちシステム1モデルだと位置づけています。
- 名前の由来はダニエル・カーネマンの二つの思考です。システム1は速く直感的な判断、システム2は遅く熟慮を要する推論。これまでのLLMはすべてシステム2を目指してきました。
- JEVは状態（state）と型付きの質問を受け取り、型付きの値を返します。選択肢から1つ選ぶ
choice、段階で採点するscore、はい/いいえの確率を返すnoulの3種類だけです。 - 応答は70〜500ミリ秒（TypeSafe AI発表）。トークンを1つずつ生成しないため、複数の質問が並列に評価されます。
- 「ハルシネーションしない」の意味は限定的です。保証されているのは型を壊さないことであって、答えが常に正しいことではありません。ここを取り違えると設計を誤ります。
- FastMetalでも、JEV（
typesafe/jev-1.13）を1回0.1円の定額で利用できるようになりました（提供開始のお知らせ）。
ソフトウェアが下している判断のうち、本当に「考える」必要があるものはどれだけあるでしょうか。この問い合わせは請求に関するものか、技術に関するものか。この出力はルールに違反しているか。次に呼ぶべきツールはどれか。
どれも一瞬で決まる種類の判断です。それなのに現在の実装では、こうした判断のほとんどが大規模言語モデルへの問い合わせになっています。数百トークンの推論を生成させ、最後に一語のラベルを受け取る。その一語のために、数秒と相応のコストを払っているわけです。
2026年9月、ステルス状態を脱したTypeSafe AIが公開したJEVは、この構造そのものに手を入れたモデルです。
カーネマンのシステム1とシステム2
出発点は行動経済学です。ノーベル経済学賞を受賞したダニエル・カーネマンは、著書『ファスト＆スロー』（原題 Thinking, Fast and Slow）で、人間の思考を二つの系統に分けました。
| システム1 | システム2 | |
|---|---|---|
| 速度 | 速い | 遅い |
| 性質 | 直感的・自動的 | 論理的・意識的 |
| 負荷 | 努力を要しない | 努力を要する |
| 例 | 表情から感情を読む、2＋2を答える | 確定申告をする、複雑な文章を書く |
顔を見て不機嫌だと察するのがシステム1、税額を計算するのがシステム2です。人間は日常のほとんどをシステム1で処理し、必要なときだけシステム2を起動します。
ここ2年ほど、フロンティアモデルの開発は一方向に進んできました。思考の連鎖（Chain of Thought）を長くし、思考予算を増やし、回答前により深く推論させる。これはすべてシステム2を強化する試みです。実際、推論モデルは答えを返すまでに数分かける場合もあります。
TypeSafe AIが指摘したのは、その反対側が空いているという点でした。
ソフトウェアの判断の大半は、システム2を必要としない
問い合わせの分類に30秒は要りません。緊急かどうかの判定に思考の連鎖は不要です。それでも推論モデルに投げれば、モデルは律儀に考え、文章を生成し、最後にラベルを出します。
推論モデルに「一語で答えて」と指示してJSONで包むことはできます。ただしその場合も、一語のラベルを得るために大量のテキストを生成する遅延コストは払っています。
さらに厄介なのが、返ってくる数値の性質です。LLMに「確信度を0から1で出力して」と頼むと、確かに数値は返ってきます。しかしそれは確率分布ではなく、0.9 という文字列を生成しているにすぎません。LLM-as-a-Judgeの評価値が特定の値に偏りやすいのは、このためです。
JEVは状態を渡し、型付きの値を受け取る
TypeSafe AIの創業者はDiogo Almeida氏です。同氏はOpenAIで、言語モデルが指示に従えるようにする手法づくりに携わってきました。モデルを人間との対話に適応させた側の人物が、次に取り組んだのが「対話をしないモデル」だったわけです。
同氏の問題意識は明快です。チャットはソフトウェアにとって正しいインターフェースではない。ソフトウェアが欲しいのは段落ではなく、そのまま使える値です。
JEVの使い方は、関数呼び出しに似ています。渡すものは2つだけです。
- state。判定したい非構造データです。問い合わせ本文、エージェントのトレース、ログ、JSONなどが入ります。
- questions。型付きの質問の集合です。
返ってくるのは、パースすべきテキストではなく、型付きの値と確率です。
LLMとJEVの構造的な違い
| LLM | JEV（システム1モデル） | |
|---|---|---|
| 出力 | 文字列・生成テキスト | 型の決まった構造化された値 |
| 生成方式 | トークンを逐次生成 | 並列サンプリング（1回のクエリで全出力） |
| 応答時間 | 数秒から、推論モデルでは数分 | 70〜500ミリ秒（TypeSafe AI発表） |
| 出力の課金 | 入力より高い単価が一般的 | TypeSafe AIは課金対象外としています |
| 確信度 | 生成されたテキストとしての数値 | 較正された確率 |
| 対話 | できる | できない |
choice・score・noulの3つの質問型
JEVに投げられる質問は3種類しかありません。この制約が型保証の根拠になっています。
choice
選択肢を渡し、1つ選ばせます。返ってくるのは選ばれた選択肢と、全選択肢それぞれの確率です。問い合わせを「請求・技術・営業」に振り分ける、といった用途がこれにあたります。
score
定義した段階で採点させます。「平静・やや不満・強い不満」のように基準を低い順に並べると、その段階の番号（0始まり）の尺度で小数のスコアが返ります。3段階なら0〜2の間の値です。
noul
はい/いいえの質問に対し、はいである確率を返します。「これは期限に言及しているか」「これは緊急か」「この出力は規約に違反しているか」。
質問は小さく分解する
設計の勘所は、大きく曖昧な質問を1つ投げないことです。「このピッチを評価して」ではなく、「実現可能性はどの程度か」「狙っている市場はどの類型か」と、小さな直感的な問いに分解します。分解した結果は通常のコードで合成できるため、判断基準を変えたいときはプロンプトではなく数値を書き換えるだけで済みます。
複数の質問は1回のリクエストで並列に評価されます。逐次的に積み上がらないので、質問を増やしても応答時間はほとんど変わりません。
実際に使ってみる
FastMetal経由で、日本語の問い合わせに3種類の質問を同時に投げてみました。
curl https://api.fastmetal.ai/openrouter/decisions/jev-1-13 \
-X POST \
-H "Authorization: Bearer $FASTMETAL_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"state": "お客様からの連絡: 昨日注文した商品がまだ届きません。明日の会議で使う予定なので、今日中に届かないなら返金してください。",
"questions": {
"intent": {
"type": "choice",
"instructions": "お客様が求めていることは何か",
"criteria": {"refund": "返金を求めている", "track_order": "配送状況を知りたい", "other": "それ以外"}
},
"is_urgent": {
"type": "noul",
"instructions": "至急の対応が必要か",
"criteria": {"true": "期限が迫っている", "false": "急ぎではない"}
},
"frustration": {
"type": "score",
"instructions": "お客様の苛立ちの強さ",
"criteria": ["落ち着いている", "やや不満", "強い不満"]
}
}
}'
返ってきた回答です。
{
"model": "typesafe/jev-1.13-20260917",
"answers": {
"intent": {
"type": "choice",
"choice": "refund",
"probabilities": {"other": 0.03, "refund": 0.95, "track_order": 0.02},
"confidence": 0.93
},
"is_urgent": {"type": "noul", "noul": 0.95},
"frustration": {
"type": "score",
"score": 1.4,
"legend": {"0": "落ち着いている", "1": "やや不満", "2": "強い不満"},
"probabilities": {"0": 0.01, "1": 0.59, "2": 0.4},
"confidence": 0.39
}
},
"usage": {"input_tokens": 506, "output_tokens": 74}
}
東京のサーバーから同じリクエストを3回送ったところ、応答までの時間はゲートウェイを含めて0.26〜0.57秒でした。返金の意図と緊急性ははっきり判定され、苛立ちの強さは「やや不満」と「強い不満」の間の1.4で、確信度は0.39と低めに出ています。判断が割れるところでは、確信度の低さとしてそれが見えるのが、文字列で数値を返すLLMとの違いです。
速度と課金の考え方
| 項目 | 内容 |
|---|---|
| 応答時間 | 70〜500ミリ秒（エンドツーエンド、TypeSafe AI発表） |
| 入力 | 100万トークンあたり課金（TypeSafe AIの価格） |
| 出力 | TypeSafe AIは課金対象外としています |
| 速度 | 同種のタスクで既存モデルの40〜200倍（TypeSafe AI発表） |
| FastMetalでの料金 | 1回0.1円の定額 |
出力が課金対象外である理由は、そもそもトークンを生成していないからだと考えるのが自然です。これは値引きではなく、アーキテクチャの帰結です。
この水準まで下がると、これまで「1件あたりのコストが見合わない」という理由で成立しなかったワークフローが成立します。分類を数十回重ねる処理も、現実的な選択肢になります。
較正された判断のための強化学習（RLCD）
TypeSafe AIは技術的な詳細をほとんど公開していませんが、3点は明かしています。新しいモデルアーキテクチャ、並列サンプラー、そしてRLCD（Reinforcement Learning for Calibrated Decisions）と呼ぶ学習手法です。
現行のLLMはRLHF（人間のフィードバックによる強化学習）やRLVR（検証可能な報酬による強化学習）で訓練されます。RLHFが最適化するのは人間の好みであり、これがモデルを流暢で自信ありげにする一方、機械が使う判断器としては扱いにくくします。
RLCDが最適化するのは、較正された判断です。確信度が高いほど実際の正答率も高い、という対応関係が成り立つことを指します。
何に使えるのか
判断が挟まるところなら、どこでも候補になります。
- モデルルーティング。入ってきたタスクの難易度を判定し、軽いモデルと重いモデルに振り分けます。
- ガードレール。ツール実行の前に危険度を判定します。
- 問い合わせトリアージ。優先度と担当部署を同時に決めます。
- ツール選択。どのツールを呼ぶべきかを決めます。
- コンテンツ判定。スパム、個人情報（PII）、プロンプトインジェクションを検出します。
- コードレビュー補助。安全か否かの一次判定を行います。
LangChainはすでに TypeSafeClassifier として統合を公開しており、2つのミドルウェア実装を示しています。複雑さに応じてモデルを切り替える ModelRouterMiddleware と、ツール呼び出しの危険度を実行前に評価する AutoModeMiddleware です。
同社が示した構図は明快です。開放的な推論と生成にはLLMを、その途中で挟まる高速な構造化判断にはJEVを使う。JEVはLLMの置き換えではなく、エージェントループの中の判断ノードとして置かれます。
誤解しやすい3つの点
ここは正確に押さえておく価値があります。
「ハルシネーションしない」の範囲
保証されているのは型を壊さないことです。壊れたJSONを返さない、存在しないツール名を発明しない、渡していない選択肢を出さない。これは構造上の保証であり、検証も容易です。
一方で、選択そのものを誤ることはあります。型は正しいが答えが違う、という状態は起こりえます。ここを「間違えないモデル」と読み替えてしまうと、検証なしで本番に載せることになります。
決定論ではありません
同じ入力でも出力はわずかに揺れます。確率的な処理である以上、複数回呼べば数値は変動します。傾向としては安定していますが、if 文と同じ意味での再現性を期待すべきではありません。
引数は抽出しません
ツール選択に使えますが、返ってくるのは「どのツールか」だけです。そのツールに渡す引数の抽出は行いません。引数まで必要な場合は、従来のfunction callingが引き続き必要です。
また、入力が極端に短いと確信度は下がる傾向があります。2〜3語では判断材料が足りません。
システム1とシステム2は競合しない
ここが実務上いちばん重要な点です。
システム1モデルは、LLMの代わりになるものではありません。文章を書く、コードを書く、要約する、対話する。これらはすべてシステム2の仕事であり、JEVには一行も書けません。
実際のエージェントには両方が必要です。生成と推論を担うシステム2、その周囲で高速に判断を下すシステム1。この二層構造が、AIを組み込んだソフトウェアの標準的な形になっていく可能性があります。
FastMetalでは、この両方の層をひとつのAPIキーと円建ての残高で使えます。システム2の側はモデル一覧にあるLLMをOpenAI互換のAPIで、システム1の側はJEVを専用のエンドポイントで呼び出します。JEVは入力の量ではなく1回0.1円の定額で課金されます。そのかわり、リクエスト本文は8KB・質問は16件までに固定されています。料金と上限はJEV 1.13 提供開始のお知らせに、使い方と制限の詳細は構造化判定（Decisions）のドキュメントにまとめています。
判断をシステム1に逃がし、生成をシステム2に任せる。その設計を、同じキーのまま試せます。
よくあるご質問
システム1モデルとLLMは、どちらが優れているのですか
比較の対象になりません。用途が異なります。文章を書く、説明する、対話するといった仕事はLLMにしかできません。逆に、分類・採点・真偽判定のような一瞬で決まる判断では、システム1モデルが桁違いに速く安価です。
JEVをチャットに使えますか
使えません。JEVはテキストを生成しないため、対話も、理由の説明もできません。返るのは型付きの値と確率だけです。FastMetalでも、チャット画面ではなくAPIから呼び出す形になります。
JEVはFastMetalで使えますか
使えます。モデルIDは typesafe/jev-1.13、エンドポイントは https://api.fastmetal.ai/openrouter/decisions/jev-1-13 で、1回0.1円の定額です。他のモデルと同じAPIキーと残高で利用できます。
日本語の入力でも使えますか
使えます。この記事の例は日本語の問い合わせ文を判定させたものです。ただし日本語の業務データでの精度は、ご自身のデータで評価されることをおすすめします。
なぜ出力トークンが課金対象外なのですか
トークンを生成していないためです。JEVは自己回帰的にトークンを1つずつ出力する仕組みを持たず、1回の処理で全出力を並列に確定させます。課金対象が入力側にしか存在しない、というのが実態に近い説明です。FastMetalではこれを1回あたりの定額にまとめています。