文章を書かない新AI「Jev」の登場――型付き判断に特化した「System One」モデルとは

TypeSafe AIは2026年9月15日、同社初のSystem One Modelである『Jev』を発表しました[1, 7]。発表者は創業者のDiogo Almeida氏です[1]。Jevは従来の対話型AIのように文章やコードを生成しません[2, 8]。入力された状態（state）に対して、事前定義された型の値や確率、確信度を返すモデルです[2, 8]。クラウド上のサーバを通じて提供される、アプリケーション接続用のホステッドAPI（ソフトウェア同士を接続する仕組み）として公開されました[2]。

TypeSafe AIは、本モデルを「System One Model」と位置づけています[1, 3]。この名称は、心理学者ダニエル・カーネマンが提唱した「速い直感的なSystem 1」と「遅く熟考的なSystem 2」という思考の区別に基づいています[3]。Jevは、ソフトウェア内部の高速な分類やルーティング（処理の振り分け）、スコアリング（評価値の算出）を担う存在として設計されています[3]。

Jevは、自由な文章を出力する大規模言語モデル（LLM）ではありません[4, 9]。非構造化の状態入力と型付きの質問を受け取り、ソフトウェアが直接利用できる構造化判断を直接返します[4, 9]。そのため、開発者は文章を構文解析してデータを取り出す処理を組む必要がありません[4]。

Jevの公開APIには、3つの「判断プリミティブ（判断の基本単位）」が用意されています[5, 6]。第1に固定された候補から1つを選ぶ「Choice」です[5, 6]。第2に尺度上で評価を行う「Score」です[5, 6]。第3に真偽を確率で判定する「Noul」です[5, 6]。開発者はこれらの出力型を呼び出し側で事前に定義し、システムの分類や優先順位付け、検証ロジックへ組み込みます[5, 6]。

後輩文章を一切書かないのにAIモデルと呼ばれるのは、少し不思議な気がします。

先輩人間向けの会話を目的とせず、プログラムの分岐処理に組み込む部品として作られているんだね。

後輩人と対話する道具ではなく、システムが判断を下すための専用機能ということですね。

先輩その通りだよ。出力形式をあらかじめ型として固定することで、システム連携の手間を省く狙いがあるんだ。

なぜ今「判断特化型」が話題なのか――逐次生成の壁を破る並列評価とRLCD

TypeSafe AIは、会話能力の向上とは異なるアプローチを提示しています[10]。AIの判断をソフトウェアの部品として扱い、文章生成やテキスト解析に伴う負担を減らそうとした点に価値が見いだされたと考えられます[10, 25]。自由文出力を使う場合、構文解析や再試行が必要になることがあります[10, 26]。Jevはこうした運用の摩擦を低減します[10]。

通常のLLMとの実装上の大きな違いは、出力データの生成方式にあります[11]。従来のLLMは、トークン（文字や単語の構成単位）を1つずつ順番に生成する逐次生成を採用しています[11]。これに対してJevは、複数の判断結果を1回の問い合わせで並列に評価します[11, 12, 27, 28]。この並列評価によって、推論にかかる時間を大幅に抑えられるとTypeSafe AIは説明しています[11]。

TypeSafe AIの公表値によると、Jevの入力から応答までの時間（エンドツーエンド応答時間）は70〜500ミリ秒です[13, 29]。同社は、同等水準のSystem One型タスクにおいて、最先端のLLM（フロンティアLLM）より40〜200倍高速であると主張しています[13, 29]。また、同社が実施した4つの一連の処理（ワークフロー）の評価では、193.6倍速く、コストが444.6分の1という結果が示されました[14, 33]。ただし、この検証は同社製のLLM接続用ソフトウェア（LLMラッパー）を用いた比較です。そのため、実運用で得られる効果よりも高い結果になっている可能性があると、同社自身も説明しています[15, 33]。利用料金は入力100万トークンあたり0.042ドル（10億トークンあたり42ドル）に設定され、出力料金は無料とされています[16]。

Jevの学習手法には、「RLCD（Reinforcement Learning for Calibrated Decisions）」が採用されています[17]。これは、予測確率と実際の正答率を一致させる、較正された意思決定のための強化学習手法です[17]。人間が好む自然な文章の生成ではなく、モデルが出力した確率が実際の正答率と整合することを学習の目標にしています[17, 18]。判断用途では正解率だけでなく、確率が正答率と対応する較正が重要になります[31, 32]。

