Jevは、ソフトウェアのための判断レイヤーとして理解するのが最も適切です。テキストや構造化された状態を読み取り、あらかじめ定義された分類、スコア、イエスかノーかの確率を返します。ユーザー向けの回答文は書きません。この限定されたインターフェースにより、AIエージェント内の大量のルーティング、トリアージ、検証、ガードレールのステップに適しています。
実践的なパターンはシンプルです。頻繁に行われ、取り消し可能な判断はJevに任せます。方針の適用はビジネスロジックのコードに任せます。不確実な場合や結果が重大な場合は、高性能なLLMか人間にエスカレーションします。
Jevを初めて知る方への最も短い説明は次のとおりです。Jevは、TypeSafe AIが新たに公開したAI判断モデルで、チャットボットというよりは意味的なif文に近い動作をします。文脈と固定された質問のセットを与えると、アプリケーションコードがすぐに使える、型付きの選択肢、スコア、確率を返します。
Jevとは何か？
TypeSafe AIは、Jevを同社初の「システム1モデル」と呼んでいます。System 1/System 2の区別における「速い」側を借用した呼び方です。リクエストでは、プログラムの状態と型付きの質問を与えます。Jevは質問を並列に評価し、ソフトウェアがそのまま利用できる確率と信頼度の値を返します。
利用可能な質問の種類は次のとおりです。
Noulは、イエスかノーかの文が真である確率を返します。Choiceは、あらかじめ定義された選択肢から1つを選びます。確率分布と信頼度を返します。Scoreは、順序付けられたレベルを評価します。スコア、基礎となる分布、信頼度を返します。
Jevは、自己回帰型のLLMと違い、任意の文字列を生成しません。TypeSafeによると、これによりスキーマへの適合が保証されるとのことです。つまり、応答がフィールドを捏造したり、誤ったデータ型を返したりすることはありません。ただし、誤った有効な回答を選ぶことはあり得ます。型安全性を、意味的な無謬性として提示してはなりません。
Jevはエージェントのアーキテクチャのどこに位置づけられるか？
システムが制約付きの判断を必要とする、状態変更の間でJevを使用します。
User or tool result
-> Jev: classify, score, route, or check risk
-> application policy
-> execute a low-risk action
-> call an LLM for reasoning or language
-> request human review
これはLLMを補完するものです。LLMは、自由形式の推論、説明、生成されるコンテンツを担当します。Jevは、取りうる答えがあらかじめ分かっている、繰り返し発生する質問を担当します。
作業ごとに適切なレイヤーを選ぶ
Jevは、より大きな自動化スタックの一構成要素として捉えるのが最も分かりやすいです。
| レイヤー | 最適な用途 |
|---|---|
| Jev | 繰り返し行われる分類、スコアリング、ルーティング、リスクチェック |
| LLM | 複雑な推論、説明、テキスト生成 |
| アプリケーションコード | 決定論的なルール、権限、実行 |
| 人間のレビュー担当者 | リスクが高い、曖昧、または例外的なケース |
この役割分担こそがJevの製品思想です。モデルがすべてを判断する必要はなく、すべてを説明する必要もありません。あいまいな意味的文脈を、型付けされた確率的シグナルに変換します。方針の適用と実行については、周囲のシステムが引き続き責任を負います。
ステップ1：適切な最初のワークフローを選ぶ
すでにLLMと構造化出力を使っている、既存の大量の判断から始めます。適した候補には、サポートチケットのルーティング、コンテンツ品質チェック、エージェントのトレースのレビュー、ドキュメントのトリアージ、モデル選択などがあります。
取り消しできない判断、法的に機微な判断、または遅延やコストよりも最大限の精度が重要な判断から始めるのは避けてください。また、自然言語による出力や、監査可能な説明を必要とするタスクも避けてください。Jevは判断と確率を返すのであって、推論の説明文を返すわけではありません。
ステップ2：状態と質問を定義する
判断に必要な根拠を状態に含めますが、方針はアプリケーションコードに残してください。可能な限り、広範なリクエストを互いに独立した質問に分解してください。
サポートのワークフローであれば、1つのリクエストで次のような質問ができます。
- チケットをどのキューに振り分けるべきか？
- 問題の重大度はどの程度か？
- メッセージに不正利用の兆候があるか？
- 人間によるレビューが必要か？
選択肢の一覧が実際のすべてのケースを網羅しきれない可能性がある場合は、unknownやnone_of_the_aboveを追加してください。逃げ道がないと、閉じた分類器は有効でも誤解を招きかねないラベルを選ばざるを得なくなります。
ステップ3：LangChain経由でJevを呼び出す
統合機能をインストールし、環境変数またはシークレットマネージャーを通じてAPIキーを指定します。
pip install langchain-typesafe
export TYPESAFE_API_KEY="your-api-key"
次に、型付きの質問を作成します。
from langchain_typesafe import Noul, TypeSafeClassifier
classifier = TypeSafeClassifier()
response = classifier.invoke(
state=(
"The deploy failed twice and customers are seeing 500s. "
"Can someone look now?"
),
questions={
"urgent": Noul(
instructions="Does this need attention right now?"
),
},
)
urgency = response.nouls["urgent"].noul
結果は確率であり、方針によってしきい値と比較できます。それ自体が実行すべき指示になるわけではありません。
ステップ4：エスカレーションの方針を構築する
単一の普遍的なカットオフ値の代わりに、複数の帯域を使用してください。
high confidence + low consequence -> automatic action
medium confidence -> LLM verification
low confidence -> human review
high consequence at any score -> stronger control or approval
しきい値は、アクションごとに設定してください。確率を使うからといって、ラベルの自動割り当てと支払いの自動承認に同じリスク方針を適用してはなりません。
ステップ5：ルーティングとガードレールを慎重に使う
LangChainの実験的なModelRouterMiddlewareは、Jevを使って、単純な作業は高速なモデルへ、複雑または重要度の高い作業はより高性能なモデルへ振り分けることができます。これにより、すべてのリクエストを最も安価な選択肢に通すことなく、フルモデルの利用を減らせる可能性があります。
実験的なAutoModeMiddlewareは、Jevをツール呼び出しのリスクチェックに適用し、提案された呼び出しを実行前にブロックできます。機微なツールの周囲では、決定論的な制御を維持してください。許可リスト、サンドボックス化、スコープ付きの認証情報、レート制限、人間による承認は引き続き必要です。分類器は偽陰性を出す可能性があるためです。
ステップ6：自社のデータで評価する
TypeSafeは、エンドツーエンドの遅延が70～500ミリ秒であり、入力トークン100万件あたり0.042ドルで、出力は計量されないと報告しています。4つのワークフロー評価において、Jevは参照確率との一致率が平均67.8%で、サンプル1件あたりの費用は約0.0004ドル、処理時間は0.4秒だったとしています。同じ試験環境では、GPT-5.6 Terraは67.9%で、費用は0.0304ドル、処理時間は10.1秒。GPT-5.6 Solは74.1%で、費用は0.0836ドル、処理時間は23.3秒だったと報告しています。
これらはベンダーが公表した結果であり、あらゆる状況に当てはまる予測ではありません。参照値は人間がラベル付けした正解ではなく、GPT-6 Astraと Fable 5.1の平均予測です。TypeSafeは、ワークフローの作成者によるバイアスの可能性に言及しており、最も大きな速度とコストの改善は、実際の改善の中でも上限に近い場合に得られる可能性が高いとしています。
本番運用の前に、可能な場合はJevを現在のLLM、単純なルール、ドメイン特化型モデルと比較してください。次の項目を測定します。
- クラスごとの正解率、適合率、再現率。
- キャリブレーションと、確信度が高いのに誤る割合。
- 判断保留とエスカレーションの割合。
- 自社のデプロイ先リージョンからのp50、p95、p99の遅延。
- フォールバックを含む、カスケード全体のエンドツーエンドのコスト。
- 分布のシフトや敵対的な入力下での性能。
ステップ7：運用上の安全対策を追加する
本番環境への対応には、モデルの品質以上のものが必要です。
- 状態のバージョン、質問のスキーマ、確率、信頼度、選択された分岐、後の結果をログに記録してください。
- プロンプトや質問の指示、判断のしきい値をバージョン管理してください。
- タイムアウト、上限付きの再試行、サーキットブレーカー、決定論的なフォールバックを追加してください。
- 確信度の高い誤りは別途レビューしてください。それらは自動化における最も危険な失敗だからです。
- ドリフトを監視し、入力の母集団が変化するにつれてしきい値を再キャリブレーションしてください。
- 取り消しできない、または規制対象のアクションは、より強力な技術的・人的管理の背後に置いてください。
現時点で公開されている資料では、Jevのパラメータ数、詳細なアーキテクチャ、RLCDの報酬設計、標準的なキャリブレーション曲線、本番環境のSLA、p95/p99のサービス遅延は開示されていません。これらの不明点は前提とせず、評価のための問いとして扱うべきです。
Jevを使うべきでないのはどのような場合か？
会話、要約、コード生成、詳細な説明、長期的な推論が必要な場合は、Jevを主要なモデルとして使わないでください。監査可能な根拠が求められる重大な判断プロセスにおいても、Jevを唯一の判断者とするのは適していません。固定されたドメインでは、従来の小規模な分類器や特化型のリランカーの方が、精度が高く、保有コストが低く、検証しやすい場合があります。
よくある質問
JevはLLMですか？
従来のチャットモデルという意味ではありません。テキストや構造化された状態を入力として受け取りますが、生成された散文ではなく、あらかじめ定義された判断の種類を返します。
「ハルシネーションなし」とは、Jevが間違えないということですか？
いいえ。出力の形式は保証できても、選ばれた答えが意味的に誤っている可能性はあります。この主張は、スキーマや型の誤りに対する保護として解釈してください。
Jevはエージェントを動かすモデルを置き換えるのですか？
通常はそうではありません。Jevは補完的な位置づけで考えるのが適切です。高速な構造化判断はJev、推論と言語処理はLLM、方針の適用はコードや人間が担います。
RLCDとは何ですか？
TypeSafeは、これを「Reinforcement Learning for Calibrated Decisions（キャリブレーション済み判断のための強化学習）」と展開しており、報告される確率を観測される正解率に合わせることを目的としています。公開されている情報源には、独立した技術監査を行えるほどの学習の詳細や、標準的なキャリブレーションの根拠はまだ十分に示されていません。
最初に何を試作すべきですか？
すでにLLMで処理している、取り消し可能で大量に発生する分類を1つ選んでください。Jevをシャドウモードで実行し、判断をラベル付きの結果と比較してください。しきい値とフォールバックが検証されてから、初めて自動化を導入してください。
測定可能な判断を1つから始める
Jevの最も強い提案は「すべてのLLMを置き換える」ことではありません。「すでに決まった形を持つ判断を生成するために、生成モデルに費用を払い続けるのをやめる」ことです。エージェントのハーネスで分岐を1つ選び、許容できる誤りとエスカレーションの方針を定義し、自社のトラフィックでテストしてください。
モデルに関する元の主張と留意点については、TypeSafe AIのSystem One ModelsとJevの紹介を、Pythonの統合とミドルウェアのパターンについては、LangChainのJevを使ったハーネス構築ガイドをご覧ください。
AIHubMixでJevの利用を始める
AIHubMixはJevのサポートを追加しました。開発者は、他の主要なAIモデルと並べて、この新しい判断モデルに1か所からアクセスできます。
AIHubMixにアクセスしてJevを試し、ワークフローの既知の分岐を1つ、測定可能な実験に変えてください。取り消し可能な分類またはスコアリングのタスクから始め、成功のしきい値を定義し、評価を進める間もLLMまたは人間のフォールバックを残しておいてください。
