Jev とは？TypeSafe AI の仕組み・LLM との違いと使い方

Jev は、TypeSafe AI が提供する「ソフトウェアから使う判断」に特化した AI モデルです。 問い合わせ文を読んで担当部署を選ぶ、対応の緊急度を評価する、用意された操作から次の一手を選ぶ、といった処理を想定しています。説明文を受け取って読み解く代わりに、プログラムが扱える値と確率を受け取ります。

ゲームを操作する動画を見て気になった方も、業務システムに組み込みたい方も、まず確認したいのは「何ができるか」と「何を保証しているか」です。この記事では、創業者の発信から開発の背景をたどり、公式 API と SDK の仕様に沿って使い方を整理します。

Jev と TypeSafe AI の関係

TypeSafe AI は開発元、Jev はモデル名、System One は同社が提案するモデルの区分です。公式の紹介では、状態を表す state と型付きの質問を渡し、コードから利用する構造化された回答を受け取ります。TypeSafe の Introduction に、この入出力の考え方が説明されています。

発表記事 の掲載日は 2026 年 9 月 15 日です。発表時は早期アクセスとして案内されているため、アカウントを登録すれば誰でも直ちに同じ条件で利用できる、とまでは読まないでください。

名前が TypeSafe だからといって、TypeScript 専用のサービスではありません。HTTP API に加えて Python と JavaScript / TypeScript の SDK が公開されています。ここでいう型は、受け取る値の形や候補をあらかじめ定めるという意味です。

創業者 Diogo Almeida の投稿から見える開発の背景

ChatGPT につながる研究から、業務の自動化へ

X の @CompleteSkeptic は、TypeSafe の CEO である Diogo Almeida 氏のアカウントです。公式チーム紹介 で役職を確認でき、InstructGPT を扱う 2022 年の論文 の著者にも名前が載っています。「ChatGPT を 1 人で作った人物」という紹介では、研究への関わりを正確に伝えられません。

発表前の 7 月 20 日の投稿 では、モデルの印象的な能力と社会での自動化の進み方との違いを論じています。人が好む応答を最適化することと、処理を自律的に完了できることを分けて考える姿勢です。これは Almeida 氏の見解であり、AI 全体の生産性を測定した結果ではありません。

この問題意識は TypeSafe のマニフェスト にもつながっています。同社は、ソフトウェアが意味や意図を判断するときに AI を呼び出し、正確な計算や制御にはコードを使う構成を提案しています。大きな処理をすべて 1 回の依頼にまとめるより、小さな判断を組み合わせられることを重視しています。

発表後も「自分の仕事で評価する」と強調

発表後の 業務評価を支持する投稿 では、公開ベンチマークだけでなく、実際の仕事に即した評価に注目しています。また モデルの位置付けについての投稿 では、単純にモデルを小さくするのではなく、文章生成を手放して組み合わせやすさを得る、という趣旨を述べています。

さらに チャットとの関係を説明した返信 でも、チャットの全面的な置き換えとは捉えていないと述べています。

この発信から記事として導けるのは、「すべての AI が Jev に置き換わる」という結論ではありません。文章の生成と、アプリケーション内の判断を別々に設計する選択肢が増えた、と捉えると用途を考えやすくなります。

Jev と LLM の違いは、コードに何を返すか

文章を生成する LLM は、説明、要約、プログラムの草案など、答えの形を事前に列挙できない仕事に適しています。Jev は、あらかじめ決めた質問と出力の範囲を使う設計です。比較するときは、チャット画面の印象ではなく、アプリケーションが必要とする出力を基準にします。

LLM にもスキーマに沿った出力を得る機能があります。「LLM は JSON を返せないから Jev が必要」という説明は不正確です。LLM の構造化出力の設計と比較し、出力形式だけでなく、処理時間、費用、判断精度まで含めて選びます。

