Jev とは何か — 文章を書かずに判定だけを返す AI を、3Dプリントの工程に置く

「このファイルは刷ってよいか」と AI に聞くと、たいてい段落が返ってくる。「一般的には問題ありませんが」で始まり、条件をいくつか並べ、最後に念のための確認を勧める。人が読むなら親切な答えだが、プログラムに組み込みたい側には扱いにくい。こちらが欲しいのは「はい」か「いいえ」と、その確からしさだけだからだ。2026年9月15日に TypeSafe が early access として公開した Jev は、この食い違いを最初から起こさない作りのモデルである。
※本記事にはアフィリエイト広告(PR)が含まれます。
Jev は返信も、コードも、推論の説明も書かない。こちらが型を決めた問いに対して、選んだ答えと確率だけを返す。本記事では、このように文章を生成せず、型の決まった答えと確率を返すモデルを、英語の decision model の訳として判定モデルと呼ぶ。
先に本記事の立場を書いておく。ここに書くのは、TypeSafe の公式文書と公式ブログ、後発各社の公式発表、arXiv に投稿された論文から読み取れることが中心で、報道を引く箇所と、当サイトが手元で測った値はそのつど書き分ける。当サイトが Jev を呼んだ結果は、この記事には含まれていない。リクエストとレスポンスの形は公式ドキュメントの例をそのまま示し、速度や費用の倍率は提供元の自己申告として書き分ける。そのうえで後半では、3Dプリントの工程を「刷る前のファイルと設定」「造形中の状態」「造形中の画像」「止めるかどうかの判断」に分け、Jev が読める文字のデータと、Jev では読めない画像の境目を表にまとめる。
文章を返す AI に判定を任せると、どこで手間が増えるのか

対話型の AI に判定をさせると、手間は答えの手前ではなく後ろで増える。
一つ目は解析である。返ってくるのは文章なので、「はい」にあたる部分を抜き出す処理を自分で書くことになる。JSON で答えるよう指示しても、前置きの一文が付いたり、指定していない項目が混ざったりすることがある。抜き出しに失敗した回をどう扱うかまで決めておかないと、自動化の途中で処理が止まる。
二つ目はばらつきだ。同じ問いを二度投げると言い回しが変わる。「問題ないと考えられます」と「おそらく大丈夫です」のどちらがより確かなのかは、文面からは決められない。言葉の強さを数値に置き換える規則を自分で作れば、その規則がまた新しい誤りの元になる。
三つ目は確からしさの扱いである。判定を自動化するなら、最終的には「この値を超えたら止める」「この範囲なら人に回す」というしきい値が要る。しきい値を置くには数値が要るが、文章の答えには数値が付いてこない。AI に「確率を数字で答えよ」と頼むことはできても、その数字がどれだけ当たっているのかは別に確かめる必要がある。
3Dプリントの作業に引き寄せると、この手間は具体的な形をとる。配布されているモデルのライセンス文を読ませて、印刷物を売ってよいかを聞く。スライサーの設定を見せて、この組み合わせで刷り始めてよいかを聞く。造形中のプリンターの状態を渡して、止めるべきかを聞く。どれも最後に欲しいのはコードの分岐であり、段落ではない。判定モデルは、この「分岐に使える値」を直接返すことを目的に作られている。
Jev は何を返すのか

System One model という呼び方
TypeSafe は Jev を System One model と呼んでいる。名前の由来は、ダニエル・カーネマンが『ファスト&スロー』で広めた「System 1」、つまり速く直感的に判断する思考の側である。モデル名の Jev は、経済学者ウィリアム・スタンレー・ジェヴォンズにちなむと公式ブログは書いている。
公式文書の説明は明快である。System One model は返信を書かず、コードを生成せず、推論の説明も出さない。Jev について別のページでは、文章を生成せず、コードを書かず、会話もしないと重ねて書かれている。したがって、Claude Code のようなコーディングエージェントのモデル設定を Jev に差し替えて使う、という使い方は無い。Jev はエージェントを動かす言語モデルの代わりではなく、エージェントや既存のプログラムから呼ばれる判定の部品である。
何を入れて、何が返るのか
Jev に渡すのは、判定の対象となる内容(API では state と呼ぶ)と、名前を付けた問いの一覧である。state には文字列のほか、JSON のオブジェクトや文字の配列を渡せる。逆に、画像・音声・動画は受け付けない。公式文書は、文字でない入力は前処理で文字や構造化した項目にしてから送るよう案内している。
返ってくるのは、問いごとの答えと確率だ。モデルの ID は jev-1.13.0 で、jev-latest と jev-preview という別名がある。使う手段としては、Playground、HTTP の API(POST /v1/systemone)、Python の SDK(typesafe-sdk)、JavaScript/TypeScript の SDK、それに Jev を使うコードをコーディングエージェントに書かせるためのスキルが用意されている。スキルは Claude Code ではプラグインとして入り、Codex など他のエージェントにも入る。リポジトリは MIT ライセンスで公開されている。2026年9月16日からは Vercel の AI Gateway 経由でも Jev を呼べるようになり(AI SDK 7 の evaluate)、9月21日には TypeSafe のクライアントと HTTP の API からも AI Gateway を通せるようになった。
学習の方法と「較正」の意味
TypeSafe は Jev の学習方法を RLCD(Reinforcement Learning for Calibrated Decisions)と呼び、文章ではなく判定と較正された確率を返すように学習させると説明している。創業者の Diogo Almeida については、TypeSafe 自身が RLHF の共同発明者と紹介している。なお、RLCD という名前を使っているのは TypeSafe だけではない。後述する Cloudflare も、同じ名前の手法を自社のモデルの学習に使ったと書いている。
ここで「較正」の意味を押さえておく。確率が較正されているとは、たとえば確率 0.8 と答えた問いを数多く集めたとき、そのうち実際に「はい」だったものがおよそ8割になる、という集団としての性質を指す。TypeSafe の文書もこの点をはっきり書いており、較正は多数の予測の集まりで測るもので、個々の答えが正しいことを保証するものではないとしている。0.95 と返ってきた一件が外れることは当然ありうる。
問いの3つの型 — noul・choice・score

