LLMに喋らせてパースする必要なし？判断だけ返すAI「Jev」を試した

　ChatGPTの生みの親の1人であるDiogo Almeida氏が立ち上げたスタートアップTypeSafe AIは9月15日、新カテゴリのAIモデル「Jev」を発表した。「テキストを生成しないAIモデル」という触れ込みに興味津々。今回はこのJevについて調べてみたい。

テキストを生成せず型付きの決定だけを返すJevの仕組み

　普段触っているLLMは、当然ながら喋る(テキストを生成する)のが仕事だ。ところがJevは違う。TypeSafeいわく「System One Model」という新カテゴリの第1弾で、トークンを逐次生成する代わりに、あらかじめ定義された型に沿った「決定(decision)」だけを返してくる。

TypeSafe AI、ログイン後のホーム画面

　具体的には、アプリ側が持っている状態(state)と、あらかじめ用意した質問(questions)を渡すと、Yes/No確率・選択肢・スケール上のスコアを1つずつ返してくる、という仕組みだ。出力の型を先に決めておくので、そもそも「変な形式で返ってくる」ことがない=ハルシネーションしようがない、というのがウリになっている。

　性能面では、フロンティア級LLMに対し40～200倍高速、レイテンシは70ms～500ms、価格は入力0.042ドル(約6.6円、1ドル=約157円換算)/100万トークン、出力は無料！……という数字が並ぶ。しかもアカウントを作るだけで5ドル(約785円)チャージ。この単価ならこれだけで結構遊べる(笑)。ゲームやロボット、シミュレーションのような、リアルタイムループの中で高速に「判断」だけほしい用途を狙っているようだ。

　Jevが受け付ける質問タイプは3種類。

• Noul: Yes/No判定(確率で返る)
• Choice: 複数の選択肢から1つを選ぶ(各選択肢の確率つき)
• Score: スケール上のどこに位置するかを判定(各段階の確率つき)

　いずれも「文章で説明してもらう」のではなく、「型で定義された答えを1個もらう」という発想。分類/ルーティング/スコアリングのように、これまで無理やりLLMに喋らせて後処理でパースしていたようなタスクを、直接置き換えるのが目的だ。

　このパターンは意外と筆者的にはよくある話で、たとえば以前記事にした、Seedance 2.0のタイムライン付きプロンプトをLTX-2.3用プロンプトに変換するプログラムを作っているときも、状況保存(state)やバリデーションなどで、LLMへ情報を渡し、結果(判断)をJSONで戻すのが入っていた。これにJevを使えばより簡単にそして速くできるというわけだ。

　まず、どのような動きか？を知るため、公式ドキュメント記載のサンプルをそのままPlaygroundに入れてみた。

　3つの例ともstateは共通で、「Hi, I've been trying to connect my Stripe account for 3 days and the integration keeps failing. I'm losing sales. Please help ASAP.」(3日間Stripeアカウントとの連携を試しているが失敗し続けていて、売り上げに響いている。至急助けて)というサポートへの問い合わせ文一本。

　これに対して「緊急かどうか(Noul)」、「どの部署が対応すべきか(Choice)」、「どれくらい怒っているか(Score)」という3種類の質問をそれぞれ投げる……という構成になっている。

Noul(Yes/No)の例:

　問い合わせ文が「緊急かどうか」を判定させる。

PlaygroundでNoul(Yes/No)の例。結果はurgency 98%

{
"urgency": {
"type": "noul",
"instructions": "Does this message express urgency?"
}
}

　結果はurgency 98%と出た。

Choice(分岐先の判定)の例:

　同じ文面を、今度は「どの部署が対応すべきか」で振り分ける例。選択肢はbilling(支払い/サブスクリプション)、technical(不具合/連携トラブル)、sales(価格/アカウント)の3つ。

PlaygroundでChoice(分岐先の判定)の例。確率はtechnical 81%、billingが19%、salesが0%。確信度(confidence)は72%

{
"department": {
"type": "choice",
"instructions": "Which team should handle this",
"criteria": {
"billing": "Payment or subscription issues",
"technical": "Bugs or integration problems",
"sales": "Pricing or account questions"
}
}
}

　選ばれた選択肢は「technical」で、確率はtechnicalが81%、billingが19%、salesが0%。確信度(confidence)は72%。つまり「不具合/連携トラブル担当に回すべき」という判断そのものと、その根拠となる確率分布、どれくらい自信を持ってそう判断したかがまとめて数値で返ってくる。

Score(度合いの判定)の例:

