Jev と System One モデル: アプリ設計のユースケース

この 3 年間、「ここに知能を少し足したい」という問題のほぼすべてに対する答えは同じでした。大規模言語モデルを呼び出す、というものです。それは機能します。しかし、しばしば間違ったツールです。驚くほど多くの本番 AI 支出が、出力全体がその場でブール値・列挙型・キュー名・1〜5 のスコアへと即座に折りたたまれる LLM 呼び出しに費やされています。自由形式の生成に対価を支払い、トークンのために数秒待ち、JSON をパースし、そのほとんどを捨ててしまう。しかも、そもそも言語生成が本質ではなかったタスクのために、LLM の最悪の特性――レイテンシ、コスト、そして自信満々にでっち上げた回答の可能性――まで引き継いでしまうのです。

新しいクラスのモデルが、まさにこのミスマッチを狙っています。2026 年 9 月 15 日、TypeSafe AI は Jev をローンチしました。同社が System One モデルと呼ぶものの最初の一つです。これが理解に値するのは、より優れたチャットボットだからではなく――そもそもチャットは一切できません――アプリケーションアーキテクチャに真に新しいコンポーネントを持ち込むからです。本稿は、Jev とは何か、どこに収まるのか、そしてそれを中心にどう責任ある設計を行うかについての実践ガイドです。（冒頭で一点だけ区別しておきます。TypeSafe の Jev は Meta の JEPA 系モデルとは無関係です。）

System One モデルとは実際に何なのか

この名称は Daniel Kahneman へのオマージュです。System 2 の思考は、遅く、意図的で、労力を要します――大規模言語モデルが計画・執筆・説明を行うときの推論がまさにそれです。System 1 の思考は、速く、直感的で、自動的です――なぜそう判断したのか言葉にする前に下す瞬時の判断です。System One モデルはこの第二のモード、すなわちソフトウェアが直接消費する、範囲の定まった高速な意味的判断のために作られています。

具体的には、Jev に何らかの状態（テキスト、またはテキストフィールドからなる JSON オブジェクト）と 1 つ以上の問いを渡します。各問いには、あらかじめ定義された正当な回答の集合が付いています。Jev は確率付きの型付き回答を返し――そして決定的に重要なことに、散文・コード・説明・任意の JSON を生成しません。あなたが定義した空間の中で選択し、スコアを付けるだけです。同じ状態を共有する問いは、それぞれ独立に、並列で評価されるため、1 回の呼び出しで 1 つの文書から複数の判断を同時に引き出せます。

Jev は 3 つの判断プリミティブを公開しており、ほぼすべてのユースケースはそれらの組み合わせです。

重要なメンタルモデルはこうです。あなたが判断とその回答空間を定義し、Jev はその中で較正済みの見解を返す。 これは「LLM にプロンプトを投げて JSON がパースできることを祈る」とは根本的に異なる契約です。

System One 対 System Two: 手早い見取り図

Jev は LLM と競合するというより、決定論的なコードと生成的推論の間の隙間を占めます。この比較こそ、それがどこに属するかの直感を最速で身につける方法です。

実用上の要点は、Jev の最強のライバルはしばしば別の LLM ではない、ということです。安定した、ラベル付けの行き届いた分類問題であれば、従来型の学習済み分類器の方が安価で、完全にセルフホスト可能かもしれません。Jev の優位性が現れるのは、カテゴリが実行時に定義されるとき、新しい問いごとに専用分類器を作るのが経済的に見合わないとき、そして生成テキストから引き出した数値ではなく、較正済み確率を第一級の出力として欲しいときです。

Jev はアプリ設計のどこに収まるか

ある問題が Jev の良い候補になるのは、次の 5 つの性質を備えているときです。入力に、単純なルールでは解けない意味的な曖昧さが含まれている。可能な回答の集合が推論前にわかっている。アプリが散文ではなく機械が消費できる結果を必要としている。判断が、長い推論の連鎖なしに、利用可能な状態から下せる。そしてそれが、LLM のレイテンシとコストが問題になるほど頻繁に起こる。これらが揃うと、同じ少数のパターンが繰り返し現れます。

意図のルーティングと分類。 定番のケースです。サポートメッセージが届く。Choice が担当キューを選び、Noul が返金要求の有無をフラグ付けし、Score が緊急度を評価する――すべて 1 つの状態から、1 回の呼び出しで。かつては数秒かかる LLM プロンプトだったルーターが、サブ秒の判断になり、しかもキュー名は実際に存在するもののいずれかであることが保証されます。

