Jevとは？文章を書かないAIの仕組み・使い方・料金を解説

Jev（ジェブ）は、文章を生成せず、入力に対して型の決まった判断を返すTypeSafe AIのAIモデルです。担当部署を選ぶような小さな判断を、プログラムへ組み込むためのモデルです。

ただ、ニュースで名前を見て「ChatGPTの代わりに使えるのか」「日本語の問い合わせでも正しく判定できるのか」と迷う方は少なくありません。

この記事では、仕事の内容からJev・LLM・通常のコードのどれを使うべきかと、試す前に決めておきたい検証項目を解説します。

Jevとは？文章を生成せず判断を返すAI

JevはTypeSafe AIが2026年9月15日に公開したSystem Oneモデルです。状態（state）と定義した質問を受け取り、コードで使える型付きの結果を返します。

Jevの読み方は「ジェブ」です。

自由な文章は生成せず、ソフトウェアの部品として使うAIです。

Jevが受け取る入力と返す結果

Jevに送るのは、判断の材料になる文章などのstateと、答えてほしい質問の2つです。返答は、プログラムの分岐にそのまま使える値として届きます。

問い合わせの振り分けを例にすると、流れは次の4段階です。

• 入力：顧客からの問い合わせ文をstateとして送る
• 質問：「担当はどこか」を請求・技術・営業・その他の4つの候補で定義する
• 返答：選ばれた候補と、各候補の確率が返る
• 処理：返答を受け取ったコードが、担当部署のキューへ問い合わせを渡す

たとえば「請求が二重に引き落とされました」という文なら、請求0.9・技術0.05・営業0.01・その他0.04のような確率付きで請求が選ばれます。ここでの数値は説明用の架空の例で、実測値ではありません。

担当部署へ渡す処理を実行するのは、Jevではなく呼び出し側のコードです。Jevの役割は、文の意味を読んで決まった形の答えを返すところまでです。

入出力の考え方は、TypeSafe AIの公式ドキュメント（Introduction）と公式のQuick startで確かめられます。

Choice・Score・Noulは何が違う？

Jevで使える質問は3種類です。Choiceは候補から1つを選び、Scoreは段階で評価し、Noulは条件が真である確率を返します。

同じ問い合わせ文「二重請求されています。至急返金してください」に対して、3つを同時に聞いた場合の返答の形は次の通りです。

質問形式	返答の形	問い合わせ業務での例	注意点
Choice	選んだ候補（choice）、各候補の確率（probabilities）、確信度（confidence）	担当は請求・技術・営業・その他のどれか	候補は最大255個。当てはまらない入力用に「その他」を置く
Score	段階上の位置（score）、各段階の確率、確信度	緊急度は3段階のどこか	段階は2〜10個。段階の間の値（1.5など）も返る
Noul	「はい」である確率（noul、0〜1）	返金を求めているか	別の確信度（confidence）の項目はない

3つの質問は1回のリクエストにまとめて送れます。Jevはそれぞれの質問を、同じstateをもとに独立して判断します。

見落としやすいのは、Noulだけ確信度が付かない点です。Noulの0.5は「中くらい」ではなく、「はい」と「いいえ」が半々という意味になります。

確信度を使った処理の分け方は、確信が低い入力を人へ渡す条件に関する見出しで解説します。仕様の全体は公式ドキュメントのPrimitivesとConfidenceのページに載っています。

Jev・LLM・通常の条件分岐をどう使い分ける？

文章の作成や長い推論にはLLM、条件を完全に書ける処理には通常のコード、文の意味を読んで決まった処理へ渡す仕事にはJevを検討します。

方法	入力から得るもの	向く仕事	向かない仕事
Jev	定義した候補・段階と、その確率	問い合わせの振り分け、優先度の判定	返信文の作成、長い手順の検討
LLM	文章・要約・コード（構造化出力も可）	返信文の下書き、要約、複数資料をふまえた検討	答えの候補が決まった判断だけを大量に回す処理
通常の条件分岐	条件に一致したかどうか	金額・日付・完全一致する文字列での分岐	言い回しが毎回違う文の意味の判定

3つは取り合う関係ではなく、1つの業務の中で工程ごとに組み合わせて使えます。

JevとLLMでは返答と役割が違う

Jevはチャットの返答、要約文、コードを作らないため、顧客へ文章で返す仕事にはLLMが必要です。ChatGPTやClaudeの代わりではなく、組み合わせて使う部品と考えると役割がはっきりします。

