Jev 1.13 解説：モデルが文ではなくラベルで答える理由

Jev 1.13（typesafe/jev-1.13）はチャットモデルではない。そして、それを理解する最速の方法は、他のあらゆるモデルの仕様書を読むときと同じ読み方をするのをやめることだ。TypeSafe はこれを 2026-09-15 に出荷した。同社が「System One モデル」と呼ぶクラスの最初の一員である。状態をひとつと、名前を付けた質問の集合を渡すと、質問ごとに型付きの答えをひとつ返してくる——あなたが用意したリストからのラベル、あなたが定義した尺度上のレベル、あるいは確率が付いた true/false のいずれかだ。散文も、コードも、説明もない。これはローンチ記事ではない。モデル自体は 2026-09-15 のもので、15日が経っており、このブログが執筆対象とする7日間のウィンドウの外にある。だからそれ自体のリリースでページを稼ぐことはない。ウィンドウの中で起きたのは、OrcaRouter が 2026-09-24 に typesafe/jev-1.13 を自社のカタログに追加し、https://www.orcarouter.ai/models/typesafe/jev-1.13 で Jev 1.13 のモデルカードを公開したことだ——Jev が TypeSafe 自身のエンドポイント経由だけでなく、サードパーティのゲートウェイを通じて呼び出せるようになったのは初めてであり、TypeSafe の外部の誰かが公開した初の実際のサービングデータでもある。読む価値があるのはその変化だ。モデルは、動いていなかった場所で動くようになったのだ。

その変化の実用的な形は、小さく具体的だ。2026-09-24より前は、Jevを採用することは二つ目のベンダー関係——TypeSafeアカウント、TypeSafeキー、TypeSafeの請求書、そしてそれに合わせて書くための専用のリクエスト形状——を意味していた。それ以降は、Jevはスタックの残りと同じキーの上に載る。単一のAPIで200+のモデルをカバーし、マークアップ0%（プロバイダーの定価がそのまま渡されるため、ベンダーの値下げはここでも当日に反映される）、そしてモデルはPOST /v1/systemoneでtypesafe/jev-1.13として利用できる。呼び出しは依然として独自の形状で行う——このエンドポイントはOpenAIのchat-completionsルートではなく、そう見せかければ判断ではなく404が返るだけだ——が、署名する契約とローテーションするキーは、すでに持っているものと同じだ。

Jevとはどんなモデルなのか

TypeSafeのローンチ投稿は、それを一文でこう述べている。「私たちの最初の公開モデルはJevで、本日アーリーアクセスで利用可能です。」その後、投稿はこのモデルを「フロンティア知能の関数呼び出し：非構造化状態を入力し、型付き確率的決定を出力する」と位置づけている。これはインターフェースの的確な説明であり、重要な説明でもある。というのも、Jevについての誤った期待のほとんどは、それを小規模言語モデルとして評価することから生じるからだ。それは小規模言語モデルではない。固定された出力文法を持つ決定モデルであり、その文法こそが製品なのだ。

インターフェースにはちょうど2つの入力があります。まず、状態は判定対象となる材料です。メール、サポートチケット、ログ行、JSONレコード、ゲーム座標の配列などが該当します。質問は名前付き項目のマップであり、各項目は型、独自の指示、そして（2つの構造化型については）基準を持ちます。すべての質問はその同じ状態に対して評価され、回答は1つの構造化JSONペイロードとして返されます。TypeSafeのドキュメントでは、質問は並行かつ独立に実行されると説明されており、チューニングではなくその設計から導かれる2つの主張をしています。質問を追加しても応答時間はほとんど変わらず、質問を追加してもコンテキストロットは生じません。なぜなら、各質問は前の質問の下流としてではなく、独立して判定されるからです。

TypeSafe自身の設計ガイダンスは、モデルが何のためのものかを最も明快に述べたものなので、繰り返す価値がある。各質問は原子的でスコープを明確に保つこと——「非常に知識豊富な人なら数秒で下せる種類の判断」だ。判断に拡張された推論が必要だったり、真に複数の独立した要因を組み合わせていたりする場合は、それを別々の質問に分割し、自分のコードで再統合すること。その例はこうだ。一つの「このスタートアップのピッチを評価して」というプロンプトではなく、市場規模、技術的実現可能性、差別化について別々に尋ね、その後、自分の重み付けを適用する。これが重要なのは、重み付けが、書き直さなければならないプロンプトの中ではなく、変更できる係数の中に置かれるようになるからだ。

