blog

Jevを使ってAIをもっと賢く活用しよう

NEXTREE.

• 15 min read
Jevを使ってAIをもっと賢く活用しよう

序論：私たちはLLMを使いすぎているのではないでしょうか？

ここ数年、AIアプリケーションの開発は、事実上LLM（Large Language Model）を中心に進められてきました。ユーザーが質問すればLLMに送り、文書を分析するときもLLMに送り、メールを分類するときもLLMに送り、Agentが次の行動を決定するときも、再びLLMに尋ねます。

LLMは非常に強力です。自然言語を理解して文章を作成し、コードを生成し、複雑な内容を要約して推論できます。問題は、私たちがLLMを必要としないところまでLLMを使っていることです。

たとえば、顧客から次のようなメールが届いたと考えてみましょう。

"I was charged twice. Please refund the duplicate payment as soon as possible."

私たちが知りたいことが次の3つだけだとしたら、どうでしょうか？

  • この問い合わせはBillingかTechnical Supportか？

  • 緊急の問い合わせか？

  • 顧客の不満の度合いはどの程度か？

従来のLLMを使うなら、次のように質問することができます。

Analyze the following customer message.

1. Determine the category.
2. Determine whether it is urgent.
3. Evaluate the customer's frustration level.

Return the result as JSON.

LLMはこの問題を十分に解決できます。しかし、私たちが実際に必要としているのは、長い説明文ではなく、次のような値です。

category = billing
urgent = 0.91
frustration = 1.7

つまり、必要なのは生成（Generation）ではなく判断（Decision）です。ところが私たちは、この小さな判断のために汎用生成モデルを呼び出し、プロンプトを作成し、JSON形式を指示し、結果をパースし、スキーマを検証し、例外処理まで行います。

TypeSafe AIが2026年9月に公開したJevは、まさにこの点から出発したモデルです。TypeSafeはJevを、自社初のSystem One Modelだと説明しています。自然言語やアプリケーションの状態を入力として受け取り、長い文章を生成する代わりに、ソフトウェアがそのまま利用できるtyped probabilistic decision、つまり型の定められた確率ベースの判断を返すモデルです。

この記事で伝えたい核心はシンプルです。LLMを使うなということではなく、LLMが必要でない判断までLLMにさせるのはやめよう、ということです。これからAIアプリケーションをうまく作る開発者は、最も強力なモデルを使う開発者ではなく、どの問題をどの種類のAIに任せるべきかを見分けられる開発者になる可能性が高いでしょう。

1. Jevとは何か？

Jevは、TypeSafe AIが公開した初のSystem One Modelです。TypeSafeは、System Oneという名称をDaniel Kahnemanの『Thinking, Fast and Slow』で説明されているSystem 1の概念から取ったと説明しています。人間の思考を、速く直感的なSystem 1と、遅く熟考するSystem 2に分ける考え方に着想を得たものです。Jevという名前も、経済学者William Stanley Jevonsに由来するとTypeSafeは明らかにしています。

一般的なLLMを非常に単純化すると、次のように表現できます。

Input
  ↓
LLM
  ↓
Text Generation
  ↓
"Based on the information provided,
 this customer seems to..."

一方、Jevは次のものに近いと言えます。

State
  ↓
Jev
  ↓
Typed Decision
  ↓
billing : 0.97
urgent : 0.91

TypeSafeの表現を借りれば、Jevは一種の「frontier-intelligence function call」です。つまり、AIを人間と会話する相手としてではなく、1つのプログラミング primitiveとして使おうというアプローチです。

unstructured state
        ↓
      Jev
        ↓
typed probabilistic decisions

この違いは、思った以上に重要です。LLMの最終的な利用者は通常、人間であることが多い一方、Jevの結果を利用するのは主にプログラムです。

LLM → Text → Human
Jev → Decision → Code

したがって、Jevの目的は魅力的な文章を生成することではなく、プログラムが次の行動を決定できるようにすることです。

2. Jevが提供する3つの判断

2.1 Choice

