3Dプリントの監視のしきい値を材料費で決める — 確率のどこで止め、どこを人に回すか

造形中のプリンターの状態を判定モデル（decision model。文章を書かずに、あらかじめ決めた形の答えとその確率を返す AI）に渡すと、「この造形は失敗している」の確率が 0 から 1 の数で返ってくる。問題はその先、3Dプリントの監視のしきい値をどこに置くかにある。scikit-learn の二値分類は何も指定しなければ確率 0.5 を境に分けるが、5 時間の造形の 1 時間目に出た 0.5 と、4 時間目に出た 0.5 を同じように扱ってよいのか。止めれば、それまでに使った材料と時間がやり直しになる。続ければ、失敗した造形に残りの時間と材料をつぎ込むことになる。どちらの誤りがどれだけ高くつくかは、造形の進み具合によって変わる。

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

本記事では、3Dプリントの監視のしきい値を、誤って止めた損失と見逃した損失から決める。式は Elkan（2001）が示した費用に基づく決定の式で、損失には当サイトの 2026-08-19 の記事で組んだ原価の計算例を使う。先に結論を書くと、本記事の前提のもとでは、止めるしきい値は造形の進み具合の割合と同じ値になる。さらに人の確認 1 回に 100 円かかると置くと、人に回す範囲は造形の中盤にだけ現れる。ただし、この式は判定モデルの返す確率が当たっていることを前提にしている。当サイトが公開データセットの写真と公式のスライサー設定で行った実行では、確率の高さが当たり外れを分けない例が出た。そこで最後に、Brier スコアで確率の当たり具合を確かめてからしきい値を使う手順を示す。

確率が返ってきても、どこで止めるかは決まらない

判定モデルとして本記事で名前を挙げるのは、次の 3 つである。

• TypeSafe の Jev。文字だけを読み、画像・音声・動画は受け付けない
• Cloudflare が 2026-10-01 に公開した Clef-flash（Apache 2.0）。Ollama 0.35.1 以降なら手元で画像も読める（当サイトの PC では、Windows 版の Ollama 0.35.1 で Clef-flash が動かなかったため、Docker 上の Linux 版で動かした）
• Ollama 0.35 以降の /v1/systemone で手元の GPU に載せて動かすモデル

問いの型は noul・choice・score の 3 つで、本記事では、はい・いいえを聞く noul と、選択肢から一つを選ぶ choice を使う。noul は「はい」の確率を 0 から 1 の数で一つだけ返す。choice はすべての選択肢の確率を返し、それに加えて confidence という値を返す。造形を止めるかどうかは「この造形は失敗しているか」という noul の問いに置き換えられるので、本記事では noul が返す確率を p と書いて話を進める。

ここで押さえておきたいのは、判定モデルの仕事が確率を返したところで終わることだ。scikit-learn の解説は、分類を二つの問題に分けて考えるよう書いている。一つはクラスの確率を予測する統計の問題、もう一つはその確率に基づいて具体的な行動を決める問題である。判定モデルが引き受けるのは前者だけで、後者、つまり確率のどこで止めるかは使う側が決める。

そして、何も決めなければ既定の値が使われる。scikit-learn の二値分類では、predict_proba の条件付き確率が 0.5 を超えたもの（decision_function を使う場合は値が 0 を超えたもの）を陽性と予測する。後で式を見ると分かるが、0.5 は二つの誤りの重さが同じだと置いたときの値である。造形の途中ではこの前提が崩れる。

確率を返すこと自体は、判定モデルに限った機能ではない。scikit-learn の分類器も確率を出せるし、生成型の AI に確率を数値で答えさせることもできる。後で示す当サイトの実行でも、Claude に確率を JSON で答えさせた。判定モデルの違いは、確率を決まった形で必ず返す点にある。

画像で造形を見張る仕組みについては、内蔵カメラと後付けの道具を比べたAI 失敗検知 2026 — 内蔵カメラと後付けツール、どちらが「印刷の見張り」に向くか（2026-07-03 公開）や、Obico AI 監視 × Klipper — スパゲッティ検出と遠隔操作の統合運用（2026-05-16 公開）で扱った。検出の仕組みが画像を読むものでも文字を読むものでも、返ってきた数をどこで切るかという段は利用者の側に残る。本記事が扱うのはその段である。

損失を数える — 誤って止めた損失と見逃した損失

止めるか続けるかの判断には、四つの結果がある。

