しきい値はコードが持ち、モデルは確率だけを返す

数百の実プロジェクトを並べて見たとき、最も安定して共通しているのはこの一点です。

モデルが答えるのは「どれくらいありそうか」。コードが答えるのは「それで足りるか」。

これは好みの問題ではありません。自己申告の信頼度が信じられないという事実から導かれる、唯一安全な結論です。この点には独立した実測の裏付けがあります（確率はどこまで信じられるか）。

具体的にどういう形になるか

Choice と Score は答えと一緒に confidence を返し、Noul は 0〜1 の確率をそのまま返します。インターフェース自体は何も判定してくれません —— しきい値はあなたのものです。 実プロジェクトでは、これが非常に具体的な形になります。

Cloudflare Worker 上で動く罵倒語フィルタは、しきい値も max() の集約方針も公開 OpenAPI schema も、すべて Worker 自身のコードに持っています。モデルはそれが呼ぶ一つの関数にすぎません。
コメントを隠すかどうかを判断するブラウザ拡張は、0.85 / 0.7 / 0.5 の三段を拡張側に固定し、検査が失敗したときは隠したままにします。これもしきい値方針の一部です。
インシデントのトリアージツールは「人を呼ぶ」を P(SEV1) + P(SEV2) ≥ 0.80 と定義し、その 0.80 は設定ファイルにあります。モデルの中ではありません。

三つに共通するのは同じことです。モデルを替えてもしきい値は動かず、しきい値を変えてもモデルは動かない。 しきい値をモデルに「決めさせ」ると、この二つが結びつきます —— そしてしきい値を調整する作業が、プロンプトを書き換える作業に変わります。

二種類の失敗を分けられるからです。

混ざると、「精度が足りない」という一つの症状がどちらなのか分からなくなります。先のトリアージツールが 0.80 を設定に直接書けるのは、その数を単独で振り返り、単独で調整できるからです。

この原則は一つの前提に乗っています。受け取った数が校正された確率であること。

独立した再計算によれば、Score の質問で返る confidence はしばしば スコアの小数部分そのもので、そうした出力は密集しています（121 件）。これは「モデルが自信を持っている」ではなく、スコアから導かれた値のように見えます。

違いは大きいです。

別に、独立した測定報告がモデルの自己申告フィールドを真値と突き合わせ、説明に書かれているほど細かい値ではないと報告しています（公開の批判を参照）。

手順は三つで、順序が重要です。

しきい値は意味ではなく運用で使う。 0.8 が「80% 正しい」を意味するかは重要ではありません。重要なのは、あなたのデータで 0.8 以上のものが明らかに精度が高いかどうかです。これはホールドアウトで確認できます。
自分のラベルでしきい値をフィットさせる。 まさにそのためのツールがあります。自分のラベル付きデータで「目標精度に必要な質問ごとのしきい値」をフィットし、ホールドアウトで検証し、モデル更新が固定済みのしきい値を壊したら CI を失敗させる。
しきい値をコードに固定し、見直し日を決める。 しきい値は価格と同じでモデルのバージョンとともに古くなります。一度決めて終わりではありません。

モデルの信頼性は、あなたのしきい値に現れるべきで、モデルの自己申告値に現れるべきではありません。 前者は自分のデータで測れます。後者は測れません。