はじめに

これは Jev を触って調べる全4回の第2回です。前回は、Jev が文章ではなく Choice、Score、Noul という型付きの値を返し、コードから扱いやすそうだと分かりました。

しかし、型に合った応答が来ることと、現実の問い合わせを正しく理解することは別です。confidence が高ければ自動処理してよいのか。こちらの選択肢や観測軸の設計が入力とうまく噛み合わないとき、何が起きるのか。少し意地悪な入力で確かめました。

曖昧ならconfidenceは下がる、と予想しました

明確な checkout outage、曖昧な「ときどき壊れている気がする」文章、情報不足の文章を各1回ずつ送りました。人間の感覚では、曖昧なら Choice の probability が割れ、confidence も下がりそうです。

同じ Choice と Score を使い、入力だけを変えました。何が曖昧で、何が欠けているかを先に見てください。

明確:
"The checkout page returns a 500 error for every payment attempt.
 No workaround exists. Please investigate today."

曖昧:
"After the update, checkout sometimes feels broken, but some users
 complete payment after trying again. Please advise."

情報不足:
"Customers mentioned a checkout concern. We do not yet know the error,
 affected users, impact, or whether a workaround exists."

ところが、曖昧なケースも Choice は bug probability 1.00、confidence 1.00 でした。情報不足では Score confidence が 0.69 まで下がりましたが、Choice は bug 0.97 でした。少なくとも今回の3ケースでは、confidence は文章の曖昧さをそのまま示すメーターではありませんでした。

                 Choice             Choice confidence   Score / Score confidence
明確             bug: 1.00          1.00                2.99 / 0.99
曖昧             bug: 1.00          1.00                1.99 / 0.99
情報不足         bug: 0.97          0.97                0.31 / 0.69
                 other: 0.03

矛盾した impact を入れると、Score confidence は 0.00 になりました。一方で Choice は bug 0.94 でした。曖昧、taxonomy境界、矛盾、security reportの4 stateを各10回反復すると、selected Choice は変わりませんでしたが、矛盾入力の Score と確率には範囲がありました。4 state・40回だけで一般的な決定性は言えません。それでも confidence を一律の自動実行許可として読むのは無理がありそうです。

入力:
"Payments are completely blocked for all customers. However, every customer
 can complete payment normally. Please treat this as urgent."

出力:
  Choice: bug 0.94 (confidence: 0.93)
  Score probabilities: 0=0.31 / 1=0.03 / 2=0.03 / 3=0.63
  Score: 1.97 (confidence: 0.00)
  urgent: 0.98

「Zero Hallucinations」は何を保証しているのか

第1回で触れた「Zero Hallucinations」を、ここで今回の実験と照らします。これは TypeSafe の公式サイトにある表現です。公式サイトはその見出しの近くで、Jevの各判断にはconfidenceがあると概括的に説明しています。launch articleも、Jevは structured output に最適化され hallucinate しないと述べています。ただし現行APIでは、separate confidence fieldがあるのはChoiceとScoreで、Noulはyesのprobabilityだけを返します。Noulの公式説明

重要なのは、launch articleの「Hallucination and Type-safety」節の注記です。TypeSafeは、Jevの0%という数値は empirical な測定値ではなく、schema matching が guaranteed であるためプロットに0%を置ける、と説明しています。つまり、この主張で扱っている中心は、定義された schema から外れる値を生成しないことです。TypeSafeはChoiceについて、与えた候補集合の外の文字列を返さないと説明しています。

これは強い性質ですが、Zero Errors と読み替えることはできません。hallucinationという語の一般的な正しい定義をここで決めるのではなく、「TypeSafeがこの主張でhallucinationと呼んでいるもの」と「今回確認した意味的な適合」を分けます。

次のsecurity reportは、その差を具体的に見せます。

otherがあれば、さすがにそこへ行くでしょうか

security reportを、bug、feature_request、how_to、billing、otherの五択へ入れました。私は当初、securityはどの説明にも当てはまらず、otherを選ぶだろうと予想しました。

入力:
"I found a potential SQL injection vulnerability in the search endpoint.
 I have not exploited it. Please investigate promptly."

Choice options:
  bug / feature_request / how_to / billing / other

当初の予想:
  securityは4つの業務カテゴリに属さないためother

このsecurity reportではbug 0.66、other 0.34で、選ばれたのはbugでした。さらにotherを除くとbug 1.00、confidence 1.00でした。型としては完全に正しいresponseです。

other あり:
  bug:   0.66
  other: 0.34
  selected: bug       confidence: 0.58

other なし:
  bug: 1.00
  selected: bug       confidence: 1.00

ここで、当初の「securityならotherが唯一の正解」という予想を見直す必要がありました。実験で使ったbugのcriteriaは「製品の振る舞いが失敗または不正確」です。SQL injectionの報告は、この意味でbugにも入り得ます。問題はJevが誤った文字列を返したことではなく、アプリケーション側が「securityとしてreviewへ送りたい」という用途と、issue typeという排他的Choiceの意味空間を一致させていなかったことです。

