Jev の API を使うか、同じ型のモデルを手元で回すか — 工程ごとに選ぶ逆引きガイド

3Dプリントの工程に「この設定で刷ってよいか」「この造形を止めるか」を判定する AI を置こうとすると、最初に迷うのはモデルの賢さではなく、どこで動かすかだ。TypeSafe の Jev の API を契約するのか、OpenAI や Cloudflare の API にするのか、それとも同じ型のモデルを手元の GPU で回すのか。料金は各社の料金表に、画像を読めるかどうかはモデルのページに、送った内容がどこにどれだけ残るかは規約とデータの扱いのページに書かれている。手元で動かすときに要る VRAM は、どこにも書かれていない。

※本記事にはアフィリエイト広告（PR）が含まれます。

本記事では、文章を書かずに、型を決めた問いへの答えと確率だけを返すモデルを、英語の decision model の訳として判定モデルと呼ぶ。

比べるのは5つの実行先である。API は、Jev、OpenAI の Decisions API（モデルは gpt-6-luna、公開ベータ）、Cloudflare Workers AI の clef-flash の3つ。手元は Ollama と llama.cpp の2つで、動かすモデルは Cloudflare が公開した Clef-flash と、Bespoke Labs の Nimble 9B（Ollama 配布版）である。これらを入力の種類・データの扱い・費用・上限・ライセンス・手元の VRAM と速度・導入の手間で比べ、ファイルのライセンス、スライサーの設定、プリンターの状態、造形中の画像、止めるかどうかの判断という工程ごとに、どれを選ぶかを逆引きできる形にまとめる。

先に立場をはっきりさせておく。当サイトは Jev の API も、OpenAI の Decisions API も、Workers AI も実行していない。API の費用は、公式の入力単価に、手元のモデルで数えたトークン数を掛けた試算である。手元の VRAM と時間は、当サイトの RTX 5070 Ti で 2026年10月7日に測った値だ。測定は各モデル1回で、1回あたりの時間はその中で5回ずつ問い合わせた中央値である。どの数字も、この条件を付けたまま読んでほしい。

API か手元か、判断の材料がばらばらに散っている

判定モデルの選択肢は、2026年9月中旬から10月上旬までの3週間ほどで一気に増えた。Jev が9月15日に early access として公開され、Ollama は 0.35（UTC で9月28日公開）で判定用の入口 /v1/systemone を追加した。Cloudflare は10月1日に Clef と Clef-flash を公開し、llama.cpp は10月2日にサーバーへ同じ入口を足した。OpenAI は10月6日に Decisions API を公開ベータとして出している。判定モデルの仕組みと各社の位置づけは、Jev とは何か — 文章を書かずに判定だけを返す AI を、3Dプリントの工程に置く（2026-10-12 公開）で整理した。

選択肢が出そろうと、次に困るのは比べ方である。各社の説明は、それぞれの得意なところから書かれている。Cloudflare は画像を読めることを、Ollama は手元で動くことを、TypeSafe は確率の較正を前に出す。しかし、3Dプリントの工程に置くときに効いてくる条件は、別のところにある。

• 渡したいのはカメラの画像か、それともライセンス文や設定値のような文字だけか
• 作業場の写真や、取引先から預かった設計に結びつく設定を、外部に送ってよいか
• 造形中に1分おきに問い合わせたら、費用はどれくらい積み上がるか
• 手元の GPU に載るか、載るとして1回に何秒かかるか

最後の問いには、どの提供元も答えていない。Clef-flash と Nimble の必要 VRAM は、Hugging Face のモデルカードにも Ollama のページにも書かれていない。Clef-flash の参照実装は H200 を1枚使って試したと書かれ、Nimble の参照実装（v2）は H100 80GB で測ったと書かれているが、どちらも家庭で使う GPU の目安にはならない。

料金の比べ方にも落とし穴がある。API の3社とも、料金表に載っているのは入力の単価だけで、単位は 100万トークンあたりだ。ところが、トークンの数え方はモデルごとに違い、1回の判定が何トークンになるかは、渡す内容と問いの長さで決まる。単価を横に並べただけでは、1,000 回の判定にいくらかかるのかは見えてこない。そこで本記事では、当サイトが手元で行った実行のトークン数を使って、工程ごとの費用を試算する。

選ぶ順序 — 入力の種類、データの扱い、費用、手元の GPU

材料が散っているときは、比べる順序を先に決めておくと迷いが減る。ローカルとクラウドの担当を決める — 用途で振り分けるAI環境構築の逆引きガイド（2026-08-30 公開）では、データを外に出せるかどうかを最初の分かれ目にした。判定モデルでは、その手前にもう一つ、入力の種類という分かれ目が来る。

