Jev とは何か — ブログ57記事のタグ付けを任せたら、正誤が付かなかった

Jev（TypeSafe 社のモデル）は、文章を書かずに「はい」の確率や選択肢で答える判断モデルです。これに自分のブログ57記事のタグ付けを任せ、Claude Haiku 4.5 と答えが割れたところを私が判断したら、ほとんどが「どちらでも間違いではない」でした。タグ付けは、正誤のある分類問題ではありませんでした。

この記事は、3回に分けて Jev を測る連載の Part 1 です。前半で Jev が何を返すモデルかを整理し、後半で57記事の結果を書きます。割れたカテゴリの28件はすべて「どちらも妥当」、タグの10件も8件は好みの問題で、はっきり誤りと言えたのは2行だけでした。

Jev は何を返すモデルか

文章ではなく、型の決まった答えを返す

Jev は、答えの形（はい／いいえの確率、選択肢のどれか、など）を先に決めて質問すると、その形のまま答えを返します。ふつうの LLM との違いは、答えを文章で受け取って読み取り直す手間が要らないことです。

TypeSafe は、Jev を作った理由を LLM の使い方の食い違いから説明しています。

When you need a model to make a judgment that your code will consume, that creates a mismatch: you are coercing a text-generation system into outputting structured decisions, then parsing the results back into something your code can depend on.

（訳）コードが使う判断をモデルにさせようとすると、食い違いが生まれます。文章を生成する仕組みに構造化された判断を無理に出させ、その結果を、コードが頼れる形に読み取り直すことになるからです。

— TypeSafe Docs「Introduction」¹

LLM に「この問い合わせは請求の話か、技術の話か」を判断させるときの、文章で答えさせてコードで読み取る、あの往復のことです。Jev の定義は、その往復をなくすことそのものになっています。

Jev evaluates typed questions against a state and returns structured results directly. No text generation, no parsing.

（訳）Jev は、型の付いた「質問」を「状態」に対して評価し、構造化された結果を直接返します。文章の生成も、読み取りもありません。

— TypeSafe Docs「Introduction」¹

TypeSafe はこの種のモデルを System One と呼び、エージェント（自分で手順を考えて道具を使い分ける仕組み）とは違うものだと線を引いています。

System One is TypeSafe’s model for building AI-powered software, not agents. It does not generate code or choose its own next action.

（訳）System One は、AI を使ったソフトウェアを作るためのモデルであって、エージェントではありません。コードを生成せず、次に何をするかも自分では選びません。

— TypeSafe Docs「How to build with System One」²

つまり、制御の流れはこちらのコードが持ち、Jev は判断が要る箇所にだけ呼ばれます。この連載でタグ付けを任せたのも、この分担に合う使い方だからです。モデルの構造（何層か、どんな仕組みか）は公開されていないので、この連載でも推測はしません。

質問の型は3つ

質問の型は3つだけです³。

判断させたい中身（問い合わせの文面や、記事の題名など）は「状態」と呼ばれ、質問とは別に渡します。1回のリクエストで渡すものを、公式の仕様から並べるとこうなります。

状態と質問を分けて渡すので、同じ文面に何問でも聞けます。質問どうしは互いの答えを見ないので、「1問目で『はい』なら2問目を聞く」といった流れは、呼び出す側のコードで組みます。

3つの型の最小の例

公式の API リファレンスは、同じ問い合わせの文面「Help! My payouts have been failing for 3 days.」（助けて、3日前から支払いが失敗している）に、3つの型で1問ずつ聞く例を載せています⁵。聞き方と返ってくる値を並べると、こうなります。

どの型も、返ってくるのは表の右端の値だけで、文章はありません。Score の 1.05 は、段階の番号（0・1・2）を確率で重み付けした値で、段階と段階のあいだに落ちることがあります。この例では「Frustrated」（1）にほぼ寄っています。

実際に送る JSON は、次の折りたたみに入れました。

