Jev — 文章を書かないAIは何を返すのか。TypeSafeの「System Oneモデル」を賢いif文として読む

何が出たのか

2026年9月15日、サンフランシスコのAIラボ TypeSafe AI がステルスを抜け、最初のモデル Jev を早期アクセスで公開しました。 CEOの Diogo Almeida 氏は、ChatGPTの土台になった InstructGPT論文の共著者です。 DCVCがリードするシードラウンドで4,000万ドルを調達し、Forbesは評価額を2億ドルと報じています。

Jevが目を引くのは、性能の数字よりも「LLMではない」と言い切っている点です。 Jevはテキストを生成しません。文字列かJSONの「state」と、型の決まった「質問」を受け取り、質問ごとに型付きの答えと確率、そしてconfidence（確信度）を返します。 TypeSafeはこれをカーネマンの「速い思考」になぞらえて System Oneモデル と呼び、 「チャットするためのAIではなく、ソフトウェアの中で判断を下すためのAI」と定義しています。

LLMと何が違うのか

「LLMにJSONで出力させれば同じでは？」というのが最初に浮かぶ疑問です。 違いは出力の形式ではなく、モデルが何を計算しているかにあります。

LLMの構造化出力は、あくまでトークンを1つずつ生成した結果がたまたまJSONの形をしているものです。 スキーマ違反はゼロにできず、確率も「そのトークン列を出す確率」であって「その判断が正しい確率」ではありません。 Jevは出力トークンを1つも生成しません。用意された選択肢のそれぞれについて確率を並列に見積もり、その分布をそのまま返します。 だから出力は無料で、レイテンシは選択肢の数にほとんど依存せず、返ってくる値は構造的にスキーマの中に収まります。

この表でいちばん重要な行は「誤答の形」です。 TypeSafeは「ハルシネーションしない」と宣伝していますが、公式ドキュメントの注意書きを正確に読むと「リストにない選択肢は返せない。リストの中の間違った選択肢は普通に返す」です。 ゼロなのはスキーマ違反であって、正答率ではありません。この区別は後述のconfidenceの話につながります。

3つのプリミティブ

質問の型は3種類しかありません。この少なさが、逆に「何に使えて何に使えないか」をはっきりさせています。

実際のリクエストとレスポンスを見ると、形はほぼ自明です。 問い合わせメールを1通渡して、担当部署・怒り具合・緊急かどうかを一度に聞く例です。

{
  "model": "jev-latest",
  "state": "Stripe連携が3日間ずっと失敗しています。売上が立たず困っています。至急お願いします。",
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "Which team should handle this",
      "criteria": {
        "billing": "Payment or subscription issues",
        "technical": "Bugs or integration problems",
        "sales": "Pricing or account questions"
      }
    },
    "frustration": {
      "type": "score",
      "instructions": "How frustrated the customer appears",
      "criteria": ["Calm, just stating facts", "Frustrated but civil", "Very angry, strong language"]
    },
    "is_urgent": {
      "type": "noul",
      "instructions": "The message conveys urgency or time-sensitivity"
    }
  }
}

{
  "model": "jev-1.13.0",
  "answers": {
    "department": {
      "choice": "technical",
      "probabilities": { "billing": 0.159, "technical": 0.84, "sales": 0.001 },
      "confidence": 0.596
    },
    "frustration": { "score": 1.035, "confidence": 0.842 },
    "is_urgent": { "noul": 0.999 }
  },
  "usage": { "input_tokens": 312, "output_tokens": 48 }
}

ポイントを3つ挙げます。

• Choiceは「選ばれた1つ」だけでなく分布全体を返します。 上の例では technical が0.84、billing が0.159。「Stripe連携」を billing と読む余地が残っている、というモデルの迷いがそのまま数字になっています。
• Scoreは整数ではなく確率加重の平均です。 1.035 は「ほぼ段階1（frustrated but civil）だが、わずかに段階2に寄っている」という意味で、閾値として使うものであって測定値ではありません。
• Noulにはconfidenceがありません。 確率そのものが確信度の役割を果たすからです。0.999 は「ほぼ確実に緊急」、0.5付近なら「判断がつかない」と読みます。