1. 入力は文字か、画像か。Jev は文字しか受け付けない。公式文書は画像・音声・動画を受け付けないと明記し、文字でない入力は前処理で文字や構造化した項目にしてから送るよう案内している。画像を直接渡すなら Jev は候補から外れ、OpenAI の Decisions API、Workers AI の clef-flash、手元の Clef-flash が残る。手元の Nimble 9B も文字だけを読む
2. データを外に出してよいか。出せないなら手元しかない。出せる場合、API の3社はいずれも送った内容を学習に使わないと書いているので、違いは「どこに、どれだけの期間残るか」になる
3. 1,000 回あたりいくらか。単価ではなく、自分の判定1回のトークン数から計算する。判定モデルの API どうしの差は小さく、大きく開くのは、文章を書く一般のモデルに判定させる場合との間である
4. 手元の GPU に載るか。手元を選ぶなら、VRAM と1回の時間を自分の環境で測る。当サイトの 16GB のカードでは、Clef-flash を載せると空きはほとんど残らなかった

この順序には理由がある。入力の種類とデータの扱いは、満たせなければほかの条件を比べる意味がない制約だ。画像を読めないモデルは、どれほど安くても画像の判定には使えない。外に出せない写真は、どれほど速い API にも送れない。費用と GPU は、その二つを通った候補の間で比べる量の問題になる。

日本語の扱いも、順序の早い段階で確かめておきたい。TypeSafe は、Jev の学習の主な言語は英語で、日本語を含む CJK の文字は扱えるものの精度は同等ではないと書いている。日本語の説明文や、日本語で書いた設定のメモをそのまま渡すなら、手元のモデルやほかの API と同じ問いで比べてから決めるほうがよい。差の大きさは、自分の内容で確かめるしかない。

作業場の写真や、預かった設計に結びつく設定を外部のサービスに送ってよいかは、生成 AI を業務で使うときのセキュリティの問題でもある。データの扱いを整理する一冊を挙げておく。

生成AIセキュリティの教科書

¥1,650 （2026/09/22 15:04時点 | Amazon調べ）

Amazon

楽天市場

ポチップ

5つの実行先を並べる — Jev の API・OpenAI・Workers AI・Ollama・llama.cpp

料金・入力・上限

2026年10月7日に各社の公式ページで確かめた値を並べる。円の換算は七十七銀行の同日の仲値（1ドル＝158.45 円）による。

まず料金から見る。出力に課金しない形は Jev に限らない。OpenAI は入力のトークンにだけ課金すると明記し、Workers AI の料金表にも入力の単価しか載っていない。入力の単価で比べると Jev が最も安く、Workers AI の clef-flash、OpenAI の順に続く。ただし OpenAI には、地域を指定した処理の割増と、長い入力に対する倍率がかかる。ベータの間は、料金や仕様が変わりうることも前提にしておく。

画像の行は、提供元ごとに渡し方まで違う。OpenAI は base64 で埋め込んだ data URL しか受け付けない。Workers AI は base64 の data URL か、content_type と base64 を分けたオブジェクトで受け取り、外部の URL は指定できない。1回に4枚までで、1枚あたり 4 MiB・1,600 万画素、デコード後の合計 8 MiB、リクエスト全体で 13 MiB という上限がある。手元の Ollama は base64 の文字列を受け取るが、data URL は受け付けない。llama.cpp は逆に data URL しか受け付けない。同じ写真を送るにも、実行先ごとに包み方を変える必要がある。

長い入力の扱いにも違いがある。Workers AI の clef-flash は、長すぎる文字の state をモデルに収まるよう切り詰める。Ollama は入力を切り詰めず、読み込んだ文脈に収まらない入力はエラーで返す。Nimble 9B の文脈は 8,192 トークンなので、これを超える長い G-code やログは受け付けられない。切り詰められたことに気づかないまま判定が返ってくる事態も、エラーで判定が返らない事態も避けたいので、長い入力を渡すなら、手前で必要な部分だけを抜き出しておくほうが安全だ。

文脈の長さの表記にも注意がいる。Jev は「1リクエスト 64k トークン」と「state と最も長い問いの合計で 32k トークン」の二つの数字を並べている。片方だけを引くと、何の上限なのかが変わってしまう。Clef-flash は Workers AI のページで 65,536 トークンとされているが、Ollama のページには 256K という表示と 64K という説明文が混在している。本記事では Workers AI の 65,536 を使う。

データの扱い・ライセンス・支払い

学習に使わないという点は、API の3社に共通している。違いが出るのは保存である。OpenAI は、/v1/decisions に送ったデータを不正利用の監視のために最長 30 日保持するとしている。データを保持しない契約（ZDR）もあるが、対象は条件を満たし、承認を受けた顧客だ。条件を満たした顧客は、データの所在地を米国と欧州（EEA とスイス）から選べる（米国以外は追加の承認と契約が要り、所在地の指定には料金の割増がかかる）。TypeSafe は企業向けに ZDR を用意しているが、通常のプランで何日保存するかは書いておらず、データ処理の契約は「必要な間」保持すると書く。Cloudflare は Clef の発表で、リクエストと応答を読まず、保存せず、学習にも使わないとしている（微調整のサービスを使う場合を除く）。

手元の実行は、そもそも外に出ない。Ollama は、手元で動かしている間は入力やデータを見ないと FAQ に書き、手元へのリクエストには API キーも要らない。llama.cpp には同じ趣旨の説明文は見当たらないが、構成として手元で完結する。