Choiceは、複数の候補の中から1つを選択します。たとえば、顧客からの問い合わせを次のように分類すると考えてみましょう。

billing
technical
sales
other

Jevに「Which department should handle this request?」と質問すると、選択された項目とともに、それぞれの選択肢の確率を受け取ることができます。

choice = billing

billing 0.93
technical 0.04
sales 0.01
other 0.02

Choiceは、問い合わせの分類、文書の分類、Agent Toolの選択、Model Routing、Intent Detection、イベントRoutingといった問題に特に役立ちます。

2.2 Score

Scoreは、順序のあるいくつかの基準を定義し、その間でスコアを計算します。たとえば、顧客の不満の度合いを次のように定義できます。

0 = Calm
1 = Frustrated
2 = Very Angry

そして「How frustrated is the customer?」と尋ねます。結果は必ずしも0、1、2のいずれかである必要はなく、たとえばscore = 1.63のように中間値で表すこともできます。

したがってScoreは、緊急度、危険度、関連性、品質、優先度、顧客の不満度、文書の重要度といった問題によく適しています。

if score > 1.5
    → priority queue
else
    → normal queue

2.3 Noul

最もなじみのない用語がNoulです。Noulは誤記ではなく、TypeSafeが実際のAPIで使用しているprimitiveの名前です。簡単に言えば、Yes/Noの性質を持つ質問に対して、Yesである確率を返す方式です。

Does this customer require an immediate response?

→ 0.92

単純なBooleanより確率値が便利な理由は、アプリケーションのポリシーを細かく設計できるからです。

0.90 이상      → 자동 처리
0.60 ~ 0.90   → 사람이 확인
0.60 미만      → 처리하지 않음

つまり、AIにすべてを決定させるのではなく、AIは確率を提供し、実際のポリシーはコードが決定します。この点が、開発者の観点からJevを特に興味深いものにしています。

3. では、LLMとJevは何が違うのか？

ここで、重要な誤解を1つ先に整理しておく必要があります。「LLMは文字列だけを返し、構造化された値を返すのはJevだけだ」と単純化するのは正確ではありません。最近のLLMは、Structured Output、JSON Schema、Function Calling、Tool Callingなどをサポートしています。LLMを使ってChoiceのようなインターフェースを作ることも十分に可能です。

違いは、モデルの目的と構造にあります。Jevは最初から、制限された形式の判断を迅速に返す意思決定 primitiveに焦点を当てています。

区分

LLM

Jev

主な目的

生成、会話、推論

判断

代表的な出力

Text / Code / JSON

Choice / Score / Noul

出力の自由度

非常に高い

あらかじめ定義された範囲

適した利用者

人間 + プログラム

主にプログラム

自由な文章作成

非常に強い

不適切

分類／判断

可能

核心となる目的

結果の確率

個別設計が必要な場合が多い

モデルインターフェースの核心

Agentの小さな意思決定

可能だが、相対的に重くなる可能性がある

非常に適している

創作／要約／コード生成

適している

不適切

簡単に言えば、LLMは何かを作り出すAIであり、Jevは何をするかを判断するAIに近い存在です。もちろん、実際のLLMの役割はこれよりはるかに広いですが、アプリケーションアーキテクチャを設計する際には、この程度の役割分担だけでも非常に役立ちます。

4. Jevが注目を集める最大の理由――速度とコスト

AIサービスを運用していると、最初はモデルの知能だけに目が向きます。しかし、サービスの規模が大きくなると、Latency、Cost、Throughput、Reliabilityといった運用上の特性が重要になります。特にAgentは、1回のユーザーリクエストを処理するためにAIを複数回呼び出すことがあります。

현재 화면 분석
    ↓
어떤 행동을 할지 판단
    ↓
버튼 선택
    ↓
다음 화면 확인
    ↓
다음 행동 판단
    ↓
...

1つのタスクを実行するために、10回、20回、50回の判断が発生することがあります。判断のたびに高性能なLLMを呼び出すと、Token CostとLatencyが積み重なります。

