判定専用モデル Jev が LLM の代わりに使える処理と使えない処理

2026/9/19更新: 2026/10/2Web開発者向け

LLM に「この問い合わせは配送か返品か」「この文は急いでいるか」のような分類や判定をさせている処理は、文章を書かない判定専用のモデルに置き換えられるのか。Jev（TypeSafe AI が 2026年9月に公開したモデル）に、『デプロイしたのに本番が古いまま。3時間溶けた。』という一文を渡し、『書き手は苛立っているか』と聞いてみました。返ってきたのは 0.98 という数字だけで、理由も根拠の引用もありません。

紹介記事の多くは『学習データが要らない』『LLM より数百倍速くて安い』を先に出すので、プロンプトを投げればいい感じに考えて答えてくれる安い LLM、と受け取られがちです。実際に触ると、Jev は文章を生成せず、こちらが宣言した選択肢に対する確率を返すだけの、まったく別の種類のモデルでした。手持ちの LLM 呼び出しのどれを置き換えられるかを洗い出し、日本語で実測した結果を書きます。

Jev は確率しか返さない、理由も推論も付かない

Jev が返すのは、こちらが宣言した選択肢に対する確率だけです。型は 3つあります。

noul: yes／no で答える問いに、yes である確率を返す
choice: 宣言した選択肢から 1つを選び、選択肢ごとの確率も返す
score: 宣言した段階（3段階、5段階など）のうち 1つを選び、段階ごとの確率も返す

返ってくるのは数字だけで、理由も根拠の引用も付きません。

ChatGPT や Claude のような LLM は、直前までの出力を条件に次の 1語を予測する処理を繰り返して文章を組み立てます（自己回帰）。考えを書き出しながら答えを作る、いわば熟考型です。Jev はこの逆で、渡した文章を一度読んだら、複数の問いを 1回のリクエストで並列に答えます。公式の Quick start も、1回のリクエストの問いはすべて同じ入力を見て、並列かつ独立に評価されると説明しています。

TypeSafe はこのモデルを『System One』（心理学でいう、速い直感の System 1 になぞらえた呼び方）と呼びます。じっくり考える System 2 の処理を持たず、一度読んで直感で答える System 1 の処理だけをするモデル、という意味です。

触ってみると、『データを用意せずにいい感じに推論してくれる』という理解は半分だけ正しいと感じました。学習データが要らないのは本当で、問いと選択肢さえ書けばすぐに答えます。その代わりに問いと選択肢を設計する手間が要ります。宣言していない答えは絶対に出ません（捏造はしない）が、宣言した選択肢の中で選び間違えることはあります。確率が現実の判定と合っているかは、自分の人手の判定と並べて確かめるまで分かりません。

入力もテキストに絞られています。公式はText only. String, JSON object, or array of text values. No image, audio, or video input.と明記しており、入力に渡せるのは 32,000 トークンまでです（質問文を含めた分）。

日本語については、公式がEnglish is the primary training language and where accuracy is currently best. Other languages, including CJK scripts, are handled but not equally wellと書いています。

使うまでに要るのは、アカウントとキーと 1つのエンドポイント

console.typesafe.ai でアカウントを作り、API キーを発行します。2026年9月19日時点、カード登録は求められませんでした。

エンドポイントは 1つだけです。ホスト api.typesafe.ai の /v1/systemone に POST し、ヘッダー Authorization: Bearer <APIキー> を付けて送ります。body は state（判定させたい文章を渡すフィールド）、model（jev-latest を指定）、questions（問いの宣言）の 3つです。questions の各項目は type（noul／choice／score）と instructions（問いの文）を持ち、choice と score はさらに criteria（選択肢や段階の説明）を持ちます。

実際に叩いた例です。問い合わせ文の窓口振り分けと、急いでいるかどうかの判定を 1回のリクエストにまとめています。

curl -X POST https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "state": "配送状況を教えてください。今日中に届くか知りたいです。",
    "model": "jev-latest",
    "questions": {
      "department": {
        "type": "choice",
        "instructions": "この問い合わせを担当する窓口はどれか",
        "criteria": {
          "shipping": "配送状況や到着日についての問い合わせ",
          "returns": "返品や交換についての問い合わせ",
          "billing": "支払いや請求についての問い合わせ",
          "account": "アカウントやログインについての問い合わせ"
        }
      },
      "is_urgent": {
        "type": "noul",
        "instructions": "書き手が急いでいるかどうか"
      }
    }
  }'

返ってきたのは次の JSON です。

