「System One」というモデルカテゴリー：その中でのJev 1.13の位置づけ

「System One」は、TypeSafeが「決定するモデル」と「書くモデル」を分ける際に用いるカテゴリ用語であり、Jev 1.13（typesafe/jev-1.13）がその最初のメンバーだ — 文ではなく型付きの回答を返すモデルである。これは新しいモデルではない。TypeSafeは2026年9月15日にJevを出荷しており、このページはローンチ記事ではない。モデルは15日前に登場したもので、このブログが執筆対象とする7日間のウィンドウの外にある。ウィンドウ内で起きたのは、OrcaRouterが2026年9月24日にこのモデルをカタログに追加し、Jev 1.13のモデルカードを https://www.orcarouter.ai/models/typesafe/jev-1.13 で公開したことだ — サードパーティのゲートウェイ経由で呼び出せるようになったのは初めてであり、TypeSafe自身のエンドポイント経由にとどまらない。このカテゴリの構想こそがこのページが存在する理由であり、サービングの変更がこれを今日付にしている理由だ。

このカテゴリの平易な説明: LLM は質問を投げかけられ、人が読むための答えを書く。System One モデルは質問を投げかけられ、プログラムが分岐に使う値を返す。TypeSafe 自身の言い方では、「LLM は人のために言葉を生み出す」一方で、「Jev は型付きの決定を生み出し、よりコードに近い。信頼でき、高速で、自己整合的で、型安全である」としている。この文はカテゴリ全体を一つの節に圧縮したものであり、ゆっくり解きほぐす価値がある。なぜなら、四つの形容詞はそれぞれ異なる量の働きをしており、そのうちの一つはほかのどれよりも多くの働きをしているからだ。

「よりコードらしい」が実際に主張していること

4つの主張を順に取り上げよう。それらは「より良い」という同じことを4通りに言い直したものではないからだ。

• 信頼性 — 出力の形はあらかじめ固定されています。あなたが質問を宣言すると、答えは、あなたが許可した値のいずれかとしてしか返ってきません。TypeSafe は「モデルが型エラーを起こすことは決してない」と明言し、これが彼らの主張のうち、反例によって反証することが「数学的に不可能」である唯一の主張だと指摘しています。なぜなら、宣言した集合にない値は、モデルが出力できる値ではないからです。

• 高速 — すべての回答は、トークンを1つずつ生成するのではなく、1回のパスで生成されます。TypeSafeのローンチ投稿では、「Jevはトークンごとに自己回帰的に生成するのではなく、すべての確率を並列に出力します」と述べています。2026-09-30に終了する当社独自の7日間のサービングウィンドウでは、typesafe/jev-1.13の最初のトークンまでの時間の中央値は151 ms、p95は247 msです。

• 自己整合的 — 同じ状態に同じ問いを投げれば、同じ答えが返る傾向がある。コーディングの類推はこれを読み取れる形にするが、それは同時に、類推が証明ではなくなる地点でもある。コンパイラの決定性はその構築の性質だが、これは振る舞いについての主張だ。それについての正直な読み取りとなるのは、われわれ自身の測定だ。同じ7日間のウィンドウにおけるわれわれのプレイグラウンド・トラフィックのエラー率は0.49%であり、つまりそれは、良い関数が自己整合的であるのと同じ意味で自己整合的であり、算術がそうであるような意味ではない。

• 型安全 — そしてこれが最も重い意味を担う項目だ。ここで型安全は品質を表す形容詞ではない。モデルが型チェッカーに対してどこに位置するかについての宣言である。通常の生成パイプラインでは、型システムはモデルが処理を終えた後に始まる。モデルがテキストを書き、パーサーがその形を推測し、バリデータがそれを検証し、推測が外れたケースは失敗パスが処理する。System One モデルは、型宣言を呼び出しの前へと移動させる。私たちのカードが記述している3つのプリミティブが、型システムそのものだ：noulは較正済みの確率とともに返される真偽の判定；choiceは最大255個のラベル付き選択肢から1つ選ばれるラベル；そしてscoreは2〜10段階の順序尺度上の評価である。プリミティブを選び、ラベルまたは基準を与えれば、返ってくる値はその集合から取り出される。

TypeSafeは、自社のドキュメントと当社のドキュメントの間に、解決するというよりは明言しておく価値のある相違点を1つ公開しています。ベンダーのドキュメントではゼロインデックスのScore例が示されている一方、当社のカードではスケールを2～10レベルとして記載しています。どちらも同じプリミティブを説明しています。しきい値を構築する場合は、お使いのSDKがどのインデックス方式に準拠しているかを、ベンダーのページで確認してください。

