Jev公式Playgroundの使い方 ─ Noul・Choice・Scoreを実際に試してみた

Posted at 2026 年 10 月 05 日

前回の記事では、TypeSafe AIが開発した「文章を書かないAI」Jevについて紹介した。

JevはChatGPTやClaudeのように文章を生成するのではなく、与えられた状態から「どれを選ぶか」「どの程度か」「Yesである確率は何%か」といった判断だけを返すAIである。

では、実際にはどのように動くのか。

今回は、TypeSafe公式のコンソール(console.typesafe.ai)に用意されているPlaygroundを使って、コードを書かずにJevを触ってみた。

※本記事の内容は2026年10月5日時点の画面と公式ドキュメントに基づく。Jevは公開から間もないサービスのため、画面や仕様は変わる可能性がある。

■Playgroundを開く

TypeSafeの公式サイト(typesafe.ai)からコンソールにサインインし、左側のメニューからPlaygroundを選ぶ。直接開く場合のURLは次のとおり。

https://console.typesafe.ai/playground

左側のメニューには、次の項目が並んでいる。

メニュー

内容

Home

コンソールのトップ

Playground

コードを書かずにJevを試す画面

Usage

API利用量の確認

API Keys

APIキーの発行・管理

Documentation

公式ドキュメント(docs.typesafe.ai)へのリンク

左下にはBalance(残高)が表示されている。

■画面は「State」と「Questions」の2つに分かれている

Playgroundの画面は、上下2つの入力欄で構成されている。

欄

入れるもの

State

判断させたい情報(文章やJSON)

Questions

Jevに聞きたい質問

ChatGPTのような「プロンプト入力欄」は存在しない。「判断材料」と「質問」を分けて渡すのがJevの基本である。

State欄には、最初から次のようなサンプルが薄く表示されている。

{
  "example_state": "Add context for TypeSafe to evaluate"
}

ここに、問い合わせメールやフォームの投稿内容など、判断させたい情報を入れる。

画面下部には使用するモデル(初期値は jev-latest)とRunボタンがあり、Runを押すとJevが判定を返す。

■質問の型は3種類から選ぶ

Questions欄の { の中にカーソルを置くと、「Select primitive type」という候補が表示される。ここで選べるのが、Jevの3つの質問の型(プリミティブ)だ。

型

画面の説明

例

Noul

Evaluate how true something is

Is food a sandwich?

Score

Set up a rubric to grade with

How much did subject contribute?

Choice

Ask a multiple choice question

What color is object?

日本語にすると、次のようになる。

  • Noul:それがどのくらい正しいか(Yesである確率を0〜1で返す)
  • Score:自分で決めた評価基準(ルーブリック)で段階評価する
  • Choice:選択肢の中から1つ選ぶ

自由記述で答えさせる型はない。最初から「答えの形」を決めてから質問するという点が、通常の生成AIとの大きな違いである。

■右側の「Learn to TypeSafe」で例を試せる

画面右側には「Learn to TypeSafe」というパネルがあり、すぐに試せるサンプルが用意されている。

Walkthrough lessons(3つの型を1つずつ学ぶレッスン)

型

レッスン

Noul

Is hotdog a sandwich?(ホットドッグはサンドイッチか?)

Choice

What color is the sky?(空は何色か?)

Score

Can monkeys create art?(サルは芸術を生み出せるか?)

Real-life use cases(実務を想定したサンプル)

  • Resumé screening:エンジニアの履歴書の評価
  • Support agent audit:カスタマーサポート対応の監査
  • LLM guardrails:ジェイルブレイク(脱獄)の試みの検出

「ホットドッグはサンドイッチか」のように答えが割れそうな問いを、Yes/Noの二択ではなく確率で返させるのがNoulの面白いところだ。

■問い合わせメールを判定させてみる

公式のQuick Startにある例を使って、実務に近い判定を試してみる。
※クレジットに事前入金が必要です。

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.

「Stripe連携が3日間失敗していて、売上を失っている。至急助けてほしい」という内容だ。

Questions欄には、3つの型をまとめて入れる。

{
  "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"
    }
  },
  "frustration": {
    "type": "score",
    "instructions": "How frustrated the customer appears",
    "criteria": [
      "Calm, just stating facts",
      "Frustrated but civil",
      "Very angry, strong language"
    ]
  },
  "is_urgent": {
    "type": "noul",
    "instructions": "The message conveys urgency or time-sensitivity"
  }
}

聞いているのは次の3点である。

質問

型

内容

department

Choice

どの部署が担当すべきか(請求・技術・営業)

frustration

Score

顧客のいら立ちの度合い(3段階)

is_urgent

Noul

緊急性があるか

Runを押すと、画面右側にResponseパネルが開き、結果が表示された。

質問

結果

Confidence

department

technical 82% / billing 18% / sales 0%

73%

frustration

1 of 2

100%

is_urgent

99%(true)

―

