Jevとは？AIエージェントに必要なのは、チャットボットの増加ではなく意思決定モデルかもしれない理由

Jevは別のチャットボットではありません。TypeSafe AIは、より限定された用途のためにJevを開発しました。状態を受け取り、構造化された判断を行い、ソフトウェアがすぐに実行できる形式で返します。段落を書く代わりに、Jevは事前定義された選択肢、スコア、確率、確信度の推定値を出力します。

これは重要です。AIエージェントの仕事の多くは、文章の生成ではないからです。エージェントは、どのツールを呼び出すか、文書が関連しているか、操作にリスクがあるか、いつ再試行するか、いつエスカレーションするかを絶えず判断します。Jevは、アーキテクチャについての有益な問いを投げかけます。ソフトウェアが判断だけを必要としているのに、なぜ大規模な生成モデルを呼び出すのでしょうか？

Jevとは？

Jevは、TypeSafe AIがSystem One Modelsと呼ぶもののもとで公開した最初のモデルです。自由形式の会話ではなく、ソフトウェア内で素早く判断することに最適化されています。

TypeSafeは、2026年9月にJevを発表しました。そのインターフェースはシンプルです。

非構造化状態
        ↓
構造化された質問
        ↓
型付き確率判断

従来型のLLMは、サポートリクエストを次のように文章を生成して分類する場合があります。

「これは、次の理由から請求に関する問題と思われます。
顧客は二重に請求されたと言っています。」

Jevは、ソフトウェアが実際に必要とする部分を返すように設計されています。

billing:     0.87
technical:   0.09
sales:       0.04

重要なのは、知能があるかないかではありません。違いはインターフェースにあります。言語モデルは生成し、判断モデルは選択します。

JevとLLM：必要なのは判断だけなのに、なぜテキストを生成するのか？

汎用LLMが価値を持つのは、説明、コード、計画、要約、メール、ツールへの引数など、ほとんどあらゆるものを生成できるからです。

しかし、その柔軟性は、タスクが次のことだけの場合には不要なオーバーヘッドを生みます。

この処理を担当するツールはどれですか？

A. ウェブ検索
B. コード実行
C. ファイル検索
D. メール

従来型のモデルでもこれは解決できますが、分類器やルーターとして汎用生成システムを使うことに変わりはありません。

そのためJevは、実用的なAIエージェントの自動化に特に適しています。そこでは、ユーザー向けの回答を1つ生成する前に、モデルが多数の小さなルーティングや安全性に関する判断を行うことがあります。

Jevはどのように構造化された判断を行うのか？

TypeSafeはアーキテクチャの詳細をすべて公開しているわけではありませんが、重要な違いとして、構造化された判断に最適化されたモデル、並列サンプラー、そして確度調整された判断のための強化学習（RLCD）と呼ばれる学習手法の3つを挙げています。

開発者向けの抽象化は次のようになります。

状態
  ↓
意思決定の問い
  ↓
確率分布
  ↓
アプリケーションポリシー

TypeSafeの公開ワークフロー評価では、3つの意思決定プリミティブが示されています:

不確実な判断はモデルが担います。ただし、各判断で何が許可されるかは、引き続きコードが決定します。

AIエージェントに意思決定レイヤーが必要な理由

本格的な推論が必要になる前に、エージェントは数十もの小さな判断を下す必要があるかもしれません:

• どのツールを呼び出すべきですか？
• この文書は関連性がありますか？
• ウェブを検索すべきですか？
• このアクションは自動実行できますか？
• 前のステップは成功しましたか？
• 再試行すべきですか？
• 人間の承認が必要ですか？

すべての分岐で利用可能な最大のモデルを使うのは簡単ですが、遅延とコストの両方が増える可能性があります。

ユーザーのリクエスト
      ↓
意思決定レイヤー
      ↓
 ┌────┼─────┬─────┐
 ↓    ↓     ↓     ↓
ウェブ  ファイル  コード  メール
エージェント エージェント エージェント エージェント

ルーターは、ファイルエージェントを選んだ理由を説明する必要はありません。十分な確信をもって正しい経路を選べばよいのです。

これは、自律システムにおける重要な安全原則も強化します。モデルの出力はアクションを提案するものであり、その実行権限を自動的に得るものではありません。独立したツール実行の信頼境界によって、コードが実際にファイルやシステムを変更する前に、権限、引数、副作用を検証できます。

AIエージェントのスタックは思考と意思決定に分かれる可能性がある

初期のエージェントの多くは、リクエストの解釈、ツールの選択、結果の評価、処理を続けるかどうかの判断、回答の作成まで、ほぼすべてを1つの強力なモデルで行います。

より専門化されたアーキテクチャでは、これらの役割を分離します:

意思決定レイヤー
      ↓
推論レイヤー
      ↓
ツールレイヤー
      ↓
データ / ストレージレイヤー

意思決定レイヤーは、反復的な振り分け、スコアリング、関連性の判定、ゲート制御を担います。大規模モデルは、統合、計画、コーディング、難しい推論を担います。決定論的なソフトウェアが最終的なアクションを実行します。