リスクを考えるエンジニアにとって重要なあらゆる意味で、このモデルはクローズドである。Jev のアーキテクチャ、パラメータ数、トレーニング計算量、重みは非公開だ。TypeSafe の GitHub 組織には重みのリポジトリは存在しない — そこにある 11 の公開リポジトリはツール群、SDK、ワークフロー、無関係な 3 つのフォークであり、そのどれもがこのモデルではない。

「Typed」が製品のすべて

OrcaRouterのモデルカードは3つのプリミティブを公開しており、重要なことに、それぞれの制限も示している。あなたがJevに尋ねるすべての質問は、正確に3つの形のいずれかである：

• {{1}}noul{{/1}} — {{2}}単なる真偽値ではなく{{/2}}{{3}}較正された確率を伴って返される真偽の判定であり、「おそらく真」と「確実に真」が{{4}}区別可能な値となっている{{/4}}。{{/3}}

• choice — 最大255個のラベル付きオプションから1つを選択します。各オプションにはそれぞれのcriteriaテキストが含まれるため、モデルはあなたのラベルを区別する要素を把握できます。

• score — 2～10段階の順序尺度で評価し、各段階の定義を基準とする。

その制約の結果として、散文から解析すべきものは何もなく、モデルが従ったと期待したスキーマに対して検証すべきものも何もない。TypeSafe のローンチ記事はこの保証について異例なほど率直だ。そのプロットにある「0%」というスキーマ不一致の数値は「経験的なものではない。スキーマ一致は保証されているので、プロットに 0% を自信をもって加えられる」と述べている。あなたが提供した回答空間が閉じた集合である場合、返された値はその集合に含まれるか、モデルから出たものではないかのどちらかだ — モデルがもっともらしいが間違った形で何かを書き、あなたの正規表現がそれを黙って受け入れた、という第三の結果は存在しない。

この3つの型は、レビュアーがチャットモデルを評価するようにはJevを評価できない理由でもある。比較すべきMMLU-Proスコアもなければ、読むべき文章サンプルもなく、検査すべき推論トレースもない。意味を持つ唯一の問いは、型付けされた回答が正しいかどうか、そしてそれに付与された確率が誠実かどうかだ。そのどちらも測定可能だが、あなたのデータとラベルに照らしてのみ測定できる。

文書化された相違点が1つあり、解決するというより指摘しておく価値がある。TypeSafe自身のドキュメントには、0からインデックス付けされたScoreの例が示されている一方、OrcaRouterカードはスケールを2–10レベルとして公開している。ベンダーはレベルを文書化しており、当社のカードは2–10を公開している。Scoreの上にルーブリックを構築する場合は、インデックスを仮定するのではなく、自身のレスポンス内のレベル定義を読んでほしい。

なぜ課金対象となる出力トークンが存在しないのですか

料金体系は、このアーキテクチャを最も明快に表している。Jev は OrcaRouter 上で 100 万入力トークンあたり $0.042 かかり、出力料金は 100 万トークンあたり $0.000000 だ。これは割引でも、ローンチプロモーションでもなく、計量できる量が存在しないことによる。生成モデルは、それが書き出すテキストに対して課金される。Jev はテキストを書かない。ラベル、レベル、確率を返す。出力側には数えるものが何もないため、そこでは何も課金されない。

TypeSafeは自社のホームページで、同じ数字を逆の方向から示している——「入力トークン10億あたり42ドル」——さらにそれに比較の主張を添えている。「Claude Fable 5.1より入力価格が238倍低い」。それは、ホームページ上の他のすべてと同様、ベンダー自身によるもので、誰によっても再現されていない。しかし、それが依拠する計算は、読者にとって自分の請求額と照らし合わせて簡単に確認できるもので、そこが役に立つ部分だ。意思決定ワークロードの量は、ほぼ完全に、どれだけの状態を投入するかによって決まる。そして、状態は、生成されるトークンとは違って安価だ。

