Jevは何ができるのか。判断に特化したモデルの使い道と、試して分かったクセ

Jevとは

提供しているのはTypeSafe AIです。公式の説明を見ると、文章やアプリの現在の状態を渡すと、こちらで用意した選択肢の中から適切なものを選んで返してくれるモデルのようです。

生成AIのように長い文章を返すのではなく、返すのは「選択」や「評価」のみ。公式では、候補から選ぶ Choice、段階を評価する Score、ある事柄が成り立っている確率を返す Noul の3つが用意されていました。

気になるところ

こうした分類タスク自体は、これまでも通常のLLMでプロンプトを工夫すれば実行できました。「〇〇だったら1と返して」などの制御です。
「欲しいのはテキストではなく、次の処理に使う判定結果だけ」という場面で、その判断部分をJevに切り出すとどうなるのか、少し気になるところです。

細かい判断を何回も挟むパイプラインだと、都度かかるレイテンシやAPIコストも無視できません。Jevでこのあたりの負荷を軽くできるなら、組み込みたい場所は色々思い浮かびます。

Jevの3つの機能はどのように使えそうか

候補から1つを選ぶのか、度合いを見たいのか、事実として成り立っているかを見たいのかで使い方が違いそうです。

まずはその違いを整理した上で、それぞれプロダクトの現場でどう使えそうか、考えてみたパターンを書き出してみます。

Choice — 用意した候補から、今の1つを選ぶ

Choiceが向いているのは、システムの「次の動き」が、あらかじめ決まった選択肢のどれかで分岐するケースです。担当部署、検索の参照先、キャラクターのモーション、呼び出すツール、記憶の保存先など。返ってきたラベルを使って、コード側で処理を振り分ける形です。

生成AIのように気の利いた返信文を作る必要はなく、「どれに該当するか」だけが分かればいい。候補はこちら側で完全に握っておき、AIに勝手な名前を生成させない。この割り切りができる用途に向いています。

ざっと考えてみた使い道は、このあたりです。

• 受信トレイの仕分け：営業メール・フィッシング・販促メール・案件に関するメール・プライベート・迷惑メールといったフォルダ分け。すぐに返すべきか少しあとでもいいか承認が必要か、次に人間がどう動くかの判断などを決める処理。

• 問い合わせの一次ルーティング：届いた文面が返品・請求・サポートのどれなのかを判定し、カテゴリを付与して適切な部署（CS、経理、開発など）へルーティングする使い方。

• 自然文から検索クエリへの変換：たとえばECサイトで「1万円以下で、ノイズキャンセリング付きの黒いワイヤレスイヤホンが欲しい」と入力された場合。カテゴリ＝イヤホン、価格上限＝1万円、機能＝ノイズキャンセリング、カラー＝黒、といった形で検索条件に落とし込む使い方です。Amazonのように検索対象や絞り込み条件が多いサービスでも、ユーザーの自然な言い方から既存のカテゴリや属性マスタへ対応付けし、そのまま商品検索に使える形へ変換できそうです。

• 表記揺れの吸収とマスタへの名寄せ：同じ対象を指しているのに表記がバラバラなケース。会社名なら正式社名と英語表記、ECなら正式名称と略称などです。候補マスタを渡しておき、手元のデータのどれと一致するか。

• 非構造化テキスト（PDF等）の構造化：取り出したテキストが見出しなのか、本文なのか、前の段落の続きなのかをブロック単位で判定していく処理。

• エージェントやアプリの挙動制御：社内RAGで「就業規則」と「製品マニュアル」のどちらを参照しにいくかの判断や、LLMがツールを使う前の「そもそも今、検索が必要か？」の判定。「こんにちは」に検索は不要ですが、「明日の天気は？」ならツールを呼び出す、といった分岐。

• キャラクターのリアクション選定：返答を生成している間の「相づち」や「困り顔」、返答の内容に合わせた笑顔などを、用意済みの表情や動き、相づちなどから選ぶ処理。返答待ちの間ずっと無反応だと、少し寂しく感じられますが、先にうなずきや表情の変化を挟むことで、文章が返ってくるまでの間にも「話を聞いている」様子を見せられそうです。