簡潔に言うと:

高速モデル:
「何をすべきですか？」

大規模モデル:
「どう実行すればよいですか？」

コード:
「実行してください。」

これがAIコストのモデルルーティングが重要である理由でもあります。最も安価なアーキテクチャは、多くの場合、1つのモデルですべてを処理するのではなく、各タスクを確実に処理できる最も低コストのレイヤーに振り分ける構成です。

最有力の回答よりも信頼度が重要な理由

ソフトウェアが明白なケースと曖昧なケースを区別できると、確率を考慮した意思決定がより有用になります。

検討してください:

請求書:       0.97
契約書:       0.02
その他:       0.01

自動処理が妥当かもしれません。

次と比較してください:

請求書:       0.43
契約書:       0.39
その他:       0.18

「請求書」が依然として最有力の回答ですが、不確実性によって次の処理を変えるべきです。

信頼度が高い
      ↓
自動実行

信頼度が中程度
      ↓
より大規模な推論モデル

信頼度が低い
      ↓
人による確認

TypeSafeは、下流の判断に活用できる信頼度を実現するための学習としてRLCDを説明しています。実際に重要なのはキャリブレーションです。システムが高い信頼度を示したとき、それは現実世界での精度の高さに対応しているでしょうか？

これは、承認プロセスによって低リスクの自動化と影響の大きい変更を切り分けられるため、ローカルファイルやシステム操作を扱うエージェントに特に役立ちます。

Jevは本当に「ハルシネーションがゼロ」なのか？

この主張には明確な定義が必要です。

Jevの出力範囲はあらかじめ定義されています。選択肢が次のとおりなら、

請求
技術
営業

モデルは、次のような想定外の自由形式のカテゴリを返せません。

マーケティング

あるいは、有効な型ではなく説明文が返されること。

これにより、重要な失敗要因の1つである無効な出力を取り除けます。

それでも、もう1つの問題は解消されません。

有効だが誤った判断。

正しい答えがtechnicalであっても、Jevはbillingを返す可能性があります。出力が型安全でも、間違っていることはあります。

したがって、役立つ解釈は次のとおりです。

Jevはスキーマにない回答を防げます。しかし、スキーマ内の判断がすべて正しいと保証することはできません。

エージェントが実際の操作を実行できる場合、この違いはさらに重要になります。構造化出力は曖昧さを減らしますが、アプリケーションレベルの権限設定と検証も依然として重要です。

Jevと構造化出力：これって単なるJSONモードでは？

最新のLLM APIは、すでに制約付きオブジェクトを返せます。

{
  "route": "billing",
  "priority": 4,
  "needs_human": false
}

つまり、本質的な違いは単に「Jevが構造化データを生成する」ことではありません。

構造化出力LLMは、応答がスキーマに従うよう制約された汎用生成モデルです。Jevは、構造化された判断そのものを処理対象として設計されています。

したがって、より適切な問いは、どちらもJSONを返せるかどうかではありません。どちらも返せます。

問うべきなのは、何百万もの小規模な分類、ルーティング、ゲーティングの判断において、汎用の言語生成モデルが最も効率的なツールなのかということです。

Jevはどれほど速く、低コストなのか？

TypeSafeは、公開されているJevのワークロードにおけるエンドツーエンドの応答時間を、約70～500ミリ秒と報告しています。また同社によると、特定の判断タスクでは、最先端モデルの構成と比べて約40～200倍高速です。

TypeSafeによると、ローンチ時点でJevは入力トークン100万個あたり0.042ドルで、判断結果には現在、別途料金がかかりません。

その数値は興味深いものの、Jevが一般に「LLMより200倍速い」ことを示す証拠ではありません。

TypeSafe自身のベンチマークに関する注記によると、ワークフローの改善幅は、ユーザーが期待すべき上限に近いケースで最も大きくなる可能性があります。また同社は、ワークフロー評価を社内で設計したため、偏りが含まれている可能性があることも認めています。

重要なコスト面のメリットが現れるのは、エージェントが小さな呼び出しを何度も行う場合です：

分類
振り分け
関連性を確認
安全性を確認
結果を検証
再試行するかどうかを判断

特化型の判断レイヤーでこれらの手順の大半を処理できれば、より深い知能が本当に必要なときだけ、高コストな推論モデルを実行すればよくなります。

Jevは実際にはどこで役立つのか？

これらのタスクには共通点があります。有効な出力がすでにわかっていることです。

答えの発見や生成そのものがタスクである場合、Jevは適していません。コードの作成、メールの下書き、論文の解説、移行計画の策定、創造的な応答の生成には、依然として生成モデルが必要です。

JevはLLMルーターの代わりになりますか？

ルーティングは、判断優先型モデルの最も明確な用途の一つです。

現在、多くのエージェントシステムでは、高コストまたは特化型のモデルの前段に、より小型のLLMを配置しています：

ユーザー
  ↓