ベンダーの見出し数値は価格表示よりも大きく、同じラベル付けに値する。TypeSafeは「193.6倍高速、444.6倍安価」と宣伝し、脚注でそれを「System Oneタスク向けのワークフロー」に限定しており、その下に計算例を掲載している。TypeSafe AIは$0.000081で0.114秒で完了し、LLMは$0.013880で8.566秒で完了した。ローンチ投稿自体もこの見せ方のリスクを認めており、193.6倍と444.6倍は「実世界での向上の上限寄り」にある可能性が高いと説明し、並べて比較するデモでは、ベンダーが「自社モデルを有利に見せる」ために選んだ人間可読のキーを使った「高度に簡素化された」クエリを使用したと指摘している。これらの数値はいずれも独立に再現されておらず、ベンダー自身のベンチマークカードも依然として保留中と記されている。

「キャリブレーション済み」とはどういう意味か、そしてRLCDとは何か

TypeSafeは自社の学習手法を自ら「Reinforcement Learning for Calibrated Decisions（RLCD）」と名付けている。RLCDは、同社より前に存在した一般的な機械学習の頭字語ではなくTypeSafe独自の用語であり、その最適化目標はローンチ記事の比較表で「較正された意思決定：System Oneタスクにおける、認識論的に誠実な確率を伴う回答」と述べられている。同じ表が対比しているのは、人間の選好——評価者が好む文章やチャット応答——を最適化するRLHFと、プログラムで検証可能な出力を最適化するRLVRである。RLCDが最適化するのは第三のもの、すなわち、回答に付される確率が、モデル自身の不確実性を正確に述べたものになっていることだ。

実務上、「キャリブレーション済み」とは信頼度についての主張であり、回答が正しいことの保証ではありません。ある質問集合に対して0.8と言うキャリブレーション済みモデルは、その集合全体ではおよそ80%の確率で正しいはずです。ただし、個々の質問では依然として間違っている可能性があります。この区別こそ、TypeSafeのホームページの一文「ハルシネーションゼロ — すべてのJevの判断には信頼度の推定値が付くため、ソフトウェアは信頼度が高いときに行動し、そうでないときにはエスカレーションできます」を誠実に読む方法です。これは信頼度推定の主張であり、エラーゼロの証明ではありません。そして、それに対抗する重しは私たち自身のデータです。2026-09-30で終わる7日間において、私たちのカードはOrcaRouterを経由するJevトラフィックで0.49%のエラー率を計測しています — 同じ期間のより早い時点では0.57%を示していた数値です。なぜなら、これは固定のテストセットではなく、ライブのプレイグラウンドトラフィックのローリング7日間で計算されているからです。どちらの事実も同じ段落に書くべきです。信頼度こそがこのモデルの要点であり、それでもモデルは私たちのトラフィックではおよそ200コールに1回失敗します。

キャリブレーションに関する説明は、そうでなければバグのように見えるレイテンシー挙動も説明している。TypeSafe のローンチ投稿にはこうある。「より高いカーディナリティの選択肢では、独立にスコアリングしてから明示的に選択する2段階システムを採用しているため、時折遅くなります。」255個の選択肢の選択は1回のフォワード比較ではない。ベンダーはスコアリングしてから選択する。大きなラベルセットに対するリクエストが noul より明らかに長くかかるのを見たら、それは混雑ではなく、文書化されたメカニズムである。

今日あなたがそれをどう呼ぶか

OrcaRouter では、モデルは typesafe/jev-1.13 で、カタログ上は「TypeSafe: Jev 1.13」という名前です。context_length は 65,536 トークンで、対応するエンドポイントタイプは systemone の 1 つだけです。OrcaRouter キーで POST /v1/systemone を呼び出し、model フィールド、state フィールド（文字列、オブジェクト、または配列）、および questions マップを送信します。questions マップの各エントリには、type（noul、choice、score のいずれか）、instructions、criteria が含まれます。レスポンスは単一の構造化 JSON ペイロードで、ストリーミングされません。オプトインできるストリーミングモードはありません。

