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

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

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

1時間に1回だけ処理される問い合わせ窓口

　私の会社の問い合わせ窓口は、現在、Claude Codeの「Routine」機能で運用しています。Routineは、指定した時刻にClaude Codeのクラウド環境でエージェントを自動起動する機能です。問い合わせが届くとSlackに投稿される仕組みは既に用意してあり、Routineはその投稿を毎日7時から20時まで1時間置きに確認し、単なる営業目的のものは自動でアーカイブします。

　連載の第1回で、問い合わせフォームに届くメッセージの9割は事業と関係のない売り込みだと書いたのですが、このように、売り込みを振り分ける作業はめでたく私の手を離れています。ただし夜間は動かしていないため、20時の最終処理後に届いた問い合わせは、翌朝まで処理されません。深夜に熱心な営業メールを送ってくださる方には申し訳ないです。

　先日、この窓口と同じ判定処理を、TypeSafe AIが公開した判断専用モデル「Jev」で試してみました。すると結果は一瞬で返ってきました。一方、同じ判定処理をそのままClaude Code経由でAnthropicの小型モデル「Haiku」に依頼すると、約40秒かかります。

　ただし、これは同一条件での比較ではありません。どちらの実験でも、Slackへのアクセスや外部ツールの呼び出しは行わず、純粋な判定のみを依頼しています。Claude Code側はコンテナの起動処理から始まるため、40秒の大部分はその起動時間に費やされていると考えられます。

　しかし、私の会社としては、この40秒のレイテンシで実務上の問題が生じるわけではありません。1時間に1回のみ同期する窓口において、応答が一瞬で返るか40秒かかるかの違いはほとんどありません。では、この応答速度の差が問題となるのはどのようなケースなのでしょうか。

文章ではなく、確率を返すJev

　さて、このJevを開発したのはTypeSafe AIという企業です。CEO（最高経営責任者）のディオゴ・アルメイダ（Diogo Almeida）氏は、InstructGPTに関する論文の著者20人の1人でもあります。このInstructGPTは、OpenAIが2022年に発表した技術で、人間のフィードバックを使った強化学習（RLHF）によって、GPT-3が指示通りの文章を書けるように鍛えたものです。OpenAIは、ChatGPTをInstructGPTの姉妹モデルと位置付けています。

　つまり、言語モデルに指示通りの文章を生成させる研究に携わった研究者が、今度は文章を出力しないモデルを開発したのです。この点だけでも、既に興味深い事実ではないでしょうか。

　また、「TypeSafe」という社名は、出力結果がプログラムのコードで直接扱われるため、「typesafe（型安全）」だということから来ているそうです。Jevの説明には「System One Models」というフレーズが出てくるのですが、これは『ファスト＆スロー』という書籍でも紹介されている直感的かつ高速な「システム1」から来ており、思考過程を文章にせず即座に判定結果だけを返すJevの在り方を表しています。

　現在の多くの生成AIが行う文章応答には、3つの課題があります。第1に「表記の揺れ」が生じ、第2に境界線の判断でも単一解答しか得られず「確信度が欠如」し、第3に理由まで生成させると「コストが増加」します。

　「Structured Outputs」などの型指定を用いれば表記揺れは防げますが、確信度を扱う枠組みがないため、あとの2つの課題は解消できません。

　Jevに入力するデータはシンプルです。判断の材料となるテキストやJSONなどの「state」と、型が定義された問いの2つのみを指定します。例えば問い合わせの分類であれば、本文をstateに渡し、あらかじめ定義した選択肢（「営業」「研修・講演の依頼」「取材」「既存のお客様」など）から選ばせる「Choice」形式の問いを渡します。

　Jevからの返答は、この3つの課題を解決します。まず、返される答え（choice）は型定義に従った固定値であるため、表記のブレが生じません。次に、全ての選択肢に対する確率（probabilities）と、その分布の偏りを0から1の範囲で数値化した確信度（confidence）が提示され、判断の確からしさが可視化されます。さらに、判断理由などの余計な文章を出力しないため、応答のトークン長が膨らみません。例えば、営業と研修依頼の境界線にあるような問い合わせに対しても、「判定：営業（確率：営業 0.62、研修・講演依頼 0.31、取材 0.05、既存のお客さま 0.02）」といった明確なデータ構造で応答を得られます。

確率はずっとモデルの中にあった

　Jevは全く新しいアイデアというわけではありません。生成AIが登場する以前から、スパム判定や問い合わせの分類といった用途では、専用の分類器が確率値を算出するのが一般的でした。

　私がGoogleにいた頃、「NavSuggest」という機能の開発に少し携わったことがあります。ユーザーが特定のWebサイトを訪問しようとするものの正確なドメイン名が分からない場合、検索窓で検索を行うことがあります。例えば、私の会社「Tably」では設立時に少し珍しいドメインを選択し、「rocks」というTLDを用いて「tably.rocks」をドメイン名に決定しました。会社自体の認知度も発展途上ですが、仮に社名を知っていたとしても、ブラウザのアドレスバーに直接「tably.rocks」と入力してアクセスできる方は極めて稀でしょう。こうした場面で役立つのがNavSuggestです。

　NavSuggestは、Googleの検索窓やChromeのアドレスバーに文字列が数文字入力された時点で、検索候補とともにアクセス先のURLを予測表示する機能です。この仕組みは、入力テキストを目的地となるサイトの選択肢へと割り振る分類器と考えてもらっていいでしょう。

　LLMの内部にも確率の概念は存在します。文章を生成する際、LLMは次に続く単語の候補に対してそれぞれの確率を算出した上で、1つの単語を選択しています。OpenAIのAPIでは、対応するモデルにおいて「logprobs」オプションを指定することで、出力されたトークンの対数確率を取得できます。ただし、分類に使うにはラベルとトークンの対応付けが要ります。なお、GPT-3の時代には分類機能に特化した「Classifications」エンドポイントも提供されていました。

　しかし、調べた限りでは、現在において確率を直接活用する手法は主流から外れつつある印象を受けます。チャットAPIは文章応答を基本設計とし、確率の出力は補助的な位置付けに後退しました。その結果、判定処理も「文章で出力させて解釈する」アプローチが定着しています。それでも、確率の取得だけで十分に完結するシステムは決して少なくありません。

　Jevは、汎用性を保ったまま確率値を返すという原点を示すことで、その重要性を再認識させてくれたものと言えるでしょう。

新しいのは仕組みではなく、データかもしれない