Jev への問いには型がある。型は3つで、TypeSafe の API での名前は noul・choice・score である。
noul — はい・いいえを確率で返す
noul は「はい」か「いいえ」で答える問いで、答えが「はい」である確率を 0 から 1 の数値で返す。「印刷物を販売してよいか」「この設定で刷り始めてよいか」のような問いがこれにあたる。公式の例では、答えは "noul": 0.95 のように数値一つで返る。
同じ型の呼び方は提供元によって違う。Vercel の AI Gateway の新しい API は boolean と呼び、OpenAI は predicate と呼んでいる。本記事では TypeSafe の呼び方に合わせて noul に統一する。
choice — 選択肢から一つを選び、全部の確率を返す
choice は、こちらが定義した選択肢の中から一つを選ぶ問いである。返ってくるのは、選ばれた選択肢と、全選択肢の確率の分布だ。選択肢は1つの問いに最大 255 個まで置ける。「止める・知らせる・続ける」のどれにするか、「どの設定項目が問題か」のように、分岐が3つ以上ある判定に向く。
score — 段階の尺度で評価する
score は、こちらが定めた段階の尺度に沿って評価させる問いである。段階は最低2つで、API は 10 段階まで受け付ける。返る値は各段階に確率で重みを付けた値で、段階と段階の間に落ちることもある。「この設定の組み合わせはどの程度危ういか」のような、程度を表す判定に使う型だ。
confidence は正しさの確率ではない
choice と score の答えには、確率とは別に confidence という 0 から 1 の値が付く。これは確率の分布から導く値で、確率がすべて一つの答えに集中しているときに 1、すべての答えに均等に散らばっているときに 0 になる。noul の答えには付かない。
注意したいのは、confidence が「答えが正しい確率」ではないことだ。分布がどれだけ一つに偏っているかを表しているにすぎない。手元で判定モデルを動かせる Ollama の文書は confidence を「正しさの較正ではない」と明記し、llama.cpp の説明も、確率が手元のデータに対して較正されている保証はないと書いている。確率と confidence を混同すると、しきい値の設計を誤る。
公式ドキュメントの例で見るリクエストとレスポンス
TypeSafe の API リファレンスに載っている choice の例を、そのまま引く。問い合わせの文面を、請求・技術・営業のどの担当に回すかを判定させるものだ。リクエストは次の形になる。
{
"state": "Help! My payouts have been failing for 3 days.",
"model": "jev-latest",
"questions": {
"department": {
"type": "choice",
"instructions": "Which team should handle this?",
"criteria": {
"billing": "Payments, invoicing, refunds",
"technical": "Bugs, outages, integrations",
"sales": "Pricing, upgrades, new accounts"
}
}
}
}
問いには自分で名前(この例では department)を付け、型(type)、問いの文(instructions)、選択肢とその説明(criteria)を書く。同じ例に対する応答として、公式ドキュメントには次の形が示されている。
{
"model": "jev-1.13.0",
"answers": {
"department": {
"type": "choice",
"choice": "billing",
"probabilities": { "billing": 0.88, "technical": 0.12, "sales": 0.0 },
"confidence": 0.81
}
},
"usage": { "input_tokens": 318, "output_tokens": 34 }
}
数値はいずれも公式ドキュメントに載っている例の値で、当サイトが得た結果ではない。読み取れることは三つある。まず、答えは問いに付けた名前と同じキーの下に返るので、文章を解析する処理が要らない。次に、選ばれた選択肢だけでなく、残りの選択肢の確率も返るので、「二番目の候補がどれだけ迫っていたか」まで分かる。最後に、リクエストでは別名の jev-latest を指定し、応答には実際に処理した版の jev-1.13.0 が返っている。後から結果を見返すときに、どの版の判定だったかを記録として残せる。
なお、公式文書は choice の confidence を、最も高い確率が均等な割り当て(選択肢が3つなら各 1/3)からどれだけ離れているかで計算すると書いている。この式に表示された確率 0.88 を当てはめると 0.82 になり、例の 0.81 とはわずかに差がある。差の理由は文書に書かれていないので、例の値は書き換えずに載せた。
一つのリクエストに複数の問いを並べることもできる。公式文書によれば、Jev は state を一度だけ読み、各問いをそれに対して並行に評価する。問いの数の上限は文書に書かれておらず、制約はトークン数のほうで決まる。
料金と上限 — 入力だけに課金され、出力は無料