従来の構造化出力（Structured Outputs）や関数呼び出し（Function Calling）との間には、明確な技術的差異があります[20, 21, 30, 34]。構造化出力は、LLMが生成する文章を指定されたJSON Schema（データ構造の規約）に適合するようトークンを制約する仕組みです[19, 20]。OpenAIの評価では100%のスキーマ適合が確認されている一方、初回リクエスト時に最大1分程度のスキーマ処理遅延が発生する場合があります[22, 23]。これに対しJevは、型付き判断そのものをAPIの主出力として設計し、候補ごとの確率分布と確信度を標準で返します[20, 23, 35, 36]。また関数呼び出しが外部ツール名と引数を出力する仕組みであるのに対し、Jevは推論プリミティブそのものとして振る舞います[21]。

比較項目従来の生成LLM（Structured Outputs含む）Jev（System Oneモデル）
主たる出力形式テキストまたはスキーマ制約付きJSON [19, 20]型付き判断値（Choice/Score/Noul）と確率分布 [5, 20]
サンプリング方式逐次生成（トークンを1つずつ順番に出力） [11]並列評価（1回の問い合わせで全出力を生成） [11, 12]
エンドツーエンド応答時間初回スキーマ処理に最大1分程度かかる場合がある [23]70〜500ミリ秒（LLM比40〜200倍高速と主張） [13]
利用料金体系入力および出力トークン数に応じた従量課金入力100万トークンあたり0.042ドル、出力無料 [16]

ただし、AIエージェントの処理全体を見渡すと、推論速度の向上だけで全体の遅延が解消されるわけではありません[24]。エージェントの応答時間は推論だけでなく、API処理やツールの実行、通信の往復など多層的な処理で構成されているからです[24]。判断を高速化しても、周辺の外部処理が全体のボトルネックとして残る可能性があります[24]。

後輩推論速度が数十倍から数百倍になれば、システム全体の処理も同じくらい一瞬で終わるのでしょうか？

先輩システム全体がそのまま同じ倍率で高速化するわけではないよ。

後輩外部APIとの通信やツールの実行にかかる時間が別にあるからですね。

先輩その通りだね。推論が速くなっても外部処理の待ち時間は消えないから、システム全体の遅延要因を冷静に見極める必要があるよ。

業務コードはどう変わるのか――徹底調査で見えたJevの主要ユースケース6選

Jevは、取り得る出力の範囲（出力空間）を事前に厳密に定義できる高頻度な業務において、適性があるとTypeSafe AIは説明しています[37, 38]。表現力や文章の創造性を競う用途ではなく、判断候補と許容尺度があらかじめ決まっている領域で適性を持ちます[38]。ここでは、Jevの特性を活かした具体的な主要ユースケースを6つ紹介します。

第1のユースケースは「問い合わせ分類とルーティング」です[39]。届いた問い合わせ本文や会話履歴を入力状態（state）として渡します[39]。Choiceプリミティブを使い、適切な担当部署やカテゴリを選択させます[39]。確信度（confidence）としきい値を照合し、確信度が高い場合は自動で部署へ振り分け、不確実な場合は手動トリアージ（人手による仕分け）へ送る分岐を記述できます[39]。

さらに問い合わせ処理では、複数の判定を1回のリクエストで同時に評価できます[40]。担当部署の判定に加え、返品理由の特定、配送トラブルの有無、顧客の希望内容といった独立した質問を並列に処理できます[40]。1度のAPI呼び出しで複数の結果が得られるため、後続処理を通常のif文で簡潔に組み立てられます[40]。

第2のユースケースは「コンテンツ審査」です[41]。ユーザが投稿した文章をstateに設定します[41]。Noulで利用規約違反の有無を判定し、Scoreで危険度や深刻度を測定します[41]。さらにChoiceで違反カテゴリを特定できます[41]。これらの判定値をコード側のしきい値と組み合わせることで、自動公開、確認待ち、人手審査、即時遮断といった制御を柔軟に行えます[41]。