カード自体の契約上の表現は「テキスト入力、構造化JSON出力」であり、設計の前提とすべきなのは公表されている制限です。すなわち非ストリーミングで、状態と質問を合わせて最大およそ64K入力トークン、その上限を超えるリクエストはモデルに到達する前に拒否されます。カタログ項目では、定価を100万入力トークンあたり$0.042と記載し、完了率をゼロと表示しています。これらはベンダーの数値をそのまま通したもので、当社の価格設定方法を比例の形で示したものです。プロバイダー定価に対する0%のマークアップです。

このモデルには2つのトークン予算が出回っており、それらは矛盾しないので、別々に扱ってください。65,536という数値はカードのcontext_lengthであり、状態と質問を合わせておよそ64Kの入力と記載されています。以前のOrcaRouterの記事が引用している「およそ32,000トークン」は状態予算だけを指します。つまり、質問が取り分を取る前にあなたの素材が使える余地です。リクエストの予算を立てる場合、構築するペイロードを制約するのは状態予算のほうで、合計の数値は呼び出し全体の上限です。

Jevにできないこと、率直に述べる

文章を書くこと、要約すること、翻訳すること、会話することはできない。それは設計であり、謝罪すべき制約ではない。ローンチ記事には、Jevは「文字列生成を諦める」と述べられており、TypeSafe自身のjaggednessページでは「Generation」が名前付きの失敗モードとして挙げられ、その横に「生成モデルを使え」という指示が添えられている。無理に生成させると遅く、質も低い。パイプラインに文章による要約が必要なら、Jevは間違ったコンポーネントであり、どれほどプロンプトを工夫してもそれは変わらない。

これは生成モデルの代替ではない。Jevが属するワークフローには2つのモデルがある。テキストを読み、書き、推論する生成モデルと、その傍らでJevがミリ秒単位で型付き呼び出しを行っている。これがベンダーのホームページにあるすべてのコスト比較の正直な枠組みだ —「LLMs」の列は、取って代わられる競合ではなく、同じシステムのもう半分であり、この組み合わせが興味深いのは、意思決定の半分が今では、独自の契約の背後にあるのではなく、生成の半分と同じキー上にあるからだ。

そして「calibrated」は正しいという意味ではない。回答に付された数値が確率として読めるように意図されている、という意味だ。noul における 0.62 は、モデルが確信を持っていないと伝えているのであり、それは単なる「はい／いいえ」なら失われていたはずの有用な情報だ — そして、その「はい」が正しいという約束でもない。信頼度に基づいて組まれたエスカレーション・ロジックが意図されたパターンであり、回答を ground truth として扱うのはそうではない。

数字を正直に読む

カードに掲載している提供指標はすべて、ベンダーのベンチマークではなく、OrcaRouterのプレイグラウンドを通した自社トラフィックから、直近7日間のローリングウィンドウで算出したものです。しかも、この記事を書いている間にもそのウィンドウは動いていました。仕様ではなく、ひとつの読み取り値として扱ってください。2026-09-30までの7日間では、初回トークンまでの時間の中央値が151 ms、p95が247 ms、出力スループットが毎秒約349トークン、エラー率が0.49%、提供トークン数は7,620万でした。ウィンドウ全体の日次p50は175、170、163、161、170、147、143 msと推移しており、緩やかに改善しています。09-28のp95である2,448 msは、その系列の中に実在する単日外れ値であり、それを標準値として引用するのは誤りですが、完全に除外するのもまた不誠実であるという点では同じです。

トラフィックの数値について、もう1つ補足があります。毎秒349出力トークンというと、生成モデルのスループットのように聞こえますが、Jevが生成テキストを一切出力しないことを思い出すと、そうではありません。このメーターが測っているのは、構造化ペイロードに対してレスポンス側で私たちのplaygroundが数える値であり、Jevをチャットモデルと比較するためというより、日ごとの劣化を見つけるのに役立ちます。

