Jevとは？判断に特化したAIの使いどころ

2026年9月15日、​TypeSafe AIが​「System One Model」と​いう​新しい​種類の​モデルと、​その​最初の​公開モデル​「Jev」を​発表した。​X上では​DOOMを​リアルタイムで​操作する​動画が​拡散し、​「LLMの​200倍速い」​「出力トークンが​無料」と​いった​数字が​独り​歩きしている。

だが​公式の​ブログと​ドキュメントを​読むと、見出しの数字より重要な設計思想と、公式自身が書いている限界が見えてくる。

• Jevは​文章を​1文字も​生成しない。​返すのは、​あらかじめ定義した​選択肢・段階・真偽に​対する確率付きの判断だけである
• 「193.6倍速い・444.6倍安い」は​公式の​独自評価の​数字で、​公式ブログ自身が実運用での改善幅としては高い側の値だと​注記している
• 公式ドキュメントには​「Jevは​計算機ではない」​「日付の​比較は​信頼できない」​「無関係な​情報が​多いと​精度が​落ちる」と、苦手なことが8項目で​明記されている
• 公表レイテンシの​測定は​主に米国西海岸からで、​サービスの​拠点も​そこに​ある。​日本から​呼ぶ​場合は​通信の​往復が​上乗せされる

本記事は、​TypeSafeの​公式ブログ・ドキュメントと、​Browser Useが​公開した​実装​（jev-ultrafast）の​計測レポートを​一次​資料と​して、​Jevが​何で、​どこに​使えて、​どこに​使うべきでないかを​整理する。​結論を​先に​書くと、​Jevは​「強い​LLMを​安く​置き換える​技術」ではなく、LLMに考えさせていた小さな判断を、ソフトウェアの側へ戻す技術と​して​読むのが​正確である。

この​​記事の​​対象読者

• LLMを​業務システムに​組み込んで​おり、​呼び出し回数・レイテンシ・コストが​膨らんでいる​開発者
• エージェントや​RAGの​ガードレール、​モデルルーティングを​設計している​実装担当者
• 問い​合わせ振り分け・営業リードの​優先度付け・審査の​一次判定など、​大量の​小さな​判断を​自動化したい​業務部門の​推進担当者
• 話題の​Jevを​自社で​試すべきか、​試すなら​何から​測る​べきかを​判断したい情報システム部​門

Jevとは​何か

Jevは​TypeSafe AIが​開発した​判断特化型の​モデルである。​創業者の​Diogo Almeida氏は、​OpenAIで​ChatGPTの​基盤と​なった​指示追従の​研究に​関わった​人物で、​2年間の​ステルス期間を​経て​発表した。

公式ドキュメントと​ブログから、​現時点​（2026年9月17日確認）の​事実を​押さえる。

名前の​由来は​2つある。​「System One」は​ダニエル・カーネマン『ファスト＆スロー』の、​速く​直感的な​思考​（システム1）から。​「Jev」は、​蒸気機関の​効率化が​石炭の​需要を​かえって​増や​した​ことを​指摘した​経済学者ジェヴォンズから​取っている。​知能の​コストが​一桁下がる​たびに、​使い道は​何桁も​増える、と​いう​賭けである。

LLMと​​何が​​違うのか

文章ではなく​​「判断」を​​返す

LLMは、​入力を​受けて​トークンを​1つずつ生成する。​構造化出力を​指定しても、​内部では​文字列を​生成し、​それを​パースして​使う​経路を​通る。

Jevは​文字列を​生成しない。状態（State）と質問（Questions）を渡すと、型の決まった答えと確率が返る。 TypeSafeは​これを、​非構造化の​状態を​入れて​型付きの​確率的な​判断を​受け取る​関数​呼び出し、と​表現している。

判断の​型は​3つだけである。

Choiceは​1問あたり​最大255候補まで​扱える。

複数の​​質問を、​​並列かつ独立に​​評価する

