はじめに
最近のAIモデルの発表というと、だいたい「またLLM（大規模言語モデル）の新バージョンか」という受け止め方をされることが多いんじゃないでしょうか。
パラメータ数が増えました、ベンチマークが伸びました、推論速度が上がりました。
中身のアーキテクチャは基本的にトランスフォーマーの自己回帰生成（前の単語から次の単語を予測し続ける仕組み）のままで、進化はあくまでその延長線上にあります。
そんな中、2026年9月15日にTypeSafe AIというスタートアップが出した発表が、ちょっと毛色が違っていました。
「LLMではない新しいクラスのモデル」 だそうです。
エンジニアとしては「それって結局ただの分類器では」と疑いたくなる気持ちもありつつ、公式ブログを読んでみたら、それなりに筋の通った設計思想でした。それ以上に、業界全体がLLM一強という空気になっている中で、あえて別の道を選んで勝負を挑んでいること自体、素直にすごいと感じます。技術的に整理してみます。
何が起きたのか
TypeSafe AIは公式ブログで、System One Modelsという新しいモデルの分類と、その第一弾となるJevというモデルを発表しました。
Models have been superhuman at chat for years, so where is all the automation?
（チャットに関してモデルはもう何年も人間を超えているのに、なぜ自動化はここまで進んでいないのか）参考：TypeSafe AI公式ブログ「Introducing System One Models & Jev」 https://typesafe.ai/blog/introducing-system-one-models-and-jev
創業者のDiogo Almeida氏は、OpenAIでInstructGPT（人間のフィードバックでモデルをinstruction追従型に鍛える手法）の論文を共著し、ChatGPTのクレジットにも名前が載っている人物です。
Almeida, TypeSafe's co-founder and CEO... co-authored OpenAI's 2022 InstructGPT paper... His name also appears in OpenAI's credits for the original ChatGPT release
参考：runtimewire「TypeSafe opens Jev early access for fast, typed AI decisions」 https://runtimewire.com/article/typesafe-jev-system-one-ai-model-early-access
そんな人物が「チャット向けのモデルは十分賢いのに、自動化に使おうとすると途端に扱いづらくなる」という課題意識から、あえてチャット（文字列生成）を捨てたモデルを作った、というのが今回の発表の骨子です。ChatGPTの土台を作った側の人間が、自らその路線に疑問を投げかけて新しい選択肢を作りに行く、というのはなかなか胆力のいる決断だと思います。現在は早期アクセス（限定公開のテスト運用）として提供が始まっている段階です。
この章のまとめ
- TypeSafe AIが「LLMではない新カテゴリ」としてSystem One Modelsを発表
- 第一弾モデルはJev、現在は早期アクセス中
- 創業者はOpenAIでChatGPTの土台技術に関わった人物
Jevのアーキテクチャを技術的に見る
いちばん気になるのは「LLMではない」の中身です。
普通のLLMは自己回帰（前に生成した単語を踏まえて次の単語を1つずつ予測する仕組み）でトークンを1個ずつ順番に生成します。だからこそ文章としては自然な出力になりますが、裏を返すと「1個ずつ律儀に予測し続ける」処理なので時間がかかりますし、たまに文脈から外れた出力（いわゆるハルシネーション）もしてしまいます。
Jevはここを根本から変えていて、公式ブログによると次のような設計になっています。
- 並列サンプラー：文字列を1トークンずつ生成するのではなく、あらかじめ定義された選択肢や確率を一括で計算して出力する仕組み
- 型付き構造化出力：出力形式（「はい/いいえ」や「怒りレベル1〜5」など）を事前にスキーマとして定義し、その型からはみ出す出力が構造上そもそも発生しない設計
- RLCD（Reinforcement Learning for Calibrated Decisions）：人間の好みに合わせる従来のRLHF（人間のフィードバックを使った強化学習）ではなく、「その判断がどれくらい確からしいか」という確率の精度自体を最適化する独自の強化学習手法
自己回帰をやめて並列サンプリングに切り替える、というのは口で言うほど簡単な決断ではありません。既存のトランスフォーマー系の学習・推論の資産をかなり作り直す必要があるはずで、わざわざそこに手を出した点は、単なる差別化のためのマーケティング的な選択ではなく、本気で設計思想からやり直した結果に見えます。
公式ブログでは「フロンティア級の知能を持った関数呼び出し」という表現をしています。
Think of Jev as a frontier-intelligence function call: unstructured state in, typed probabilistic decisions out.
（Jevは、非構造化データを渡すとフロンティア級の知能で型付き確率判断を返す関数だと考えてほしい）参考：TypeSafe AI公式ブログ「Introducing System One Models & Jev」 https://typesafe.ai/blog/introducing-system-one-models-and-jev
イメージをつかむために、公式が紹介している「カスタマーサポートの怒り検知」の例をもとに、リクエスト/レスポンスの形を再構成してみます（※実際のAPI仕様そのままではなく、公式説明をもとにしたイメージです）。
// リクエストイメージ
{
"state": "顧客からの問い合わせ本文（要約テキスト）",
"questions": {
"is_angry": "この顧客は怒っていそうか？",
"churn_risk_level": "解約リスクのレベルは？(low/medium/high)"
}
}
// レスポンスイメージ
{
"is_angry": { "probability": 0.9 },
"churn_risk_level": {
"low": 0.1,
"medium": 0.3,
"high": 0.6
}
}
普通のチャットボットなら「お客様は大変お怒りのようですね、返信文を作成しましょうか」と長文で返してくるところを、Jevは確率つきの数値だけを即座に返す、という設計です。
Say you're building software that prioritizes customer service requests... Jev might answer 0.9, which means there's an estimated 90 percent probability that the answer is yes
参考：Every「mini vibe check: typesafe's jev judged everything i've written in 0.7 seconds」 https://every.to/also-true-for-humans/mini-vibe-check-typesafe-s-jev-judged-everything-i-ve-written-in-0-7-seconds
ソフトウェアに組み込む用途では「自然な文章」より「型が保証された数値」のほうが扱いやすい、というのがこの設計の核心だと思います。LLMの出力をコードから使おうとすると、JSONっぽい文字列をパース（構文解析）してバリデーション（検証）して、というひと手間が必ず必要でした。しかもその過程で「たまに変な形式で返してくる」という不確実性がつきまといます。Jevはその不確実性自体をアーキテクチャレベルで消してしまおう、という発想です。
この章のまとめ
- Jevは1トークンずつではなく並列で確率を計算する方式
- 出力はあらかじめ定義した型のスキーマに固定される
- RLCDという独自の強化学習で「確率の精度」自体を最適化している
既存LLMとどう違うのか数値で比較する
公式ブログのベンチマークを表にまとめました。
| 項目 | 既存LLM | Jev（System One） |
|---|---|---|
| 応答時間 | 3秒〜329秒 | 70ミリ秒〜500ミリ秒 |
| 入力コスト | $0.20〜$10 / MTok（100万トークンあたり） | $0.042 / MTok |
| 出力コスト | 入力の約5倍が目安 | 無料（課金対象外） |
| サンプリング | 逐次（トークンを1つずつ生成） | 並列（一括で確率を計算） |
| 出力形式 | 自由な文字列（要パース・バリデーション） | 事前定義された型付き構造化データ |
| 型エラー | パース失敗などで発生しうる | スキーマ制約により原理的に発生しない |
参考：TypeSafe AI公式ブログ「Introducing System One Models & Jev」 https://typesafe.ai/blog/introducing-system-one-models-and-jev
数字で見ると、入力コストは最も高価なLLMと比べて最大で200倍以上安い計算になります。出力に至っては無料なので、単純比較すると1件あたりのコストは既存LLMとは桁が違う水準です。
命名にも設計思想が表れていて、社名に近い「System One」は心理学者ダニエル・カーネマンの著書『ファスト&スロー』に登場する、直感的で高速な「システム1思考」から取っています。LLMの深く考える「システム2」的な役割に対して、Jevは反射的で高速な判断だけに特化したモデル、という位置づけです。
一方で変わっていない部分もあります。文字列を自由に生成する能力そのものは手放しているので、雑談したり長文を書いたりという用途には使えません。あくまで「あらかじめ決められた種類の判断」を高速に返すことに全振りしたモデルで、LLMを置き換えるものではなく役割分担する存在として設計されています。
「なんでもできる汎用モデル」を目指すのが最近の主流だった中で、あえて用途を絞り込んで尖らせる、という逆方向の選択をしたこと自体が挑戦だと思います。こういう選択肢が増えること自体、技術業界全体にとって良いことなんじゃないでしょうか。LLM一択の世界だと、どうしても「LLMで無理やり解決する」という発想に寄りがちですが、選べる道具が増えれば、課題ごとに適した手段を選ぶという当たり前の設計判断がしやすくなります。
この章のまとめ
- コストは既存LLMより大幅に安く、速度も数十〜数百倍速い
- ただし自由な文章生成はできず、あくまで「判断特化」
- LLM（システム2寄り）とJev（システム1寄り）は競合ではなく役割分担の関係
現場エンジニアとしての正直な感想
ここからは実務目線での話です。
まず良さそうな点は、既存のコードに「あいまいな判断が必要なif文」を安全に組み込めるようになりそうな点です。公式ブログでも「AIを使ったワークフロー」や「あいまいなif文」という表現をしていて、これまで人手やルールベースの条件分岐で頑張っていた部分を、確率つきの判断に置き換えられる可能性を示しています。
一方で気になるのは、ベンチマークの大半が自社発表の数値である点です。外部メディアも「TypeSafeの主張はTypeSafe自身の数値に基づく」と釘を刺しています。
TypeSafe's case is credible enough to test, but its benchmark claims still come from TypeSafe.
参考：runtimewire「TypeSafe opens Jev early access for fast, typed AI decisions」 https://runtimewire.com/article/typesafe-jev-system-one-ai-model-early-access
「型エラーがゼロ」という主張自体はスキーマ制約上そうなるのは理解できますが、「フロンティア級の知能」という部分は第三者の追試を待ちたいところです。ただ公式ブログ自身も、参照値としてGPT-6 AstraとFable 5.1の平均を使っているためOpenAIとAnthropicのモデルに有利なバイアスがあり、DeepSeek系モデルの相対評価は過小になっている可能性がある、と自ら注記しています。都合の良い数字だけを並べるのではなく、自分たちの手法の弱点まで開示する姿勢は、スタートアップの発表としては誠実なほうだと感じます。
また現時点では選べる選択肢の数（カーディナリティ）が255までに制限されているなど、あくまで早期アクセス版らしい制約も見えます。まだ荒削りな部分が残っているのは事実ですが、二年間ステルスで研究を続けてここまでの形にまとめてきた、という時点でかなり気合の入ったチャレンジだと思います。
キャリア面で考えると、これまで「LLMをどうプロンプトで手なずけるか」に寄っていたAIエンジニアリングのスキルセットに、「構造化された判断ワークフローをどう設計するか」という新しい軸が加わりそうです。チャットボットや対話エージェントを作るスキルと、業務システムの中に組み込む確率的な条件分岐を設計するスキルは、似ているようで求められる感覚がだいぶ違います。この手のモデルが普及していくなら、後者の「AIを使ったスマートな条件分岐設計」ができる人材の価値が上がっていくかもしれません。
さいごに
「LLMではないものが出た」という見出しに最初は少し眉唾な気持ちもありましたが、読み進めると「文字列生成という自由さを手放す代わりに、型安全性と速度を手に入れる」というトレードオフの設計思想自体は筋が通っていると感じました。
なんでもLLMに投げてプロンプトで頑張る、というここ数年の空気に対して、「そもそもチャット向けに最適化されたモデルを業務の自動化にそのまま流用するのは無理があったのでは」という問いかけ自体は、地味に鋭い指摘だと思います。
正直なところ、LLMという巨大な潮流に対して真正面から違う道を提示するのは、技術的にもビジネス的にもリスクの大きい賭けだと思います。それでも「みんなと同じ土俵で少しだけ性能を競う」のではなく「そもそも土俵を変える」という挑戦をした点は、素直に応援したくなります。こういう選択肢が業界に一つ増えるだけで、他の開発者やチームにとっても「LLM以外にもこういうアプローチがあり得るんだ」という視野の広がりにつながるはずです。
ベンチマークの多くが自社発表である以上、実際の業務でどこまで通用するかは、今後の第三者検証や早期アクセスユーザーの声を待つ必要がありそうです。それでも、こうした異色の挑戦が出てくること自体が技術コミュニティ全体にとってプラスだと思うので、今後の展開を追いかけていきたいです。もし興味があれば、早期アクセスのウェイトリストに登録して自分の目で確かめてみるのも面白いんじゃないでしょうか。
参考リンク
- TypeSafe AI公式ブログ「Introducing System One Models & Jev」（一次情報）
https://typesafe.ai/blog/introducing-system-one-models-and-jev - runtimewire「TypeSafe opens Jev early access for fast, typed AI decisions」
https://runtimewire.com/article/typesafe-jev-system-one-ai-model-early-access - Every「mini vibe check: typesafe's jev judged everything i've written in 0.7 seconds」
https://every.to/also-true-for-humans/mini-vibe-check-typesafe-s-jev-judged-everything-i-ve-written-in-0-7-seconds