はじめに

2026年9月、TypeSafe AIから Jev というAIモデルが公開されました。

最近のAIモデルといえば、

より自然な文章を書ける
より難しい問題を解ける
コーディング性能が上がった
長いコンテキストを扱える

といった方向の進化をよく見ます。

ところがJevは少し違います。

文章を生成することではなく、「判断すること」に特化したAIです。

最初にJevを見たとき、

判断だけするAIって、そんなに必要なのか？

と思いました。

ですが、Webアプリケーションの処理に置き換えて考えてみると、かなり面白いモデルでした。

例えば、ユーザーから送られてきた問い合わせを、

請求・支払い
アカウント
技術的な問題
その他

に自動で振り分けたいとします。

ログインできなくなりました。
パスワードを変更しても改善しません。

なら、アカウント関連っぽい。

クレジットカードから同じ料金が
2回引き落とされているようです。

なら、請求関連っぽい。

人間なら文章を読んで比較的簡単に判断できます。

しかし、これを通常のプログラムだけで柔軟に判定しようとすると、

どんな単語が含まれているか
どういう表現ならどのカテゴリなのか
複数のカテゴリに該当しそうな場合はどうするか

など、ルールを考える必要があります。

そこで最近なら、LLMに文章を渡して、

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

- billing
- account
- technical
- other

JSON形式で回答してください。

のように判断させる方法も考えられます。

でも、この処理で本当に欲しいものは文章でしょうか。

欲しいのは、

billing

という判断結果です。

しかも実際のシステムで使うなら、

billingっぽさ: 95%
technicalっぽさ: 3%
accountっぽさ: 2%

のように、どれくらい確信しているかまで分かると扱いやすい。

そこに特化したのがJevです。

この記事では、

Jevとは何なのか
普通のLLMと何が違うのか
Choice / Score / Noulとは何か
Webアプリではどう使えそうか
Laravelから使うとどうなるか
LLMとJevをどう使い分けるのか

を、Webアプリ開発者の目線から整理してみます。

Jevとは

JevはTypeSafe AIが公開した、最初の System One Model です。

公式では、

unstructured state in, typed probabilistic decisions out

という考え方で紹介されています。

ざっくり言えば、

構造化されていない情報
        ↓
       Jev
        ↓
型の決まった判断 + 確率

を返すモデルです。

通常のLLMの場合、

入力
 ↓
LLM
 ↓
文章を生成

します。

Jevは、

入力
 ↓
Jev
 ↓
判断

を返します。

ここが大きな違いです。

例えば、

Help! My payouts have been failing for 3 days.

という問い合わせについて、

緊急か？
担当部署は？
顧客はどれくらい怒っている？

といった複数の質問をJevに渡せます。

すると、

緊急度
→ Yes寄り

担当部署
→ billing

感情
→ Frustrated

のような結果を、それぞれ確率付きで返してくれます。

つまりJevは、ChatGPTのような「人間と会話するAI」というより、

プログラムの中から呼び出す判断エンジン

に近い存在です。

「AI版if文」と言われる理由

Jevについて調べると、

smart if-statements

という表現が出てきます。

確かに分かりやすい表現です。

ただ、個人的には単純に「if文をAIに置き換える」と考えると少し違うように感じます。

例えば、

if ($price >= 10000) {
    // ...
}

のような条件をJevに判断してもらう意味はほとんどありません。

コードで確実に判定できるからです。

Jevが面白いのは、

この問い合わせは緊急そうか？

このレビューは荒らし目的っぽいか？

この文章はかなり怒っているか？

この処理結果は人間による確認が必要そうか？

のような、

人間なら判断できるけれど、普通の条件式には落とし込みづらい判断

です。

そう考えると、

AI版if文

というより、

今までコードに書きづらかった「曖昧なif文」を扱うためのモデル

と考えると理解しやすい気がします。

Jevの3つの質問タイプ

Jevでは主に、

Choice
Score
Noul

という3種類の質問を使います。

