TypeSafe Jevレビュー：価格、実際のレイテンシー、正直な限界

私のコンテンツパイプラインで最もコストがかかるのは、執筆ではありません。判断です。まさにその問題のためにTypeSafe Jevは作られました。だから私は、文章を一文も書けないモデルに午前中を費やしました。

パイプラインを通過するすべての記事では、小さな判断が積み重なります。このトピックは取り上げる価値があるか、tech記事かmusic記事か、ドラフトは編集者のゲートを通過できる品質か、このSEOスコアはリライトを正当化するほど高いか。これらのどれにも散文は必要ありません。switch文が読み取れる答えが必要です。そして先週まで、私がそれを得る唯一の方法は、段落を生成してJSONで包み、その両方に対して課金するフロンティアモデルを借りることでした。

2026年9月15日、TypeSafe AIというラボがこのパターンを終わらせるために特化して作られたモデルをリリースしました。TypeSafe JevはSystem Oneモデルです。テキストをまったく生成せず、入力トークン100万個あたり$0.042で、出力料金はゼロです。

私はまだ実際に触れていません。早期アクセスはウェイトリスト制です。したがって、これは実地テストではありません。ロードマップに載せるかどうかを決める前に行った調査、精査に耐えるローンチ内容、耐えない内容、そしてすでに運用しているシステムのどこに実際に組み込めるのかをまとめたものです。

TypeSafeが実際にリリースしたもの

TypeSafe AIは、DCVCが主導した$40Mのシードラウンドを受け、約2年間のステルス期間を経て登場しました。創業チームはDiogo Almeida、Erik Gafni、Sasha Shengです。

このローンチがスクロールされずに注目を集めた理由は、Almeidaの経歴にあります。彼はOpenAIに在籍し、InstructGPT論文の共同筆頭著者として同等の貢献を行い、GPT-4にも貢献しました。ローンチに関する報道の一部はこれを「ChatGPTの共同発明者」と単純化しましたが、これは大規模な共同作業を一人に集約する誇張です。正確な表現でも十分に強力です。彼は会話型アシスタントを機能させた指示追従研究の構築に貢献し、現在はそのアプローチが自動化にとって間違ったインターフェースだと主張しています。

彼の問いかけで良いのは、次の部分です。モデルは何年もチャットで人間を超えているのに、自動化はどこにあるのか？

TypeSafeの答えは、ボトルネックは知能ではなかったというものです。問題は、散文で返答するモデルが、ソフトウェアを構築する基盤として扱いにくいことです。質問をすると文字列が返り、それをパースし、検証し、拒否した場合に対応し、最初に3段落の推論を書いた場合にも対応し、その後でようやく分岐します。構造化出力によってこれは多少楽になりました。しかし、下にあるインターフェースが依然として生成的であるという事実は変わりません。

Jevは、代わりに判断空間から始めます。名称の両端には意図があります。「System One」は、Kahnemanの速く直感的なSystem 1思考への言及であり、Jevは、コストが下がると消費量が増えるという逆説を唱えたWilliam Stanley Jevonsにちなんで名付けられています。TypeSafeは、呼び出し量に何が起きると予想しているのかを伝えているのです。

3つのプリミティブ、それがAPIのすべて

プログラムの状態と型付きの質問を送ります。返ってくるのは型付きの回答で、すべてにキャリブレーション済みの確率が付いています。質問タイプは正確に3つです。

Choice、Score、Noul

Choiceは、宣言した集合から最大255個までの選択肢のうち1つを選び、すべての選択肢に対する確率分布と信頼度を返します。

Scoreは、言葉で説明した2〜10段階の順序付きレベルによるスペクトラム上に入力を配置します。レベル間にも位置できる連続値を返すため、1.035も有効な回答です。

Noulは二値命題を評価し、それが真である確率を0〜1の単一の数値として返します。数値自体が信念を表すため、個別の信頼度フィールドはありません。

実際の呼び出しの形

TypeSafeのPython SDKがドキュメントで示している形は次のとおりです。

python from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient()