たとえば問い合わせ対応なら、Jev に分類を任せ、既存のチケット管理システムが担当先を決め、返信の下書きが必要なときだけ文章生成モデルを呼ぶ構成が考えられます。部署の決定と返信文の作成を分けることで、それぞれの評価データも作りやすくなります。

FIXIT

いま使っている AI を、全部 Jev に変える話ではないんだね？

Hayate

はい。選択肢を決められる判断が候補です。文章を書く処理は、生成モデルと分担します。

System One と RLCD は何を目指しているのか

公式の AI primer は、RLCD を Reinforcement Learning for Calibrated Decisions と説明しています。判断と確率を学習の対象にし、確率をソフトウェアの制御に利用する考え方です。

ここでの calibration、つまり確率の較正は、多数の予測をまとめて見たときに、予測した確率と実際の結果の割合が対応することを指します。単発の回答が必ず正しいという保証とは異なります。業務データや質問の作り方が変われば、同じ性能が得られるか改めて確かめる必要があります。

また、System One は「何でも短時間で解決する」という意味ではありません。複数の条件を長く検討する問題なら、条件を分け、必要な情報を与え、それぞれの回答を組み合わせる設計が要ります。「この案件をうまく処理して」と一括で頼むより、「情報は足りているか」「どの担当が適切か」を別々に問うほうが、失敗した箇所を調べやすくなります。

この方法は開発者の役割を減らすだけのものではありません。何を質問するか、どの状態を渡すか、結果をどう使うかがシステムの品質を左右します。モデルの学習目標を理解したうえで、質問と業務ルールを設計することが必要です。

Choice・Score・Noul の使い分け

Jev には 3 種類の基本的な質問があります。同じ言葉でも、何を判定するかによって適した型は変わります。

Choice は、順序のない候補から選ぶ質問です。請求、技術、その他といった分類に使えます。候補に含まれない入力があり得るなら、other などの受け皿を設けます。候補の定義が重複している場合は、どちらを優先するかも決めておきます。

Score は、説明を付けた段階に沿う評価です。返る値は段階の間の値になることもあります。たとえば 0 を「影響の記載なし」、1 を「一部の操作ができない」、2 を「主要な業務を続けられない」と定義したなら、値の意味はその尺度に限られます。別の尺度で得た 1.5 と直接比較しないでください。

Noul は、モデルが推定した真である確率を 0〜1 で返します。0.5 は程度が中くらいという意味ではありません。「返金を希望しているか」に対して 0.5 なら、真偽の判断が拮抗していると読みます。Noul には独立した confidence フィールドがない点も、Choice や Score と異なります。

「緊急度」という項目名だけでは、3 種類のどれを使うかは決まりません。緊急という語が含まれるか、対応を急ぐべきか、影響の大きさを何段階で表すかは別の質問です。質問を文章で書いてから、必要な答えに合う型を選ぶと曖昧さを減らせます。

同じ状態を見る質問はまとめ、依存する質問は分ける

Primitives の仕様 では、同じリクエストに入れた質問は共通の状態を見て、独立して評価されます。したがって「部署を選び、その部署の回答を見て次を決める」という依存関係は、同じリクエストに並べるだけでは表せません。

入力文からそれぞれ直接判断できる「部署」と「返金依頼の有無」は一緒に聞けます。一方、最初の判断によってデータベースから追加情報を取得する場合は、その取得後に次のリクエストを作ります。並列にできる範囲を設計することで、必要な情報がないまま後続の判断を行うのを避けられます。

「型が安全」と「判断が正しい」は別の話

部署の候補を billing、technical、other に限定した場合、候補外の部署名が返らないことと、正しい部署が選ばれることは別です。技術的な相談を billing に分類しても、型には適合します。

さらに、型が正しく分類も合っていても、その後の処理が正しいとは限りません。請求の相談であることから、返金を実行してよいと結論付けるには情報が不足しています。注文の実在、二重請求の有無、契約条件、実行者の権限などは、アプリケーション側で確認します。

