信頼度ゲーティングと人へのエスカレーション

前のページは「しきい値はコードが持つ」という話でした。このページは、 そのしきい値が分けるもの —— 両側にできる三つの帯の話です。

二段ではなく三段

実プロジェクトで「自動かそうでないか」の二択はほとんど見かけません。三段が標準です。

三つ目の帯は見落とされがちで、三つの中で最も安い帯です。 「見ない」と「人が一度見る」の差は、人一人分です。

あるトリアージツールの実装が典型的です。P(SEV1) + P(SEV2) ≥ 0.80 のときだけ 人を呼び、「実行可能性」の判定も反対しているときに限り 0.20 未満で破棄し、 中間帯は人に渡します。

本当の問題は中間帯にある

三段に分けた瞬間、難しい問いはすべて真ん中に集まります。

それは人手であって、余剰能力ではありません。 帯が広いほどエスカレーションが増え、 人が処理する量が増えます。9% という数字は低く見えますが、母数が 1 日数千件なら そうではありません。

フェイルセーフがなければ、静かに詰まります。 人に渡した瞬間、誰かが見るまで 何も起きません。そしてダッシュボード上では「すべて正常」と見分けがつきません。 先のツールの答えは明快です。15 分以内に ack がなければ、それでも人を呼ぶ。 P1 を待ち行列に置き去りにするより、人を起こす方がましです。

エスカレーション条件そのものも壊れます。 agent 内の自律度ゲートは 「Choice が 0.6 を超え、かつ自律安全の Noul が 0.5 を超えるときだけ続行」し、 それ以外はターンを人間に返します。両方を通す必要があるのは、 「何をすべきか」と「これは安全か」が別の問いであり、一つの信頼度で両方に 正直に答えることはできないからです。

しきい値の決め方：まず測る

0.8 を思いつきで決めるのが最も一般的で、三か月後にノイズになる可能性が最も高い やり方です。再現可能なやり方は、自分のラベル付きデータで、目標精度に必要な しきい値を測ることです。

公開されている例を一つ。0.7 を低信頼のゲートとしたとき、n=130 のサンプルで 9% のエスカレーション率のもと、誤判定 3 件のうち 3 件すべてを捉えました。 サンプルは小さい。価値は 0.7 という数ではなく、こういうふうに数字を報告する という点にあります。サンプル数、エスカレーション率、そして何を捉えたか。

遅延は過小評価されがちなリスク

先のトリアージツールの実測値は、独立して見る価値があります。

p95 は p50 の 3.5 倍です。つまり平均より裾の方がずっと重要です —— タイムアウト方針は裾で発火し、発火した時点で走るのは設計した分岐ではなく フォールバックだからです。最遅の呼び出しがタイムアウトまで 151 ms だったというのは、 このシステムの決定性が、たまたま外れなかったコインに依存していたことを意味します。

ゲートシステムの失敗は「判断を誤った」ではなく、タイムアウトして フォールバックに落ちたという形で起きます。フォールバック経路は、 主経路とは別に試験してください。

二つのフォールバック方向、どちらも正しい

エラー時にどうするかについて、公開されている実装は二派に分かれます。そして両方が正しい。

• fail-closed（エラーなら拒否）：ある権限判定器は、タイムアウトやエラーで そのまま deny します。安全ゲートはこうでなければなりません —— fail-open の安全ゲートは静かな穴です。
• fail-open（エラーなら許可）：ある Claude Code の Stop フックは、 いかなるエラーでも許可します。効率ゲートはこうでなければなりません —— fail-closed の効率ゲートはフロー全体を止めます。

判断基準は「どちらが安全か」ではなく、誤って止めるコストと誤って通すコストの どちらが大きいかです。そしてこれはコードを書く時点で決める必要があります。 決まるのは例外経路であって、主経路ではないからです。

一文で

三段構造の工作量は真ん中の帯に集中します。その広さはコストであり、 そのフェイルセーフは信頼性です。 どちらも既定値に任せず、明示的に設計してください。