Jev 1.13 が破綻する箇所：TypeSafe 自身の限界リスト

Jev 1.13（typesafe/jev-1.13）は2026-09-15にリリースされた。これは直近7日間から2週間外れているため、そのローンチが本題ではない。日付の付いた出来事は2026-09-24だ。その日にOrcaRouterがtypesafe/jev-1.13をそのカタログに追加し、モデルカードを公開した——サードパーティのゲートウェイにおけるJevへの初のサービングサポートであり、それまでの2週間、それを呼び出す唯一の方法はTypeSafe自身のエンドポイントだった。これがここで重要であるのには、ある特定の理由がある。Jevは、そのベンダーが失敗する方法の一覧を公開しているという点で珍しい。そして、読むことしかできない一覧は、実際に呼び出せるモデルよりもはるかに飛ばしやすい。

このページはそのリストであり、TypeSafe 自身が述べている内容に限定し、さらに運用上の制限と請求額を加えたものです。

TypeSafeは独自のギザギザリストを公開している

docs.typesafe.ai には、次のタイトルのページがあります：Jev 1.13 のギザギザした箇所。これは明示的に jev-1.13 を対象としており、レビュー日は 2026-09-17 で、冒頭はベンダー自身の説明で次のようになっています：「Jev は完璧ではありません。ここに挙げるのは、jev-1.13 について私たちが把握しているいくつかのギザギザした部分です。これらの多くは今後のバージョンで修正される予定です。」続いて9つの名前付きモードがあり、それぞれに具体的なケースと「代わりに：」という対処法が付いています。以下の内容は推測ではなく、やわらげられてもいません。文言は TypeSafe のものであり、同社が自らの例を挙げている箇所では、その中の数字も同社のものです。

文字通りの読み方では、それはあなたが書いた質問に答えています。

範囲を限定する語、否定表現、暗黙の条件は、額面どおりに解釈される。質問は、指示内の文言に基づいて回答される。「一方、人間なら指示の背後にある意図を読み取ったかもしれない。」

ベンダーの診断が役に立つ部分だ。誤った回答を見て、自分が本当は何を意図していたのかを説明していることに気づくとき、その説明こそが指示の欠けていた半分である。対策は、指示に正確な条件を明記し、判定基準に境界事例を入れ、解釈がどうしても避けられない場合には、質問を二つの文字通りの問いに分割し、コード内で結合することだ。

数学と数：それは{{1}}KEEP{{/1}}ではありません

TypeSafeは、数学的論理をコードで実装するようはっきりと言っている。その根底には3つの具体的な失敗がある：

• 数え上げは信頼できない。これには、単語内の文字数、文章中のある語の出現回数、長いリスト内の項目数が含まれる。「モデルは数え上げるのではなく、答えの形を認識しており、数える対象の規模が大きくなるほど誤差も大きくなる。」そもそも尋ねるべきかどうかについてのベンダー自身の基準は、正規表現やパーサーでその単位を見つけられるなら、そのカウントはコードに属し、モデルは何も付け加えない、というものである。

• 数値表現は意味表現より性能が劣る。16進値を使って色について尋ねる質問は、英語の色名を使って同じことを尋ねる質問より劣る。RGB三つ組や16進値が与えられても、Jev は2つの値が互いに近いかどうかを信頼性高く判断できない。同じギャップは、低水準コード——アセンブリやバイナリ符号化された命令——と高水準言語との間でも見られる。コード内で変換またはバケット化し、真に判断を要する部分にはモデルを残すこと。

• スコア出力は正確な数値の大きさを持たない。ベンダーは、Jevのスコアレベルは数値的キャリブレーションが弱いと述べている。期待値は、何かが閾値を超えるかどうかをテストするために使用できるが、最も近い2つのレベルの間を補間して数値を再構成するために使用することはできない。これは、スコアを測定値として読むという、ある種の誤用全体に対する断固たるノーである。

日付と時刻: 日付は数値ではなくテキストとして読み取られます。

2つの日付を並べ替えること、それらの間の隔たりを測ること、あるいは一方がウィンドウ内に収まるかどうかを判断することは信頼できず、混在した形式、相対的な参照、そして四半期や決済ウィンドウ、経過期間といったドメイン上の境界によってさらに悪化します。