POST https://api.typesafe.ai/v1/systemone
Authorization: Bearer <API_KEY>

{
  "state": "Help! My payouts have been failing for 3 days.",
  "model": "jev-latest",
  "questions": {
    "is_urgent": {
      "type": "noul",
      "instructions": "Does this convey urgency?",
      "criteria": {
        "true": "Explicitly time-sensitive",
        "false": "No urgency expressed"
      }
    }
  }
}

{
  "model": "jev-1.13.0",
  "answers": { "is_urgent": { "type": "noul", "noul": 0.95 } },
  "usage": { "input_tokens": 307, "output_tokens": 20 }
}

{
  "state": "Help! My payouts have been failing for 3 days.",
  "model": "jev-latest",
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "Which team should handle this?",
      "criteria": {
        "billing": "Payments, invoicing, refunds",
        "technical": "Bugs, outages, integrations",
        "sales": "Pricing, upgrades, new accounts"
      }
    }
  }
}

{
  "model": "jev-1.13.0",
  "answers": {
    "department": {
      "type": "choice",
      "choice": "billing",
      "probabilities": { "billing": 0.88, "technical": 0.12, "sales": 0.0 },
      "confidence": 0.81
    }
  },
  "usage": { "input_tokens": 318, "output_tokens": 34 }
}

{
  "state": "Help! My payouts have been failing for 3 days.",
  "model": "jev-latest",
  "questions": {
    "frustration": {
      "type": "score",
      "instructions": "How frustrated is the customer?",
      "criteria": ["Calm", "Frustrated", "Very angry"]
    }
  }
}

{
  "model": "jev-1.13.0",
  "answers": {
    "frustration": {
      "type": "score",
      "score": 1.05,
      "legend": { "0": "Calm", "1": "Frustrated", "2": "Very angry" },
      "probabilities": { "0": 0.0, "1": 0.95, "2": 0.05 },
      "confidence": 0.92
    }
  },
  "usage": { "input_tokens": 304, "output_tokens": 18 }
}

この連載の実験は、すべて Noul で聞いています。

0.5 は「中くらい」ではない

Noul の値の読み方を、公式はこう書いています。

A value near 1 is a strong yes. A value near 0 is a strong no. A value near 0.5 means the model gives yes and no similar probability.

（訳）1 に近い値は強い「はい」、0 に近い値は強い「いいえ」です。0.5 付近は、モデルが「はい」と「いいえ」に同じくらいの確率を付けている、という意味です。

— TypeSafe Docs「Noul」⁷

表にすると、こうなります。

0.5 は「中くらいの強さの、はい」ではありません。どちらとも言えない、という値です。

もう1つ誤解しやすいのが「確信度」です。確率の散らばり具合を1つの数にまとめた値で、公式は Noul には付かないと明記しています。

The answer’s confidence property collapses that shape into a single number from 0 to 1, so you can threshold on it without doing the math yourself. (Noul answers don’t carry one.)

（訳）答えの confidence は、確率の分布の形を 0 から 1 の1つの数にまとめたもので、自分で計算しなくても閾値を当てられます（Noul の答えには付きません）。

— TypeSafe Docs「Confidence」⁸

型ごとに並べると、こうなります。

閾値の決め方について、公式は数字を示していません。

The correct threshold values depend on your domain and the performance of the model for your use case.

（訳）正しい閾値は、使う分野と、その用途でのモデルの性能によって決まります。

— TypeSafe Docs「Confidence」⁸

この連載では、この一文を「閾値は自分のデータで決めるもの」と読んでいます。後半の実験で、確率の線をどこで引くかを送る前に書き留めたのは、そのためです。

何に向けて学習したか

Jev は、答えが当たる割合に確率を合わせるように学習した、と TypeSafe は説明しています。この学習の段階を TypeSafe は RLCD（Reinforcement Learning for Calibrated Decisions）と呼び、人の好みに出力を合わせる学習（RLHF と呼ばれます）と並べて説明しています。