ライセンスで気をつけたいのは Nimble の版である。Ollama で配布されている nimble は、Bespoke-Nimble-9B の LoRA と Qwen3.5-9B を合わせたもので、どちらも Apache 2.0 だ。ところが Bespoke Labs の v3 は CC BY-NC 4.0 で、商用には使えない。llama.cpp 向けに ggml-org が配布している Nimble の GGUF は v3 なので、それを使うと非商用の重みになる。印刷物を販売する工房や業務で使うなら、版を確かめずに「Nimble は Apache 2.0」と判断しないことだ。当サイトも、手元で使う Nimble は Ollama 配布版に限っている。

支払いの形も違う。Jev は前払いのクレジット制で、契約書によれば、注文時に別の定めが無い限り、買ったクレジットは購入日から最長 12 か月で失効する。新規登録時の無料分は公式の文書に金額の記載が無く、契約書は販促用のクレジットを出すかどうかを TypeSafe の任意としている。OpenAI も、新規の API アカウントは前払いのクレジットで、買ったクレジットは1年で失効する。

Workers AI は、Workers AI 全体で1日1万 Neurons まで無料で、Workers の無料プランでも使える。clef-flash だけに使うと、計算上は入力で1日あたり約 122 万トークンになる。これを超えて使うには、最低月5ドル（約 792 円）の有料プラン（Workers Paid）が要る。なお、Vercel の AI Gateway を経由すれば、Jev の請求を AI Gateway の側にまとめることもできる。

1,000 回あたりの費用の目安 — 公式単価と手元で数えたトークン数からの試算

費用の試算は、1回あたりの入力トークン数の中央値に 1,000 を掛け、100万で割り、入力単価を掛けて出した。トークン数は、当サイトが2026年10月7日に手元で行った実行で、Nimble 9B と Clef-flash が返した usage.input_tokens の中央値を使っている。

ここには大きな但し書きが付く。Nimble と Clef-flash はどちらも Qwen3.5 系のモデルで、そのトークンの数え方が Jev や OpenAI と同じとは限らない。さらに Ollama の文書は、問いを一つずつ採点するモデルでは、共有の文脈を問いの数だけ数え直すと書いている。Jev は state を一度だけ読み、すべての問いをそれに対して並行に評価すると説明しているので、同じ内容でも数え方が変わりうる。したがって下の表は、各社の請求額の予測ではなく、桁の目安として読んでほしい。

claude -p の列は試算ではなく実測である。Claude Code の非対話実行 claude -p（Sonnet 5.5）を、ツール・MCP・設定ファイルを読み込まない最小構成で動かし、記録された費用の1回平均を 1,000 倍した。これは Claude Code を経由した実行の費用で、入力の内訳（トークン数）は記録していない。Claude の API を直接呼んだ場合の費用とは違いうる。

プリンターの状態の行は、トークン数は最終の例で数え、claude -p の費用は例を直す前の最初の実行の値を使った。例を直した後の実行では、直前に同じ入力を送っていた4件の費用が1件 0.0035〜0.0057 ドルに下がり（直前の入力のキャッシュが効いたとみられる）、6件の平均は 1,000 回あたり 11.73 ドルだった。claude -p の費用は、直前に同じ入力を送ったかどうかで大きく変わる。

表から読み取れることは三つある。

一つ目に、判定モデルの API の試算は、どの工程でも 1,000 回あたり約5〜30 円に収まった（1ドル＝158.45 円で換算）。ライセンス文の判定なら、Jev で約 10.8 円、Workers AI で約 23.2 円、OpenAI で約 25.7 円になる。単価の差はそのまま残るが、絶対額はどれも小さい。

二つ目に、文章を書く一般のモデルに判定させた claude -p の実測は、1,000 回あたり 21〜25 ドル（約 3,400〜4,000 円）で、判定モデルの API の試算とは 100 倍以上の開きがあった。ただし、これは Claude Code を経由した実行の費用で、入力の内訳は記録していないため、Claude の API を直接呼んだ場合の差としてそのまま読むことはできない。

三つ目に、回数に置き換えると規模がつかみやすい。1分おきに1回問い合わせると、1,000 回はおよそ 16.7 時間の造形にあたる。造形中の画像を1分おきに Workers AI の clef-flash に送っても、その 16.7 時間で約 13.5 円という計算になる。プリンター1台の監視なら、判定1回ごとの料金が選択を左右する場面は少ない。

むしろ効いてくるのは、無料枠と最低料金である。Workers AI の無料枠を画像の判定に当てると、手元と同じ 948 トークンで数えた場合、計算上は1日に約 1,290 回分になる。1分おきに24時間問い合わせると 1,440 回なので、わずかに超える。この計算は入力だけで数えたもので、出力の分は料金表に載っていない。超えた分のために有料プランへ移ると、最低月5ドル（約 792 円）が先にかかり、判定ごとの料金よりこちらのほうがずっと大きい。Jev はクレジットが最長 12 か月で失効するので、少しずつ使う場合は買う額を小さくしておくとよい。

手元で動かすときの実測と注意

Clef-flash と Nimble 9B の VRAM と時間