response = client.system_one( state={ "ticket": {"subject": "Duplicate charge", "body": "I was charged twice for order A-104."}, "order": {"id": "A-104", "charges": [{"amount_usd": 49}, {"amount_usd": 49}]}, "refund_policy": "Duplicate charges are eligible for a refund.", }, questions={ "department": Choice( instructions="Which team should handle this", criteria={ "billing": "Payment or subscription issues", "technical": "Bugs or integration problems", "other": "Anything else", }, ), "frustration": Score( instructions="How frustrated the customer appears", criteria=["Calm, just stating facts", "Frustrated but civil", "Very angry"], ), "refund_requested": Noul(instructions="The customer is explicitly asking for a refund"), "policy_supports": Noul(instructions="The stated refund policy covers this situation"), }, )

if response.answers["refund_requested"].noul > 0.7 and response.answers["policy_supports"].noul > 0.8: start_refund_flow("A-104")

4つの判断、1回のリクエスト、1往復です。モデルは意味理解を担います。ポリシーは、私が読み、差分を確認し、テストできるコード内に残ります。

この最後の部分がアーキテクチャ上の主張であり、価格よりも興味深い点です。モデルに「この顧客に対応して」と頼む代わりに、何を理解する必要があるかを指定し、その後に何が起きるかは通常のソース管理下に置きます。

TypeSafe Jevの料金

これが人々の注目を集めた数字です。

出力が無料なのはプロモーションではありません。自己回帰的なデコードループがないため、計測するものがないのです。$0.042が持続可能な価格なのか、ベンチャーによる補助価格なのかは、現時点では分かりません。TypeSafe自身のローンチ記事でも、その点を直接述べています。価格は上がるのではなく下がると予想していますが、それが正しいかどうかを決めるのは時間だけです。

コンテキスト制限はLLMとは異なる仕組みで機能します。状態は一度取り込まれ、その上で質問が並列に実行されるため、状態とすべての質問を合わせておよそ64kトークン、状態と最長の単一質問については約32kトークンです。対応するのはテキストと構造化JSONのみです。画像、音声、動画には対応していません。

レイテンシーの主張と、実際に測定された結果

TypeSafeはエンドツーエンドで70〜500msと公表しました。ローンチ記事では、これらの実行がチーム自身の米国西海岸のノートPCから行われたことを正直に明記しています。米国でホストされたAPIにとっては、最良の条件です。

Classmethod Malaysiaのエンジニアが実際のルーティングタスクで試しました。ウェイトリストを通過し、POST https://api.typesafe.ai/v1/systemoneを直接呼び出し、Choiceを使ってNVIDIAのNeMo Switchyardルーティング設定にある分類器を再現し、会話を4つの層に分類しました。各層10回、合計40回です。

40回すべてが成功しました。40回すべてが期待された層と一致しました。中央値のレイテンシーは0.64〜0.67秒でした。1回あたりのコストは$0.000025〜$0.000027です。

これは見出しにある70msの約10倍遅い数字ですが、それでもローンチサイクル全体で最も興味深い結果です。置き換えられたのは、中央値2.1秒のGemini 3.5 Flash分類器、または7.2秒のDeepSeek V4 Flash分類器だったからです。Jevは、高速だが高価な選択肢より約3倍速く、安価だが遅い選択肢より10倍速く、しかも1回あたり数セント未満のコストでした。

このテストの詳細のうち、速度の数字より価値があるものがあります。曖昧さのない3つの層では、信頼度は1.0でした。本当に境界的な「medium」層では、0.57〜0.67に下がりました。モデルは、どの呼び出しが難しいかを把握していたのです。これはチャットモデルから安定して得ることのできない特性であり、周辺コードの書き方を実際に変える特性です。

TypeSafe Jevについて他の人々が言っていること

ローンチには256件のコメントが付いたHacker Newsスレッドが生まれました。そこから分かる有益な点は、ほとんど誰も技術が偽物だとは主張していないことです。複数のコメント投稿者は、実際に出荷したいと述べています。反発はマーケティングに真っ向から向けられていました。この内容は、これを前提にロードマップを作る前に読む価値があります。

「フロンティアモデル」という言葉に多くが込められている

