TypeSafeのJevとは何か。文章生成ではなく、ソフトウェアの判断を担うSystem One Model

はじめに

2026年9月、TypeSafe AIは初の公開モデルJevを発表しました。Jevはチャットやコード生成のためのLLMではありません。アプリケーションの内部で必要になる分類・ルーティング・スコアリング・検証といった「判断」を、型付きの出力として返すためのモデルです。

この記事では、TypeSafeの公式ドキュメントや公式ブログ、Web上で確認できる公開情報をもとに、次の内容を整理します。

TypeSafe AIとJevの概要
従来のLLMとの設計思想の違い
システム内での使い所
公式Playgroundの状況
ローカル互換実装のjeff
現時点で本番導入をどう判断するか

結論を先に書くと、筆者はJevを、生成LLMの置き換えではなく、アプリケーション内の小さく反復的な判断を型付きで扱うための選択肢として注目しています。一方で、公開直後であり、closed-weightで自己ホストもできないため、特定ベンダーに強く依存する形での本番導入は慎重に判断すべきだと考えています。

執筆時点では、急激な需要によりTypeSafeの公式Consoleで新規サインアップが一時停止されており、Playgroundを使った実機検証はできていません。公式アクセスが再開されたら、本家Jevとローカル互換実装の比較結果を追記する予定です。

この記事の内容は次のとおりです。

TypeSafe AIとは
Jevは何をするモデルか
LLMとの違い
システム内での使い所
公式Playgroundの現状
ローカルで試すjeff
導入判断
まとめ
参考文献

TypeSafe AIとは

TypeSafe AIは、米サンフランシスコを拠点に2024年に設立されたAI企業です。2026年9月15日にステルス状態から脱し、DCVC主導による約4,000万ドルのシード資金の調達と、初の公開モデルJevを発表しました。

TypeSafe AIが掲げるのは、チャット画面の中で人間に文章を返すAIではなく、ソフトウェアから直接呼び出し、組み合わせ、制約をかけられるAIです。公式はこれをcomposable AIと呼んでいます。

その最初の公開モデルがJevです。

Jevは何をするモデルか

Jevは自由な文章を生成する代わりに、アプリケーションがそのまま使える型付きの判断結果を返します。

たとえば問い合わせ本文を入力として、次の判断をまとめて返せます。

入力:
「三回も問い合わせしているのに、まだ解決していません。
 今すぐ人と話したいです。」

出力したい判断:
- 人間の担当者へエスカレーションすべきか
- 問い合わせ先の部署はどこか
- 緊急度はどの程度か
- 脅迫・攻撃的な表現があるか
- 返金・請求に関する問い合わせか

従来のLLMでも、JSON Schemaを指定すれば似たことはできます。ただしJevは「まず文章を生成し、その文章をJSONとして構文解析する」という流れを取らず、最初から判断結果を返すように設計されています。

TypeSafeのSDKでは、主に次の3種類の質問を使います。

型	返すもの	例
`Noul`	文が真である確率（0〜1）	「人間の担当者を求めているか？」
`Choice`	定義済みの候補から1つ選んだ結果	「請求・技術・アカウントのどれか？」
`Score`	順序を持つ段階の上での評価	「緊急度は低・中・高のどこか？」

Noulは一般的な用語ではなく、TypeSafeがこの「真である確率」を返す型に付けた名前です。

LLMとの違い

従来のLLMの典型的な使い方

一般的なLLMに問い合わせを分類させる場合、次のようなプロンプトを書くことが多いはずです。

以下の問い合わせを分類してください。

問い合わせ:
三回も問い合わせしているのに、まだ解決していません。
今すぐ人と話したいです。

以下の JSON だけを返してください。

{
  "requires_human": true,
  "team": "technical",
  "urgency": "high"
}

この方式は柔軟な一方で、運用では次の問題が起きやすくなります。

JSON以外の文章が混ざり、パースに失敗する
指定したenum以外の値を返す
JSONの構文が壊れる
1項目だけを変えたいときも、出力全体を生成し直す
出力トークンの分だけコストとレイテンシが増える
確信度が分からず、しきい値で分岐させる設計がしにくい

