前回の記事では、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 |
Score | Set up a rubric to grade with | How much did |
Choice | Ask a multiple choice question | What color is |
日本語にすると、次のようになる。
- 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の一番面白いところかもしれない。
