3Dプリントの不良を写した公開データの写真を手元のモデルに分類させる — Jev が読めない画像を Clef-flash で補う

長い造形を夜に流し、朝に見に行くとプレートの上に糸の塊が残っている。途中で失敗に気づければ材料も時間も無駄にせずに済むので、プリンターにカメラを向けている人は多い。ところが、撮った写真で3Dプリントの不良の分類をする仕組みは、これまで不良の写真を集めて学習させた検出器が中心だった。自分のプリンターで撮った不良の写真を何百枚も持っている個人は多くない。

2026 年 9 月から 10 月にかけて、文章を書かずに、型を決めた問いへの答えと確率だけを返すモデルが各社から相次いで出た。TypeSafe の Jev は文字しか読めないが、Cloudflare が公開した Clef-flash は画像を読める。しかも重みが Apache 2.0 で配布されていて、手元の GPU で動く。学習はさせず、不良の種類と説明を問いとして書くだけで、写真を分類させられる。

本記事では、造形中にプリンターの上で撮られた公開データセットの不良写真 50 枚を、手元の Clef-flash と、比べる相手としての claude -p（Claude Sonnet 5.5）に5種類で分類させ、3Dプリントの不良の分類がどこまで当たるかを数えた。先に結論を書くと、正答は Clef-flash が 50 枚中 25 枚、claude -p が 41 枚だった。正答率以上に差が出たのは確率の当たり具合である。Clef-flash は確率の最大値が 0.8 以上だった 21 件のうち正解が 10 件にとどまり、この実行では確率の高さが当たりの目安にならなかった。一方の claude -p は、同じ条件の 18 件中 16 件が正解だった。Windows 版の Ollama では Clef-flash が動かず、Docker の Linux 版で回避した経緯も書いておく。

造形中の不良を写真で見つける方法は、学習させるものが中心だった

造形の失敗をカメラで見張る仕組みは、プリンターに内蔵されたものも後付けのツールもすでにある。両者の違いは AI 失敗検知 2026 — 内蔵カメラと後付けツール、どちらが「印刷の見張り」に向くか（2026-07-03 公開） で比べた。画像で不良を見つける方法として長く使われてきたのは、不良の写真を集めて検出器を学習させるやり方だ。

本記事で使うデータセットの元になった研究も、その方法をとっている。杭州電子科技大学の Hu WenJing らは、FFF 方式（FDM とも呼ばれる熱溶解積層）の 3D プリンターで造形中に起きる不良をその場で見つけて知らせる仕組みを、2024 年に The International Journal of Advanced Manufacturing Technology で発表した。不良を意図的に作って写真を集め、YOLOv8 の検出ヘッドを軽くしたモデルを学習させている。論文の抄録によれば、改良したモデルの mAP50 は 97.5% に達し、FPS は 18.1% 増え、計算量（GFLOPs）は 32.9% 減った。

ただし、この 97.5% は物体検出の指標（mAP50）で、このデータのために学習させたモデルについて論文が報告した値である。後で示す本記事の正答率は、学習させていないモデルに5種類から1つを選ばせた割合で、指標も条件も違う。二つの数字を並べて、どちらが優れているかを言うことはできない。

学習させる方法には、手間が使う側に残るという問題がある。自分のプリンターとカメラの角度で不良の写真を集め、一枚ずつラベルを付け、学習させて評価し直す必要がある。YOLO と Raspberry Pi 5 で検査の仕組みを組む例は AI外観検査 3Dプリントで「目視」を卒業する。印刷後品質管理の自動化（2026-03-01 公開） で扱った。学習させれば精度を詰められる反面、不良がめったに起きないプリンターほど、学習用の写真は集まらない。

学習なしで問いを書くだけの判定モデル — Jev と Clef-flash

