Laya-MLXが7.4msで即答、Jev超えのオープンソース判断AIを現場でどう活かすか

• 事実と背景：Jevに対抗するオープンソースの意思決定モデル「Laya」が登場し、ローカル環境でのセルフホストが可能に。
• 技術的変革：ModernBERTをベースにしたエンコーダー型非自己回帰モデルで、Jev比約7.8倍、MLX版で最速7.4msの超高速推論を実現。
• 現場への影響：コンテキスト長や選択肢のトークン制限が厳しいため、プロンプトを極限まで簡潔に設計する「処方箋」が必須となる。

深夜の障害対応で、次々と押し寄せるアラートの山を前に「これは本当に今すぐ対応すべき緊急事態なのか、それとも明日の朝でいいのか」と頭を抱えた経験は、インフラやバックエンドを支えるエンジニアなら誰しも一度はあるはずだ。従来、こうした「瞬時の判断」をLLMに委ねようとすると、APIのレイテンシという巨大な壁にぶち当たっていた。数秒かけて生成されたテキストをパースし、正規表現で判定するようなスパゲッティコードは、リアルタイム性が求められる現場では使い物にならない。そこに現れたのが、テキスト生成を一切行わず、1回のフォワードパスで較正された確率を返す「System One Models」の思想だ。先行するTypeSafe AIの「Jev」は大きな注目を集めたが、クローズドなAPIであり、コストやプライバシーの懸念が残っていた。

これに対し、Convai InnovationsのNandakishor Mukkunnoth氏が「1年も前から作っていた」と怒りの告発と共に公開したのが、オープンソースの意思決定モデル「Laya」である。Layaはローカル環境でセルフホスト可能であり、何よりもその推論速度が圧倒的だ。GitHubで報告されたベンチマークによると、Jevの推論速度が236〜276msであるのに対し、Layaはわずか32.8msと、約7.8倍の高速化を達成している。さらに、Apple Silicon向けに最適化された「Laya-MLX」にいたっては、多言語版で7.4msという、もはや人間の知覚を遥かに超えた次元で動作する。

ここで、JevとLaya、そしてLaya-MLXのスペックとコストの比較を表にまとめておこう。この圧倒的な数値の差を見れば、我々エンジニアがどちらに未来を感じるかは明白だろう。

この表が示す通り、Layaは「無料かつ超高速」という、ローカルでエッジAIを動かしたい開発者にとって夢のような選択肢を提示している。テトリスの操作を20msで判断し実行するデモ動画が示すように、リアルタイムゲームのAIから、ミリ秒単位の判定が求められる金融取引、あるいはWebアプリケーションの動的なルーティングまで、その応用範囲は無限に広がっているように見える。しかし、この「銀の弾丸」に見えるLayaにも、アーキテクチャに起因する致命的な制約が存在するのだ。

なぜLayaはこれほどまでに速いのか。その秘密は、従来のLLMのような「自己回帰型（Autoregressive）デコーダー」を完全に捨て去り、「非自己回帰型（Non-autoregressive）エンコーダー」を採用した点にある。

Layaのバックボーンには、最新のエンコーダーモデルである「ModernBERT-large」（約395Mパラメータ）または多言語対応の「mmBERT-base」（322Mパラメータ）が採用されている。通常のLLMは、次のトークンを1つずつ予測しては入力に戻すという「無限ループ」のようなステップを繰り返すため、生成するテキストの長さに比例してレイテンシが増大する。これに対し、Layaは入力の冒頭に [CLS] トークンを、そして質問の選択肢ごとに [MASK] トークンを配置し、双方向注意機構（Bidirectional Attention）によってコンテキスト全体を一度に読み込む。

そして、[MASK] 位置の隠れ状態（Hidden State）を直接取り出し、その上に載せられた約25.2Mパラメータの「Decision Head」に流し込む。ここで選択肢スコアラが各選択肢のロジットを算出し、温度付きソフトマックス関数によって較正された確率を出力するのだ。つまり、テキストを「1文字も生成しない」ため、推論は常に1回のフォワードパスで完了する。質問を複数同時に投げても、並列で処理されるため、1問あたりのオーバーヘッドは劇的に減少する。