ルーター
  ↓
 ┌──────┬──────┬──────┐
 ↓      ↓      ↓      ↓
コード   Web    ファイル   チャット

Jev型のルーターは、確率とエスカレーションの層を追加します：

ユーザー状態
    ↓
判断モデル
    ↓
ルーティング確率
    ↓
信頼度ポリシー
   ↙             ↘
明確             不確実
 ↓                   ↓
ツール / エージェント      大型LLM

すべての振り分け判断が確実であるかのように装うことなく、高コストなモデル呼び出しの回数を減らせます。

同じアーキテクチャはJevを使わなくても有用です。ルールや小型モデルで簡単な判断を処理し、曖昧なケースはより大きなモデルに任せられます。

Jevをローカルで実行できますか？

現時点では、一般公開されたJevモデルを使って実行することはできません。

2026年9月時点で、TypeSafeはJevをホステッドの早期アクセスサービスとして提供しています。公開資料には、ダウンロード可能なモデルの重みも、文書化されたセルフホスト推論の方法もありません。

これはローカルファーストAIにとって重要です。

ローカルファイル
    ↓
Jev API
    ↓
判断
    ↓
ローカルエージェント

最終的なエージェントはローカルで実行される場合もありますが、関連する状態がJevのホステッドサービスに送信されるなら、そのワークフローは依然としてハイブリッドです。

これは、プライベートな文書、顧客記録、メール、社内ナレッジベース、ホームオートメーションの状態、コード、NASのメタデータにおいて特に重要です。クラウドツールとローカルファイルを使うワークフローでは、ローカルでホストされたエージェントならすべてのデータが自動的にプライベートに保たれると考えるのではなく、ネットワーク境界を越えるコンテキストを明示的に制御する必要があります。

TypeSafeはデータ処理補遺を公開していますが、これは推論を完全に自社ネットワーク内で実行する場合とは、プライバシーモデルが異なります。

ローカルでJevのような意思決定レイヤーを構築できますか？

公開リリースに基づく限り、現在Jev自体をセルフホストすることはできませんが、そのアーキテクチャの考え方は再現できます。

リクエスト
   ↓
決定論的ルール
   ↓
ローカル分類器
   ↓
小規模なローカルモデル
   ↓
大規模なローカルモデル
   ↓
人間

たとえば、プライベートなドキュメントエージェントでは、明白なケースにはルールを、既知のカテゴリには小型のローカル分類器を、曖昧な振り分けにはコンパクトなLLMを使い、難しい推論に限って大規模モデルを使うことができます。

NAS上のプライベートAIアシスタントなら、ファイル、検索、メモリ、軽量な意思決定サービスをデータの近くに保ちながら、選択したタスクだけをより大規模な計算環境にエスカレーションできます。

完全なオフライン動作が重要なら、すべての依存関係もローカルでなければなりません。LAN上でモデルを実行していても、ルーティング、埋め込み、認証、その他の必須処理がインターネットに依存しているなら不十分です。これはオフラインでも耐障害性のあるAIワークフローにも求められる、エンドツーエンドの要件です。

Jevが示す、ローカルAIエージェントの未来

Jevの最も重要なアイデアは、Jev自体よりも長く生き続けるかもしれません。

AIシステムは、専門化し始めています。

すべての処理を単一の巨大なモデルに任せるのではなく、効率的なローカルまたはハイブリッドのエージェントは、次の要素を組み合わせられます。

意思決定モデル
→ 振り分け、分類、スコア付け

推論モデル
→ 難しい問題を解決

生成モデル
→ テキスト、コード、メディアを生成

決定論的ソフトウェア
→ 承認済みの操作を実行

ローカルストレージ
→ ファイル、メモリ、状態を保持

異なるワークロードを異なるハードウェアで、異なるプライバシールールのもとで実行できるため、セルフホスト型インフラに適しています。

これは、ローカルAIに役立つ原則にもつながります。

定型的でプライベートな高頻度の判断はデータの近くで処理し、本当に大規模なモデルやクラウドサービスが必要なタスクだけをエスカレーションします。

このアーキテクチャは、知的な処理をすべて、利用可能な最も高性能なモデルとの会話に頼るよりも、堅牢です。

JevはChatGPT、Claude、Gemini、またはローカルLLMの代替ですか？

いいえ。Jevは、任意の文章を生成する機能を意図的に手放しています。

文章の作成、説明、コーディング、統合、ブレインストーミング、自由形式の会話を担うモデルの代わりにはなりません。

その役割は、アプリケーションロジックと生成AIの間にあります。

成熟したエージェントは、複数の種類の知能を同時に活用できます。

意思決定レイヤー
→ 選択

推論レイヤー
→ 解決

生成レイヤー
→ 作成

ポリシーレイヤー
→ 承認

ツールレイヤー
→ 実行

Jevから得られるより大きな教訓は、チャットモデルが時代遅れになったということではありません。それは、本来は言語生成の問題ではなかった多くのタスクで、チャットが標準のインターフェースになっているということです。