Jev と Laya とは？判定専用モデルを4言語でファインチューニングした検証記録

Jev は、文章を生成せず「どの選択肢か」「はいか、いいえか」の確率だけを返す判定専用のモデルで、Laya は同じ使い方ができる OSS（Apache 2.0）です。当社は AI 社員サービス AGTO の投稿判定を想定し、Laya の多言語版を日本語・タイ語・英語・ラオス語の合成データでファインチューニングしました。学習前は、投稿が作業の依頼かどうかを見分ける正解率が 5 割前後でしたが、学習後は約 0.90 まで上がり、応答時間は LLM より短くなりました。ただし正解率は上位の LLM に届かず、最もバランスが良かったのは、迷った投稿だけを LLM に回す組み合わせです。

LLM に「はい・いいえ」を答えさせるためだけに、毎回 1 秒前後待っていないでしょうか。判定処理の速さや費用を見直したいエンジニア・プロダクト担当者に向けて、Jev と Laya の仕組み、当社の実測値、試して効かなかった手、導入前に確かめる点を順に紹介します。

**Jev と Laya は、入力文と「型の決まった問い」を受け取り、1 回の計算で答えの確率を返すモデルです。**LLM のように文章を 1 語ずつ生成しないため答えが速く、返ってきた確率をそのままプログラムの分岐に使えます。違いは、Jev が TypeSafe AI のホスト型 API で、Laya が自前のサーバーで動かす OSS だという点です。

Jev は TypeSafe AI の主力モデルで、同社が「System One モデル」と呼ぶ種類の最初のモデルです。判定の対象となる本文（公式の用語では state。以下「状態」）と問いを一緒に渡すと、問いごとに答えを返します。扱える問いの型は 3 つあります。候補から 1 つを選ぶ Choice、段階で評価する Score、はい・いいえの確率を返す Noul です。公式ドキュメントによると、Choice と Score は答えと候補ごとの確率に加えて確信度（confidence）を返します。1 回の呼び出しに複数の問いを混ぜても、問いは互いに独立して並列に評価されるため、応答時間はほとんど増えないとされています。

名前だけでは分かりにくいのが Noul です。はい・いいえで答えられる問いに対して、答えが「はい」である確率を 0〜1 の値 1 つで返します。公式の例では、「顧客は人間の担当者を求めているか」という問いに対し、「ありがとう、直りました！」は 0.02、「あなたはボットですか？」は 0.40、「もう 3 回聞いています。人と話させてください」は 0.99 でした。答えが 2 つしかないので、この値そのものが確信の強さを表し、Choice や Score のような確信度は別に返しません。また、値は程度の物差しではありません。たとえば「Python が得意か」に 0.6 と返っても、それは得意さの度合いではなく「得意である確率」です。度合いを測りたいときは Score を使います。

提供形態はホスト型の API で、コンソールで発行した API キーを使って POST https://api.typesafe.ai/v1/systemone を呼びます。料金と主な制約は、モデルのページに次のように書かれています（執筆時点の記載です。最新は公式ページを確認してください）。

見落としやすいのは、Jev は顧客ごとにファインチューニングできない点です。全アカウントが同じ重みを使い、自社向けの調整は、状態に入れる情報と、問いの指示・候補の説明の書き方で行います。速さについては、公式サイトが「System One 向けの作業で、LLM の 8.566 秒に対して 0.114 秒」という実演を載せていますが、これは TypeSafe 自身による比較です。

Laya は Convai Innovations が Apache 2.0 で公開している判定モデルです。英語版（ModernBERT-large、4.21 億パラメータ）と、100 以上の言語に対応した多言語版（mmBERT-base、3.22 億パラメータ、入力 1,024 トークン）などがあり、Choice・Score・Noul を Jev と同じ考え方で扱います。付属の HTTP サーバーは Jev と同じ POST /v1/systemone の形式で受け付けるため、Jev 向けに書いたクライアントを自前のサーバーへ向け直すこともできます。

README では、GPU（T4）で 1 問 p50 32.8ms とし、第三者が公表した Jev の 236〜276ms と比べています。ただし Jev の数値は作者自身が測ったものではない、と明記されています。精度については、公開ベンチマーク typed-decisions でファインチューニング済みの版が 0.766（Jev の公表値は 0.727）とする一方、選択肢が 70 を超える意図分類（Banking77）では Jev が大きく上回るとも書かれています。