問い合わせ対応なら、工程を2つに分けられます。担当先を選ぶ工程はJevのChoiceに任せ、顧客への返信を書く工程はLLMに残す形です。

こうして分けると、振り分けの正しさと返信文の品質を別々に評価できます。どちらかに問題が出たとき、直す場所もすぐに分かります。

ただし、LLMにもJSONなどで答えを返す構造化出力の機能があり、分類そのものができないわけではありません。

Jevを選ぶ理由は、判断と確率を返す用途に絞って作られ、答えが必ず定義した型に収まる点にあります。

開発元の考え方は、TypeSafe AIの公式発表と公式ドキュメントで読めます。

条件を明確に書けるなら通常のコードで足りる

「金額が10万円以上なら承認へ回す」のように条件を明確に書ける処理は、Jevに判断させず、通常の条件分岐で処理します。

違いがはっきり出るのは、解約の申し出を見つける場面です。

「解約したい」「来月から使わない予定です」「契約を止める手続きを教えて」は、言い回しが違っても同じ意図です。キーワードの完全一致では拾いきれない文の意味を読む部分が、Jevを検討する範囲になります。

一方、プラン名や会員IDのように、値が完全に一致するかどうかで決まる判定は、コードで書けば毎回同じ結果になります。

Jevを呼ぶたびにAPI料金と応答までの待ち時間がかかり、誤判定の可能性も生まれます。コードで書ける部分までAIに任せる理由はありません。

公式ドキュメントのHow to build with TypeSafeでも、閉じたチケットのような確定した状態はモデルを呼ばずに処理する例が示されています。

Jevはどんな業務に向いている？

Jevを検討する価値があるのは、決まった候補へ大量の入力を振り分ける仕事です。正解が候補にない仕事や、長い推論・自由な文章が必要な仕事には、別の手段を使います。

問い合わせや文書の振り分けに使う

最初に試すなら、担当部署の振り分けや文書の種類の分類のように、返答の候補と次の処理が決まっている仕事がJevに向いています。

問い合わせなら、問い合わせ文を受け取り、Choiceで請求・技術・営業・その他から選び、選ばれた担当部署のキューへ送る流れです。

文書の分類も同じ形です。届いたファイルのテキストを請求書・契約書・見積書・その他に分け、保存先のフォルダを決める処理に使えます。

候補に「その他」を入れるのは、どの候補にも当てはまらない入力を無理に押し込まないためです。「その他」になったものを人が確認すれば、候補の抜けにも気づけます。

振り分けた後の自動返信や返金の実行は、Jev単体では行いません。担当者や別の仕組みが、判断結果を受けて動く形になります。

候補の書き方の例は、公式ドキュメントのPrimitivesで確かめられます。

優先度や条件の該当確率を返す

分類のほかにも、段階の評価はScore、条件に当てはまるかの確率はNoulでJevに返させ、次の処理はコード側で決められます。

緊急度なら、「0：急ぎではない」「1：今日中に対応したい」「2：業務が止まっている」のように段階を定義し、スコアが高い問い合わせから対応の順番を並べ替えます。

返金依頼の有無ならNoulを使い、「はい」の確率が一定以上のものに返金担当のラベルを付けるといった使い方です。

注意したいのは、数値の意味が質問の定義で決まる点です。同じ1.5でも、段階の書き方を変えれば指す状態が変わります。

そのため、値が高いというだけで返金や通知をすぐ実行するのではなく、ラベル付けや並べ替えのような取り消しやすい処理から始めるとよいでしょう。

長い推論や自由文の生成には使わない

顧客への返信文の作成や、複数の資料をふまえて長い手順を検討する仕事は、Jev単体の役割ではありません。

質問を小さく分ければ、それぞれの判断はJevに任せられます。それでも、必要な資料を集める、処理の順番を決める、最終的な文章を書くといった工程は、通常のコードやLLMが担います。

入力の形にも制限があります。Jevに渡せるのはテキストだけで、画像・音声・動画は直接渡せません。

たとえば請求書のスキャン画像を判定したい場合は、先にOCRでテキストにする処理が必要です。詳しくは日本語と画像・音声の入力に関する見出しで解説します。

入力形式の仕様は、公式ドキュメントのModelsに載っています。

Jevの料金・速度・日本語対応は？

Jev 1.13.0の公開料金は、入力100万トークン当たり0.042ドルで、出力トークンは無料です。英語が最も得意で、日本語は自社のデータで精度を評価してから使う必要があります。

料金と速度の公表値はどう読む？

