LLMはすべてのif文を置き換えるのか。Jevの判断APIを考える

問い合わせを読めても、処理はまだ決まらない

「二重に請求されています。先月は使っていません。もう解約したい」。この問い合わせを読めば、請求の相談と解約の希望が含まれていることは分かる。しかし、担当部署への振り分け、請求記録の照合、返金の可否、返信の作成は、それぞれ違う仕事である。以下は、この分担を考えるための想定例であり、Jevの導入実績ではない。

すべてを一度に生成LLMへ頼むと、柔軟な説明と業務の実行が同じ回答に混ざる。逆に、単語の一致だけで振り分けると、否定や複数の用件を取りこぼす。欲しいのは、自然言語の曖昧さを読み取り、その結果を既知の処理へ渡せる接点だ。ここに、TypeSafe AIが9月15日に発表した判断モデルJevを見る意味がある。

本稿の判断は、Jevがすべてのif文を置き換えるというものではない。意味を読む部分を確率付きの判断として切り出せれば、規則を実行するコードと、文章を作るLLMの役割を分けやすくなる。ただし、型に合う値が返ることと、その値で仕事を進めてよいことは、別に確かめる必要がある。

新しさは「学習不要の分類」だけでは説明できない

分類器は以前から、この接点を担ってきた。BERTの論文では、文章の表現に分類層を加え、正解ラベルを使って追加学習する方法を示している。分類体系が安定し、十分なラベル付きデータがあるなら、このような専用の分類器は比較に残すべきだ。Jevの登場だけで、既存の方法が不要になるわけではない。

追加学習なしに、ラベルの説明から文章を分類する考え方も新発明ではない。Yinらのゼロショット分類研究は、話題、感情、状況の異なる分類を、文章とラベルの関係を判定する問題として扱った。業務ごとの学習データを見ない設定も評価している。「学習せずに使える」という説明だけでは、Jev固有の価値は分からない。

Jevについて注目したいのは、呼び出す側が質問と候補を渡し、通常のプログラムで扱える判断を受け取る設計である。分類ラベルが案件ごとに変わる仕事では、固定の分類器を作り直す負担を減らせる可能性がある。一方で、候補の定義や入力の整備が不要になるわけではない。手間がどこへ移るのかまで比較して、採用を決めたい。

生成LLMも、決められた型で答えられる

型のある回答は、Jevだけの能力でもない。OpenAIのStructured Outputsは、開発者が指定したJSON Schemaに合わせて生成結果を制約する。ただし、拒否や生成の途中終了には別の扱いが必要で、型に合う値の中にも誤りは残り得ると説明している。形式が整うことと、内容の正しさを混同してはいけない。

TypeSafeは、Jevが文章を生成せず、限定された判断を並列に返す設計だと説明している。ここから考えられる価値は、長い返答を後から解析する工程を減らせることだ。ただし、生成LLMにも型を制約した呼び出しを用意すれば、似た接続は作れる。比較すべきなのは接続できるかどうかに加え、同じ仕事をどの精度、時間、費用で終えられるかである。

Jevが用件を読み、コードが請求記録を照合し、生成LLMが確認済みの結果から返信を作る。冒頭の問い合わせなら、このような分担が考えられる。説明文を作る能力が必要な場所では生成LLMを残し、判断だけが必要な場所でJevを比較する。使うモデルを一つに統一することより、必要な出力を決めることが先だ。

三つの出力は、違う質問に答える

公開されたSDKのAPI定義には、Choice、Noul、Scoreの回答がある。どれも数値を含むが、意味は同じではない。冒頭の問い合わせに当てはめると、次の違いが見える。

例えば「緊急度2」という同じ平均でも、中程度に確率が集まる場合と、低い段階と高い段階に割れる場合では、確認したい内容が違う。これは出力の読み方を示す例であり、Jevの実測結果ではない。数値が一つあるから判断が明確になるのではなく、何を数値にしたかが明確である必要がある。

質問の定義では、指示や候補の説明を呼び出し側が指定する。「請求」の範囲に解約相談を含めるか、緊急度を何で区別するかは、業務側の設計だ。モデルへの質問を作る作業は、曖昧だった処理条件を言葉にする作業でもある。

確率の集中と、実際の正答率を分ける

ChoiceとScoreにはconfidenceもあるが、それを業務全体の正解確率として読むのは危険だ。例えば、比較用の公式LLMアダプターの実装は、Choiceの確率が一つにどれだけ集中しているかを、一様な分布を基準に計算する。候補が三つで確率が0.8、0.1、0.1なら、この実装のconfidenceは0.7になる。これは計算例であり、Jevサーバーの出力を測定した値ではない。

一方、Guoらが扱う較正は、予測確率と実際の正答率の対応である。0.8程度と予測した案件を集めたとき、およそ8割が正しかったかを確かめる。単独の問い合わせに0.8が付いても、その一件の正しさを保証する証明にはならない。較正の確認にも十分な件数と、業務に合う正解が必要だ。

さらに、用件の分類が正しくても、返金条件が満たされているとは限らない。請求記録が古い、正しい用件が候補にない、担当者に実行権限がない、といった失敗は別に残る。出力確率、確率の集中、業務結果の正しさを分けて記録すれば、誤りが起きたときに直す対象を見つけやすくなる。

質問を分けても、入力と候補の責任は残る

TypeSafeの開発ガイドは、既知の規則、計算、正確な検索、実行をコードに残し、意味の判断を質問として切り出す分担を勧める。また、同じ呼び出しの質問は独立に評価され、互いの回答を読むわけではないと説明している。並列に答えられることは、必要な確認の順番を省けることではない。