測り方は次のとおりだ。GPU は RTX 5070 Ti（16,303 MiB）で、Ollama は 0.35.1。モデルを外した状態の VRAM を基準にし、モデルを読み込んだ後との差を「モデルの分」とした。デスクトップのアプリが同じ GPU を使っているので、基準は毎回測り直している。文字の判定は noul（はい・いいえを確率で返す型）の問い1つ、画像の判定は長辺 1024px の JPEG 1枚で、モデルを読み込んだ後にそれぞれ5回ずつ問い合わせ、時間はその中央値を取った。

Clef-flash は、モデルの分だけで 13,112 MiB を使った。デスクトップの分と合わせると 15,391 MiB で、16,303 MiB のカードの空きは 912 MiB しか残らない。画像生成のような別の GPU の仕事と同時に動かす余地は無い。Nimble 9B は 8,953 MiB だった。二つのモデルの分を足すと 22,065 MiB になり、このカードには同時に載らない。両方を使うなら、片方を外してからもう片方を読み込むことになり、そのたびに初回の読み込みの時間がかかる。

時間は、二つのモデルの値を並べて比べてはいけない。Clef-flash は Windows 版の Ollama で動かなかったため（次の節）Docker 上の Linux 版で、Nimble は Windows 版で測っている。文字1回の中央値は Clef-flash が 330 ms、Nimble が 2,197 ms と開いたが、実行環境が違うので、この差をモデルの速さの差と読むことはできない。VRAM の値も同じく別々の実行環境で測ったもので、同じ環境では測り直していない。

同じモデルでも、測る実行が違えば値は変わる。ライセンス文やスライサーの設定を判定させた実行（問いが2〜4つ）では、Nimble の1回の中央値は 2.6〜2.9 秒だった。造形中の画像を分類させた実行では、Clef-flash の1枚の中央値は 1,486 ms で、この計測の 689 ms とは開きがある。条件の違う別の実行で、どの違いが効いたのかは切り分けていない。

提供元が出している速さも、手元の目安にはならない。Ollama は Nimble が M5 Max の MacBook Pro で 100ms 未満で答えると書き、Cloudflare は自社のベンチマークで、応答時間の中央値を Clef-flash 38.8 ms、Jev 524.1 ms としている。どちらも提供元の測定で、機種も OS も問いも当サイトの計測とは違う。

ファイルの大きさと VRAM も別物である。Ollama のページは clef-flash の既定のタグを 11〜12GB と表示しているが、読み込んだときのモデルの分は 13,112 MiB だった。見積もりの考え方は手元のVRAMで動くモデルを見積もる — 量子化とメモリ計算の基礎（2026-08-25 公開）に、GPU を選ぶときの考え方はAIのために買うなら何から買うか — VRAMと電気代と騒音で決めるGPU選び（2026-08-29 公開）にまとめた。

小さい量子化に替える手もあるが、当サイトは試していない。Ollama の nimble には q4_K_M（5.6GB）のタグがある。clef-flash には Ollama に q4 のタグが無く、llama.cpp 向けには ggml-org が Q4_K_M（6.49 GB）を配布している。量子化を変えると確率の出方が変わりうる点にも注意したい。llama.cpp では、Clef（27B）の Q8_0 で確率が均等に寄ってしまい、BF16 では正しく出るという不具合が報告されていて、2026年10月7日時点で解決していない。Clef-flash で同じことが起きるという報告は無い。それでも、手元で動かして確率がどの選択肢にもほぼ均等に散るようなら、量子化を疑う価値はある。

Windows 版の Ollama では Clef-flash が動かなかった

当サイトの PC（Windows）に入れた Ollama 0.35.1 では、Clef-flash への /v1/systemone のリクエストが毎回 Clef: non-finite logit で失敗した。同じ症状は Ollama の GitHub に issue #18769 として報告されている。修正（PR #18777）は2026年10月7日に取り込まれたが、修正を含む版は同日時点でまだ公開されていない（最新版の 0.40.0 には入っていない）。一方、同じ Windows 版でも Nimble 9B は動いた。/v1/systemone の文書には、OS ごとの対応状況は書かれていない。Windows 版の要件として公式が挙げているのは、Windows 10 22H2 以降と、NVIDIA の GPU なら 551.61 以降のドライバーである。

回避には、Docker Desktop で Linux 版の Ollama 0.35.1 のコンテナを GPU を割り当てて起動し、Windows 側にダウンロード済みのモデルのフォルダをコンテナと共有した。同じ GPU のまま、Clef-flash は Linux 版で動いた。

この回避には代償が二つある。一つは初回の遅さだ。Windows のフォルダをコンテナから読ませる構成で、初回の呼び出しはモデルの読み込みを含めて 125.9 秒かかった。2回目からはモデルが常駐するので、この待ちは無い。もう一つは安定性で、計測を終えた後に Docker Desktop のプロセスが無くなり、コンテナに接続できなくなった。原因は確かめられていない。造形中の監視のように常に動かしておく用途では、コンテナが落ちたことに気づける仕組みも一緒に用意しておきたい。

