2026年9月15日に、文章を生成しないAIモデルが出ました。TypeSafe AIの「Jev」です。返すのは型のついた値と、確率と、信頼度。人間が読むためではなく、ソフトウェアがそのまま使うための出力です。
このサイトは「自分のサーバーで動かした記録」を書いています。なので、最初に確認したのはこれを自前で動かせるのかでした。
確認できた範囲では、動かせません。 そして、その理由の書かれ方が少し特殊でした。
確認できたこと
- Jevのウェイトは公開されていない。 ライセンスはproprietary(専有)で、アーキテクチャも技術論文も公開されていないとされている
- セルフホストの選択肢について、公式サイト・Cloudflareのドキュメント・Wikipedia・技術メディアの4か所を見ても、記載が1つもなかった
- 提供はホスト型APIのみ。エンドポイントは
api.typesafe.ai/v1/systemone - 価格は入力100万トークンあたり$0.042。出力トークンは課金されない(2つの情報源で一致)
- コンテキスト長については、情報源が食い違っている(後述)
- 応答時間は70〜500ミリ秒とされている
私はJevを実際には叩いていません。 この記事は公開情報の確認と、自前で同じことをやる場合の計算です。そこは最後にはっきり書きます。
Jevが何を返すのか(最小限)
大規模言語モデルと違い、Jevは自然言語のテキストを返しません。用意されているのは3種類の問い方です。
| プリミティブ | 何をするか | 返ってくるもの |
|---|---|---|
| Choice | 選択肢から1つ選ぶ(最大255個) | 選択肢・確率・信頼度 |
| Score | 順序のある段階で評価する | スコア・段階別の確率・信頼度 |
| Noul | はい/いいえを判定する | 0〜1の確率 |
信頼度は確率分布の形から出しており、高信頼度は自動処理へ、中程度はレビューへ、低信頼度は人間へという振り分けが想定されています。
「判断だけを返す」というのは、つまりこういうことです。文章を読ませて要約させるのではなく、「この問い合わせは対応が必要か」に0〜1で答えさせる。 用途がはっきり分かれています。
自前サーバーで動かせるのか
4か所を確認しました。
| 確認先 | セルフホストに関する記載 |
|---|---|
| TypeSafe AI 公式サイト | 記載なし(early accessの案内、コンソール、ドキュメントへのリンクのみ) |
| Cloudflare AI のモデルドキュメント | 記載なし(typesafe/jev として第三者製モデルを提供) |
| Wikipedia | ライセンスはproprietary。「アーキテクチャ、ウェイト、技術論文のいずれも公開していない」 |
| MarkTechPost | 「TypeSafe has not published weights, a parameter count, or a self-hosting option」 |
注意して書きます。「できない」と断定できるのは、公式が明示的に禁じている場合です。 ここで確認できたのは、そのための情報が公開されていないということです。ウェイトが無ければ動かしようがないので、実務上は「できない」と同じですが、書き方は分けておきます。
つまりJevを使うということは、判断を外部のAPIに投げるということです。自前サーバーの話とは、前提が逆になります。
情報が食い違っている点:コンテキスト長
ここは正直に書きます。2つの情報源で、記載が食い違っています。
- Cloudflare AI のドキュメント:コンテキストウィンドウ 32,000トークン
- MarkTechPost:「Context length and model size remain undisclosed(コンテキスト長とモデルサイズは非公開のまま)」
TypeSafe自身が公開していない数字を、提供事業者であるCloudflareが自社ドキュメントに書いている、という形です。どちらが正しいのかは、私には判断できませんでした。
Cloudflare経由で使う場合は32,000で考えてよさそうですが、TypeSafeのAPIを直接叩く場合に同じとは限りません。 長い入力を投げる設計にするなら、ここは自分で確かめてください。
同じことを自前の小型モデルでやれるか
「判断だけ返してほしい」なら、自前の小型モデルでもできそうに見えます。実測した範囲では、厳しいです。
さくらのVPS 2Gプラン(GPUなし・CPUのみ)で測った数字です。
| 実測値 | |
|---|---|
| Ollama本体の常駐メモリ | 36MB |
| 0.5Bモデルの生成速度 | 15.36 tok/s |
| 0.5Bのロード時間 | 3.18秒 |
| 1Bモデルの生成速度 | 0.07 tok/s(実用外) |
| 必要メモリ | モデルファイル × 約2.4 |
速度の問題より、性質の問題のほうが大きいと考えています。
0.5Bクラスに判断させると、出力が安定しません。 実際、日本語で答えさせたときに「東京」が簡体字の「东京」になりました。文章としては読めますが、これを機械が受け取る前提の構造化データにするには、後段で整形と検証が要ります。 Jevが返すのは最初から型のついた値と確率なので、そこが要りません。
加えて、Ollamaは既定で5分アイドルするとモデルをメモリから降ろします。 つまり、たまにしか呼ばない判断処理だと、毎回ロード時間を払い直すことになります。詳しくはOllamaの使い方に書きました。Jevの応答は70〜500ミリ秒とされているので、この用途では桁が違います。
費用はどこで逆転するか
ここからは計算値です。 実測ではありません。
Jevの価格は入力100万トークンあたり$0.042、出力は無課金。仮に1件の判断で入力500トークンを使うとすると、
500トークン ÷ 1,000,000 × $0.042 = $0.000021 / 件
一方、自前で動かす側は固定費です。さくらのVPS 2Gプランは月額1,706円(2026年9月時点の公式価格・税込)。1ドル150円と仮定すると約$11.37。
$11.37 ÷ $0.000021 ≒ 約54万件 / 月
月に54万件、1日あたり18,000件の判断を回して、ようやく費用が並びます。 そこまで行かないなら、Jevを呼ぶほうが安いという計算になります。
ただし前提が1つあります。上の計算は、この用途のためにVPSを新しく借りる場合の話です。 私のように、すでに別の用途でVPSを借りていて空きメモリがある場合、Ollamaを追加で動かす費用はゼロです。その場合、比較の土台が変わります。 プランの積み上げはAI用途のVPSは何GB必要かに書きました。
それでも自前を選ぶ理由があるとすれば
費用と速度では、判断タスクに関して自前の小型モデルに勝ち目が見えませんでした。それでも自前を選ぶ理由があるとすれば、費用ではありません。
- データを外に出せない。 要件として決まっている場合、比較の問題ではなくなります
- 外部サービスの終了や仕様変更に縛られたくない。 ウェイトが手元にあるかどうかの差です
「自前AI」という名前のサイトですが、自前が常に正しいとは書きません。 測って、計算して、負けているところは負けていると書きます。判断だけを返すAPIが$0.042/100万トークンで使えるなら、判断タスクを自前の0.5Bで回す理由は、上の2つ以外に見つかりませんでした。
この記事が書けなかったこと
- 私はJevを実際に使っていません。 公式サイト、Cloudflareのドキュメント、Wikipedia、技術メディアの記載を確認しただけです。精度も速度も自分では測っていません
- コンテキスト長はどちらが正しいか判断できませんでした(Cloudflareは32,000、TypeSafeは非公開)
- 一般公開の時期を確認できませんでした。 2026年9月22日時点で、公式サイトには early access の案内が出ています
- モデルサイズもアーキテクチャも公開されていないので、なぜ速くて安いのかは説明できません
- 1ドル150円という前提で計算しています。 為替で結論の分岐点は動きます
- 0.5Bで判断タスクをやらせる実験はしていません。 生成速度と日本語品質の実測から「厳しい」と書きましたが、判定精度そのものは測っていません
出典
- Jev (AI model) - Wikipedia(ライセンス、ウェイト非公開、公開日/2026年9月22日確認)
- TypeSafe AI 公式サイト(early accessの案内、入力価格/2026年9月22日確認)
- Jev (typesafe) · Cloudflare AI docs(モデルID、コンテキストウィンドウ、入出力仕様/2026年9月22日確認)
- TypeSafe AI Releases Jev - MarkTechPost(プリミティブの仕様、価格、セルフホストに関する記載/2026年9月22日確認)
- 実測値は当サイトの測定による(さくらのVPS 2Gプラン / Ubuntu 24.04 LTS / GPUなし / Ollama 0.33.3)
関連記事
- GPUなしでローカルLLMは使えるのか — 自前で動かす場合に載るモデルの決め方
- Ollamaの使い方 — 5分でアンロードされる話とロード時間
- VPSにローカルLLMを構築する — 自前側の構築手順