2026年10月7日時点で公式文書に載っている値を並べる。
| 項目 | 値 |
|---|---|
| モデル ID | jev-1.13.0(別名 jev-latest・jev-preview) |
| 入力の料金 | 100万トークンあたり 0.042 ドル(約 6.65 円) |
| 出力の料金 | 無料 |
| 1リクエストの上限 | 64k トークン(うち state と最も長い問いの合計で 32k トークン) |
| 速度の上限 | 毎秒 10万トークン、毎秒 80 リクエスト |
| choice の選択肢 | 1つの問いに最大 255 |
| score の段階 | 2〜10 |
| 入力の種類 | 文字のみ(文字列・JSON オブジェクト・文字の配列) |
円の換算は、七十七銀行の 2026年10月7日の仲値 1ドル=158.45 円による。仮に1回の入力が 1,000 トークンなら、1,000 回で 100万トークンになり、入力の料金は約 6.65 円になる。実際のトークン数は渡す state と問いの長さで決まるので、この計算は目安の立て方として読んでほしい。上の公式の例の応答にも usage として output_tokens が載っているが、料金がかかるのは入力の側だけである。
速度の上限について、公式文書は動的に調整しており予告なく変わりうると書いている。上限の引き上げは個別の契約や企業向けのプランで扱う。
支払いは前払いのクレジットで、契約書によれば、注文時に別の定めが無い限り、購入したクレジットは購入日から最長 12 か月で失効する。新規登録時の無料分については、公式の文書に金額の記載が無く、契約書は販促用のクレジットを出すかどうかを TypeSafe の任意としているため、本記事では金額を書かない。
上限の書き方には一つ注意がある。Cloudflare は自社モデルとの比較で Jev の文脈の長さを 32k としているが、TypeSafe の文書には「1リクエスト 64k」と「state と最も長い問いの合計で 32k」の二つの数字が並んでいる。片方だけを引くと、何の上限なのかが変わってしまう。
データの扱いについては、Jev は顧客のリクエストと応答で学習しないと公式文書とプライバシーポリシーに書かれている。企業向けには、データを保持しない契約(ZDR)も用意されている。一方、通常のプランでの保存期間の日数は書かれていない。
Jev の料金は入力のトークン数で決まる。トークンが何を数えているのか、言語モデルが答えの確率をどう出しているのかを内側から押さえておくと、判定モデルとの違いも見えやすくなる。
何が新しく、何は新しくないのか