本記事でいう判定モデル（decision model）とは、文章を書かずに、あらかじめ型を決めた問いに、答えと確率だけを返すモデルのことだ。使う側は、判定させたい状態（写真や文字）と、問いと選択肢の説明を渡す。今回なら「この写真の不良は次の5種類のどれか」という問いと、各種類の説明を英語で書いた。返ってくるのは5つの確率で、学習用の写真は1枚も要らない。問いを書き換えれば、同じモデルが別の分類器になる。

TypeSafe の Jev もこの種のモデルの一つだが、文字しか受け付けない。公式のドキュメントは入力について「No image, audio, or video input.」と書き、画像などは先に文字や構造化したフィールドに直してから送るよう求めている。造形中のカメラ画像を Jev に判定させるには、別の仕組みで写真を文章に直す工程が要る。Cloudflare も Clef の発表で、Jev が現時点で文字の分類しかしない点を自社のモデルとの違いに挙げている。

そこで本記事では、画像を直接読める判定モデルとして、Cloudflare の Clef-flash を使った。2026 年 10 月 1 日に発表された 9B（約 90 億パラメーター）のモデルで、Qwen3.5-9B から微調整されている。重みは Apache 2.0 で Hugging Face に公開され、Ollama なら 0.35.1 以降で画像を渡せる。上位版として 27B の Clef もあるが、本記事では Clef-flash だけを使った。

Cloudflare の説明では、Clef は Jev と同じ API の形に従っていて、接続先とモデル名を変えれば Jev 向けの組み込みを移せる。ただし、confidence の計算式は提供元ごとに違う。TypeSafe は問いの型ごとに式を決めており（choice なら最も高い確率が均等な割り当てからどれだけ離れているか）、Ollama は確率の分布のエントロピーから計算する。実行先を変えたら、confidence を使うしきい値は測り直す。

手元で動かす利点は、カメラの画像を外部のサービスに送らずに済むことにある。なお、画像を読める判定モデルは Clef-flash だけではない。ここでは、手元で動かせて重みのライセンスが明確なものとして選んだ。

提供元が出している数字には注意が要る。Cloudflare は自社の評価での Clef-flash の応答時間の中央値を 38.8 ms と公表しているが、これは提供元の測定で、どの環境で測ったかは発表に書かれておらず、本記事の手元の実測とは条件が違う。また、Hugging Face のモデルカードにある評価表を見ても、画像の分類と明記された項目は見当たらなかった。3Dプリントの不良写真で当たるかどうかは、自分で確かめるしかない。

confidence は「正しい確率」ではない

Ollama 経由で Clef-flash を呼ぶと、確率と一緒に confidence という値が返る。名前から「この答えが正しい確率」と読みたくなるが、そうではない。Ollama のドキュメントは、これを確率の分布がどれだけ一つの選択肢に集中しているかを表す値と定義している。式は 1 − H(p)/ln(N) で、H(p) は確率のエントロピー、N は選択肢の数だ。すべての確率を一つの選択肢に置けば 1、均等に散らせば 0 になる。ドキュメント自身が「Not calibrated correctness.」と断っており、値が高くても答えが正しいとは限らない。

確率が当たり具合と合っているかは、正解が分かっている写真で確かめるしかない。本記事では、その確かめ方として、正答率に加えて多クラスの Brier スコアと、確率の最大値が 0.8 以上と 0.8 未満の答えそれぞれの正答を数えた。

3Dプリントの不良の分類を試した条件 — 公開データセットから 50 枚

写真は造形中にプリンターの上で撮られたもの

写真は、Hu らが公開した FDM 3D Printing Defect Dataset から選んだ。ライセンスは MIT で、作者は 2024 年 10 月に Kaggle で公開している。今回は、Hugging Face のベンチマーク（ppak10/Additive-Manufacturing-Benchmark。カードの説明では Carnegie Mellon University の大学院の授業から作られたもの）に 2026 年 3 月に同梱された版を、ログインせずに取得して使った。写真はすべてデータセットの作者らが不良を意図的に作って撮ったもので、当サイトがプリンターで印刷したり撮影したりしたものではない。記事には転載せず、配布元へのリンクだけを張る。各節の画像は内容を表したイラストで、実測に使った写真ではない。

