「判断に文章は不要」 Jevという確率を返すモデルへの回帰：及川卓也からエージェント時代の開発者たちへ（13）（2/2 ページ）

2026年9月に登場した「Jev」は、文章を出さずに判定結果と確率だけを返す手法で注目を集めました。もともとシステム処理に文章は必須でなく、確率で足りる場面も多いため、Jevは原点回帰と言えます。今回は、Jevの返す情報や回帰の意味、有効な活用場面について、私の会社の問い合わせ窓口を例に考えます。

[及川卓也，Tably株式会社]

　ここまで読んで、Jevの新しさは文章を返さない仕組みにあると思った方もいるかもしれません。

　既に説明したように、文章を生成せずに結果や確率のみを返す手法自体は、決して新しいものではありません。しかし、業務専用の分類器を運用するには、あらかじめ数百〜数千件規模のデータを用意して手作業でラベル付け（「営業」「研修依頼」など）を行う必要があり、分類項目の変更に合わせて再学習が必要になる点も課題でした。

　業務ごとの学習なしで使える手法として、候補ラベルごとの確率を返却する「ゼロショット分類」モデルも存在していました。これらと比較した際のJevの革新性は、型定義された問いに対して汎用LLMと同等レベルの高度な文脈理解力を維持しつつ、選択肢ごとの確率分布を直接返せる点にあります。

　Jevのリリース直後、AIエージェント「Devin」の開発元であるCognitionのエンジニアリング担当バイスプレジデント、ジャレッド・パルマ―（Jared Palmer）氏が、そのアプローチを再現したオープンソースプロジェクト「Kev」を公開しました。Kevは「Qwen」をベースにしており、文章トークンを一切生成せずに各選択肢の確率を算出します。テキストを出力せず「読むだけ」で判断を下す手法は、こうしたアーキテクチャでも実現可能です。

　GitHub Copilotの初期開発に携わり、「Prompt Engineering for LLMs」の共著者でもあるArcturus Labs創業者のジョン・ベリーマン（John Berryman）氏は、9月21日の記事で、OpenAIが、いずれJevの機能を複製するか自社モデルに取り込んでくるだろうと予測しました。この予測は8日後に的中します。9月29日（米国時間）、OpenAIは開発者向けイベント「DevDay 2026」で、あらかじめ定めた問いと選択肢に対して確信度付きの答えを返す「Decisions API」を発表しました。

　ベリーマン氏は9月21日の記事で、TypeSafeの本当の競争優位性はアーキテクチャそのものではなく、学習に用いる「データ設計」にあると指摘しています。

　実際、TypeSafeも自社の学習データが全て合成データであることを認めています。 具体的な作成方法や適用工程までは明かしていないものの、「現実のデータは偏りが大き過ぎるため、ユーザーのデータで学習させたくない」と語っています。

　かつて私が関わっていた「NavSuggest」を振り返ってみても、その独自の強みを築いていたのはシステム的な仕掛けそのものにとどまりません。「どのような検索語句を入力したユーザーが、最終的にどのWebサイトへと遷移したか」という膨大な行動ログデータこそが本質的な優位性の源泉でした。単に候補となるURLを提示する仕組み自体は追従できるかもしれませんが、その背後にある圧倒的なデータ資産は、Google以外の追随を許さなかったのです。

　この観点から捉え直すと、前述した私の会社の「tably.rocks」というサイトは、本来NavSuggestの対象にはなり得ません。なぜなら、検索を経て実際にサイトへアクセスする絶対的なユーザー数が極めて少なく、NavSuggestを機能させるために不可欠な規模のデータが蓄積されないためです。

　Jevにおけるデータの価値は、出力される確率の信頼性（精度）に直結します。提示した確率通りに的中させる調整は「較正（キャリブレーション）」と呼ばれますが、同社の真の強みはそれを支える高精度な合成データの生成ノウハウにあると考えられます。もっとも、これは外から見た私の推測にすぎません。

ルールでは書けなかった判断へ

　それでは、自社の問い合わせ窓口の自動化処理をJevへ移行すべきでしょうか。結論から言えば、現時点ではその必要性を感じていません。冒頭で書いた通り、1時間に1回の運用なら40秒でも支障はありません。また、受信件数自体が多くなく、営業目的か否かの判別さえできれば十分なため、確率値を検証して手動対応へ回すといった運用も不要だからです。

　TypeSafeの公式サイトでは「238倍安価」という数値が強調されているので、上司から「238倍安いなら、うちも乗り換えるのか」と聞かれるかもしれません。ただしこれは、割引非適用時の入力単価をAnthropicの最上位モデル「Fable 5.1」と比べた数字で、小型モデルの「Haiku 4.5」と比べれば約24倍です。比較対象によって見かけ上の倍率は大きく変わります。私の会社の窓口のように件数が少なければ、この差は乗り換えの理由になりません。

　分類モデルの運用経験がある方には馴染み深い概念ですが、推論には大きく2つの形式が存在します。1つは「バッチ推論」で、蓄積されたデータを一括処理する手法です。定時にまとめて問い合わせを処理する自社の窓口も、この形態に該当します。もう一つは「オンライン推論」で、リクエストが発生する都度、即座に判定を返す手法です。ユーザーが画面越しに応答を待つ対話的機能（例えばNavSuggestなど）では、入力の変化に応じて即座に候補を更新する必要があるため、この即時性が不可欠となります。

　Jevの活用事例としてまず想定されるのは、従来人間が担当していた判断業務の代替です。コールセンターにおける問い合わせの一次振り分けなどは処理件数が膨大であるため、導入効果の高い領域と言えます。しかし、これは初期段階の適用事例に過ぎないと捉えています。

　本来、Jevが真価を発揮するのは、プロダクトの内部処理への組み込みです。具体的には、明確なルール定義が難しく、従来は人間やLLMの判断に依存せざるを得なかったものの、テキスト形式の出力では確信度が取得できず、推論理由まで出力させるとレイテンシとコストが著しく増大するため、高頻度かつ細かい単位での実行が困難であった判断タスクです。

　私の知人の@mizchi氏が開発した「jev-lint」は、この活用例を的確に示しています。同ツールのコンセプトには「to decide what a parser cannot」（パーサーでは判定不可能な要素を判定する）と掲げられています。例えば、コードコメントと実装内容の整合性や、テスト名と検証内容の一致といった検証です。これらは構文解析（AST）のみで判別することが困難なため、従来はコードレビューやLLM（大規模言語モデル）による解析に依存していました。GitHub Copilotなどによるpush契機の自動レビュー機能も存在しますが、jev-lintは特定の検証観点のみを抽出し、極めて低コストかつ高頻度に実行可能にした仕組みと言えます。実際に2ファイル／6箇所の指摘を行う処理が、わずか0.1セント程度のコストで完了したと報告されています。

　こうしたプロダクトは、必ずしも大規模なサービスである必要はなく、個人運用のツールであっても十分に有効です。日常的に使用し、大量のデータを処理し、かつ即座の応答が求められる環境こそが、Jevの最も適した適用領域（スイートスポット）であると考えられます。

　日頃利用しているツールや業務プロセスの中で、明確なルール化が困難という理由から、目視による確認や限定的なLLM呼び出しに委ねている判断処理には、どのようなものが存在するでしょうか。それこそが、Jev的アプローチの出番なのでしょう。