TypeSafeが2026年9月に公開したJevの価格は、当時の基準で入力100万トークンあたり0.042ドルで、出力トークンには別途課金しない仕組みでした。同社が公開した応答時間の範囲は約70～500msでした。ただし、これらの数値は環境、入力長、ネットワーク、workloadによって変わる可能性があるため、すべての状況で同じ性能が得られると解釈してはいけません。

それでも、構造上の違いは明らかです。アプリケーションでbilling、0.92、1.71のような値だけが必要であれば、長い説明を生成しないモデルのほうが自然な選択になる場合があります。不要な出力を作らないこと自体が最適化なのです。

5. 実際、Jevはどこで使えるのか？

Jevが公開されて以降、メール分類、Browser Agent、広告分析、論文分類、ファイルの自動整理など、さまざまな実験が登場しました。以下のコストと速度は、各デモの制作者が自身の環境で公開した結果であるため、同一条件で比較した標準benchmarkとして受け取ってはいけません。

5.1 メール500件の自動分類

公開されたあるデモでは、500件のメールをカテゴリ、緊急度、返信の要否などによって分類しました。制作者が公開したJevのコストは約0.035ドルでした。

Inbox
  ↓
Jev
  ├─ 중요?
  ├─ 답장 필요?
  ├─ 업무 관련?
  └─ 긴급?
  ↓
Priority Queue
  ↓
필요한 메일만 LLM에게 전달
  ↓
답장 초안 생성

この構成の核心はLLMを排除することではなく、LLMが本当に必要な箇所でのみ使うように、呼び出し回数を減らすことです。

5.2 Browser Agent

Browser Agentは、Jevの特徴を理解するのに適した事例です。公開プロジェクトでは、WebページのDOMを分析し、次のアクションをJevが選択するように構成しました。

CLICK
TYPE_TEXT
SELECT
SCROLL_UP
SCROLL_DOWN
WAIT
DONE
BLOCKED

興味深いのは、実際にテキストを生成する必要があるTYPE_TEXTの状況でのみLLMを使う方式です。

Decision        → Jev
Text Generation → LLM
Browser Operation→ Code

公開されたチューリッヒからロンドンへのGoogle Flights検索デモでは、全体の実行時間が約7.1秒、Jevのコストが約0.0039ドルと表示されました。この事例は、Agent全体が1つの巨大なLLMである必要はないことをよく示しています。

5.3 広告724件の分析

別の公開デモでは、37ブランドの724件の広告を、Hook、Format、Offer、CTA、Awareness Stageなどの基準で分析しました。制作者が公開した結果は、約40秒、Jevのコストは約0.09ドルでした。

AIによる判断の単価が十分に低くなると、一部のサンプルだけを見る方式から、可能な限りすべてのデータを分析する方式へと業務パターンが変わる可能性があります。これは単なるコスト削減以上に重要な変化です。以前はコストのために試せなかった問題を解決できるようになるからです。

5.4 AI論文1,018件の分類

1,018件のAI関連論文を24のテーマに分類した公開事例もあります。この事例では、論文の要約はLLMが担当し、定められたtaxonomyに基づく分類はJevが担当しました。

Paper
   ↓
LLM
   ↓
Summary
   ↓
Jev
   ↓
24개 Topic 중 하나 선택

制作者が公開したJevによる分類コストは約0.08ドルで、median latencyは論文1件あたり約256msでした。ただし、パイプライン全体には別途LLMによる要約コストが発生していました。この事例が示す核心は、すべてのAI問題を1つのモデルで解決する必要はないという点です。

6. Jevをコードで使ってみよう

TypeSafeはPython SDKとJavaScript/TypeScript SDKを公開しています。Python SDKのパッケージ名はtypesafe-sdkで、公式サンプルはstateとquestionsをsystem_one()に渡す構成になっています。

uv add typesafe-sdk

export TYPESAFE_API_KEY="..."

以下は、顧客からの問い合わせを分類し、緊急度と不満のレベルを判断する例です。

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

state = {
    "message": "I was charged twice. "
               "Please refund the duplicate payment today."
}