1回の​API呼び出しに、​3種類の​質問を​何問でも​混ぜられる​（上限は​トークン予算で​決まる）。各質問は同じ状態に対して並列に、互いに独立して評価される。 ある​質問の​答えが、​別の​質問の​答えの​文脈に​紛れ込むことはない。

公式の​クックブック​（jev-1.12 で​実施）では、​GDPRの​Wikipedia記事​（約5万4,000字）に​13問を​投げる​例で、​1問ずつ​13回呼ぶより​1回に​まとめた​ほうが​12.2倍安く​10.0倍速く、​まとめた​ことに​よる​回答への​影響は​見られなかったと​報告している。​ただし速度の​比較は​13回を​順番に​呼んだ​場合の​合計時間との​比較で、​並行して​呼べば差は​縮むと​公式も​書いている。​費用の​差は、​長い​文書を​毎回​送り直す分なので​残る。

confidenceが​​「わからない」を​​伝える

Choiceと​Scoreの​答えには、​確率分布から​計算した​ confidence（0〜1）が​付く。​分布が​1つの​候補に​集中していれば​高く、​ばらけていれば​低い。

公式ドキュメントは、​これを​3段階の​振る​舞いに​分ける​設計を​推奨している。​高ければ​自動で​実行し、​中程度なら​確認を​挟み、​低ければ​実行せず​人や​別の​システムに​回す。​そして閾値は行動のリスクで変える。​残高照会のように​間違えても​戻せる​操作と、​送金承認のように​戻せない​操作で、​同じ​閾値を​使わない。

公表値を​​どう​​読むか

数字が​派手な​発表ほど、​測り方を​確認する​必要が​ある。​TypeSafeは​公式ブログで​各主張に​「Nuance」と​いう​注記を​付けており、​そこを​読むと​数字の​位置づけが​はっきりする。

「40〜200倍速い」「193.6倍速い・444.6倍安い」

70〜500msは、​同程度の​知能水準の​LLMと​比べ、​System One型の​クエリで​40〜200倍と​いう​主張である。​193.6倍・444.6倍は​TypeSafeが​独自に​作った​Workflow Evalsの​数字で、​公式自身が実運用での改善幅としては高い側の値だろうと​書いている。​評価用の​ワークフローは​自社の​モデル能力チームの​メンバーが​作っており、​偏りが​ありうる​ことも​明記されている。​人手で​確定した​正解ではなく、​GPT-6 Astraと​Fable 5.1の​予測確率の​平均を​参照値と​して​比べている。​さらに​比較対象の​LLMは、​TypeSafeの​APIと​同じ​形式の​判断と​確率を​返すラッパー経由で​呼んで​おり、​公式は、​この​方式は​確率を​付けずに​判断だけ返させる​場合より​遅く​高価に​なりやすいと​注記している。

レイテンシ

公式は、​公表している​評価が​主に​米国西海岸の​ラップトップから​実行された​もので、​サービスの​拠点も​そこに​あると​書いている。日本からの呼び出しでは、この数字に通信の往復時間が加わる。 日本の​業務システムに​組み込む前に、​自社の​環境から​実測する​必要が​ある。

価格

入力100万トークンあたり$0.042、​出力は​無料である。​ただし公式ブログは、​この​価格が​補助的に​安くされていない​ことは​証明できない、​長期で​持続​可能性を​示す必要が​ある、​とも​書いている。​現行価格を​前提に​した​長期の​原価計算は​避け、​価格が​変わっても​成り​立つ設計に​しておくのが​安全である。

「ハルシネーションしない」

ここは​最も​誤読されやすい。​公式が​保証しているのは、あらかじめ定義した型と選択肢から外れた値を返さないことである。​スキーマに​合わない​出力が​出ないのは​構造上の​性質で、​だから​公式は​「型エラーは​数学的に​起こり得ない」と​書ける。