停止させる2つの故障モード

「散文なし」の興味深い帰結は、美的なものではない。それは、本番の生成パイプラインを支配する2つの失敗が、この設計によって緩和されるのではなく、そもそもこの設計には存在しないということだ。

フォーマットのドリフトがまず第一だ。JSON を返すように指示された LLM は、ほとんどの場合は JSON を返すが、残りの場合は JSON に近い何か——末尾のコメント、markdown のフェンス、同義語に改名されたフィールド、スキーマが文字列を求めている箇所のネストされたオブジェクト——を返す。プロンプトレベルの修正（より強い指示、few-shot の例、システムメッセージ内のスキーマ）はどれも、モデルが自由に放棄できる形を保持しようとする試みだ。なぜならその形は制約ではなく要求だからだ。TypeSafe の枠組みはその対比を明示している。文字列の場合、「取りうる出力と構造」は要求されるものであり、応答は「パースして検証する必要がある」。そして「AI が脱線するリスクは常にある」のだ。取りうる出力が事前に宣言されていれば、ドリフトは行き場を失う。

解析不能な出力は2つ目のものであり、それは実際には同じ障害がさらに悪いタイミングで起きているにすぎません — 少し誤った値が返ってきたフィールドではなく、パーサーがまったく読めない応答が、ワークフローの中で最も都合の悪い時点で届くのです。型付きの値を出力するモデルには、そのような状態はありません。

これは構造的な議論であり、そのように述べられるべきものだ。個々の答えが正しいかどうかについては何も語っていない——選択式の問題が誤ったラベルを選ぶこともあれば、正直な答えが偽であるときに noul が高い確信度でtrueを返すこともある。消え去るのは、パーサーなら捕捉していたはずの失敗というカテゴリーだ。それは現実的で有用な削減であり、「答えは正しい」という主張と同じものではない。

なぜ価格は「形」であり、割引ではないのか

このモデルの価格は100万入力トークンあたり0.042ドルで、出力の請求はゼロです。そしてこのゼロはプロモーション価格ではなく、設計上の産物です。構造化された回答を3トークン出力するモデルには計量すべき出力量がないため、出力トークン単位の価格設定には結び付ける対象が何もありません。課金の形は、入力トークン単位の課金と一つの判断です。当社のカタログはプロバイダーの定価を0%のマークアップでそのまま反映しているため、0.042ドルは当社が設定した数字ではなくTypeSafeの数字であり、ベンダーの価格変更は同日に有効になります。

二つの形を並べてみれば、その違いはパーセンテージの問題ではない。生成パイプラインのコストは、モデルがどれだけ話すかに比例する。同じ意思決定でも、冗長な回答は簡潔な回答より高くつき、chain-of-thought推論モデルでは、回答が改善するかどうかに関わらず、答える前に考えるために費やしたトークン分が課金される。System Oneの呼び出しコストは、どれだけ見せるか、つまり状態と質問の量に比例する。長い文書に対して質問を一つ投げれば、文書の分を支払うことになる。同じ状態に対して40個の質問を詰め込めば（私たちのカードの入力バジェットは、状態と質問を合わせて65,536トークン、およそ64Kです。以前のOrcaRouterの記事で「およそ32,000トークン」という数字を見たことがあるなら、それは状態バジェットだけであり、競合する合計値ではありません）、文書の分は一度支払うだけで、40の意思決定が返ってくる。

だからこそ、このクラスにとって適切な単位はトークンあたりのコストではなく意思決定あたりのコストなのだ——そして、ほとんどのチームが予想するのとは逆方向にメーターが回る理由もそこにある。生成AIにおける典型的なコスト削減策は「モデルに話させる量を減らす」ことだ。しかしここでは、減らすべき言葉がそもそも何もない。