「解約を希望しているか」と「請求への不満があるか」は同じ文章から別々に聞ける。しかし、請求記録を取得してからでないと判定できない条件は、先に取得する必要がある。前の判断結果が次の入力を変えるなら、コードで結果を受け、状態を更新してから次の呼び出しへ進む。

候補の漏れも重要だ。「請求」と「技術相談」しか渡さなければ、そこにない用件を正しく選べない。「その他」や判定を保留する経路を設計し、必要な情報が欠けた状態も試すべきだ。細かく分解しただけで頑健になるのではなく、それぞれの質問に必要な証拠と、回答の使い道を合わせることで改善を狙う。

判断APIを、実行可能な処理へ接続する

想定例を処理へ戻すと、まず問い合わせと必要な記録を集め、Jevで用件と解約希望を判定する。次にコードで顧客と請求の対応、契約の状態、定義済みの条件を確認する。情報不足なら確認待ちへ送る。実行できる処理が決まってから、生成LLMにその結果を使った返信案を作らせる。返金という言葉を読み取っただけで、返金処理を走らせる設計にはしない。

この接続には、判断の誤り以外の失敗もある。SDKの呼び出し仕様は、接続や時間切れ、APIの失敗、回答形式の検証失敗を区別している。アプリケーション側でも、必要な回答がそろったか、どのモデルで判定したかを確認し、失敗時に実行を進めない処理を用意する必要がある。

人の仕事も変わる。問い合わせをすべて読み直すのか、不確かな案件だけ確認するのかで、負担は違う。保留の理由と入力の根拠が分かれば担当者は判断しやすいが、数値だけ渡されると再調査が必要になる。自動化の価値は、APIの呼び出しが速いことに加え、確認と修正を含む仕事が軽くなることで測りたい。

ベンダーの比較は、何を正解にしたかまで読む

Jevの発表は、同じ処理手順で各モデルを比較し、高性能な外部モデルの予測を平均して参照確率に使う評価を説明している。これは、決められた手順にモデルを組み込む比較として興味深い。一方、その参照は人が独立に確定した業務の正解とは異なるため、実際の問い合わせの処理成功率とは読めない。

発表には、開発チームが評価を作ったことによる偏り、短く情報密度の高い入力による実演の有利さ、米国西海岸からの速度測定も記されている。これらは隠すべき注記ではなく、結果を自分の環境へ移せるかを判断する条件だ。長い日本語の問い合わせや、記録取得を含む処理でも同じ優位があるかは、別に確かめる必要がある。

比較用のLLMアダプターには、確率を返す方式と、離散的な回答だけを返す方式がある。確率を求める比較と、用件ラベル一つだけを求める比較では、時間や費用の条件が変わる。Jevの性能を過大にも過小にも評価しないために、必要な出力、入力、再試行、接続条件を合わせたい。

自動で進める件数と、誤りを同時に評価する

導入を決めるなら、実際の業務から確認用の案件を用意し、候補と正解、情報不足で保留すべき条件を人が定義する。その一部で質問や閾値を調整し、残りで評価する。モデル名、質問文、候補、入力の作り方を固定し、日本語と英語、複数の用件、未知の用件で結果を分ける。平均の正答率だけでは、困る案件がどこに残るか分からない。

選択的分類の研究は、判断を保留できる分類器を、答えた案件での誤りと、答えた割合の関係で評価する。ここでは、その視点を自動処理へ応用したい。論文の保証をそのままJevに移すのではなく、自分の案件で「どれだけ進め、どれだけ誤るか」を測るのである。

例えば、1,000件中400件を自動で進め、そのうち4件で誤れば、自動処理率は40%、その範囲の誤り率は1%だ。厳しい条件で200件へ減らし、誤りが1件になれば20%と0.5%になる。これは比較方法を示す想定値である。後者がよいかは、誤りの影響と、残った案件を確認する人の時間で変わる。閾値を上げても高い確信を持つ誤りは残り得るため、誤りの内容も読む。

待ち時間は再試行や記録取得を含めて測り、平均だけでなく遅い案件も見る。費用も一回の推論価格に加え、人の確認、修正、再処理を含める。記録の取得や回答の欠落など、モデル以外の失敗を含む全案件を分母にすれば、判断モデルを導入した結果、仕事全体が改善したかを評価できる。

if文を減らす前に、何を判断させるかを決める

Jevは、自然言語を読む能力を文章生成から切り離し、ソフトウェアの判断に使う方向を示している。その価値が出やすいのは、候補を定義でき、意味の読み取りに手書きの規則が追いつかず、保留した案件を別の経路で扱える仕事だ。安定した分類なら専用分類器、説明の作成なら生成LLMという比較は引き続き必要になる。

冒頭の問い合わせで減らしたいのは、「二重」という語があれば請求担当へ送る、といった脆い判定である。請求記録が確認できたか、定義済みの条件を満たすか、実行に必要な確認が済んだか、という分岐は残す。そこを明示してこそ、判断が外れても原因を追い、処理を修正できる。

判断APIを採用する理由は、AIへ任せる範囲を広げること自体にはない。曖昧な意味を扱う部分を改善しながら、人とコードが確かめるべき条件を見える形に保ち、処理の誤りと修正負担を減らせるか。その問いに答えられたとき、Jevは新しいモデルの紹介を超えて、業務を変える選択肢になる。