C_FP は「失敗している」と誤って判定したとき（偽陽性）の損失、C_FN は失敗を見逃したとき（偽陰性）の損失を表す。正しく止めた場合も、それまでに使った材料は失敗した造形に消えている。しかし、その分は止めても続けても戻ってこない。判断によって増えたり減ったりする分だけを数えるので、正しく判定したときの追加の損失は 0 と置く。

金額を入れるには、原価の内訳が要る。当サイトの3Dプリントの原価を日本の電気代で計算し直す — 値付けの根拠を作る（2026-08-19 公開）では、1 個の造形品の原価を 8 つの要素に分けて計算例を示した。本記事ではそのうち、造形そのものにかかる材料費・電気代・機械費を使う。

最初に断っておくと、本記事が使う値のうち公式に定まった値は電気代の単価だけだ。公益社団法人 全国家庭電気製品公正取引協議会（家電公取協）が示す目安単価 31円/kWh（税込、令和4年7月22日改定）である。これも目安であり、実際の料金は契約している小売電気事業者によって異なる。ほかの値はすべて、2026-08-19 の記事が計算例のために置いた仮定である。

この値から、5 時間の造形の直接費は次のようになる。

2026-08-19 の記事は電気代を約 19 円に丸めて合計を 495 円としているが、本記事では 1 時間あたりに割るので、丸めずに 494.6 円を使う。5 時間で割ると、1 時間あたり 98.92 円（材料 55.2 円・電気 3.72 円・機械 40 円）になる。機械費は、本体価格を想定稼働時間で割った管理上の配分であり、税務上の減価償却とは別のものだ。

ここで一つ仮定を足している。材料が時間に比例して減っていく、という仮定である。実際には、底面を厚く埋める造形と、上のほうに細かい部分が多い造形とでは、時間あたりの材料の減り方が違う。自分の造形で使うときは、進捗ごとに使い終わった材料を見積もり直すほうが実態に近い。

なお、2026-08-19 の記事は失敗率も 10% と仮定し、直接費を成功率 0.9 で割って約 11% を上乗せしていた。この 10% も仮定で、当サイトが測った値ではない。止める判定は、この失敗の分の損失を小さくするための仕組みだと見ることができる。

損失の金額は、材料費・電気代・機械費と手間をどこまで数えるかで決まる。ハンドメイドの原価を、作る時間まで含めて書き出すためのノートを挙げておく。

つくる時間まで価格に変える ハンドメイド制作・原価ノート

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

Amazon

楽天市場

ポチップ

3Dプリントの監視のしきい値を決める式 — Elkan（2001）の式 (2)

判定モデルが「失敗している」の確率 p を返したとする。止めた場合と続けた場合の期待損失は、それぞれ次のとおりである。

止めたときの期待損失 ＝ (1 − p) × C_FP
続けたときの期待損失 ＝ p × C_FN

止めたほうが損失が小さいのは、p × C_FN が (1 − p) × C_FP 以上のときだ。これを p について解くと、次の式になる。

p* ＝ C_FP ÷ (C_FP ＋ C_FN)
p が p* 以上なら止める。p* 未満なら続ける

この式には出典がある。Charles Elkan の論文「The Foundations of Cost-Sensitive Learning」（IJCAI 2001、973〜978 頁）は、ある事例の予測は、各クラスの条件付き確率で重みを付けた期待コスト（本記事でいう期待損失）が最も小さくなるクラスにすべきだと書いている。二つのクラスについては、論文の式 (2) がしきい値を与えている。

p* ＝ (c10 − c00) ÷ (c10 − c00 ＋ c01 − c11)
c_ij は「真のクラスが j のときに、クラス i と予測する」コスト

c10 は失敗していない造形を失敗と判定するコスト、c01 は失敗を見逃すコストで、それぞれ本記事の C_FP と C_FN に当たる。正しく当てたときのコスト c00 と c11 を 0 とすると、式 (2) は本記事の p* ＝ C_FP ÷ (C_FP ＋ C_FN) になる。つまり上の式は、Elkan（2001）の式 (2) で、正しく当てたときの損失を 0 とした形である。

式の向きは直感と合っている。誤って止めた損失が大きいほど p* は上がり、よほど確かでなければ止めない。見逃した損失が大きいほど p* は下がり、少し怪しいだけで止める。二つの損失が等しいとき、p* はちょうど 0.5 になる。scikit-learn の既定の 0.5 は、二つの誤りの重さが同じだという前提を置いた値だということが、ここから分かる。