判定モデルの説明には、Jev だけの特徴に見えて、実はそうではない点がいくつか含まれている。順に切り分ける。
型を守るだけなら構造化出力でもできる
答えが決まった形で返ること自体は、新しくない。OpenAI の構造化出力(Structured Outputs)は、指定した JSON スキーマに沿った応答を生成させる機能で、型の正しさはここでも保たれる。ただし条件付きである。OpenAI の文書によれば、スキーマに使える書き方は JSON Schema の一部に限られ、モデルが安全上の理由で応答を断った場合や、出力の上限に達して応答が途中で終わった場合は、スキーマに沿った応答にならない。その場合の処理は呼ぶ側で用意しておく必要がある。OpenAI 自身も、自分の JSON スキーマに沿った物を生成させたいなら構造化出力、確率付きの型の答えが欲しいなら判定の API、と使い分けを説明している。
違いは確率にある。判定モデルは、選択肢ごとの確率を返し、その確率の較正を目的として学習されている。構造化出力は形を守らせる仕組みであり、選んだ答えがどれだけ確かなのかまでは返さない。
ログ確率と地続きの判定モデルもある
確率を返すという点も、技術としてはゼロからの発明ではない。公開されている判定モデルの一部は、答えの候補のロジット(確率に変える前の値)を softmax で確率に変える方式をとっている。Cloudflare も、試作の段階では大規模言語モデルが出すログ確率を使ったと書いている。つまり公開されている判定モデルの一部は、言語モデルのログ確率と地続きの技術である。
違いは、確率の較正を目的に学習しているかどうかにある。Jev については、TypeSafe は新しいモデル構造と並列のサンプラーを使い、トークンを1つずつ生成するのではなく、すべての確率を一度に出すと説明しており、よくある質問への答えでは Jev は LLM ではないとしている。ただし構造の詳細は公開されていないので、ここを後発の公開モデルから類推して書くことはしない。
なお、手元で使う側には一つ注意がある。Ollama の OpenAI 互換の API は、2026年10月7日時点でもログ確率に対応していない。Ollama で判定モデルの確率を得るには、後述する判定用の入口を使う必要がある。
課題ごとに学習させる分類器との違い
画像の不良検出のように、特定の課題のためにラベル付きのデータを集めて学習させた分類器は、以前から使われてきた。Jev を分析した論文も、従来の教師あり分類器は課題ごとのラベル付きデータと学習を必要とすると書いている。判定モデルの利点は、問いを書くだけで分類器として使える点にある。学習データを用意できない小さな判定や、問いの中身が頻繁に変わる判定では、この差が大きい。
反対に、同じ判定を大量に繰り返し、ラベル付きのデータも十分にある課題なら、その課題のために学習させた分類器が引き続き有力な選択肢である。判定モデルは、その手前の「学習させるほどではない判定」を広く拾う位置にある。
「幻覚しない」という主張の意味
TypeSafe の公式ブログには、幻覚(もっともらしい誤り)と型の安全性は本質的につながっている、という主張がある。その中身は、出力が事前に決めた型と選択肢から外れないことであり、スキーマとの一致は保証されている、という意味だ。同じブログは、示している数値が実測ではなく保証から導いたものであることも明記している。
したがって「Jev は間違えない」と読むのは誤りである。型や選択肢から外れた答えは返らないが、選択肢の中で誤ることはある。台湾の IT 媒体 iThome も、型が正しいことは判断が正しいことを意味しないと指摘している。
速さと費用の倍率は提供元の自己申告
公式ブログによれば、Jev の応答時間は 70〜500 ミリ秒で、System One に向いた形の問いでは、同等の知的水準の LLM より 40〜200 倍速いという。公開している評価はおおむね米国西海岸から自社のノートパソコンで測ったもので、サービス自体も現在は西海岸に置かれていると書かれている。日本から呼ぶ場合は、そのぶん通信の往復が加わる。
トップページに掲げている「193.6 倍速く、444.6 倍安い」という数字は、自社のワークフローでの評価から来たものだと公式ブログが説明しており、実際の利用で得られる差としては高い側の値だろうとも書いている。その評価では、GPT-6 Astra と Claude Fable 5.1 の答えの平均を基準の答えにしている。いずれも提供元自身の測定である。参考までに、Cloudflare は自社の測定で Jev の応答時間の中央値を 524.1 ミリ秒としており、測る人と場所が変われば値も変わることが分かる。比較の基準にされた2つのモデルについては、GPT-6 Astra は何を変えたのか — 発表と一次情報だけで現在地を測る(2026-09-14 公開)とClaude Fable 5.1 で何が変わったのか — 同じモデルの二つの名前と、キャッシュ読み取りが4分の1になった意味(2026-09-21 公開)で整理した。
では何が新しいのか
切り分けた結果、Jev の新しさは個々の要素ではなく、組み合わせ方にある。文章を一切書かないモデルを、確率の較正を目的に学習させ、型の決まった問いの API として、入力だけに課金する形で提供した。どの要素にも先例や同業の例はあるが、この組み合わせを一つの製品として出し、後発各社が同じ型のモデルや入口を続けて出した。それが次の節の話である。
同じ型のモデルが3週間で各社から出た