questions = {
    "category": Choice(
        instructions="What is this customer request about?",
        criteria={
            "billing": "Payment, refund or charge related issue",
            "technical": "Technical problem",
            "sales": "Sales or pricing inquiry",
            "other": "Anything else"
        }
    ),

    "urgent": Noul(
        instructions="Does this request require urgent attention?"
    ),

    "frustration": Score(
        instructions="How frustrated does the customer appear?",
        criteria=["Calm", "Frustrated", "Very angry"]
    )
}

with TypeSafeClient() as client:
    response = client.system_one(
        state=state,
        questions=questions
    )

category = response.choices["category"].choice
urgent = response.nouls["urgent"].noul
frustration = response.scores["frustration"].score

概念的に、category = billing、urgent = 0.94、frustration = 1.32のような結果が得られたと仮定すると、その後は通常のプログラムコードでポリシーを適用できます。

if urgent > 0.90:
    priority = "HIGH"
elif urgent > 0.60:
    priority = "MEDIUM"
else:
    priority = "NORMAL"

ここで重要なのは、Jevにビジネスポリシーまで決定させないことです。Jevは判断に必要なシグナルを提供し、実際のポリシーはコードが担当します。

AI   → Probability
Code → Business Rule

7. TypeScriptではさらに明確に見える

TypeScript SDKでは、質問の型に応じて返される結果の形式も明確に区別できます。例は次のとおりです。

import { choice, noul, score, TypeSafeClient }
  from "@typesafe-ai/sdk";

const client = new TypeSafeClient();

const result = await client.systemOne({
  state: {
    message: "I was charged twice. " +
             "Please refund the duplicate payment today."
  },
  questions: {
    category: choice(
      "Which department should handle this?",
      {
        billing: "Payment and refund issues",
        technical: "Product or technical issues",
        sales: "Pricing and sales",
        other: "Anything else"
      }
    ),
    urgent: noul(
      "Does this request need urgent attention?"
    ),
    frustration: score(
      "How frustrated is the customer?",
      ["Calm", "Frustrated", "Very angry"]
    )
  }
});

開発者の立場から見ると、String Prompt → AI → String Response → Parsing → Validation → Applicationという構成よりも、Typed Question → Jev → Typed Decision → Applicationという構成のほうが、はるかに自然に感じられるかもしれません。

8. Java開発者はどのように使うのか？

現在、TypeSafeが公式に公開している代表的なSDKはPythonとJavaScript/TypeScriptであり、Java向けにはcommunity SDKやSpring AI連携プロジェクトが登場しています。しかし、Jev API自体はREST方式であるため、Javaで必ず別途SDKが必要なわけではありません。

主要なAPIはPOST /v1/systemone形式で、リクエストにはmodel、state、questionsが含まれます。Java開発者であれば、HttpClient、Jackson、Spring RestClient、またはWebClientなどを使って簡単にラッピングできます。

interface DecisionService {
    TicketDecision classify(CustomerMessage message);
}

record TicketDecision(
        String category,
        double urgentProbability,
        double frustrationScore
) {}

アプリケーションコードにJev APIの呼び出しが直接広がるようにするのではなく、上記のようにabstractionを置けば、背後でJevを使っているのか、別のDecision Modelを使っているのかをアプリケーションが知る必要はありません。将来、モデルやproviderを交換する際にも有利です。

9. Jevを最も効果的に使う方法――LLMをなくそうとしてはいけない

JevとLLMは競合関係というより、役割が異なります。たとえば、顧客の不満に共感しながら丁寧な返金案内メールを作成する仕事は、文章を生成する必要があるためLLMが適しています。一方、「この顧客には返信が必要か？」「この問い合わせをどのチームに送るべきか？」といった質問は、Jevのほうが適しています。

Decision   → Jev
Generation → LLM
Execution  → Code
Review     → Human

この組み合わせこそが、Jevを最も興味深いものにしている部分です。それぞれのツールに、最も得意な役割を担当させるのです。