関連性スコアリングと検索ゲーティング。 これこそが意味的コード検索を実用的にするものです。オープンソースの jevgrep ツールは Jev を使い、リポジトリのフォルダ・ファイル・宣言をまたいで関連性を判断します。これにより、コーディングエージェントは文字列を grep する代わりに、振る舞いを記述して正しいコードを見つけられます――作者らは、あるベンチマークのサブセットでエージェントのコストを約 40% 削減したと報告しています。同じパターンは RAG にも当てはまります。広く検索したうえで、生成器に何かが届く前に、Jev に各パッセージの関連性・証拠的裏づけ・矛盾をスコアリングさせるのです。検索と証拠の受容が、別個の観測可能なステップになります。

リアルタイムの判断ループ。 LLM では単純に遅すぎる場面でも、System One モデルはループの内側で動けます。jev-trader プロジェクトは示唆に富む極端な例です。板情報を読み、方向を決め、単一の約 300 ms のブロック内で注文を出さなければならないマーケットメイキングボットです。それはエッセイではなく判断です――そしてそれは、ゲーム・ロボティクス・制御システム・ライブパーソナライゼーションにおける、無数のもっと地味なループの形でもあります。

エージェントとツールのゲート。 エージェント型システムは、全体のタスクが自由形式であっても、範囲の定まった選択に満ちています。どのツールか？続けるか止めるか？この提案されたアクションは危険か？ Jev はそうしたゲートに自然にはまります――Vercel と LangChain はすでにツールルーティングと事前のアクションリスクチェックのために Jev を公開しています。ただし後述の境界には注意してください。Jev はポリシーに情報を与えるべきであって、ポリシーそのものになるべきではありません。

本番評価。 高価な LLM-as-a-judge のために一部のトレースをサンプリングする代わりに、すべてのトレースに対して安価な型付き評価器を走らせられます――正しさ、安全性、ユーザーの不満、ポリシー準拠――そして確率をメトリクスとして保存します。Langfuse は 2026 年 9 月に、まさにこれを実験的な Jev 評価器として出荷しました。必要な判定が狭く型付きであるとき、これは劇的に安価なカバレッジです。記述された理由づけが必要なときは、依然として LLM-as-a-judge に軍配が上がります。

すべてを結びつけるパターン: 確率を意識した選択的自動化

ここが最も重要なアーキテクチャの発想であり、チームが最も頻繁に取り違える点でもあります。Jev の回答は、行動せよという指示ではありません。 それは確率です。その確率をどう扱うかは、あなたが所有する、別個の決定論的なポリシー判断です――そしてそれは、単なる信頼度の数値ではなく、間違えたときの帰結に依存すべきです。

「信頼度 ≥ 0.8 なら行動する」という普遍的なルールは悪い設計です。マーケティングタグを自動付与する方が、資金を放出したり、請求を却下したり、本番インフラを変更したりするよりも、はるかに多くの不確実性を許容できます。正しい形は、信頼度でゲートされたカスケードです。

input → deterministic validation → retrieve & minimize context
      → Jev decision layer → typed answer + probabilities
      → risk-aware policy engine:
            high confidence + low consequence → automate
            middle band / needs reasoning     → escalate to LLM
            uncertain / high consequence       → human review
            policy violation                   → block / safe fallback
      → outcome captured → calibration monitoring → back to policy

これを説得力あるものにするのは経済性です。C_J、C_F、C_H をそれぞれ Jev 呼び出し・フォールバック LLM 呼び出し・人間によるレビューのコストとし、r_F と r_H をケースがエスカレーションする割合とすると、1 判断あたりの期待コストはおおむね C_J + r_F·C_F + r_H·C_H になります。Jev が報われるのは、下流のエラー率を押し上げることなく、これらのエスカレーション率を安全に引き下げられるとき、まさにその場合です。TypeSafe 自身の抽出クックブックもこの形を使っています――安価なモデルが抽出し、Jev が検証し、検証が不確実なときにのみ高価な推論モデルが走る、というものです。

これは目新しい発明ではありません。よく確立された選択的分類のトレードオフ――エラーを下げるためにカバレッジの低下を受け入れる――と、較正、すなわち「90% の確率」と呼んだものが実際に約 90% の頻度で起こるという性質を組み合わせたものです。どちらにも深い研究文献があり、どちらも Jev で設計するための正しいレンズです。

設計時に織り込むべき限界

TypeSafe は、Jev 1.13 について率直な「モデルが弱いところ」ページを公開したことは評価に値します。これらは脚注ではなく、アーキテクチャ上の制約として扱ってください。

2 つの但し書きは、ガバナンスを左右するため強調しておきます。

第一に、「ハルシネーションを起こせない」は正確で狭い主張です。 出力空間が固定されているため、Jev は存在しない選択肢を出力できません――Choice["approve","deny"] は決して「たぶん償却」を返しません。これは形式のハルシネーションを排除します。しかし意味的な誤りは排除しません。deny が正しかったときに approve を返すことはあり得ますし、その「妥当だが間違った」回答は、検証をきれいに通過してしまうぶん、不正な LLM 出力よりもむしろ危険だと言えます。Vercel 自身のドキュメントもはっきりこう述べています――スキーマは回答を制約するのであって、その正しさを制約するのではない、と。