さらに興味深いのは、その学習手法「RLCD（Reinforcement Learning for Calibrated Decisions）」における「Strictly Proper Scoring Rules（厳密固有スコアリング規則）」の導入だ。一般的な分類タスクで使われるクロスエントロピー損失は、モデルに「過信（Overconfidence）」を学習させやすい。つまり、自信満々に間違った答えを出す「生意気なAI」になりがちなのだ。Layaは、予測確率が実際の正解率と一致するように、対数スコア、球面スコア、そして順序尺度を考慮した順位確率スコア（RPS）を組み合わせた独自の報酬設計を行っている。

特筆すべきは、訓練データにLLMによる合成データを一切使わず、人間がラベル付けした実世界のデータセットのみを使用している点だ。作者のMukkunnoth氏は「合成データで較正モデルを訓練すると、LLMのバイアスや間違いまで学習してしまう」と指摘する。この徹底した職人気質なアプローチこそ、Layaの「直感」の精度を支えるバックボーンなのだ。

しかし、実際の開発現場にLayaを投入しようとすると、我々は冷酷な現実の壁に直面することになる。GMOインターネットグループによる日本語タスク（ECサイトのレビュー分析や問い合わせエスカレーション判定）の検証結果は、Layaの「実用上の限界」を浮き彫りにしている。

まず、日本語のニュアンス理解において、LayaはJevに一歩及ばない。例えば、価格に満足しつつも機能に不満を述べているレビューに対し、Layaは不満カテゴリを誤判定するケースが見られた。さらに深刻なのは、確率の「較正（Calibration）」を売りにしているにもかかわらず、Layaの出力する確率が0%や100%といった極端な値に振り切れやすい点だ。Jevが「25%〜53%」といったグラデーションのある中間的な判断を下すのに対し、Layaは「0%か100%か」の二者択一に陥りがちである。これは、バックボーンであるmmBERTの日本語表現力の限界や、多言語版のパラメータサイズ（322M）の小ささに起因していると考えられる。

そして、エンジニアにとって最大の「デッドロック」となるのが、極めて厳しいトークン制限だ。Layaのチェックポイント設定では、入力上限が英語版で512トークン、多言語版で1,024トークンに制限されている。さらに致命的なのは、選択肢（Criteria）に割り当てられるトークン数が、英語版で192、多言語版で256トークンしかない点だ。Jevが最大255択の複雑な条件分岐に対応できるのに対し、Layaで複雑な判定基準（Policy）をプロンプトに書き込もうとすると、あっという間にトークン上限に達し、判定精度が著しく低下する。

実際、検証において「判定基準（Policy）を長々と書いたパターンAやB」では誤判定が多発したが、「判定基準を極限まで短く要約したパターンD」では精度が劇的に向上した。ここから導き出される、我々エンジニアが明日から取るべき「実践的な処方箋」は以下の通りだ。

• プロンプトの極限までのダイエット: 判定基準は長文で与えず、20〜30文字程度の簡潔なキーワードに要約して criteria に流し込むこと。
• ハイブリッド構成の採用: 複雑な文脈理解が必要な一次トリアージはJevや通常のLLMに任せ、Layaは「超高速な二次判定」や「エッジ側での即時フィルタリング」に特化させる。
• ドメイン特化のファインチューニング: オープンソースである強みを活かし、自社の過去の対応ログ（人間がラベル付けしたもの）を用いてLayaをローカルで追加学習させる。

我々は、巨大なフロンティアモデルが提示する「何でもできるが遅くて高いAI」に依存し続けるべきなのか。それとも、Layaのような「単機能だが超高速で無料のローカルAI」を組み合わせた、新しい分散型アーキテクチャを模索すべきなのか。この問いに対する答えが、次世代のシステム設計の成否を分けることになるだろう。