全体は 1,912 枚で、不良は次の5種類に分かれている。本文では、配布元のクラス名に括弧で和名を添えて書く。

Kaggle の説明文は Cracking を 427 枚と書いているが、それでは合計が 1,912 枚にならない。Hugging Face の版のファイル数を当サイトが数えたところ 472 枚で、合計も 1,912 枚になったため、472 枚が正しいとみられる。

撮影の時点は、記事の題名にかかわるので確かめた。論文の抄録は造形中の不良をその場で検出する研究だと書き、Hugging Face のカードも、造形中に不良を意図的に起こして写真を集めたと説明している。当サイトが各クラスから1枚ずつと、左右反転で水増しした画像とその元画像の1組（2枚）の計7枚を見たところ、7枚ともノズルと冷却ファンのカバーが造形物の真上にあり、造形物はプレートに載ったまま横から撮られていた。取り外した完成品の写真ではなく、プリンターの上で造形中（または造形の直後）に撮られた写真として扱う。

論文の本文は購読制で読めておらず、撮影に使ったプリンターやカメラ、撮影の条件は確認できていない。当サイトが確かめた 10 枚の解像度は、すべて 3072×2048 だった。

抽出のしかたと問い

各クラスから 10 枚ずつを乱数のシード 20261012 で選び、計 50 枚にした。どのクラスも同じ枚数なので、5種類から当てずっぽうに1つを選べば、当たるのは平均して5枚に1枚になる。結果を読むときは、この割合を比べる基準にする。

写真は長辺 1024px に縮小し、両方のモデルに同じ画像を1枚ずつ渡した。縮小をそろえたのは、Claude（4.7 以降のモデル）が長辺 2576px か、画像を 28×28 画素の区画で数えた視覚トークン 4,784 のどちらかを超える画像を自動で縮小する一方、Ollama の Clef-flash が内部で縮小するかどうかは文書に書かれていないためだ。モデルには画像だけを渡し、ファイル名やフォルダ名は渡していない。もっとも、データセットのファイル名にはもともとクラス名が入っておらず、クラスはフォルダ名で分けられている。

データセットには、元の写真を加工して水増しした画像（ファイル名の末尾が _aug）が 81 枚含まれている。抽出の際にこれを除いていなかったため、50 枚のうち 2 枚（層ずれと糸引きの各1枚）が水増し画像だった。元の画像と並べると、糸引きの1枚は左右反転、層ずれの1枚は向きを変えずに明るさを上げたものだった。元の画像は抽出に入っておらず、同じ写真が二重に入ったわけではない。それでも念のため、結果には 2 枚を除いた 48 枚の集計も併記する。

Clef-flash には、Ollama の /v1/systemone に choice（選択肢から1つを選ぶ型）の問いを1つ渡した。5種類の名前と英語の説明は次のとおりで、送った JSON の形をそのまま示す（画像の中身は省略）。

{
  "model": "clef-flash",
  "state": "A photo of an FDM 3D print taken at the printer.",
  "questions": {
    "defect": {
      "type": "choice",
      "instructions": "This photo shows an FDM 3D print with exactly one kind of defect. Which defect does it show?",
      "criteria": {
        "Cracking": "Cracks or splits between layers of the printed part",
        "Layer_shifting": "Layers are offset sideways from the layers below, partway up the part",
        "Off_platform": "The part has come loose from the build plate or moved on it",
        "Stringing": "Thin strands or wisps of plastic stretched across or between parts of the print",
        "Warping": "Corners or edges have lifted or curled up away from the build plate"
      }
    }
  },
  "images": ["（JPEG を base64 にした文字列）"]
}

