Jev vs Laya（2026）：どのSystem One意思決定モデルを選ぶべきか
同じ仕事。まったく別の製品。
2026年9月、型付き意思決定モデル（typed decision models）は研究ネタではなく、エンジニアが実際に選ぶ部品になった。
Jev（TypeSafe AI）と Laya（Convai Innovations）はどちらも同じ層に座る。アプリの状態と宣言済みの質問を送り、機械が使える答えと確率が返る——またパースする段落ではない。共通の三つの原語は choice、score、noul（Yes/No 確率）。
インターフェースが似ているから、タイムラインはライバル扱いする。運用の現実はもっと明確だ。Jev はホスト型の意思決定 API。Laya はApache 2.0 のオープンウェイトを自分で動かすスタック。答えの形は同じ。所有モデルは違う。
Jev 単体の解説が先なら、TypeSafe Jev / System One の深掘りから。本稿は「どちらを選ぶか」のための比較だ。
両モデルが実際にやっていること
どちらもチャットボットではない。メールを書かせたり、ツール名を捏造したりしない。答え空間を先に定義し、モデルはそれをスコアする。
| 原語 | 聞くこと | 返ってくるもの |
|---|---|---|
choice | 定義したラベル集合から一つ選ぶ | 選ばれた選択肢 + 信頼度 |
score | 自分で書いた順序尺度で評価 | その尺度上の数値 |
noul | Yes/No 質問 | 「Yes」が成り立つ確率 |
だから agent harness、ルーター、ガードレール、トリアージ、エスカレーションのゲートに合う。副作用はあなたのコードの仕事。モデルは曖昧判断の仕事。
公式の位置づけは TypeSafe の System One 発表 と Laya の Hugging Face モデルカード。
対比：本当に効く差分
| 観点 | Jev | Laya |
|---|---|---|
| 提供形態 | TypeSafe ホスト API（ゲートウェイ経由も可） | オープンウェイト + Python パッケージ、自前提供 |
| ライセンス／検証性 | クローズド；API 契約 | Apache 2.0 の重みとコード |
| 典型的な入力予算 | 文書上おおよそ 64k トークンのリクエスト上限 | 既定は約 512–1,024 トークン（設定とエンコーダ依存） |
| 多数の選択肢 | choice あたり最大 255 | 選択肢が固定 head 予算を共有；既定では概ね 20 未満を推奨 |
| 適応 | 条件・状態・プロバイダ版 | チェックポイントの微調整 + 自データでの校正 |
| コストの形 | 約 $0.042 / 100万 input トークン；output 無料 | 重みは無料；計算・メモリ・運用時間がコスト |
| レイテンシの物語 | サブ秒の API 経路（ネットワーク込み） | ロード後のローカル前方は数十 ms 級——ハード次第 |
同じトレードオフを、リーダーボードで決着したふりをせず整理した独立記事：AgentGrid、Anthus。
まず Jev が妥当なとき
今週ホスト済み部品が欲しい
GPU 群もチェックポイント管理もサービングも要らない。API キー（またはゲートウェイ）と HTTP クライアントで意思決定ループに入れる。
長い状態や大きなラベル集合
履歴付きチケットや数十キューの choice では、文書化されたリクエスト予算と高い選択肢上限が効く。Laya も head を広げられる——だがその作業は自分の責任。
微調整なしのゼロショット基線
公開・独立評価は繰り返し示す：Laya のベースは型付き意思決定ワークフローに特化が要る。ラベルが少なく、箱から出して使いたいなら Jev から測れ。
すでにプロバイダ SLA 前提で最適化している
レート制限・認証・過負荷の意味論は TypeSafe 側の問題面。リトライは必要でも、ModernBERT の運用まで抱えない。
まず Laya が妥当なとき
データを自前インフラに閉じたい
ローカル推論はチケット・メール・トレースを第三者の意思決定 API に出さない選択になる（周辺ツールのプライバシーは別問題）。
量が出てトークン課金が間違ったコストモデル
高 QPS のルーティングとガードレールはホスト課金を永久に燃やす。余力のある GPU/CPU + Apache 2.0 なら経済がひっくり返る——運用できるなら。
微調整と校正をする前提
Laya 自身のカードは明確だ。英語・多言語のベースは一部の typed-decisions でほぼチャンス水準で、特化後のチェックポイントは別物。Laya は「所有する速いベース」であり、Jev のゼロショット双子ではない。
明示的ルーター付きの多言語
英語 root は読めない文字でも「自信あり」に失敗しうる。Router は英語／多言語／typed-decisions を振り分ける——実際に走ったチェックポイント名を残せ。
ベンチマークの読み方（切り替える前に）
数値が本物でも、ベンダー表は宣伝の匂いを帯びやすい。Jev vs Laya の議論でほぼ必ず出る三つの罠：
| 罠 | なぜ痛いのか |
|---|---|
| 微調整 Laya ≠ ベース Laya | 0.76 前後の typed-decisions スコアは特化チェックポイントのもので、英語 root のダウンロードではない。 |
| 第三者の Jev 列 ≠ 同一実行の対戦 | Laya 公開比較は外部の Jev 数値を引用し、プロンプトとサンプルサイズが違うと明記している。 |
| ウォームなローカル ms ≠ エンドツーエンド API | ロード済み GPU 前方とネットワーク込みホスト呼び出しは別の問いに答えている。 |
Anthus は同じテキスト・質問・フィードバックループで両側を回し、ステアリング後は Jev が先行（そのベンチでおおよそ 87% vs 80%）。これは一つの同一タスク信号であって宇宙ランキングではない。既定の選択肢予算での Banking77 の落ち込みも同様に現実的で、高カーディナリティは今のところ Jev の文書化された上限の方が、再調整なしでは安全に見える。
結論：自分のチケット、名前付きチェックポイント、校正のあとで評価せよ。他人のリーダーボードのマスを相続するな。
Laya はファミリー——チェックポイント名を言え
| チェックポイント | バックボーン（公開情報） | おおよその既定コンテキスト | 向いている用途 |
|---|---|---|---|
convaiinnovations/laya（英語 root） | ModernBERT-large ~421M | ~512 トークン | 英語トリアージ、ガードレール |
laya-multilingual | mmBERT-base ~322M | ~1,024（エンコーダはさらに伸ばせる） | 非英語／複数スクリプト |
laya-typed-decisions | ModernBERT-large ~421M | ~1,024 | 特化 typed-decisions ワークフロー |
Router().predict(...) が選ぶ。評価行ごとに routing.model（相当）を残せ。さもなくば一つのブランド名で三製品を比較してしまう。
意思決定ガイド
| 状況 | まず試す | 理由 |
|---|---|---|
| 今週ホスト型の意思決定層が必要 | Jev | インフラが少ない。次に自前ルーブリックで精度を測る |
| 入力がよく約 512–1k を超える | Jev（またはタスク再設計） | 文書上の大きなリクエスト予算 |
一つの choice に数十ラベル | まず Jev | 既定 Laya head の選択肢予算の崖 |
| 厳格なデータ局所性／隔離 | Laya | 重みと推論が自前 |
| 高ボリューム + 余剰アクセラレータ | Laya | トークンが単位経済にならない |
| ドメインラベルが数百ある | Laya を微調整 | 特化が製品の意図された道 |
| 自ケースの精度が未決 | どちらでも——同じ評価ハーネス | 共有ケースがブランド忠誠に勝つ |
実務的な推奨
「Jev vs Laya」をオープン対クローズドの道徳劇にするな。デプロイと評価の選択として扱え。
- どちらのモデルを呼ぶ前に、期待カテゴリ付きの合成ケースを 5〜20 件書く。
- アダプタは分ける。版・デバイス・切り捨て・チェックポイント名を記録する。
- ホールドアウトで信頼度を校正する。自信満々の誤りは、誤りだ。
- そのうえで、プロバイダ依存と自前運用のどちらが長期的に安い失敗かを決める。
統合速度・長い文脈・大きな選択肢集合が支配的なら Jev。制御・流量経済・微調整の所有が支配的なら Laya。有用な勝者は、あなたのチケットを、許容できる失敗の仕方と運用可能なコストで扱う方だ。
Jev が agent harness にどう嵌るかは TypeSafe AI の Jev がバズった理由 を参照。