型の制約には価値があります。未知の部署名に備える処理を減らし、候補ごとの分岐をコードとして書けるからです。ただし、その利点を「内容の誤りが起こらない」と広げると、必要な評価を省いてしまいます。

confidence は正答率をそのまま返すフィールドではない

Confidence の説明 では、confidence は回答の確率分布から計算する指標です。候補のどれかに分布が集中しているかを要約しており、confidence: 0.9 を「この回答が 90% の確率で正解」と直訳することはできません。

しきい値を決めるときは、検証用データで「この値以上の案件を自動処理したとき、何件が誤っていたか」を数えます。しきい値を上げると、人に回す案件が増える可能性があります。誤分類の減少と自動処理できる割合を、同じ表で追うことが大切です。

TypeScript で Jev を使う最小構成

アカウントと API キーを用意する

公式の Quick start では、コンソールで API キーを取得して呼び出す手順が案内されています。利用権限を確認したうえで、サーバー側の環境変数 TYPESAFE_API_KEY に設定します。キーをブラウザへ配信するコードや Git に含めないでください。

JavaScript SDK の要件は Node.js 20 以上です。次の例は独立した作業用ディレクトリで利用する想定です。

pnpm add @typesafe-ai/[email protected]
pnpm add -D typescript tsx @types/node

Vercel AI Gateway 経由でも利用できる

Vercel は 9 月 16 日に Jev の AI Gateway 対応を発表しています。AI SDK 7.0.105 以降の実験的な evaluate API で、typesafe-ai/jev を指定する経路です。既に AI Gateway でモデル呼び出しを管理している場合は、この接続方法も候補になります。

ただし、以下のコードは TypeSafe の直接 SDK 用です。Gateway 側では真偽判定を boolean と表し、confidence の取得場所も異なります。2 つの API のフィールドを混ぜず、利用する経路のドキュメントに合わせてください。

部署の分類と返金依頼の判定をまとめて送る

次を triage.mts として保存します。SDK の choice と noul を使い、結果の確認だけを行う例です。チケットの更新や返金は実行しません。

import { choice, noul, TypeSafeClient } from "@typesafe-ai/sdk";
 
const client = new TypeSafeClient({
  timeout: 5_000,
  retry: { maxRetries: 0 },
});
 
const response = await client.systemOne({
  state: {
    message: "同じ注文の代金が二重に引き落とされました。返金をお願いします。",
  },
  questions: {
    department: choice("message の主な相談内容を分類してください。", {
      billing: "請求、支払い、返金についての相談",
      technical: "機能の不具合や操作方法についての相談",
      other: "どちらにも該当しない、または情報が不足している相談",
    }),
    refundRequested: noul("message は返金を明示的に依頼していますか？"),
  },
});
 
const department = response.answers.department;
const selected: "billing" | "technical" | "other" = department.choice;
 
console.log({
  selected,
  distribution: department.probabilities,
  confidence: department.confidence,
  refundRequested: response.answers.refundRequested.noul,
  usage: response.usage,
});

環境変数を設定したシェルで pnpm exec tsx triage.mts を実行します。掲載コードは SDK 0.6.0 と TypeScript 6.0.2 で型チェックを通しています。日本語の判定結果や応答時間を実測した例ではないため、架空の実行結果は掲載していません。

selected を billing、technical、other のいずれかに限定した型として受け取れる点が、TypeScript 側での利点です。別の部署名を使う分岐を書いたり、存在しない回答フィールドを参照したりする誤りを、開発時に見つけやすくなります。

SDK の クライアント実装 と 型定義 も公開されています。この例の 5 秒はアプリケーション側で設定したタイムアウトであり、Jev の速度保証ではありません。再試行を 0 回にしているのは、試行回数が見える最小例にするためです。本番では呼び出し側の期限と再試行方針を合わせます。

結果を実行につなぐ前に、分岐を設計する