当サイトが使ったのは 0.35.1 で、10月7日時点の Ollama の最新版は 0.40.0 である。修正の入った版が出ているかどうかは、使う前にリリースの説明で確かめてほしい。なお 0.40.0 では、Apple シリコンの Mac で MLX での実行が既定になり、判定モデルも MLX で動くようになった。Windows 版にも MLX（CUDA）の追加パッケージがあるが、Windows で判定モデルが MLX で動くかは公式文書に書かれておらず、当サイトも試していない。

llama.cpp で動かすときの注意

llama.cpp も、Ollama と同じ形の入口 /v1/systemone を持つ。ただし、対応は入ったばかりだ。入口そのものは2026年10月2日、Clef への文字での対応は10月3日、Clef の画像入力への対応は10月5日に取り込まれた。10月5日より前のビルドでは、Clef に画像を渡せない。当サイトは llama.cpp では試していない。

ggml-org が Clef-flash の GGUF を配布しており、大きさは Q4_K_M が 6.49 GB、Q8_0 が 9.66 GB、BF16 が 18.2 GB である（2026年10月7日時点で、このリポジトリに画像用の投影ファイルは置かれていない）。Hugging Face のページには、次の1行で取得から起動までを行う例が載っている。

llama serve -hf ggml-org/Clef-Flash-GGUF:Q4_K_M

使う前に知っておきたい点を並べる。

• ストリーミングには対応していない。画像は data URL でしか受け付けず、Ollama とは渡し方が逆になる
• Clef を動かしているサーバーは判定の入口しか出さず、文章を生成する入口は使えない
• Clef では入力全体を1回で評価するため、入力が --ubatch-size（既定 512）に収まる必要がある。収まらない長さの入力を渡すなら、-ub を入力のトークン数以上に上げる
• 説明書きは、返す確率が手元のデータに対して較正されている保証は無いと明記している
• Nimble の GGUF は v3（CC BY-NC 4.0、非商用）である。このため本記事では、llama.cpp で Nimble を動かす手順は扱わない

Jev の API と同じ書き方で手元に切り替える

5つの実行先のうち、OpenAI を除く4つは、Jev の API と同じ形で呼べる。Ollama は nimble のページで、入口が TypeSafe の Jev の API に従うと書いている。Cloudflare は、既存の Jev の組み込みを、接続先とモデル名を変えるだけで Clef に移せると説明している。llama.cpp の説明書きも、TypeSafe と互換の System One API だとしている。TypeSafe の Python の SDK は、接続先を Ollama に向けて使える。

ただし、confidence の計算式は提供元ごとに違う。TypeSafe は問いの型ごとに式を決めており（choice なら最も高い確率が均等な割り当てからどれだけ離れているか）、Ollama は確率の分布のエントロピーから計算する。実行先を変えたら、confidence を使うしきい値は測り直す。

例外は OpenAI である。Decisions API は、入力の名前、問いの並べ方（配列）、型の名前（はい・いいえの型を predicate と呼ぶ）が Jev と違う。Jev 向けに書いたコードを、そのまま OpenAI に向けることはできない。

切り替えの仕組みを最初に作っておくという考え方は、ローカルとクラウドの担当を決める — 用途で振り分けるAI環境構築の逆引きガイド（2026-08-30 公開）で書いたことと同じだ。ただし判定モデルでは、共通の形は OpenAI 互換の API ではなく、Jev の API の形のほうになる。Ollama の OpenAI 互換の API は2026年10月7日時点でログ確率に対応しておらず、判定モデルの確率は /v1/systemone で受け取る。

形が同じでも、中身まで同じではない。ここまでに見たとおり、上限、長い入力の切り詰め、画像の渡し方、トークンの数え方は実行先ごとに違う。文字だけの判定なら、各社の説明どおり接続先とモデル名の変更で移せる。画像を渡す判定では、実行先ごとに画像の包み方を書き分ける必要がある。

手元で判定モデルを回すなら、まずローカルで言語モデルを動かす流れに慣れておくとよい。ノート PC から始める実践入門を挙げておく。

ローカルLLM実践入門　ノートPCで始める自前生成AIアプリ開発（技術の泉シリーズ）

¥2,200 （2026/09/22 09:05時点 | Amazon調べ）

Amazon

楽天市場

ポチップ

工程ごとの逆引き — ファイル・設定・状態・画像・止める判断

ここまでの比較を、3Dプリントの工程に当てはめる。表の「第一候補」は、選ぶ順序（入力の種類、データの扱い、費用、手元の GPU）に沿って当サイトが選んだもので、どれも自分の正解付きの例で確かめてから使う前提である。

ファイルのライセンス

配布サイトのライセンス名と条文は公開された文字のデータで、外に出して困ることは少ない。条文の多くは英語なので、英語が主の Jev とも組み合わせやすい。Jev なら 1,000 件の判定で約 10.8 円という試算なので、費用で迷うことも無い。手元に GPU があれば、Nimble 9B でも同じ問いを回せる。