10. Multi-Agent時代にはModel Routingがより重要になる

これからAgentシステムはますます複雑になるでしょう。1つのAgentですべての仕事を行うのではなく、複数のToolとModelを組み合わせるようになる可能性が高いです。

User Request
     ↓
Jev
     ↓
Task Complexity
     │
     ├── Simple → Small Model
     ├── Medium → General LLM
     └── Complex → Frontier Model

すべての質問を最も高価で強力なモデルに送る必要はありません。むしろ、AIシステム自体が「この問題は難しいか？」「検索が必要か？」「Human approvalが必要か？」「高性能モデルに送る必要があるか？」を先に判断するように設計できます。

過去に開発者がClass、Method、Database、API、Transaction、Eventを設計していたとすれば、AI時代にはDecision Architectureも併せて設計する必要があります。つまり、どの判断をコードが行い、どの判断をJevが行い、どの判断をLLMが行い、どの判断を人間が行うべきかを区別する能力が重要になります。

11. AIを巨大な1つの関数にしない

LLMを使用する際によくある設計は、1つの巨大なpromptに分類、判断、routing、生成までをすべて組み込む方式です。最初は便利ですが、システムが複雑になるほど、どこで間違いが起きたのかを確認しにくくなり、ポリシーの変更やテストも難しくなります。

isSpam()
    ↓
category()
    ↓
urgency()
    ↓
needsReply()
    ↓
route()
    ↓
generateReply()

前段の判断をJevが担当し、route()をコードが担当し、最後のgenerateReply()だけをLLMが担当するように分離できます。この構造の利点は、単に安くて速いというだけでなく、デバッグとテストが容易になることです。

12. しかしJevも間違うことがある

Jevがtyped outputを提供するからといって、判断そのものが常に正確だという意味ではありません。たとえば「このメールは詐欺メールか？」という質問に対して、応答形式が正しく返されることと、実際に詐欺かどうかを正確に判定することは、まったく別の問題です。

Schema correctness ≠ Semantic correctness

したがって、確率値をアプリケーションのポリシーに組み込むことが重要です。

High Confidence   → Automatic Action
Medium Confidence → Strong LLM / Additional Check
Low Confidence    → Human Review

確率を提供するモデルの本当の利点は、AIが自信を持って回答することにあるのではなく、ソフトウェアが不確実性をポリシーに組み込めることにあります。

13. Jevを使うべきではない場所

Jevが注目されているからといって、あらゆる場所に組み込むのが良い設計とは限りません。レポート・メール・ブログなどの文書作成、長文書の要約、コード生成、エラー原因の説明、複雑で開かれた戦略的問題には、LLMのほうがはるかに適しています。

反対に、AかBか、どのCategoryか、どの程度重要か、どのToolを実行すべきか、どのModelに渡すべきか、人による確認が必要か、といったように答えの範囲がある程度限定されている問題であれば、Jevを検討する価値は高いでしょう。

14. 開発者の視点から見たJevの最大の価値

Jevが興味深い理由を、単にトークン価格が安いことだけで捉えると、本質を見失う可能性があります。より重要な変化は、AIがプログラムの中に入ってくる方法です。

기존 방식
Application → Prompt → LLM → Text

Decision Model 방식
Application State → Decision Primitive → Probability → Application Logic

開発者にとって、後者の構造はなじみ深いものです。私たちはすでに数十年にわたり、if (condition) { execute(); }のようなコードを書いてきました。Jevは、これまでコードで表現するのが難しかったfuzzy conditionを、プログラムの中に持ち込むツールと見ることができます。

if (jev("Is this request urgent?") > 0.9) {
    escalate();
}

15. 「AIをうまく使う」という意味も変わりつつある

これまで、AIをうまく使う人といえば、Prompt Engineeringに長けた人を思い浮かべることが多くありました。しかし、AgentとAI Automationが増えるにつれて、重要な能力も変化する可能性が高いでしょう。

  • この問題はdeterministic codeで解決できるか？

  • AIによる判断が本当に必要か？

  • AIが必要なら、生成か判断か？

  • 小さなモデルで十分か？

  • Frontier Modelが必要か？

  • 確率が低い場合、誰にescalationするのか？

  • どの判断は必ず人が確認すべきか？