最初は出力を記録し、人が付けた分類と比較してください。次に other、不確かな回答、通信失敗を、人が確認するキューへ送るようにします。自動処理の対象は、検証を終えた分類だけに限定して広げます。

API 呼び出しに成功したことと、チケットが更新されたことは別です。後続の更新が失敗したときに、同じチケットを重複登録しない設計も必要になります。判定結果、対象チケットの識別子、処理状態を分けて記録すると、どこからやり直すべきか判断しやすくなります。

ゲーム・ブラウザのデモはどこが面白いのか

マリオの動画は、判断を繰り返す用途の入口

開発者 Fadil Shaik 氏は、Jev に Super Mario Bros. を操作させる動画 を公開しています。短い間隔で次の操作を選ぶ用途は、文章生成とは異なる Jev の使い道をイメージしやすい例です。

ただし、動画から分かるのはその実装の実行場面です。失敗を含めた試行回数や条件を揃えた評価なしに、ゲーム全体を安定して攻略できる、別のゲームでも同じ性能になる、とまでは言えません。映像の見栄えと再現性の検証は分けて扱います。

また State の仕様 では、Jev の入力はテキストで、画像・音声・動画は非対応です。ゲームの動画があることを「Jev が映像を直接見て判断している」証拠として扱うのは誤りです。ゲーム内の状態をどう取得し、テキストに変換して渡すかも実装の一部になります。

ブラウザ操作では、Jev と別モデルの分担にも注目

Almeida 氏が 紹介した Browser Use と Jev のデモ では、引用された開発者の説明に DOM による状態表現と、文字入力用の小さな LLM へのフォールバックが挙げられています。Jev だけで自由な文字入力まで担ったという説明ではありません。

ここから考えられる実装方針は、表示されている操作候補の選択を Jev に任せ、入力文の作成は生成モデル、実際のクリックや入力はブラウザ操作のコードに担当させることです。新しいページへ移ったら操作候補を更新します。前の画面に存在したボタンを、次の画面でも使えると思い込まない設計が要ります。

ゲームやブラウザのデモが面白いのは、速度だけでなく、この分担を試せる点です。既存のアプリケーションが状態と操作を明確に持っていれば、限定した判断を追加する用途を検討できます。

「高速・低コスト」の数字をどう読むか

公式の Workflow evals は、セキュリティ事象、エージェントの実行記録、請求書処理、顧客対応の 4 種類を扱います。共通の処理手順に沿ってモデルを比較する一方、参照回答には大規模モデルの出力を使っています。人が全件確定した業務上の正解に対する精度と、同じ意味ではありません。

発表記事には、比較対象に対して速度が 193.6 倍、費用が約 1/444.6 という同社の評価結果が掲載されています。同社自身も、実際の改善幅の中では大きい側の結果と説明しています。これらは、上記の評価条件に結び付いた数字です。短い入力、質問の分け方、比較モデルの推論設定、呼び出す地域で結果は変わります。自社の長い日本語文書でも同じ倍率になるという保証として使わないでください。

たとえばユーザーが待つ時間を評価するなら、モデルへの API 呼び出しだけでなく、データ取得、ネットワーク、再試行、後続の処理まで測ります。平均が短くても、一部のリクエストだけ数秒待たされるなら、対話画面での印象は変わります。

比較用に同じ入力と出力をそろえ、既存モデルにも必要な構造化出力を設定します。一方だけ詳しい確率を返させ、もう一方は部署名だけを返させると、同じ仕事の比較になりません。モデル単体の比較と、サービス全体として採用した場合の比較は、記録を分けると判断しやすくなります。

Jev の料金は、業務 1 件の総費用で考える

料金や利用枠は TypeSafe の公式サイト と利用中のコンソールで確認してください。発表時の単価だけで月額費用を固定すると、入力の長さや契約条件、再試行の増加を見落とします。