一方で、正解がAなのにBを選ぶ判断ミスは起こる。 公式ドキュメント自身、​キャリブレーションは​多数の​予測を​集めて​測る​ものであり、​個々の​答えが​正しい​ことは​保証しないと​書いている。​型の​安全性と​答えの​正しさは​別物である。

公開事例：ブラウザ操作エージェント​「jev-ultrafast」

公開から​日が​浅く、​事例の​多くは​デモである。​その​中で、​測り方まで​公開されているのが​Browser Useの​「jev-ultrafast」である。

Google Flightsで​「チューリッヒ発ロンドン行き」を​検索する​タスクを、​動画上で​7.073秒で​完了している。​計測は​最初の​ページを​読み込んで​観測した​後の​最初の​判断から、​完了​（DONE）の​判断が​受理されるまでで、​ブラウザの​準備、​最初の​ページ遷移、​終了後の​独立した​結果​検証は​時間に​含まれていない。

仕組みは​次の​とおりである。

1. 画面の​DOMから、​操作できる​要素を​番号付きの​表に​する​（スクリーンショットは​既定の​ループでは​使わない）
2. Jevに​1回の​リクエストで​「次の​操作​（CLICK・TYPE_TEXT・SELECT・SCROLL・WAIT・DONEなど）」と​「対象の​要素」を​同時に​選ばせる
3. 操作が​文字入力​（TYPE_TEXT）の​ときだけ、​小型の​LLMが​入力する​文字列を​生成する

改良前後の​実装を​同じ​条件で​交互に​3回ずつ走らせた​比較​（こちらも​最初の​ページ遷移は​除外）では、​所要時間の​中央値が​9.450秒から​7.092秒へ​25.0%短縮した。​Jevへの​リクエストは​中央値22回から​17回、​ブラウザへの​プロトコル呼び出しは​1,092回から​101回に​減っている。​記録した​実行での​Jevの​レイテンシ中央値は​178msだった。

この​数字から​読み取るべきことは、Jevが魔法のようにブラウザを理解したから速い、ではないと​いう​点である。​上の​比較は​改良前も​改良後も​同じ​ jev-1.13.0 を​使っており、​25%の​短縮は​DOMの​読み取りを​1回に​まとめると​いった​実装側の​改善から​来ている。​7秒台と​いう​速さその​ものも、​スクリーンショットの​画像理解や​長い​推論を​ループから​外し、​Jevには​「次の​操作を​選ぶ」と​いう​狭い​判断だけを​任せた​設計に​支えられている。

レポート自身も、​3組だけでは​統計的に​強い​主張は​できない​（符号検定で​p=0.25）、​これは​1タスクの​小さな​比較で​あり汎用的な​エージェントの​ベンチマークではない、と​明記している。​また​「DONE」を​選んだ​ことは​成功の​証拠にならず、​結果は​別途検証する​設計に​なっている。

Jevが​​苦手な​​こと

TypeSafeは、jev-1.13 に​ついて​分かっている​弱点を​「jaggedness​（ギザギザ）」と​いう​ページで​公開している​（2026年9月16日レビュー）。​導入を​検討するなら、​性能の​数字より​先に​ここを​読むべきである。

拡大 ⤢

入力の​長さにも​上限が​ある。jev-1.13 の​ページでは、​状態と​すべての​質問を​合わせて​64kトークン、​状態と​最も​長い​質問を​合わせて​32kトークンと​されている。​一方、​質問の​型を​説明する​別の​ページでは​「約32,000トークン」と​書かれており、​ドキュメント間で​表現が​揃っていない。​長い​文書を​扱う​場合は​実際に​投げて​確認した​ほうが​よい。

この​表から​分かるのは、Jevは「何でも速くするモデル」ではなく、判断の形に切り出された問いにだけ強いモデルだと​いう​ことである。

使いどころ：LLMから​​「短い​​判断」を​​剥が​​す

拡大 ⤢