SDKでは型が推論される

JavaScript SDK（@typesafe-ai/sdk）では、質問の定義から答えの型が推論されます。choice のキーを列挙しておけば answers.category.choice はそのユニオン型になり、存在しないキーへのアクセスはコンパイル時に弾かれます。 「型安全」という社名は、この体験をそのまま指しています。

import { choice, noul, score, TypeSafeClient } from '@typesafe-ai/sdk'

const client = new TypeSafeClient() // TYPESAFE_API_KEY を読む

const { answers } = await client.systemOne({
  state: { ticket: 'Safariでエクスポートボタンを押すと落ちる' },
  questions: {
    category: choice('What kind of ticket?', {
      bug_report: 'Something is broken',
      feature_request: 'Asks for new feature',
      billing: 'Charges, refunds',
    }),
    severity: score('How severe?', [
      'Cosmetic',
      'Broken with workaround',
      'Blocking',
    ]),
    has_repro: noul('Are reproduction steps included?'),
  },
})

answers.category.choice   // 'bug_report' | 'feature_request' | 'billing'
answers.severity.score    // number（0〜2）
answers.has_repro.noul    // number（0〜1）

Vercel AI SDK 7 を使っているなら、AI Gateway経由で typesafe-ai/jev を experimental_evaluate に渡す形でも呼べます。 こちらはウェイトリスト不要で、料金はTypeSafe直と同じです。

import { experimental_evaluate as evaluate } from 'ai'

const { answers } = await evaluate({
  model: 'typesafe-ai/jev',
  state: { prompt, repoSummary },
  questions: {
    difficulty: {
      type: 'score',
      instructions: 'How much reasoning does this request need?',
      criteria: [
        'Lookup or single-file edit',
        'Multi-file change with tests',
        'Architecture or debugging across systems',
      ],
    },
  },
})

// difficulty.score が 1 を超えたら高性能モデルへ、そうでなければ軽量モデルへ
const model = answers.difficulty.score > 1 ? 'claude-fable-5-1' : 'claude-haiku-4-5-20251001'

中核：質問は並列かつ独立に評価される

Jevの設計でいちばん効いているのはここです。 1回の呼び出しに載せた質問はすべて同じstateに対して並列に、しかも互いに独立して評価されます。 ある質問の答えが別の質問の文脈になることはありません。

これが意味するのは、質問を追加するコストがほぼ質問文のトークン分だけということです。 LLMなら「まず分類して、その結果を見てから次の質問を投げる」という直列のループになるところを、 Jevでは「使うかどうか分からない質問も先に全部投げておいて、コード側で必要なものだけ拾う」のが正しい使い方になります。 公式はこれを speculative fan-out と呼んでいます。

flowchart LR
    S["state<br/>文字列 or JSON<br/>（例: 54,000字の規制文書）"] --> J["Jev<br/>1回のsystemOne呼び出し"]
    Q["questions<br/>Noul × 8 / Choice × 2 / Score × 3"] --> J
    J --> A1["answers.q1<br/>noul 0.93"]
    J --> A2["answers.q2<br/>choice + probabilities"]
    J --> A3["answers.q3<br/>score 1.3"]
    J --> A4["…13問ぶん"]
    A1 --> C["コード側で分岐<br/>必要な答えだけ使う"]
    A2 --> C
    A3 --> C
    A4 --> C

公式クックブックの数字を引くと、約54,000字の文書に対する13問（Noul 8・Choice 2・Score 3）で、 個別に13回呼ぶと $0.006090・2.71秒、1回にまとめると $0.000497・0.27秒。12.2倍安く、10.0倍速いという結果です。 重い文書を13回送るか1回送るかの差がそのままコストになっています。 そして5回ずつ繰り返しても、ほとんどの答えは標準偏差0.0で一致しました。まとめて送ることで答えがぶれる、ということはありません。

confidenceは「正解かどうか」ではなく「行動してよいか」の軸