見落としやすいのは、多言語版が温度（確率の尖り方の補正）を合わせないまま配布されている点です。README 自身が、自分のデータで補正してから使う前提を示しています。

LLM に「この投稿は依頼ですか？ はい・いいえで答えて」と聞くこともできますが、判定専用モデルとは得意な仕事が違います。結論から言えば、判定専用モデルは速さと確率の扱いやすさで勝り、問いの自由度と説明の力では LLM に劣ります。

向いているのは、同じ形の問いを大量に、短い時間で繰り返し判定する場面です。反対に、理由を添えた回答が要る判断、候補が数十に及ぶ分類、長い文脈を読む必要がある判断は LLM のほうが向いています。TypeSafe も既知の弱点のページで、数え上げ・数値の計算・日付の比較は苦手なのでコード側で行うよう案内しています。

判定専用モデルと LLM の役割分担は、クラウド LLM とオンデバイス SLM の振り分けと同じ発想で考えると整理しやすくなります。

**結論から言うと、目的は AI 社員が投稿を拾う入口の判定を、LLM より速く・安くできるかを確かめることでした。**AGTO では、チャットの投稿を AI 社員が読んで作業を始めます。その判定を 2 つの問いに分け、学習なしの Laya から測り始めました。

1 つ目の問いは「この投稿は、誰かに作業を頼んでいるか」という、はい・いいえで答える問い（Noul）で、以下「依頼」の判定と呼びます。「〜してもらえると助かります」は依頼、「〜が終わりました」は依頼ではない、「A さんに〜をお願いしたい」は依頼、という線を引きます。2 つ目は「頼まれている作業は、どの業務に当たるか」を、5 つの業務と「該当なし」から選ぶ 6 択（Choice）です。業務の候補はテナントやチャンネルによって変わるので、特定の業務名を覚えさせるのではなく、候補の説明を読んで選ぶ力が求められます。

言語は日本語・タイ語・英語・ラオス語の 4 つです。LLM に聞けば判定はできますが、投稿のたびに 0.6〜2 秒ほど待つことになり、件数が増えれば費用も積み上がります。判定専用モデルで同じことができれば、この 2 点を改善できると考えました。

最初に、多言語版の Laya を学習なしで試しました。日本語・タイ語・英語の対訳 114 文による小さな試験では、「依頼」を見分ける力（AUROC）は 0.89〜0.95 と高かった一方で、確率が「いいえ」側に大きく偏っていました。0.5 で区切ると「はい」と答えたのは 5〜25% だけで、正解率は 0.55〜0.70 にとどまります。担当部署を当てる 6 択（業務の 6 択とは別の試験問題）は 0.53〜0.72、緊急度の 3 段階はランダムと変わらない水準でした。

後で作った評価セット（1 言語 100 件）でも、学習前の「依頼」の正解率は日本語 0.47、英語 0.54、タイ語 0.53、ラオス語 0.52。コインを投げるのとほとんど変わりません。

AUROC が高いのに正解率が低いのは、並び順は正しく付けられているのに、境目の位置がずれているからです。自前のデータで閾値を決め直すと 0.75〜0.93 まで上がりましたが、温度を合わせるだけでは 0.5 の境目は動きません。そのまま差し込めば使えるモデルではなく、自社の問いに合わせた学習と補正が前提だと分かったので、ファインチューニングに進みました。

**顧客の投稿は使わず、LLM に書かせた職場チャットの合成データで学習しました。**意外だったのは、精度を左右したのがデータの量よりも「評価の作り方」と「正解の付け方」だったことです。

学習データは、LLM に 1 件ずつ条件を指定して職場チャットの投稿を書かせて作りました。指定したのは投稿の種類（依頼 7 種、依頼でないもの 9 種）、業務の型（60 種から 1 つ）、長さ、口調、業種です。雑談は話題まで指定しないと、天気と昼食の話ばかりになりました。

正解は、書かせたときの指示を見せずに 2 回付けさせ、2 回とも一致したものだけを残しました。2 回目は候補の並び順を入れ替えています。言語の違う文や、文字 3-gram の Jaccard 係数が 0.8 を超える近い重複も除きました。

