TypeSafe AI「Jev」の衝撃：出力無料＆1MTok$0.042でLLM依存を脱却する

• TypeSafe AIが文章を一切返さず確率とスコアのみを返すSystem One Model「Jev」を公開
• 入力$0.042/MTokかつ出力無料でJSONパース不要、型付き質問（noul/choice/score）に特化
• 不確実な自然言語生成を排除し、コード側で閾値判定を行う安全かつ堅牢な業務フローが構築可能に

深夜のオンコール対応やCSチャンネルの監視において、我々バックエンドエンジニアが最も頭を抱えるのは「LLMの出力フォーマット崩れ」だ。どれほどシステムプロンプトに『JSON以外の余計な解説を一切出力するな』と厳格に指示しても、モデルのアップデートやわずかなコンテキストの揺らぎによって「はい、以下が判定結果のJSONです:」といったノイズが前後に付着し、後続のjson.loads()で例外が吹き飛ぶ。正規表現でのトリミングやリトライ処理といった泥臭いモンキーパッチでパイプラインを糊塗してきたエンジニアは私だけではないはずだ。

生成AIブームの狂騒の中で、我々は知らず知らずのうちに「AIとは文章で会話するものだ」というドグマに囚われていた。しかし、システム間の連携やイベントドリブンなワークフローの分岐において、本当に求めていたのは情緒豊かなチャットボットのテキストではなく、後続のif文にそのまま渡せる決定論的な数値やフラグではなかったか。TypeSafe AIがリリースした新モデル「Jev」は、そうした生成AIの無駄肉を冷徹に削ぎ落とした「System One Model」を名乗る。Jevはテキストを渡しても「〜と思われます」といった自然言語を一切返さない。渡されたテキストに対し、こちら側が事前に型定義した質問への確率やスコア（例えば0.93といった浮動小数点数）のみを淡々と返すのだ。

このアプローチは、ソフトウェアアーキテクチャの観点から極めて健全だと私は評価している。従来のLLMエージェントパターンでは、判断のロジックそのものがプロンプトというブラックボックスの中に閉じ込められ、なぜその分岐に至ったのかを外部からコードレベルで追跡することが極めて困難だった。しかしJevの設計思想では、「確率の算出」という推論の仕事のみをモデルに委ね、その数値をどう解釈して「ドキュメント参照」「CS切り分け」「開発チームへエスカレーション」といったアクションを実行するかというビジネスロジックは、すべて呼び出し元のPythonコード側に明示的に記述する。モデルの曖昧さに振り回されず、コード側で確定ロジックを握るという当たり前の主権を、我々開発者の手に取り戻す試みと言える。

JevのAPI設計（エンドポイント: https://api.typesafe.ai/v1/systemone、検証モデル: jev-latest）は、実に開発者フレンドリーで無駄がない。POSTリクエストのペイロードには、評価対象の文字列であるstateと、型定義されたquestionsの辞書を渡す構造となっている。サポートされている質問の型は極めて実用的で、以下の3種類に厳密に集約されている。

• noul: はい/いいえの確率を0〜1の浮動小数点数で返す二値分類型。
• choice: 定義された選択肢（キー群）の中から最も適合するものを選択し、各選択肢の確率分布と確信度を返す多値分類型。
• score: 段階評価の基準を定義し、その間を補完する連続値のスコア（例: 0.00〜2.00）を返す段階評価型。

社内問い合わせのトリアージを想定した検証実装では、1問で安直に「どこに流すべきか？」とLLMに丸投げするのではなく、判断の構成要素を5つの型付き質問に分解してJevに問い合わせる設計が採用された。問い合わせ種別を特定するchoice型のcategory、ドキュメントで自己解決可能かを問うnoul型のanswerable_from_docs、ソースコードや本番DBログ調査が必要かを問うnoul型のneeds_code_or_log、CSチーム内で一次切り分け可能かを問うnoul型のcs_can_verify、そして業務影響の度合いを測るscore型のurgencyである。それぞれの質問には、プロンプトの役割を果たすcriteria（判定基準）を明確に記述する。