これらは私たちの数値です。ベンダーの数値は、193.6x、444.6x、$0.000081の計算例、そしてClaude Fable 5.1との238x比較です。いずれもTypeSafe自身のもので、独立に再現されたものはなく、すべて自社の脚注によって特にSystem Oneのタスクワークフローに限定されています。TypeSafeが行っているパフォーマンス主張のうち、ベンチマークですらないものの、倍率よりも価値があるのは、構造に関する主張です。つまり、回答が型付けされているため、統合には解析ステップもスキーマ検証ステップもなく、それはどのレイテンシ表にも現れないコストです。

何が開いていて、何が開いていないのか

2026-09-30時点で確認したところ、TypeSafe GitHub organizationは11のリポジトリを公開していた。いずれにもJevは含まれていない。モデルを統合する開発者にとって重要なものはすべてMITまたはApache-2.0である：skills（MIT）、system-one-adapter-python（MIT、「LLM APIに支えられたドロップインのTypeSafeClient代替」と説明されている）、typesafe-sdk-js（MIT）、typesafe-sdk-python（MIT）、daggerverse（Apache-2.0）、WorkflowEvals（Apache-2.0、ワークフローコードはevals.typesafe.aiで公開）、n8n-nodes-typesafe-ai（MIT）、typesafe-ai.github.io および pulumi-clickhouse。スター数やプッシュ日は変動するので、これを後で読んでいる場合は、このリストを信用せず再確認してほしい。

11 個のうち 3 つは無関係なプロジェクトのフォークであり、Jev がどのように動作するかについて何も証明しない。2025 年 5 月に最後にプッシュされた vLLM フォーク、2025 年 6 月の LLaDA フォーク — LLaDA は無関係な拡散言語モデルのリリースだ —、そして ClickHouse Cloud 用の Pulumi プロバイダーである。フォーク一覧からアーキテクチャを読み取るのは誘惑に駆られる。だが、そうしてはならない。Jev の設計について、あの 3 つから導かれることは何もない。特に、LLaDA フォークの存在がどれほどそう示唆していても、Jev は拡散モデルではない。

「Jev はオープンソースか」に対する正直な一行の答えは、ツール群はオープンで、モデルはそうではない、というものだ。これはホスト型のフロンティアモデルでは一般的な体制であり、Jev を前提に計画を立てる際に想定すべき体制でもある。すなわち、公開価格、文書化された契約、そして非公開のパラメータ数を持つ API だ。

ベンダーがJevは信頼できないと述べている箇所

TypeSafeはjev-1.13向けの独自のギザギザ度ページを公開しており、最終レビュー日は2026-09-17で、モデルがどこで破綻するかを明記している。これは異例なほど率直で、制限事項セクションを始めるのにうってつけの場所だ。競合他社のリストではなくベンダー自身のリストだからである：

• 文字通りの読み取り — 文言を額面通りに受け取る。適用範囲を示す語、否定、暗黙の条件は推論されず、「あなたが書いた質問に答えるのであって、意図した質問に答えるのではない」。ベンダーによる修正策は、正確な条件と各選択肢の基準を記述することだ。

• 数学と数値 — 電卓ではなく、数え上げも信頼できません。計算はコードで行ってください。

• 日付と時刻の比較 — 日付は順序付けられた数量ではなくテキストとして読み取られるため、並べ替え、間隔、期間は信頼できず、形式が混在しているとさらに悪化します。

• 間接性 — 二重否定やマルチホップ推論は精度を低下させる。ホップを減らし、該当する状態を直接指し示すこと。

• 無関係な詳細で埋め尽くされた大きな状態 — 無関係な内容が注意をそらす要因となり、状態が大きくなるにつれて精度は低下する。まず絞り込め。

• 敵対的コンテンツ — 状態が敵対的として扱われないため、注入された指示や誤解を招くフレーミングによって回答が誘導される可能性があります。

• 矛盾する指示と基準 — その2つが異なることを求める場合、モデルは「混乱するかもしれない」。

• 常識的な構造不変条件 — P(noul) と 1 − P(not noul) が整合していることは保証されない。各決定は一方向で問い合わせ、恒等式をコードで強制せよ。

• 生成 — すでに説明済みであり、ベンダー自身も生成モデルの使用を勧めている。