6 択の候補は、毎回 60 種の業務から 2〜8 個をランダムに選び、最後に必ず「該当なし」を置きます。依頼の一部では正解の業務をわざと候補から外し、正解を「該当なし」にしました。60 種のうち 12 種は学習に使わず評価だけに回し、学習で見ていない業務にも当てられるかを測っています。

最終的な学習データは約 1 万行（判定にして約 3 万 2,000 問）で、公開データセット typed-decisions も 600 行混ぜました。「日付に触れているか」などの補助の問いも入れています。最初はこれがなく、学習していない判定の正解率が 10 ポイント下がったためです。

学習データと同じ LLM・同じ指示で評価セットを作ると、「その LLM の癖を覚えたか」を測ることになってしまいます。そこで評価セットは、学習データとは別のモデルと別の指示で「あるチームのチャンネルの 1 週間分」として書かせました。正解は元の答えを伏せて付け直し、食い違った件だけを裁定して確定させました。

規模は途中で見直しました。当初は 1 言語 100 件でしたが、同じデータで乱数の種だけを変えて学習し直すと、1,200 問中 87 問（約 7%）の答えが入れ替わったのです。これでは 3〜5 ポイントの差が乱数の揺れと区別できません。そこで 1 言語 300 件（4 言語で 1,200 件）に増やし、同じ問いへの答えの食い違いを数える McNemar 検定で比べるようにしました。この変更の後、「少し良くなった」と見えていた改善の多くが、実は揺れの範囲だったと分かりました。

合成データだけでは実際の文体とずれるため、社内チャットの実際の投稿 121 件（人名・社名・URL を置き換えて匿名化したもの）も、別の評価として使っています。

学習は社内の GPU マシン 1 台で行いました。Laya の公式ノートブックは Kaggle の GPU 2 枚を前提にしているため、1 枚で動くように書き換えています。ピーク時のメモリは約 6.5GB、約 1 万行・4 エポックの学習は 1 回およそ 1 時間です。

乱数の種を変えて 3 本学習し、その重みを平均する「model soup」も試しました。推論の重さは 1 本分のまま 6 択の正解率が 1〜2 ポイント上がったので、最終版の重みはこの方式で作っています。

API の費用は、最初の学習データ約 5,600 件の生成と正解付けで約 $17、学習データ全体の正解を上位のモデルで付け直す試行が 1 回あたり約 $26〜29 でした（執筆時点の単価による参考値）。GPU の利用料がかからない分、費用のほとんどはデータづくりです。

**Laya 単体は「依頼」の判定で Claude Haiku と同程度の正解率を、より短い待ち時間で出しました。**ただし 6 択と上位の LLM との差は残り、最もバランスが良かったのは、迷った投稿だけを LLM に回す組み合わせです。

結論として、Laya は「依頼」の判定で Claude Haiku をわずかに上回り、待ち時間はもっとも短い一方、正確さでは Claude Sonnet に届きませんでした。学習後の Laya（最終版）と、同じ問いを LLM に解かせた結果を並べます。時間はタイのオフィスから東京リージョンまでの往復を含む値で、1 件ずつ順に送って測りました。

Laya の p95 は Haiku の半分以下です。6 択は Haiku や gpt-oss-120b のほうが高く、Claude Sonnet はすべての項目で最も正確な代わりに、p50 で約 1.9 秒かかります。Laya のサーバー内の処理時間だけを見ると p50 は約 310ms で、残りの約 120ms は通信と暗号化の往復です。

言語別に見ると、Laya の「依頼」の正解率は英語が 0.860 と最も低く（タイ語 0.927、ラオス語 0.903）、遠回しな依頼や「知っている人いる？」のような情報を尋ねるだけの問いで外しがちでした。4 言語全体の 0.903 は、この差をならした値です。

表の Laya の値には、2 つの問いの食い違いを直す小さな規則を入れています。6 択では業務を選んでいるのに「依頼」の確率は低い、という矛盾が起きるため、「依頼」の確率を、選んだ業務の確率まで引き上げる規則です。最終版の重みでは、これだけで「依頼」の正解率が 0.897 から 0.903 に上がりました。Jev の公式ドキュメントも、別々の問いの答えが互いに整合するとは限らないと注意しています。

なお、評価セットの文と正解も LLM が作っています。正解を付けたモデルと同じ系統の LLM には有利に出る可能性があるので、LLM どうしの順位はその前提で読んでください。

