Jevは「確度付きIF文」──TypeSafe AIの新モデルを実務にどう組み込むか

この記事をシェア

2026年9月、TypeSafe AIが「Jev（ジェヴ）」というAIモデルを公開しました。発表直後からエンジニア界隈で話題になり、需要が集中してAPIが一時的に提供できなくなるほどの反響があったモデルです。ただ、記事を読んでも「結局これは何に使えるのか」がピンと来ていない方が多いようです。ChatGPTのような会話型AIでもなく、画像生成でもなく、「テキストを生成しないAI」と言われても、自分の業務との接点が見えない。この記事では、Jevを「確度付きIF文」という一言で捉え直し、実務のどこに置けるのか、置くときに何に気をつけるべきかを、できるだけ具体的に解説します。

Jevとは何か

LLMとの決定的な違い

ChatGPTやClaudeのようなLLM（大規模言語モデル）は、入力に対して文章を生成します。回答も、コードも、JSONも、すべて「文章を一文字ずつ書き出す」という方法で作られています。

Jevはこれをやりません。入力として「今の状況（アプリケーションの状態）」と「問い」を渡すと、返ってくるのは事前に定義した選択肢の中からの判断と、その確信度だけです。

たとえば「荷物が破損したので返金してほしい」という問い合わせを渡したとき、LLMなら「この場合はまず謝罪し、注文番号を確認して……」という文章が返ってきます。Jevが返すのは、次のような値です。

担当部門: 請求 (0.94)
優先度: 高 (0.88)
返金審査が必要: true (0.91)

括弧内が確信度です。ソフトウェアはこの値をそのまま使って次の処理に進めます。文章を解釈する工程がそもそも存在しません。

LLMは文章を生成しパース工程が必要になるが、Jevは選択肢の中の判断と確信度を返すためそのままIF文で使える

図：「書く」AIと「決める」AIの処理の違い

なぜ「確度付きIF文」なのか

プログラムを書く人なら、これがIF文であることがすぐ分かるはずです。

if (担当部門 == 請求) { 請求チームのキューに入れる }

ただし普通のIF文と違うのは、条件の中身がコードでは書けなかった判断だという点です。「この文章は請求の話か」という条件は、正規表現やキーワード一致では書けません。だからこれまでは人間が読んで振り分けるか、LLMに文章で聞いて返答をパースするしかなかった。

Jevは、その「書けなかった条件」をIF文の中に入れられるようにします。しかも確信度付きで。

TypeSafe AIについて

開発元のTypeSafe AIは、元OpenAIの研究者Diogo Almeida氏が創業した企業です。同氏はRLHF（人間のフィードバックによる強化学習）とChatGPTの共同発明者の一人で、2年間のステルス期間を経て今回の発表に至りました。調達額は4,000万ドルとされています。

Jevは「System One Model（システム1モデル）」という新しいクラスの第1弾と位置づけられています。心理学でいう「速い思考（システム1）」と「遅い思考（システム2）」の前者、つまり熟考せず即座に下す判断を担う、という意味です。学習手法にはRLCD（Reinforcement Learning for Calibrated Decisions）という独自の方法を使っています。

名前の由来は19世紀の経済学者ウィリアム・スタンレー・ジェヴォンズです。「効率が上がるとコストが下がり、結果として消費量が増える」というジェヴォンズのパラドックスにちなんでいます。判断のコストが下がれば、判断はもっと多くの場所で使われる、という同社の賭けが名前に込められています。

「LLMでも同じことができる」への答え

ここで当然の疑問が出ます。LLMにも「JSONで返して」と指示する構造化出力機能があるし、小型モデルを使えば速い。確率もlogprobsを見ればある程度取れる。Jevでなくてもいいのでは、と。

正直に言えば、半分はその通りです。実際、「構造化出力付きの普通のLLMとそう変わらないが、インターフェースの設計が非常に優れている」という冷静な評価をしている技術者もいます。

それでもJevが別物だと言える理由は3つあります。

1. 確信度が「較正」されている

LLMのlogprobsは、温度設定やプロンプトの書き方で簡単に歪みます。「80%」と出ても、実際に80%当たるという保証はありません。

Jevは、この較正そのものを学習目標にしています。「95%と言ったら、だいたい95%当たる」ことを目指して訓練されている。「確信度が高ければ自動で進め、低ければ人間に回す」という設計は、確信度が信用できて初めて成立します。