claude -p には、同じ問いと同じ説明を文章で渡し（state の1文は渡していない。システムプロンプトは「You are a careful assistant.」の1文）、選んだ種類と5種類それぞれの確率を JSON で答えさせた。確率は「正直な見積もりで、合計が1になるように」と指示し、合計が1にならない回答は合計で割ってそろえてから採点した。Claude Code のツール・MCP・設定ファイルを読み込まない最小構成で動かし、モデルは --model sonnet で指定した（記録上のモデル ID は claude-sonnet-5-5）。

公開データセットの写真を AI に見せ、当たるものと外れるものを数えるという組み方は、葉の写真で植物の状態を AI に診断させる — 当たる症状と外れる症状を 33 枚で数えた（2026-10-06 公開） と同じだ。違いは、今回は答えを文章ではなく確率で受け取り、確率の当たり具合まで数えた点にある。

結果 — 正答は Clef-flash が 25 枚、claude -p が 41 枚

実行は 2026 年 10 月 7 日に、各条件1回だけ行った。48 枚の行は、水増し画像の2枚を除いた集計である。正答は、各モデルが選んだ種類（choice）で数えた。claude -p には、選んだ種類と確率がいちばん高い種類が食い違う回答が 4 件あった（後述）。

正答率は Clef-flash が 50%、claude -p が 82% だった。当てずっぽうなら5枚に1枚しか当たらないので、学習させていない Clef-flash も偶然よりは多く当てている。それでも半分は外した。水増し画像の2枚を除いても、どちらの正答率もほとんど変わらなかった。

Brier スコアの読み方

多クラスの Brier スコアは、1枚ごとに「5種類それぞれの確率と、正解なら1・不正解なら0の値との差の2乗」を足し、全体で平均したものだ。正解に確率1を置いて当て続ければ 0、外れた種類に確率1を置き続ければ 2 になり、0 に近いほどよい。scikit-learn の brier_score_loss も、多クラスでは 0〜2 の尺度のまま返す。二値の場合だけ半分にして 0〜1 にするので、他の記事の値と比べるときは尺度を確かめたい。

基準として覚えておきたいのは、5種類すべてに 0.2 ずつ確率を置いた場合の値だ。(1−0.2)² ＋ 4×0.2² ＝ 0.64 ＋ 0.16 ＝ 0.8 になる。各クラスの枚数が同じ今回のデータでは、0.8 が「何も分からない」と答え続けた場合の値にあたる。

Clef-flash の 0.751 は、この 0.8 とほとんど変わらない。正答率は 50% あったものの、確率の付け方で見ると、何も分からないと答えた場合と大差がなかった。これに対して claude -p の 0.379 は、正解の種類に比較的高い確率を置けていたことを示している。

ただし、Brier スコアは、確率と実際に当たる割合が合っているか（較正という）だけを測る値ではない。当たる写真に高い確率、外れる写真に低い確率を付け分けられているか（識別という）も、同じ一つの値に混ざる。scikit-learn の解説も、Brier スコアは較正と識別の力などを同時に評価するため、較正だけを見るには限界があると注意している。たとえば、各種類が同じ枚数の今回のデータで全種類に 0.2 ずつ置き続けると、Brier は 0.8 になる。それでも、0.2 と付けた種類が実際に正解だった割合は 5 回に 1 回で、確率と当たる割合は合っている。この答え方に足りないのは較正ではなく、写真ごとに確率を変える識別の力だ。0.8 に近いことから言えるのは、全種類に 0.2 ずつ置いた場合からの改善が小さいことまでで、確率がどう外れているかは、確率の高さで区切って実際の正答の割合と比べて確かめる（後述）。

時間と費用は条件が違う

時間は、そのまま比べられない。Clef-flash は手元の GPU で1枚あたりの中央値が 1,486 ms だった。claude -p はネットワーク越しに API を呼び、CLI の起動も含めて 6,156 ms かかった。片方は手元の GPU、片方は外部の API なので、この差はモデルそのものの速さの比較ではない。

費用は、claude -p が返した記録の合計で 50 枚あたり 1.213 ドルだった。Clef-flash は手元で動かしたので API の費用はかからない（電気代は含めていない）。