TypeSafe自身の数値は、ベンダーが報告したもので、独立して再現されたものではないが、まさにその比較を狙っている。「193.6倍高速、444.6倍安価」とされ、脚注には「System Oneタスク向けのワークフローに基づく（証明）」とあり、計算例として「TypeSafe AIコスト $0.000081、完了時間 0.114秒 / LLMコスト $0.013880、完了時間 8.566秒」が示されている。ホームページにはまた「入力トークン10億あたり42ドル」が「Claude Fable 5.1より入力価格が238倍低い」と対比して掲載されている。これらすべては、測定結果ではなくベンダーの主張として扱うべきだ。ローンチ記事は「当社が公開している評価は、通常、西海岸にある当社のノートPCで実行されている」こと、また「それが補助金で支えられていないことを証明できない。価格の持続可能性を証明するには長期的な検証が必要だ（価格は上がるのではなく下がると予想している）」ことを認めている。これら二つの譲歩はベンダー自身によるものであり、ページ上のあらゆる倍率を解釈するための適切な枠組みである。

キャリブレーションはアイデアの後半です

もしカテゴリが「構造化出力」だけなら、それは余分な手順が付いた関数呼び出しを説明するものになるだろう。これが独自のものになるのは、すべての回答が確率とともに届き、その確率が訓練ターゲットになる点だ。TypeSafe はこの手法を Reinforcement Learning for Calibrated Decisions（RLCD）——彼らの用語であり、一般的な頭字語ではない——と呼んでおり、ローンチ記事の比較表では RLHF と RLVR の隣に置いている。RLHF は人間の評価者が好むものに向けて最適化し、RLVR はプログラムで検証できる出力に向けて最適化し、RLCD は「System One のタスクにおける認識論的に誠実な確率を伴う回答」に向けて最適化する。

実用的な違いは、その確率が何のためのものかにある。生成パイプラインでは、信頼度の推定は二次生成である。モデルにどれだけ確信があるかを尋ねると、数値を書き出すが、それ自体が同じ失敗モードを持つ文章である。ここでは、確率は同じパスで判断とともに返ってきて、それが分岐の基準になる。TypeSafe自身の説明では、その利点は、タスクを95%の確率で実行できても「5%に入っているときにそれを言わない」モデルはタスクの自動化には使えない、というものだ。信頼度は、人または推論モデルへのエスカレーションを置く場所を与えてくれる。

TypeSafeのホームページはこれを「Zero Hallucinations」と表現し、あらゆる判断が信頼度の推定値を伴うため、ソフトウェアは「信頼度が高いときは行動し、そうでないときはエスカレーションできる」と説明している。これをよく読んでほしい。これは信頼度の推定値についての主張であり、答えが決して間違わないという主張ではない。私たち自身のカードはそのカウンターウェイトだ——2026-09-30で終わる7日間におけるエラー率0.49%、私たちのトラフィック上で、私たち自身が測定したものだ。この数値はローリングウィンドウであり、固定されたテストセットではない。同じウィンドウで数日前には0.57%を示しており、また動くことになる。

System OneがSystem Twoの隣に位置する場所

「速い/遅い」という語彙は、TypeSafe よりずっと前から存在する。それはカーネマンの『ファスト&スロー』に由来し、これより何年も前から AI 研究者たちに借用されてきた——「システム2」は、TypeSafe が存在するはるか前から思考の連鎖や熟慮的推論モデルに結び付けられており、TypeSafe はどちらの用語も造語したとは主張していない。彼らがしたのは、その区別をプロンプティング・モードではなく製品の境界に適用することだ。

• システム2推論モデルは、答える前により多くの計算資源を消費し、それを必要とする問題でより良い性能を発揮する。その出力は依然として散文であり、余分な計算は出力トークンとして課金される。

• TypeSafe流のSystem Oneモデルは、より良い答えを出すために長く考えることはない。一つのパスで答え、速度と引き換えに諦めるのは、型付きの値以外を生成する能力である。

• この2つは比較における競争相手ではなく、ワークフローにおける補完物です。System One の呼び出しは、高速で安価かつ判読可能でなければならない意思決定を処理し、推論モデルは信頼スコアが不確実としてフラグを付けたケースを引き受けます。型付き出力こそが引き継ぎをクリーンにします — 次の段階に渡すのは、再解析が必要な文ではなく、値と確率です。

用語がすべりやすくなるのは、「System One モデル」を、他のベンダーが採用した確立されたカテゴリーとして扱うときだ。そのような証拠はなく、このページはそう主張しているものとして読まれるべきではない。TypeSafe は自社のモデル群に対してこの用語を使っている。私たち自身のカードにある免責事項も、単一のモデルに対して単一のエンドポイント種別を挙げることで、同じことを暗に述べている。もし別のラボが同じアーキテクチャに対してこの言い回しを使い始めれば、それは報じる価値のある事実であり、それを報じるには彼ら自身の言葉が必要になる。