「連携が失敗している」という内容から、担当はtechnical(技術)と判定された。ただしbilling(請求)にも18%が割り振られている。Stripe(決済サービス)や「売上を失っている」といった言葉から、請求関係の可能性も残したのだろう。

いら立ちの度合いは「1 of 2」。0〜2の3段階のうち1、つまり2番目の「Frustrated but civil(いら立っているが礼儀正しい)」である。緊急性は99%で、ほぼ確実にYesという判定だ。

ポイントは、返信文はどこにも出てこないことだ。返ってくるのは選択肢・段階・確率という「判断の結果」だけである。

■結果の読み方

3つの型は、返ってくる値の形がそれぞれ違う。

型

主な値

読み方

Choice

choice / probabilities / confidence

選ばれた選択肢と、全選択肢の確率

Score

score / legend / probabilities / confidence

段階上の位置(0始まり)と、各段階の確率

Noul

noul

Yesである確率(0〜1)

特に間違えやすいのが次の2点である。

Scoreは0始まり

3段階で定義した場合、scoreは0〜2の範囲で返る。Playgroundでは「1 of 2」のように「最大2のうち1」という形で表示されるので、「2段階中の1段階目」と読み間違えないようにしたい。

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

公式ドキュメントによると、Noulは1に近いほど強いYes、0に近いほど強いNo、0.5付近は「判断がつかない」という意味になる。0.5は「YesとNoが同じ確率」であって、「中程度にYes」という意味ではない。

また、ChoiceとScoreに付くconfidenceは、確率が1つの選択肢にどれだけ集中しているかを表す値だ。確率がばらけているほど低くなる。今回のdepartmentは、technicalの確率が82%でも、billingに18%が割れているためconfidenceは73%にとどまった。

■「AIに処理させる」のではなく「AIに選ばせる」

Playgroundを触っていて最も分かりやすかったのが、この部分だった。

普通の生成AIを使ったシステムでは、

ユーザー入力
 ↓
LLM
 ↓
文章生成
 ↓
JSONへ変換
 ↓
プログラムが処理

という構成になりやすい。

Jevでは、

ユーザー入力
 ↓
Jev
 ↓
選択・確率・スコア
 ↓
プログラムが処理

となる。

例えば先ほどの判定結果なら、

if (response.answers.department.choice === "technical") {
  assignToTechTeam();
}

のように、そのまま通常のプログラムへ渡せばよい。

前回の記事でJevを「AI版の超高性能if文」と紹介したが(TypeSafe自身は「smart if-statements」と表現している)、Playgroundで実際に型付きの答えが返ってくるのを見ると、この意味がよく分かる。

■AIに全部やらせない設計

Jevの考え方で特に重要なのは、

AIに全部やらせない

という点である。

例えば返金の問い合わせなら、

Jevが「返金の依頼か」を判断する
↓
コードがルールを確認する
↓
条件を満たした場合だけ返金APIを実行する

という構成にできる。

Jevが「返金」と判断したからといって、そのまま返金処理を実行する必要はない。confidenceが低い場合は人間の確認に回す、といった分岐も組める。

Jev ─ 判断
LLM ─ 推論・生成
Code ─ 実行

と役割を分けることで、AIの判断ミスがそのまま処理に流れるのを防げる。

今後AIエージェントが増えてくると、「どのAgentを使うか」「どのToolを使うか」「人間の確認が必要か」といった小さな判断が大量に発生する。これらすべてにGPTやClaudeの大型モデルを呼び出すのは、コストとレイテンシの面で無駄が多い。Jevはこの「小さな判断」を担う部品として設計されている。

■Playgroundで試してからAPIへ

Playgroundで作った質問は、APIのリクエストにも流用できる。Questions欄に書くJSONは、APIの questions と同じ形をしている。

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": { ... }}'

APIキーは左側メニューのAPI Keysから発行できる。

まずPlaygroundで「選択肢の分け方は適切か」「確率がどのくらい割れるか」を確かめ、うまく判定できる質問ができてからコードに組み込む。この順番で進めると無駄が少ない。

■まとめ:Jevは「答えの形」を先に決めるAI

今回、公式Playgroundを触ってみて、Jevの特徴が前回よりも分かりやすくなった。

ChatGPTやClaudeは、

考える
↓
文章を書く

ことが得意なAIである。

一方Jevが狙っているのは、

状況を見る
↓
選ぶ

という非常に狭い領域だ。

Playgroundの画面がStateとQuestionsの2つに分かれ、質問の型が3種類しかないのも、この設計思想の表れだろう。AIに何を答えさせるかではなく、どんな形で答えさせるかを先に決める。ここがJevの一番面白いところかもしれない。

参考リンク

DevpediaCode編集部

DevpediaCodeはWeb、AIなどプログラムに関する最新ITテーマの情報を発信するメディアです。

お問合せ下記のURLからお願いします。

https://devpediacode.com/contact