当たった不良と外れた不良 — Clef-flash の答えの半分以上が糸引きだった

正解のクラスごとに、正答の数と主な取り違えを並べる。

いちばん目立つのは、Clef-flash の答えが糸引きに寄ったことだ。50 枚のうち 27 枚を糸引きと答えている。糸引きの写真 10 枚を全問正解したのは、この偏りの裏返しでもある。糸引きと答える回数が多ければ、本物の糸引きは取りこぼしにくい。その代わり、剥がれの写真は 10 枚すべてを糸引きと答え、層ずれの写真も 10 枚中 6 枚を糸引きとした。一つの種類の正答だけを見て「この不良には強い」と判断すると、読み違える。

反りの写真では、Clef-flash は 10 枚中 4 枚を層ずれと答えた。割れの写真でも 3 枚を層ずれとしている。反りと割れは、claude -p がそれぞれ 8 枚と 10 枚を当てた種類で、Clef-flash との差が大きく開いた。

claude -p の取り違えも、向きは Clef-flash と似ていた。剥がれの 5 枚と層ずれの 2 枚を糸引きと答え、残りは反りの写真を割れとした 2 枚だった。二つのモデルがそろって剥がれを糸引きと取り違えたことになる。

しかも、claude -p が剥がれと答えて正解した 5 枚のうち 4 枚では、同じ回答に書いた確率のほうは糸引きがいちばん高かった（糸引き 0.6〜0.75、剥がれ 0.2〜0.3）。確率がいちばん高い種類で数え直すと、claude -p の正答は 41 枚から 37 枚（74%）に、剥がれの正答は 10 枚中 1 枚に減る。Clef-flash では、選んだ種類と確率がいちばん高い種類は 50 枚すべてで一致していた。

その理由の候補として、写真の写り方がある。当サイトが目視した剥がれの1枚では、ノズルの下で糸状のフィラメントが絡まっていた。造形物が外れた後も、ノズルは樹脂を出し続ける。写真の中では、外れた造形物よりも絡まった樹脂の糸のほうが目に付くことがある。今回の糸引きの説明（Thin strands or wisps of plastic stretched across or between parts of the print）は、そうした写真にも当てはまってしまう。確かめたのは1枚だけなので断定はできないが、問いの説明文に「外れた造形物の周りにフィラメントが絡まる」といった特徴を書き足すと、取り違えが減る可能性はある。これは試していない。

確率の読み方 — 0.8 以上の答えはどこまで当てになったか

3Dプリントの不良の分類を見張りに使うなら、正答率と同じくらい大事なのは、確率が高い答えだけを拾えば当たるのかどうかだ。確率を通知や停止のしきい値に使うには、確率が高いときほど当たっていなければならない。

今回は、5つの確率の最大値が 0.8 以上だった答えを数えた。Clef-flash は 21 件で、正解は 10 件だった。さらに、正解したときと外したときの確率の最大値を平均すると 0.654 と 0.641 で、ほとんど同じだった。この実行では、Clef-flash の確率が高いからといって当たっているとは言えず、確率で当たりと外れを分けることができなかった。

claude -p は確率の最大値が 0.8 以上の答えが 18 件で、16 件が正解だった。水増し画像を除いた 48 枚でも 16 件中 14 件が正解で、高い確率を付けた答えはおおむね当たっていた。ただし、claude -p の確率は、モデルが文章として書いた数値である。判定モデルのように、1回の計算で全選択肢の確率を出す仕組みから取り出したものではない。今回の 50 枚では当たり具合の目安になったが、別の写真や問いでも同じになるとは言えない。

確率と実際に当たる割合が合っているかは、付けた確率の平均と実際の正答の割合を、確率の高さの区切りごとに並べると見える。1枚ごとに5つの確率の最大値を取り、0.8 未満と 0.8 以上に分けた。区切りごとに、確率の最大値の平均（最大値の合計 ÷ 件数）と、正答の割合（確率がいちばん高い種類が正解だった件数 ÷ 件数）を出した。確率が当たっていれば、二つの値は近くなる。

