Jeffyで問い合わせ分類を自分の例から作る。学習用36文と別の12文で確かめる

Jeffyは2026年10月3日にPyPIへ配布された jeffy-classify を使って試せます。今回固定した版は 0.1.0a9 です。名前が似ているJeffとは別のプロジェクトで、Jevのように、選択肢や判断基準を渡せば未学習の仕事もその場で扱う製品として読むと、使い方を誤ります。公式リポジトリ・今回使った配布版

この記事では、独自に作った架空の英語36文から3分類を学習させ、別に残した12文を確認する手順を扱います。日本語の分類品質は検証していません。公開されている性能表を、今回の問い合わせ業務での精度として使うこともしていません。

公式配布には、銀行への問い合わせの意図、SMSの迷惑メッセージ判定、ニュースの話題など、13種類の学習済み分類器があります。ただし、使う用途は利用者が指定します。「今日は請求書の緊急度、明日は契約書の危険性」と説明だけを差し替えて使う方式ではありません。公式も、未学習の汎用分類や、対象外の仕事を別の大きなAIへ回す機能は含まないと説明しています。対応範囲

仕組みは、既存の英語モデル BAAI/bge-large-en-v1.5 で文章をEmbeddingへ変換し、ロジスティック回帰で分類ごとの値を計算する構成です。自分のデータで学習するのは、この分類部分です。文章を読む大きなモデル全体を、36文で最初から作り直すわけではありません。固定版の学習コード

JevやJeffとの違いを詳しく比較したい場合は、判断モデルと実行ツールの整理も参照できます。今回は製品同士の勝敗ではなく、正解例を自分で管理できる仕事で、分類器をどう検収するかを中心にします。

教材では、海外向けの架空の小さな通販窓口を想定しました。次の3つを学習対象とし、英語の文章をそれぞれ12文、計36文用意しています。実在する顧客の問い合わせは使っていません。教材ZIPには文章とラベルを収めています。

次に、学習に使わない検収用の文を作ります。今回は各分類3文の明確な9件に加え、複数の相談を含む文、情報が足りない文、採用への問い合わせを1件ずつ、計12件にしました。検収側では後半3件を human_review としていますが、これは人が決めた期待条件で、モデルへ教えた4番目の分類ではありません。

例えば「二重請求を直し、届かない荷物の場所も教えてほしい」という文は、請求と配送の両方を含みます。単一の分類を返す仕組みなら、片方を選んでも、もう一方の相談が残ります。このような例を先に入れると、返り値が正常なだけで自動化が完成したと判断することを避けられます。

学習文と検収文は、実行前に内容と照合値を固定しました。同じ文章の混入はありません。ただし、どちらも編集部が作った小さな架空教材です。現実の顧客の言い回し、分布、誤字、長さを代表する独立したデータセットではありません。

Jeffy本体の今回の配布ファイルは約1.61MBですが、推論には別のモデルが必要です。今回取得した文章モデルの重みは約1.34GBでした。「小さなPythonパッケージだから、ダウンロードも数MBで済む」とは考えない方がよいでしょう。必要なメモリについて公式は約2GBを目安にしていますが、端末での余裕や処理時間は別に確認します。モデル配布と条件

教材を展開し、最初に次だけを実行します。これはPython標準ライブラリによる教材検査で、Jeffyのインストールもモデルの取得も行いません。

学習36件、検収12件の数、ID、入力の照合値、文章の完全一致が混ざっていないことを検査します。この PASS は教材の形式が整っているという意味で、分類精度の評価ではありません。結果を見ずに手順だけ確かめたい人は、ここまででも教材を読めます。

実際の学習まで試す場合は、READMEの手順で専用の仮想環境を作り、固定したJeffyと依存ライブラリを入れ、公式モデルを取得します。この準備段階には外部通信とディスク容量が必要です。有料APIの契約やAPIキーは使いません。モデル取得後、次のように新しい出力フォルダを指定します。