Jev の提供元である TypeSafe も、noul の説明で同じ考え方を書いている。しきい値をどこに置くかは、誤ったときの損失で決まる。はい・いいえのどちらに対しても同じように動けるなら 0.5 を使う。誤った「はい」に基づいて動くのが高くつくなら上げ、本当の「はい」を逃すのが高くつくなら下げる。下げるべき例として、安全上の問題を見逃すことが挙げられている。向きは Elkan の式と一致する。

Elkan の論文には、本記事の組み立てに関わる指摘がもう一つある。誤りの損失が種類によって異なる場面で標準的なベイズ法や決定木の学習法を使うなら、学習データの比率を変えて分類器を作り直すのではなく、与えられたデータのまま分類器を学習し、その分類器が出す確率から最適な決定を明示的に計算するのがよい、というものだ。判定モデルを問いを書くだけで使う場合、使う側が手を入れられるのは、確率から行動を決める段だけになる。確率をそのまま受け取り、しきい値を損失から計算するという手順は、この勧めと同じ方向にある。

原価の計算例で試算する — 進捗によってしきい値が動く

ここからは、2026-08-19 の記事の値を使って p* を計算する。前提は次の 6 つで、最後の 1 つは次の節で使う。

• 5 時間の造形で、直接費は 1 時間あたり 98.92 円ずつ一様に積み上がる
• 失敗した造形物は使えない
• 止めなければ、最後まで刷ってから失敗に気づく
• 止めたら、最初から刷り直す
• 正しく判定したときの追加の損失は 0
• 人に確認してもらえば、必ず正しく判定できる

造形の進み具合の割合を r とすると、誤って止めた損失は「それまでに使った分」、見逃した損失は「残りの時間に使う分」になる。正常な造形を誤って止めると、それまでの分が刷り直しで無駄になる。失敗した造形を見逃すと、最後まで刷り切る残りの分が無駄になる。

C_FP ＝ 494.6 × r        （それまでに使った分が、刷り直しで無駄になる）
C_FN ＝ 494.6 × (1 − r)  （残りの時間に使う分が、失敗した造形に消える）
p*   ＝ C_FP ÷ (C_FP ＋ C_FN) ＝ r

進捗 20%・50%・80% の三つの時点で計算すると、次の表になる。

造形の序盤は、誤って止めても失うのは 1 時間分の 98.92 円にとどまる。一方で見逃せば、残り 4 時間分の 395.68 円が無駄になる。このため、確率が 0.20 を超えただけで止めるのが、期待損失の上では得になる。

終盤は逆になる。4 時間分を積み上げた造形を誤って止めると 395.68 円を失うが、失敗を見逃して残りを刷り切っても無駄になるのは 98.92 円である。したがって、確率が 0.80 を超えるまでは止めない。同じ 0.5 という確率でも、1 時間目なら止め、4 時間目なら続けるのが、この前提のもとでの答えになる。

ただし、しきい値が進捗の割合と同じになるのは、上の前提を置いたときの結果であり、一般則ではない。前提が一つ変われば、式の中身も変わる。

• 途中で人が見て失敗に気づける場合は、見逃しても最後まで刷り切るとは限らない。見逃した損失が小さくなり、しきい値は上がる方向に動く
• 止めた造形を途中から続けられる場合は、誤って止めた損失が小さくなり、しきい値は下がる方向に動く
• 材料の減り方が時間に比例しない造形では、二つの損失の内訳を進捗ごとに数え直す必要がある
• 後処理の手間や、刷り直しのためにプリンターがふさがることの影響は、ここでは入れていない

自分の造形に当てはめるときは、まず前提を書き出し、それから二つの損失を自分の数字で置き直す。式そのものは変わらないが、中に入れる金額は造形ごとに違う。

人に回す範囲 — 確認 1 回の費用で中間の帯が決まる

止める・続けるに、三つ目の行動として「人に知らせて確認してもらう」を加える。人の確認にも費用がかかるので、確認 1 回の費用を c_h と書く。前提の 6 つ目のとおり、確認すれば必ず正しく判定できると置く。

人に回すのが止めるより安いのは、c_h が止めたときの期待損失 (1 − p) × C_FP より小さいときである。続けるより安いのは、c_h が続けたときの期待損失 p × C_FN より小さいときである。両方を満たす p の範囲が、人に回す範囲になる。