配布されている3Dモデルのライセンスを AI に判定させる — 商用利用・改変・再配布を確率で仕分ける（2026-10-13 公開）では、Nimble 9B（Ollama 配布版）に4つの問い（印刷物を売ってよいか、改変版を公開してよいか、同じライセンスを付ける義務があるか、作者表示が要るか）を判定させた。条文を添えると、採点した 46 問中 43 問が正解し、Brier スコアは 0.055（0〜1 の尺度）だった。

一方で、作者が説明文で条件を書き足した7例のうち、正解が割れるはずの4例でも、Nimble の確率は 0.006・0.005・0.097・0.968 と端に寄り、中間の値を出さなかった。確率が中ほどに落ちたものだけを人に回す設計は、この実行の Nimble では働かなかったことになる。同じ4例で claude -p は 0.62〜0.85 を返した。

ライセンスの判定は法的な助言ではない。判定モデルの役割は、大量のファイルの中から人が条文を読むべきものを絞り込むところまでで、最終的には条文を読み、必要なら作者に確かめる。ライセンスの読み方そのものはそのモデルを売っていいのか — 著作権・意匠権・商標とライセンスの読み方（2026-08-20 公開）で扱った。

スライサーの設定

設定値は文字（JSON）で渡せる。自分の設定なら外に出しても困らないことが多いが、取引先から預かった設計に結びつく設定なら手元に置く。回数は造形の数だけなので、費用はここでも小さい。公式プロファイルから正解を作って判定させた結果は、スライサー設定の取り違えを AI に見つけさせる — 素材・温度・プレートの組み合わせを公式プロファイルで試す（2026-10-14 公開）にまとめてある。

まず、規則で書ける確認は規則に回す。Bambu Studio は、選んだプレートのベッド温度が 0（その素材はそのプレートに非対応）ならスライスを止め、ノズル温度は、フィラメント設定で推奨範囲の外の値に書き換えたときに警告を出す（スライスは止まらず、スライス時と送信時には確かめない）。範囲に入っているかどうかのような数値の比較は、判定モデルに聞かなくても、スライサーやコードで確かめられる。

それでも判定モデルを使うなら、推奨値を一緒に渡すことが効いた。当サイトが Bambu Studio の公式プロファイルから正解を作った 42 組の設定を Nimble 9B に判定させたところ、推奨値を添えた JSON では「どこが問題か」（choice）が 42 組中 38 組で当たった。推奨値を渡さない日本語の依頼文では 17 組に落ち、confidence の平均は 0.066 まで下がった。さらに、推奨値を添えた日本語の依頼文では、ノズル温度の誤りを含む 18 組すべてで choice は正しく「ノズル温度」を選んだのに、「刷ってよいか」（noul）は 18 組とも「はい」の側に誤った。同じ状態に対して、問いの立て方で答えが逆を向いたのである。

プリンターの状態

温度・目標温度・進捗・エラーをまとめた JSON は、文字のデータとしてどの実行先にも渡せる。この工程の特徴は回数の多さにある。1分おきに問い合わせれば、1,000 回は約 16.7 時間で来る。Jev の試算では、3回分の状態を渡す判定で 1,000 回あたり 0.0791 ドル（約 12.5 円）なので、費用はやはり小さい。速度の上限も、Jev の毎秒 80 リクエストや、Workers AI の区分の既定値の毎分 300 リクエストに、プリンター1台で届くことはない。

効いてくるのは、通信が切れたときに判定も止まることと、状態が外に出ることだ。造形中ずっと動かす判定は、手元で常駐させるほうが扱いやすい。当サイトの計測では、Nimble 9B のモデルの分は 8,953 MiB で、文字1回の中央値は 2,197 ms だった。1分おきの判定なら十分に間に合う。状態の JSON の組み立て方と判定の例は、造形中のプリンターの状態を AI に読ませる — 温度・進捗・エラーの JSON から止めるかを判定する（2026-10-15 公開）で示した。

当サイトは、Klipper の API サーバー Moonraker の文書にあるフィールド名で例の JSON を作り、Nimble 9B と claude -p に「続ける・知らせる・止める・判定できない」を選ばせた。これは計測ではなく例示で、6つの例に置いた想定も当サイトが決めたもので、正解ではない。進捗の項目を消した例では、2つとも「続ける」と答えた。ほかの項目（使ったフィラメントの量や経過時間）は増え続けていたので、この答え自体は不自然ではない。だからこそ、欠けた項目の検出は判定モデルに任せず、送る前に規則で検査する設計にする。

判定モデルは、プリンター自体の安全機能の代わりではない。熱暴走の保護のような仕組みはプリンターの側で働くもので、判定の答えでそれを置き換えることはできない。判定の結果で自動的に造形を止める構成にはせず、人に知らせるか、人の確認を挟む形にとどめる。

造形中の画像

Jev は画像を読めないので、この工程では候補から外れる。手元なら Clef-flash、API なら Workers AI の clef-flash か OpenAI の Decisions API になる。

