ローカルLLM・クラウドLLM・Jev・Laya
AIは「賢さ」から「配置」へ
2026年、AIの論点は「どのモデルが最も賢いか」から「どの層に何を置くか」へ移りつつあります。クラウドの値下げ競争、手元で動くオープンモデル、そしてテキストを生成しない第三の選択肢。4つの話題を一枚の地図に整理します。2026.09.22
3分でわかる要旨
- クラウドLLMは性能競争から価格競争へ。GPT-5.6 Luna は80%値下げされ、フロンティア各社が価格性能比でぶつかり合っています。
- ローカルLLMは「手元で動く」が前提になりました。MoE+4bit量子化と投機デコードの実用化で、日本語の実用用途はQwen3.6-35B-A3Bが第一候補という水準です。
- 決定モデルという第三の層が立ち上がりました。TypeSafe AI の Jev と、Convai Innovations の Laya は、どちらもテキストを生成せず「型付きの判断」だけを返します。
- 3つは競合ではなく層が違う。決定的な処理はルール、反復する曖昧な判断はローカル決定モデル、難しい推論と生成はクラウドLLM、という三層構成が現実味を帯びています。
- ただし Jev はホスト型APIの早期アクセスで、提供元評価と複数の公開第三者評価はありますが、一般的な順位を確定できる統一ベンチマークはまだありません。「ハルシネーションしない」という表現も、消えるのは出力の形の誤りであって判断そのものの誤りではない点に注意が必要です。
問いの立て方が変わった
ここ数年、AIの議論は「どのモデルが賢いか」を中心に回ってきました。ベンチマークの順位が話題の中心で、モデルの規模は大きくなる一方でした。2026年に入って、この構図がはっきりと変わってきています。争点は賢さの上限から、どこに何を置くかという配置の問題へ移りました。
背景には、実際に動くシステムを作る側の事情があります。稼働中のシステムが1日に下す判断の大半は、小さくて反復的です。「この問い合わせは急ぎか」「これはどの担当に回すか」「この応答はポリシーに触れていないか」「この文書は請求書か」。こうした判断を毎回フロンティアの生成モデルに投げるのは、生成の値段と生成の待ち時間を、ほぼ検索に近い処理に払っていることになります。
クラウドLLMの値下げ、ローカルLLMの実用化、そして決定モデルの登場は、別々のニュースに見えて同じ方向を指しています。以下、4つの話題を順に整理します。
クラウドLLM ―― 性能競争から価格競争へ
フロンティア側で起きているのは、能力の差別化が難しくなり、価格と供給の条件が競争軸になったという変化です。当サイトでも、OpenAI が GPT-5.6 Luna を80%値下げした件や、Grok 4.8 の公表と GPT-6 Astra のAPI提供、「AI IS OVER」が示す価格破壊と投資の再点検を追ってきました。共通しているのは、モデルの入れ替わりが速く、価格は下がり続けているという点です。
クラウドのフロンティアモデルの入力価格は、おおむね100万トークンあたり0.20ドルから10ドルの帯にあり、出力は入力のおよそ5倍というのが一般的な相場です。レイテンシは、TypeSafe AI が引用する第三者ベンチマークでは3秒から329秒に分布するとされます。つまりクラウドは、難しい問題には圧倒的に強いが、安くはなく、速くもないという性質を保っています。価格が下がっても、この構造そのものは変わりません。
ローカルLLM ―― 「手元で動く」が前提になった
この半年でローカル側の景色は大きく変わりました。クラスメソッドの森茂氏による2026年夏版の整理が示す変化は明快です。主役はMoE+4bit量子化に移り、量子化はユーザー側の節約術ではなく配布側が最初から用意するものになり、投機デコード(MTP)が実用段階に入りました。ハードウェアの主戦場も、24GB GPUから128GB級の統合メモリ機へ広がっています。
日本語を含む汎用用途の第一候補は Qwen3.6-35B-A3B(総35B、うち実際に働くのは3B、Apache 2.0)で、実測で投機デコード込み108.3 tok/sという水準に達しています。ツール側では Ollama が0.32系で大きく高速化し、単一ストリームのデコード速度なら vLLM と並ぶようになりました。
| 用途 | 2026年7月時点の推奨 |
|---|---|
| 汎用チャット(日本語) | Qwen3.6-35B-A3B、Gemma 4 26B-A4B |
| コーディング | Qwen3.6-27B-coding、Devstral 2、Laguna S 2.1 |
| コスト効率重視 | Qwen3.6-35B-A3B(Active 3B) |
| 軽量・16GB帯 | Gemma 4 12B(QAT)、gpt-oss-20b |
| マルチモーダル | Gemma 4 26B-A4B(画像入力+MoE) |
| 巨大MoE・推論 | DeepSeek V4 Flash、Kimi K2.6 |
商用利用の観点では、Qwen3.6 と Gemma 4 がどちらも Apache 2.0 で選びやすい2強です。一方で更新が止まっている系列もあり、gpt-oss は2025年8月版、Llama 4 は2025年4月版から後継が出ていません。オープンモデルの進化は中国勢とGoogleの回転が速いという構図が、この半年でより鮮明になりました。
重要なのは、これが「クラウドの劣化版」ではないという点です。入力データを外に出さずに済む、レイテンシが一定である、APIの提供条件や価格改定に振り回されない。ローカルを選ぶ理由は性能ではなくデータ経路と運用の自律性にあります。
第三の道 ―― テキストを生成しない決定モデル
そして2026年9月、この2択とは別の層が立ち上がりました。テキストを生成せず、型付きの判断だけを返すモデルです。代表が TypeSafe AI の Jev と、Convai Innovations の Laya です。
発想は単純です。コードが使いたいのは文章ではなく判断です。if (order.total > 100) のような分岐は書けますが、条件が判断になると途端に崩れます。「この問い合わせは怒っているか」「このメールは請求の話か」「この12個のリンクのどれが購入手続きの続きか」。従来は、分類器を訓練するか、汎用LLMにJSONで出させて解析するか、の二択でした。決定モデルはその中間に位置します。LLMのように実行時に質問を定義でき、分類器のように制約された確率分布を返す。返ってくるのは文章ではなく、確率の付いた値です。
Jev ―― 「賢いif文」という発想
TypeSafe AI は Diogo Almeida 氏(OpenAI で ChatGPT につながる instruction-following 研究に携わった人物)が創業したサンフランシスコのラボで、2026年9月15日にステルスを解除し、DCVC主導で4,000万ドルのシードを公表しました。名前の由来も示唆的です。Jev はジェヴォンズのパラドックス(蒸気機関が効率的になると石炭消費は減らず、むしろ増えた)から、System One はカーネマンのシステム1(速く直感的な判断)から取られています。判断の単価が桁違いに下がれば、これまでLLMを呼ばなかった場所に判断を置き始める、という賭けです。
インターフェースは3つの型だけです。当サイトの先行記事で扱った内容を、その後の資料で補うと次のようになります。
| 型 | 問い | 返るもの |
|---|---|---|
| Noul | これは真か | 確率(0〜1) |
| Choice | どの選択肢か | 選択された値、確率分布、confidence |
| Score | 尺度上どこか | スコア、目盛りの凡例、確率分布、confidence |
設計上重要なのは並列サンプリングです。1回のリクエストに含まれる全質問は、同じ状態に対して独立に並列評価されます。ある質問の答えが別の質問の文脈になることはなく、質問を1つ追加しても応答時間はほとんど変わりません。TypeSafe はこれを「context rot が起きない」と説明しています。加えて、答えは自分で定義した選択肢の上の分布なので、スキーマ外の値は構造的に出せません。同社が示す型エラー率0%は実測ではなく、この構造から導かれる値だと明記されています。
価格は入力100万トークンあたり0.042ドル、出力は「測定するほどではない」として実質無料。公称レイテンシは70〜500ミリ秒です。同社自身のワークフロー評価では193.6倍高速・444.6倍安価という数字が示されていますが、これは同社が自ら設計した評価形式の結果であり、参照モデルの選び方にも偏りがあると同社が注記しています。上限値として読むべき数字です。
国内では FastMetal が2026年9月19日に JEV 1.13 の提供を開始し、1回0.1円の定額・円建て前払いという料金体系を打ち出しています。OpenRouter 経由(typesafe/jev-1.13)でも利用でき、LangChain も2026年9月17日にハーネス構築の記事を公開しました。
Jev は自由テキストを出力しないため、存在しない引用やツール名を作り出すことは原理的にできません。これは事実です。ただしハルシネーションが無いことと、判断が正しいことは別の問題です。3つの許可されたカテゴリに制約されたモデルでも、堂々と間違ったカテゴリを選ぶことはできます。消えるのは壊れた答えであって、誤った判断ではありません。型の保証は形を守りますが、中身は守りません。この区別は、出力がエージェントや決済やセキュリティの動作を制御する場合に決定的に重要です。TypeSafe 自身、この「判断の正しさ」を較正(calibration)で解こうとしており、まさにそこが第三者検証を要する主張です。
Laya ―― オープンウェイトの決定モデル
もう一つの注目が Convai Innovations の Laya です。位置づけは Jev と近く、決定的な違いは重みが Apache 2.0 で公開され、完全に手元で動かせることです。
アーキテクチャは ModernBERT-large を土台に、395Mのエンコーダと2層の決定ヘッド、選択肢マーカーのスコアラ、act/escalate ヘッドを組み合わせた英語版とtyped-decisionsは421M、多言語版は322Mパラメータ。自己回帰ではありません。質問の型は Jev と同じ3種(choice / score / noul)で、選択肢の空間をリクエスト時に定義できる点も共通です。つまり新しい分類体系のために再訓練する必要がありません。
チェックポイントは3つ用意されています。英語向けの laya、100言語以上をカバーする laya-multilingual(mmBERT-base)、型付き決定ワークフロー向けの laya-typed-decisions。Routerは文字体系と言語に基づき英語版または多言語版を選びます。typed-decisionsは通常、明示指定または自動タスク検出の有効化が必要です。重みは1GB未満で、PyTorch/Transformers のほか、Node.js・TypeScript向けの ONNX Runtime 実装や Apple Silicon 向けの MLX 実装といったコミュニティ製ランタイムも出ています。
| Laya の公表ベンチマーク | 数値 |
|---|---|
| レイテンシ(Tesla T4・英語1問) | 39.5 ms |
| レイテンシ(Tesla T4・多言語1問) | 32.8 ms |
| 同・10問/50問(多言語) | 72.3 ms/337 ms |
| バッチ処理(多言語) | 約103〜332問/秒 |
| MLXポート(M3 Max・多言語) | 約7.4 ms |
ただし、Laya の本当の姿は速度の数字よりも専門化の効き方に表れています。型付き決定の評価(400ケース・2,000決定・4ワークフロー)で、ファインチューニング済みの laya-typed-decisions は全体精度0.766を記録する一方、ベースのLayaはゼロショットで0.362にとどまり、多数派クラスのベースライン0.461を下回ります。つまりそのまま落としてきて専門家レベルの判断を期待するモデルではありません。小さな決定モデルを自分の領域に合わせて特化させ、較正して、大量に安く回す——これが想定された使い方です。
較正についても正直な数字が出ています。温度再フィットによって平均ECE(期待較正誤差)を0.466から0.081まで下げられるとされています。逆に言えば、生の確率をそのまま信じてはいけないということです。「リスク0.90超なら人手で確認」といったしきい値を引くなら、自分の実データで較正し直す必要があります。
制約も明確です。Choice は20択程度までが推奨で、それ以上は階層化が有効。順序尺度(スコア)は得意ではなく、近接した段階の識別は苦手です。入力は英語版で512トークン、一部の変種でも1,024トークンにとどまり、長文書を丸ごと入れる用途には向きません。選び抜いた根拠を渡す使い方が前提です。
Jev と Laya、何が違い何が同じか
| Jev | Laya | |
|---|---|---|
| 提供形態 | ホスト型API(早期アクセス) | オープンウェイト(Apache 2.0) |
| 自己ホスト | 不可 | 可(PyTorch/ONNX/MLX) |
| モデル規模 | 非公開 | 英語・typed-decisions 421M/多言語322M |
| 質問の型 | Noul/Choice/Score | noul/choice/score |
| 訓練目的 | RLCD(較正された決定) | RLCD+温度再フィット推奨 |
| レイテンシ | 公称70〜500 ms | T4で数十ms、M3 Maxで7〜13 ms |
| 入力価格 | 0.042ドル/100万トークン | 自前推論のコストのみ |
| データ経路 | ホスト型サービスへ送信 | 手元に留められる |
| 専門化 | 公開された手順なし | ファインチューニング前提の設計 |
この2つは「どちらが優れているか」という比較には向きません。分かれ目は性能ではなく統制の所在です。Jevは運用を提供側に預けます。TypeSafeは確率を較正済みと説明していますが、対象データでの再評価が必要です。Laya は重みそのものを渡し、較正も専門化もデータ配置も利用者の責任にします。どちらを選ぶかは、扱うデータの機微さと、モデルを差し替える自由をどれだけ確保したいかで決まります。
Laya のモデルカードは Jev 1.13.0 とのレイテンシ比較を掲載していますが、そこに挙げられた Jev 側の数値は第三者が公表した値であり、Laya チーム自身が計測したものではないと明記されています。サンプル数もプロンプトも異なります。さらに、その数値は TypeSafe の公称70〜500ミリ秒と約236〜276ミリ秒という第三者測定は公称70〜500ミリ秒の範囲内ですが、対等なベンチマークとして引用できるものではありません。この種の比較は、提供元の主張として読むのが安全です。
三層アーキテクチャという落としどころ
4つの話題を並べると、方向は一つに見えます。単一の万能モデルですべての呼び出しに答えるのは、プロトタイプの型であって本番の型ではない、という認識です。実務的な構成は次の4層になります。
| 層 | 担当する仕事 | 選ぶもの |
|---|---|---|
| ルール | 決定的に決まる処理 | 通常のコード、正規表現、しきい値 |
| ローカル決定モデル | 反復する曖昧な判断、機微なデータの一次判定 | Laya、ファインチューニングした小モデル |
| クラウドLLM | 難しい推論、生成、長文の読解 | フロンティアモデル |
| 人・ポリシー | 影響の大きい判断の承認 | ワークフロー、監査 |
この設計の効き目はコスト削減だけではありません。信頼度が返ることが本質です。確率の付いた判断が第一層にあれば、「確信度が高いものは自動処理、中程度は大きなモデルに回す、低いものは人に渡す」という分岐を、アプリケーションのコードとして明示的に書けます。これまでブラックボックスだった自動化の境界が、しきい値として可視化されます。
そしてこの構成では、判断の層を差し替えられることがシステムの安定性になります。特定のモデルに依存しない呼び出し経路を用意し、ログと認証を一本化しておけば、価格や提供条件の変更に振り回されません。2026年のモデル入れ替わりの速さを見れば、これは過剰な設計ではありません。
AIfrontierの視点 ―― Sign言語と決定モデル
当社が開発を進める Sign言語 は、圏論を土台にした型と合成によって構造の正しさを静的に保証することを目指しています。決定モデルの設計と重なる点が3つあります。
第一に、答えの形を先に決めるという発想です。Sign では型が値の作られ方を制約し、Jev と Laya では選択肢の空間が出力を制約します。どちらも「自由に書ける」ことを手放して、「正しい形しか書けない」ことを得ています。
第二に、判断と生成の分離です。決定モデルは判断だけを行い、文章にする作業はLLMに残します。Sign もまた、意味の確定と実行の分離を設計の中心に置いています。
第三に、較正という共通の課題です。確率が返ることと、その確率が信用できることは違います。Laya の ECE が0.466から0.081に改善するという事実は、返ってきた数値をそのまま使ってはいけないことを示しています。型で保証できる範囲と、経験的に測るしかない範囲を切り分ける——これは Sign が向き合っている問題そのものです。
Signページの Playground では、Sign スキーマから Jev 呼び出しを組み立て、しきい値で分岐とエスカレーションを行う構成をデモとして公開しています。決定モデルを「確率を返す部品」として扱い、その採否をコード側の型としきい値で決める——この分担が実装の出発点になると考えています。
上記は当社の設計思想と公開情報に基づく整理であり、Jev および Laya の性能を当社が独立に検証したものではありません。Jev は早期アクセスの段階で公開ベンチマークが無く、Laya の数値は提供元の公表値です。実運用への採用判断は、それぞれの環境での較正と評価を経て行うべきものです。
これから見るべき3点
第一に、Jev の第三者検証です。最も注目されている数字(193.6倍高速・444.6倍安価、フロンティア相当の精度)は、いずれも提供元自身が設計した評価形式の結果です。公開ベンチマークでの成績と、他人の手によるドメイン固有タスクでの精度が待たれます。
第二に、Laya の専門化の再現性です。ベース0.362からファインチューニング後0.766という伸びが、自分の領域でも再現するかどうか。ここが再現すれば、「小さく特化して大量に回す」という設計が一般解になります。
第三に、主要各社が決定モデルを出すかどうかです。フロンティアの提供各社に、決定専用モデルを投入する理由は十分にあります。人が1日に数回チャットを開くのに対し、ソフトウェアは背景で何千もの小さな判断を下せます。呼び出し回数で見れば、決定モデルの市場は生成モデルより大きくなる可能性があります。判断の単価が下がれば、これまでLLMを呼ばなかった場所に判断が置かれ始める——ジェヴォンズのパラドックスが当たるかどうかは、そこにかかっています。
一次情報
本記事の事実関係は以下の公開情報に基づきます。数値はいずれも各提供元の公表値であり、当社による独立検証は行っていません。
- Jev(TypeSafe AI): 公式ドキュメント / 発表ブログ
- Jev の実装解説: flaviocopes.com — A deep dive into Jev
- Jev の検証状況の整理: TrueFoundry — What "System One Models" Actually Are
- JEV 1.13 国内提供: FastMetal(PR TIMES)
- Laya(Convai Innovations): Hugging Face モデルカード
- Laya の解説と限界: Laya Model: Open-Source Decision AI You Can Run Locally
- ローカルLLMの2026年夏時点の整理: DevelopersIO — 2026年夏のローカルLLM事情を整理してみた