人に回す範囲:  c_h ÷ C_FN ＜ p ＜ 1 − c_h ÷ C_FP
範囲が空なら、人に回すより、止めるか続けるかを決めたほうが期待損失が小さい

ここでは c_h を 100 円と置く。2026-08-19 の記事が仮定した時給 1,200 円で、5 分の確認にかかる費用として本記事が置いた例であり、2026-08-19 の記事の値ではない。

進捗 20% と 80% で人に回す範囲がないのは、どちらかの誤りの損失が、人の確認 1 回の 100 円を下回るからだ。進捗 20% の時点では、誤って止めても 98.92 円しか失わない。100 円をかけて人に確かめるより、怪しければ止めて刷り直したほうが安い。進捗 80% の時点では、見逃しても無駄になるのは残りの 98.92 円分なので、確かめるより刷り切ったほうが安い。

中盤では、二つの損失がどちらも 247.30 円になる。確率が 0.5 付近で止めるか続けるかを決めきれないときにだけ、100 円の確認に回す価値が出る。人に回す範囲の幅は、確認の費用が安いほど広がり、高いほど狭まる。通知を受けてすぐに見に行ける状況かどうかで確認の手間は変わるので、c_h は自分の状況に合わせて置く。

判断を保留して別の手段に回すという考え方には古典がある。C. K. Chow は 1970 年の論文「On Optimum Recognition Error and Reject Tradeoff」（IEEE Transactions on Information Theory）で、判断を保留する（棄却する）最適な規則と、誤りと保留の確率の関係を論じた。TypeSafe も noul の説明で、中間の値は二つのコードの経路のどちらでもなく、人に回せると書いている。本記事の試算は、その中間の帯の幅を、材料費と確認の費用から具体的に決めたものにあたる。

人に回すときは、通知を受けてすぐに造形の様子を見られるかで確認の手間が変わる。プリンターに向けた USB カメラがあれば、見に行かずに画面で確かめられる。

EMEET USB ウェブカメラ 1080p（三脚穴付き）

¥1,998 （2026/09/19 11:27時点 | Amazon調べ）

Amazon

楽天市場

ポチップ

式は確率が当たっていることを前提にしている

ここまでの計算では、p を「その時点でその造形が実際に失敗している確率」として扱ってきた。期待損失 p × C_FN は、判定モデルが 0.8 と答えたもののうち 8 割が本当に失敗している、という前提で初めて意味を持つ。もし 0.8 と答えたものの半分しか失敗していなければ、しきい値をいくら正確に計算しても、計算上の期待損失と実際の損失はずれる。

確率と実際の頻度が合っていることを、機械学習では較正（calibration）と呼ぶ。本記事では「確率の当たり具合」と書く。scikit-learn の解説は、よく較正された二値の分類器とは、確率 0.8 前後を付けた事例のうちおよそ 80% が実際に陽性になるものだと説明している。同じ解説は、モデルによってはクラスの確率の見積もりが悪いことがある、とも書いている。

提供元はそれぞれ、確率の当たり具合に手を入れていると説明している。TypeSafe は、Jev を RLCD と呼ぶ強化学習の手法で訓練し、較正された判定を返すとしている。Cloudflare は、Clef の後段の学習で、確率の較正を詰めるために Brier スコアを損失関数として組み合わせたと書いている。どちらも提供元の主張であり、使う側の問いとデータで当たっているかは、別に確かめる必要がある。TypeSafe 自身も、確率の当たり具合は予測の集団についての話で、1 件ごとの答えを保証するものではないと書いている。

以下では、当サイトが 2026-10-07 に行った二つの実行から、確率の高さと当たり外れの関係を見る。どちらも各条件 1 回だけの実行で、この結果を一般化することはできない。また、Jev はこの二つの実行に含まれていない。

画像の分類 — Clef-flash は確率の最大値が 0.8 以上でも半分も当たらなかった

一つ目は、造形中の不良の写真を 5 種類に分類させた実行である。写真は、公開データセット FDM 3D Printing Defect Dataset（Hu ほか、MIT ライセンス）の Hugging Face 版から、各種類 10 枚、計 50 枚を乱数で選び、長辺 1024 ピクセルに縮小して使った。作成者が不良を意図的に作り、プリンターの上で造形中（または造形の直後）に撮った写真で、当サイトの撮影ではない。写真は記事に載せず、配布ページへのリンクにとどめる。