TypeSafeの​ドキュメントは、​ソフトウェアを​3つの​型に​分けている。​従来の​ソフトウェアは、​信頼できる​単純な​部品を​組み合わせた​決定木である。​LLMエージェントは、​指示を​読んで​次の​手を​自分で​決める。​人が​見ている​前提なら​よく​機能するが、​ループの​たびに​脱線する​機会が​生まれる。​そして​TypeSafeが​勧める​3つ目は、制御の流れをコードが持ち、AIは狭く構造化された判断にだけ登場するソフトウェアである。

業務に​落とすと、​処理は​4つの​担い​手に​分かれる。

ポイントは​「何でも​Jevに​する」​ことではない。いま上位LLMに丸ごと考えさせている処理の中から、本当は短い判断で足りる部分を剥がすことである。​剥が​した​判断を​Jevに​置き、​確度で​分岐させれば、​上位LLMを​呼ぶのは​生成や​長い​推論が​本当に​必要な​案件と、​確度の​低い​案件だけに​なる。

質問は​​「原子的」に​​する

公式ドキュメントが​繰り返し強調しているのが、​質問の​分解である。​「この​案件を​総合評価して」と​1問で​聞くのではなく、​「予算が​明確か」​「決裁者が​関与しているか」​「課題が​切迫しているか」と​分けて​聞き、​重み付けは​コードで​行う。

こうしておくと、​優先順位が​変わった​ときに​プロンプトを​書き直す必要が​ない。コードの係数や閾値を変えれば済む。 判断の​根拠も​質問単位で​ログに​残るので、​どの​観点で​判断が​ずれたかを​後から​追える。

業務別の​​用途マップ

公式ドキュメントの​用途例を、​日本企業の​業務に​置き換えて​整理する。​以下は​筆者の​設計例であり、​TypeSafeが​特定の​業務での​性能を​保証している​ものではない。

公式の​クックブックには、​ここに​近い​例が​いくつも​公開されている。​たとえば​法律文書の​検索では、​BM25で​絞った​30件の​候補を​Jevで​1件ずつ​採点し直す​ことで、​40件の​クエリの​うち、​正解の​文書が​1位に​来た​割合が​5%から​18%に、​上位10件に​入った​割合が​38%から​62%に​上がったと​報告している​（jev-1.12 で​実施）。​件数が​小さい​公式の​例である​点は​割り引いて​読む必要が​あるが、​「候補を広く出すのは既存の検索、並べ替えはJev」と​いう​分担の​形は​参考に​なる。

画像や​現場写真を​​扱う​​業務では

建設・製造・保守のように​現場写真や​図面を​扱う​業務では、​現時点の​Jevは​画像を​直接受け付けない。​DOOMの​デモも、​画面画像ではなく、​テキストを​含む構造化された​ゲーム状態を​入力している。

その​ため構成は​分業に​なる。​画像認識モデルや​OCRで​「ヘルメットの​有無」​「亀裂の​候補」​「資材の​種別」を​構造化し、​その​結果を​Jevに​渡して​「作業を​止めるべきか」​「撮り直しが​必要か」​「専門家の​レビューに​回すか」を​判断させる。画像の認識と業務の判断を分ける設計である。

導入前に​​検証する​​こと

Early Accessの​段階で、​性能の​数字も​ベンダー自身の​評価が​中心である。​いきなり​「導入するか」を​判断するより、自社の判断のうち、どれだけの割合をJevに移せるかを​測る​検証が​適している。​TypeSafe自身も、​公開ベンチマークを​重視せず、​利用者が​自分の​ユースケースで​評価を​作る​ことを​勧めている。

最初の​​2週間で​​やる​​こと