第3のユースケースは「リスク判定」です[42]。セキュリティアラート、コードの変更差分、請求書データ、エージェントの実行履歴などをstateに集約します[42]。Scoreプリミティブを用いて、リスクや緊急度、重大度を連続的な尺度に変換します[42]。設定した閾値を超えた場合にのみ、端末の隔離措置や保留、アナリストへの優先通知といった処理を自動で進められます[42]。

第4のユースケースは「承認ゲート」です[43]。各種申請内容やアカウント情報、操作の可逆性（元に戻せるか否か）をstateに入力します[43]。Noulで承認条件を満たすかを判定し、Scoreでリスクを評価します[43]。確信度をしきい値にし、高信頼かつ低リスクな申請のみを自動実行させます[43]。たとえば、不確実な処理を人手へ回す基準を確信度0.5とし、高リスク操作を確認付きで実行する基準を0.9とする運用が可能です[43]。

第5のユースケースは「検索結果の検証」です[44]。検索候補のリンク、取得した文書、引用箇所をstateに渡します[44]。Choiceで最も適切な情報源を選び、Noulで元の主張と根拠情報の整合性を判定します[44]。さらにScoreで関連性や証拠の強度を測定します[44]。もし確信度が低ければ、検索のやり直しや人手確認へ回すことで、AIの事実誤認による誤作動のリスクを低減します[44]。

第6のユースケースは「AIエージェントのツール選択と安全ガードレール」です[45]。ユーザーの要求、対話履歴、環境状態、候補ツールと引数をstateに与えます[45]。Choiceで実行すべきツールを選定し、NoulやScoreで危険度を判定します[45]。不正な操作や意図しないツール呼び出しを遮断し、危険度の高い処理だけを人間の承認へ送る制御層として機能します[45, 46]。

これらのユースケースでは、出力空間を事前に固定できる特徴が活かされています[37]。Choiceは最大255個の選択肢を扱い、Scoreは2〜10段階のレベルを受け付けます[37]。Noulは真偽確率を出力します[37]。複雑な判断であっても、あらかじめ選択肢や尺度を定義できる高頻度業務ほど、Jevの導入価値が高まります[37, 38]。

後輩これまでプロンプト内に自然言語で記述していた業務ルールは、どのように変わるのでしょうか？

先輩プロンプトに長文で指示するのではなく、受け取った数値を使ってコード側のif文で分岐させる形になるよ。

後輩AIにルールを丸ごと解釈させるのではなく、判断の境界線をエンジニア自身が握り直すわけですね。

先輩その通りだね。判定結果が確率付きで返るから、どの水準で人間に委ねるかをプログラム側で厳密に制御できるんだ。

「1つのプロンプト」から「原子的質問の合成」へ――Jevが促す設計思想の転換

Jevの導入は、システム開発の設計思想に変化をもたらします。複雑な判断を、さらに分解できない単位の質問（原子的質問）に分ける設計です[52]。従来の開発では、複雑な業務要件や多様な判断条件を1つの巨大なプロンプトに詰め込む手法が多く用いられていました[49]。しかしこの手法は、複雑化や保守上の課題につながる場合があります[49]。

Jevが提示するアプローチは、複雑な判断を「原子的質問」へ分解することです[49, 52]。たとえば「規約違反はあるか」「緊急度はどの水準か」「担当部署はどこか」といった独立した問いに切り分けます[49]。非構造化の状態を入力し、これらの質問を1回のAPI呼び出しで並列に問い合わせます[40, 48, 49]。

開発者は、Jevから得た定義済みの型に適合する判断値（型安全な判断値）や確率分布を、アプリケーション側のコードで組み合わせます[47, 49, 51]。各要素の優先順位や重み付けを考慮し、通常のif文や条件分岐を用いて最終的な業務アクションを決定します[47, 49, 51]。判断の根拠がコードとして明示されるため、保守性と透明性が向上します[47, 51]。

開発者は、Jevが出力する「confidence」と「確率分布」を状況に応じて使い分けられます[50]。単一の指標であるconfidenceは、0から1の範囲で確率分布の集中度を示します[50, 61]。単純なしきい値判定を行いたい場合に適しています[50]。一方で、複数の候補へ同時に通知を送る場合や僅差の選択肢を精査したい場合には、全候補の確率分布を直接参照する設計が有効です[50]。