Choice

Choiceは、複数の選択肢から1つを選ぶための質問です。

例えば問い合わせの担当部署を決める場合、

Which team should handle this support request?

account
billing
technical
other

のような質問を作れます。

結果は、

{
  "type": "choice",
  "choice": "billing",
  "confidence": 0.8,
  "probabilities": {
    "billing": 0.87,
    "technical": 0.13,
    "account": 0,
    "other": 0
  }
}

のような形式になります。

単に、

billing

と返すだけではなく、

billing   87%
technical 13%

という確率まで分かるのがポイントです。

これならアプリ側で、

90%以上
→ 自動処理

90%未満
→ 人間が確認

のようなルールも作れます。

Score

Scoreは、段階的な評価をさせるための質問です。

例えば、

このユーザーはどの程度不満を感じているか？

について、

0: Calm
1: Frustrated
2: Very angry

という基準を渡します。

するとJevは、

{
  "type": "score",
  "score": 1.04,
  "confidence": 0.94,
  "probabilities": {
    "0": 0,
    "1": 0.96,
    "2": 0.04
  }
}

のような評価を返します。

用途としては、

問い合わせの緊急度
リスク
顧客の不満度
コンテンツの品質
問題の重大度

などが考えられそうです。

Noul

最初に見たとき、

Noulって何？

となりました。

Noulは、Yes / Noのような二値的な判断に使います。

例えば、

この問い合わせは返金を要求しているか？

という質問です。

結果は、

{
  "type": "noul",
  "noul": 0.99
}

のようになります。

つまり、

Yesである確率 ≒ 99%

というイメージです。

ちなみにVercel AI SDKでは同様の用途をbooleanとして扱っています。

LLMとの違い

同じ問い合わせ分類をLLMで行う場合を考えてみます。

例えば、

以下の問い合わせを

billing
account
technical
other

のいずれかに分類してください。
JSON形式で回答してください。

とLLMにお願いする方法があります。

処理として見ると、

問い合わせ
    ↓
   LLM
    ↓
テキスト生成
    ↓
構造化された結果
    ↓
アプリで利用

という形です。

もちろん、現在はStructured Outputsなどがあるため、

LLMにJSONを出させるのは危険

というほど単純な話ではありません。

型の決まった出力をかなり扱いやすくする仕組みも整っています。

それでもJevとは根本的な設計思想が違います。

Jevでは、

問い合わせ
    ↓
   Jev
    ↓
Choice / Score / Noul
    ↓
アプリで利用

となります。

つまり、

文章生成を経由せず、最初からソフトウェアが利用する「判断」を出力する

ためのモデルです。

Jevは複数の判断を同時にできる

ここもJevの面白いところです。

例えば、

Help! My payouts have been failing for 3 days.

という問い合わせが来たとします。

この文章に対して、

という複数の判断を1回のリクエストで行えます。

Cloudflareの公式サンプルでも、

is_urgent
department
frustration

という3つの質問を同時に渡しています。

通常の文章生成モデルは、基本的にトークンを順番に生成していきます。

一方Jevは、宣言された質問に対する判断を並列に行う設計になっています。

TypeSafe AIがJevを高速なモデルとして紹介している理由の1つです。

「193.6倍高速、444.6倍安価」は本当？

Jev関連でかなり目を引くのが、

193.6x Faster
444.6x Cheaper

という数字です。

かなり強烈です。

ただし、ここは少し注意して見る必要があります。

これはTypeSafe AIが公開している System One向けWorkflow Evals の結果です。

つまり、

あらゆるLLMの処理で必ず193倍高速になる

という意味ではありません。

TypeSafe自身も、この数字について、

実際のユースケースで期待される改善幅の中でも高い側の結果

であると説明しています。

また、評価対象も、

Security Incident
Invoice Processing
Customer Service
Agent Trace Observability

など、Jevが得意とする「多数の判断を組み合わせるワークフロー」です。

なので、