1. ログとラベルが既にある業務を1つ選ぶ。 問い​合わせの​振り分けや、​商談の​有望度判定のように、​過去の​判断結果が​残っている​業務が​向いている
2. 判断を原子的な質問に分解する。 1つの​業務判断を​3〜10問程度に​分け、​組み合わせの​ロジックは​コードに​書く
3. シャドーモードで並走させる。 本番の​判断は​変えずに、​既存の​LLMや​人の​判断と​同じ​入力を​Jevにも​投げ、​結果を​比べる
4. 正解率だけでなく、確率が当たっているかを見る。 ある​候補の​確率や​Noulの​値が​0.9前後と​出た​とき、​その​候補や​命題が​実際に​約9割の​頻度で​成立しているか​（キャリブレーション）を​確かめる。​これとは​別に、​confidenceの​帯ごとに​実際の​正解率と​誤処理の​割合を​集計し、​自動化する​範囲の​閾値を​決める。​confidenceは​確率分布の​形から​計算した​指標で、​正解率​その​ものではない​点に​注意する
5. 閾値で3つに分ける。 自動実行・上位LLM・人の​確認の​境界を、​業務の​リスクごとに​決める
6. すべてを記録する。 状態・質問・答え・confidence・​最終的な​結果・​使った​モデルの​バージョンを​ログに​残す

評価する​指標

評価セットの​作り方はAIエージェントの​Eval設計で​詳しく​扱っている。

本番化で​​守る​​こと

Jevを各アプリケーションから直接呼ばない。 間に​1枚、​判断の​窓口と​なる​層を​挟み、​質問の​定義・閾値・ログを​そこに​集める。​こうしておけば、​モデルの​バージョンアップや別の​モデルへの​差し替えが​起きても、​業務側の​コードは​変えずに​済む。

jev-latest のような​エイリアスは、​新しい​リリースが​出ると​指す先が​変わり、​同じ​入力でも​答えが​変わりうると​公式が​書いている。閾値をあるバージョンで調整したなら、バージョンIDを固定し、移行は自分の都合で行う。

日本企業が​​確認すべき制約

機密情報を​扱う​設計の​考え方はAIガバナンスと​実装セキュリティで​整理している。

失敗パターン

「総合評価して」と1問で聞く。 複数の​観点を​1つの​質問に​詰めると、​Jevの​得意な​形から​外れる。​観点ごとに​分けて​聞き、​重み付けは​コードで​行う。

計算や日付比較を任せる。 公式が​明確に​苦手と​している​領域である。​金額・件数・期限の​判定は​コードに​残す。

「ハルシネーションしない」を「間違えない」と読む。 保証されているのは​型から​外れない​ことだけで、​判断ミスは​起こる。​confidenceに​よる​分岐と​人への​経路が​ない​設計は​危うい。

全文を状態に詰め込む。 無関係な​情報は​精度を​下げる。​先に​検索と​絞り込みを​行い、​質問に​必要な​項目だけを​渡す。

公表値のまま費用対効果を試算する。 193.6倍は​公式自身が​高い側と​書いている​値であり、​レイテンシは​日本からの​通信を​含まない。​自社の​業務と​環境で​測った​数字で​判断する。

エイリアスで本番運用する。 モデルの​更新で​答えの​傾向が​変わると、​調整した​閾値が​合わなくなる。​バージョンを​固定する。

すべての判断をJevに移そうとする。 Jevは​上位LLMの​代替ではない。​文章生成や​長い​推論は​LLMに​残し、​剥が​せる​判断だけを​剥がす。

FAQ

Q1. Jevは​​LLMの​​小型版なのか？

A. 公式は​「小さくもないし、​LLMでもない」と​答えている。​LLMが​文字列を​1トークンずつ生成するのに​対し、​Jevは​文字列を​生成せず、​あらかじめ定義した​選択肢・段階・真偽に​対する​確率を​並列に​出力する。​学習方​法も、​人の​好む文章を​目標に​する​RLHFではなく、​確率の​正確さ​（キャリブレーション）を​目標に​する​RLCDと​いう​独自の​手法を​使っている。

Q2. Jevは​​本当に​​ハルシネーションしないのか？

