![\"\"](\"https://images.microcms-assets.io/assets/52137c02cafa4450bbdc092b64fbadac/b20990781018446da43feb947baee946/typesafe.png\")
前回の記事では、TypeSafe AIが開発した「文章を書かないAI」Jevについて紹介した。
JevはChatGPTやClaudeのように文章を生成するのではなく、与えられた状態から「どれを選ぶか」「どの程度か」「Yesである確率は何％か」といった判断だけを返すAIである。
では、実際にはどのように動くのか。
今回は、TypeSafe公式のコンソール（console.typesafe.ai）に用意されているPlaygroundを使って、コードを書かずにJevを触ってみた。
※本記事の内容は2026年10月5日時点の画面と公式ドキュメントに基づく。Jevは公開から間もないサービスのため、画面や仕様は変わる可能性がある。
TypeSafeの公式サイト（typesafe.ai）からコンソールにサインインし、左側のメニューからPlaygroundを選ぶ。直接開く場合のURLは次のとおり。
https://console.typesafe.ai/playground\n左側のメニューには、次の項目が並んでいる。
メニュー | 内容 |
|---|---|
Home | コンソールのトップ |
Playground | コードを書かずにJevを試す画面 |
Usage | API利用量の確認 |
API Keys | APIキーの発行・管理 |
Documentation | 公式ドキュメント（docs.typesafe.ai）へのリンク |
左下にはBalance（残高）が表示されている。
Playgroundの画面は、上下2つの入力欄で構成されている。
欄 | 入れるもの |
|---|---|
State | 判断させたい情報（文章やJSON） |
Questions | Jevに聞きたい質問 |
ChatGPTのような「プロンプト入力欄」は存在しない。「判断材料」と「質問」を分けて渡すのがJevの基本である。
State欄には、最初から次のようなサンプルが薄く表示されている。
{\n "example_state": "Add context for TypeSafe to evaluate"\n}\nここに、問い合わせメールやフォームの投稿内容など、判断させたい情報を入れる。
画面下部には使用するモデル（初期値は jev-latest）とRunボタンがあり、Runを押すとJevが判定を返す。
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 |
日本語にすると、次のようになる。
自由記述で答えさせる型はない。最初から「答えの形」を決めてから質問するという点が、通常の生成AIとの大きな違いである。
画面右側には「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（実務を想定したサンプル）
「ホットドッグはサンドイッチか」のように答えが割れそうな問いを、Yes/Noの二択ではなく確率で返させるのがNoulの面白いところだ。
公式のQuick Startにある例を使って、実務に近い判定を試してみる。
※クレジットに事前入金が必要です。
![\"\"](\"https://images.microcms-assets.io/assets/52137c02cafa4450bbdc092b64fbadac/d3bf77dbe10844678e7f8205ee804417/typesafe2.png\")
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.\n「Stripe連携が3日間失敗していて、売上を失っている。至急助けてほしい」という内容だ。
Questions欄には、3つの型をまとめて入れる。
{\n "department": {\n "type": "choice",\n "instructions": "Which team should handle this",\n "criteria": {\n "billing": "Payment or subscription issues",\n "technical": "Bugs or integration problems",\n "sales": "Pricing or account questions"\n }\n },\n "frustration": {\n "type": "score",\n "instructions": "How frustrated the customer appears",\n "criteria": [\n "Calm, just stating facts",\n "Frustrated but civil",\n "Very angry, strong language"\n ]\n },\n "is_urgent": {\n "type": "noul",\n "instructions": "The message conveys urgency or time-sensitivity"\n }\n}\n聞いているのは次の3点である。
質問 | 型 | 内容 |
|---|---|---|
department | Choice | どの部署が担当すべきか（請求・技術・営業） |
frustration | Score | 顧客のいら立ちの度合い（3段階） |
is_urgent | Noul | 緊急性があるか |
Runを押すと、画面右側にResponseパネルが開き、結果が表示された。
![\"\"](\"https://images.microcms-assets.io/assets/52137c02cafa4450bbdc092b64fbadac/663177bb0fee4cf9b63dfc5fcce0eccb/typesafe3.png\") 質問 | 結果 | 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%にとどまった。
Playgroundを触っていて最も分かりやすかったのが、この部分だった。
普通の生成AIを使ったシステムでは、
ユーザー入力\n ↓\nLLM\n ↓\n文章生成\n ↓\nJSONへ変換\n ↓\nプログラムが処理\nという構成になりやすい。
Jevでは、
ユーザー入力\n ↓\nJev\n ↓\n選択・確率・スコア\n ↓\nプログラムが処理\nとなる。
例えば先ほどの判定結果なら、
if (response.answers.department.choice === "technical") {\n assignToTechTeam();\n}\nのように、そのまま通常のプログラムへ渡せばよい。
前回の記事でJevを「AI版の超高性能if文」と紹介したが（TypeSafe自身は「smart if-statements」と表現している）、Playgroundで実際に型付きの答えが返ってくるのを見ると、この意味がよく分かる。
Jevの考え方で特に重要なのは、
AIに全部やらせない\nという点である。
例えば返金の問い合わせなら、
Jevが「返金の依頼か」を判断する\n↓\nコードがルールを確認する\n↓\n条件を満たした場合だけ返金APIを実行する\nという構成にできる。
Jevが「返金」と判断したからといって、そのまま返金処理を実行する必要はない。confidenceが低い場合は人間の確認に回す、といった分岐も組める。
Jev ─ 判断\nLLM ─ 推論・生成\nCode ─ 実行\nと役割を分けることで、AIの判断ミスがそのまま処理に流れるのを防げる。
今後AIエージェントが増えてくると、「どのAgentを使うか」「どのToolを使うか」「人間の確認が必要か」といった小さな判断が大量に発生する。これらすべてにGPTやClaudeの大型モデルを呼び出すのは、コストとレイテンシの面で無駄が多い。Jevはこの「小さな判断」を担う部品として設計されている。
Playgroundで作った質問は、APIのリクエストにも流用できる。Questions欄に書くJSONは、APIの questions と同じ形をしている。
curl -X POST https://api.typesafe.ai/v1/systemone \\\n -H "Authorization: Bearer $TYPESAFE_API_KEY" \\\n -H "Content-Type: application/json" \\\n -d '{"state": "...", "model": "jev-latest", "questions": { ... }}'\nAPIキーは左側メニューのAPI Keysから発行できる。
まずPlaygroundで「選択肢の分け方は適切か」「確率がどのくらい割れるか」を確かめ、うまく判定できる質問ができてからコードに組み込む。この順番で進めると無駄が少ない。
今回、公式Playgroundを触ってみて、Jevの特徴が前回よりも分かりやすくなった。
ChatGPTやClaudeは、
考える\n↓\n文章を書く\nことが得意なAIである。
一方Jevが狙っているのは、
状況を見る\n↓\n選ぶ\nという非常に狭い領域だ。
Playgroundの画面がStateとQuestionsの2つに分かれ、質問の型が3種類しかないのも、この設計思想の表れだろう。AIに何を答えさせるかではなく、どんな形で答えさせるかを先に決める。ここがJevの一番面白いところかもしれない。