教材スクリプトは学習・推論時に外部接続を使わず、既存のローカル重みを使います。公式の学習関数にはモデルの版を指定する引数がないため、教材では参照先だけを固定済みローカルモデルへ切り替えました。分類器の学習方法や重みを都合よく変更していません。再実行では別の出力フォルダを指定し、前の結果を上書きしない構成です。

2026年10月4日07:14 JST、Apple M2 Ultra・メモリ192GiB・macOS 27.0で、CPUを4スレッドに指定して実行しました。Python 3.12.10の専用環境を使い、モデル取得後はOS側でもネットワーク接続を拒否しています。学習は1回、検収文の推論も各1回です。結果を見て文章や設定を調整してから取り直すことはしていません。

明確な9件は、人が先に決めた分類と9件とも一致しました。ただし、これらは学習文に近い言い換えです。「請求の例を学んだ後、似た請求の文を分けられた」という小試験の結果であり、実務で100%正しくなるという意味ではありません。

一方、人の確認が必要な3件には、次のようにいずれかの分類が返りました。

後半3件は、人へ戻す仕組みが付いたことを示していません。学習した3分類の外に答えを出せず、採用の相談まで請求へ振り分けています。モデルが文章を読めたことと、仕事としてその返り値を採用できることを分けて考える必要があります。未修正の全出力と集計を教材に同梱しました。

今回の学習では、公式の train_classifier を使い、C=0.01 としました。検収文は最初から別ファイルにあるため、学習関数内での再分割と内部評価は無効にし、学習36件と検収12件を分けています。学習文を当てた成績を、未知の文への精度として数えていません。

Jeffyの今回の学習済みオブジェクトが返す confidence は、分類器が出した確率の最大値です。3つのどれを強く選んだかは読めますが、その値だけで「現実にもその割合で正しい」とは言えません。公式も、確率は校正されていないと記載しています。返り値の実装

例えば、採用の問い合わせも、今回の分類器にとっては3つのどれかを選ぶ入力です。請求・配送・ログインのどこにも適さないことを、ラベル一覧だけから表現する余地がありません。値が低いときだけ人へ戻す仕組みを作る場合も、実際の業務データで境界を調べる必要があります。本記事では、自動処理の閾値は設定していません。

確率校正を調べたいなら、検収文を十分に増やし、確率の帯ごとに誤りがどのくらいあるかを見ます。混在した依頼や対象外の依頼も含め、分類できた件数と、人が読み直すべき件数を別に集計します。今回の少数例から全社共通の閾値を作ることはできません。

この数値を、JevやJeffが返す同名の値とそのまま交換することもできません。APIの項目名が同じでも、計算方法や学習データ、選択肢が違えば、同じ数値の意味はそろわないためです。比較するときは、同じ入力と判定基準を用意するところから始めます。

Jeffyのコードと、今回使った英語の文章モデルはMITライセンスです。一方、付属する13種類の分類器は、それぞれ異なる公開データから学習されています。コードのライセンスだけを見て、すべての分類器をどの用途にも同じ条件で使えるとは判断しません。コードのLICENSE・出所と利用条件の記録

公式の詳細記録には、表示や継承の条件があるもの、学術・研究用途の文言があるもの、明示ライセンスが不明なものが並びます。元データの条件が、配布している数値パラメータへどう適用されるか未解決とした項目もあります。READMEの短い表だけで商用利用の可否を一括判定せず、使う分類器ごとに出所へ戻る必要があります。

今回は付属の分類器を読み込まず、編集部が作った架空の英語だけで新しい分類器を作りました。教材にも第三者の分類器や重みは同梱していません。自社で試す際は、文章を用意する権限、含まれる情報、ラベルの定義を確認し、使ったデータの版を残します。

Jeffyの共有モデルは英語向けです。日本語を入力できることと、日本語の意味を業務に十分な品質で分類できることは別です。まず海外からの英語問い合わせなど対象が明確な仕事で、例を作る手間と、人が直す手間を測る。少数の正解例を増やしてよい結果が出ても、使っていない検収文を残して確認する。この順序が、この道具を選ぶ判断材料になります。