Jev = LLMより必ず193倍速い

と考えるのは少し危険です。

一方で、TypeSafeによるとJev自体のエンドツーエンドの応答時間は、おおよそ

70ms ～ 500ms

を掲げています。

文章を生成せず、判断だけを返すモデルとして設計されているため、こうした高速化が可能になるというわけです。

料金もかなり安い

TypeSafe AIが公開している価格は、

入力:
$0.042 / 1M tokens

出力:
無料

です。

出力が無料というのも面白いところです。

通常のLLMは文章を生成するので、

入力トークン
+
出力トークン

に料金が発生します。

Jevは長い文章を生成するモデルではありません。

そのため、料金体系からも、

文章生成AIではなく、プログラム内部の判断に使うAI

という性格がよく分かります。

Webアプリで使うなら？

では、実際のWebアプリでJevを使うとしたらどうなるでしょうか。

今回は、

問い合わせの自動振り分け

を考えてみます。

ユーザーから、

ログインできなくなりました。
パスワードを変更しても改善せず、
リセットメールも届きません。

という問い合わせが届いたとします。

判断したいのは、

担当部署

です。

候補は、

account
billing
technical
other

とします。

LaravelからJevを呼んでみる

今回はCloudflare AI Gateway経由でJevを呼び出してみます。

CloudflareではJevが、

typesafe/jev

として提供されています。

CloudflareのREST APIは、

POST
/accounts/{ACCOUNT_ID}/ai/run

からモデルを実行できます。

LaravelならHttpファサードを使って呼び出せます。

まず.envに設定します。

CLOUDFLARE_ACCOUNT_ID=xxxxxxxx
CLOUDFLARE_API_TOKEN=xxxxxxxx

config/services.php

'cloudflare' => [
    'account_id' => env('CLOUDFLARE_ACCOUNT_ID'),
    'api_token' => env('CLOUDFLARE_API_TOKEN'),
],

Jevを呼び出すServiceを作ります。

<?php

namespace App\Services;

use Illuminate\Support\Facades\Http;

class JevService
{
    public function classifySupportRequest(string $message): array
    {
        $accountId = config('services.cloudflare.account_id');

        $response = Http::withToken(
            config('services.cloudflare.api_token')
        )
            ->acceptJson()
            ->post(
                "https://api.cloudflare.com/client/v4/accounts/{$accountId}/ai/run",
                [
                    'model' => 'typesafe/jev',
                    'input' => [
                        'state' => $message,

                        'questions' => [
                            'department' => [
                                'type' => 'choice',

                                'instructions' =>
                                    'Which team should handle this support request?',

                                'criteria' => [
                                    'account' =>
                                        'Login, password, profile, or security issues',

                                    'billing' =>
                                        'Charges, invoices, refunds, or subscriptions',

                                    'technical' =>
                                        'Product bugs, outages, or integrations',

                                    'other' =>
                                        'Requests that do not fit the other departments',
                                ],
                            ],
                        ],
                    ],
                ]
            );

        $response->throw();

        return $response->json();
    }
}

Cloudflare公式ドキュメントで紹介されている問い合わせ分類の例を、LaravelのHTTP Clientに置き換えた形です。

返ってくる結果

例えば公式ドキュメントでは、

I cannot log in after changing my password,
and the reset email never arrives.

という問い合わせに対して、

{
  "model": "jev-1.13.0",
  "answers": {
    "department": {
      "type": "choice",
      "choice": "account",
      "confidence": 1,
      "probabilities": {
        "technical": 0,
        "billing": 0,
        "account": 1,
        "other": 0
      }
    }
  }
}

という結果例が掲載されています。

Laravel側では、

$result = app(JevService::class)
    ->classifySupportRequest($message);

として呼び出し、

$answer = data_get(
    $result,
    'result.answers.department'
);

のように取得できます。

Cloudflare API側のレスポンスラッパーを考慮すると、実際の取得位置は利用するAPI・SDKに合わせて確認する必要があります。