Jev の発表から3週間のうちに、同じ型の判定モデルや、それを呼ぶ入口が相次いで公開された。
| 日付 | 提供元 | 公開されたもの |
|---|---|---|
| 2026-09-15 | TypeSafe | Jev(early access) |
| 2026-09-16 | Vercel | AI Gateway から Jev を呼べるようにした(9月21日に TypeSafe のクライアントと HTTP の API にも対応) |
| 2026-09-18 | Bespoke Labs | 判定モデル Nimble(9B)の重みを Hugging Face で公開 |
| 2026-09-28 | Ollama | 0.35 で判定用の入口 /v1/systemone を追加 |
| 2026-10-01 | strands-labs | Strands Decider を公開(重みの Hugging Face 登録は 9月30日) |
| 2026-10-01 | Cloudflare | Clef(27B)と Clef-flash(9B) |
| 2026-10-01 | Ollama | Clef と Clef-flash への対応を取り込み(0.35.1 で配布) |
| 2026-10-02 | llama.cpp | サーバーに /v1/systemone を追加 |
| 2026-10-06 | OpenAI | Decisions API(公開ベータ) |
Bespoke Labs・Ollama・strands-labs・llama.cpp の行は、GitHub と Hugging Face の記録にある UTC の日付である。
後発の説明の仕方にも特徴がある。Ollama のブログの題は「Jev-style decision models」に対応したというもので、Cloudflare は自社モデルの性能を「Jev Decision Index」という基準で示している。どちらも、Jev を基準にして自社の位置を説明している。
Ollama — 手元の PC で判定モデルを動かす
Ollama は 0.35(UTC で2026年9月28日公開)で /v1/systemone という入口を追加し、Jev の API に基づく判定モデルを手元の PC で動かせるようにした。1回のリクエストで聞ける問いは 1〜64 問である。使えるモデルとして、Bespoke Labs の 9B の判定モデル Nimble と、Together AI の実験版 tev1(4B と 0.8B の2種)の3つが挙がっている。0.35.1 からは、画像も読める Cloudflare の Clef と Clef-flash にも対応した(対応のコードが取り込まれたのは UTC で2026年10月1日)。ソフトウェアと重みは無料だが、手元の GPU と電気代は自分の負担になる。手元で AI を回す構成の考え方はクラウドAIの請求書を見てローカルAIを考え直す — 手元のGPUで回る仕事と回らない仕事(2026-08-24 公開)にまとめてある。
Strands Decider — 文章を書く部分を外した小さなモデル
AWS が公開したエージェント開発キット Strands Agents の関連プロジェクト(strands-labs)は、2026年10月1日(UTC)に Strands Decider を公開した(重みの Hugging Face への登録は UTC で9月30日)。Qwen3.5-2B-Base から文章を生成するための出力部分を外し、選択肢を指す小さな出力部に置き換えた 1.9B のモデルで、ライセンスは Apache 2.0 である。画像は、判定のための追加の学習なしに受け付けるとしている。発表は Strands Agents の公式ブログで行われており、AWS のサイトでの告知は見つかっていない。
Cloudflare Clef — 画像も読める判定モデル
Cloudflare は 2026年10月1日に、Clef(27B)と Clef-flash(9B)を公開した。Workers AI で提供し、重みは Hugging Face に Apache 2.0 で置かれている。Clef は Qwen3.8-27B、Clef-flash は Qwen3.5-9B を固定したうえで作られており、入力を一度読み込む処理だけを行い、そのあと有効な選択肢を並行に採点する。確率の較正の調整には Brier 損失を使ったと書かれている。
Jev との最大の違いは画像を読めることで、Cloudflare 自身も「Jev は現時点で文字の分類しかしない」と対比している。Workers AI での Clef-flash の入力の料金は 100万トークンあたり 0.09 ドル(約 14.26 円)である。Cloudflare は自社の測定として、応答時間の中央値で Clef は Jev の 2.5 倍、Clef-flash は 13 倍速いとしているが、これも提供元の数字である。
Cloudflare の説明では、Clef は Jev と同じ形の API に従っており、既存の Jev の組み込みは接続先とモデル名を変えれば Clef に移せる。ただし、API の形が同じでも confidence の計算式まで同じとは限らない。TypeSafe は問いの型ごとに式を決めており(choice なら最も高い確率が均等な割り当てからどれだけ離れているか)、Ollama の /v1/systemone は確率の分布のエントロピーから計算している。手元の Ollama に移すなら、confidence のしきい値は測り直したほうがよい。
OpenAI Decisions API — 公開ベータで gpt-6-luna だけ
OpenAI は 2026年10月6日に Decisions API を公開ベータとして出した。使えるモデルは現時点で gpt-6-luna だけで、型は predicate・choice・score の3つである。画像も渡せるが、base64 で埋め込んだ data URL の形に限られる。料金は入力 100万トークンあたり 0.10 ドル(約 15.85 円)だけで、出力やキャッシュには課金されない。ただし、地域を指定した処理の割増と、長い入力に対する料金の倍率がかかる。OpenAI は「Responses API より10倍速い」と書いているが、これも自社の説明である。数週間のうちに正式版にする予定とされているので、料金や仕様は変わりうる。
なお、OpenAI の API は Jev とは形が違う。入力の名前、問いの並べ方、型の名前が異なるため、Jev 向けに書いたコードをそのまま OpenAI に向けることはできない。
共通点と相違点
入力だけに課金する料金の形も、型の決まった答えと確率を返すことも、Jev・OpenAI・Workers AI の Clef-flash に共通している。各社の間で違うのは、主に「画像を読めるか」と「手元で動かせるか」の二点だ。Jev と OpenAI は API でのみ使え、Clef-flash・Nimble・Strands Decider は手元でも動く。画像を読めるのは Clef 系と OpenAI(Strands Decider も、もとのモデルの機能で受け付ける)で、Jev と Nimble は文字だけを扱う。
Ollama のように判定モデルを手元の PC で動かす場合は、ローカルで言語モデルを動かす基本の流れを先に押さえておくと、/v1/systemone の扱いにも入りやすい。
公開プロジェクト 2,170 件で見た使われ方