特筆すべきはscore型の挙動だ。criteriaに「急がない」「通常」「顧客の業務が停止」といった3段階のテキストを配列で渡した場合、返ってくるのは整数インデックスではなく、例えば1.60や0.42といったレベル間を補間した連続的な位置情報（position）となる。そのため、後続のdecide()関数内では「URGENCY_ESCALATE = 1.6」といった細やかな閾値を設定し、コード側で厳密なフロー制御を記述できる。Jevから確率を受け取ったPythonスクリプトは、開発調査フラグ（needs_code_or_log）が閾値0.55以上であっても、CS側での一次切り分け確率（cs_can_verify）が0.50以上かつ緊急度が1.6未満であればCSに差し戻す、といった極めてロジカルな意思決定をミリ秒単位で完結させるのだ。

Jevを評価する上で避けて通れないのが、従来のチャット型LLMや自律型エージェントとの構造的なアーキテクチャ差、そして運用コストの圧倒的な非対称性だ。社内検証における疑似問い合わせ8件（合計10,339トークン：入力9,290、出力1,049）の集計データによると、API利用料は約0.0004ドルという驚くべき数値を記録している。1件あたり約1,300トークンを消費しても、コストはわずか約0.00005ドル（約0.0075円）に過ぎない。この異常なコスト効率の背景には、入力が100万トークンあたり0.042ドル（$0.042/MTok）という破壊的な価格設定に加え、出力トークンが完全無料というJev独自のプライシングモデルが存在する。

従来のLLMに同じ判定を行わせようとすれば、「なぜその結論に至ったのか」の理由文や、Markdownコードブロックで囲まれた無駄なJSON構文を大量に生成させることになり、その生成トークンすべてに対して割高な出力料金を支払い続けることになる。Jevは余計なテキストを一切出力しないため、出力コストはゼロであり、ネットワーク転送量も最小限に抑えられる。公式ドキュメントが「fast, structured decisions」と胸を張る通り、質問項目を増やしてもレスポンスタイムがほとんど劣化しない特性は、リアルタイム性が求められるマイクロサービスの内部通信において圧倒的なアドバンテージとなる。

だが、手放しでJevを礼賛するわけにはいかない。銀の弾丸が存在しないのと同様に、Jevの「文章を返さない」というストイックな思想は、実務運用において極めて重いトレードオフを開発者に突きつける。最大の弱点は、「モデルがなぜその確率を弾き出したのか」という思考の軌跡が完全に不可視化される点にある。

例えば、needs_code_or_log（コード・ログ調査の必要性）に対してJevが「0.81」という数値を返してきたとしよう。LLMであれば「問い合わせ本文の〇〇行目にエラーコード500の発生が記載されており、DBデッドロックの可能性があるため」といったもっともらしい解説（ハルシネーションのリスクはあるにせよ）を添えてくれる。しかしJevから返ってくるのは冷徹な「0.81」という数値のみだ。その数字の妥当性を担保できるかどうかは、ひとえにエンジニア自身がcriteria（判定基準）をどれほど精緻かつ漏れなく言語化できているかに依存する。質問の分解設計を1つ誤れば、モデルは質問に対して極めて忠実に高精度な確率を返しているにもかかわらず、全体のトリアージ結果が明後日の方向へ暴走するという惨劇を引き起こす。

さらに現場を悩ませるのは「入力が不完全でも処理が止まらない」という特性だ。ユーザーからの問い合わせ本文が途中で途切れていたり、意味不明な文字列が入力されたりしても、Jevは何らかの数値を律儀に計算して返してくる。チャット型LLMであれば「情報が不足しているため判断できません」と返答してくれるケースであっても、Jevは平然とスコアを出力するため、呼び出し側のコードに確信度（confidence）のチェックや、異常値検知のガードレールを自前で幾重にも張り巡らせる必要がある。

また、プライバシー面においてはTypeSafe AIが明記している通り、「Jev is not trained on customer requests or responses」として顧客入力データの学習利用を排除するポリシーを掲げている点は評価できる。しかし、社内の機密データや顧客の生々しいインシデントログを外部APIに流すこと自体のガバナンスリスクは依然として残る。

我々エンジニアは今、重大な問いに直面している。何でもこなせる巨大で雄弁な汎用LLMに高額なAPIコストを払い続け、パースエラーの恐怖に怯えながらプロンプトを弄り続けるのか。それとも、自らの頭で業務ドメインを型へと分解し、確率値のみを高速・安価に取得して、決定論的なコードで手堅くシステムを組み上げるのか。すべてのタスクに大規模なチャットモデルをあてがう思考停止を捨て、推論と制御の責任分界点を再設計するタイミングが来ている。