この二つの応答は、TypeSafeの「Zero Hallucinations」という主張への反証ではありません。どちらも与えたschema / 型への適合性を満たしています。schemaへの適合性、schema設計そのものの妥当性、アプリケーション設計者が期待した振り分けは別です。otherを外したケースも、high confidenceだけで未観測のsecurity relevanceを人手確認へ送れるわけではない例です。

選択肢の作り方も、プログラムの一部でした

では、選択肢を直せばどうなるのでしょうか。ここで初めて taxonomy という言葉を使います。本記事では、Choice の候補集合と各候補の criteria を合わせたものを taxonomy と呼びます。

既存18件へ四つの条件を当てました。baselineは12/18、bugとfeature requestの説明だけを具体化した条件も12/18でした。security labelを追加した条件と、両方を加えた条件は18/18でした。ただしbaselineのsecurity 6件の期待ラベルはother、security labelありの条件ではsecurityと、こちらがtaxonomyに合わせて定義し直しています。したがってこれは、今回定義した期待ラベルへの一致率が変わった観測です。脆弱性をbugと扱うtaxonomyより、securityを独立labelにするtaxonomyが一般に正しいことは示していません。

同じ18件への4条件

A 既存の候補・criteria                    12 / 18
B bug / feature_requestのcriteriaのみ具体化  12 / 18
C securityという候補を追加                18 / 18
D criteria具体化 + security追加             18 / 18

other と none_of_the_above も20件で比べました。taxonomy内5件と feature request境界5件はどちらでも期待通りでした。しかし securityの5件は、どちらの schema でも2/5しか reject されず、3/5は bug でした。reject用の選択肢を置くだけで自動検出できるとは考えにくそうです。

一度に複数の質問をするとどうなるか

高confidenceな同一checkout stateにtarget質問だけ、関連Noulを2問追加、無関係Noulを8問追加した各5回で、target出力の差を観測しませんでした。これはquestion independenceの証明ではなく、1 state・15回の限定観測です。今回の実行環境で、1、4、8、16 questionを一requestへまとめたp50は約234、241、226、230 msでした。16件を逐次送った合計p50は約3.65秒です。独立した意味判断をまとめて取る使い方には、今回の条件では実用上の魅力がありそうです。

calibrationは今回どこまで確認できたか

TypeSafeはcalibrated probabilitiesを公式に説明しています。Brier Scoreは確率予測と実際の結果のずれを二乗誤差で見る指標、ECEは予測確率と実際の正答率のずれを見る指標で、いずれも小さいほどよい値です。今回の64件のテンプレート化データでは、Choiceの「選ばれたtop optionのprobability」とその選択の正誤から、Brier Score 0.0968、5-bin ECE 0.0730を計算しました。3種類のNoul、計192予測をまとめた参考値はBrier Score 0.0065、ECE 0.0458です。ただしNoulは3種類の質問をまとめた値なので、質問ごとのcalibrationの差はこの値からは分かりません。しかし、同じ規則からground truthを作った小規模synthetic datasetです。これだけでJevが一般にcalibratedであることは確認できません。確かめられたのは、このデータ上で確率と正解ラベルの関係を診断できたことまでです。

日本語ではどうだったか

日英20 pairでは Choice は19 pairで一致し、Scoreの平均絶対差は0.115、urgency Noulの平均絶対差は0.0105でした。ただし請求書ダウンロードの1 pairは billing と how_to に割れました。日本語性能を一般化できる結果ではありませんが、候補の境界は翻訳対でも揺れ得ます。

英語: "Where can I download invoices?"
  selected: billing    confidence: 0.47

日本語: 「請求書はどこからダウンロードできますか。」
  selected: how_to     confidence: 0.39

TypeSafeはChoiceについて、定義した候補集合の中から回答し、schema matchingを保証すると説明しています。しかし、候補集合や質問の設計がアプリケーションに必要な観測軸と合わなければ、高confidenceでも望む振り分けにはなりません。confidence thresholdだけを置けば安全、とは言えません。質問設計、taxonomy coverage、意味的な観測値、決定的な判定ルール、人手確認を組み合わせて設計する必要がありそうです。一方、複数の小さな判断をまとめて取れる性質は面白そうです。では、最終判断までJevに任せず、意味判断だけを取り出して普通のコードと組み合わせたらどうなるでしょうか。次回は実際に小さなPoCを通します。

検証条件: 保存済みAPI応答の取得日は2026年9月17日JSTです。Python 3.13.14、typesafe-sdk 0.6.0、requested modelはjev-latest、returned modelはjev-1.13.0でした。Early Access中のため、後日のmodel aliasやAPIの挙動が同じであることは保証されません。

前回: TypeSafe AIの「Jev」を触ってみた。文章を生成しないAIは何ができるのか
次回は、「Jevをアプリに組み込んでみる。AIの意味判断と業務ルールを分ける」です。お楽しみに。