Jevはコードを書けず、会話を続けられず、文章を生成できません。GPTやClaudeと同じフレーズに並べることで、独自にはまだ獲得していない信頼性を借りています。あるコメント投稿者は、より正直な見出しを提案しました。それは、構造化された判断における速度とコストのフロンティアを前進させた、というものです。これは本当の成果です。しかし、同じ文章ではありません。

「ハルシネーションできない」は聞こえるほど広い意味ではない

自由なテキストを一切出力しないモデルが、引用やツール名を発明できないというのは事実です。また、TypeSafeの0%型エラーという数字は、測定ではなく構造から導かれています。しかし、3つの許可されたカテゴリーに制約されたモデルでも、間違ったカテゴリーを自信を持って選ぶことはあります。排除されたのは不正な回答であって、誤った判断ではありません。TypeSafeのCEO自身も、スレッド内でこの区別に直接同意しています。

速度比較は同じ条件ではない可能性がある

70msという数字は、LLMがスキーマ名やフォーマットを含む構造化された回答全体を自己回帰的に生成する場合と比較して測定されています。LLMに同等の短い判断だけを出力させた場合との比較ではありません。この方法論上の問題は、まだ解決していません。

評価は自社設計

TypeSafeは公開ベンチマークを実行する代わりに、新しい「workflow eval」形式を構築し、正解データではなくGPT-6 AstraとFable 5.1の平均予測に対してモデルを採点しました。同社は自ら限界を示しています。ワークフローは自社チームが構築したものであり、参照モデルはOpenAIとAnthropicに結果を偏らせ、競合LLMはTypeSafe独自のアダプターを通して実行されています。また、公開リーダーボードを避けるとも述べており、これを都合の良い対応だと受け取った人もいます。

アーキテクチャ論文はありません。RLCD、つまりReinforcement Learning for Calibrated Decisionsは、ピッチ全体の基盤となるトレーニング手法ですが、説明はされているものの非公開です。報酬関数も、キャリブレーション曲線も、独立して再現できるものもありません。Anthony Maioが指摘したように、キャリブレーションのための強化学習自体も新しいものではありません。「Rewarding Doubt」のような先行研究が同じ領域を探っています。新しい可能性があるのはパッケージであって、必ずしも手法そのものではありません。

多くの報道が見落とした数字

TypeSafe自身の評価には、セキュリティインシデント対応、エージェントトレースの可観測性、請求書処理、カスタマーサービスを対象とした4つのワークフロー全体にわたる、精度の実態が埋もれています。

注意深く読んでください。これが全体像を変えるからです。Jevは、中位のフロンティアモデルと同等の結果を、およそ76分の1のコスト、25分の1のレイテンシーで実現しています。最上位層には及びません。特に請求書処理では差が最大で、Jevが61.8%だったのに対し、Solは79.1%でした。

したがって、正直な位置づけは「フロンティア級の知能をより安く」ではありません。「Sonnetクラスの判断を、必要なときだけでなく、すべてのリクエストに対して呼び出せる価格で提供する」です。ルーター、分類器、事前フィルターにとって、このトレードオフは非常に優れています。間違いのコストが高い判断では、Solとの差12ポイントがすべてです。

TypeSafe Jevを私のスタックのどこに組み込めるか

すでに運用しているシステムを対象に検討すると、適合する場所は3つ、適合しない場所は2つあります。

コンテンツパイプラインの記事ゲート

このサイトのマルチエージェントパイプラインを実行するコーディネーターは、1回の実行で十数個の限定的な判断を行います。techとmusicの分類は、現在はタグ分布のヒューリスティックです。編集、推敲、humanizerの各パスは、それぞれ「これは準備できているか」という問いに答えています。これらは、LLMの衣装を着たChoiceとNoulの質問です。ここでは価格よりもキャリブレーションが重要です。信頼度スコアがあれば、明確なケースを自動的に通過させ、曖昧なものだけをより大きなモデルに回せます。

Apify actors

そのうちの1つは既存記事のSEO品質をスコアリングします。損益分岐に対して不利になるのは、API内部のモデル費用だけです。同じ仕事をするフロンティアモデルに対して、1回あたり$0.000026のScoreプリミティブを使えるなら、これは最適化ではなく利益率の変化です。まずこれを測定し、次に確信したいと思います。

