Jev（ジェヴ）は、TypeSafe AIが開発した最初のSystem Oneモデルです。人が読む文章を作るのではなく、ソフトウェア内で高速に処理できる、構造化された判断を返すことを目的にしています。TypeSafe AIは2026年9月15日にJevの初期アクセスを開始しました。同社はサンフランシスコを拠点とし、元OpenAI研究者のディオゴ・アルメイダ氏が、エリック・ガフニ氏、サーシャ・シェン氏と共同で設立しました。216

最大の違いは「文章生成」ではなく「判断の返却」

大規模言語モデル（LLM）は、基本的に次のトークンを順番に予測しながら文章を生成します。説明文、企画、コード、会話などを柔軟に扱える反面、アプリケーション側では返答文を解析したり、生成されたJSONが期待どおりか検証したりする工程が必要になりがちです。

Jevが対象にする仕事は、これより限定的です。アプリケーションは、文字列・JSONオブジェクト・テキスト配列などの**state（状態）**と、型を指定した質問を渡します。Jevは質問ごとに、コードが直接分岐処理に使える構造化された回答を返します。TypeSafeのAPIドキュメントでは、stateを質問マップに対して評価し、質問ごとに構造化された回答を返す仕組みと説明されています。17

対応する主な判断形式は次の3種類です。

• Boolean（真偽）：たとえば「このコマンドは実行して安全か」のような命題が真である確率を推定する。
• Choice（選択）：開発者が指定した候補の中から1つを選ぶ。
• Score（評価）：順序付きの評価基準や数値尺度に沿って採点する。

そのためTypeSafeは、Jevをチャットボットではなく、ルーティング、分類、検索結果の絞り込み、リスク評価、AIエージェントのガードレールといった用途の「意思決定プリミティブ」として位置付けます。公式ドキュメントでも、モデルの振り分け、意味的検索、実行トレースの分類、ほかのAI出力の検査などがユースケースとして挙げられています。18

「System One」とは何か

名称は、心理学者ダニエル・カーネマンが提示した、速く直感的な「システム1」と、遅く熟慮的な「システム2」の区分に由来します。TypeSafeはこれを、自由形式の推論や文章作成ではなく、速く範囲の定まった判断に焦点を当てるモデル群の呼称として使っています。16

これは、Jevが汎用的な推論を解決したという意味ではありません。重要なのはインターフェースです。必要な状態と明確に定義した判断を渡し、段落の文章ではなく、確率分布を伴う制約付きの結果を受け取ります。

制約された出力が自動化に役立つ理由

Jevでは、アプリケーション側が出力の形を事前に定義します。Choiceでは、選択可能な答えも呼び出し側が指定します。そのため、プログラムが固定値を期待している場所で、想定外のフィールドやツール名、自由文の説明が返るといった、生成AIの連携で起きやすい問題を避けやすくなります。

ただし、これは出力構造に関する保証であり、内容の真実性を保証するものではありません。選択肢が制限されていても、Jevが誤った候補を選ぶことや、実運用で十分に較正されていない確信度を返すことはあり得ます。Vercelも、スキーマ適合性は回答の構造に関するものであり、意味的な正しさは別途評価が必要だと明示しています。

本番運用では、確信度の閾値を「信頼性の証明」ではなく、検証すべきポリシーの入力値として扱うべきです。たとえば、低リスクで高確信度の判断だけを自動化し、曖昧な案件や影響の大きい案件はLLM、ルールエンジン、または人の確認に回す設計が考えられます。

学習と較正：TypeSafeが示す仕組み

TypeSafeによれば、Jevは合成データだけで学習され、**RLCD（Reinforcement Learning for Calibrated Decisions）**という手法を用いています。人に好まれる文章を返すことではなく、出力する確率が実際の正答率により近づくよう最適化することが狙いだとしています。