カメラの写真には作業場そのものが写る。外に出したくないなら手元の Clef-flash で、当サイトの 16GB のカードではモデルの分が 13,112 MiB、画像1枚の中央値が 689 ms（Docker 上の Linux 版）だった。Windows 版の Ollama で動かなかった点は先に書いたとおりだ。API に送ってよいなら、Workers AI は1枚 4 MiB までなので、大きな写真は縮小してから送る。OpenAI はベータで、料金や仕様が変わりうる。費用はどちらも 1,000 枚あたり 0.085〜0.095 ドルの試算だった。

精度については、3Dプリントの不良を写した公開データの写真を手元のモデルに分類させる — Jev が読めない画像を Clef-flash で補う（2026-10-16 公開）で、公開データセットの不良写真 50 枚を5種類に分類させた。正答は Clef-flash が 25 枚、claude -p が 41 枚だった。Clef-flash は確率の最大値が 0.8 以上の答え 21 件に平均 0.929 の確率を付けたが、当たったのは 10 件で、確率が実際に当たる割合を大きく上回っていた。多クラスの Brier スコアは 0.751（0〜2 の尺度）で、5種類に 0.2 ずつ置く答え方の 0.8 からの改善は小さかった。確率が当たっているかは、Brier の値だけでなく、確率の区切りごとに確率の平均と当たった割合を並べて確かめる。手元で動くことと、確率をそのまま使えることは別の話である。

止めるかどうかの判断

この工程は、実行先を選ぶ問題ではない。判定モデルが返すのは確率までで、どこで止めるかはコードの側で決める。3Dプリントの監視のしきい値を材料費で決める — 確率のどこで止め、どこを人に回すか（2026-10-17 公開）では、誤って止めた損失と見逃した損失からしきい値を計算した。

実行先の選び方に関わるのは二点だけだ。一つは、しきい値の式は確率が当たっていることを前提にしているので、どの実行先を選んでも、自分の正解付きの例で確率を確かめてから使うこと。もう一つは、判定1回ごとの API の料金を期待損失に足せることである。ただし、ここまで見たとおり判定モデルの API の料金は 1,000 回で約 30 円までの試算なので、材料費の損失と比べれば小さい。

当サイトの実行から言えること — 確率は当たり具合を確かめてから使う

当サイトは2026年10月7日に、ライセンス文、スライサーの設定、プリンターの状態、造形中の画像の4種類の判定を、手元の判定モデルと claude -p で各条件1回ずつ実行した。Jev はこの実行に含まれていない。件数は少なく、結果を一般化はできないが、実行先を選ぶ前に知っておきたいことがいくつか見えた。

• 迷うべき問いでも、端の確率を返すことがある。作者が条件を書き足したライセンスの例で、Nimble 9B は正解が割れる4例に 0.005〜0.097 と 0.968 という端の確率を返した。claude -p は同じ4例で 0.62〜0.85 だった
• 渡す材料で結果が大きく変わる。スライサーの設定で推奨値を渡さないと、Nimble 9B の choice の正答は 42 組中 17 組に落ちた。confidence は確率の分布の集中度を表す値で、正しさの確率ではない
• 問いの立て方で、同じ状態への答えが逆を向く。noul と choice が食い違う場面があった。noul の文面は1通りしか試していない
• 確率の高さが当たりの目安にならないことがある。造形中の画像で、Clef-flash は確率の最大値が 0.8 以上の答えの半分ほどしか当たらなかった
• 一般のモデルは、この実行では当たりが多かったが、費用と時間がかかった。claude -p は条文を添えたライセンスの判定で、採点した 46 問すべてに正解し、画像では 50 枚中 41 枚を当てた。ただし費用は 1,000 回あたり 21〜25 ドルで、1回の中央値は約 4.7〜6.7 秒だった。また、その確率はモデルが文章として書いた数値で、判定モデルのように全選択肢の確率を一度の計算で出したものではない

ここから言えるのは、API を選ぶか手元を選ぶかより前に、確率の当たり具合を確かめる手順が要るということだ。TypeSafe は Jev の確率が較正されていると説明しているが、それは提供元の主張であり、自分の問いとデータで当たっているかは別に確かめる必要がある。llama.cpp は返す確率が手元のデータで較正されている保証は無いと書き、Ollama は confidence を正しさの較正ではないと書いている。

確かめ方は、実行先によらず同じである。

1. 結果の分かっている例を集め、運用と同じ問いの文面で判定させる
2. 返ってきた確率をすべて記録する
3. Brier スコアを、尺度（二値は 0〜1、多クラスは 0〜2）を添えて、何も分からない場合の基準の値と比べる
4. 確率の高さで区切り、区切りごとの実際の正答の割合を見る

Jev を含めて4つの実行先が同じ形で呼べることは、ここで役に立つ。文字だけの例を、どの実行先の上限にも収まる長さでそろえておけば、接続先とモデル名だけ変えて手元の Nimble 9B や Clef-flash、Workers AI、Jev に流し、どれの確率が自分の工程で当たるかを同じ物差しで比べられる。画像を含む例は Jev と Nimble 9B には渡せず、ほかの実行先でも画像の包み方を書き分ける必要がある。confidence を使うしきい値も、実行先ごとに確かめ直す。判定モデルの API の費用は 1,000 回で約 30 円までの試算なので、比べる作業そのものにはほとんどお金がかからない。