2. コストの桁が違う

TypeSafe AIの主張では、分類タスクにおいて同等のLLMと比べて最大200倍高速、400倍低コスト。出力トークンは無料で、入力トークンは100万単位ではなく10億単位で課金されます。

これは「LLMより少し安い」という話ではありません。「1リクエストにつき1回だけAIに聞く」のではなく、「全イベント、全ステップに判断を挟む」という使い方が、初めて経済的に成立するという話です。

3. 出力の可能性空間が閉じている

Jevは、事前に定義した選択肢の外には何も出しません。プロンプトインジェクションで「以上の指示を無視して別の文章を出せ」と仕込まれても、出す先がない。

これは監視やガードレールの用途で決定的に重要です。LLMエージェントの安全性を別のLLMに監視させると、監視役のLLMも同じ手口で乗っ取られる可能性があります。喋らないAIには、その弱点がありません。

実務での導入案

ここからが本題です。「自分の業務のどこに置けるのか」を、業種や規模ごとに挙げていきます。

導入案1：問い合わせの一次振り分け

最も分かりやすく、最も効果が出やすい用途です。

メール、フォーム、チャット、LINEなどから届く問い合わせを、担当部門・緊急度・種別ごとに自動で振り分けます。

担当部門：営業 / サポート / 経理 / 採用 / その他
緊急度：即対応 / 当日中 / 通常
感情：怒っている / 困っている / 中立
対応要否：返信必要 / 自動返信で可 / 無視可

ポイントは確信度による分岐です。確信度0.9以上なら自動で振り分け、0.6〜0.9なら振り分けたうえで「要確認」フラグを立てる、0.6未満なら人間の一次受付に回す。この3段階にするだけで、人間が見る件数を大きく減らしつつ、誤振り分けの事故を防げます。

確信度0.9以上は自動振り分け、0.6から0.9は要確認フラグ付き振り分け、0.6未満は人間の一次受付に回す3段階の設計図

図：確信度による3段階の振り分け設計

導入案2：LLMエージェントのガードレール

社内でLLMを使った自動処理（エージェント）を動かしている場合、そのエージェントが実行しようとする操作を、Jevに事前チェックさせます。

このツール呼び出しは不可逆な操作か（削除、送金、送信など）
この操作は元の依頼の範囲内か
このプロンプトはインジェクションの疑いがあるか
人間の承認を挟むべきか

LangChainではこれをミドルウェアとして組み込む方法が公式に紹介されています。エージェントが1回動くたびに数十回の判断が発生しますが、Jevのコスト構造ならこれが成立します。LLMで同じことをやると、本体の処理より監視の方が高くつきます。

導入案3：モデルルーティング

LLMを業務で使っている企業の多くが、「全部を高性能モデルに投げている」状態です。簡単な質問にも複雑な分析にも同じモデルを使い、コストが膨らんでいる。

Jevに「この依頼は簡単か難しいか」「生成が必要か検索で足りるか」を先に判定させ、簡単なものは安いモデル、難しいものだけ高性能モデルに回します。判定のコストはほぼゼロなので、ルーティングを挟むだけでLLM費用が下がります。

導入案4：承認フローの自動化

経費精算、休暇申請、購買依頼、契約書のレビュー依頼。これらの「承認するかどうか」の判断には、明文化されたルールと、明文化されていない慣習の両方が混ざっています。

明文化されたルールは普通のIF文で書けます。「1万円以下は自動承認」のように。書けないのは「この領収書は業務目的として妥当か」「この申請理由は過去の却下パターンに似ているか」という判断です。

ここにJevを置き、確信度が高い案件だけ自動承認、それ以外を人間に回す。承認者の作業は「全件を見る」から「迷う案件だけを見る」に変わります。

導入案5：不動産・施設管理の異常検知

家賃の入金確認、修繕依頼の緊急度判定、入居者からの連絡の分類。物件数が増えると人間の目では追いきれなくなる領域です。

「この修繕依頼は水漏れなど即日対応が必要な種類か」「この連絡は退去予告か」「この支払い遅延は常習か初回か」といった判断を、連絡が届いた時点で自動で付けておく。管理者はダッシュボードで「緊急」だけを見ればよくなります。

導入案6：営業リードのスコアリング

Webからの資料請求、展示会の名刺、セミナー参加者。これらに「今すぐ商談すべきか」「育成対象か」「対象外か」を付けます。