Structured Outputsやfunction callingによって、こうした問題は以前より改善しています。それでも、モデルの中心的な仕事は「次のトークンを生成すること」のままです。

Jevの設計思想

Jevは、テキストを生成するモデルではなく、入力状態（state）に対して、定義した質問（questions）の答えを計算するモデルとして位置づけられています。

state（判定対象の情報）
    +
questions（型付きで定義した質問）
    ↓
Jev / System One Model
    ↓
typed answers（構造化された判断・確率・確信度）

「System One」という呼び名は、ダニエル・カーネマンが『ファスト＆スロー』で説明した、速く直感的で自動的な思考様式（システム1）に由来します。Jevが狙っているのは、複雑な推論や説明文の生成ではなく、ソフトウェアの中に大量に存在する小さな判断を高速にさばくレイヤーです。

比較表

観点	一般的な生成LLM	Jev / System One Model
主な目的	会話、文章生成、要約、コード生成、複雑な推論	分類、ルーティング、検証、スコアリング、条件判定
基本の出力	自由形式のテキスト	型付きの判断結果・確率・確信度
実装上の扱い	生成させたJSONをパース・検証する	そのままコードで扱える構造化出力
向く作業	曖昧な要求の解釈、説明、文書作成、推論	大量・反復的・低レイテンシな判定
失敗の代表例	幻覚、JSONの破損、enum外の出力、冗長な文章	判定ミス、低い確信度、質問設計の曖昧さ
改善の手段	プロンプト、RAG、モデル変更、ファインチューニング	`instructions`・`criteria`の見直し、質問の分解、しきい値、評価データ
評価のしかた	生成内容の良し悪しを人間が読んで確かめがち	正解ラベルと突き合わせて自動で評価しやすい

表のとおり、JevはLLMの代替ではありません。「ユーザーへの丁寧な回答文を作る」「複数の資料から障害の原因を推論する」「設計書を生成する」といった作業には、引き続き生成LLMが必要です。

一方で、「どの処理にルーティングするか」「危険な操作を人間の承認に回すか」「入力が所定の条件を満たすか」といった判断の層には、Jevのようなモデルが向いています。

システム内での使い所

Jevを使うときのポイントは、既存のLLMを丸ごと置き換えることではなく、アプリケーションの中にある「小さく、反復的で、構造化された判断」を任せることです。ここでは、SDKの呼び出しイメージと、運用で重要になるログと評価の扱いを紹介します。

SDKのイメージ

次は、問い合わせを判定するPythonの例です。

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient(api_key="YOUR_API_KEY")

result = client.system_one(
    "三回も問い合わせしているのに、まだ解決していません。今すぐ人と話したいです。",
    {
        "human_escalation": Noul(
            instructions="顧客が人間の担当者との会話を明確に求めているか？"
        ),
        "team": Choice(
            instructions="この問い合わせを担当すべき部署を選択する。",
            criteria={
                "billing": "請求、返金、支払い、二重請求に関する問い合わせ",
                "technical": "障害、不具合、機能、操作方法に関する問い合わせ",
                "account": "ログイン、認証、権限、アカウント設定に関する問い合わせ",
                "other": "上記のいずれにも明確に該当しない問い合わせ",
            },
        ),
        "urgency": Score(
            instructions="問い合わせの緊急度を評価する。",
            criteria=[
                "低: 通常の問い合わせであり、即時対応を求めていない",
                "中: 困っているが、業務停止や明確な期限は示していない",
                "高: 業務停止、金銭的損失、強い即時対応要求、重大な期限がある",
            ],
        ),
    },
)

print(result.nouls["human_escalation"].noul)
print(result.choices["team"].choice)
print(result.scores["urgency"].score)

ここで人間が決めるのは、モデルに対する「問いの設計」です。

何を判定させるか
どの選択肢を用意するか
各選択肢をどう定義するか
どの確信度から自動実行してよいか
確信度が低いときに誰へエスカレーションするか

一方で、実際にhuman_escalationが真か、teamがtechnicalか、urgencyが高いかを判断するのはモデルです。

ログを取っておくと精度を確かめられる

