はじめに
Jevは、文章や業務データを読み取り、分類・採点・条件判定の結果を確率付きで返すAIモデルです。
モデルが返す結果は、アプリケーションが処理を分岐する場面に利用することが想定されています。プログラムは条件を明確に判定し、複雑な制御に応用することが可能です。
このJevが発表された後、まるでJevが従来のLLMや周辺のAIエージェントの技術を置き換えるかのような盛り上がりを見せていますが、果たしてJevと従来の技術は何が違うのでしょうか。この記事では、その違いを冷静に紐解いていきます。なお、従来技術の例として、AWSのAmazon Bedrock AgentCoreを取り上げています。
Jevの初出
TypeSafe AIは2026年9月15日、同社が「System One Model」と呼ぶAIモデルの最初の公開モデルとして、Jevを発表しました。
System Oneという名称は、ダニエル・カーネマンが説明した、素早く直感的に判断する「システム1」に由来し、Jevの名前は、効率改善に伴って資源の利用が拡大する現象で知られる経済学者ウィリアム・スタンレー・ジェヴォンズにちなんでいるそうです。
従来のLLMとJevの違い
TypeSafe AIはJevの発表にあたってアプリケーションが利用しやすいAIの出力を重視しているとしました。
業務システムには、問い合わせの内容を分類する、文書が条件を満たすか確認する、次の処理を選ぶといった判断が数多くあります。Jevは、このような判断を型付きの値として返し、プログラムが直接利用できるように設計されています。
この説明だけではやや難しいので、分かりやすい例を挙げてみましょう。例えば、顧客から次のメールが届いたとします。
先ほどの注文ですが二重に請求されています。重複した分を返金してください。先週も問い合わせましたが、まだ返事がありません。
これに対してシステムが行うべき処理はどう決まるのでしょうか。従来のLLMをAIエージェントと組み合わせて実装したシステムと、Jevを非AIエージェントのアプリケーションと組み合わせて実装したシステムで比べてみましょう。
従来のLLM+AIエージェントの場合
Amazon Bedrock AgentCoreなどでAIエージェントを実装してシステムを運用している姿をイメージしてください。
AIエージェントは、LLMに対して顧客のメール、対応履歴、利用可能なツール、返金規程を入力として渡します。LLMは内容を読み、例えば次のように処理を進めることを決定して、文字列として指示文に相当する文章を返すでしょう。
* 注文情報と請求履歴を取得するツールを選ぶ
* 取得した結果を読み、二重請求かどうかを判断する
* 返金規程を確認し、返金または承認依頼のツールを選ぶ
* 実行結果を踏まえて返信文を作成する
上の例では、LLMが状況に応じて次のツールや処理の順序を選んでいます。開発者が予めツールを接続し、権限や承認条件を設定し、その範囲でLLMが判断しています。
Jev+非AIエージェントの場合
対してJevは、与えられた状態に対して、定義済みの質問への選択結果や確率を返します。
まず、事前に「問い合わせの種類」の選択肢を定義しておきます。その上で「返金要求があるか」「再問い合わせか」という質問を定義しておきます。
この状態で先ほどのメールを評価するリクエストを送信した時、Jevでは以下のような結果が返ることを期待します。
以下のレスポンスはJevの考え方の理解を容易にするため、公式ドキュメントを参考にして、便宜上、模式化して説明するものです。
{
"問い合わせの種類": {
"選択結果": "二重請求",
"確率": {
"二重請求": 0.98,
"配送": 0.01,
"その他": 0.01
}
},
"返金要求がある確率": 0.99,
"再問い合わせである確率": 0.97
}
一見、従来のLLMでも出来ることを再発明しているように見えますが、このようなレスポンスを返すJevに期待する役割は「処理のルーティング役」でしかありません。Jevから返される結果は静的な数値で表されており、プログラムはこの数値を評価し、最も高い数値の処理をただ実行すれば良いのです。
当然ながら、Jevが返す数値は毎回変わります。どんな値が返ろうとも、プログラムは返された値を評価し、従来の比較演算を行って、呼び出すツールを決定するだけです。
従来のAIエージェントではLLMが呼び出すツールを決めていますが、その判断ロジックは非常にブラックボックスです。Jevではレスポンスこそ確率で決まりますが、判断ロジックはプログラムコードで明快に定義できます。
ただし、LLMにも確率を含む同じ形式で出力させることはできるため、生成できる情報だけを見れば、両者に決定的な違いはありません。
Jevが主張している従来のLLMとの違いは、モデルがこのような分類・確率の出力に特化して学習・設計されており、高速・低コストで実行できるという点になります。モデルが分類した結果に従って処理するだけなら、プログラムはJevのモデル呼び出しをして、その結果に基づいて条件分岐が出来れば良いので、Amazon Bedrock AgentcoreのようなAIエージェント基盤は不要になります。
「LLM+AIエージェント」vs「Jev+非AIエージェント」
Jevが従来の技術を置き換えるかのような説明をしてきましたが、従来のLLMと組み合わせたAIエージェントが勝る場面は当然あり、その違いは以下の表で示されるように定義できます。
| 観点 | Jevを組み込んだ業務アプリケーション | LLMを中心としたAIエージェント |
|---|---|---|
| AIに任せること | 分類、条件の該当判定、スコアリング | 状況の解釈、次の行動やツールの選択 |
| プログラムで定義すること | 判定結果に対応する処理と、その実行条件・順序 | 利用可能なツール、権限、承認条件、実行上の制約 |
| 次の処理の決め方 | AIの判定結果を受け、コードに記述した条件分岐で決める | 指示、会話履歴、ツールの実行結果を基にLLMが選ぶ |
| 顧客対応の例 | 返金要求と判定されたら、定義済みの請求確認・承認フローへ進む | 状況を見て、請求確認、追加質問、担当者への引き継ぎなどを選ぶ |
Jevを組み込むアプリケーションでは、AIが入力内容を分類・評価し、その結果に応じてプログラムが事前定義された処理を実行します。アプリケーションコード側では、エージェンティックな処理がありません。
LLMを中心としたAIエージェントでは、与えられた権限と制約の範囲で、AIがコンテキストに応じて次に使うツールや処理順序を選択します。
分かりやすく説明すれば、処理の進め方を決める責任をプログラムとAIのどちらに持たせるかの違いです。
まとめ
Jevは、入力の意味を読み取り、分類や条件判定の結果を確率付きで返すAIモデルです。業務に組み込むことを考える際には、プログラムで実行する処理が明確になっていることが重要となります。顧客対応であれば、問い合わせの内容や返金要求の有無をJevが判定(確率として出力)するため、プログラムコード内に判定ロジックを持ち、さらに請求確認や承認の手続きといった処理を事前定義しておく必要があります。
一方、LLMを中心としたAIエージェントでは、会話履歴やツールの実行結果を踏まえ、次に何を確認し、どのツールを使うかをAIに委ねられます。非常に柔軟ではありますが、同じ処理を実行するにも、毎回の思考時間やコンテキストの消費量が異なり、コストに影響することがあるでしょう。
Jevを使うことで、繰り返し発生する判断と処理を、必要な品質を保ちながら、アプリケーション側で低遅延・低コストに実行することが期待できます。AIに数値を出力させれば、あとは決まり切った処理さえ実行すれば良いのです。
この記事で紹介したように「LLM+AIエージェント」と「Jev+非AIエージェント」で比較すると、分かりやすく理解できます。それぞれの特徴を知って、使い分けていくことが大切です。