複数LLMを比較して安い方へ流す時、品質ゲートを嘘つきにしない作り方

これは何か

「分類はA社、生成はB社、コードはC社」のようにタスク種別ごとに安いLLMへ振り分けると、コストは大きく下がる。 その判断を支えるのがゴールデンタスクによる成功率の実測だが、この計測は放っておくと必ず楽観側へ壊れる。

この指示書は、複数プロバイダの成功率を比較して自動でルーティングを推薦する仕組みを作る時に、 **「安くする判断を、過大な品質評価が承認してしまう」**のを防ぐための設計と検証手順を示す。

実際に運用中の仕組みで、3つのプロバイダが過大報告されていた事例を一般化したもの。

前提

• 5〜20問程度のゴールデンタスク（カテゴリ別に数問ずつ）を用意している
• 複数プロバイダへ同じ問題を投げ、LLM-as-a-judge か決定的な照合で採点している
• その結果からカテゴリごとの推奨プロバイダを自動で決めている

設計

1. 成功率の分母は「試行数」にする（最重要）

最も踏みやすい罠。採点できた件数を分母にすると、エラーや切断で脱落した問題が分母から消え、 大半を完了できないプロバイダほど高得点に見える。

悪い: rate = pass / graded     ← エラーは分母から消える
良い: attemptedRate = pass / n ← 試行した全件が分母

実例（同一の15問セット）:

プロバイダ	pass/graded の表示	実態 pass/n	内訳
P社 flash	100.0%（表の最上位）	0%	全件が429（無料枠クォータ切れ）
Q社 9b	100.0%	13.3%	出力切断13件
Q社 flash	80.0%	26.7%	出力切断10件

既に pass/graded で履歴を蓄積している場合、定義を変えずに試行ベースの率を併記する。 過去との比較が壊れるので、既存の指標は消さない。

2. 「計測不能」という区分を作り、点数に関わらず推薦から外す

成功率の高低とは独立に、完走できたかどうかで足切りする。

(errors + truncated) / n > 0.10  →  計測不能。順位に関わらず推薦候補から除外

「良い点だが大半が完走していない」は良い結果ではない。 表示上は警告アイコンを付けるだけでなく、 推薦を生成する関数の側で確実に除外すること。表示だけの警告は、自動推薦の経路では読まれない。

3. 問題ごとの内訳を保存する

カテゴリ単位の集計しか保存していないと、どの問題が落ちたかを後から追えない。 結果レコードに {id, category, pass, status} の配列を持たせる。 status は pass / fail / error / truncated を区別する（エラーと不正解を同じ扱いにしない）。

4. 全滅した問題は「対象」ではなく「問題」を疑う

参加プロバイダの半数以上が落とした問題は、モデルの優劣ではなく設問か採点基準が壊れている可能性が高い。

その問題を推薦の根拠から除外し、「設問または採点基準が疑わしい」と警告する

これをやらないと、たまたま採点者の期待に一致した1つを「このカテゴリの勝者」として選んでしまう。 実例では、ある返信文生成の問題を7社中6社が落としており、隔離した結果そのカテゴリの推薦先が実際に変わった。

5. 無料枠は「成功と失敗の間」ではなく「成功と沈黙の間」で壊れる

無料枠のAPIはクォータを使い切ると 429 を返すだけで、何も言わずに結果が減る。 リトライを実装していると、リトライ後の最終エラーだけが記録されて件数がさらに見えにくくなる。 エラー件数と、その内訳（HTTPステータス）を必ず結果に残す。

検証（ここまでやって初めて信用してよい）

1. 合成データの単体テスト: エラー率が閾値を超えるプロバイダが「計測不能」に分類され、 推薦関数の戻り値に現れないことを検証する。表示のテストだけでは不十分
2. 実データでの端から端まで: 実際のログに対してレポートを出し、 過大報告されていたプロバイダが除外されること・推薦が実際に変わることを目で確認する
3. 同一条件の2回計測: 1回では判断しない。実例では同じプロバイダが同日2回の計測で 93.3% → 66.7% と振れた。1回の計測は安定した根拠にならない

運用上の原則

• 安くする変更は「品質が落ちていない実測」とセットでのみ採用する。 実測が無い節約案は提案止まりにする
• 計測が古くなると、実測を根拠にしていたはずの判断が惰性に変わる。 最終計測日からの経過日数を監視し、一定日数で警告を出す
• 推薦を自動で他システムへ流し込んでいる場合（設定ファイル生成、エージェントへの指示注入など）、 その経路の先で誰が何を決めているかを把握しておく。 過大な推薦は、人が表を見て気付く前に自動で採用されてしまう
• 他ドメインのベンチマーク結果を、自分のドメインの判断へ横流ししない。 「保険金査定10問で品質を維持したまま65%安くなった」は、 設計や横断調査を含むタスクで同じ結論になる保証にはならない