これらのうち二つは強調に値する。敵対的なほうが重要なのは、Jevの価値提案の全体が信頼できない素材を判断することにあり、指示を含む状態は回答を動かし得るからだ。あなたの状態がユーザーから届くものであるなら、それは他のどれとも同じ形のプロンプトインジェクションの攻撃面になる。構造的不変量のほうが重要なのは、「校正済み」モデルはその確率について算術を行うよう誘い、ベンダーはその算術が閉じると仮定するなと言っているからだ。

ローンチ投稿が約束するもの、そしてそうでないもの

この記事で引用されているベンダーの主張は、ほぼすべて1つのページに遡る。TypeSafe自身の発表で、Company Newsに分類され、日付は2026年9月15日、創業者Diogo Almeidaの署名入りだ。それを直接読む価値は2分ある。なぜなら、ある一行の文言が、それ以降のすべての条件を定めているからだ。「当社初の公開モデルはJevで、本日よりアーリーアクセスで利用可能です。」アーリーアクセスとは、ベンダー自身のプラットフォーム上での提供についてのベンダー自身による説明であり、見た目よりも狭い表明だ。TypeSafeが承認されたユーザーにモデルを提供することを約束するもので、それ以外の誰が提供できるかについては何も述べていない。まさにその隙間を、2026年9月24日のカタログ追加が埋めたのであり、今日Jevを評価する誰にとっても、投稿よりもモデルカードのほうが重要である理由がそこにある。

同じページは、それ自体の限界についても同様に明確であり、だからこそ上記では言い換えずに引用している。そこにはパラメータ数も、「新しいモデルアーキテクチャ」以外のアーキテクチャ記述も、学習コンピュートも、重みのリポジトリも公表されておらず、一般提供の日付や条件も示されていない。これらの不在こそが計画上の制約である。一方には価格が公表されたAPIがあり、もう一方には内部を検査できないスタックがある。この投稿はまた、モデルを仕様として役立つ程度には正直に位置づけている——「フロンティア知能の関数呼び出し：非構造化状態を入力し、型付きの確率的決定を出力する」——これは、その中で野心ではなくインターフェースを説明している唯一の文である。

このインターフェースが提起する疑問

選択セットが255個の選択肢より大きい場合、何が起こりますか？上限があります — 255個のラベル付き選択肢が選択質問の上限であり、基数が増えるにつれてベンダーが採用するのは2段階のスコアリング後に選択するアプローチで、これは大きなラベルセットで時折発生する速度低下の文書化された原因でもあります。タクソノミーがそれより大きい場合、設計上の答えはそれを複数の質問に分解し、コード内で再結合することです。これはTypeSafeが複合的な判断について与えているのと同じアドバイスです。

65,536トークンのコンテキストとは、65,536トークンの状態を意味しますか？いいえ。公表されている予算は、状態とすべての質問を合わせておよそ64Kトークンであり、古い報道に見られる「およそ32,000トークン」という数字は状態のみの予算です。ペイロードの見積もりは合計ではなく状態の数字を基準にしてください。また、制限を超えるリクエストはモデルに到達する前に拒否されることを覚えておいてください。

これをどうすればいいですか

Jev 1.13は、一般的な理由ではなく、特定の理由で一見の価値がある。パイプライン内に、現在チャットモデルにラベルを返すよう求められ、正しい形式で返すことを信頼されているステップがあるなら — ルーター、グレーダー、ポリシーチェック、数千件のレコードに適用されるルーブリックスコアなど — そのステップこそ、このモデルが置き換えるものであり、100万入力トークンあたり$0.042で、出力側では一切課金されない。文章による回答が必要なステップがあるなら、Jevは適したツールではなく、ベンダー自身がそう言っている。

ここ一週間で変わったのは、モデルではない。試すのに2つ目のベンダーとの関係を必要としなくなったことだ。8日前、Jevの評価には別のアカウントと別の統合が必要だった。今日では、すでに200以上のモデルに届くキー上の1つのモデルIDであり、ベンダーの定価は変わらずそのまま渡され、型付きの回答はほかと同じ場所から返ってくる。これほど異例のモデルにとって、新しい契約を交わすことなく自分のラベルでテストできることは、意思決定の大半を占める。