{
  "model": "jev-1.13.0",
  "answers": {
    "department": {
      "type": "choice",
      "choice": "shipping",
      "confidence": 1.0,
      "probabilities": { "shipping": 1.0, "account": 0.0, "billing": 0.0, "returns": 0.0 }
    },
    "is_urgent": { "type": "noul", "noul": 0.79 }
  },
  "usage": { "input_tokens": 455, "output_tokens": 65 }
}

usage.input_tokens がリクエストごとに返るので、コストの見当がその場で付きます。料金は公式の Models のページに、入力 100万トークンあたり 0.042 ドル、出力は無料と書かれています。

TypeScript（fetch のみ）でも書けます。score の型はこうなります。

const res = await fetch("https://api.typesafe.ai/v1/systemone", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.TYPESAFE_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    state: "パスワードを忘れてログインできません。",
    model: "jev-latest",
    questions: {
      urgency: {
        type: "score",
        instructions: "書き手がどれだけ急いでいるか",
        criteria: ["急いでいない", "やや急いでいる", "すぐ対応してほしい"],
      },
    },
  }),
});
const body = await res.json();

返ってきた score は 1.17、確信度は 0.47 でした。段階 0〜2 のうち、1（やや急いでいる）付近に確率 0.65 が集まった状態です。

判定と文章生成を混ぜていた LLM 呼び出しが、置き換えの候補になった

個人で運用しているサイトや自動化の仕組みから、LLM や規則で判定している処理を一通り洗い出すと、置き換えられる処理の形は 1つでした。既存の LLM 呼び出しの多くは、判定と文章生成を 1回に混ぜて出す作りです。Jev は文章を書けないので、使うには判定の部分を切り出す設計に変える必要があります。

判定なのに生成用の LLM を使っている処理は、次の 3つの形でした（括弧内は私の手元の例）。

分類の項目と説明文を 1回の JSON でまとめて出させる呼び出し。分類の項目だけを切り出せば、そのまま Jev の型で聞ける（技術ニュースの収集で、記事ごとに 7択の分類・優先度・即時通知の要否など 5項目と説明文を出していた）
1件ずつ yes／no を LLM に聞いている呼び出し。yes／no の問いにそのまま置き換えられる（サイト診断で、競合候補が同業か・同地域か・自社サイトかの 3問）
残すか切るか、どの雰囲気かのような少数の選択肢を大きな LLM に選ばせている呼び出し（動画の自動編集で、発話の区間ごとの残す／切ると、BGM の雰囲気の 5択）

規則だけの分類や、判定をしていない所も 3つ、足す候補にしました。

規則が 1つだけの判定。問い合わせフォームのスパム判定は、今は honeypot（人には見えない入力欄に値が入ったら弾く仕掛け）だけ
キーワード一致の分類。ページの種類の分類で、『工事業』の『事業』に部分一致してブログ記事を事業紹介のページと誤判定したことがある
組み合わせが多すぎて人が選んでいる判定。記事同士の内部リンクの関連度は、記事の組が記事数の 2乗で増えるのに、今は本文を読んで選んでいる

記事のカテゴリとタグ付けも候補にしました。私のサイトでは今、記事を書く AI エージェントが 1本ずつ付けています。1本だけならこのついで付けが一番安く、Jev が役に立つのは既存記事をまとめて付け直すときです。カテゴリは宣言した候補から 1つ選ぶ choice、タグは語彙が決まっていれば「タグ 1つにつき yes／no」を 1回の呼び出しで並列に聞けるので、タグの数だけ呼び出しを分ける必要がありません。ただし語彙に無い新しいタグを思いつくことはできません。

関連記事の表示も、今はタグが重なるかどうかだけで決めていますが、関連度を事前に計算して持たせれば、表示のたびに呼ばずに中身で選べます。タイトル候補の生成は Jev では作れないので対象外です。

使わないと決めた処理も 3つあります。

監視の警報を出すかどうかの判定。警報の経路にはモデルの推論を入れない方針にしている
同名の別会社を取り違えないための社名の照合。ここは意図的に LLM を使っていない
画像を見て判定する処理（開発中のサービスで、カメラ映像を見てその場の出来事に反応する処理）

一番使いたかったのは 3つ目です。『何か起きたか』『何が起きたか』を即答する問いは Jev の型でそのまま聞けますが、入力はテキストだけです。公式は、画像をテキストか構造化データに前処理してから state に渡すよう書いています。画像を読めるモデルで一度文字にしてから Jev に聞く 2段構成は組めますが、画像モデルの呼び出しは残ったまま Jev の分の待ち時間が足されるだけで、今より速くも安くもなりません。公式が画像に対応する予定は 2026年9月19日時点で公開されていないので、回避策は作らず、公式の対応を待つことにしました。