• ゲーム内NPCの行動選択：体力や所持アイテム、プレイヤーの指示などを判断材料にして、「素材を集める」「追従する」「休む」「助ける」といった実行可能な行動からChoiceで1つ選ぶ使い方です。ゲーム内部の状態を直接渡す構成なら、画面の画像を見せなくても状況を判断させられます。

• ステート管理・記憶の分類：会話から切り出したメモを、「本人の好み」「確定した予定」「他人の情報」「一時的なステータス」のどこに保存するか選ぶ役。診断やヒアリングフォームで、既に入力された内容から「次に聞くべき設問」を選ぶ用途にも使えそうです。

Choiceは直感的に使いやすいですね。同時に成り立つ可能性がある条件を無理やり1つの選択肢に詰め込むと、選択肢の組み合わせが爆発してしまうため、そこだけ注意が必要そうです。そこで残りの2つが役に立ちそうです。

Score — 段階を見る

Scoreは、入力された内容の強さがどれくらいかを判断するのに使えそうです。クオリティ、感情の強さ、緊急度のように強さの程度を数値で把握したいケースです。選択肢のどれか1つに丸めるのではなく、度合いを落とさずに拾いたい場面ですね。

考えてみた用途は以下の通りです。

• 自由記述アンケートの多面評価：「便利だけど、初期設定でかなり躓いた」という声を、ポジティブ/ネガティブの2択に潰してしまうと、使いやすさへの評価と導線の分かりにくさが相殺されてしまいます。「利便性」「初期体験の分かりやすさ」といった観点ごとにJevを呼び出して段階でスコア化できれば、どこを直せばいいかが見えやすくなりそうです。

• テキストからの特徴量生成：「価格への納得感」「説明の明瞭さ」「継続利用の意欲」などを文章から数値として抽出し、ダッシュボードでの集計や、別の機械学習モデルへのインプットとして使う処理。

• 問い合わせのトリアージ：担当部署への振り分け自体はChoiceで行いつつ、「どれくらい困っているか」「急ぎの度合いはどの程度か」をScoreで並行して測る使い方。

• 検索結果のマッチ度ソート：条件による絞り込みはChoiceで処理した上で、残った候補を「希望のニュアンスにどれだけ近いか」で並び替える処理。条件には合っていても、雰囲気やニュアンスの近さは程度の問題なので、Scoreの方が合いそうです。

• UGC（投稿やレビュー）のモデレーション：規約違反かどうかをいきなり白黒つけるのではなく、「有用性」「不満の強さ」「違法性」などを段階で判定し、人間が優先して確認すべきものを前に寄せる使い方。

• キャラクター表現の抑揚づけ：どの表情を出すかはChoiceで決めつつ、反応の大きさをScoreで調整する使い方。軽く微笑むのか、満面の笑みになるのかといった度合いの調整にも使えそうです。

Noul — あることが成り立っているかを見る

Noulは、選択肢同士を比べるのではなく、「その要素が含まれているかどうか」を1つずつ判定したいときに使えそうです。同時に成り立ち得る条件をChoiceでまとめようとすると、「返金希望かつ急ぎ」「返金希望だが急ぎではない」のように組み合わせの設計が必要になりますが、Noulなら個別に判定できます。

また、「書かれていないこと」を勝手に補完させたくない場合にも使えそうです。金額に触れていない入力に対して、無理に金額条件を推測させる必要はありません。

考えてみた使い道は、このあたりです。

• 問い合わせの前提チェック：「返金の希望が含まれているか」「過去にやり取りがあると言っているか」「個人情報が書かれているか」など。これらは同時に成り立ち得るので、個別にNoulで判定し、その結果をルーティング用のChoiceに渡す前処理。

• 自由入力からの条件抽出判定：ECの商品検索などで、「価格に言及があるか」「色の指定があるか」「サイズや機能などの条件が含まれているか」をまずNoulで判定し、言及されている項目だけを次の検索条件の生成へ回す使い方です。

• 文字起こし・会話ログの不要語判定：相づちの「はい」を機械的に削除していいのかどうか。契約内容への同意としての「はい」なら、消すと文脈が壊れるので、「これは同意の意図を含んでいるか」を単体で判定する処理。