試算には、1 件あたりの入力トークン数、処理件数、再試行を含む平均呼び出し回数、適用される料金条件を使います。質問や候補の説明も入力に含まれるので、同じ本文でも設計によって使用量が変わります。本文だけの文字数から費用を決めないでください。

月間の推論費用
  = 月間処理件数 × 1 件あたりの平均使用量（再試行を含む）÷ 課金単位 × 適用単価
 
業務全体の費用
  = 推論費用 + 周辺システム費用 + 人が確認する作業費用

比較時に確認したいのは、単に API の費用が下がるかだけではありません。誤分類の調査や手直しが増えていないか、従来より多くの案件を人に戻していないかも含めます。反対に、単価が同程度でも、対応待ちの時間を短くできれば導入の理由になります。LLM のコスト最適化でも、処理全体から見積もる観点を整理しています。

実務に導入するなら、問い合わせ分類から比較する

以下は公式ベンチマークの再掲ではなく、本記事で提案する評価手順です。まずは結果を取り消しやすく、人の判断と比較できる業務を選びます。既存の問い合わせに分類候補を付ける処理なら、最初から顧客向けの返答や返金を自動化する必要はありません。

1. 判断の対象と正解を決める

問い合わせの担当部署を決めるなら、単一の相談、複数部署にまたがる相談、情報不足、対象外を含む検証用データを用意します。担当者の間でも判断が割れる例は、モデルの評価前に扱いを決めます。曖昧な正解をそのまま使うと、モデルの改善とルールの変更を区別できません。

日本語では、依頼が遠回しに書かれていたり、前のやり取りを省略していたりする例も入れます。「返金は不要です」と「返金してほしいです」のように、近い語を使っても判断が逆になる組み合わせを確認します。顧客の文章に別の指示が混ざる場合も検証対象です。

2. しきい値を調整するデータと、最終評価のデータを分ける

同じ案件を見ながら質問としきい値を何度も調整すると、その案件には合っていても新しい入力では誤る可能性があります。調整用のデータと、最後に性能を確かめるデータを分けます。調整中に最終評価の結果を見て方針を変えたら、その評価を独立した確認と呼ばないようにします。

しきい値は部署ごとに変える余地があります。誤った部署へ送ってもすぐ直せる処理と、営業時間外の通知を発生させる処理では、許容する誤りが違うためです。モデルの返す値だけでなく、実行する操作の影響で決めてください。

3. 精度と自動処理率を並べて比較する

p95 は、応答時間を短い順に並べたときの 95% 点です。遅いリクエストも含めてサービスの応答時間を考えるために使います。測定時は利用地域、入力の長さ、同時実行数、モデル名、SDK のバージョンを記録しておきます。

4. 既存処理と並行して確認してから切り替える

最初は Jev の判定を記録するだけにして、現在の担当者や既存システムの判断と突き合わせます。どの分類で間違えるかが分かってから、範囲を限定して振り分けを有効にします。

Jev を呼び出す部分を小さな関数にまとめておけば、比較対象のモデルや手動処理へ戻しやすくなります。質問の仕様と呼び出し元の業務ロジックを分ける考え方は、AI 開発でベンダーロックインを避ける設計とも共通します。

Jev は、小さな判断をソフトウェアに追加する選択肢

Jev の注目点は、ソフトウェアが利用する判断を、型と確率を持つ出力として受け取れることです。創業者の発信にも、対話の印象的な能力を、実際の自動化につなげたいという問題意識が見られます。

使い始めるなら、担当部署の分類や処理の振り分けなど、入力と候補を決められる仕事を選んでください。既存の方法と同じデータで比較し、判断の精度、人に戻す割合、応答時間、総費用を確認します。型の保証を生かしながら、業務上の正しさは別に評価することが、採用判断の出発点です。

FIXIT は AI 駆動開発のクリエイティブスタジオとして、AI を組み込むプロダクトの設計・開発を支援しています。業務のどの判断から試すかを整理したい場合は、お問い合わせからご相談ください。