推奨される分割は明快です。抽出は判断なので、モデルに任せましょう。日付の各構成要素は、12か月、最大31日、有限の年の範囲という小さな閉じた集合です — これにより、抽出は自由形式の解析ではなく、列挙された選択肢からの選択になります。また、明示的な「未記載」を入れる場所ができるため、欠けている部分は推測ではなく報告されます。コードが各部分を組み立て、それ以降のすべて、つまり順序、期間、オフセット、曜日を担います。

間接性：二重否定と余分なホップは精度を損なう

二重否定や重層的な間接表現を含む指示は、回答の信頼性が低くなる。ある性質の性質についての質問や、数段階の推論を要する質問は、精度を損なう。その対策は、指示をできるだけ直接的に書き、状態の関連する部分を説明するのではなく名指しすることである。

無関係な詳細で満たされた大きな状態は精度を損なう

判断に関係のない内容によって状態が大きくなるにつれて、精度は低下する。無関係な詳細は気を散らす要因として働き、また状態が大きいと、入力のどの部分が誤った回答を生み出したのかを判別するのが難しくなる。TypeSafe 自身による末尾の注記での注意喚起は率直だ。「Jev はコンテキスト腐敗に悩まされるため、状態内の無関係な材料は精度を損なう。」

まずコード側で取得とフィルタリングを行い、その質問に必要なフィールドだけを送信します。リクエスト前のフィルタリングができない場合、ベンダーは noul を使って関連性で絞り込み、残ったものを判定することを推奨しています。

状態内の敵対的コンテンツが回答を動かす

状態はデータであり、jev-1.13 はそれをデフォルトで敵対的なものとして扱わない。注入された指示、意図的に誤解を招く枠組み、あるいは自らの結果を正当化しようとするテキストが、結果を変え得る。これが、ベンダーが修正を将来の課題として明示している唯一のモードであり——「将来的にこれを改善する予定です」——当面の助言は、基準を明示し、多くの人の前に出す前に統合を徹底的にテストすることです。

矛盾する指示や基準は、それを混乱させます

指示と基準が異なるものを求めていると、モデルは混乱することがあります。TypeSafeの例は、trueがnoに、falseがyesに対応するnoulで、同じ質問を一貫した表現で尋ねた場合よりも性能が悪くなります。指示とは、基準を指示の延長として扱い、平均的な人が読んで理解できる言葉で両者を揃えることです。

それが保証しない構造的不変条件

これは、誰も書き留めなかった前提の上に構築されたシステムを最も壊しやすいモードです。Jevは通常の意味では極めて一貫しています——意味的に類似した入力は定量的に類似した出力を生み出します——しかし、成立すると期待されるかもしれない構造上の同一性は保証されません。ベンダーは2つの実例を公開しています。

• 1つの質問、2つの質問タイプ。「顧客は返金を求めていますか？」をnoulとして尋ねた場合と、yes/noの選択として尋ねた場合、チケット「サイズが合わなくて不満です。ここでどのような選択肢がありますか？」では、noulは0.22、選択はyes 0.01、no 0.99、信頼度0.97を返します。これらは同じ質問への回答です。

• 質問とその否定。「顧客は返金を求めていますか？」と「顧客は返金以外の何かを求めていますか？」を、チケット「同じ注文で二重に請求されました。誰か調べてもらえますか？」上の2つのnoulsとして尋ねると、0.72と0.47を返します。それらを合計すると1.19になります。

救済策は修辞的ではなく運用上のものである。期待される構造的不変性に依存してはならず、noul で調整された閾値を選択に持ち込んではならず、またモデルに別々の質問間の算術的同一性を要求してはならない。その理由は、選択は相対的であり――どの選択肢かを決める――一方で、各 noul は絶対的であり、それらすべてについて低い値を返すことがあるからである。

生成：それは書くようには訓練されていない

jev-1.13はテキストを生成するようには訓練されていません。選択肢を連鎖させることで出力を強制できますが、TypeSafeは、これが「うまく機能せず、非常に遅くなる」と直接述べています。抽出に関しては、正規表現または生成モデルで候補値を取り出し、Jevに正しいものを選ばせるか、あるいは — 回答空間が限定されている場合は — 値そのものを尋ねるのではなく、抽出を選択肢の中からの選択に変えることが指針です。