確率の較正が機能すれば、たとえば0.9という出力を基に、開発者は意味のあるレビュー閾値を設定しやすくなります。一方、RLCDは広範な独立検証で確立された手法とは言えず、提示された資料には、Jevの較正、敵対的入力への強さ、分野横断の正確性を包括的に監査した第三者評価はありません。導入を検討する組織は、自社のデータと意思決定ポリシーに即して検証する必要があります。

価格、コンテキスト長、速度

TypeSafeが掲げるJev 1.13の料金は、入力100万トークン当たり0.042ドル（10億トークン当たり42ドル）で、出力トークンは無料です。この入力単価では、税金や個別契約条件を除けば、5ドルで約1億1,900万入力トークンを利用できます。ドキュメント上のリクエストコンテキストは64,000トークンで、stateには最大32,000トークンと、最長の質問を含められます。

同社および初期報道では、レイテンシは処理内容に応じておおむね70〜500ミリ秒とされています。ただし実際の応答時間は、リクエスト量、質問設計、リージョン、サービス状況によって変動します。

Vercelでの早期導入

VercelはAI GatewayにJevを追加し、実験的な評価APIからtypesafe-ai/jevとして呼び出せるようにしました。

Vercelによると、JevはAI Gatewayでの提供開始から24時間以内に、有料チームの約13％に利用されました。これは同じ期間における過去のどのモデル公開よりも、2倍を超える有料チーム数に達したというものです。 開発者の関心や試用の広がりを示す指標ではありますが、長期的な継続利用、本番規模での信頼性、あらゆる業務での優位性を示すものではありません。

初期報道では、コマンド実行の安全性分類やメール分類での試行も伝えられています。こうした事例はJevが狙う、境界の明確な業務を理解する手掛かりになりますが、独立した統制条件下のベンチマークに代わるものではありません。LLMと比較するなら、各チームは自社の代表的なデータで、正確性、確信度の較正、誤判定時の重大性、レイテンシ、ワークフロー全体の費用を測る必要があります。

Jevに向く場面、向かない場面

アプリケーションが必要な判断をあらかじめ把握し、回答の範囲を明確に定義できる場合、Jevは有力な選択肢になり得ます。例としては次のようなものがあります。

• エージェントが継続、再試行、追加確認、停止のどれを選ぶか決める。
• コマンドやツール呼び出しを分類し、安全性レビューに回す。
• 緊急度、関連性、リスクをスコア化する。
• 決定的なコードで抽出した候補値から、適切な値を選択する。
• 高コストなモデルを呼ぶ前に、大量のテキストをフィルタリングまたはラベル付けする。

逆に、自由な文章作成、説明、ブレインストーミング、コード生成、広範な計画、事前定義のスキーマに収まらない回答が必要な製品では、JevはLLMの代替にはなりません。Jevの導入品質は、質問文、入力として渡す情報、候補、閾値、テスト戦略にも大きく左右されます。TypeSafeも、条件を正確に記述し、可能なら送信前にコンテキストを絞り込み、十分に統合テストするよう助言しています。

対応モダリティとロードマップ

現時点でJevが受け付けるのは、文字列、JSONオブジェクト、テキスト配列といったテキストベースのstateです。画像、音声、動画には対応していません。TypeSafeはこれらを「not supported (yet)」と表記していますが、提供資料にはマルチモーダルモデルの公開時期は示されていません。

実務上のポイント

Jevの提案は、「すべてのAIが言語生成をやめるべきだ」というものではありません。むしろ、多くのソフトウェア処理では、そもそも文章生成が必要ないという考え方です。範囲が定まった分類、ルーティング、ポリシー判断であれば、型付きで確率を伴う結果は、チャット形式の返答よりも統合しやすく、低コストかつ迅速に処理できる可能性があります。

一方で、構造化出力が減らせるのは主に出力形式の失敗であり、判断ミスそのものではありません。Jevの価値は、分野ごとの実データを使った独立検証で、精度と確信度がどこまで維持されるかにかかっています。現段階では、LLMの汎用的な代替ではなく、適切に範囲を切り出したソフトウェア上の意思決定に向けた、有望な専門ツールと捉えるのが妥当です。