重要なのは、その後です。

$department = $answer['choice'];
$confidence = $answer['confidence'];

として、

if ($confidence >= 0.9) {
    // 十分な確信度があるため自動振り分け
} else {
    // 確信度が低いため人間に確認してもらう
}

のような処理につなげられます。

これがJevのかなり面白いところだと思います。

AIに全部任せるわけではない

Jevを使うと、

AIが判断
↓
そのまま実行

としたくなります。

ですが、Jevが確率を返す意味を考えると、

                  ┌─ 確信度が高い
                  │      ↓
入力 → Jev → 判断 ┤   自動処理
                  │
                  └─ 確信度が低い
                         ↓
                     人間が確認

のように設計する方が自然です。

例えば、

account: 99%

なら自動振り分け。

一方、

billing: 51%
account: 47%

なら無理に判断せず、人間に確認してもらう。

つまり、

AIに判断そのものを丸投げするのではなく、不確実性まで含めてプログラム側で制御する

ことができます。

「Zero Hallucinations」はどういう意味？

TypeSafe AIのサイトでは、Jevについて

Zero Hallucinations

というかなり強い表現が使われています。

これだけを見ると、

Jevは絶対に判断を間違えない？

と思ってしまいます。

そういう意味ではありません。

Jevも判断自体を間違える可能性はあります。

ここでTypeSafeが言っている「hallucination」は、

あらかじめ定義していない型や値を勝手に生成しない

という意味合いが強いです。

例えばChoiceで、

account
billing
technical
other

しか定義していないのに、

customer_success

という新しい値を突然返す、といったことはありません。

Jevは指定された型の中から回答します。

しかし、

billing

と判断すべき問い合わせを、

technical

と判断してしまう可能性までゼロになるわけではありません。

だからこそJevは、不確実性もプログラムから扱える形で返します。

Choice / Scoreでは、

confidence
probabilities

Noulでは、

noul: 0.99

のように、判断の確からしさを数値として扱えます。

個人的には、

「幻覚しないAI」

というより、

出力の型を壊さず、不確実性まで返してくれる判断モデル

と理解する方がしっくりきました。

普通のコード・Jev・LLMをどう使い分ける？

ここまで調べてみると、それぞれ得意な領域はかなり違います。

手段	向いていること
普通のコード	明確なルール・計算・DB処理
Jev	曖昧な分類・評価・判断
LLM	文章生成・説明・会話・複雑な推論

例えば、

price >= 10,000円

はコードで十分です。

この問い合わせは緊急そうか？

ならJevが候補になります。

このユーザーに送る返信文を作って

ならLLMです。

これを組み合わせると、

ユーザーから問い合わせ
        ↓
       Jev
        ↓
   問い合わせ分類
        ↓
       LLM
        ↓
    返信文を生成

という構成も考えられます。

LLMを置き換えるものではなさそう

Jevを最初に見たとき、

LLMの代わりになるモデルなのか？

とも思いました。

ですが、触り方を考えていくと、むしろ逆に見えてきます。

JevはLLMを置き換えるというより、

LLMにやらせていた処理の中から「判断」だけを切り出す

ためのモデルに近そうです。

例えばAI Agentなら、

ユーザー
   ↓
  LLM
   ↓
Tool実行
   ↓
  Jev
   ↓
┌─────────────────┐
│ 成功した？       │
│ 再試行する？     │
│ 続ける？         │
│ ユーザーに聞く？ │
│ 人間に渡す？     │
└─────────────────┘
   ↓
次の処理

という使い方ができます。

実際、VercelもJevの用途として、

次のToolやSubagentを選択する
Continue / Retry / Ask User / Stopを判断する
UrgencyやRiskを評価する
Model Outputを検証する

といった例を挙げています。

「判断はJev、説明はLLM」

個人的に分かりやすいのが、

判断と説明を分離する

という考え方です。

例えばレビューのチェックなら、

レビュー
   ↓
  Jev
   ↓
