Jeff v1.1で英文問い合わせを担当分けする——Jev互換の小型モデルを使う前に

Jeffは、文章と候補を受け取り、候補ごとの確率を返すオープンウェイトのモデル群です。2026年9月30日朝の確認では、Qwen版がv1.1になり、一つの問いで扱える候補が26から254へ増えました。本記事では更新点と利用条件を整理し、英文問い合わせを人が確認する前の担当案に変える方法を考えます。編集部ではモデルを実行していません。確認したのは公式資料・コードと、末尾の模擬応答を使う教材です。

Jeffの初版は9月28日付で公開されました。今回取り上げる更新は、公式v1.1リリースの公開時刻で日本時間9月30日3時28分53秒です。0.8B版の新しい重みも、その直前に配布履歴へ追加されています。新着投稿の日を、そのまま初公開日とは扱いません。

v1.1の対象はJeff-Qwen3.5-0.8Bと2Bです。初版では候補が多いと27番目以降を選べない問題が報告され、候補数を増やした学習で修正されました。Gemma版は初版のまま、上限26候補です。254はQwen版の受付上限であり、「254部署に必ず正しく振り分ける」という保証ではありません。

ここでいう互換は、Jevと似たAPIの要求形式で呼べるという意味です。JeffはTypeSafeとは別の開発者による独立プロジェクトで、Jev本体の公開版ではありません。同じ候補と文章を送っても、判断や確率が一致するとは限りません。型付きの判断を業務に入れる考え方は、Jevの基礎記事でも整理しています。

公式モデルカードは言語を英語とし、v1.1の注意事項も英語・テキストのみと明記しています。土台のモデルが多言語を扱えても、Jeffとして日本語の業務分類が検証されたことにはなりません。今回は英文の受信文を対象にします。日本語を自動翻訳して渡す場合も、翻訳と分類の両方を別々に確認する必要があります。

重みの容量は、必要な作業メモリや導入後のディスク総量と同じではありません。WindowsやLinuxを含む全環境の動作保証表は確認できないため、CPU向け手順があることから「あらゆるPCで導入できる」とは言えません。必要なバージョンは固定版の構成ファイルを参照してください。

実際のモデル導入は公式Quick startに沿って進めます。外部から依存パッケージと重みを取得する工程と、その後に手元で問い合わせを分類する工程は分けて考えます。後述の教材だけなら、モデルの取得もAPIキーも不要です。

例として、架空のショップに届く問い合わせを、支払い・配送・ログイン・要確認の四つに分けます。返金の承認や顧客への返信は対象にしません。最初に小さくするのはモデルの大きさだけでなく、任せる仕事の範囲です。

たとえば「二重請求された」は支払い担当の候補になります。一方で「荷物が壊れていたので返金してほしい」は配送と支払いにまたがります。どちらかを無理に正解にする前に、会社としてどちらが一次対応するのかを決める必要があります。教材では、このような複数担当の案件を要確認へ戻すルールにしました。

次は架空の英文を分類する要求例です。候補の短い番号と、役割を説明する英文を分けています。これは入力例で、実行して得た結果ではありません。 要求の項目は公式サーバー実装に合わせています。

「要確認」もモデルが選ぶ一候補なので、それだけでは取りこぼしを防げません。導入初期は全件を人が読み、担当案だけを画面に付けます。人が直した案件は、本文・候補の説明・モデルの版を残して次の検証に回します。顧客の実データを試験資料に流用せず、まず架空例で手順をそろえましょう。

Jeffのchoice応答には、候補ごとのprobabilitiesと別のconfidenceがあります。v1.1の計算コードでは、候補が2つ以上の場合、候補数をn、最大確率をpとしたとき、後者は(p - 1/n) / (1 - 1/n)です。四候補の最大確率が0.8ならconfidenceは約0.733です。二つの値を取り違えて受け取り条件を書くと、意図した振り分けになりません。

確率校正の改善が報告されていても、手元の問い合わせ一件が正しいことを保証する数値ではありません。候補の説明が重複している、商品特有の言い回しがある、文章に条件が抜けている、といった場面は別途確認が必要です。単一のconfidenceだけで返金やアカウント変更を実行しない設計にします。

導入時には、正しい担当を選んだ数に加え、「担当が複数ある案件を要確認へ戻せたか」「情報不足を勝手に補わなかったか」を分けて記録します。四候補で確認を始め、候補を増やしたら同じ問い合わせを再確認します。254候補を使えることと、細かな分類規則が整っていることは別の条件です。

検証コード、架空の英文6件、模擬応答6件、教材の説明を同じフォルダに保存します。Pythonの標準ライブラリだけで動き、通信・モデル実行・ファイルの書き換えは行いません。

検査するのは、候補番号が四つそろっていること、確率が有限の数で合計がほぼ1になること、選ばれた候補と最大確率が一致すること、confidenceが公式の計算方法と合うことです。不正な応答は失敗として終了します。形式が正しくても、本文を理解して正しく分類したかどうかは、このコードには判定できません。

編集部では、正常な二つの模擬応答と、未知の候補・確率合計のずれ・confidenceの取り違え・非有限値を含む四つの模擬応答について、想定どおりに受理または拒否されることを確認しました。6件の検査が通ったことは、Jeffが問い合わせ6件に正答したという意味ではありません。

架空例のexpected_routeは、人が先に決めた教材用の期待分類です。実際に試す際は、この答えをモデルに渡さず、requestだけを入力します。明確な案件と要確認案件を分けて照合し、結果・処理時間・実行環境・重みの版を記録します。Ollayaの記事にも、同じ問題を固定して比較する際の考え方を掲載しています。

作者の速度表では、0.8B版はRTX PRO 6000で22ms、Apple M4 MaxのMLXで28msです。約200入力トークンの200問を一問ずつ処理した中央値であり、初回の重み読み込みや、日本語の長文、254候補の業務分類の速度を保証していません。Jevの比較値とも環境・通信条件が異なります。

またv1.1では、作者の五つの評価をまとめた2B版の成績が83.1%から82.0%へ下がりました。長い候補リストへの対応が改善しても、すべての評価が良くなったわけではありません。Jev側の数字は別サンプルの公開値で、同条件の直接対決としては読めません。リリースの変更点も、この低下を明記しています。

最初の検収は「英文を読んだ人が、担当案を役立つと判断できるか」です。速度だけを先に合格条件にせず、誤った担当案が増えないか、要確認へ戻す案件が適切かを確認します。ここまで決めてから、実際の受信箱との接続や、自社用データでの調整を検討すると、試す範囲と結果の意味がはっきりします。