はじめに

新しいAIの発表を見て「これ、あの処理に使えるのでは？」と手が止まることがあります。
TypeSafe AIの「Jev」は、まさにそんな技術でした。

「次にどのツールを呼ぶか」「検索を続けるか」。
LLMに任せていた判断の一部を切り出せたら、面白いものが作れそうです。

TypeSafe AIが2026年9月15日に発表したJevは、
ソフトウェア内部での「判断」に特化したAIモデルです。

開発を率いるDiogo Almeida氏は、OpenAIでChatGPTの基盤となった研究にも携わっています。

私が試してみたいのは、Jevを判断役として組み込み、その評価を使ってプログラムがLLMやツールの次の処理を選ぶ構成です。
DifyやAIエージェントの中にある、次のような判断を切り出せないかと考えています。

次にどのツールを呼び出すべきか
必要な情報はそろっているか
このまま処理を続けてよいのか

こうした細かな判断の待ち時間が短くなれば、AIシステムの動き方も変わりそうです。
正直なところ、いち開発者として触ってみたくてたまりません。
利用案内はTypeSafe AIの公式サイトで確認できます。

この記事では、公式資料をもとにJevの仕組みとLLMとの違い、DifyやAIエージェントへ組み込む設計案を整理します。

この記事は、公式資料を読んで「これを作りたい！」と思ったことを書く、未検証の構想・ポエムです。
Jevの独自実測やDify連携の動作検証は行っていません。製品仕様として確認できたことと、私が試したい使い方を分けて書いています。

ゲームの行動選択で、Jevの入出力を考える

たとえば、RPGで目の前に敵が現れた場面を想像してみます。

味方のレベルや残りHP、装備、手持ちの道具。
対する敵の攻撃力や弱点。
そうした状況を渡し、AIに「次に取るべき合理的な行動は何か」を判断してもらいます。

選択肢は「攻撃」「道具の使用」「逃走」「防御」の4つです。

行動	モデルが「適切な選択肢」と評価した確率
攻撃する	80％
道具を使う	10％
逃げる	5％
防御する	5％

※説明用の架空の数値です。Jevの実測結果ではありません。

ここでいう「攻撃80％」は、攻撃すれば80％の確率で勝てる、という意味ではなく
渡した状況と判断基準のもとで、モデルが攻撃を適切な選択肢と評価した確率です。

プログラム側で「最も確率が高い行動を選ぶ」と決めておけば、この結果を受け取って攻撃を実行できます。
80％の頻度で攻撃をランダムに選ぶ、という使い方とは異なります。

状況を渡す → 選択肢ごとの確率が返る → プログラムが次の行動を実行する

この流れを図にすると、次のようになります。

※図はAIで生成した説明用のイメージです。Image2.5の性能は目を見張るものがありますね。

自分のHPや敵の状態が変わったら、更新した情報でもう一度評価する。
この「判断と実行の往復」を細かく回す使い方に極めてワクワクしています。

Jevには、用意された候補から選ぶ Choice という質問形式があります。
最も高い確率を付けた選択肢と、候補全体の確率分布が返る形式で、選択肢ごとに判断基準も指定できます。

「何をもって合理的とするか」をこちらで設計できる点も面白いところです。
生存を優先するのか、最短ターンでの撃破を狙うのか。
同じ状況でも、目的によって望ましい行動は変わります。

「道具は温存してほしい」と指示したら、選び方はどう変わるのか。
「とにかく生き残ってほしい」ならどうか。

某ゲームにおける「いのちだいじに」「ガンガンいこうぜ」「バッチリがんばれ」なんかがわかりやすいですかね。
ここを考えるだけでも、もう作りたくなってきます。

LLMの構造化出力と何が違うのか

「選択肢から選ぶだけなら、従来のLLMでもできるのでは？」
と思われるかもしれません。

たしかにそのとおりです。
構造化出力のように、LLMの返答を決まった形式へ制限する仕組みもあります。
判断を得るために、必ず長い説明文を生成させる必要はありません。

Jevで注目したいのは、プログラムが直接使う判断と確率を返すことを前提にモデルを設計している点です。

TypeSafe AIはこのモデル群を「System One Models」と呼んでいます。
公式発表では、判断の不確かさを確率に適切に反映することを目指す学習方式「RLCD」と、出力を並列に求める仕組みを説明しています。

TypeSafeのAPIで使う基本の質問形式は、次の3種類です。