　「どれくらい怒っているか」をスケールで判定させる。Calm(穏やか)、Frustrated(いら立っている)、Very angry(かなり怒っている)の3段階。

PlaygroundでScore(度合いの判定)の例。score: 1.05

{
"frustration": {
"type": "score",
"instructions": "How frustrated is the customer?",
"criteria": ["Calm", "Frustrated", "Very angry"]
}
}

　score: 1.05と、「穏やか(0)」～「かなり怒っている(2)」の3段階のうち「いら立っている(1)」寄りという値が返ってきた。

　上記では分かりやすいよう、3つの質問をバラバラに投げているが、1つにまとめて送ることも可能。つまり1つの問い合わせに対して、「緊急度」、「担当部署」、「怒りの度合い」が一式数値/ラベルとして手に入る。これは従来のLLMに全部自由文で書かせてパースする……というやり方に比べると、圧倒的に扱いやすい。

　もちろんPlaygroundではなくAPIでの利用も可能だ。Python SDK(pip install typesafe-sdk)も用意されている。

POST https://api.typesafe.ai/v1/systemone
Authorization: Bearer <API_KEY>
Content-Type: application/json

ローカルで動く“同じ発想”のlaya-mlxを試す

　いきなりのJev登場でAI界隈が盛り上がっている中、早速いろいろ「Jev互換」のモデルが出てきたので試すことに。state+questionsを渡すとchoice/score/noulが返ってくる、というJevのインターフェイスをそのまま真似たオープンウェイトモデルの「laya-mlx」をピックアップ。手持ちの「MacBook Pro 14」(M4 Max 128GB)で動かしてみる。本家Jevとの違いは以下の表の通り。

　中身のモデル(学習データやアーキテクチャ)が別物なのは当然なのだが、それ以外の設計や入力の渡し方、質問タイプの種類、出力の形はほぼ同等といっていい。

　laya-mlxはConvai Innovations製の意思決定モデルLayaをApple Silicon上でネイティブ推論できるようにしたMLX移植版で、Hugging Faceで重みが公開されており、ローカルのMacに落とせばそのまま動く。FP16でも614MB～804MBとサイズも小さく、気軽に試せるのもありがたい。

　では先の「緊急かどうか」の質問を、laya-mlxのサンプルの文面で投げてみる。今回はPythonを使用。

pip install laya-mlx
# Noul(緊急かどうか)
import laya_mlx as laya
agent = laya.load("aac6fef/laya-mlx")
result = agent.predict(
"Help! My payouts have been failing for 3 days.",
{
"is_urgent": {
"type": "noul",
"instructions": "Does this convey urgency?",
}
},
)
print(result["answers"]["is_urgent"])

　実行結果:

{'type': 'noul', 'confidence': 0.7411, 'action': {'act_probability': 1.0}, 'noul': 0.7411}

　Jevではnoul: 0.98だったがlaya-mlxは0.7411と、どちらも「緊急寄り」という判断は一致しつつ、確信の強さには差が出た。いずれにしても動作はOK。ローカルで動くならいろいろ遊べそうだ。

型付き決定でSnakeを動かす

　laya-mlxにはlaya-snakeというデモが用意されている。

　内容は、蛇を上下左右に動かして餌を食べていくゲームで、食べるたびに体がどんどん伸びていく。ルールは「壁にぶつからない」、「自分自身の伸びた体にぶつからない」の2つ。ぶつかったらゲームオーバーとなる。

　laya-snakeのデモでは、この「次にどっちへ進むか」の判断(choice)と、「行き止まりに向かってないか」、「餌にまだ届くか」の判定(noul ×2)を、laya-mlxが毎手リアルタイムで返し続けることで自動プレイする。

　これはSnake専用に学習したAIではなく、あくまで、choice/noulという型付き決定を、1手ごとにリアルタイムで叩き続けて実際のゲームを動かすというものだ。

pip install 'laya-mlx[demo]'
hf download aac6fef/laya-multilingual-mlx
laya-snake

　具体的には毎手、以下の3問をAgent.predictにまとめて投げている。

• choice: 上下左右のうち安全な方向の中でどれを選ぶか
• noul: 今、行き止まりリスクがあるか
• noul: 今、餌に到達可能か

　盤面の状態は事前にプランナーが「安全な方向」、「進行度」などの特徴量に変換してからモデルに渡しており、モデルは生の盤面ピクセルを直接見ているわけではない。返ってきたchoiceの確率分布のうち、安全に動ける手の中で最も確率が高いものを実行し、万一モデルの一番手が危険な手だった場合は安全機構(サイクルシールド)が介入する仕組みだ。