• パーソナルデータの抽出精度向上：「私は辛いものが苦手」と「友達は辛いものが苦手」は、主語が違いますし、「今日は辛いものを食べたくない」という発言も、普段から苦手だという意味とは限らないです。テキストからメモを切り出す際、「これはユーザー本人についての情報か」「一時的な状態についての話か」をNoulで個別に確認する使い方に使えそう。

• メッセージの要対応フラグ：メールやチャットで「返信を求めているか」「明確な期限が指定されているか」「約束事（コミットメント）が含まれているか」の検出。フォルダ分けとは別に、フラグを立てるために走らせる処理。

• RAGにおける検索結果の妥当性評価：ナレッジベースから拾ってきたチャンクが、「本当にユーザーの質問に対する回答を含んでいるか」の検証。検索先を選ぶのはChoice、拾ってきたテキストが使えるかどうかの判定はNoul。

返ってきた値を、次の処理の材料にする

これらの3つの機能は、単体で呼び出して終わるだけでなく、パイプラインとして繋ぎ合わせると、使える場面が一気に広がりますね。

診断アプリなら、複数のNoulやScoreで観点をバラバラに評価してから、ロジック側で合算して最終的なタイプ名を決定する。審査系なら、手前のNoulやScoreで「怪しい要素」を検知したものだけを後ろの大型LLMや人間の目視に回し、後ろに回す件数そのものを減らすなど。

どこから使えるか

2026年9月現在の情報では、TypeSafe AIの公式PlaygroundおよびAPIのほか、OpenRouter、Vercel AI Gatewayなどでも利用アナウンスが出ています。

利用料金や呼び出しの仕様はプロバイダごとに異なるため、用途に合わせて確認してみてください。今回の手元の検証では、開発環境への組み込みやすさからOpenRouter経由で動かしています。

試して分かったクセ

上の使い道から、店舗検索、キャラクターのリアクション、旅行タイプ診断の3つを小さく作ってみました。日本語のざっくりした希望から店舗の条件を選ぶ、発言に合わせてモーションを選ぶ、といった処理は素直に動きました。

引っかかったのは、LLMに分類させるときと同じ感覚で質問を書いたところです。

旅行タイプ診断は、次の旅行でしたいことを自由に書いてもらい、「のんびり」「グルメ」「観光」「アクティブ」の4タイプから結果を出す遊びの診断です。Choiceは候補ごとの確率も返してくれるので、1位と2位を組み合わせれば「食べ歩き観光派」のような結果が出せると考えていました。ところが「朝から名所を回って、夜は地元の居酒屋で名物を食べたい」と入れても、結果は観光0.89、グルメ0.11で、ほぼ「観光」一択。Choiceは候補同士を比べて一番合うものを選ぶので、2位が「2つ目の特徴」を表しているわけではありませんでした。

予算でも似たことが起きました。候補を「500円以内・1,000円以内・2,000円以内」にして「1,500円以内」と入力すると、「不明」を用意して「近い候補に寄せない」と書いておいても、「2,000円以内」が選ばれます。1,500円は2,000円以内に収まっているので、Jevにとっては「当てはまる」ようです。このまま検索すると、1,800円の店まで出てきてしまいます。

こうした答え方のクセは、知っていれば質問の書き方とアプリ側の組み方で避けられます。有料部分では、ここを中心に書いています。

ここから先の有料エリアでは、この3つの試作を動かして分かったことを、実装寄りにまとめています。例に出している答えや数字は、どれも実際にJevに送って返ってきたものです。

• 自分のプロダクトから「Jevに任せるべき判断」を切り出す設計の考え方

• 自由入力のテキストから検索条件を判定し、手元データを絞り込む実装例

• レスポンス待ちの間に挟む、キャラクターのモーション・リアクション選定ロジック

• 会話メモの自動分類や、複数要素を掛け合わせた診断ロジックへの応用パターン

• JevとLLMを組み合わせる際のコスト試算と、パイプライン設計の注意点

• ClaudeやCursorなどに実装を頼んだ後の、できあがったものの確かめ方

• Jevを使うときのコツ10個

ここまで読んでいただきありがとうございました！