種類は、割れ（Cracking）、層ずれ（Layer_shifting）、造形物がベッドから外れる不良（Off_platform）、糸引き（Stringing）、反り（Warping）の 5 つである。50 枚はすべて不良の写真で、「問題なし」の選択肢はない。手元の Ollama で動かした Clef-flash と、Claude Code の非対話実行 claude -p（Sonnet 5.5）に、同じ写真を 1 枚ずつ渡した。

Clef-flash は、確率の最大値が 0.8 以上だった 21 件のうち、10 件しか当たらなかった。正解したときと外れたときの確率の最大値の平均は 0.654 と 0.641 で、ほとんど差がない。この実行では、Clef-flash の確率の高さは当たり外れの目安にならなかった。外れ方にも偏りがあり、ベッドから外れる不良の 10 枚をすべて糸引きと判定し、50 枚中 27 枚を糸引きと答えている。

50 枚のうち 2 枚は、データセットに含まれていた水増し画像（糸引きの 1 枚は左右反転、層ずれの 1 枚は向きを変えずに明るさを上げたもの）だった。この 2 枚を除いた 48 枚で数え直しても、Clef-flash は確率の最大値が 0.8 以上の 20 件のうち 9 件しか当たっておらず、傾向は変わらない。

この問いは不良の種類を選ぶもので、止めるかどうかの問いではない。それでも、確率の高さと当たり外れが対応していない例として読める。このような確率をそのまましきい値の式に入れると、計算上の期待損失と実際の損失がずれる。

設定の判定 — 推奨値を渡さないと confidence の平均が 0.066 まで下がった

二つ目は、刷る前のスライサー設定の誤りを判定させた実行である。Bambu Studio の公式プロファイル（GitHub の本家。Bambu Lab P1S・0.4 mm ノズル）から正解を作り、素材・ノズル温度・プレート・ベッド温度の組を 42 組用意した。内訳は、問題のない組が 18、ノズル温度を推奨範囲から 20℃ 外した組が 18、その素材に対応しないプレートを選んだ組が 6 である。公式の資料どうしで推奨が食い違う組は除いた。

これを 3 通りの渡し方で、手元の Ollama の Nimble 9B に渡した。推奨値を添えた JSON、推奨値を添えた日本語の依頼文、推奨値を添えない日本語の依頼文の 3 通りである。問いは、「この設定で刷り始めてよいか」（noul）と「どこが問題か」（choice）の二つにした。問いの文面は 3 通りとも同じ英語の 1 通りで、変えたのは状態の書き方と推奨値の有無だけである。

推奨値を渡さないと、choice の正答は 42 組中 17 組に落ち、confidence の平均は 0.066 まで下がった。この実行では、判断の材料が足りないときに confidence も下がり、正答の少なさと同じ向きに動いた。ただし、この confidence は Ollama が確率の分布の集中度から出す値である。Ollama の文書は、正しさの確率ではないと明記している。confidence が低いから外れる、高いから当たる、と読める値ではない。

もう一つ目立ったのは、問いの立て方で答えが食い違ったことだ。推奨値を添えた日本語の依頼文では、ノズル温度の誤りを含む 18 組すべてで、choice は「ノズル温度」が問題だと当てた。ところが同じ状態への noul の「刷ってよいか」は、18 組とも「はい」の側に誤った。noul の文面は 1 通りしか試していないので、書き方を変えればどうなるかは分からない。

それでも、同じ状態から出た二つの答えが逆を向くことがある以上、noul の確率をそのまましきい値の式に入れるのは危うい。式に入れる前に、その問いの確率が当たっているかを確かめる必要がある。なお、同じ 42 組で claude -p は、推奨値を添えた 2 通りでは noul・choice とも全問正解、推奨値なしでは 34 組を正答した。

確率の当たり具合を Brier スコアで確かめる

確率の予報を採点する方法として、1950 年に米国気象局の Glenn W. Brier が Monthly Weather Review（78 巻 1 号、1〜3 頁）に発表したのが Brier スコアである。原典の定義は、もともと多クラスの形をしている。n 回の機会のそれぞれで、事象は r 個のクラスのどれか一つで起きる。各回・各クラスについて、予報した確率 f と、実際に起きたクラスで 1・ほかで 0 となる E との差を二乗して足し合わせ、n で割る。

P ＝ (1 ÷ n) × （すべての回と、すべてのクラスについての (f − E)² の合計）
0 が完全な予報、2 が最悪の予報（原典の尺度）