規約違反？
   ↓
 Yes / No

だけをJevに担当させる。

ユーザーへの説明が必要なら、

判断結果
   ↓
  LLM
   ↓
「この投稿は〇〇の理由により
ガイドラインに抵触する可能性があります」

と文章を作ってもらう。

つまり、

Jev
→ Machine向け

LLM
→ Human向け

という役割分担です。

もちろん、実際にはここまで完全に分離できないケースもあります。

それでも、

このAI処理は「生成」が必要なのか、それとも「判断」だけでいいのか？

と考えるきっかけにはなります。

Jevが向いていそうなところ

実際のWebアプリを考えてみると、Jevを使えそうな場所はかなりあります。

例えば、

お問い合わせ
↓
担当部署の分類

レビュー
↓
スパム・荒らし判定

ユーザー操作
↓
不正利用の可能性

エラー内容
↓
人間へのエスカレーションが必要か

AI Agent
↓
次にどのToolを使うか

LLMの回答
↓
質問にちゃんと回答できているか

などです。

共通しているのは、

答えの候補は決まっているけれど、そこへ至る条件を普通のコードで書くのが難しい

ということです。

逆にJevを使わない方がいいところ

当然、すべてをJevにすればいいわけではありません。

例えば、

$total = $price * $quantity;

の計算。

$user->id === $post->user_id

のような所有者判定。

期限を過ぎているか？

のような日時比較。

これらは普通のコードで確実に判断できます。

わざわざAIを挟む必要はありません。

Jevが面白いからといって、

if文
↓
全部Jev

にするのではなく、

確実に書けるルール
↓
コード

曖昧な判断
↓
Jev

文章生成・説明
↓
LLM

と分けるのが大事そうです。

Jevで一番面白いと思ったところ

Jevを調べる前は、

また新しいAIモデルが出た

くらいに思っていました。

でもJevの面白さは、単純なモデル性能ではない気がします。

これまでAIをアプリケーションに組み込むとき、

ユーザー入力
↓
LLM
↓
何か返してもらう

という構成をとりあえず考えることが多くありました。

Jevはそこに、

ユーザー入力
↓
判断が必要？
↓
Jev

という別の選択肢を持ち込んでいます。

つまり、

「AIを使う = LLMに文章を生成させる」ではなくなる

ということです。

これまでコードかLLMのどちらかに任せていた処理の間に、

普通のコード
      ↓
     Jev
      ↓
     LLM

という新しいレイヤーが入ってくる。

これはWebアプリケーションの設計としてかなり面白い考え方だと思います。

まとめ

Jevは、文章生成ではなくソフトウェア内部の判断に特化したAIモデルです。

特徴をまとめると、

自由な文章を生成しない
Choice / Score / Noulで判断する
判断結果と確率を返す
複数の質問を並列に評価できる
ソフトウェアから直接扱いやすい
LLMと比べて高速・低コストを狙った設計

というモデルになっています。

そして個人的に一番しっくりきたのは、

Jevはif文をAIに置き換えるものではなく、これまでif文として書けなかった「曖昧な判断」をプログラムから扱えるようにするもの

という理解です。

明確なルール
↓
コード

曖昧な判断
↓
Jev

文章を作る
↓
LLM

この3つを適切に組み合わせることで、AIを使ったWebアプリの設計も少し変わってくるかもしれません。

Jev自体はまだ登場したばかりです。

TypeSafe自身もearly accessとして提供を始めた段階なので、実際の精度、安定性、どんな業務に向いているのかは、これから検証されていく部分も多いと思います。

ただ、

「人間なら分かるけど、
コードの条件式にはしづらい」

という処理をどう扱うか。

そこに新しい選択肢が出てきた、というだけでもかなり面白いです。

今後、実際のWebアプリに組み込んで、通常のLLMと速度・コスト・分類精度なども比較してみたいと思います。

参考

※ 本記事は2026年9月18日時点で公開されている情報・ドキュメントをもとにしています。