Jev（ジェヴ）は、TypeSafe AIが開発した最初のSystem Oneモデルです。人が読む文章を作るのではなく、ソフトウェア内で高速に処理できる、構造化された判断を返すことを目的にしています。TypeSafe AIは2026年9月15日にJevの初期アクセスを開始しました。同社はサンフランシスコを拠点とし、元OpenAI研究者のディオゴ・アルメイダ氏が、エリック・ガフニ氏、サーシャ・シェン氏と共同で設立しました。216

最大の違いは「文章生成」ではなく「判断の返却」

大規模言語モデル（LLM）は、基本的に次のトークンを順番に予測しながら文章を生成します。説明文、企画、コード、会話などを柔軟に扱える反面、アプリケーション側では返答文を解析したり、生成されたJSONが期待どおりか検証したりする工程が必要になりがちです。

Jevが対象にする仕事は、これより限定的です。アプリケーションは、文字列・JSONオブジェクト・テキスト配列などの**state（状態）**と、型を指定した質問を渡します。Jevは質問ごとに、コードが直接分岐処理に使える構造化された回答を返します。TypeSafeのAPIドキュメントでは、stateを質問マップに対して評価し、質問ごとに構造化された回答を返す仕組みと説明されています。17

対応する主な判断形式は次の3種類です。

• Boolean（真偽）：たとえば「このコマンドは実行して安全か」のような命題が真である確率を推定する。
• Choice（選択）：開発者が指定した候補の中から1つを選ぶ。
• Score（評価）：順序付きの評価基準や数値尺度に沿って採点する。

そのためTypeSafeは、Jevをチャットボットではなく、ルーティング、分類、検索結果の絞り込み、リスク評価、AIエージェントのガードレールといった用途の「意思決定プリミティブ」として位置付けます。公式ドキュメントでも、モデルの振り分け、意味的検索、実行トレースの分類、ほかのAI出力の検査などがユースケースとして挙げられています。18

「System One」とは何か

名称は、心理学者ダニエル・カーネマンが提示した、速く直感的な「システム1」と、遅く熟慮的な「システム2」の区分に由来します。TypeSafeはこれを、自由形式の推論や文章作成ではなく、速く範囲の定まった判断に焦点を当てるモデル群の呼称として使っています。16

これは、Jevが汎用的な推論を解決したという意味ではありません。重要なのはインターフェースです。必要な状態と明確に定義した判断を渡し、段落の文章ではなく、確率分布を伴う制約付きの結果を受け取ります。

制約された出力が自動化に役立つ理由

Jevでは、アプリケーション側が出力の形を事前に定義します。Choiceでは、選択可能な答えも呼び出し側が指定します。そのため、プログラムが固定値を期待している場所で、想定外のフィールドやツール名、自由文の説明が返るといった、生成AIの連携で起きやすい問題を避けやすくなります。

ただし、これは出力構造に関する保証であり、内容の真実性を保証するものではありません。選択肢が制限されていても、Jevが誤った候補を選ぶことや、実運用で十分に較正されていない確信度を返すことはあり得ます。Vercelも、スキーマ適合性は回答の構造に関するものであり、意味的な正しさは別途評価が必要だと明示しています。

本番運用では、確信度の閾値を「信頼性の証明」ではなく、検証すべきポリシーの入力値として扱うべきです。たとえば、低リスクで高確信度の判断だけを自動化し、曖昧な案件や影響の大きい案件はLLM、ルールエンジン、または人の確認に回す設計が考えられます。

学習と較正：TypeSafeが示す仕組み

TypeSafeによれば、Jevは合成データだけで学習され、**RLCD（Reinforcement Learning for Calibrated Decisions）**という手法を用いています。人に好まれる文章を返すことではなく、出力する確率が実際の正答率により近づくよう最適化することが狙いだとしています。