確率を自分の正解付きの例で確かめる手順は、生成 AI のアプリを評価で改善していく考え方と重なる。評価の組み立て方をまとめた一冊を挙げておく。

LLMアプリケーション評価駆動開発 継続的に改善し運用していくための実践知

¥3,960 （2026/09/22 14:35時点 | Amazon調べ）

Amazon

楽天市場

ポチップ

まとめ — Jev の API か手元かは、入力の種類とデータの扱いで先に絞る

• 判定モデルの実行先は、API の Jev・OpenAI の Decisions API（gpt-6-luna、ベータ）・Workers AI の clef-flash と、手元の Ollama・llama.cpp の5つ。比べる順序は、入力の種類、データの扱い、費用、手元の GPU
• Jev は文字しか読めない。画像を渡す工程では、手元の Clef-flash か、Workers AI・OpenAI の API になる
• 学習に使わないのは API の3社に共通で、違いは保存と所在地にある。外に出せないデータは手元に置く
• 1,000 回あたりの費用は、判定モデルの API なら約5〜30 円という試算で、トークン数は手元のモデルで数えた桁の目安にすぎない。claude -p の実測は 21〜25 ドルで、Claude Code を経由した実行の費用である
• 当サイトの RTX 5070 Ti（16GB）では、Clef-flash のモデルの分が 13,112 MiB、Nimble 9B が 8,953 MiB で、同時には載らない。時間は実行環境が違うので並べない
• Windows 版の Ollama 0.35.1 では Clef-flash が動かず（issue #18769）、Docker の Linux 版で回避した
• Nimble は版でライセンスが違う。Ollama 配布版は Apache 2.0、v3 は非商用
• どの実行先でも、確率は自分の正解付きの例で Brier スコアを見てから、しきい値に使う。判定モデルはプリンターの安全機能の代わりではない

実行先の選択は、一度決めたら終わりというものでもない。OpenAI の Decisions API はベータで、llama.cpp の対応は入ったばかりで、Windows 版の Ollama の不具合も、修正は10月7日に取り込まれたが、修正を含む版は同日時点でまだ公開されていなかった。Jev の API と同じ形で書いておけば、文字だけの判定なら、実行先を変えるのは接続先とモデル名の書き換えで済む（画像の渡し方と confidence のしきい値は、実行先ごとに確かめ直す）。まずは自分の工程の判定を一つ選び、正解付きの例をそろえて、手元のモデルで確率の当たり具合を測るところから始めたい。

参照

• TypeSafe Docs「Models」
• TypeSafe Docs「API reference」
• TypeSafe Docs「Quick start」
• TypeSafe Docs「Legal」
• TypeSafe Privacy Policy
• TypeSafe Data Processing Agreement
• TypeSafe Master Customer Agreement
• TypeSafe 公式ブログ「Introducing System One Models & Jev」
• Vercel Changelog（Jev on AI Gateway）
• OpenAI API Docs「Decisions」
• OpenAI API Changelog
• OpenAI API Docs「Data controls」
• Cloudflare Blog「Introducing Clef: our open-source decision models, and new RL fine-tuning platform」
• Cloudflare Changelog（Clef on Workers AI、2026-10-01）
• Workers AI「clef-flash」
• Workers AI「Pricing」
• Workers「Pricing」
• Workers AI「Data usage」
• Workers AI「Limits」
• Hugging Face「Cloudflare/clef-flash」
• Hugging Face「ggml-org/Clef-Flash-GGUF」
• Hugging Face「bespokelabs/Bespoke-Nimble-9B」
• Hugging Face「bespokelabs/Bespoke-Nimble-9B-v2」
• Hugging Face「bespokelabs/Bespoke-Nimble-9B-v3」
• Hugging Face「ggml-org/Bespoke-Nimble-9B-v3-GGUF」
• Ollama Blog「Ollama now supports Jev-style decision models」
• Ollama Docs「System One」
• Ollama Docs「Decision」
• Ollama Docs「FAQ」
• Ollama Docs「Windows」
• Ollama Docs「OpenAI compatibility」
• Ollama ライブラリ「nimble」
• Ollama ライブラリ「nimble」のタグ一覧
• Ollama ライブラリ「clef-flash」
• Ollama ライブラリ「clef-flash」のタグ一覧
• Ollama v0.40.0 リリース
• Ollama の LICENSE
• ollama/ollama issue #18769
• ollama/ollama PR #18777（Windows 版の Clef の修正）
• llama.cpp server README
• llama.cpp PR #29818（/v1/systemone の追加）
• llama.cpp PR #29831（Clef への対応、文字のみ）
• llama.cpp PR #29969（Clef の画像入力）
• llama.cpp issue #30064（Clef の Q8_0 で確率が均等に寄る）
• llama.cpp の LICENSE
• Bambu Studio（GitHub、bambulab/BambuStudio）
• Moonraker Docs「Printer Administration」
• 七十七銀行 米ドル対円相場（仲値）一覧表 2026年

ブラウザだけでできる本格的なAI画像生成【ConoHa AI Canvas】

swiftwand

X

AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.