私たちのカードでは、ギザギザさを驚きとしてではなく、正直な境界線の一部として挙げています。9つの名前付き失敗モードです。文字通りの読み取りと間接参照の項目は、「よりコードに近い」という類推から直接導かれるものです——あなたが意図した質問ではなく、あなたが書いた質問に答えるモデルは、コードが言ったとおりに正確に実行した関数のように振る舞っています。数え上げの項目はそうではありません。「数え上げるのではなく、答えの形を認識する」モデルは、まったくコードらしくありません。それこそが、TypeSafe自身の推奨が、コードで数えること、そして本当に判断が必要な場合には項目ごとに1つの質問をして自分で答えを合計することである理由です。

デザインを形作る2つの制約であり、スコアではない

どちらも同じところから来ています。文字列がなければ、ストリーミングするものも、分割して送るものもありません。

• 非ストリーミング — 最初の出力が完成した回答であるため、System One の呼び出しは単一のレスポンスであり、ストリームではない。問題はストリーミングできるかどうかではなく、何がストリーミングされるかだ。

• ひとつのリクエスト形状 — このモデルは、chat-completions 形式ではなく、当社のカタログ上で POST /v1/systemone を通じて提供されます。そしてこれが、「独自のリクエスト形状を話す」という以前の主張の正直なバージョンです。呼び出し方には実際の違いがあります。state オブジェクトと named-questions マップを入力し、質問ごとに構造化された回答が出力されます。あなたはそのためのマッパーを書くことになりますが、出力が型付きであるため、マッパーが統合のすべてです — その下に防御的なパース層はありません。

ロードテストの前に知っておくべきこと：レイテンシは質問タイプによって一定ではありません。TypeSafeは自身の言葉でその理由を説明しています — 「より高いカーディナリティの選択肢の場合、我々は独立してスコアリングを行い、その後明示的な選択を行う2段階システムを採用しているため、時折遅くなるのです。」4つの選択肢のルーティング決定と200の選択肢の分類は、紙の上では同じプリミティブであり、実際には異なる作業量です。2026-09-30で終わる7日間の日次中央値は175、170、163、161、170、147、143 msです。そのシリーズのある日、2026-09-28は、p95が2,448 msでした — 正直にシリーズに存在する実際の単日外れ値ですが、サービスの形状ではありません。

初回統合の前に知っておくべきもう一つのことは、何に接続しようとしているかだ。Jev をめぐるツール群は MIT および Apache-2.0 ライセンスのオープンソースである——Python と JavaScript の SDK、通常の LLM API を基盤に同じクライアントを提供するアダプター、workflow-evals のコード、そして一連のエージェントスキルで、いずれも TypeSafe の公開リポジトリにあり、スター数とプッシュ日は 2026-09-26 と 2026-09-29 という最近の日付まで更新されている。モデルはそうではない。重みのリポジトリは存在しない。Jev のアーキテクチャ、パラメータ数、学習コンピュート、重みは非公開であり、それを確認する読者は、その組織にある無関係なプロジェクトのフォークである3つのリポジトリ——vLLM のフォーク、2025年の拡散言語モデルのリリース、Pulumi プロバイダー——に惑わされるべきではない。それらのどれも Jev がどのように作られているかについては何も語っていない。一言で言えば、ツール群はオープンで、モデルはオープンではない。

今日それを実行すること、そして読者にとって何が変わるか

Jev 1.13 は OrcaRouter 上で typesafe/jev-1.13 として提供されており、200 以上の他のモデルと同じキーでアクセスできます。プロバイダーの定価が 0% のマークアップでそのまま適用されます。カテゴリについてのページにおいて、その実用的な価値は限定的であり、正確に述べておく価値があります。System One のモデルを試すのに、まだ必要かどうかわからないモデルのために別のアカウント、別のキー、別の請求書を用意する必要はもうありません。それは同じワークフローの生成側の半分の隣に位置します — 分類器とライターが 1 つの認証情報で、1 か所に、実際に呼び出したもののカウント付きで。

ここにあるものはモデルが何であるかを変えるものではない。それは2026-09-15にローンチされ、TypeSafeは今もアーリーアクセスだと説明している。それが何であるかはそれ以降変わっていない。2026-09-24に変わったのは、読者が先に2社目のベンダー関係を結ばなくても、実際にいくらかかるのかを把握できるようになったことだ。このカテゴリがプロトタイプを作る価値があるかどうかを見極めようと待っていたなら、動いたのはまさにその点だ。