つまり、1つのモデルをうまく使うことよりも、AI全体のorchestrationをうまく設計することが重要になります。

16. 推奨するAI Architecture

これを1つの簡単な原則にまとめると、次のようになります。

LLM   → 생성합니다.
Jev   → 판단합니다.
Code  → 실행합니다.
Human → 중요한 결정을 검토합니다.

この構造では、特定のモデルがシステム全体を支配することはありません。それぞれのツールが、自分の最も得意な仕事を担当します。

結論：最も強力なAIではなく、最も適切なAIを使おう

Jevはまだ非常に新しい技術です。TypeSafeがJevを公開したのは2026年9月であり、エコシステムやAPI、toolingも急速に変化しています。したがって、現在の価格や性能、SDKの状態が長期間そのまま維持されると仮定してはいけません。

それでも、Jevが投げかける問いは非常に重要です。なぜ私たちは、あらゆるAIの問題を1つのLLMで解決しようとするのでしょうか？

LLMは驚くべきツールです。しかし、1通のメールをどのフォルダーに送るかを判断するために、長い文章を生成する必要はありません。Agentが次にどのボタンをクリックするかを決めるために、毎回巨大なFrontier Modelによる長い推論を待つ必要もありません。

決められた候補の中から1つを選べばよい問題なら、Choiceを使用できます。はい／いいえの性質を持つ判断が必要ならNoulを使用でき、程度の違いを判断する必要があるならScoreを使用できます。そして、本当に文章を書いたりコードを作成したり、複雑な問題を解決したりする必要があるときは、LLMを使えばよいのです。

Generation → LLM
Decision   → Jev
Execution  → Code
Review     → Human

AIを賢く使うということは、常に最も賢いモデルを呼び出すことではありません。必要な問題に対して、必要な分だけのIntelligenceを使うことが、より重要な設計原則になる可能性があります。

数多くの小さな判断を高速で安価なDecision Modelに任せ、本当に難しい問題にだけ強力なLLMを使用する方式は、Multi-AgentとAI Orchestrationの環境で特に意味があります。

これから開発者に必要な問いは、「どのAIが最も優れているか？」ではなく、「この判断をどのAIに任せるのが最善か？」になるのかもしれません。Jevの登場は、まさにその問いを私たちに投げかけています。

参考文献

1. TypeSafe AI, 「Introducing System One Models & Jev」, 2026-09-15. https://typesafe.ai/blog/introducing-system-one-models-and-jev

2. TypeSafe AI Official Website / Jev. https://typesafe.ai/

3. TypeSafe API Reference. https://api.typesafe.ai/docs

4. TypeSafe AI Python SDK. https://github.com/typesafe-ai/typesafe-sdk-python

5. TypeSafe AI JavaScript/TypeScript SDK. https://github.com/typesafe-ai/typesafe-sdk-js

6. TypeSafe Workflow Evals. https://evals.typesafe.ai/

7. Browser Use, jev-ultrafast. https://github.com/browser-use/jev-ultrafast

8. Community Jev Email Classification Demo. https://madewithjev.com/categories/triage-and-routing

9. 1k Papers / Jev Classification Demo. https://jev.gorock.sh/projects/1k-papers

10. 724 Ads Jev Demo. https://systemonemodels.org/examples/discussions/breaking-down-724-ads-from-37-brands-with-jev/

11. Spring AI Community、TypeSafe/Jev統合プロジェクト。 https://github.com/spring-ai-community/spring-ai-typesafe

※本文の価格、latencyおよびAPIの内容は、2026年9月24日時点の公開資料を基に整理したものです。Jevは公開されてからまだ日が浅いサービスであるため、実際に導入する際には、TypeSafeの最新の公式ドキュメント、料金ポリシーおよびモデルバージョンを再度確認することをおすすめします。

syhan

Site footer