質問の形式	役割	質問の例
Choice	候補から選択する	次にどのツールを実行すべきか
Score	定めた段階・基準で評価する	この問い合わせはどの程度緊急か
Noul	ある命題が真である確率を返す	回答に必要な情報はそろっているか

同じ状況に対する複数の問いは、1回のリクエストにまとめて並列評価できます。
ただし各質問は独立に評価されるため、前の質問の答えを使って次を判断する処理とは区別します。

たとえば問い合わせを1件受け取った際に、担当部署、緊急度、情報不足の有無をまとめて尋ねる。
返ってきた結果を組み合わせて、プログラムが処理の行き先を決める構成が考えられます。

必要な判断を小さく切り出し、部品として組み合わせていく。
Jevを組み込むなら、まずはこうした単位で処理を分けてみたいです。

Difyの「条件分岐」に組み込んでみたい

まず試したいのが、Difyのようなローコードツールで作るワークフローです。

社内向けの問い合わせ対応なら、受け取った文章をもとに「社内FAQを検索する」「利用者へ追加質問する」「担当者に引き継ぐ」といった処理を選びます。

ここへJevを組み込むなら、次の流れを考えています。

問い合わせ → 状況と選択肢をJevに送信 → 返ってきた評価で条件分岐 → 後続の処理を実行

Difyには外部APIを呼び出すHTTP Requestノードがあり、TypeSafe AIもHTTP APIを公開しています。
状況と選択肢を送信し、応答から必要な値を取り出して条件分岐へ渡す構成が考えられます。

ここで紹介しているのは、公開仕様をもとにした設計案です。
実際の接続や動作は、これから確かめたいと思っています。

Jevが返した評価を使い、プログラムが「検索する」「追加質問を作る」といった処理を選ぶ。
LLMには、その分岐先で質問文や回答文の生成を任せるイメージです。

既存のワークフローの分岐を1つ差し替えたら、全体の応答時間はどのくらい変わるのか。
振り分けの正確さを保てるのか。

モデル単体の速さだけでなく、利用者が回答を受け取るまでを比べてみたいところです。

AIエージェントの「次、どうする？」にも使えそう

AIエージェントは、検索したあとにも判断を続けます。

キーワードを変えて再検索するのか。別のツールを使うのか。
人に確認を求めるのか。あるいは材料が集まったと判断して、回答の作成へ進むのか。

この「次、どうする？」を繰り返す部分にJevを組み込む使い方に
私はいちばん可能性を感じています。

Vercelも2026年9月16日、AI GatewayでのJev対応を発表し、ツール選択や、継続・再試行・停止の判断を利用例に挙げています。

一方で、複雑な計画や新しい手段の発想まですべて同じ形式に収まるとは考えていません。

だからこそ、エージェントの処理を見ながら「ここは選択肢が決まっている」「ここは新たに考える必要がある」と分けてみたい。
どの判断を任せると速くなり、どこには深い推論を残したほうがよいのか。
その境目を知ること自体が、次の開発に役立ちそうです。

公表された「193.6倍高速」という数字の受け止め方

TypeSafe AIは、自社のワークフロー評価で、LLMとの比較で193.6倍高速、444.6倍低コストだったと公表しています。
ただし、同社自身も実利用での改善幅としては大きい側の結果だと説明しています。

比較では、LLM側にも構造化された判断と確率を返させています。
また、判断の評価には他の高性能モデルの予測を参照しており、実際の業務での正答率を独立に保証するものではありません。

自分の用途でも同じ倍率になると受け取らず、どんな条件で得られた数字なのかを押さえておきたいところです。

速さとあわせて確かめたいのが、判断が割れたときの振る舞いです。

同じ「攻撃」が1位でも、攻撃80％と、攻撃35％・逃走34％では状況が違います。
後者なら、追加情報を集めたり、別の推論処理に渡したりする設計が考えられます。

Choice や Score には、確率分布から計算される confidence という値もあります。
評価が1つの候補に集中しているか、複数に分かれているかを、1つの数値にまとめたものです。

選択肢ごとの確率とは別の指標で、その判断が正しい確率をそのまま保証する数字でもありません。
自分のデータで結果を確かめ、どの値なら自動実行に進めるかを決める必要があります。

出力形式を守れることと、判断が業務上正しいことも別です。
選択肢の基準や、渡す情報によって結果は変わります。

まずは同じ入力をJevとLLMへ渡して、どこで判断が一致し、どこで分かれるのかを見たい。
さらに、あらかじめ人が確認した正解や評価基準と照らし合わせ、両方が同じ間違いをしていないかも確かめたいと思っています。