Jevの料金は入力トークンだけで計算され、出力トークンには課金されません。公式ドキュメントのModelsでは、10億トークン当たり42ドル、100万トークン当たり0.042ドルと示されています。

項目	公式の値・条件	導入時に測るもの
料金	入力100万トークン当たり0.042ドル、出力は無料	1件あたりの入力トークン数と月間件数から出す実際の費用
速度	1回の判断で70〜500ミリ秒（開発元の発表値）	自社の環境での往復時間と、遅い側の応答時間
モデルID	jev-1.13.0（jev-latestは最新の正式版を指す別名）	実際に応答したモデルの版（レスポンスのmodel欄）

質問文や候補の説明も入力トークンに含まれるため、同じ問い合わせ文でも質問の数や書き方で費用は変わります。

速度の70〜500ミリ秒は、TypeSafe AIの公式発表に基づく値です。発表ではフロンティアLLMより大幅に速く安いという比較値も掲げていますが、開発元自身の評価条件で測った数字です。

開発元もその比較値を、現実の改善幅としては高い側の結果だと注記しています。日本から呼ぶ場合は通信の往復時間も加わるため、自社の環境で測った値で判断するのが確実です。

なお、Jevに1回のリクエストで渡せるのは、stateと質問を合わせて64,000トークンまでです。

日本語と画像・音声の入力には制約がある

Jevには日本語のテキストも入力できますが、英語と同等の精度は示されていません。

公式ドキュメントは英語を主な学習言語とし、日本語を含むCJKの文字は扱えるものの、同じ精度ではないと説明しています。英語以外で使う前に自社のコンテンツで試し、振り分けでは確信度に注意するよう勧めています。

「日本語対応」という言葉だけで導入を決めず、自社の問い合わせ文を使って正解率と確信度を測ってから判断しましょう。

画像・音声・動画は、Jevに直接入力できません。入力はテキストのみで、文字列・JSONオブジェクト・テキストの配列のいずれかの形で渡します。

請求書の画像ならOCR、通話なら文字起こしで先にテキストへ変換し、その結果をstateに入れて送ります。

Jevを試すには何から始める？

Jevを試すなら、1つの入力文と1つの質問でPlaygroundの返答を確かめてから、APIへ移ると手戻りが少なくなります。

なお、TypeSafe AIは需要の急増で新規登録を一時停止したあと、2026年9月27日に再開を発表しています。ただし、再開後の新規アカウントには以前付いていた無料クレジットが付かないため、Playgroundで試す前に利用料金の支払い方法を確かめておきましょう。

Playgroundで入力文と質問を設定する

コードを書かずに試すなら、Jevの公式Playgroundにログインし、stateに短い文章を入れて、Choice・Score・Noulのいずれか1つの質問を作って返答を見ます。

• 例示用の問い合わせ文を用意する（実在の顧客の文章や個人情報は使わない）
• 質問と候補を定義する（例：担当は請求・技術・その他のどれか）
• 返答と各候補の確率を見る
• 判断が分かれそうな曖昧な文でも試す

4つ目の手順を省くと、分かりやすい文で正しく答えた結果だけを見て、判断が難しい入力での振る舞いを知らないまま次へ進むことになります。

たとえば「請求の件で連絡しましたが、ログインもできません」のように2つの話題が混じる文を入れると、確率が複数の候補に分かれるかどうかを見られます。

公式のQuick startでも、Playgroundにログインし、stateに任意のテキストを貼り付けて試す手順が案内されています。

APIの返答をコードの処理へつなぐ

Playgroundで手応えを確かめたら、APIでJevにstateとquestionsを送り、返答の型付きフィールドを読んでコードの処理を分岐します。

公式Quick startの形に沿うと、リクエストの要点は次の3つです。

• 送信先は POST https://api.typesafe.ai/v1/systemone
• ヘッダーのAuthorizationにAPIキーを付ける
• modelに jev-latest、questionsに質問の種類（type）と指示文（instructions）を入れる

返答を受け取った後の処理は、次のような流れです。実行できるコードではなく、流れを示す擬似コードです。

answer = Jevの返答.answers["department"]
もし answer.choice が "billing" なら → 請求担当のキューへ送る
もし answer.choice が "other" なら → 人の確認待ちへ送る

SDKはPython向けとJavaScript向けが用意されています。細かなパラメータは、組み込む時点の公式ドキュメントに合わせて指定します。

APIキーはサーバー側で管理し、ブラウザで動くコードや共有リポジトリに書き込まないようにします。