A. 定義した​型や​選択肢から​外れた​値を​返さない、と​いう​意味では​正しい。​これは​構造上の​性質である。​一方で、​正解が​Aなのに​Bを​選ぶと​いった​判断の​誤りは​起こりうる。​公式ドキュメントも、​キャリブレーションは​多数の​予測で​測る​ものであり、​個々の​答えが​正しい​ことは​保証しないと​書いている。​confidenceを​見て、​人や​上位LLMに​回す経路を​設計に​入れる​必要が​ある。

Q3. 日本から​​使っても​​70〜500msで​​返ってくるのか？

A. 保証は​ない。​公式は、​公表している​評価が​主に​米国西海岸から​実行され、​サービスの​拠点も​そこに​あると​書いている。​日本からの​呼び出しでは​通信の​往復時間が​加わる​ため、​自社の​環境から​p50と​p95を​実測してから、​リアルタイム用途に​使えるかを​判断すべきである。

Q4. 画像や​​音声を​​入力できるのか？

A. 2026年9月17日​時点では​テキストのみで、​画像・音声・動画は​未対応と​公式ドキュメントに​明記されている。​DOOMの​デモも​画面画像ではなく、​テキストを​含む構造化された​ゲーム状態を​入力している。​画像を​扱う​業務では、​画像認識モデルや​OCRで​構造化してから、​その​結果を​Jevに​判断させる​構成に​なる。

Q5. 上位LLMは​​不要に​​なるのか？

A. ならない。​Jevは​文章・コード・説明を​生成しないため、​回答文の​作成、​原因分析、​設計変更のような​処理は​引き続きLLMが​担う。​変わるのは、​LLMを​呼ぶ回数である。​分類・優先度・要レビュー判定のような​短い​判断を​Jevに​移し、​confidenceが​低い​案件や​生成が​必要な​案件だけを​LLMに​回す設計に​すると、​呼び出しを​必要な​場面に​絞れる。

Q6. 自社の​​データで​​追加学習する​​必要は​​あるか？

A. APIを​使う​前提と​して​追加学習は​不要である。​重要なのは、​判断を​原子的な​質問に​分解し、​選択肢と​基準を​正確に​書く​ことと、​組み合わせの​ルールや​閾値を​コード側で​持つことである。​ただし本番で​使うなら、​自社の​過去データで​正解率と​キャリブレーションを​検証し、​閾値を​決める​作業は​欠かせない。​な​お公式は、​ユーザーの​データで​モデルを​学習しない​方​針を​示している。

Q7. いま導入を​​決めるべきか？

A. 導入を​決めるより、​検証を​始める​段階である。​発表から​数日の​Early Accessで、​レート制限は​予告なく​変動すると​公式に​明記されており、​SLAや​サポート条件は​個別に​確認が​必要である。​ログと​正解ラベルが​既に​ある​業務を​1つ​選び、​シャドーモードで​2週間並走させて、​判断の​うち何割を​Jevに​移せるか、​確率が​実際の​正解の​頻度と​対応しているか、​confidenceの​どの​帯なら​自動化できるかを​測るのが​現実的である。

次に​​読むべき記事

• ハーネスエンジニアリングとは？​エージェント品質の​決め手 — 品質を​モデルではなく​仕組みに​預ける​設計
• AIエージェントの​Eval設計｜評価セットの​作り方 — 判断の​精度を​測る​評価セットの​作り方
• LLMトークン節約5パターン — LLMの​呼び出しコストを​設計で​下げる
• AIガバナンスと​実装セキュリティ｜6つの​制御点 — 機密情報を​外部​APIに​渡す前の​確認点
• AIエージェント完全ガイド — エージェントの​構築アプローチの​全体​像

まとめ