選択式の質問における255個の選択肢の上限

選択の問い——Jev 統合はギザギザした縁ではなく、製品の形そのものだ。これらは切り分けておく価値がある。どれだけプロンプトを工夫しても、それらは変わらないからだ：

• テキスト生成は行いません。文章ではなく決定を返します。それは欠陥ではなく設計です。

• 会話はありません。Jevはチャットモデルではなく、構造化された意思決定モデルです。状態と名前付きの質問のセットを送信すると、質問ごとに1つの構造化された回答を返します。ターン交代を考慮して設計する必要はありません。

• マルチモーダル入力なし。入力はテキストのみ — 文字列、JSONオブジェクト、またはテキスト値の配列であり、画像、音声、動画は含まれない。非テキスト素材は、状態の一部となる前に、テキストまたは構造化フィールドに前処理される必要がある。

• 非ストリーミング応答。単一の構造化された応答があり、ストリーミングモードはありません。これが問題にならない理由は、それを明言する価値がある理由と同じです。ストリーミングするものが何もありません。型付きの決定 — 確率を伴う真偽値、集合の中の1つのラベル、または尺度上のレベル — には、トークンごとに明かす価値のある部分的な形がありません。

• 英語が主要言語です。CJK文字体系を含むその他の言語も処理されますが、同等にうまく処理されるわけではありません。TypeSafeの推奨は、非英語のワークロードでJevに依存する前に自分のコンテンツでテストし、ルーティングの際には信頼度に頼ることです。

選択式の質問における255個の選択肢の上限

選択式の質問は、最大255個のラベル付き選択肢から1つを選ぶものであり、その上限は厳然としている。TypeSafeは、大きな選択肢セットが遅くなる理由についても、ベンダー自身の言葉でこう説明している。「カーディナリティの高い選択肢の場合、まず独立にスコアリングし、次に明示的な選択を行うという2段階システムを採用しています。そのため時折遅くなるのです。」つまり、大きな選択肢セットのレイテンシコストは偶発的なものではなく構造的なものであり、それがどこから来るのかをベンダー自身が語っているのだ。

当社自身の typesafe/jev-1.13 のサービングウィンドウは、2026-09-30 にモデルカードから読み取ったもので、当社自身のトラフィック7日間において実際にどのようなものかを示している。中央値 151 ms、p95 247 ms、毎秒 348 出力トークン、提供された 7,620 万トークン全体でエラー率 0.49% である。日次中央値は狭い範囲に収まっている — 2026-09-24 から 2026-09-30 にかけて 175、170、163、161、170、147、143 ms — しかし 2026-09-28 の日次 p95 は 2,448 ms で、その前後の日の約10倍である。その単日外れ値を選択肢のカーディナリティに帰属させることはできず、またそうするつもりもない。正直な読み方は、テールは存在するということであり、レイテンシに敏感なワークフローは中央値ではなくテールを基準に設計すべきである。

入力請求書は請求書全体です。

Jevでは出力はゼロで課金される。これは時に「Jevは無料」と解釈される。そうではない。なぜなら入力は従量課金され、出力側に何もないというだけで大きな状態が無料になるわけではないからだ。ベンダー価格は100万入力トークンあたり$0.042 — TypeSafeが10億あたり$42と述べているのと同じ数字 — であり、OrcaRouterはプロバイダーの定価を0%のマークアップで通過させるので、ベンダーの値下げは同じ日にここに反映される。

現実的な形状に対して、ベンダー自身のレートを使うと、これがどのような結果になるかを示します：

• 小さなお願いです。1,200トークンのサポートチケットに、およそ300トークンのルーブリックと質問を加えると、1,500入力トークンになり、1回の呼び出しあたり$0.000063です。

• 大きなリクエスト。55,000トークンの契約書と、リクエストを60,000トークンにする質問は、トークン数が40倍になるため、1回の呼び出しあたり$0.0025 — 1回あたりでは依然として小さいが、同じ1つの回答に対して最初のケースより40倍大きい。

