なぜ0.9のようなマジックナンバーは必ず失敗するのか

多くのAIエージェント設定ファイルには、こんな一行があります。

ESCALATION_THRESHOLD = 0.90

これ以上ならエージェントが単独で処理し、以下なら人間にエスカレーションする。シンプルで調整しやすく、自律性を制御している気分にもなれます。

しかし、これは間違ったフレームです。より良い数字を探すのが答えではありません。エスカレーション閾値はそもそもパーセンテージではなく、**価格(price)**でした。

多くのチームは「エージェントはこれができるか?」という能力の問いを立てます。SQLを書けるか? 返金を処理できるか? 可能なら走らせてしまう。しかし「できる」と「単独でやっていい」は別問題です。後者はコストの問いです。

  • エージェントが処理する → エラーコストをリスクとして抱える
  • 人間に渡す → エージェントが正しくても間違っていても、人間の時間コストを払う

この2つの数字があれば、あとはほとんど気まずいほど単純になります。(根拠資料: Towards Data Science 原文)

Developer configuring AI agent confidence threshold in code editor with escalation logic Algorithm Concept Visual

真の閾値は「比率」である (Chow's Rejection Rule, 1970)

人間がエスカレーションされたチケットを常に正しく処理すると仮定します。エージェントが単独で行動すべき条件は以下です。

(1 - p) × ErrorCost  <  EscalationCost

ここで p = エージェントが正解である確率

これを p について整理すると:

p  >  1 - (EscalationCost / ErrorCost)

この右辺の値が本当の閾値です。 ここで注目すべき点:

  • モデル性能に依存しない
  • ワークショップで決めたポリシーに依存しない
  • ただ2つのコストの比率にのみ依存する

エラーが安ければ閾値は下がり、エージェントはより頻繁に単独行動できます。エラーが高価なら閾値は上がり、どれだけ自信があっても人間に聞くべきです。

固定カットオフは、この比率がすべての意思決定で同一であると仮定します。そんなケースは稀です。

2つのチケット例

数値は論証用に作ったものですが、構造は実務と同じです。

ケースA — 通常の返金リクエスト

  • エラー時の後処理コスト: £15 (後続チケット + goodwill credit)
  • エスカレーションコスト: £4 (専門家3分)
  • 閾値 = 1 - 4/15 ≈ 0.73
  • エージェント信頼度 90% → 単独処理すべき

ケースB — アカウント乗っ取りの疑い

  • エラー時の後処理コスト: £2,000 (不正損失、規制対応、離脱顧客)
  • エスカレーションコスト: £4
  • 閾値 = 1 - 4/2000 ≈ 0.998
  • エージェント信頼度 90% → 必ずエスカレーション

同じエージェント、同じ90%、正反対の正解です。0.9ルールは両ケースで単独処理を指示し、2番目のケースでチケットあたり£196を静かに燃やします。

コードで見るルール

# 教育用の例です。プロダクションコードではありません。
def should_act_alone(p_correct: float, error_cost: float, escalate_cost: float) -> bool:
    """
    Chowのrejection ruleに基づく判定。
    p_correctは必ずキャリブレーション済みの確率である必要があります。
    """
    threshold = 1 - (escalate_cost / error_cost)
    return p_correct > threshold

# ケースA: 通常の返金
assert should_act_alone(0.90, error_cost=15, escalate_cost=4) is True

# ケースB: アカウント乗っ取りの疑い
assert should_act_alone(0.90, error_cost=2000, escalate_cost=4) is False

関数の中に派手なものはありません。本当に重要なのは3つの入力値をどう選ぶかです。マジックナンバーが0.85か0.92かを巡って議論する時間は不要です。

Data analyst reviewing calibration chart comparing stated confidence versus actual accuracy of AI agent System Abstract Visual

罠1: キャリブレーション (Confidence ≠ Calibration)

上記の算術はすべて1つの仮定の上に立っています。エージェントが90%と言うとき、実際に90%当たるという仮定です。

これがキャリブレーションであり、confidenceとは違います。

  • Confidence: モデルが出力する数値
  • Calibration: その数値が実際に意味を持つかどうか

もしstated 0.95が実際には0.70なら? 期待エラーコストは算術の6倍です。そうして丁寧に計算した閾値はフィクションになります。リスクを管理しているのではなく、確率の顔をした数値でリスクを洗浄しているのです。

キャリブレーション確認の手順

  1. すべての意思決定をstated confidenceと共にロギング
  2. 決定クラスごとにconfidence bandで区間化
  3. 各区間でstated vs. realized accuracyを比較
  4. 90%と言って78%なら、そのギャップをマッピング (Isotonic regression または Platt scaling)

注意点2つ:

  • エージェントは稀で高リスクなクラスでキャリブレーションが最悪になりがちです。まさにそのクラスが極端な閾値を担っています。グローバル平均は重要な失敗を隠します。
  • チケットミックスが変わればマッピングもドリフトします。スケジュールに沿って再測定してください。

罠2: エスカレーションコストは見た目よりずっと高い

エスカレーションコスト ≠ 分 × 時給ではありません。

  • エスカレーションはキューに積まれ、キューは混雑します
  • さらに悪いことに、過剰エスカレーションはレビュアーをハンコ係に変えます
  • 1時間に通常の返金40件を送れば、1週間で誰も読まなくなります

すべてを承認する人間は統制装置ではなく儀式(ritual)です。 ボリュームが増えるほどこのギャップは広がります。

罠3: 人間も間違える

先ほど保留した仮定を出しましょう。専門家のエラー率をhとすると:

(1 - p) × ErrorCost  <  EscalationCost + h × ErrorCost

通常hは無視できるほど小さいですが、本当に曖昧なチケットではそうではありません。この場合、閾値はエージェント側に再び傾きます。意外と多くの人がここで驚きます。

Security engineer evaluating cost-based escalation threshold for account takeover detection in AI triage system

実務適用の手順 (5ステップ)

  1. 決定クラスのグループ化 — エラーコストが同程度のものをまとめる。返金は返金同士、セキュリティインシデントはセキュリティ同士。
  2. 各クラスに価格を付ける — エージェントを作った人ではなく、後始末をする人に聞いてください。 ファイナンスとサポートオペスの方がエンジニアリングよりこの数字をよく知っています。そして大抵、誰かが聞いてくれて喜びます。
  3. エスカレーションコストの推定 — 混雑とハンコ係効果を含めて。
  4. キャリブレーション済みの確率をルールに使用 — raw scoreではなく。
  5. クラス別閾値を導出、コストが動けば一緒に動くように — 新しい詐欺パターンが登場すればセキュリティエラーの価格が上がり、閾値も自動的に上がります。会議は不要。導出されたものであり、宣言されたものではないからです。

日本の開発現場における適用文脈

国内のSI・金融系環境では、このアプローチが特に重要です。なぜなら:

  • 監査要件のため「なぜこの判断をエージェントに任せたか」を説明する必要がありますが、「0.9を超えたから」は答えになりません。「エラーコストに対するエスカレーションコストが低いから」は答えになります。
  • 規制産業(金融、医療、公共)では、クラス別に閾値を変えることがコンプライアンス防御に有利です。
  • 逆に初期スタートアップではエスカレーションコストが事実上創業者の時間なので、比率が極端に低くなります。この場合、ほぼすべてをエージェントに任せるのが合理的です。

このアプローチの限界

正直に言うと:

  • コスト推定自体が難しい。 特に規制リスクやブランドリスクのように定量化が困難な項目は、数値にするのが苦痛です。
  • クラス境界が曖昧な場合が多い。「アカウント乗っ取りの疑い」と「通常のパスワードリセット」はスペクトラムです。
  • キャリブレーション測定コストが馬鹿になりません。特にロングテールクラスはサンプルが集まりません。

それでもこの手法の本当の利点は、議論の軸を変えることです。「0.85が正しい、0.92が正しい」という終わりのない争いの代わりに、「このエラーの価格はいくらか?」という答えられる問いに移行します。

次の学習ステップ

  • Learning to Defer 研究ライン (Chow 1970 → Geifman & El-Yaniv 2017 → 最新のselective prediction論文)
  • Calibration技法: Temperature scaling, Isotonic regression, Platt scaling
  • Cost-sensitive learning: クラス別コスト行列を学習に反映する方法

まとめ

「私のエージェントは単独行動する前にどれだけ自信があるべきか?」は答えられない問いです。仕様が不足しているからです。

「ここで誤った判断のコストはいくらで、聞くコストはいくらか?」は答えられます。

閾値を価格として設定してください。パーセンテージは自然に整います。

あわせて読みたい

本コンテンツは、信頼性の高い情報源をもとにAIツールを活用して作成され、編集者によるレビューを経て公開されています。専門家によるアドバイスの代替となるものではありません。