JevのChoice・Score・Noul：確率、confidence、権限を混同しない

三つの質問は代用品ではない

公式 primitive ガイドは Choice を定義済みの一つを選ぶ質問、Score を順序付きの説明レベルで評価する質問、Noul を yes の確率を返す yes/no 質問として区別する。名前が似ていても、後続コードで必要な意味が違う。

Choice は「この依頼をどの既存ハンドラへ送るか」に向く。返答には選ばれた値、各候補の確率、confidence があり、選択肢間の競合が見える。Score は「この検索候補は利用者の問いにどの程度直接答えるか」を none / weak / useful / direct のように比較可能な段階で採点したい時に向く。Noul は「このメッセージに返金要求が含まれるか」のような独立した条件に向く。複数タグが同時に成り立つなら、巨大な Choice に詰め込まず Noul を一つずつ置く。

1. 1閉じた一つの分岐
2. 2Choice
3. 3候補間の分布

1. 1順序のある質
2. 2Score
3. 3段階ごとの分布

1. 1独立した条件
2. 2Noul
3. 3yes の確率

1. 1分布 + 業務規則 + 実行権限
2. 2自動化・確認・拒否

probability と confidence の読み方

確率は「この質問と state に対し、その答えがどの程度支持されるか」を表す。confidence は Choice/Score では分布の集中度を要約する指標である。これはワークフローが正しい確率でも、ユーザーが許可した確率でも、現実世界で安全な確率でもない。confidence の公式説明が強調する通り、Choice の候補が二つとも妥当なら分布が割れ、低 confidence になることがある。害のない表示の選択なら問題ではない。一方、候補が一つに偏っていても、古い価格表を state に渡していたら発注してはいけない。

Noul の 0.5 付近は「強さが中くらい」ではなく yes/no が拮抗しているという意味だ。is_urgent=0.51 を「少し緊急」として並び替える前に、緊急の定義と、見逃し・過剰通知のどちらの損失が大きいかを決める。確率を意思決定に使うには、検証用データで校正と損失を確認する必要がある。

安全なゲート設計

まず行動を三段階に分ける。A は検索順位や下書きタグなど可逆・低影響の提案、B は人が確認してから送信する操作、C は支払い、外部公開、削除、物理的な実行のような高影響操作である。A は代表例で精度を観察しつつ confidence を補助的に使える。B は confidence が低い、state が欠ける、対象が新規ならレビューへ送る。C はモデルの値に関係なく、明示的な権限、本人確認、決定論的なポリシー検査、再確認、監査記録を必要とする。

具体例として、候補文書を読む Choice が refund を選んでも、実際の返金 API は呼ばない。コードは (a) 利用者の権限、(b) 注文 ID の存在、(c) 金額計算、(d) 返金済みでないこと、(e) 人の確認トークンを検証し、初めて実行する。Jev はチケットを見つける補助であり、権限委譲の装置ではない。

閾値を作る実験

閾値を「0.8 なら安全」と決め打ちしない。実際の利用に近い、時系列で分けた保留データを用意する。各ケースに人の期待ラベルと影響度を付け、モデルの回答、全候補確率、confidence、処理時間を保存する。0.5 から 0.95 までの閾値で、coverage（自動処理の割合）、誤処理率、レビュー量、重大誤り数を表にする。誤りのコストが高い業務では、正解率の平均より重大誤りを優先する。

対照群も必要だ。現行のルール、ランダムではない既存の人手フロー、モデル無しの検索順位を残し、同じ入力集合で比較する。モデル導入後だけの数字は、季節性や担当者変更と区別できない。質問文・criteria・候補生成・モデル版を同時に変えず、一つずつ変える。低 confidence ケースを除いて評価すると、実運用のレビュー負荷を隠すので、必ず「全件」と「自動化された部分」を併記する。

演習：レビュー・キューを作る

前章のメモ分類器に、needs_review の Choice 候補を加える。閲覧だけのアプリで、confidence が低い時、または needs_review の確率が最大の時はタグを確定せず review へ置く。次に、候補確率の最大値と confidence を混ぜない二本の集計を作る。20 件のホールドアウトに人が判定し、レビュー行きの理由を残す。最後に「confidence が高いのに誤った」一例を追い、state、候補網羅性、criteria、現実のラベルのどれが原因かを文章で説明する。この反例が安全設計の出発点になる。

未実行のゲート例

