問い合わせを経理へ回すか、情シスへ回すか。文章を生成するより、担当案だけを返してほしい仕事があります。に続き、、、などが登場しましたが、似た呼出形式で動くことと、同じ判断ができることは別です。
本記事は2026年9月30日の公式資料と実装に基づき、言語・送信先・機材・数値の意味を比較します。各開発元の速度表による順位は付けません。Layaの「約7.8倍高速」という紹介の確認範囲は、Layaの主張を検証する記事で扱います。
1. 判断するモデルと、動かす道具を分ける
Jev、Laya、Jeff、Micaは、文章と候補を渡して判断を求める対象です。候補選択のChoice、段階評価のScore、はい・いいえのNoulを返せます。一方、は公開モデルを取得して手元で動かすソフト、は開発作業に使うモデルを振り分けるソフトです。Ollaya単体の「日本語精度」を聞いても、どのモデルを動かしたかが分からなければ答えは定まりません。
| 名前 | 比較する際の役割 | 最初に確認すること |
|---|---|---|
| Jev | 提供元が運用する判断モデルをAPIで利用 | アカウント、入力の外部送信、従量料金 |
| Laya | 英語版・多言語版がある公開モデル群 | どちらのモデルか、入力長、実行環境 |
| Jeff | 独立した公開判断モデル群 | Qwen版かGemma版か、英語の用途か |
| Mica | Qwen3.5-4Bを基にした公開判断モデル | 英語・韓国語の用途か、対応機材 |
| Ollaya | モデルの取得・実行・API提供 | ソフトの版と、モデル名・重みの版の両方 |
| Jevia | Jevを使って開発用モデルの能力段階を選ぶ | 振り分け先、実行権限、別途のモデル費用 |
「Jev互換」は、同じようなでつなげるという意味で使われています。Jevの重みや、同じ判断結果が得られるという意味ではありません。文章の生成、ファイルの変更、顧客への返信は、判断結果を受け取った別の処理が担います。
2. 4モデルの言語・費用・機材を先に絞る
日本語を入力できることと、業務に十分な品質で分類できることは別です。まず言語と実行条件で候補を絞ります。
| 対象と確認版 | 日本語を試す前提 | 利用条件と導入の入口 |
|---|---|---|
| Jev 1.13／jev-1.13.0 | 英語が主な学習言語。日本語などは自分の資料で検証 | 提供元のクラウドへ送信。キーが必要。入力100万トークン当たり0.042ドル、出力は無料 |
| Laya／Python v0.3.22 | 英語421Mと多言語322Mを区別。多言語版は日本語を含む100以上の言語を掲げる | 重み公開・Apache 2.0。公式Pythonは3.10以上。初回は依存関係と重みを取得し、手元で推論 |
| Jeff v1.1 | 公式対象は英語・テキスト。日本語品質は未確認 | コードMIT、重みApache 2.0。Python 3.12以上。CPU・NVIDIA向け、Qwen版はApple SiliconのMLXにも対応 |
| Mica v0.1 4B | 英語・韓国語で学習。日本語品質は未確認 | Apache 2.0。公式手順はLinux・CUDA 12・Python 3.10以上。Q5_K_M重みは約3.51GB |
Jevの料金を読む際は、100万が100万文字と同じではない点に注意します。入力量や再試行も利用方法によって変わります。ローカル推論も、モデルの呼出料金が不要であることと、機材・電力・保守まで無料であることを分けます。
長い資料を扱う場合も条件が違います。Jevは全体64k、stateと最長の質問の合計32kという二つの上限があります。Layaの多言語版は既定1,024トークンで、長くする指定と品質確認が必要です。Micaの公式既定構成は8,192トークン超を切り詰めず拒否します。重みの3.51GBなどの数字は、必要なメモリ総量ではありません。Micaの8GB GPUという案内も開発元の推奨です。
JeffはQwen版のv1.1で最大254候補に広がりましたが、Gemma版v1.0は26候補です。JevとMicaのChoiceは最大255候補。候補上限の近さは品質の同一性を意味しません。導入の詳細はJeffの個別記事を参照してください。
3. Ollayaは実行役、Jeviaは開発作業の振り分け役
Ollayaはモデル名で取得し、手元のサーバーから呼び出せます。確認時の最新公開版はv0.7.5。Apple SiliconのMac、Windows、Linux向け配布があり、利用できる計算機能はモデルと環境次第です。ソフトはApache 2.0、モデルの利用条件はそれぞれ別です。初回の取得は外部通信を伴います。
比較表に書く単位は「Ollaya＋laya:multilingual＋重みの版」です。利用するモデルを替えると、必要なメモリ、言語、入力の種類も変わります。既刊のMac実測はOllaya 0.7.2での記録なので、その数字を最新版全体の性能に読み替えません。
Jevia v0.1.5は、開発の依頼をJevに判定させ、fast・balanced・strongの段階を、自分が設定した具体的なモデルへ結び付けます。MITの実験的なソフトで、Mac・Linux・Windows向け配布があります。Jevのキーに加え、実行先の認証や利用料が必要です。
設定や履歴を手元で管理しても、Jevへの問い合わせまで端末内で完結するわけではありません。現在の依頼文などが送信対象になります。過去の作業結果を次回の判断材料に使いますが、Jevの重みを追加学習する仕組みではありません。部署分類なら、前節のモデルを直接試す構成から始められます。
4. 同じconfidence、同じScoreとは限らない
でも、項目名だけで意味を決めないことが重要です。とくには「この回答が正しい確率」ではありません。実装ごとに、候補の確率分布を異なる方法で要約しています。
| 呼出先 | Choiceのconfidence | Scoreが返す値 |
|---|---|---|
| Jev | 分布から計算する0〜1の統計。公式の説明用近似式を本番の厳密な式と扱わない | 段階番号の確率付き平均。小数になり得る |
| Laya v0.3.22の直接呼出・HTTP | 分布の散らばりから計算。answer_confidenceは別項目で最大確率 | 段階番号の確率付き平均 |
| Jeff v1.1 | 候補数K、最大確率pなら(K×p−1)/(K−1)。Kが2以上の場合 | 段階番号の確率付き平均 |
| Micaの公式サーバー | 最大確率そのもの | 最大確率になった段階番号 |
| Ollaya v0.7.5の互換API | (K×p−1)/(K−1)。Kは2以上。Layaを載せても直接呼出とは異なる | 段階番号の確率付き平均 |
根拠はJevの説明とAPI仕様、Layaの確率処理とScore計算、Jeffの計算、Micaの応答実装、Ollayaの応答実装です。Ollayaのnative APIにあるlaya.confidenceも、互換APIのconfidenceとは別項目です。
たとえば5択で最大確率が0.8なら、Micaのconfidenceは0.8、JeffやOllayaの上記式では0.75になります。これは数式の例で、実モデルの応答ではありません。段階0・1・2の確率が0.2・0.5・0.3なら、Scoreの平均は1.1、最大確率の段階は1です。小数か整数かだけで不正な応答と決めると、別の意味を持つ実装を取り違えます。
式が同じでもや入力の得意不得意は同じになりません。「0.8以上なら自動処理」という条件を、そのまま別モデルへ移すのは避けます。まず内容の正しさを人が確かめ、形式の不備、誤分類、要確認への戻し過ぎを別々に数えます。
5. 日本語5択10件で、比べる条件を固定する
共通検収教材をダウンロードできます。架空の日本語10件を5択に分けます。明確な案件は4部署各2件、残り2件は複数部署と情報不足です。期待する担当と理由は検収者用の別ファイルに置き、モデルへ送りません。
境界になるのは「経費精算システムにログインするとエラーになり、入力画面を開けません」という問い合わせです。本教材では、経費の可否ではなくログイン障害なので情シスにします。複数部署へ独立した用件がある場合は、どちらかへ無理に寄せず要確認へ戻す、という基準も先に決めています。
{ "accounting": "経理：立替経費、請求書、取引先への支払い", "it": "情シス：会社のパソコン、業務システム、ログイン、ネットワークの障害", "hr": "人事：勤怠、休暇、入退社、社会保険の手続き", "general": "総務：会議室、入館証、備品、オフィス設備", "human_review": "要確認：独立した複数部署の依頼、情報不足、対象外"}これは共通の候補定義で、応答結果ではありません。既刊Ollaya記事の日本語20件は4択だったため、今回の5択とは別試験です。また、Jeffを日本語から英訳して試す場合は、翻訳も含む構成として記録し、日本語の直接入力と同じ条件の比較にはしません。
# 展開した教材フォルダで実行。通信せず、固定した入力資料を検査します。python3 run_local.py実送信は明示的に選び、起動済みの手元のOllayaへ送ります。Jevへの有料呼出や、Jeff・Micaの導入を一括で実行するコードではありません。結果を保存するときはソフトとモデルの版、同じ候補と指示だったか、初回と通常処理の時間を分けて残します。
6. 小試験では、明確8件中6件が一致した
編集部は9月30日13時20分、M2 Ultra・メモリ192 GiB・macOS 27.0で10件を実行しました。Ollaya 0.7.2と取得済みの多言語Laya、MLX・fp32の構成です。起動ログとAPIの表示で実行経路を確認しました。最新版Laya 0.3.22や、Jev・Jeff・Micaの実測ではありません。
| 見た項目 | 今回の記録 |
|---|---|
| 担当が明確な8件 | 一致6件、誤った部署1件、要確認へ戻した1件 |
| 要確認にすべき2件 | 要確認0件、部署を選んだ2件 |
| 応答形式・通信の失敗 | どちらも0件 |
| 最初の1件／残り9件の中央値 | 1,612.2ms／12.8ms |
新しいサーバープロセスで予熱せず、各入力を1回ずつ送信しました。初回はモデル読込みを含み、時間は手元のHTTP往復・応答解釈・検査までです。入力と期待分類は実行前に固定し、結果を見て調整していません。モデルの識別子、設定、生応答、集計は教材ZIPに同梱しています。
「会議室の予約」は総務を期待したのに情シス、「入館証の再発行」は要確認になりました。さらに、経費の確認とパソコン故障を同時に頼む例は経理を選び、confidenceは0.7196でした。要確認を候補に加えるだけで、曖昧な案件を拾えるわけではありません。
これは10件の架空教材で、言語全般の精度やモデル間の順位は示しません。旧記事の4択20件とも条件が違います。まず人が全件を読み、担当案が合うか、要確認への見逃しと戻し過ぎがないかを分けて記録します。その結果で、試験を増やす構成を決めます。