Jevの出力は構造化されているので、アプリケーションのログにそのまま残せます。モデルの出力と、あとから人間が確認した正解ラベルを突き合わせれば、精度を継続的に評価できます。

{
  "request_id": "req_01H...",
  "model": "jev-<pinned-version>",
  "question_set_version": "support-routing-v3",
  "state_hash": "sha256:...",
  "answers": {
    "human_escalation": {
      "value": true,
      "probability": 0.97
    },
    "team": {
      "value": "technical",
      "confidence": 0.81
    },
    "urgency": {
      "value": 1.8,
      "confidence": 0.76
    }
  },
  "final_action": "handoff_to_human",
  "human_label": {
    "human_escalation": true,
    "team": "technical",
    "urgency": "high"
  }
}

urgencyのvalueは、この例では低・中・高を0〜2とした尺度上の値として記録しています。

ログには、少なくとも次の項目を残しておくとよいです。

推論に実際に使ったモデルの固定バージョン
instructionsとcriteriaを含む質問セットのバージョン
入力本文そのもの。個人情報を避けたい場合は、ハッシュや安全に抽出した特徴量
選ばれた値だけでなく、確信度や確率分布
コードが採用した最終アクション
あとから人間が確認した正解ラベル

ログと正解ラベルがそろえば、次の観点からモデルの性能と運用上のリスクを確認できます。

正解率（Accuracy）
Precision / Recall / F1-score
混同行列（confusion matrix）を使った、誤分類の多い部署・カテゴリの特定
しきい値ごとの自動実行率と誤実行率
「確信度0.9の予測が、実際にも約90%正解しているか」を確かめるキャリブレーション（calibration）
モデルや質問セットを更新したときに、同じ評価セットで性能が落ちていないかを確かめる回帰テスト（regression testing）

しきい値・キャリブレーション・回帰テストの詳細はこの記事の主題から外れるので、ここでは概要にとどめます。TypeSafeの公式は、確信度に応じて自動実行・確認・人間へのエスカレーションを振り分け、しきい値はユースケースのリスクと自分のデータに基づいて調整することを推奨しています。詳しくはTypeSafe: ConfidenceとConfidence-gated routingを参照してください。

ただし、確信度が0.9だからといって、その1件の予測が90%の確率で正解するとは限りません。0.9を実際の正解率として扱えるかどうかは、同じユースケースで十分な件数を集め、確信度の帯ごとに実測の正解率を確かめて初めて判断できます。

公式Playgroundの現状

TypeSafeは公式ConsoleでPlaygroundを提供しており、テキストを入力してNoul・Choice・Scoreの質問を試せます。公式のQuick StartもPlaygroundを入口として案内しています。

ただし執筆時点では利用希望者が急増しており、筆者の環境では新規ログイン画面に次のメッセージが表示されました。

Whoops, we're full

URLにはsignups_disabledが含まれており、新規アカウントの作成が一時停止されている状態でした。

アクセスできるようになったら、次の点を検証する予定です。

日本語の問い合わせを入力したときの分類精度
同じ入力を繰り返したときの出力の安定性
instructionsとcriteriaの粒度を変えたときの精度の差
複数の質問を1リクエストにまとめたときのレイテンシ
本家Jevとローカル互換実装との出力の差
確信度の低いケースを人間のレビューへ回すしきい値の設計
固定したモデルバージョンごとの回帰テスト

ローカルで試す`jeff`

本家Jevはモデルの重みを公開しておらず、ローカルでの実行や自己ホストはできません。ollama run jevのように、手元で本物のJevを起動することはできないということです。

一方でGitHubには、JevのAPI形式に合わせたローカル互換実装があります。代表的なものがlogan-markewich/jeffです。

GitHub: logan-markewich/jeff
目的: Jev互換の/v1/systemone APIをセルフホストする
バックエンド: オープンモデルのGLiFormer（knowledgator/gliformer-large-v1）
特徴: 公式のtypesafe-sdkをそのまま使い、Noul・Choice・Scoreをローカル環境で試せる
注意: 出力の精度・確信度・レイテンシは、本家のJevと同じではない