二値の場合は、この値を 2 で割って 0〜1 で表すことが多い。scikit-learn の brier_score_loss も、既定では多クラスで 0〜2、二値では 2 で割った 0〜1 で返す（多クラスへの対応は 1.7 以降）。同じ「Brier スコア」でも尺度が二通りあるので、値を書くときは必ず尺度を添える。

Brier スコアが確率の採点に向いている理由は、確率をごまかしても得をしない点にある。Brier は原典で、この採点のもとでは、予報者は完全に当てられないときに各事象の確率を偏りなく述べるよう促され、予報の技術がまったく無ければ過去の頻度どおりの確率を出すよう促される、と書いている。scikit-learn の説明でも、Brier スコアは strictly proper scoring rule、つまり正直な確率を出したときに最も良い点になる採点規則とされている。

比べる基準の値も計算できる。5 クラスで常に各 0.2 と答えると 0.8（0〜2 の尺度）、二値で常に 0.5 と答えると 0.25（0〜1 の尺度）になる。画像の分類の実行は各種類 10 枚ずつの同数なので、何も分からずに各 0.2 と答えた場合の 0.8 が基準になる。Clef-flash の 0.751 はこの基準をわずかに下回るだけで、claude -p の 0.379 とは大きく開いた。

ただし、Brier スコアが低いことは、確率の当たり具合が良いことを必ずしも意味しない。scikit-learn の解説は、Brier スコアが低くても、当たり具合の悪いモデルが識別の力の強さで点を稼いでいる場合があると注意している。そこで Brier スコアに加えて、確率の高さで区切り、区切りごとに確率の平均と実際の正答の割合を比べる。これを図にしたものが較正曲線（reliability diagram）で、scikit-learn は横軸に区切りの中の確率の平均、縦軸に実際に陽性だった割合をとる。比べる相手は区切りの下限ではなく、区切りの中の確率の平均である。

画像の分類の実行でいえば、確率の最大値が 0.8 以上の判定は、当たり具合が良ければ、正解の割合がその判定の確率の最大値の平均に近くなるはずだった。実際には、Clef-flash では 21 件の平均が 0.929 なのに正解は 10 件（0.476）、claude -p では 18 件の平均 0.896 に対して正解は 16 件（0.889）だった。ただし、50 件程度では、確率を細かい区間に分けると 1 区間あたりの件数が少なすぎ、較正曲線の形は読めない。この件数では「0.8 以上」のような大きな区切りで見るのが限度である。

しきい値を使う前に確かめる手順

3Dプリントの監視のしきい値を計算で決めるなら、その前に次の手順で確率を確かめる。

1. 正解の分かっている事例を集める。判定モデルに渡す造形中の状態と、その時点で造形が実際に失敗していたかどうかを組にして記録する。p は「いま失敗しているか」の確率なので、正解もその時点の状態で付ける。正解は、その時点の写真などを後から人が見て決める。造形が最後に失敗したかどうかで付けると、途中までは正常だった時点まで失敗と数えてしまう
2. 判定モデルに同じ問いを投げ、返ってきた確率をすべて記録する。問いの文面と状態の渡し方は、運用で使うものと同じにする。状態の書き方や渡す情報（推奨値の有無）を変えると答えが変わったことは、上の設定の判定で見たとおりである。問いの文面そのものを言い換えた場合の影響は、この実行では確かめていない
3. Brier スコアを計算し、尺度を添えて基準の値と比べる。二値なら、常に 0.5 と答えた場合の 0.25（0〜1 の尺度）が基準になる。ただし、失敗が少ない記録ではこの基準は甘い。Brier は原典で、毎回同じ確率を答えるなら、実際の頻度どおりに答えたときに点が最も良くなることを示している。二値（0〜1 の尺度）では、記録の中で失敗していた割合を b とすると、常に b と答えた場合の b × (1 − b) がこの基準になり、b が 0.1 なら 0.09 である
4. 確率の高さで区切り、区切りごとに件数・確率の平均・実際の失敗の割合を並べる。比べる相手は区切りの下限ではなく、区切りの中の確率の平均である。確率 0.8 以上の事例で 8 割が失敗していても、その事例の確率の平均が 0.95 なら、確率は実際より高めに出ている。件数が少ない区切りの割合は偶然で大きく動くので、件数も必ず並べる。しきい値の判断に効くのは p* と人に回す範囲の近くの確率なので、その区切りで確率の平均と失敗の割合が近く、件数も足りていることを確かめてから、式に入れる
5. 合わなければ、計算したしきい値をそのまま使わない。TypeSafe も noul の説明で、しきい値は使う側のコードに置くものだとし、人に回る件数が多すぎれば「いいえ」と「はい」のしきい値の間を狭め、誤った振り分けが多く通るなら広げるよう書いている。確率そのものを補正する方法は、scikit-learn の較正の章にまとまっている