誰がどう使うべきか――開発者・企業への影響と導入時の注意点

Jevの実用化が進んでも、従来の文章生成LLMが不要になるわけではありません[53, 54]。自然な対話や文章の執筆、未知の問題の分解においては、生成LLMが不可欠だからです[53, 54]。企業にとっては、文章生成を担うLLMと制御や検証を担うJevを分ける二層アーキテクチャ（役割を二層に分ける構成）が選択肢になります[54]。

二層アーキテクチャでは、上位のLLMが要約や文章作成、ユーザーとの対話を担当します[54]。下位のJevは、生成された文章の検証、リスク判定、ツール呼び出し前の安全ガードレールを担います[41, 45, 54]。企業の業務部門では、高頻度業務を段階的に自動化しやすくなる一方、業務ルールや閾値をコードとして適切に管理する責任が増加します[55]。

ただし、企業がJevを導入する際には、技術的な限界とリスクを理解しておく必要があります[58, 59, 60]。Jevが保証する「型安全性」とは、事前に定義された形式や選択肢に適合することです[20, 60]。出力形式が崩れないことを意味するものであり、判断の意味内容が常に正しいことを保証するわけではありません[57, 59, 60]。

確信度（confidence）の解釈にも注意が求められます[56, 61]。confidenceは確率分布の集中度から算出された統計指標であり、正答そのものを保証する値ではありません[61]。またRLCDによる確率の較正は、検証されたデータ分布下での対応関係を示したものです[56, 62]。実運用で学習時と異なるデータ分布（分布シフト）が生じた場合、同様の較正精度が維持されるとは限らないと指摘されています[62]。なお、TypeSafe AIは似た入力に似た回答を返すという定性的な一貫性を主張していますが、LLMと比較した出力のばらつきや決定性を示す具体的な指標は、公開資料から確認できません[57]。

評価手法や学習データの透明性にも留意が必要です[63, 64]。Jevの公式評価は、TypeSafe AIが作成したワークフローを前提としています。GPT-6 AstraやClaude Fable 5.1の平均値と比較していますが、外部機関が作成した正解データによる検証ではありません[63]。また、モデルの学習データの出所については、公式FAQで質問項目が掲載されているものの回答は示されていません[64]。

運用面では、未知の入力への対策が不可欠です[65, 66]。Choiceプリミティブは定義済み集合（最大255候補）から必ず選出するため、想定外の事例を検出するには「その他（other）」や「該当なし」の選択肢を明示的に用意する必要があります[37, 65]。また曖昧な入力に対してはJevも確率を分散させるため、低確信度のケースを追加確認や人手審査へ回す設計が推奨されます[66, 67]。

後から判断過程を検証できる監査ログと、セキュリティの管理も重要です[68, 69]。入力識別子、質問定義、モデル名、確率分布、confidence、適用閾値、最終分岐、レビュー結果を記録する監査体制が求められます[68]。個人情報や機密情報を含む原文は処理から分離するか、マスキング（情報の一部を伏せる処理）したうえで、stateには最小限の属性のみを渡すべきです[68, 69]。判定ミスの責任はモデル提供者に移るわけではなく、TypeSafe AIの利用規約における責任上限は100米ドルに設定されています[70]。

市場全体に目を向けると、機械向け意思決定APIへと競争軸が広がり、既存事業者も型付き出力や低遅延、監査機能の強化を迫られるとの見方もあります[72]。初期導入においては、高リスクな基幹業務の全自動化を避けるべきです[71]。低リスクな補助分類や人手レビューの絞り込みから段階的に導入することが推奨されます[71]。また、ホステッドAPIに過度に依存すると、特定の事業者から離れにくくなる状態（ベンダーロックイン）が生じやすくなります。コード側で呼び出しを抽象化し、モデルの差し替えや代替経路を確保しておくことが重要です[71, 72]。

後輩形式エラーが起きにくい仕組みでも、業務の自動化を全面的に任せられるとは限りません。

先輩そこは一番慎重になるべき点だね。形式が崩れないことと、判断内容が正しいことは全く別物なんだ。

後輩正しいフォーマットで間違った判定が返ってくる可能性は残るわけですね。

先輩その通りだよ。だからこそ、確信度に応じた人間のチェック体制や、ログの記録設計が不可欠になるんだね。