• Jevは​TypeSafe AIが​2026年9月15日に​発表した判断特化型のモデル。​文章を​生成せず、​Choice・Score・Noulの​3種類の​型付き判断と​確率を​返す。​現在は​Early Access
• 複数の​質問を​1回の​呼び出しで並列かつ独立に評価でき、​Choiceと​Scoreにはconfidenceが​付く。​confidenceと​行動の​リスクで、​自動実行・確認・​人への​回付を​分ける​設計が​前提に​なる
• 「193.6倍速い・444.6倍安い」は​公式の​独自評価の​数字で、公式自身が実運用では高い側の値と注記している。​「40〜200倍」も​System One型の​クエリに​限った​公式の​主張である。​レイテンシの​測定は​主に​米国西海岸からで、​日本からは​通信時間が​加わる
• 「ハルシネーションしない」は型から外れないという意味で、​判断ミスが​起きないと​いう​意味ではない
• 公式は苦手なことを8項目で公開している。​計算・カウント・​日付比較は​コードに​残し、​無関係な​情報は​渡さず、​文章生成は​LLMに​任せる
• 公開事例の​ブラウザ操作エージェントが​速いのは、​Jevに​「次の​操作を​選ぶ」と​いう狭い判断だけを任せた設計に​よる​部分が​大きい
• 使いどころは、上位LLMに考えさせていた処理から短い判断を剥がすことである。​営業の​優先度付け、​問い​合わせの​振り分け、​RAGの​文書選別、​ガードレール、​モデルルーティングが​候補に​なる
• 検証は、​ログと​正解が​揃った​業務で​シャドーモードの​並走から​始め、正解率、確率のキャリブレーション、confidence帯ごとの誤処理率を​測る。​本番化では​判断の​窓口を​1枚挟み、​バージョンを​固定する

FDXの​​支援範囲

FDXは​AX​（AI Transformation）の​実装パートナーと​して、​業務の​分解から​実装・現場定着・運用移管までを​対応領域と​する。

Jevのような​新しい​モデルが​出る​たびに、​モデル​その​ものは​入れ替わっていく。​残るのは、自社の業務の判断をどの原子的な質問に分解し、どの閾値で自動化し、どこで人や上位LLMに戻すかと​いう​設計である。​この​設計を​持っていれば、​どの​モデルが​次に​出ても​差し替えて​使える。

自社の​どの​判断を​モデルに​移せるかを​業務の​流れから​整理したい​場合はお問い合わせから、​まず​現状を​把握したい​場合はAX診断からどうぞ。

出典・参考文献

• TypeSafe AI, Diogo Almeida​「Introducing System One Models & Jev」​（2026年9月15日。​発表内容、​LLMとの​比較、​Workflow Evalsと​その​注記、​レイテンシの​測定地点、​価格の​持続性、​DOOM・Wikiracingの​デモ、​Choiceの​候補上限、​FAQ）
• TypeSafe AI Documentation​「Introduction」「System One」​（3つの​プリミティブ、​原子的な​質問、​テキストのみの​入力、​キャリブレーションは​個々の​正しさを​保証しない​こと。​2026年9月17日確認）
• TypeSafe AI Documentation​「Confidence」​（confidenceの​定義、​3段階の​使い分け、​リスクに​応じた​閾値）
• TypeSafe AI Documentation​「How to build with TypeSafe」​（3つの​ソフトウェアの​型、​コードが​制御の​流れを​持つ設計）
• TypeSafe AI Documentation​「Jev 1.13 jaggedness」​（2026年9月16日レビュー。​8つの​苦手な​領域と​回避策、​入力長の​上限）
• TypeSafe AI Documentation​「Models」「Example use cases」「Legal」​（価格、​レート制限、​エイリアスと​バージョン固定、​用途例、​データの​扱いと​ZDR）
• TypeSafe AI Documentation​「Parallel questions」「Re-ranking」​（まとめて​質問した​場合の​費用と​速度、​法律文書検索での​再ランキング）
• Browser Use​「jev-ultrafast README」「Faster on the real web」​（ブラウザ操作エージェントの​設計、​改良前後の​比較計測、​制約）

※ 英語資料からの​引用・要約は​編集部に​よる​翻訳である。​業務別の​用途マップと​検証の​進め方は、​公開情報を​踏まえた​編集部の​設計例であり、​TypeSafeの​公式機能や​性能を​保証する​ものではない。