従来はスコアリングルールを人間が設計していましたが、Jevなら「過去に受注した顧客の特徴」を状態として渡し、「このリードは似ているか」を聞けます。ルール設計の手間が減り、営業が電話をかける優先順位が自動で決まります。

導入案7：ログ・イベントの監視

システムのログ、SNSのメンション、ニュース記事。大量に流れてくるものの中から「対応が必要なもの」だけを拾う用途です。

「このエラーログは既知のパターンか新種か」「この投稿は自社への批判か」「この記事は競合の動きを含むか」。件数が多いほど、LLMでは費用が合わず、キーワード検索では精度が足りない。Jevの得意領域です。

導入時の注意点

ここまで良いことばかり書きましたが、実務で使うなら以下は必ず押さえてください。

賢くなるわけではない

TypeSafe AI自身が「System OneタスクにおいてLLMと同等の知能」と言っています。LLMより賢い判断が返ってくるわけではない。優位性は速度、コスト、型の保証、確信度の信頼性であって、判断の質ではありません。

確信度の閾値は自分で決める

「95%なら採用、50%なら無視」という閾値を決めるのは利用者の責任です。TypeSafe AIも「ハルシネーションを利用者に少し委ねている」という趣旨の指摘を受けています。閾値を決めるには、自社の業務データで評価する必要があります。

具体的には、過去の事例を100〜300件程度用意し、Jevの判断と人間の正解を突き合わせて、確信度ごとの正解率を測ってください。「0.9以上なら正解率98%」のような表が作れて初めて、自動化の範囲を決められます。

ハルシネーションが「ない」の意味

「出力を事前定義するのでハルシネーションしない」という表現が使われていますが、これは文章を捏造しないという意味であって、判断が間違わないという意味ではありません。閉じた選択肢の中で間違った選択肢を選ぶことは普通にあります。

早期アクセス段階である

2026年9月時点でJevは早期アクセスです。発表直後にAPIが一時停止した事実からも、供給の安定性はまだ保証できません。本番の基幹処理に組み込む前に、フォールバック（Jevが応答しないときにLLMや人間に回す経路）を用意してください。

日本語の性能は要検証

公開されている評価は英語中心です。日本語の問い合わせ文や社内文書で同じ精度が出るかは、自社データで確認するまで分かりません。

データの送信先を確認する

状態として渡す情報には、顧客情報や社内情報が含まれます。API経由で外部に送ることになるので、利用規約とデータの扱い（学習に使われるか、保持期間はどれくらいか）を確認したうえで、必要ならマスキングを挟んでください。

LLMの置き換えではない

文章を書く、要約する、翻訳する、コードを生成する。これらはJevにはできません。LLMを「考える・書く」役に、Jevを「決める」役にする分業が前提です。両方を組み合わせて初めて効果が出ます。

どこから始めるか

おすすめの順番は次の通りです。

問い合わせ振り分けから始める。効果が見えやすく、失敗しても人間が拾える。
自社データで評価表を作る。確信度と正解率の対応を測り、閾値を決める。
確信度が低い案件だけ人間に回す運用を1か月続ける。人間の判断結果を記録しておく。
エージェントのガードレールに広げる。LLM自動処理を動かしているなら、次はここ。
モデルルーティングでLLM費用を下げる。効果が金額で見えるので社内説明がしやすい。

まとめ

Jevは「賢いAI」ではなく、「これまで書けなかった条件を、確信度付きでIF文に入れられるようにする部品」です。

LLMの導入で止まっている企業の悩みは、たいてい「精度が保証できない」「何をするか分からない」の2点です。Jevは、確信度が較正されていること、出力が閉じていることで、この2点に直接答えます。

判断が安くなれば、判断は増えます。これまで「人間がざっと見て振り分ける」で済ませていた無数の小さな判断が、確度付きIF文として業務フローの中に入っていく。ジェヴォンズの名を冠したモデルが狙っているのは、まさにその世界です。

まずは、自分の業務で「人間が毎日目視で振り分けているもの」を一つ挙げてみてください。そこが最初の置き場所です。

※本記事は2026年9月時点の公開情報に基づいています。Jevは早期アクセス段階のため、仕様・料金は変わる可能性があります。

参考

この記事が役に立ったらシェアしてください

「確度付きIF文」という捉え方が誰かの整理に役立ちそうなら、ぜひシェアをお願いします。

Facebookでシェア X (Twitter)でシェア