Choice と Score には probabilities とは別に confidence が付いてきます。 confidenceは確率分布の形から計算される統計量で、分布が1つに尖っていれば高く、平らなら低くなります。 答えが「何か」を言うのが choice / score で、「その答えに従って行動してよいか」を言うのが confidence、という二軸の設計です。

TypeSafeはこの確率が現実に合うように学習した、と主張しています（RLCD）。 「0.9と答えた100件のうち、およそ90件は実際にそうである」という較正の主張で、 これが本当なら閾値をそのまま業務上のリスク許容度に対応させられます。 公式の目安は次の3段階です。

公式パターン「Confidence-Gated Routing」の銀行の例は、操作の危険度ごとに閾値を変えるところまで含めて書かれています。 残高照会は0.6で実行してよいが、送金承認は0.85を超えないと確認を挟む、という書き方です。

action = response.answers["intent"]

if action.confidence < 0.6:
    route_to_support_agent(account_id)          # 本当に迷っているものは人へ

elif action.choice == "check_balance":
    show_balance(account_id)                    # 低リスク: 0.6あれば実行

elif action.choice == "approve_transfer":
    if action.confidence > 0.85:
        approve_transfer(account_id)            # 高リスク: 0.85超でだけ自動実行
    else:
        ask_user_to_confirm("Just to confirm: you would like to approve this transfer, is that correct?")

else:
    route_to_support_agent(account_id)

「答えが正しいかどうか」をモデルに保証させるのではなく、「迷っているときは迷っていると言う」ことを保証させて、その先はコードが決める。 これがSystem Oneモデルの使い方の骨格で、TypeSafeが繰り返す「コードがワークフローを所有し、AIは狭い判定だけを担う」というメッセージの実体です。

数字で見る

第三者の評価も出始めています。 メディアのEveryが行った「文書に7つの欠陥を仕込んで検出させる」テストでは、Claude Fable 5.1が7つすべてを検出したのに対しJevは6つ。 ただしコストはおよそ580分の1でした。 「最良のLLMよりわずかに劣る判定を、桁違いの回数回せる」というのが、現時点でいちばん公平な位置づけだと思います。

公式が認める9つの弱点

TypeSafeはモデルのバージョンごとに「jaggedness（でこぼこ）」というページを出していて、このバージョンが苦手なことを列挙しています。jev-1.13 向けの9項目を要約します。 どれも「LLMなら文脈で補ってくれること」が補われない、という共通の形をしています。

⑨は見落としやすい設計上の制約です。 「このメールから金額を抜き出して」はできません。 正規表現で候補の数値を先に列挙し、「このうちどれが請求額か」を Choice で聞く、という抽出を選択に変換する手順が必要になります。 公式クックブックの「Pre-Parsed Value Extraction」「SDE Cascade」はその型です。

日本語ではどうか

Modelsページには「英語が主な学習言語で最も精度が高い。CJKを含む他言語も対応するが、同等ではない」と明記されています。 AI Native社の検証記事は、日本語の問い合わせ12件に5問ずつ（部署・緊急度・営業か・インジェクションか・案件の具体度）を投げて、 部署・緊急度・営業判定・インジェクション判定は12/12、案件の具体度は10/12という結果を報告しています。 外した2件は criteria の曖昧さを字義通りに読んだもので、上の①がそのまま出た形です。 あわせて「曖昧な日本語表現でconfidenceが低めに出る傾向があり、本番前に閾値の調整が要る」と書かれており、 これは精度よりも閾値設計の問題として扱うのが現実的です。

どこに置くか

公開から1週間でコミュニティが作ったものを見ると、Jevの居場所はかなりはっきりしています。LLMやエージェントの「外側」で、速くて安い判定が大量に必要になる場所です。