最初の1件を試す手順は、TypeSafe AI公式のQuick startから確認できます。

Jevを業務に入れる前に何を検証する？

Jevを業務に入れる前には、対象業務の実例で正解率、曖昧な入力での振る舞い、既存の方法との差を測り、人へ戻す条件を決めます。作業の順番は次の3段階です。

• 実際の日本語データに正解ラベルを付け、今の方法と同じデータで誤りの数を比べる
• 自動で進める・人が確認する・人が対応するの3段階と、その境目を決める
• 使ったモデルの版を記録し、版が変わったら同じデータで結果を比べ直す

全件の自動化を前提にせず、まず一部を自動で処理し、残りを人へ戻す形から始めます。

正解例と曖昧な例を混ぜて精度を測る

Jevの試験には、実際の日本語データから正解ラベル付きの例を用意し、誤分類の数と種類を数えます。

分かりやすい文だけで試すと、正解率が実際より高く見えます。評価用のデータには、次のような入力を意図して混ぜます。

• どの候補にも当てはまらず「その他」に入るべき文
• 「先日の件です」のように情報が足りない文
• 請求と不具合の相談が混じるなど、複数の意図を含む文

誤りは件数だけでなく、「技術を請求と取り違えた」のように何を何と間違えたかまで記録します。取り違えの傾向が分かると、候補の定義文のどこを直せばよいかが見えてきます。

比較には、今使っているLLMやルール処理と同じデータを使います。速度や費用が下がっても、誤りを直す人の手間が増えれば、業務全体では得になりません。

採用するかどうかは、正解率・誤りの種類・人が確認する件数をあわせて見て決めます。

確信が低い入力を人へ渡す条件を決める

Jevの誤りを業務へ流さないためには、ChoiceとScoreの確信度（confidence）や確率の分布を見て、曖昧な返答を人へ回す処理をコードで決めます。

公式ドキュメントのConfidenceでは、確信度を高・中・低の3つの範囲に分け、それぞれ別の動きをさせる形を出発点として示しています。

問い合わせの分類に当てはめると、確信度が高いものは自動で振り分け、中くらいのものは担当者が確認してから確定し、低いものは最初から人が対応する3段階です。

それぞれの境目の値は、自社のデータと誤判定したときの影響で決めます。公式ドキュメントも、同じシステムの中で取り消しにくい操作ほど高い確信度を求める例を示しています。

Noulには別の確信度の項目がないため、「はい」の確率そのものに境目を設けます。

また、答えが必ず定義した型で返ることは、判断が正しいことを意味しません。候補の中から間違った担当を選ぶ可能性は残るため、人へ戻す経路は必ず用意しておきます。

返答の形式は公式ドキュメントのPrimitivesで確かめられます。

モデル更新後も同じ入力で再評価する

jev-latestは参照先のモデルの版が変わる別名です。Jevで使った版を記録し、更新後は同じ評価用データで結果を比べ直します。

公式ドキュメントのModelsによると、jev-latestは最新の正式版を指し、新しい版が出ると移動します。利用者側で何も変えなくても、同じ入力への返答が変わる可能性があるということです。

レスポンスのmodel欄には実際に応答した版のIDが入ります。判定結果と一緒に保存しておくと、どの版で出た結果かを後から追えます。

確信度の境目を特定の版で調整した場合は、別名ではなくjev-1.13.0のような版のIDを指定し、自社の都合に合わせて移行することを公式ドキュメントも勧めています。

重要な業務ほど、移行の前に正解率・確信度の分布・処理時間を旧版と新版で見比べ、差が許せる範囲か確かめてから切り替えます。

Jevのまとめ

Jevは、意味を含む入力を定義済みの判断へ変える小さな部品として検討するAIです。自由な文章の作成はLLM、明確に書ける条件は通常のコードに任せ、その間にある「文の意味を読んで決まった処理へ渡す」工程にJevを置きます。

日本語は英語ほどの精度が示されていないため、開発元が示す速さや安さより、自社の問い合わせ文で測った正解率と、誤りを人が直す手間を優先して判断してください。

正解ラベル付きの実例を用意でき、確信度が低い返答を人へ戻す条件を決められる方は、問い合わせの分類など1つの作業に絞った小規模な試用から始めるとよいでしょう。

評価用のデータをまだ用意できない段階なら、今のLLMやルール処理を続けながら、正解ラベル付きの実例集めを先に進めるのが確実です。準備が整ったら、TypeSafe AI公式のQuick startに沿って最初の1件から試せます。