confidence（信頼度）とは｜Jevの確率を1つの数に圧縮し、リスクごとにしきい値を変える読み方

Jev（ジェヴ）の答えには probabilities（確率）と confidence（信頼度）の2つの数字が付いてきますが、どちらを見て分岐を書けばよいのでしょうか。
結論から言うと、confidence は確率分布の「形」を 0 から 1 の1つの数に圧縮したもので、コードのしきい値判定にはこちらを使うのが公式の推奨です。
実務では、答えを信じるかどうかを confidence で決め、行動の重さに応じてしきい値を変える設計が基本になります。

confidence（信頼度）とは

probabilities（確率）の形を1つの数に圧縮したもの

公式ドキュメントの Confidence のページでは、Choice（選択肢）と Score（段階採点）の答えには必ず probabilities が付くとされています。
Choice なら各選択肢、Score なら各段階に確率が割り振られ、分布が1つに集中していれば確信が強く、広く散っていれば迷っている、という読み方です。
confidence はこの分布の形を 0 から 1 の1つの数に畳み込んだ統計量で、TypeSafe AI 側が計算して毎回返すため、自分で分布を集計しなくてもしきい値を書けます。
一方で Noul（ヌール、はい／いいえの質問）の答えには confidence が付かないとされています。

この数字は「勝った選択肢の確率」とは別物です。
公式クックブックでは、1位が 0.45 で2位が 0.44 の場合と、1位が 0.45 で残りが薄く散っている場合は別の状況であり、confidence はその違いを区別する数だと説明されています。
公式の定義に縛られる必要はなく、用途に合わせて probabilities から独自の指標を計算してもよい、という注記もあります。

「わからない」を数で受け取る意味

公式ドキュメントは、正直に不確かさを表せない知的システムは信頼できない、という立場を取っています。
confidence はモデルが「これは自信がない」と伝えるための仕組みで、コードはその値ごとに違う動きを実装できます。
低い値は失敗ではなく、state（状態）に材料が足りない、選択肢の境界が曖昧、質問がこの形に向いていない、といった信号として扱うことになります。

読み方｜3段階に分けてコードの動きを変える

1. 高・中・低の3つの帯を決める

公式が最初の型として勧めているのは、信頼度を3つの帯に分ける方法です。
高い帯は自動で実行し、人を挟みません。
中程度の帯では、ユーザーに確認を求める、レビュー待ちに回す、追加情報を集める、のいずれかを取ります。
低い帯では行動せず、人に回すか、聞き直すか、別の仕組みに切り替えます。
境界をどこに引くかは、間違えたときの被害の大きさで決める、というのが公式の説明です。

2. しきい値は行動のリスクごとに変える

しきい値は1つの数ではありません。
Confidence-gated routing のページにある音声バンキングの例では、残高照会と送金承認で別の基準を置いています。

action = response.answers["intent"]

# Below 0.6 confidence on any action, route to a human
if action.confidence < 0.6:
    route_to_support_agent(account_id)

elif action.choice == "check_balance":
    # Low stakes. 0.6 confidence is sufficient.
    show_balance(account_id)

elif action.choice == "approve_transfer":
    if action.confidence > 0.85:
        # High stakes, but high confidence. Safe to act automatically.
        approve_transfer(account_id)
    else:
        # High stakes, moderate confidence. Verify intent first.
        ask_user_to_confirm("Just to confirm: you would like to approve this transfer, is that correct?")

else:
    route_to_support_agent(account_id)

0.6 の下限は、モデルが本当に迷っているものを一括で人に回すための床です。
残高照会は間違えても読み上げが違うだけなので 0.6 で十分とされ、送金承認は 0.85 を超えない限り本人に確認を取る設計です。
リスクの許容度をコードに書き込む、という考え方がここに表れています。

3. 自分のデータで信頼度と正解率を描いて決める

正しいしきい値は分野とモデルの成績次第で、公式は保守的な値から始めて自分のデータで試し、結果を見て調整するよう勧めています。
How to build with TypeSafe のページでは、信頼度と正解率を自分のデータ上でプロットしてしきい値を検証する、という手順が示されています。
横軸に confidence、縦軸に正解率を置けば、どこから下で精度が落ちるかが見えるため、帯の境界を根拠を持って決められると考えられます。

活用例｜どんな業種・職種で使えるか

金融・調査（企業の業種分類）: Classification using confidence のクックブックでは、SEC の年次報告書を 75 の産業グループに Choice で分類し、confidence が 0.9 未満なら1段上の大分類（産業グループを束ねる粗い区分）を返します。
公式ドキュメントでは、60 件の書類が 0.9 でほぼ半分に割れ、確信のある半分は 90%、ない半分は 40% の正解率で、後者を大分類で報告すると 70% になったとされています。
2回目の呼び出しなしに「粗いが使える答え」を確保する使い方です。

編集・リサーチ（引用の検証）: Double-checking citations のクックブックでは、引用元の文脈が主張を支えるかを Choice で判定し、confidence が 0.8 以上なら判定をそのまま採用、未満なら人が確認する流れになっています。
モデルを信頼できるまでは高めの値から始める、という注記が付いています。

カスタマーサポート（意図分類）: 問い合わせの意図を Choice で分類し、confidence が低いものだけを担当者に回す構成が公式の Intent routing の例です。
確信のある問い合わせは決まった処理や専門の LLM に流し、迷ったものだけ人の手に残せます。

つまずきポイント・注意点

• Noul の答えに confidence はありません。
  はい／いいえの確率そのもの（noul の値）が 0.5 に近いかどうかで迷いを読むことになると考えられます。
• confidence と「1位の確率」を混同しないことです。
  僅差の2択と、1位以外が薄く散った状態は別物で、後者のほうが confidence は高くなると説明されています。
• 他社や他事例のしきい値を借りないことです。
  公式は、値は分野とモデルの成績に依存するとし、自分のデータで検証するよう求めています。
• 低い confidence を「エラー」として捨てないことです。
  大分類で返す、確認を挟むなど、粗くても使える答えに変える設計が公式の例には多く見られます。

限界と向き不向き

まとめ｜confidence は「答えを信じる」から「答えを選ぶ」への入り口にする

confidence は probabilities の形を 0 から 1 の1つの数に圧縮した統計量で、Choice と Score の答えに毎回付き、Noul には付きません。
核心は、答えそのものではなく「行動するかどうか」をこの数で決め、しきい値を行動のリスクごとに変える点にあります。
次の一手は、シリーズの『Choice（選択肢）』の記事の質問を1つ用意し、正解が分かるデータで confidence と正解率を並べて、あなたの業務での 0.6 や 0.85 にあたる値を探すことです。