第二に、成熟度こそが本当のリスクです。 本稿執筆時点で、Jev はおよそ 2 週間前に生まれたばかりです。査読済みのアーキテクチャ論文はなく、公開された重みやパラメータ数もなく、再現可能な学習仕様もありません。TypeSafe は自社の手法を「Reinforcement Learning for Calibrated Decisions」と説明していますが、詳細は非公開です――ですから、検証されたパラダイムではなく、ベンダーが説明するパラダイムとして扱ってください。目を引く数値（ベンダーは、比較対象とした LLM ワークフローに対して最大で約 400 倍のコスト削減、約 200 倍のレイテンシ削減を主張）は、TypeSafe 自身のチームが自社のワークフロー上で生成した一次ベンチマークです。それらは、あなたのワークロードで再現すべき有望な仮説であって、SLA ではありません。

これがエンタープライズアーキテクトにとって意味すること

もし実運用システムのために Jev を評価しているなら、いくつかの原則がトレードオフの正しい側にとどまる助けになります。

プロバイダー中立な判断サービスの背後に置く。 すべてのアプリケーションにベンダー API を直接呼ばせてはいけません。内部的な「判断」契約――状態、問い、許可された回答、リスククラス――を公開し、正規化された結果を返させます。これは認証情報を隔離し、しきい値のガバナンスを一元化し、代替案のシャドーテストを可能にし、そして退出経路を与えます。ここでは通常以上に重要です。なぜなら Jev は現時点ではホスト型のみで、セルフホストの選択肢がないからです。データ所在地が譲れないのであれば、その同じインターフェースが SemIf のようなオープンな代替を代わりに前面に立てられます。

モデルバージョンを固定する。 jev-latest のようなエイリアスは、新バージョンが出荷されると移動します。ひとたび特定バージョンに対して信頼度のしきい値を較正すると、告知なきアップグレードがそれを黙って無効化します。jev-1.13.0（またはあなたが検証したもの）を固定し、バージョンの引き上げはモデル移行のように扱ってください――リプレイ、シャドー、カナリア、それからロールアウト。

プロンプトではなく基準を設計する。 報われる規律は、長い chain-of-thought プロンプティングではありません――曖昧な判断（「この請求を承認すべきか？」）を原子的な問い（「ポリシー本文はこの事象を裏づけるか？」「証拠はどれほど強いか？」）へ分解し、それらを決定論的なポリシーコードで組み合わせることです。算術・日付・不変条件・副作用はソフトウェアに置き、Jev には狭い意味的な問いだけを尋ねてください。

ガバナンスはモデルではなくシステムに付随することを忘れない。 採用・融資・安全性のワークフローに組み込まれた非生成の判断コンポーネントは、EU AI Act や NIST AI RMF のようなフレームワークの下でのあなたの義務から逃れられるわけではありません。解決されたモデルバージョン、判断の定義、ポリシーのバージョン、そして結果をログに記録し――影響の大きい判断には人間による不服申し立ての経路を残してください。

正直にまとめれば、Jev はわくわくする専用アクセラレータであって、プラットフォームを賭けるべき土台ではありません。2026 年の正しい姿勢は、中立なインターフェースの背後で、決定論的な安全エンベロープと常時利用可能なエスカレーション経路とともに行う、シャドー → 較正 → 信頼度ゲート → カナリア → 拡大です。そのように進めれば、生まれて 2 週間の確率的モデルを単一障害点にすることなく、潜在的に大きなレイテンシとコストの優位性を手に入れられます。

Big Hat Group とともに判断層を設計する

System One モデルは真に新しい構成要素であり、その価値はほぼすべて、それらを取り巻くアーキテクチャの中にあります――ルーティング、信頼度ゲート、較正モニタリング、そしていつ確率を信頼するかを決める決定論的なガードレールです。それこそ、私たちが行っている AI システム設計そのものです。

Big Hat Group は、エンタープライズチームが自社のスタックのどこに判断モデルが属するのかを見極め、System One / System Two / 人間のハイブリッドアーキテクチャを設計し、安全に運用できるようにするガバナンスとオブザーバビリティとともにそれを立ち上げるのを支援します。

あなたの AI 判断アーキテクチャの設計についてご相談ください →

関連記事: AI ガバナンス 2026: エンタープライズコンプライアンスガイド · AI 成熟度モデル: エンタープライズのレベル

本稿は、TypeSafe の公開 Jev ドキュメントおよびローンチ資料、Vercel・Cloudflare・LangChain・Langfuse の統合ドキュメント、オープンソースの jevgrep および jev-trader プロジェクト、ならびに較正と選択的分類に関する研究文献に基づいています。TypeSafe に帰属する性能およびコストの数値はベンダーによるベンチマークであり、執筆時点では独立に再現されていませんでした。