公開情報で分かる、Jev とは何か
2026年9月15日、TypeSafe AI は最初の公開モデルとして Jev（ジェヴ）の早期アクセスを始めました。創業者の Diogo Almeida 氏による発表では、Jev は System One Model と呼ぶ新しい系統で、ソフトウェアがそのまま使える、速くて構造化された判断を返すことを目的にしています。人が読むチャットの先にある自動化を、文章生成の延長ではなく、別のインターフェースで解こうとする試みです。
名前の由来も公開されています。系統名は、心理学者ダニエル・カーネマンの『ファスト＆スロー』にある、速い直感的な思考（システム1）と遅い熟慮（システム2）の区別に由来します。Jev という名は経済学者ウィリアム・スタンレー・ジェヴォンズから取られ、効率が上がると需要が増えた、という歴史上の観察を、知能のコスト低下に重ねたものだと説明されています。
ドキュメント上の使い方は、次の骨格です。入力は state（判断の材料。文字列、JSON、テキストの配列）と、型付きの questions（質問）です。出力は文章ではなく、型の決まった答えと確率です。質問は三つです。Choice は候補から一つを選ぶ判断で、確率と確信度が付きます。Score はルーブリック（評価の段階基準）に沿った点数で、やはり確率と確信度が付きます。Noul は「その記述は成り立つか」を 0 から 1 の確率で返す二値の判断です。複数の質問は同じ state に対し、1回のリクエストの中で並列に、互いに独立して評価されます。API は POST /v1/systemone です。ドキュメントの例ではモデル名 jev-latest が使われ、この別名は記事執筆時点でバージョン固定の jev-1.13.0 を指すと書かれています。
入力はテキストに限られ、画像・音声・動画はそのままでは扱えません。1リクエストの文脈長は 64k トークン、state と最も長い質問を合わせた上限は 32k トークンです。料金は入力 100 万トークンあたり 0.042 ドル、出力トークンは無料と公開されています。応答時間について同社は、System One 向けの問い合わせでおおよそ 70 ミリ秒から 500 ミリ秒と述べています。学習は、較正された判断のための強化学習（RLCD、Reinforcement Learning for Calibrated Decisions）と呼ぶ方法だと説明されています。顧客ごとのファインチューニングは行わず、顧客のリクエストや応答で再学習もしないとドキュメントにあります。英語が主な学習言語で、日本語を含む CJK（中国語・日本語・韓国語の文字）は扱えるものの、精度は同等ではない、という注意もあります。
型について同社は、ありうる出力と構造を事前に決めるため型エラーは起きない、と述べています。これは「判断が常に正しい」という意味ではありません。公式の jaggedness（でこぼこ、既知の弱点）の文書は jev-1.13 を対象に、2026年9月17日時点でレビューされています。そこでは、指示を額面どおりに読む、数え上げや日付の比較が弱い、遠回しな推論が苦手、関係のない情報が多いと精度が落ちる、敵対的な文面に影響されうる、別々の質問の確率が足して 1 になるといった恒等式は保証されない、文章の生成には向かない、と自ら限界を列挙しています。Choice の候補数については、発表の中で上限 255 が触れられています。
発表では、System One のタスクにおいて既存の大規模言語モデル（LLM）と同程度の知能を、おおよそ二桁速く・効率的に出せる、とも述べています。ワークフロー評価に由来する「193.6 倍速い、444.6 倍安い」という数字も、同社サイト上の自社計測として示されています。同時に同社は、この倍率は実運用では上振れ側になりやすいこと、評価を作ったチームに偏りがありうること、参照答案が他社の大規模モデルの平均であることに留保を付けています。独立した第三者の再現としてではなく、公開された自社計測として受け取るのが妥当です。
文章生成やコード生成との、発想の違い
ここからは、公開されている設計思想を開発の言葉に置き換えた整理です。速度や費用の優劣を断定するものではありません。
現場に入ってきた LLM は、人が読む文章を生成することに最適化されています。チャット、下書き、手順の説明。出力は文字列です。ソフトウェアに渡すときは、JSON を生成させてからパースし、スキーマで検証する段が入ります。形式が崩れる、余計な文章が混ざる、表明された自信と実際の正答率がずれやすい、といった問題は、生成という自由度の裏側に残ります。
コード生成 AI は、その文字列の中身がプログラムである場合です。設計のたたき台や定型的な実装を速くする力は大きい一方、生成されたコードが正しいかは、テスト、型検査、レビューが担保します。モデル自身が「この分岐でよいか」を、呼び出し元がそのまま使える型として返すわけではありません。
Jev の公開されている発想は、その逆側にあります。文字列の生成を手放し、質問の時点で答えの形を決めておく。確信度や確率が、分岐の材料として最初から付いてきます。同社の表現を借りれば、非構造の state を入れ、型付きの確率的な判断を返す、関数呼び出しに近いものです。複数の観点は一つの長い指示に詰め込まず、一つのことに絞った質問に分け、重み付けや組み合わせは周囲のコードが持つ、という推奨もドキュメントにあります。質問は、知識のある人が適切な文脈を見れば数秒で下せる判断、という粒度が想定されています。
これは、LLM の置き換えとして発表されているわけではありません。発表文でも、チャット、コーディング支援、正しさを自動で確かめられる問題での試行錯誤は LLM の領域として整理され、Jev 側には分類、振り分け、採点、ガードレール、待ち時間の短い判断が例示されています。文章が要る仕事と、判断が要る仕事を分ける、という役割分担の提案だと読むのが、公開情報に近い理解です。
設計、実装、型安全、レビュー、運用への含み
この節は考察です。公開されたインターフェースから、各工程で何が変わりうるかを考えます。導入すれば効果が得られる、という主張ではありません。
設計では、「どこまでをルールで書き、どこからをモデルに渡すか」の線を引きやすくなる可能性があります。料金区分や在庫の有無のように条件が閉じている処理は、これまでどおりコードです。問い合わせの緊急度、文章の意図、禁止事項への当てはまりのように、文言の解釈が必要な箇所だけを質問にする。公式ドキュメントも、計算、数え上げ、日時の前後はコードに残し、モデルには意味の判断を渡すよう勧めています。設計の成果物は、長いプロンプトそのものより、「どの判断を、どの型の質問にし、どの確信度から自動で進め、どこから人に戻すか」という仕様に近づくかもしれません。
実装では、条件分岐が真偽値だけでなく、確率としきい値の組になる場面が増ええます。たとえば Noul が一定以上なら自動で振り分け、それ未満は人に回す、という書き方です。しきい値は用途ごとに決めるもので、公式の例でも「いくつにするかは利用側が決める」とされています。質問を足しても応答時間がほとんど変わらない、という説明が自社の処理で成り立つなら、一つの巨大な判定より、観点ごとの小さな判定を並べる実装が自然になります。しきい値を調整したあとは、jev-latest のような移動する別名ではなく jev-1.13.0 のような固定の ID を使うようドキュメントが勧めています。応答の model フィールドには、実際に答えたバージョンが入るため、ログに残す前提で設計できます。
型安全は、言葉を分けておきたい論点です。TypeScript の型は、プログラムの値の形をコンパイル時に検査します。Jev が言う型安全は、モデルが決めた構造の外の値を返さない、という実行時の約束です。両方が揃うと、パースに失敗して落ちる事故は減らせる可能性があります。一方で、中身の判断が業務として正しいかは、型では保証されません。公式も、スキーマの一致は保証できるが、知能や速度の強い主張は別の評価だと区別しています。既存の型検査、テスト、権限を置き換える部品ではなく、判断の入出力を型の内側に閉じるための部品、と見るのが安全です。
レビューでは、二つの使い方が考えられます。一つは、確信度が低い判断だけを人が見るキューにすること。もう一つは、発表で例示されているように、別の LLM の出力やその途中経過を採点し、検証し、危険な指示を検知する側に置くことです。コードレビューそのものを代替する、という公開情報はありません。差分の意図が仕様に沿うか、危険なパターンが含まれるか、といった閉じた問いに分解できたときに、レビューの補助線になりうる、という範囲に留めるのが妥当です。
運用では、速度と単価の主張が自社の経路で再現できるなら、画面の待ち時間や大量データの処理の中に判断を置きやすくなります。同時に、レート制限（単位時間あたりの呼び出し上限）は需要に応じて変わりうるとドキュメントが明記しています。記事執筆時点の記載は、毎秒 10 万トークン、毎秒 40 リクエストで、超過時は 429 が返ります。早期アクセスであること、英語以外は自社の文面で確かめる必要があること、敵対的な入力を標準では敵対的と扱わないことも、運用設計に入ります。顧客リクエストでは学習しない、という記載はデータを預ける判断の材料にはなりますが、契約条件は各社のリーガル文書で確認する必要があります。
期待できることと、まだ分からないこと
公開情報の範囲で期待してよい性質は、次のようなものです。答えの形が事前に決まり、確信度や確率と一緒に返る。質問を分解し、組み合わせのルールをコードに残せる。テキストについての判断を、人が読む文章の生成とは別の部品として置ける。入力単価が公開されており、出力トークンは課金されない。
まだ分からないことも、同じくらいはっきりしています。ワークフロー評価は同社の計測であり、第三者による再現や、自社の業務での正答率は別問題です。料金が長期にこの水準で続くかは、同社自身がこれから示す、と書いています。でこぼこの一覧は jev-1.13 時点のもので、次の版でどこまで直るかは未公表です。画像などの直接入力は、まだ対応していないと明記されています。早期アクセスのため、利用枠や商用の条件はアカウントごとに異なりえます。日本語は「扱えるが、英語と同等ではない」とある以上、帳票、方言、社内用語でどの程度使えるかは、公開情報だけでは分かりません。確信度が高いほど実際の正答率も高い、という較正は同社の主張であり、Score の段階そのものは数値としての精密さに弱い、とも公式が注意しています。
開発チームが今から持てるとよい視点
モデルの採否を急ぐ必要はありません。先に整理できるのは、業務の中にある「曖昧だが、繰り返し起き、答えの候補を人が列挙できる判断」です。振り分け、優先度、禁止事項への当てはまり、危険な依頼の検知。候補を列挙できない文章作成や、正確な計算が本体の処理は、これまでどおり生成モデルやコードの側に残す。この切り分けは、公式が挙げる失敗例とも整合します。
試すときには、質問を一つずつに分け、確信度の低いものを人に戻し、モデルのバージョンを固定し、どの版が答えたかをログに残す。無関係な文脈を長く渡さない。日本語の実データでしきい値を決める。計算はコードに残す。これらは、特定の製品の有無にかかわらず、判断をソフトウェアに渡すときの基本です。
sorena が伴走で大切にしているのも、新しいモデル名を先に置くことではなく、現場の判断がどこで生まれ、どこで人が見るべきかを一緒に描くことです。判断を返す AI が広がるとしても、責任の置き場所と、止める条件は、導入する側の設計に残ります。公開情報を一次ソースで追い、自社の問いに対して小さく確かめる。その姿勢が、これからのシステム開発ではますます実用的になると考えています。