Laya は確率を返すので、「確信度が基準より低い投稿だけ LLM に回す」構成が組めます。基準は、LLM に回す割合が問いごとに 10% を超えない範囲で正解数が最大になるよう、交差検証で決めました。評価セットでは、投稿の 16〜17% が LLM に回りました（Haiku・Sonnet で測定）。上限は問いごとにかけていて、2 つの問いのどちらかで迷えばその投稿を回すため、投稿単位では 10% を超えます。結論として、p50 はほぼ保ったまま、評価セットではどの LLM と組んでも Laya 単体より精度が上がります。ただし実際の投稿での「依頼」の正解率は、Sonnet と組んだとき以外は下がりました。

組み合わせにしても p50 は Laya 単体とほぼ変わらず、評価セットでの「依頼」の正解率は、どの組み合わせも LLM 単体の Haiku を上回ります。Laya と LLM で外す問いが重ならないためです。p95 は回した投稿の LLM の時間で決まるので、Sonnet と組むと 2.5 秒になります。当社は精度を優先し、Sonnet と組む構成を選びました。

p95 を縮めたいなら、回す投稿そのものを減らす手があります。確信度・言語・2 つの問いの食い違い・文の長さから「Laya が外しそうな投稿」をロジスティック回帰で見積もり、上位だけを回す方式です。回す投稿を 5% 以下に絞ると、評価セットで p95 は 0.65〜0.77 秒に戻り、代わりに正解率は 0.6〜2.4 ポイント下がりました。

Laya は CPU で動きます。検証サーバーは AWS の EC2 1 台に Docker で載せており、インスタンスの型ごとに同じ条件で測りました。結論として、同じ月額なら物理コアの多い型を選ぶのが最も効きました。

月額は執筆時点の単価 × 730 時間で出した参考値です。ほぼ同じ月額でも、1 vCPU が物理コア 1 つに当たる c7a.large にすると 17% 短くなり、コアを 4 つにするとほぼ半分になりました。

一方、量子化（重みの INT8 化）は約 2 倍速くなるものの、6 択の正解率が 1.4〜3.1 ポイント下がったので採りませんでした。ONNX Runtime への書き出し（fp32）は答えが変わらない代わりに、速さも 5〜8% しか変わりません。当社の条件で速さに効いたのは、CPU のコアを増やすことでした。

ここまでの数字は順調に見えるかもしれません。しかし、合成データの工夫は途中から頭打ちになり、実際の投稿との間には、データを足しても埋まらないずれが残りました。

効きそうに見えて採らなかった手のほうが、得たものは多くありました。

チャンネル名と説明を入力に加えれば、根拠が増えて 6 択が良くなると考えていました。結果は逆で、0.787 から 0.706 に下がっています。正解が「該当なし」の投稿でも、チャンネルの業務を選んでしまう誤りが増えました。モデルが文脈に頼りすぎたのです。

境目にある投稿の正解が、学習データと評価セットで食い違っていたことも分かりました。英語の「does anyone know …（知っている人いる？）」のように情報を尋ねるだけの問いは、学習データでは 59% が依頼、評価セットでは 33% が依頼と付けられていました。学習データ全体の正解を評価セットと同じモデルで付け直してみましたが（約 $26）、全体の正解率は上がりませんでした。これは学習の問題というより、「知っている人いる？」を AI 社員に拾わせたいかという製品の判断を先に決めるべき問題でした。

このほか、英語だけ英語版 Laya に振り分ける、正解を確率で柔らかく与える、あいまいな例を除く、といった手も試しましたが、どれも最終版を上回りませんでした。合成データの作り方を変えた 6 通りの学習のうち、それまでの最良を 1 ポイント以上上回ったものはありません。

合成データの評価セットで日本語の「依頼」の正解率が 0.92 あっても、社内チャットの実際の投稿では 0.80 に下がりました（学習の途中段階での比較）。とくに差が出たのが、開発チャンネルの「修正したので確認お願いします」のような投稿です。

原因を切り分けるため、自作の文で候補を固定して比べました。「ログイン画面のバグを直したので確認お願いします」なら、学習後も「不具合修正」を 0.98 以上の確率で選びます。ところが「4箇所修正したので確認お願いします」のように業務を示す語がないと、学習後は「該当なし」を選びました。学習前は「修正」だけで不具合修正と推測していたので、学習によって「本文に根拠がなければ選ばない」慎重な判定に変わったことになります。実際の開発チャンネルでは、文脈があるので本文に業務名を書きません。人や LLM はそれを推測して正解を付けますが、本文しか見ない Laya には手がかりがないのです。