この中でいちばん先に試したのは、好みの判定です。私は X に 4 コマ漫画を投稿していて、ネタを一文にした素材を LLM がふるいにかけ、残った物を私が見て出すかどうかを決めています。この LLM による選別を Jev に替えられるかを試しました。理由は、既存の判定が甘かったこと（ある回の素材 12本すべてに既存の判定は『通す』を出したが、私自身が通したのは 3本だった）と、私自身の判定という正解データが手元にあったことの 2つです。結果は次の節のとおり、好みの判定は Jev でも解けませんでした。残っている候補は、本文から読める判定で量の多い、記事同士の内部リンクの関連度です。

日本語でも実測すると、原因の分類は当たり、好みの判定は当たらなかった

自分のサイトの記事Cloudflare にデプロイしたのに反映されないのはブラウザのキャッシュ（本文約 5,000 トークン、淡々とした調子で原因を追っている記事）を state に渡し、複数の問いを 1回のリクエストで聞きました。

『書き手は苛立っているか』（noul）: 日本語の問いで 0.09、英語の問いで 0.15。記事は実際に淡々としている
最終的な原因はどれか（choice、エッジ/ブラウザ/ビルド/DNS の 4択）: 両言語ともブラウザに 1.00
疑った原因が外れていたかどうか（noul）: 両言語とも 0.96
感情の強さ（score、3段階）: 『淡々』に 0.73（日本語）/0.75（英語）

応答は 798ms（日本語）、649ms（英語）でした。原因の分類と、疑いが外れていたかの判定は日英でほぼ同じ確率が返り、感情の強さも近い値でした。

対比として、冒頭の作り文『デプロイしたのに本番が古いまま。3時間溶けた。』に同じ問い（苛立っているか）を聞くと 0.98 でした。本文のどこにも『苛立ち』とは書いておらず、Jev は言い回しから苛立ちを読んでいます。ただし同じ文と同じ問いを時間を置いて送り直すと 0.92 で、確率は呼ぶたびに少し変わります。

問い合わせを模した文 8件（急ぎのものが 4件、急ぎでないものが 4件）を日本語と英訳の両方で用意し、同じ問いを聞いた結果です。

窓口（配送/返品/支払い/アカウントの 4択）: 日本語 8/8、英語 8/8 とも正解で、確率はすべて 1.00
急いでいるか（noul）: 急ぎの 4件は日本語 0.83〜0.98・英語 0.82〜0.97、急ぎでない 4件は日本語 0.05〜0.53・英語 0.03〜0.48
両言語で最も迷ったのは『パスワードを忘れてログインできません』で、日本語 0.53・英語 0.48
日本語は急ぎでない文をやや急ぎ寄りに見ており、領収書の再発行は日本語 0.26・英語 0.08、メールアドレス変更は日本語 0.26・英語 0.12

応答の中央値は約 555ms で、公式が示す 70〜500ms より長めでした。私の環境はプロキシを経由しているので、その分も含んだ値です。

好みの判定はここまでのようには当たりませんでした。4 コマ漫画の素材 32件（実際に私が通したのは 2件）に、『うちにもあると思うか』『笑うかぎょっとするか』など 4つの問いを聞きました。Jev も、同じ問いを解かせた Claude Sonnet も、私が通した 2件を見分けられず、結果は偶然と同程度でした。通した例が 2件しかないのでモデルの優劣は言えませんが、一文から特定の人の好みを当てる問いは、判定させるモデルを替えても解けませんでした。素材 32件の中身は載せません。

本文から読める判定は分岐の条件に使え、好みの判定は人がする

実測から決めた使い分けは次のとおりです。

振り分け、急ぎ度、原因の分類のように、本文を読めば人間でも同じ結論に至る判定は、コードの分岐の条件に使える
好みやセンスのように、同じ文章を読んでも人によって評価が割れる判定は、Jev に聞いても人手の代わりにならない
どちらに当たるかは事前にはわからないので、確率を信じる前に、自分の人手の判定と並べた表で確かめる必要がある

内部リンクの関連度のように本文から読める判定で量が多い処理を、実際にコードの分岐の条件に置き換えられるかは、まだ確かめていません。

参考リンク

TypeSafe AI, Introduction / Quickstart — エンドポイントの仕様、並列評価の説明
TypeSafe AI, Models — 入力形式、トークン上限、言語サポート、料金