• コーディングエージェントのガードレール。 pi-warden はツール呼び出しごとに「不可逆か・タスクから外れていないか・意図と一致するか」を判定し、17,000回超の呼び出しで42回止め、精度は約88%と報告。jev-guard / jev-axi は Claude Code の PreToolUse でシェルコマンドの破壊度を採点する。
• モデルルーティング。 プロンプトの難しさを Score で測り、軽量モデルか高性能モデルかを振り分ける。Jevonian、Switchboard、LiteLLM Router がこの型。
• 検索・RAGの再ランキング。 公式クックブックの法務文書検索では top-1 精度が5%から18%に改善。取得済みパッセージの関連度を Noul で採点して捨てる。
• 引用・出典のチェック。 主張と出典ページを並べて「この文はこの箇所に支持されているか」を Noul で聞く。捏造された引用が高confidenceで弾かれた事例が報告されている。
• 大量ラベリング。 論文1,018本の分類が約$0.08、ドキュメント500ページの分類が約10セント。人間のレビューは「confidenceの低いものだけ」に絞る。
• ブラウザ・デスクトップ操作の行動選択。 browser-use の jev-ultrafast は「次にどの要素をどう操作するか」だけを Jev に選ばせ、文章入力が要るときだけLLMを呼ぶ。

flowchart TD
    S["ソフトウェアの中で判断が要る"] --> A{"答えは文章や<br/>コードか"}
    A -->|"はい"| LLM["LLM<br/>生成・説明・要約"]
    A -->|"いいえ、選択・段階・真偽"| B{"選択肢を事前に<br/>列挙できるか"}
    B -->|"できない（未知の値の抽出）"| C["先にコードで候補を作る<br/>正規表現・パーサー"]
    C --> B
    B -->|"できる"| D{"計算・日付比較・<br/>多段の推論が要るか"}
    D -->|"要る"| E["その部分はコードで書く<br/>Jevには最後の判定だけ"]
    E --> JEV
    D -->|"要らない"| JEV["Jev<br/>質問を全部まとめて1回"]
    JEV --> F{"confidence"}
    F -->|"高い"| AUTO["自動実行"]
    F -->|"中"| ASK["確認を挟む"]
    F -->|"低い"| HUMAN["人に回す / LLMで再判断"]

試すなら

• いちばん早い経路はVercel AI Gateway。 ウェイトリストなしで typesafe-ai/jev を呼べます。ただし無料枠のレート制限が厳しい（1〜2リクエスト/分程度）という報告があるので、まとまった検証はAPIキー取得後に。
• SDKは @typesafe-ai/sdk（npm）と typesafe-sdk（pip）。 環境変数は TYPESAFE_API_KEY。エンドポイントは POST https://api.typesafe.ai/v1/systemone の1本だけです。
• Claude Codeにはスキルがある。 claude plugin marketplace add typesafe-ai/skills のあと claude plugin install typesafe@typesafe-ai で、Jevを使うコードをエージェントに書かせるためのスキルが入ります。Jevがエージェントの代わりになるわけではなく、「エージェントがJevを呼ぶコードを正しく書ける」ようにするものです。
• 最初に読むのは jaggedness ページ。 何ができるかより先に「何ができないか」を9項目読んでおくと、criteria の書き方がだいぶ変わります。
• 閾値は自分のデータで決める。 公式も「正しい閾値はドメインとモデルの性能次第」としか言っていません。ラベル付きの数十件で confidence の分布を見てから決めるのが順当です。

まとめ

• ① Jevは「生成しないAI」で、返すのは型付きの判定と確率。 Choice / Score / Noul の3プリミティブだけで、用意した選択肢の外は構造的に返らない。ただし「ハルシネーションしない」はスキーマ違反がゼロという意味で、選択肢の中で間違えることは普通にある。
• ② 質問は並列・独立に評価されるので、まとめて投げるほど得。 13問で12.2倍安く10倍速く、答えは変わらない。LLMの「必要になったら聞く」とは逆に、「使うか分からない判定も先に全部載せる」（speculative fan-out）が正しいクセになる。答えの正誤ではなく confidence で「自動実行／確認／人へ」を分岐させ、閾値は操作の危険度ごとに変える。
• ③ 弱点は公式が9つ明記している。 字義通りに読む、計算できない、日付を比較できない、無関係なstateで崩れる、抽出はできない。どれも「コードで先に整えて、最後の判定だけ渡す」ことで避けられる形をしていて、これがSystem Oneモデルの使い方そのもの。日本語は「対応するが英語と同等ではない」ので、精度より閾値の再調整を前提にする。