手順 3 と 4 の計算は、表計算でも数行のコードでも済む。Python なら次のように書ける。

# rows: (確率 p, その時点で失敗していたら 1・いなかったら 0) の組の一覧
def brier_binary(rows):
    # 二値の Brier スコア（0〜1 の尺度。原典の 0〜2 の尺度を 2 で割った値）
    return sum((p - y) ** 2 for p, y in rows) / len(rows)

def band(rows, lower, upper):
    # 確率が lower 以上 upper 以下の事例の、件数・確率の平均・実際に失敗していた割合
    picked = [(p, y) for p, y in rows if lower <= p <= upper]
    n = len(picked)
    if n == 0:
        return 0, None, None
    return n, sum(p for p, y in picked) / n, sum(y for p, y in picked) / n

b = sum(y for p, y in rows) / len(rows)  # 記録の中で失敗していた割合
print(brier_binary(rows), "基準は常に 0.5 なら 0.25、常に b なら", b * (1 - b))
print(band(rows, 0.4, 0.6), "件数と、確率の平均・失敗の割合が近いかを見る")

二値の場合、原典の式で 2 つのクラスの差を足すと (p − y) の二乗の 2 倍になるので、2 で割った値は (p − y) の二乗の平均になる。上の brier_binary はこの形で計算している。

確率の当たり具合を自分の例で数える作業は、生成 AI のアプリを評価で改善していく考え方と同じだ。評価の組み立て方をまとめた一冊を挙げておく。

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

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

Amazon

楽天市場

ポチップ

運用の設計 — 止める判定はプリンターの安全機能の代わりではない

ここまでの内容を、造形中の運用に組み立てる。

1. 造形を始めるときに、その造形の直接費と時間から、進捗ごとの C_FP と C_FN を出す
2. 人の確認 1 回の費用 c_h を、自分の状況に合わせて置く
3. 状態を判定モデルに渡すたびに確率 p を受け取り、その時点の進捗でのしきい値と人に回す範囲と比べる
4. 判定と、その時点で造形が失敗していたかを後から確かめた結果を記録し、Brier スコアと、区切りごとの件数・確率の平均・実際の失敗の割合を更新する

手順 3 の判断は、次の形で書ける。

下限 ＝ c_h ÷ C_FN
上限 ＝ 1 − c_h ÷ C_FP
下限 ＜ p ＜ 上限 なら、人に知らせる
それ以外で p ≥ p* なら、止める
それ以外なら、続ける

下限と上限は C_FN と C_FP で割るので、この形が使えるのは二つの損失がどちらも 0 より大きいとき、つまり進捗が 0% と 100% の間のときに限られる。進捗 0% では誤って止めた損失が、100% では見逃した損失が 0 になり、割り算ができない。Elkan（2001）も、真のクラスがどちらの場合でも、誤ったときのコストが正しく当てたときのコストより大きいという条件を置いている。そして、この条件が一方のクラスでだけ崩れた場合は、すべての事例を同じクラスに振り分けるのが最適になると書いている。端点を含めて一つの規則で書くなら、止めたときの期待損失 (1 − p) × C_FP、続けたときの期待損失 p × C_FN、人に回したときの費用 c_h の三つを直接比べ、最も小さい行動を選べばよい。

人に回す範囲が空でないときは、その範囲は必ず p* を含む。したがって、範囲の外では止めるか続けるかが p* だけで決まる。通知の仕組みは、Home Assistant で水やりを知らせて自動化する — 通知からポンプ制御まで（2026-10-08 公開）で組んだ、センサーの値がしきい値をまたいだら知らせる自動化と同じ形で作れる。

しきい値は confidence ではなく、確率 p に置く。confidence の式は提供元ごとに違うからだ。TypeSafe の choice の confidence は、最上位の確率が均等な分布からどれだけ離れているかを表し、(p_max − 1/n) ÷ (1 − 1/n) で計算する。最上位の確率しか使わない。Ollama の /v1/systemone の confidence は、分布の集中度を 1 − H(p) ÷ ln(N)（H(p) はエントロピー、N は候補の数）で計算し、文書は正しさの確率ではないと明記している。

