Jev が LLM の代わりに使えた処理と任せられなかった処理

2026/9/19Web開発者向け

『デプロイしたのに本番が古いまま。3時間溶けた。』という一文を Jev（TypeSafe AI が 2026年9月に公開したモデル）に渡し、『書き手は苛立っているか』と聞いてみました。返ってきたのは 0.98 という数字だけで、理由も根拠の引用もありません。紹介記事の多くは『学習データが要らない』『LLM より数百倍速くて安い』を先に出すので、プロンプトを投げればいい感じに考えて答えてくれる安い LLM、と受け取られがちです。実際に触ると、Jev は文章を生成せず、こちらが宣言した選択肢に対する確率を返すだけの、まったく別の種類のモデルでした。

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 呼び出しが、置き換えの候補になった

手持ちのシステムを一通り洗い出すと、置き換えられる処理の形は 1つでした。既存の LLM 呼び出しの多くは、判定と文章生成を 1回に混ぜて出す作りです。Jev は文章を書けないので、使うには判定の部分を切り出す設計に変える必要があります。

判定なのに生成用の LLM を使っている処理が 3つ見つかりました。

技術ニュースの収集基盤。小型 LLM が記事ごとに層（7択）・優先度（高中低）・種別・即時通知の要否・対応（すぐやる/計画/無視）と説明文を、1回の JSON で出す構成。分類の 5項目はそのまま Jev の型に乗る
サイト診断の道具。競合候補のサイトが同業か・同地域か・自社サイトかを小型 LLM で 1件ずつ判定する構成。yes／no の 3問にそのまま置き換えられる
動画の自動編集。発話の区間ごとに残す/切るを大きな LLM に判定させる構成。BGM の雰囲気の 5択も同様

規則だけか、何もしていない処理も 3つ、足す候補にしました。

問い合わせフォームのスパム判定。今は honeypot だけ
ページ型の分類。今はキーワード一致で、『工事業』の『事業』に部分一致してブログ記事を事業ページと誤判定した記録がある
記事同士の内部リンクの関連度。記事の組は記事数の 2乗で増えるのに、今は本文を読んで選んでいる

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

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

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

監視の警報の判定。警報の経路に推論を入れない方針
同名の他社を誤爆しないための照合。意図的に LLM を使っていない
開発中のサービスで、カメラ映像を見てその場の出来事に反応する処理

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

X に投稿する 4 コマ漫画がウケそうかどうかを判定する処理を、この中でいちばん先に試しました。理由は、既存の判定が甘かったこと（あるバッチの 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 でした。本文のどこにも『苛立ち』とは書いていません。言い回しから読んでいます。ただし同じ文と同じ問いを時間を置いて投げ直すと 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 より長めでした。私の環境はプロキシを経由しているので、その分も含んだ値です。

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

本文から読める判定はコードの分岐に置け、好みの判定は人に残す

実測から引ける線はこうです。

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

残っている検証は、内部リンクの関連度のように、本文から読める判定で量が多い所です。ここが実際にコードの分岐に置き換えられるかは、まだ確かめていません。

参考リンク

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