Jev がどう使われ始めたかについては、早くも論文が出ている。中山大学と香港中文大学の研究者による arXiv 2609.30216「Jev in the Wild」(2026年9月24日投稿)は、2026年9月22日時点で GitHub から集めた、Jev を使う公開プロジェクト 2,170 件を分析した。
型ごとの使用率は、choice が 81.0%、noul が 72.2%、score が 45.4% だった。一つのプロジェクトが複数の型を使うので、合計は 100% を超える。2,170 件の内訳は、発表からの1週間で新しく作られたものが 1,865 件、既存のリポジトリが Jev を組み込んだものが 305 件である。
この数字には読み方の条件が付く。まず、査読前の論文である。次に、各プロジェクトの用途や、どの型を使っているかは、GPT-6 Luna Max のエージェントがリポジトリを読んで付けている。つまり上の型ごとの割合も、LLM が分類した結果をまとめたものだ。それでも、choice が最も多く使われているという結果は、二択で済まない分岐を組み込む用途が多いことをうかがわせ、3Dプリントの工程を考えるうえでも参考になる。
3Dプリントの工程のどこに置けるか

ここからが本題である。造形の工程には、「刷ってよいか」「止めるか」という判定がいくつも含まれている。それぞれの判定で AI に渡すものが文字なのか画像なのかを分けると、Jev の置き場所がはっきりする。
| 工程 | AI に渡すもの | 問いの例 | 向く型 | Jev で読めるか |
|---|---|---|---|---|
| 刷る前(ファイル) | 配布ページのライセンス文、作者の説明文 | 印刷物を販売してよいか | noul | 読める(文字) |
| 刷る前(設定) | 素材・ノズル温度・ベッド温度・プレートの組み合わせ | この組み合わせで刷り始めてよいか、どこが問題か | noul と choice | 読める(文字)。ただし数値の比較は規則で行う |
| 造形中(状態) | 温度・目標温度・進捗・エラーを並べた JSON | 止める・知らせる・続けるのどれか | choice | 読める(JSON) |
| 造形中(画像) | カメラの写真 | どの不良が出ているか | choice | 読めない。Clef-flash などで補う |
| 止めるかどうかの判断 | 上の判定の確率 | 確率がしきい値を超えたか | (コード側で処理) | 判定ではなく設計の問題 |
刷る前 — 配布ファイルのライセンス文
3Dモデルの配布サイトでは、作品ごとにライセンスが付いている。クリエイティブ・コモンズの各種や GPL、配布サイトが用意したライセンスなどが混在し、作者が説明文で条件を書き足していることもある。「印刷物を売ってよいか」「改変したものを公開してよいか」は、ライセンス文という文字のデータに対する判定であり、Jev がそのまま読める種類の入力だ。
ただし、AI の判定はライセンスの解釈についての法的な助言ではない。判定モデルの役割は、大量のファイルを仕分けて「人が条文を読むべきもの」を絞り込むところまでである。確率が中ほどに落ちたものは、条文を読み、必要なら作者に確認する側に回す。
もう一つ、言語の問題がある。TypeSafe は、学習の主な言語は英語で、日本語を含む CJK の文字は扱えるものの精度は同等ではないと書いている。日本語の説明文をそのまま渡すのか、英語の原文のライセンス名と組み合わせて渡すのかで、結果が変わりうる。自分の内容で試してから使うよう提供元も勧めている。
刷る前 — スライサーの設定値
Bambu Studio は、自社のフィラメントと、汎用(Generic)や他社製のフィラメントの公式プロファイルを GitHub で公開している。素材ごとの推奨のノズル温度やプレートごとのベッド温度が文字のデータとして手に入るので、「この素材にこのプレートとこの温度の組み合わせで刷り始めてよいか」という判定の材料を作れる。
ここで、Jev の苦手なことが効いてくる。TypeSafe は Jev 1.13 の苦手なことを一覧にして公開しており、数値の精度が要る作業、計算、日付の前後の比較(日付を順序のある量ではなく文字として読む)、RGB や 16 進の色の値が近いかどうかの判断、選択肢のうち最初のものに寄る傾向などを挙げ、「計算はコードの側に置け」と勧めている。
3Dプリントに当てはめると、ノズル温度が推奨範囲に入っているかのような数値の比較は、判定モデルに聞かずに規則で書くべきだということになる。フィラメントの色が指定に近いかを16進の値で聞くのも避けたほうがよい。選択肢の並び順で答えが偏るなら、「問題なし」をどこに置くかも設計の一部になる。
同じ一覧には、判定に関係の無い内容が state に多いほど精度が落ちることと、答えを誘導するように書かれた文が state に混ざると答えが動きうることも載っている。作者の説明文やプリンターの状態の JSON をそのまま渡す使い方では、この二つも関わってくる。
それでも判定モデルを使う候補になるのは、規則に書き下しにくい判断である。たとえば、素材名の表記の揺れや、製品ごとに違うプレートの呼び名を含んだ設定を渡し、「どの項目が問題か」を choice で聞く使い方だ。範囲の確認は規則で行い、表記の揺れを含む読み取りは判定モデルに渡す、と役割を分けられる。ただし、この分担がどこまで機能するかは、自分の設定で試すまで分からない。
造形中 — プリンターの状態
造形中のプリンターは、温度・目標温度・進捗・エラーといった状態を持っている。Klipper を使うプリンターでは、API サーバーの Moonraker がこうした状態を取得する API を公開している。状態を JSON にまとめて state に入れ、「止める・知らせる・続ける」を choice で聞けば、3つの選択肢それぞれの確率と confidence が返る。Jev は JSON のオブジェクトをそのまま受け付けるので、文章に書き直す必要はない。
ここで書いておくべき境界がある。判定モデルは、プリンター自体の安全機能の代わりではない。熱暴走の保護のような仕組みはプリンターの側で働くもので、判定モデルの答えでそれを置き換えることはできない。止める判定はあくまで補助であり、判定モデルを組み込んだからといって無人運転の安全が保証されるわけではない。
造形中 — カメラの画像は Jev では読めない
造形中の不良の多くは、目で見れば分かる。スパゲッティ状の崩れ、層のずれ、ベッドからの剥がれ。ところが Jev は画像を受け付けないので、この種の判定には使えない。ここは画像を読める判定モデルで補うことになる。
候補の一つが Cloudflare の Clef-flash である。重みが Apache 2.0 で公開されており、Ollama 0.35.1 以降なら手元の PC で画像を渡して判定させられる。
当サイトの環境(RTX 5070 Ti、VRAM 16,303 MiB)で Clef-flash の Q8_0 を Linux 版の Ollama 0.35.1(Windows 上の Docker のコンテナ)で読み込んだときは、モデルの分として 13,112 MiB の VRAM を使った(1回の測定)。なお、同じ環境の Windows 版の Ollama 0.35.1 では、試したかぎり Clef-flash の判定が毎回エラーになった。この不具合は報告されており、修正は2026年10月7日に開発中のコードへ取り込まれたが、同日時点で修正を含む版はまだ公開されていない。
API でよければ、OpenAI の Decisions API も画像を受け付ける。
画像の失敗検知そのものには、以前から使われてきた道具がある。造形中の画像から失敗を検出するために学習させた検出器がその代表で、仕組みと導入はもう睡眠不足にはならない:あなたのプリンターを24時間監視するAIエージェント(2026-01-09 公開)で、プリンターの内蔵カメラと後付けの道具の比べ方はAI 失敗検知 2026 — 内蔵カメラと後付けツール、どちらが「印刷の見張り」に向くか(2026-07-03 公開)で扱った。判定モデルは、こうした検出器を置き換えるというより、学習済みの検出器が対象にしていない問いを、問いを書くだけで足す道具として位置づけるのが妥当だろう。
止めるかどうかの判断 — 確率をしきい値で切る
判定モデルを工程に置く最大の利点は、答えが確率で返ることにある。確率が返れば、「0.9 を超えたら止める」「0.3 から 0.9 の間は人に知らせる」といった分岐を、コードの側で決められる。
どこで切るかは、間違えたときの損失の大きさで決まる。誤って止めれば、やり直しの時間と、途中まで使った材料が無駄になる。見逃せば、崩れた造形が続く間の材料と時間が失われる。どちらの損失が大きいかは、造形の長さや材料の値段で変わるので、一つの正解は無い。確率をしきい値で切る設計にしておけば、この損失の見積もりを変えるだけで振る舞いを調整できる。文章で答える AI では、この調整の手がかりそのものが無い。
ただし、先に書いたとおり、較正は多数の予測の集まりで成り立つ性質であり、一件ごとの保証ではない。しきい値を決める前に、自分の判定で確率がどれだけ当たっているかを、ある程度の件数で確かめておく必要がある。
本シリーズでスライサー設定の正解表に使ったのは、Bambu Lab P1S の公式プロファイルだ。同じ機種なら、記事の正解表をそのまま自分の判定の確かめに使える。
使う前に知っておく限界