次は API 呼び出しそのものではなく、取得済みの Choice 回答をどう扱うかの短い TypeScript 例である。これも未実行であり、confidence の数値範囲・フィールド名は採用 SDK の公式 responses 型で確認する。閾値 0.85 は普遍値ではなく、評価で差し替える仮の設定である。

type Decision = { value: string; confidence: number; probabilities: Record<string, number> };
function route(d: Decision, permissions: { canAutoTag: boolean }) {
  if (!Number.isFinite(d.confidence) || d.confidence < 0 || d.confidence > 1) throw new Error("invalid confidence");
  const labels = ["research", "implementation", "idea", "needs_review"] as const;
  if (!(labels as readonly string[]).includes(d.value)) throw new Error("invalid Choice label");
  const unclear = d.value === "needs_review" || d.confidence < 0.85;
  if (!permissions.canAutoTag || unclear) return { kind: "review", reason: "authority-or-uncertainty" };
  return { kind: "display_tag", value: d.value }; // 外部副作用なし
}

ここで canAutoTag はモデルが出してはいけない。ログイン中のユーザー、対象レコード、組織ポリシーから決定論的に求める。外部送信なら display_tag の代わりに必ず確認画面を返し、確認時に対象が変わっていないかを再読込する。confidence が高い回答を連続して見ても、権限検査を一度省略する理由にはならない。

実験表と失敗診断

評価表は case_id, split, predicted, p_max, confidence, action, human_label, harm_class, latency_ms, question_version を最低限持つ。action は回答そのものではなく、表示、自動タグ、レビュー、拒否のどれを選んだかを記録する。これにより「分類が正しいが権限で止めた」「分類は誤ったがレビューで被害を防いだ」を区別できる。重大度は事後に好都合に書き換えず、評価開始前に定義する。

よくある失敗は、ラベルが均等なテストで精度が高くても、現実では稀な危険ケースを見落とすこと、レビュー者がモデル回答を見て誘導されること、閾値をテストセットに何度も合わせることだ。対策は、危険ケースを別層として集計し、ブラインドな人手判定を取り、最終セットを一回しか意思決定に使わないことである。モデルの確率が校正されているかは reliability diagram と bin ごとの実測正解率で確認し、サンプルが少ない bin を過信しない。

confidenceは第四のprimitiveではない

現行System One docsはtext-only Jevを説明し、ChoiceとScoreのconfidenceは0〜1、Noulには別confidenceがないとしています。n候補のChoiceでは集中度の計算は(pmax − 1/n) / (1 − 1/n)です。pmax=.7なら2候補で.4、4候補で.6になります。これは算術であって、測定済み信頼性の主張ではありません。fixtureの.valueは教材内の表現でありSDK field名ではありません。

gate前に全fixtureを検証します。labelは現在のcandidate tupleに含まれ、confidenceは有限で0〜1でなければなりません。その後、holdout、drift、adversarial caseで確率を校正します。Brier scoreは(p − y)^2の平均で、各calibration pointにはbin件数を併記します。誤った自動tagの損失9、reviewの損失1という玩具例では、検証済みの事象確率が8/9を超える時だけ自動化します。Choice confidenceをこの確率で置換してはいけません。

2026-09-22のBetterOffline議論はharness解釈を問い直しています。これはコミュニティコメントです。決定論的なprocess exit codeにはモデルが不要なことがあり、threadはモデルの利益を証明しません。日付付き9月資料の境界はSystem One early-access記事です。vendor evalはharnessが正しいと仮定し、人間の真実ではありません。

都合のよいsplitではなく変化に対して校正する

新しい文書からtemporal holdoutを作り、変化した語彙、policy、candidate数からdrift setを作ります。各確率binについて件数、予測確率の平均、実測結果率、区間を公開します。3件だけでほぼ完全に見えるbinは校正ではありません。同じlocked caseでBrier scoreを計算し、harm classとcandidate数別にも確認します。confidence thresholdに普遍的な意味はありません。base rate、candidate集合、policy、annotator不一致がすべて変わるからです。

損失は隠れたpolicyでなく明示的な玩具仮定です。誤った自動tagの損失9、reviewの損失1から8/9が導かれるのは、検証済みの事象確率がその正確な損失モデルを記述する場合だけです。reviewも誤ります。reviewerの覆しをsampleし、queue delayを測り、別のescalation pathを残します。確率は可逆な表示tagを決める助けにはなりますが、重大操作の署名済み権限確認を置き換えません。