Clef-flash は、0.8 以上の答えに平均 0.929 の確率を付けたが、当たったのは半分に届かず、確率が実際の当たる割合を大きく上回っていた。0.8 未満の答えと比べても、正答の割合は高くなっていない。claude -p は、0.8 以上で確率の平均 0.896 に対して正答が 89%、0.8 未満で 0.626 に対して 66% と、どちらも近かった。0.8 未満の 32 件には、選んだ種類と確率がいちばん高い種類が食い違う 4 件が入っており、選んだ種類で数えると正答は 25 件になる。件数は区切りあたり 18〜32 件で、これより細かく区切ると1つあたりの件数が少なすぎて読めない。

3Dプリントの不良の分類を自分のプリンターで確かめる手順

確率をしきい値に使う前に、次の順で確かめておくとよい。

1. 正解が分かっている写真を用意する。自分のプリンターとカメラで、不良の種類が分かっている写真と、不良の無い写真を集める。今回のデータセットには不良の無い写真が入っていないので、正常な造形を不良と判定してしまう割合は測れていない
2. 問いに「不良なし」の選択肢を入れる。今回の問いは「不良が必ず1種類写っている」前提で書いたが、見張りに使う写真の大半は正常な造形のはずだ
3. 正答率と一緒に、種類ごとの答えの数を数える。Clef-flash の糸引きのように、一つの種類に答えが偏っていないかを見る
4. 確率の最大値で区切って正答を数える。0.8 以上とそれ未満のように分け、区切りごとに確率の平均と実際の正答の割合が近いか、確率の高いほうが当たっているかを見る
5. Brier スコアを基準の値と比べる。各種類の枚数が同じ5種類なら 0.8 が「何も分からない」場合（全種類に 0.2 ずつ置いた場合）の値で、そこに近ければ、その答え方からの改善が小さい。Brier には較正と識別の力が混ざっているので、確率そのものが当たっているかは 4 の区切りで確かめる
6. 確かめた範囲でだけ、確率をしきい値に使う。確率の高い答えが当たると確かめられた場合だけ自動で知らせ、それ以外は人が写真を見る

止める操作につなげる場合も、判定モデルはプリンター自体の安全機能の代わりにはならない。熱暴走の保護などはプリンター側の仕組みが担う。画像の判定は、人に知らせるための補助として置くのがよい。

文字で渡せる情報（温度や進捗）は Jev のような文字の判定モデルに、カメラの画像は手元の Clef-flash に、と分けて判定させる組み方もできる。Clef が Jev と同じ API の形に従うので、問いの書き方と応答の受け取り方をそろえられる。

手元で Clef-flash を動かす — Ollama の /v1/systemone に画像を渡す

リクエストの要点

Clef-flash は Ollama のライブラリから取得できる。ただし判定モデルは、ollama run のように CLI で対話しながら試すものではない。clef-flash のページは、判定モデルがまだ Ollama の CLI では使えないとし、HTTP の /v1/systemone に JSON を送るか、TypeSafe の Python SDK の接続先を Ollama に向けて使うよう案内している。

画像の渡し方には、Ollama のドキュメントで決まっている点がいくつかある。

• 画像は base64 にした文字列を images に入れる。URL や data URL は受け付けない
• 形式は PNG・JPEG・WebP
• 画像はリクエスト内のすべての問いで共有される。同じ写真に複数の問いを続けて聞くなら、1回のリクエストにまとめられる
• 画像を含むリクエストは、base64 と JSON を含めた全体で 32 MiB まで。画像の枚数や1枚の画素数の上限は文書に書かれていない
• 入力は切り詰められず、読み込んだコンテキストに収まらなければならない。Ollama の clef-flash の既定のコンテキスト長（num_ctx）は 16,384 トークン