Ollama の文書の例にある確率 0.0125・0.9781・0.0093 で計算すると、エントロピーの式では 0.8908（文書の表示は 0.8906。確率が丸めて表示されているための差）、TypeSafe の式では 0.9671 になる。同じ確率から違う値が出るので、提供元をまたいで confidence を並べて比べることはできない。noul はもともと確率を一つ返すだけで、confidence は返らない。

判定 1 回ごとの費用、つまり API の料金も、期待損失に足すことができる。ただし本記事の試算には入れていない。判定の回数を増やすほど費用が積み上がるので、判定の間隔を決めるときに考えに入れる。

そして、最も重要な点を書いておく。判定モデルは、プリンター自体の安全機能の代わりではない。熱暴走の保護のような安全機能は、判定モデルとは別に、プリンターの側で働いていなければならない。判定モデルが止める判定を返さなかったからといって、その造形が安全だということにはならない。止める判定は、材料と時間の損失を減らすための補助として扱う。

本記事の計算は、無人で動かしてよいかどうかを決めるものでもない。期待損失は材料費・電気代・機械費だけで数えており、火災のような損失は式に入れていない。そうした損失は、確率としきい値で割り切る種類のものではない。

まとめ — 3Dプリントの監視のしきい値は、損失と確率の当たり具合の両方で決める

• 判定モデルが返すのは確率までで、どこで止めるかは使う側が決める。既定の 0.5 は、二つの誤りの重さが同じだと置いた値である
• しきい値は、Elkan（2001）の式 (2) で正しく当てたときの損失を 0 とした p* ＝ C_FP ÷ (C_FP ＋ C_FN) で決める
• 2026-08-19 の記事の原価の計算例（電気の 31円/kWh は家電公取協の目安値、ほかは仮定）を使い、直接費 494.6 円が 5 時間で一様に積み上がり、止めたら最初から刷り直すと置くと、しきい値は進捗の割合と同じ 0.20・0.50・0.80 になる。前提が変われば成り立たない
• 人の確認 1 回を 100 円と置くと、試算した 3 つの時点では、人に回す範囲は進捗 50% のときの 0.4044〜0.5956 にだけ現れ、20% と 80% では現れない
• 式は、確率が当たっていることを前提にしている。当サイトの実行では、Clef-flash は確率の最大値が 0.8 以上の 21 件中 10 件しか当たらず、Nimble 9B は推奨値を渡さないと choice の confidence の平均が 0.066 まで下がり、noul と choice の答えが食い違う場面もあった
• しきい値を使う前に、その時点の状態で正解を付けた事例で、Brier スコア（尺度を明記する）と、確率の区切りごとの件数・確率の平均・実際の割合を確かめる。しきい値は confidence ではなく確率に置く
• 止める判定はプリンターの安全機能の代わりではなく、損失を減らすための補助である

確率を返す AI を造形の監視に組み込むとき、手を動かす順番は、確率の当たり具合を確かめ、損失を数え、しきい値を計算する、の順になる。式は一行で書けるが、その一行に入れる確率と金額を確かめる作業のほうに時間をかける価値がある。

参照

• Charles Elkan「The Foundations of Cost-Sensitive Learning」IJCAI 2001（ML Anthology）
• Glenn W. Brier「Verification of Forecasts Expressed in Terms of Probability」Monthly Weather Review 78(1)（1950）
• C. K. Chow「On Optimum Recognition Error and Reject Tradeoff」IEEE Transactions on Information Theory（1970）（IBM Research）
• scikit-learn「sklearn.metrics.brier_score_loss」
• scikit-learn「Probability calibration」
• scikit-learn「Tuning the decision threshold for class prediction」
• TypeSafe ドキュメント「Noul」
• TypeSafe ドキュメント「Confidence」
• TypeSafe ドキュメント「AI primer」
• TypeSafe ドキュメント「Models」
• TypeSafe ドキュメント「API reference」
• Ollama API リファレンス「System One」
• Cloudflare ブログ「Introducing Clef: our open-source decision models, and new RL fine-tuning platform」
• 全国家庭電気製品公正取引協議会「よくある質問」
• FDM 3D Printing Defect Dataset（Hugging Face、ppak10/Additive-Manufacturing-Benchmark に同梱）
• FDM 3D Printing Defect Dataset（Kaggle、作成者による公開）
• Bambu Studio（GitHub、bambulab/BambuStudio）

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