開発チャンネルの書き方の例を 189 行足すと、実際の投稿の 6 択は 0.818 から 0.851 に上がりました。合成データの工夫だけでは頭打ちで、ここから先を良くする材料は実際の投稿です。ただ、当社は顧客のデータを学習に使わない方針なので、社内の投稿だけでどこまで集められるかが次の課題になっています。

**判定専用モデルが効くのは、判定の量が多く、正解データを用意でき、LLM の待ち時間が問題になっている場面です。**逆に、どれか 1 つでも欠けるなら、LLM に都度聞く今の形のほうが合理的なこともあります。導入を決める前に、次の 6 点を確かめてください。

1. 判定の量が損益分岐を超えるか。 当社の問い方では、Claude Haiku の費用は 1,000 件で約 $0.45 でした。4 コアの検証サーバー（月約 $189）と並ぶのは月約 42 万件です（いずれも執筆時点の単価による参考値）。量が少ないうちは、LLM に都度聞くほうが安く、運用の手間もかかりません。
2. 正解の付いたデータを用意できるか。 学習前の Laya は、自社の問いにそのままでは使えませんでした。学習にも評価にも、自社の問いの形で正解を付けたデータが要ります。
3. 評価を学習データと別に、1 言語 300 件規模で作れるか。 100 件では、乱数の揺れと改善を見分けられませんでした。
4. 境目の判断を製品として決めてあるか。 「知っている人いる？」を依頼とするかどうかで、正解そのものが変わります。
5. 縮めたいのは p50 か p95 か。 どちらを目標にするかで、LLM との組み合わせ方と回す割合が変わります。
6. 利用規約を確認したか。 LLM の出力で別のモデルを学習させる場合は、使う LLM の規約に学習の制限がないかを確かめてください。

ファインチューニングそのものを自社でやるべきかの判断基準は、ファインチューニング入門で整理しています。

Jev と Laya の導入を検討するときに出やすい疑問に、今回の検証で分かった範囲で答えます。

そのままでは使えませんでした。学習前の日本語の「依頼」の正解率は 0.47 で、学習後に 0.9 前後まで上がりました。自社データでの閾値の決め直しか、ファインチューニングが前提です。

自社データで学習させたいかどうかで分かれます。Jev はホスト型なので、学習やサーバー運用の手間がかかりません。その代わり顧客ごとのファインチューニングはできず、調整は問いの指示と候補の説明で行います。公式も、英語以外の言語は精度が同等ではないので自社の文章で試すよう勧めています。

一方の Laya は自前のサーバーで動き、データを外に出さずに学習できますが、学習データの用意、評価、運用は自社の仕事になります。GPU は必須ではなく、当社の検証では 4 vCPU のサーバーでサーバー内 p50 約 310ms でした。日本語やタイ語が中心で、判定の線引きが自社固有なら Laya、英語が中心でまず手早く試したいなら Jev から始めるのが現実的です。

Jev と Laya は、LLM が得意な文章生成を捨て、判定の速さと確率の扱いやすさに絞ったモデルです。当社の検証では、学習前の Laya は自社の問いにそのまま使えませんでしたが、合成データでファインチューニングすると 4 言語全体で「依頼」の正解率が約 0.90 まで上がり、応答時間は LLM より短くなりました。正解率は上位の LLM に届かないものの、迷った投稿の 2 割弱だけを LLM に回すと、p50 はほぼ Laya 単体のまま、LLM に近い精度が出ます。

検証を通して分かったのは、精度を決めるのはモデルの選び方よりも、評価と正解の作り方だということです。評価を学習データと分け、300 件規模で比べ、境目の判断を製品として決めておく。ここまでできていれば、判定専用モデルを入れるかどうかも数字で判断できます。小型モデルの作り方全体については、SLM 蒸留の解説もあわせてご覧ください。

当社では、AI による判定処理の設計や PoC も支援しています。ご相談は AI・DX 支援からお寄せください。

参考資料（執筆時点で参照）: Laya の GitHub リポジトリと Hugging Face のモデルカード、TypeSafe AI の公式ドキュメント。いずれも本文中にリンクしています。