client = TypeSafeClient(
    api_key="devkey",
    base_url="http://localhost:8000",
)

このようにbase_url（または環境変数TYPESAFE_BASE_URL）をローカルに向ければ、アプリケーション側は同じSDKの書き方のまま、質問設計・データ形式・ログ設計・分岐ロジックをローカルサーバーで検証できます。

jeff自身はdrop-in replacementをうたっていますが、中で動いているモデルは別物です。Jevの代替品というより、System One型のAPI設計を試すための開発・学習用の環境と捉えるのがよいと考えています。本家の品質・確信度のキャリブレーション・運用上のSLAを評価したいなら、公式APIが使えるようになってから、同じ評価データセットで比較する必要があります。

導入判断

現時点では、Jevを本番アーキテクチャの中核に置くのは早いと考えています。理由は次のとおりです。

公開直後で、長期的な運用実績がまだ少ない
公式Consoleのサインアップ停止を見ても、需要の増加に対してどこまでスケールするかは継続して見る必要がある
本家モデルはclosed-weightで、自己ホストできない
外部APIに送れない機密データや個人情報を扱うシステムには、そのまま適用できない
判定結果は確率的なもので、業務ルールや人間のレビューを完全には置き換えられない
入力データが信頼できない場合は、プロンプトインジェクションを含めた安全設計が必要になる

一方で、次の条件に当てはまるなら、PoCをする価値は高いと考えています。

分類・ルーティング・関連性判定を大量に繰り返している
生成LLMのJSON出力を毎回パースし、失敗したら再試行している
低レイテンシで、確信度に基づく分岐が必要
少量の評価データと、人間による正解ラベルを用意できる

導入するなら、公式APIへの依存を抽象化し、別の実装に切り替えられるようにしておきます。たとえばアプリケーション側に次のような層を置きます。

DecisionProvider
  ├─ TypeSafeJevProvider
  ├─ LocalJeffProvider
  └─ LlmStructuredOutputProvider

こうしておけば、Jevの提供形態・価格・精度・利用制限が変わっても、ビジネスロジックを大きく書き換えずに別の実装へ切り替えられます。

まとめ

TypeSafe AIのJevは、文章生成を主目的とするLLMとは異なり、ソフトウェア内部の判断を型付きの出力として返すSystem One Modelです。

注目すべきなのは、Jevという単一モデルの性能だけではありません。生成LLMにすべてを任せず、次のように役割を分けるアーキテクチャそのものです。

判定モデル（System One Model）:
分類・ルーティング・検証・スコアリング・ガードレール

生成LLM:
説明・要約・対話・文書作成・複雑な推論

この分離は、AIワークフローを本番環境に載せるうえで、コスト・レイテンシ・信頼性・監査のしやすさを改善する可能性があります。

まずはjeffのようなローカル互換実装で、質問設計・ログ設計・評価データセット・しきい値によるエスカレーションを試します。本家JevのPlaygroundやAPIが使えるようになったら、同じデータで精度・キャリブレーション・速度・コストを比較します。この順番なら、特定ベンダーの話題性に振り回されすぎずに、System One型の設計思想を自分のプロジェクトへ取り込めます。

TypeSafeのJevとは何か。文章生成ではなく、ソフトウェアの判断を担うSystem One Model

はじめに

TypeSafe AIとは

Jevは何をするモデルか

LLMとの違い

従来のLLMの典型的な使い方

Jevの設計思想

比較表

システム内での使い所

SDKのイメージ

ログを取っておくと精度を確かめられる

公式Playgroundの現状

ローカルで試す`jeff`

導入判断

まとめ

参考文献

TypeSafe公式

ローカル互換実装

評価指標・運用

はじめに

TypeSafe AIとは

Jevは何をするモデルか

LLMとの違い

従来のLLMの典型的な使い方

Jevの設計思想

比較表

システム内での使い所

SDKのイメージ

ログを取っておくと精度を確かめられる

公式Playgroundの現状

ローカルで試すjeff

導入判断

まとめ

参考文献

TypeSafe公式

ローカル互換実装

評価指標・運用

ローカルで試す`jeff`