• 大量利用時。1回の呼び出しあたり60,000トークン、1日10,000回の呼び出しで、1日の入力トークンは6億、つまり0.6ビリオンとなり、1日$25.20、30日間の月で約$756になります。同じ呼び出し回数を1,500トークンのリクエストに当てはめると、1日1,500万トークンです。1日$0.63、月約$18.90です。

最後の2行の間の隔たりは、価格設定の仕掛けではなく、従量課金される状態そのものだ。だからこそ、コンテキストロットのセクションにあるフィルタリングの助言は、精度のための対策であるだけでなく — 状態を削ることは、請求額を動かす唯一のレバーでもある。

誰も推測しなくて済むよう、公表された動作限界値

TypeSafeのモデルページは具体的な数値を公開しているため、プランナーがそれらを推測する必要はありません：

• スループットとレート。docs.typesafe.ai/models.md によると、毎秒10万トークン、毎秒40リクエストです。いずれかの上限を超えるリクエストには 429 Too Many Requests が返されます。ベンダーのクライアント SDK はデフォルトでバックオフ付きの再試行を行い、レスポンスに retry-after ヘッダーが含まれる場合はそれに従います。

• 制限は流動的です。ベンダーは、レート制限は動的に調整されており、キャパシティがオンラインになるにつれて「予告なく変更される可能性がある」と述べています。カスタムプランとエンタープライズプランでは、より高い制限が利用可能です。100K/40は契約上の数値ではなく、現時点の数値として扱ってください。

• コンテキスト予算。リクエスト予算は、状態と全質問を合わせておよそ64,000トークンです — モデルカードには65,536と公開されています — さらにベンダーのモデルページでは、状態と単一の最長質問を合わせて32,000トークンという上限が別途設けられています。この2番目の数値は状態予算であり、最初の数値を小さくしたものではありません。どちらも実在する数値であり、一方が他方と矛盾するわけでもありません。

• エイリアスはあなたの足元で移り変わります。jev-latest と jev-preview は現在、どちらも jev-1.13.0 に解決され、ベンダーは現時点で利用可能なプレビュービルドはないと注記しています。エイリアスは新しいリリースの出荷時に移動するため、特定のバージョンに対して信頼度しきい値を調整済みなら、バージョン付き ID を固定し、自分のスケジュールで移行してください。

あなたのユースケースがどのような形である必要があるか

最初から最後まで読むと、ベンダー自身のリストは限定的だが有用なツールを説明している。Jevが適しているのは、判断が限定されており、計算がモデルの仕事ではない場合だ：このレコードはポリシーに適合するか、これらの40のラベルのどれが適用されるか、これは5段階尺度でどう読めるか — 自分でフィルタリングした状態に対して尋ねられ、文字通りの指示とそれに一致する基準を伴い、その周りで全てのカウント、比較、日付測定がコードで行われる。

タスクに数え上げ、順序付け、日付計算が必要なとき、複数段階の推論が必要なとき、入力素材がテキストでないとき、状態が干し草の山で問いが針であるとき、あるいは情報源について何かが敵対的であるとき、それは適していない。それらはプロンプトの欠陥ではない。モデルが機能しない箇所であり、そう述べているのはTypeSafeである。

接続する前に知っておく価値のあることがもう1つあります。Jev の呼び出し方における、正直な違いです。OrcaRouter では、カタログは OpenAI の chat-completions 形式ではなく、専用の systemone エンドポイント POST /v1/systemone を通じて Jev に到達します。これは、あなたが書くリクエストにおける実質的な違いであり、Jev が「独自のリクエスト形式で話す」という以前の主張の正しい版です。それ以外はすべて、アカウント上の他のどのモデルとも同じです — 200以上のモデルに1つのキー、当社からのトークン単位の課金はなく、ルートが不調になった場合の自動フェイルオーバーもあります。TypeSafe は 2026-09-21 にウェイトリストを廃止しましたが、ベンダー自身のホームページは依然として Jev を早期アクセスと記載しており、そのベンチマークページもまだ保留中と表示されているため、このページに掲載されているパフォーマンス数値は、当社が独自に測定した配信数値と、ベンダー自身の主張（ベンダーのものとして明示）だけです。