日本語の曖昧な問い合わせや、情報が足りない入力も混ぜて試してみたいです。

JevとLLMを、どこで使い分けるか

ここまでJevへの期待を書いてきましたが、LLM全体を置き換えるものだとは考えていません。
私が面白いと感じているのは、処理に合わせてモデルを使い分けられることです。

従来のLLMは、トークンという単位で文章などを順に生成します。
同じモデルや条件であれば、出力が長くなるほど生成に時間がかかります。

一方で、決められた候補に収まらない提案をしたり、相手に合わせて説明を変えたりできる。
この自由度は、自然言語を生成できるからこその強みです。

Jevは自由な文章生成を行わず、あらかじめ定めた形式で判断を返す設計です。
選択肢や評価基準を用意できる処理では高速化を期待できますが、新しい対応案を文章にしたり、利用者への説明を組み立てたりする役割は、LLMなどに任せることになります。

また、LLMには事実と異なる内容をもっともらしく生成する、ハルシネーションの問題があります。
ただし、Jevなら誤った判断がなくなる、という話でもありません。
用意した選択肢の範囲を守っていても、その状況に合わないものを選ぶ可能性はあります。

私が考えているのは、入力する状態・選択肢・判断基準を設計し、Jevを判断の部品として組み込む使い方です。
対話を重ねて仕事を頼むというより、決めておいた問いに対する評価を、プログラムから繰り返し取りにいきます。

たとえば、LLMがツールを使って検索した結果をJevへ渡し、「回答に必要な情報がそろっているか」を評価してもらう。
不足していれば、プログラムがLLMへ検索方針の見直しを依頼する。
十分なら回答の作成へ進める、という流れです。

Jevが評価する → プログラムが分岐する → LLMやツールが処理する → 結果を再びJevへ渡す

Jevが直接LLMを操作するのではなく、間にあるプログラムが評価と実行をつなぐイメージです。
この往復をどう組み立てるかに、私は可能性を感じています。

LLMでも同様の判断はできます。
そのうえで、選択肢や評価基準を定められる部分をJevへ任せたら、処理全体はどう変わるのか。
システムを設計する視点で試してみたいです。

モデルを選ぶだけでなく、評価が割れたときの戻り先も設計しておきたいところです。
追加情報を集めるのか、別の推論処理へ渡すのか、人に確認するのか。自動実行を続ける条件と止める条件は、プログラム側で決めます。

コードで実装する場合も、Difyでワークフローを組む場合も、入力・条件分岐・繰り返しとして整理する点は共通しています。

どの判断をJevへ任せ、どこでLLMの柔軟さを使うとよいのか。
とんでもないブレイクスルーの最中にいることを自覚して、楽しんでいきたいですね。

まずは、目の前の「1つの分岐」から

問い合わせの振り分け、検索を続けるかの判断、フォーム入力中の案内。
そして、状況に合わせて行動を変えるゲームのキャラクター。

Jevの仕組みを眺めていると、「あそこにも使えるかもしれない」と、実装のアイデアが次々に浮かびます。

まずは既存のシステムやDifyのワークフローから、判断を1つだけ切り出してみる。
同じ入力と基準で比較し、次の点を確かめたいと思っています。

人が確認した正解や評価基準に照らして、判断の質を保てるか
曖昧な入力や情報不足のときに、処理を保留・切り替えできるか
通信と後続処理を含めた所要時間や費用はどう変わるか

AIに任せられることが増えるたびに作りたいものも増えていく。
Jevは私にとってまさにそういう技術でした。

まずは1つ動かして、判断と実行の往復を確かめてみたいです。

※本記事は2026年9月18日時点の公開情報をもとにした考察です。用途例と図解には筆者の構想を含み、Jevの独自実測やDify連携の動作検証は行っていません。

参照元

TypeSafe AI公式ブログ「Introducing System One Models & Jev」： https://typesafe.ai/blog/introducing-system-one-models-and-jev
TypeSafe AI公式ドキュメント「Introduction」： https://docs.typesafe.ai/introduction
TypeSafe AI公式ドキュメント「Choice」： https://docs.typesafe.ai/primitives/choice
TypeSafe AI公式ドキュメント「Confidence」： https://docs.typesafe.ai/confidence
Dify公式ドキュメント「HTTP Request」： https://docs.dify.ai/en/cloud/use-dify/nodes/http-request
Vercel公式「TypeSafe AI’s Jev now available on AI Gateway」： https://vercel.com/changelog/typesafe-ai-jev-now-available-on-ai-gateway