Reinforcement learning from human feedback turned pretrained models into chatbots. It trains models to produce responses people prefer.

Reinforcement learning for calibrated decisions trains TypeSafe to return decisions and calibrated probabilities instead of generated text.

（訳）RLHF（人の評価を使った強化学習）は、事前学習したモデルをチャットボットに変えました。人が好む返答を出すように学習させます。RLCD（判断の確率を calibrate する強化学習）は、文章を生成する代わりに、判断と、calibrated な確率を返すように TypeSafe を学習させます。

— TypeSafe Docs「AI Primer」⁹

同じページの説明を、2つの列に並べ直すと、こうなります。

RLCD の側は、公式には弱点が書かれていません。利点だけが挙がっているので、これは TypeSafe 自身の主張として読みます。

RLCD が目指すのは、確率が calibrated である状態です。この言葉は、出てきた確率の数字と、実際にそれが当たる割合とが一致している、という意味です。あえて日本語で言うなら、計器の目盛りを実物に合わせる「較正」に近い言葉ですが、なじみの薄い語なので、この連載では英語のまま calibration（calibrated）と書きます。

公式は、calibrated な確率の意味をこう書いています。

Outcomes assigned a probability of 0.2 should occur about 20% of the time.

Outcomes assigned a probability of 0.8 should occur about 80% of the time.

（訳）確率 0.2 が付いた結果は、およそ2割の頻度で実際に起きるはずです。確率 0.8 が付いた結果は、およそ8割の頻度で起きるはずです。

— TypeSafe Docs「AI Primer」⁹

同時に、公式はこの性質に限界があることも書いています。

Calibration is measured across groups of predictions; it does not guarantee that an individual answer is correct.

（訳）calibration は予測のまとまりに対して測るものであり、個々の答えが正しいことは保証しません。

— TypeSafe Docs「System One」¹⁰

この一文は大事です。0.9 と出た1件が正しいとは言えない、ということだからです。そしてこの連載では、calibration は測っていません。測れなかった理由が、この記事の後半の結果そのものです。

ブログの57記事で試したこと

57記事それぞれの題名と概要文だけを送り、タグとカテゴリを「はい」の確率で答えさせました。送ったのは 2026年9月20日、モデルは jev-1.13.0 と claude-haiku-4-5 で、設計と判断はどちらも書き手の私です。

各記事について、送ったものと送らなかったものは次のとおりです。

聞いた問いと、確率から実際のタグとカテゴリを決める読み方は、次のとおりです。読み方は送る前に決めて書き留めました。

1記事65問を57記事に聞いたので、全部で 3,705問です。

比べる相手として、Claude Haiku 4.5 にも同じ問いを送りました。Haiku には、Anthropic のコーディング用ツール Claude Code を通して送っています。条件は1点だけ揃っていません。

Haiku に1文足したのは、65問を一度に渡すと「何個選ぶか」に寄った答えが返りうるためです。Jev にはこの1文が届いていないので、確率の出方に差が出ている可能性があります。

計画では、2つのモデルの答えが割れたところを割れ方の強い順に並べ、上から順に私が判断するつもりでした。判断すれば、どちらがどれだけ正しいかが分かるはずでした。

判断はほぼ一致した

最初に分かったのは、2つのモデルの答えがほとんど同じだったことです。

選ばれたタグが完全に一致した記事は11件だけですが、割れ方を見ると1記事あたり2件前後です。3〜5個のうち1〜2個がずれる、という形でした。3,705問のうち、割れたのは4%です。

カテゴリ28件は、すべて「どちらも妥当」だった

答えが割れたカテゴリを28件見たところ、28件すべてで Jev と Haiku のどちらの答えも妥当でした。

判断する38件は、送る前に決めた順序で選びました。割れ方が強い順に上から30件と、タグだけに同じ順序を当てた上位10件です（2件が重なるので38件）。