ここまでの内容から、Jev を工程に組み込む前に押さえておくべき点を並べる。
- 提供状態は early access である。公式の表記は2026年10月7日時点でも early access のままである。順番待ちは9月下旬に外れたと報じられたが、公式の告知は確認できていない
- 入力は文字だけ。画像・音声・動画は受け付けない。画像の判定は、画像を読める別の判定モデルで補う
- 「幻覚しない」は型と選択肢から外れないという意味。選択肢の中で誤ることはある
- 速さと費用の倍率は提供元の自己申告。40〜200 倍、193.6 倍、444.6 倍といった数字は、測った人と場所と基準を確かめてから読む
- 英語が主で、日本語の精度は同等ではないと提供元が書いている。日本語のまま渡すなら、自分の内容で確かめる
- 苦手なことが公開されている。数値の精度、計算、日付の比較、色の値の近さ、選択肢の並び順による偏り、判定に関係の無い内容の多い入力、答えを誘導するように書かれた文など。計算と数値の比較は規則で書く
- 確率の較正は集団の性質で、confidence は正しさの確率ではない。しきい値は自分のデータで確かめてから決める
- 速度の上限は予告なく変わりうる。造形中の状態を短い間隔で問い合わせる設計なら、上限に当たったときの再送を組み込んでおく
- プリンター自体の安全機能の代わりではない。止める判定は補助として扱う
このうち多くは、提供元が自分の文書に書いている内容である。組み込む前に該当するページを読んでおけば避けられる誤りが多い。
まとめ — Jev を工程に置く前にやること