データセットの元の写真は、最も大きいものでも base64 にして約 7.2 MB なので、1枚ずつ送るなら縮小しなくても 32 MiB の上限に収まる。今回は縮小をそろえるために長辺 1024px にしてから送った。

応答には、選んだ選択肢（choice）、5種類それぞれの確率（probabilities）、先に説明した confidence、画像の分も含めた入力のトークン数（usage）が入る。見張りに組み込むなら、choice だけでなく probabilities も記録しておくと、後からしきい値を決め直せる。

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

当サイトの PC（Windows）に入れた Ollama 0.35.1 では、Clef-flash への /v1/systemone のリクエストが、試したかぎり毎回 Clef: non-finite logit（HTTP 500）で失敗した。Ollama のドキュメントにある例をそのまま送っても同じだった。

同じ症状は Ollama の GitHub に issue #18769 として報告されていた。修正のプルリクエスト #18777 が 2026 年 10 月 7 日に取り込まれて issue は閉じられ、修正は 10 月 8 日（日本時間）に公開された v0.40.1 に含まれた。当サイトは修正後の版での動作を確かめていない。

なお、/v1/systemone の文書には OS ごとの対応状況は書かれていない。同じ Windows 版の Ollama でも、文字だけを読む判定モデルの Nimble 9B（Ollama 配布版）は動いた。

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

注意点が二つある。一つは最初の読み込みが遅いことだ。Windows のフォルダをコンテナから読ませるため、初回の呼び出しはモデルの読み込みを含めて 125.9 秒かかった。2 回目以降はモデルが常駐するので、この待ちは無い。もう一つは安定性で、計測を終えた後に Docker Desktop のプロセスが無くなり、コンテナに接続できなくなった。原因は確認できていない。常時の見張りに使うなら、コンテナが落ちたときに気づける仕組みも用意しておきたい。

VRAM と所要時間

Ollama の clef-flash（既定のタグ、Q8_0）の配布物は、本体が 10GB、画像用の projector が 918MB である。ファイルの大きさと読み込んだときの VRAM は別物なので、実際に測った。RTX 5070 Ti（16,303 MiB）で、デスクトップのアプリが同じ GPU を使っている状態の使用量 2,279 MiB に対し、読み込み後は 15,391 MiB になった。モデルの分は 13,112 MiB で、16GB のカードの約 8 割を使う。量子化と VRAM の見積もり方は 手元のVRAMで動くモデルを見積もる — 量子化とメモリ計算の基礎（2026-08-25 公開） にまとめた。画像を読むモデルでは、projector の分も含めて見積もる必要がある。

Ollama の clef-flash には、Q8_0 より小さい量子化のタグが無い。ggml-org が Q4_K_M（6.49 GB）の GGUF を配布しているが、今回は試していない。1枚の分類にかかった時間は、先の表のとおり中央値で 1,486 ms だった。

API で使う場合

手元に GPU が無ければ、Cloudflare の Workers AI でも clef-flash を API として使える。料金は入力 100 万トークンあたり 0.09 ドルである。ただし画像は1回に 4 枚まで、1 枚 4 MiB・1,600 万画素まで、デコード後の合計 8 MiB、リクエスト全体で 13 MiB までという制限がある。今回のデータセットの元の写真は 142 枚が 4 MiB を超えるので、そのままでは送れず、縮小が要る。Workers AI でも、claude -p のような一般の対話 AI でも、API を使う限りカメラの写真は外部のサービスに送られる。

この実測で言えないこと

結果を読むときの限界を、まとめて書いておく。

