Jevとは？文章を書かないAIを、業務のどこで使うのか

AIに長い回答を作ってほしいわけではない。「この依頼は誰に回すか」「この処理を人に確認してもらうか」を、一つずつ判断してほしい。

そんな用途に的を絞ったAIが、TypeSafe AIの「Jev」です。同社は2026年9月15日、System Oneモデルと呼ぶ新しいモデル群と、その最初の公開モデルとしてJevの早期アクセスを発表しました。

続いて9月17日にはLangChainがJevを使ったモデルの振り分けやツール実行前のリスク判定の実装例を公開。9月21日には、LangSmithの評価機能への統合も発表されました。発表を眺める段階から、実際の開発環境に組み込む動きが進んでいます。

本質が注目しているのは、AIに任せる仕事の切り分け方です。Jevを使うなら、何を一つの「判断」として渡すのか。そこを、業務の例で考えます。

Jevが返すのは、文章ではなく判断の結果

TypeSafe AIは、Jevの入出力をこう表現しています。

“unstructured state in, typed probabilistic decisions out.”

当社訳：「形式の決まっていない情報を受け取り、型の決まった、確率を伴う判断を返す。」出典は同社の発表記事です。

たとえば、メールの本文と「障害」「操作質問」「追加開発」「要確認」という選択肢を渡し、どれに当たるかを返してもらう。理由を長文で説明してもらう使い方とは異なります。

公式ドキュメントでは、出力を三つに分けています。

• Choice：用意した選択肢から選ぶ。
• Score：言葉で定義した段階に沿って評価する。
• Noul：ある命題が成り立つ確率を、0〜1で返す。

ChoiceとScoreでは確率分布やconfidenceも返ります。一方、自由な文章やコード、判断理由の説明を生成するモデルではありません。返信文まで必要なら、別の生成モデルなどと組み合わせることになります。

保守窓口なら、「振り分け」の手前を見直す

ここからは、本質が考える活用例です。当社でJevを導入・検証した実績の紹介ではありません。

システムの保守窓口に、「今朝から帳票が出ません。ついでに、集計項目も追加できますか」という連絡が来たとします。

これを先ほどの四択にそのまま押し込むと、障害か追加開発かのどちらかが落ちます。現実の依頼は、分類表の都合に合わせて書かれていません。

そこで、先に問いを分けます。「現在の機能が使えないという申告を含むか」「機能追加の依頼を含むか」。それぞれを判断させ、両方なら二つの対応に分ける。どの担当へ渡すかは、契約や担当表を参照するコード側で決めます。

文章の意味を読み取る判断はJev。ルールとして定義できる契約条件や、金額・期限の照合はコード。相手に送る返信文の下書きはLLM。

これは今回の業務例で私たちが検討したい構成です。既存のLLMでも分類はできますから、Jevに置き換えるだけで良くなるとは限りません。

同じ依頼文を両方に渡し、分類の間違い、処理時間、費用を比べる。その際は、通常の依頼だけでなく、複数の用件が混ざるもの、情報が足りないもの、人に戻すべきものを含めたいところです。

「要確認」を選べるようにしておくことも大切です。confidenceの値だけで自動処理の可否を決めず、誤分類したときの影響も含めて、人に渡す条件を決めます。公式説明でも、確率の校正は予測の集まりについての性質であり、個々の回答の正しさを保証するものではないとされています。

「速い」「安い」「ハルシネーションゼロ」をどう読むか

TypeSafe AIは、特定のワークフローを使った自社評価で大幅な速度・費用の改善を報告しています。ただし、同じ倍率が自社の業務でも出るという意味ではありません。呼び出し回数や入力の長さ、人が確認し直す手間まで含めて比べる必要があります。

また、同社のいう「ハルシネーションゼロ」は、指定された出力形式を守るという文脈の主張です。「障害」か「追加開発」かの判断を一度も間違えない、という保証ではありません。 形式が崩れないことと、業務上の正解を選ぶことは別に確かめます。

日本企業が試すなら、言語の条件も見逃せません。現行モデルの説明では、Jevは英語で最も精度が高く、日本語を含む他言語が同等とはされていません。自社の用語や略語が入った日本語の依頼で、どこまで使えるかを見る必要があります。

さらに、Jev 1.13の既知の弱点には、数値計算、数え上げ、日時の比較などが挙げられています。先ほどの例で期限や金額をコードに任せたのは、このためです。依頼文に書かれた指示だけで、権限や承認の仕組みを飛ばせないようにする設計も必要です。

FDEが設計する「一つの判断」

Jevを調べていて、私たちが改めて考えたのは、業務を知るエンジニアの役割でした。

選択肢に抜けはないか。一つの依頼に二つの仕事が混ざっていないか。自動で進めてよい範囲はどこまでか。間違えた場合、誰が気づいて修正できるか。

こうした問いは、モデルを呼び出すコードを書く前に、現場とすり合わせたいことです。

SES・SIerでFDE（Forward Deployed Engineer）を育てるなら、既存業務の中から判断を一つ選び、入力、選択肢、人に戻す条件まで設計する演習にできます。Jevは、その設計を具体的に考える題材になると見ています。

※本記事は2026年9月22日時点の公式発表・ドキュメントに基づきます。製品情報と本質の活用案を分けて記載しています。