Jev は、文章を書かずに、型の決まった答えと確率だけを返す判定モデルである。型の正しさも、入力だけの課金も、確率を返すことも、それぞれは Jev だけのものではない。しかし、これらを一つの API にまとめて出した後、3週間のうちに Bespoke Labs、Ollama、strands-labs、Cloudflare、OpenAI が同じ型の判定モデルや入口を公開した。
3Dプリントの工程に置くなら、次の順で考えるとよい。
- 判定を文字と画像に分ける。ライセンス文・設定値・状態の JSON は Jev が読める。カメラの画像は読めないので、Clef-flash のような画像を読める判定モデルか、学習済みの検出器に任せる
- 数値の比較と計算は規則で書く。温度が範囲に入っているかは判定モデルに聞かない。判定モデルには、規則に書き下しにくい判断だけを渡す
- 問いの型を選ぶ。二択なら noul、三つ以上の分岐なら choice、程度なら score。confidence が要るなら choice か score にする
- しきい値を損失で決め、自分のデータで確かめる。確率は一件ごとの保証ではない
- 安全機能の代わりにしない。止める判定は補助であり、人に知らせる経路を残す
判定モデルが工程に入ると、AI に期待する役割が「説明してもらう」から「分岐の値を出してもらう」に変わる。まずは自分の工程のうち、説明が要らず分岐の値だけが要る判定がどれかを洗い出すところから始めたい。
参照
- TypeSafe 公式ブログ「Introducing System One Models & Jev」(2026-09-15)
- TypeSafe Docs「Models」
- TypeSafe Docs「API reference」
- TypeSafe Docs「Confidence」
- TypeSafe Docs「System One」
- TypeSafe Docs「AI primer」
- TypeSafe Docs「Jev with coding agents」
- TypeSafe Docs「Jev 1.13 jaggedness」
- TypeSafe Docs「Agent skill」
- TypeSafe Docs「Quick start」
- TypeSafe Docs「Client SDKs」
- TypeSafe Docs「Legal」
- TypeSafe Privacy Policy
- TypeSafe Master Customer Agreement
- typesafe-ai/skills の LICENSE
- arXiv:2609.30216「Jev in the Wild」
- Vercel Changelog「TypeSafe AI Jev now available on AI Gateway」(2026-09-16)
- Vercel Changelog「AI Gateway now supports TypeSafe clients and an HTTP API for Jev」
- iThome の Jev の報道(二次情報)
- Ollama Blog「Ollama now supports Jev-style decision models」
- Ollama Docs「System One」
- Ollama Docs「Decision」
- Ollama Docs「OpenAI compatibility」
- Ollama v0.35.1 リリース
- ollama/ollama PR #18741(Clef への対応)
- Ollama ライブラリ「nimble」
- Cloudflare Blog「Introducing Clef: our open-source decision models, and new RL fine-tuning platform」
- Cloudflare Changelog「Clef on Workers AI」
- Workers AI「clef-flash」
- Hugging Face「Cloudflare/clef-flash」
- Bespoke Labs「nimble」README
- Hugging Face「bespokelabs/Bespoke-Nimble-9B」
- strands-labs「strands-decider」README
- Strands Agents Blog「Introducing Strands Decider」
- AWS Open Source Blog「Introducing Strands Agents, an Open Source AI Agents SDK」
- OpenAI API Docs「Decisions」
- OpenAI API Changelog
- OpenAI API Docs「Structured Outputs」
- llama.cpp server README
- llama.cpp PR #29818(/v1/systemone の追加)
- ollama/ollama Issue #18769
- ollama/ollama PR #18777(Windows 版の Clef-flash の修正)
- Moonraker Docs「Printer Administration」
- bambulab/BambuStudio の公式フィラメントプロファイル
- 七十七銀行 米ドル対円相場(仲値)一覧表 2026年