確率の較正が機能すれば、たとえば0.9という出力を基に、開発者は意味のあるレビュー閾値を設定しやすくなります。一方、RLCDは広範な独立検証で確立された手法とは言えず、提示された資料には、Jevの較正、敵対的入力への強さ、分野横断の正確性を包括的に監査した第三者評価はありません。導入を検討する組織は、自社のデータと意思決定ポリシーに即して検証する必要があります。

価格、コンテキスト長、速度

TypeSafeが掲げるJev 1.13の料金は、入力100万トークン当たり0.042ドル（10億トークン当たり42ドル）で、出力トークンは無料です。この入力単価では、税金や個別契約条件を除けば、5ドルで約1億1,900万入力トークンを利用できます。ドキュメント上のリクエストコンテキストは64,000トークンで、stateには最大32,000トークンと、最長の質問を含められます。

同社および初期報道では、レイテンシは処理内容に応じておおむね70〜500ミリ秒とされています。ただし実際の応答時間は、リクエスト量、質問設計、リージョン、サービス状況によって変動します。

Vercelでの早期導入

VercelはAI GatewayにJevを追加し、実験的な評価APIからtypesafe-ai/jevとして呼び出せるようにしました。

Vercelによると、JevはAI Gatewayでの提供開始から24時間以内に、有料チームの約13％に利用されました。これは同じ期間における過去のどのモデル公開よりも、2倍を超える有料チーム数に達したというものです。 開発者の関心や試用の広がりを示す指標ではありますが、長期的な継続利用、本番規模での信頼性、あらゆる業務での優位性を示すものではありません。

初期報道では、コマンド実行の安全性分類やメール分類での試行も伝えられています。こうした事例はJevが狙う、境界の明確な業務を理解する手掛かりになりますが、独立した統制条件下のベンチマークに代わるものではありません。LLMと比較するなら、各チームは自社の代表的なデータで、正確性、確信度の較正、誤判定時の重大性、レイテンシ、ワークフロー全体の費用を測る必要があります。

Jevに向く場面、向かない場面

アプリケーションが必要な判断をあらかじめ把握し、回答の範囲を明確に定義できる場合、Jevは有力な選択肢になり得ます。例としては次のようなものがあります。

• エージェントが継続、再試行、追加確認、停止のどれを選ぶか決める。
• コマンドやツール呼び出しを分類し、安全性レビューに回す。
• 緊急度、関連性、リスクをスコア化する。
• 決定的なコードで抽出した候補値から、適切な値を選択する。
• 高コストなモデルを呼ぶ前に、大量のテキストをフィルタリングまたはラベル付けする。

逆に、自由な文章作成、説明、ブレインストーミング、コード生成、広範な計画、事前定義のスキーマに収まらない回答が必要な製品では、JevはLLMの代替にはなりません。Jevの導入品質は、質問文、入力として渡す情報、候補、閾値、テスト戦略にも大きく左右されます。TypeSafeも、条件を正確に記述し、可能なら送信前にコンテキストを絞り込み、十分に統合テストするよう助言しています。

対応モダリティとロードマップ

現時点でJevが受け付けるのは、文字列、JSONオブジェクト、テキスト配列といったテキストベースのstateです。画像、音声、動画には対応していません。TypeSafeはこれらを「not supported (yet)」と表記していますが、提供資料にはマルチモーダルモデルの公開時期は示されていません。

実務上のポイント

Jevの提案は、「すべてのAIが言語生成をやめるべきだ」というものではありません。むしろ、多くのソフトウェア処理では、そもそも文章生成が必要ないという考え方です。範囲が定まった分類、ルーティング、ポリシー判断であれば、型付きで確率を伴う結果は、チャット形式の返答よりも統合しやすく、低コストかつ迅速に処理できる可能性があります。

一方で、構造化出力が減らせるのは主に出力形式の失敗であり、判断ミスそのものではありません。Jevの価値は、分野ごとの実データを使った独立検証で、精度と確信度がどこまで維持されるかにかかっています。現段階では、LLMの汎用的な代替ではなく、適切に範囲を切り出したソフトウェア上の意思決定に向けた、有望な専門ツールと捉えるのが妥当です。