　つまり、このデモの目的は、Snakeを上手くプレイすること自体ではなく、型付き決定モデルを実際のリアルタイムループに組み込んだときに、本当に毎フレーム安定して動くかを、目で見て分かる形で示すことにあるようだ。

　画面には推論時間や1秒あたりの決定回数も表示され、モデルがちゃんとリアルタイムで判断し続けていることを可視化している。ゲームやロボット、シミュレーションのループ内で使う、というJevの想定用途とも重なる部分だ。

自作リアルタイム性別判定ライブデモ

　laya-snakeは動いているところを見せるデモとしてはよくできているものの、あくまでSnakeというゲーム内での判断。そこで、もう少し実務寄りの題材で、しかも本当に速いのか？が数字ではなくパッと見て分かるものを自分で作ることにした。

　使ったのはHugging Faceにある「DataPilot/AItuber-Personas-Japan」という、仮想AITuberのペルソナ設計書が195件入ったデータセット。

　実はこのデータ、性別を示す構造化フィールドを持っておらず、以前別のプログラムでこのデータから“任意に男女1組を選ぶ”処理にAIが苦労していた、といういわく付きの題材だったりする。ペルソナデータを調べ、choice(男性/女性/不明)で判定させる。日本語のペルソナを扱うので、モデルは英語版ではなく多言語チェックポイントのaac6fef/laya-multilingual-mlx(322M)を使用。

　やっていることは単純で、195件分の白いBOXを並べておき、開始ボタンを押すと1件ずつ判定が進むたびにBOXが男性=青、女性=赤、不明=白のまま、と色分けされていく。右側には何件目/195件のカウンターと、いま処理中のペルソナ本文の冒頭が流れる。判定が本当に1件ずつリアルタイムで進んでいるのが、数字の羅列を読むよりも一目で分かる作りだ。

　同じ題材を、比較用にQwen3.8-27B+LM Studioにも解かせる別プログラムを用意した。こちらはchoiceの代わりに“JSON形式でgenderを返して”とプロンプトで指示し、返ってきたテキストをパースする方式だ。

　なおQwen3.8-27Bを動かしているのはGeForce RTX 4090(48GB改)なので、非力な環境で遅いわけではない。実測ではプロンプト処理(prefill)が約2,000tok/s、生成(decode)が約56tok/sと、環境としては速い方だろう。加えて4並列処理をした状態なのだが、同じ195件を処理するのにlaya-mlxの実に50倍以上の時間がかかっている。

　ただし、これはあくまでも322Mの専用モデルと27Bの汎用LLMの比較であって、モデルの立ち位置自体が違う勝負だという点は差し引いて見る必要がある。

　1件あたりのconcept(ペルソナ設計書の本文)が2,000～3,000トークン近いプロンプトになるため、いくらdecode自体は速くてもprefillの負荷が積み重なる格好だ。しかもまれにJSONの形式が崩れてパースに失敗するケースも実際に出た(型で縛られていないと起きる失敗モード)。

　判定結果の傾向を見ると、laya-mlxは自信がない場合は確率が割れて「不明が多めに出るのに対し、LLM版は男性/女性のどちらかに強気に断定しがち。

　いずれにしても、筆者がこれまで実際に試したことのあるデータで、Jevと同じ発想の型付き決定が使えた意味は大きい。今後積極的に取り入れたい。

　余談になるが、現状のJevはテキスト専用で、画像や映像を直接入力することはできない。ただ、これがVision対応になれば応用範囲は一気に広がるはず。

　たとえば監視カメラの映像をstateとして渡し、「人がいるか」、「性別は」といった質問を型付きで投げれば、テキスト変換を挟まず、今回のペルソナ判定と同じような速さと精度感で判定できるようになるだろう。

　実際、laya-mlx系のエコシステムにはLaya Visionという、画像エンコーダ(SmolVLM-256M)を組み込んでtyped decisionを画像入力にも対応させた派生プロジェクトが既に存在しており、方向性としては決して突飛な話ではない。

　以上、簡単ではあるがJevとlaya-mlxによる喋らないAIを試用した。これまで自作プログラムでLLMに判断をさせるケースは結構あったが、これを使えばもっとシンプルに実装でき、しかも速く動作するので2度美味しい。早速これまで作ったプログラムの手直しから始めてみたい。まず開発中のmicro-drama生成システムだろうか？(笑)。

　今回使用したプログラム(laya-mlx/Noul、性別判定ライブデモ)はここに公開しているので興味のある人は見ていただければと思う。