上位30件のうち28件がカテゴリでした。カテゴリは「両方が高い確信で別々の答えを選んだ」ときに割れ方が強く出るので、上に集まったのです。38件の内訳は次のとおりです。

典型的なのは、ある記事を片方のモデルが「Tech」、もう片方が「AI」に入れた、という割れ方です。どちらが妥当かを判断しようとして、どちらも間違っていないことに気づきました。私のブログでは、広い意味では Tech の中に AI が入っています。「レビュー」も「開発」も同じで、レビューの記事だと言われればそうだし、AI の記事だと言われればそれも間違いなく合っています。

実際、Jev が選んだカテゴリと今のカテゴリも、57記事中37記事で食い違っていました。食い違い方を並べると、Tech と AI の入れ替わりが大半です。

37件のうち23件が Tech と AI の入れ替わりです。今のカテゴリも Tech と AI の2つで4分の3を占めています。この2つの区別は、私にもモデルにも付いていなかったのです。

つまり、カテゴリは「9つから1つ選べ」という問いとして、答えのある問いではありませんでした。モデルが間違えたから割れたのではなく、排他的に1つを選ばせる問いの立て方が、この題材に合っていなかったから割れたのです。

直すなら、AI の下に小分類を置くか、カテゴリをやめてタグの組み合わせで絞るか、のどちらかだと考えています。どちらも「1つ選ぶ」をやめる方向です。ただ、まだ実施はしていません。

判断する枠の28個を、使い切ってしまった

実験の設計としては失敗です。送る前に決めた30枠のうち28枠が、正解データを1件も生みませんでした。割れ方の強さを、タグ（2つの確率の差）とカテゴリ（低いほうの確信）で違う定義のまま1本の順位に混ぜたのが原因です。次にやるなら、種類ごとに枠を分けて登録します。

タグ10件も、8件は好みだった

タグの10件も、8件は「どちらでも誤りではないが、こちらのほうが好ましい」という好みの問題でした。

私の判断は、表の上では Jev 5件、Haiku 5件に分かれています。

最初は、これを「正しい5件と間違った5件」として表にしました。ところが自分で書いた判断のメモを読み直すと、ほとんどが「どちらも間違ってはいない。ただ、こちらのほうが好ましい」でした。メモに残っていたのは「間違ってはないんですけど」「付けないほうが適切」「誤って受け取られそう」といった言葉です。

10件を、誤りかどうかで分け直すとこうなります。

8件は、付けても付けなくても誤りではありません。これは正誤ではなく、書き手の方針です。

タグは、書き手が記事を整理するためだけのものではありません。読者が思い浮かべた語で記事にたどり着くためのものでもあります。その語を付けるかどうかは、どういう読者に届けたいかで決まります。モデルに「正しいタグ」を聞いても、答えは1つに決まりませんでした。

前の節で、この連載では calibration を測っていないと書きました。理由はここにあります。calibration を確かめるには「0.8 と出たものの8割が本当に『はい』か」を数える必要があるので、「本当に『はい』」が決まらない題材では、測定そのものが成り立ちません。

誤りと言えた2行と、好みの向き

本文に無い名前を、名前の似た話題から足した

はっきり誤りと言えたのは2行だけで、どちらも同じ記事です。ClawdBot というメッセージング連携の製品を紹介した記事に、Haiku が claude と anthropic をどちらも 0.90 で付けました。本文には claude も anthropic も一度も出てきません。Jev は 0.12 と 0.06 で、付けませんでした（Haiku は1回の測定です）。

この記事は Claude の話をしていません。名前が Claude に似ているという当時の話題に引かれただけで、実際には関係ありません。これは好みではなく誤りです。

ただ、この2行から「Jev は名前に引かれにくい」とは言えません。条件を揃えて測り直したら、Jev も名前に強く引かれる場面がありました。それが次の Part 2 の話です。

好みの向きは、名前が本文にあるかどうかと一致した