e-commerce側の顧客質問ルーティング

受信するFAQの質問には、カテゴリー、緊急度の判断、「人間による対応が必要か」というフラグが必要です。3つの質問を並列に、1回のリクエストで、1秒未満。これは典型的なユースケースであり、ローンチデモが中心に据えているものです。

適合しない場所

2つあります。どちらも判断の問題ではなく、厳しい制限です。Mixanalyticは音声分析であり、JevはテキストとJSONにしか対応していません。そのため、先に文字起こしや特徴抽出を行う必要があり、その時点で興味深い処理はすでに終わっています。また、文章を生成するもの、つまり記事のドラフト、ツイート生成、翻訳にも適しません。Jevは設計上、文字列を返しません。安価なClaudeではなく、別のコンポーネントです。

この区別は覚えておきたい点です。これはモデルの置き換えではありません。現在のLLM呼び出しが過剰な能力を使っている判断を処理する、新しい下位レイヤーです。

TypeSafe Jevを始める方法

アクセスはconsole.typesafe.aiからウェイトリストに登録するか、Vercel AI Gateway経由で取得できます。Classmethodのエンジニアは、登録直後にアクセスできたと報告しているため、実際の待ち行列は短い可能性があります。

bash export TYPESAFE_API_KEY="sk-..."

pip install typesafe-sdk # Python 3.10+ npm install @typesafe-ai/sdk # Node 20+

どちらのSDKも環境変数TYPESAFE_API_KEYを読み取り、デフォルトでjev-latestを使用します。SDKを完全に省略したい場合は、POST https://api.typesafe.ai/v1/systemoneという1つのエンドポイントがあります。コンソールには、チケットルーティング、履歴書スクリーニング、サポートエージェント監査の実例を使ったプレイグラウンドが含まれています。

最初の呼び出しの前に知っておく価値があることが2つあります。どちらも最初の48時間以内に公開された実践ガイドに基づくものです。安価な呼び出しをしてから追加で質問するのではなく、最初にすべての質問を含めてください。質問は並列に評価されるため、10個目の質問はトークンを消費しますが、時間はほとんど増えません。また、TypeSafeのcookbookによれば、1つずつ尋ねるよりもバッチ処理のほうが約12倍安く、10倍速いとされています。そしてChoiceには必ず明示的なotherオプションを含めてください。そうすれば、最も近い間違ったものを選ぶ代わりに、どれも当てはまらないとモデルが答えられます。

TypeSafe Jevの結論

価格が見出しであり、アーキテクチャが本当の主張です。「フロンティアモデル」という表現と、自社設計の評価に基づく200倍という数字を取り除いても、残るのは、今四半期にAIインフラについて読んだ中で最も興味深いものです。ソフトウェア内部で限定的な判断を行い、正直な不確実性を付与しながら、実行の制御は決定論的なコードに残すコンポーネントです。

私がしないのは、キャリブレーションが証明済みだと扱うことです。確率が正直であること、他者のドメインでも精度が維持されること、本番負荷に耐えられること。重要な主張はすべて、早期アクセス開始から1週間の企業による自己申告であり、論文も第三者による再現もありません。速度と価格は初日に検証できます。キャリブレーションには何千ものラベル付き結果が必要ですが、それを公開した人はまだいません。

したがって、ウェイトリストへの登録、すでに大量に実行しているスコアリングタスク、そして何かを移行する前に自分で行う測定。これが、良いアイデアを持ちながら、社外の誰も確認した証拠をまだ持たない、リリースから1週間のモデルに対する適切な熱量です。

Sources

開示：2026年9月19日、個人サイトのMCP経由でClaude Opus 5を使い、TypeSafeのローンチ記事と、実際のAPI測定を1件含む6本の独立した記事をもとに調査・執筆しました。私はJevへの早期アクセスを持っておらず、実際にテストしたとは主張しません。ベンダーが報告した数値は全体を通してそのように明記しています。ここにあるすべての数字は、上記のソースのいずれかに帰属します。