問い合わせを「請求」「技術」「購入相談」に振り分けるだけなのに、大きなAIに毎回長い文章を書かせる必要はあるでしょうか。Labqoatのqev-0.8bは、用意した選択肢の確率を返す小型の判断モデルです。Apple Silicon Mac向けの配布物を手元で動かし、日本語と英語の架空問い合わせを12件ずつ試しました。
公式資料は、学習データが主に英語の業務・運用・エージェントログで、他言語を評価していないと明記しています。今回の小規模な試用でも、日本語の請求書の相談を別の分類にし、その選択肢へ91.05%の確率を割り当てました。少数の成功例や高い確率だけで、無人の処理に移さないでください。
確認日は2026年10月21日です。モデルはLabqoatの配布物に限定しています。記事後半に、入力・事前の正解ラベル・実行コード・出力記録を載せました。日本語対応を保証するベンチマークではなく、導入前に確認すべき失敗を見つける試用です。公式の限界の説明
何が新しい? 0.8Bの判断モデルをMacに持ってくる
公式リポジトリの履歴では、初回リリースのコミットは2026年10月20日08:48 UTC(日本時間17:48)です。同日13:56 UTCにはゲーム・ルール・空間課題に関する重みの更新もあります。これは取得できた公開履歴の時刻で、非公開から公開へ切り替わった正確な時刻を証明するものではありません。記事作成時点で、重みと実行コードを認証なしで取得できました。公開履歴
0.8Bは約8億のパラメーターを表します。Qwen3.5-0.8B-Baseを追加学習したモデルで、自由な回答文を続けて生成する代わりに、与えられた質問と候補を読み、候補ごとの値を返します。小さなモデルを、文章を書く大きなモデルの手前に置く構成が考えられます。モデルの説明
| 項目 | 今回確認した内容 |
|---|---|
| 配布形式 | NVIDIA向けのPyTorch/CUDA、Apple Silicon向けMLX、llama.cpp向けGGUF |
| Macで使った形式 | MLXの8ビット版(q8)。重みファイルは799,974,390バイト、約0.80GB |
| ライセンス・費用 | Apache-2.0の重みとコードを利用。今回のローカル推論にAPI利用料は発生していない。端末・電力・初回取得は必要 |
| OSの扱い | 今回試したのはApple Silicon Mac。Windows/LinuxやIntel Macでの動作は未検証 |
| 出力 | choice(選択)、noul(はい/いいえ)、score(順序のある尺度) |
| 言語 | 公式カードの言語タグは英語。他言語の品質を保証する記載はない |
MLXはApple Silicon上でモデルを動かす実行基盤です。この試用はMLXを使っており、AppleのNeural Engineで動いたと確認したものではありません。また、ローカル推論とWeb上のデモは別です。デモに入力すると運営側へ送信されます。今回の問い合わせはすべて架空で、ローカルの重みから推論しました。Mac向け配布物
同じ「Qev」「QEV」でも、配布元まで確かめる
今回扱う識別子は labqoat/qev-0.8b です。検索するとAustinFu/Qev-0.8Bやtwainsk/qev-0.8bなど、別の配布元のモデルも出てきます。さらにQueryPie AIも、Gemma 4を基盤に機密情報の検知へ特化した「QEV」を10月19日に発表しています。これらの導入手順・評価値・日本語の説明を、Labqoat版へそのまま転用してはいけません。QueryPie AIの公式発表
Jev系の道具を比較する際も、名前とサイズだけでは不十分です。配布元/モデルID/重みの版/実行コード/量子化の条件をセットで記録すると、前回と何を変えたかを追えます。既存のJev・Laya・Jeff・Micaの比較に対し、本稿は新しく公開されたLabqoat版を日本語の振り分けに使う検証です。
文章を書くAIと、選択肢を選ぶAIの役割を分ける
| 種類 | 返すもの | 業務での試し方 |
|---|---|---|
| choice | 候補の選択と各候補の確率 | 請求・技術・営業・人が確認、の担当候補を出す |
| noul | 「はい」に相当する確率 | 契約更新の相談が含まれるかを一次選別する |
| score | 順序付きの段階に対する分布と期待値 | 優先度の仮順位を付ける。公式はこの形式が弱いと注意している |
入力には「state」と「questions」があります。stateには問い合わせ本文などの判断材料を、questionsには判断基準と候補を置きます。出力に自然な説明文はありません。理由が必要なら、入力の根拠と判断結果を人に見せるか、別の生成モデルで説明を作り、その説明が根拠に沿っているかを確認します。出力仕様
使いやすい入口は、既存の人の振り分けと並行して動かすことです。AIの分類はログにだけ残し、チケットの実際の担当変更や返信、返金は実行しません。担当者が確定した分類と比べれば、速度だけでなく、どの種類の相談をどの担当へ誤って送るのかが分かります。
実測:日本語11/12件、英語12/12件が事前ラベルと一致
Apple M2 Ultra、ユニファイドメモリ192GiB、Python 3.12の環境で、MLX 0.32.4、mlx-lm 0.32.2、decider-ai 1.9.0を使用しました。MLX配布物の版は 799c195002ff81181e124c6ecda0ab18558da97d、q8の重み、既定のjoint形式・compile有効・prefix cacheなしです。初回取得を済ませ、ローカルディレクトリを指定し、Hugging Faceのオフライン設定を有効にして実行しました。通信パケットの監査はしていません。
同じ意味の問い合わせ12組を日英で用意し、正解ラベルを実行前に固定しました。分類の指示文と候補の説明は両言語で共通の英語です。したがって「すべて日本語で指示した条件」との比較ではありません。請求・技術・営業の明確な相談8組と、情報不足、複数部署の相談、無関係な挨拶、分類を誘導する文を含む4組を試しました。
| 区分 | 日本語 | 英語 |
|---|---|---|
| 明確な相談8件 | 7/8件一致 | 8/8件一致 |
| 境界例4件 | 4/4件一致 | 4/4件一致 |
| 合計 | 11/12件一致 | 12/12件一致 |
| 推論時間の中央値 | 30.65ms | 30.60ms |
時間は各問い合わせについてPythonからdecideを呼び、結果が返るまでの実測です。モデル読込約11.75秒と、別の英文1件によるウォームアップ約2.45秒は中央値に含めていません。形の異なる入力で起こる追加コンパイルの影響などは分離していません。MLXが報告したピーク割当量は約1.14GBでしたが、これはPythonやOSを含む端末全体のメモリ使用量ではありません。
この24件は独立した24種類の実業務データではなく、12組の翻訳対です。正解ラベルは編集部が決めたものです。小さな確認用データでの一致件数から、日本語全般の正解率や、本番で削減できる工数は推定できません。
失敗例:請求書の宛名変更を「人が確認」に寄せた
| 入力/指標 | 結果 |
|---|---|
| 日本語の入力 | 請求書の宛名を株式会社サンプルに変更したいです。 |
| 事前の期待分類 | billing:請求・請求書関連 |
| モデルが選んだ分類 | review:情報不足・対象外・複数部署など、人の確認 |
| reviewに割り当てた確率 | 0.9105(91.05%) |
| billingに割り当てた確率 | 0.0119(1.19%) |
| 同じ意味の英語入力 | billingを選び、事前ラベルと一致 |
reviewに戻したため、この運用案なら誤った返金が実行されるわけではありません。しかし、請求担当に回せる相談が人の再確認待ちになり、期待した省力化が減ります。この1例では、最大確率が高いことと、事前の分類基準に合うことが一致しませんでした。
公式仕様のconfidenceも、正解する確率そのものではありません。choiceでは、最大の選択確率を「すべての候補が同確率なら0」になるよう調整した指標です。この例のconfidenceは0.8807、最大確率を表すx_p_maxは0.9105でした。名前が似ていても、そのまま「88%正しい」と読まないことが大切です。各フィールドの定義
実務では「最大確率が0.9以上なら自動処理」のような値を最初から正解として扱わず、実際の問い合わせと人の正解を集め、誤振り分けと確認待ちの両方を数えます。今回の分類誘導文を含む1組が通ったことも、プロンプトインジェクション対策として十分だという証拠にはなりません。
公式ベンチマークの「速い」「首位」は条件付きで読む
公式カードはBenchmark Heavenの公開231問で77.1%、L40Sでの1リクエストの中央値3.5msなどを掲載しています。ただし、一部の比較対象は実行エラーを一様な推測として採点し、VRAMは重み+0.5GBの見積もりです。また、すべての評価軸で首位という説明でもありません。本稿のMacでの24件とは、機材・入力・評価方法が違います。公式評価と注記
ゲームのデモも、画面を見て先を何手も探索しているとは限りません。公式説明では、各移動の結果をゲーム側のコードがstateへ書き、モデルが選びます。業務で使う際も、アプリ側で分かる契約状態・期限・金額などを明示する設計が重要です。ただし、機密情報を必要以上に加えず、判断に使う項目を限定します。
Apple Silicon Macで再現する手順
以下は今回と同じ配布版と8ビット重みを使う確認手順です。初回はインターネット接続と空き容量が必要です。モデル本体だけで約0.80GBあり、依存ライブラリや一時ファイルも増えるため、数GB以上の余裕を用意してください。既存のPython環境を変えないよう、専用の仮想環境に入れます。
mkdir qev-trialcd qev-trialpython3 -m venv .venvsource .venv/bin/activatepython -m pip install mlx==0.32.4 mlx-lm==0.32.2 tokenizers decider-ai==1.9.0 huggingface_hub次の3ファイルを同じqev-trialフォルダーに保存してください。モデル取得用スクリプト、実測用スクリプト、事前ラベル付き24件です。モデル取得用スクリプトは固定した公式リポジトリからq8のファイルとqev_mlx.pyだけを取得します。取得した実行コードを確認してから実行してください。
python download_model.pyHF_HUB_OFFLINE=1 TOKENIZERS_PARALLELISM=false python run_trial.pyrun_trial.pyは各入力の分類・期待ラベルとの一致・処理時間を表示し、trial-results.jsonへ保存します。チケットの送信、実際の顧客データの読込、担当変更、返金などは行いません。空の質問を渡したときにValueErrorになる検査も含みます。今回の検証では、正常な推論とこの入力エラーの両方を確認しました。
from qev_mlx import QEVMLX
model = QEVMLX.load("model-q8")answer = model.decide( {"ticket": "二重請求の返金をお願いします。"}, {"team": { "type": "choice", "instructions": "Which team should handle the actual request?", "criteria": { "billing": "Charges, refunds and invoices", "technical": "Application errors", "review": "Unclear or unrelated request" } }})print(answer)この最小例は、24件の試用より候補を少なくした説明用です。候補と指示を変えると確率も変わるので、上の91.05%と一致することは期待しないでください。日本語での導入を判断するときは、まず配布した共通条件を使い、その後、分類基準を変更した試行を別の記録に残します。
最初の導入は「担当候補を提案する」まで
- 1実際の業務から匿名化した短い問い合わせを集め、人が担当と「判断不能」を決める。今回の架空24件は動作確認用に使う。
- 2誤振り分けが困る種類、複数部署が必要な種類、人が確認すべき種類を分けて件数を見る。
- 3モデルの出力を保存し、人の運用と並行して比較する。最初は返信・返金・権限変更へ接続しない。
- 4閾値を調整したデータとは別の新しいデータで再確認する。モデル・指示文・候補の版も残す。
小さな判断モデルの価値は、単にチャットAIより速いことではなく、繰り返し行う狭い判断を、評価可能な形で取り出せることにあります。今回の試用では多くの短文を分類できましたが、日本語の請求書相談に失敗しました。その失敗を発見できる手順ごと導入するのが、qevを業務へ持ち込むための出発点です。
実測の原データは結果JSONに、実行環境の依存関係はバージョン一覧に保存しています。同系統の日本語検証としてJiwoの日英20件、Herbertの日本語試用も参照できます。テスト条件が異なるので、これらの数値をそのまま順位表にはできません。