• 枚数が少なく、1回だけの実行である。各クラス 10 枚、計 50 枚を各モデルで1回ずつ分類しただけで、正答率や確率の当たり具合を一般化できる数ではない
• 写真は一つの研究グループのものだ。不良を意図的に作って撮った写真で、撮影機材や条件は確認できていない。読者のプリンターとカメラの角度で同じ結果になるとは限らない
• 不良の無い写真が含まれていない。問いも「不良が必ず1種類写っている」前提で書いた。正常な造形を不良と判定してしまう割合は測れていない
• 同じ造形を続けて撮った写真が混ざっている可能性がある。抽出した 50 枚にもファイル名の数字が近い写真がまとまって入っており、剥がれの 10 枚は数字の近い2つのまとまりに分かれる。同じ造形の写真かどうかは確かめていない
• 問いの説明文は1通りだけ。説明文を書き換えれば、剥がれと糸引きの取り違えなどは変わりうる
• Clef-flash は Q8_0 の1種類だけを試した。量子化の違う版や、上位版の Clef（27B）は試していない
• 論文の 97.5% とは比べられない。学習させたモデルの物体検出の指標で、本記事の正答率とは測っているものが違う
• Windows 版の不具合は Ollama 0.35.1 で確かめたもの。修正を含む v0.40.1 以降で動けば、Docker を使う回避は要らなくなる（当サイトは確かめていない）

それでも、学習させずに問いを書くだけで、手元のモデルが偶然を上回る割合で不良を分類したこと、そして確率の高さが当たりの目安にならない場合があることは、この 50 枚から読み取れる。

まとめ — 3Dプリントの不良の分類は、確率の当たり具合を確かめてから使う

• 判定モデルは、文章を書かずに、型を決めた問いへの答えと確率だけを返す。Jev は文字しか読めないが、Clef-flash（Apache 2.0、9B）は画像を読み、手元の GPU で動く
• 造形中にプリンターの上で撮られた公開データセットの不良写真 50 枚を5種類に分類させると、正答は Clef-flash が 25 枚、claude -p（Sonnet 5.5）が 41 枚だった
• Clef-flash は 50 枚中 27 枚を糸引きと答え、剥がれの 10 枚はすべて糸引きとした。claude -p も剥がれの半分を糸引きと取り違えた
• 確率の最大値が 0.8 以上の答えの正答は、Clef-flash が 21 件中 10 件、claude -p が 18 件中 16 件だった。Brier スコア（0〜2）は 0.751 と 0.379 で、Clef-flash は全種類に 0.2 ずつ置いた場合の 0.8 に近かった
• Ollama の confidence は確率の集中度で、答えが正しい確率ではない
• Windows 版の Ollama 0.35.1 では Clef-flash が Clef: non-finite logit で動かず、Docker の Linux 版で回避した（修正は v0.40.1 に含まれた）。モデルの分の VRAM は 13,112 MiB だった

写真を学習させなくても、問いを書くだけで分類の仕組みはすぐに作れる。ただし、出てきた確率をそのまま停止や通知のしきい値にする前に、自分のプリンターで撮った正解付きの写真で、確率の高い答えほど当たっているかを数えておく。その一手間が、判定モデルを見張りに組み込むときの出発点になる。

参照

• FDM 3D Printing Defect Dataset（Kaggle、作者による公開）
• ppak10/Additive-Manufacturing-Benchmark（Hugging Face、今回の取得元）
• Hu, Chen, Su, Zhang, Zhu「Real-time defect detection for FFF 3D printing using lightweight model deployment」The International Journal of Advanced Manufacturing Technology 134（2024）
• The MIT License（Open Source Initiative）
• TypeSafe Docs「Models」
• Cloudflare Blog「Introducing Clef: our open-source decision models, and new RL fine-tuning platform」
• Cloudflare Changelog（Clef の Workers AI 提供、2026-10-01）
• Cloudflare/clef-flash（Hugging Face）
• Workers AI「clef-flash」
• Ollama Library「clef-flash」
• Ollama Library「clef-flash:9b」
• Ollama Docs「System One」
• Ollama Docs「Decision」
• ollama/ollama issue #18769
• ollama/ollama pull request #18777「llama: fix clef head reads past 2GiB on windows」
• ollama/ollama リリース v0.40.1
• Claude API Docs「Vision」
• scikit-learn「brier_score_loss」

ブラウザだけでできる本格的な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.