Haiku だけが「付けるべき」と言った9件を並べ直すと、書き手の判断はきれいに分かれていました。

9件すべてで、名前が本文にあるタグは付け、ないタグは付けませんでした。多くは好みの判断ですが、その好みの向きは「本文に無い名前は足さない」で一貫していました。ただし9件で、判断したのは私1人です。

私の判断とは別に、似た向きの観察がもう1つあります。今付いているタグのうち、各モデルが選んだ割合を、タグ名が題名か概要文にそのまま出ているかどうかで分けて数えました。

名前が出ていない側はほぼ同じで、出ている側で差が付きました。タグ名が本文に出ていると、Haiku のほうが強く引かれます。ただしこの割合は高めに出ています。今のタグと概要文は、同じモデルが同じ手順で書いたものだからです。どちらが正しいかではなく、寄り方が違う、という観察です。

両方とも ai を足せと言う

もう1つ、2つのモデルで答えが揃ったのに困ったところがあります。ai タグです。

私のタグ一覧には、ai の説明として「これ1つで終わらせず、必ず具体的なタグと併用する」と書いてあります。2つのモデルはどちらもその説明を読んだうえで、ほぼすべての記事に ai を付けました。

AI の記事ばかりのブログで「AI の話題を探している読者が、この記事を求めるか」と聞けば、ほぼすべて「はい」になります。これは片方のモデルの癖ではありません。ai というタグが記事を絞り込む役に立っていないか、私の聞き方がそうなっているか、あるいは両方です。どちらにしても、直すのはモデルではなくタグの設計の側です。

正誤で比べられないときに見るもの

ここまでをまとめると、この題材では「どちらのモデルが正確か」に答えが出ません。38件のうち、正誤が付いたのは2行だけです。そこから見えたのは、モデルの差よりも、自分のタグとカテゴリの設計のほうでした。

同じようにタグ付けやカテゴリ分けをモデルに任せるなら、先に次の3つを確かめることを勧めます。

2つ目は、私の場合「本文に無い名前は足さない」という方針がそれでした。一方で、本文に無い名前を似た話題から足すのは、方針ではなく誤りです。この2つを分けて数えないと、好みの割れに埋もれて誤りが見えなくなります。

3つ目は、カテゴリのように「1つ選べ」と聞く問いが、選択肢どうしが重なっていると必ず割れるためです。モデルには候補を並べさせ、どこで切るかは人の方針で決める、という分担が合っています。

この3つにも向かない場面があります。1つ目は、割れた件を人が読む手間がかかり、件数が多いと10件では足りません。2つ目は、好みか誤りかの線引き自体が人によって変わるので、判断する人が1人だと、その人の方針がそのまま結果になります。3つ目は、選択肢が本当に排他的な題材（たとえば記事の言語が日本語か英語か）には当てはまりません。

この結論が崩れる条件

この記事の結論は、次の観測が出たら崩れます。

表の「未確認」が多いのは、判断した人が私1人だからです。この記事の結論は、私のブログを私が判断した範囲のものです。

測っていないこと

• 判断したのは書き手の私1人です。57記事、判断した38件で、統計的に何かを主張できる件数ではありません
• 名前の有無で9件がきれいに分かれた件は、n=9 です
• Haiku の数字はすべて1回ずつの測定で、揺れは測っていません。指示文に1文多いという非対称もあります
• どちらが速いか、安いかは比べていません。Haiku は Claude Code 経由で送っていて、送った量の大半が道具側の準備の文章でした。モデル同士の比較になっていないためです
• calibration（0.9 と出たものが9割正しいか）は測っていません。理由は上に書いたとおりです

次の Part へ

正誤が付かない題材では、モデルを測れません。そこで次の Part 2 では、正解が作り方で決まる記事を自分で書いて送りました。名前は出てくるのに中身は違う、「名前だけ同じ記事」です。そこで、Jev の確率が何に反応しているのかが見えてきます。

参考文献