安いモデルは「知らないこと」を自覚できない
安いモデルで下書きし、自信がないときだけ高いモデルに回す。よくある設計です。 私たちもそれを本番の既定にしていました。182問で測ったら、間違える設問の97%でモデルは「自信あり」と申告していました。 エスカレーションは一度も起きていなかった。
1. 自己申告は機能しない
teai.io の shitate/orchestrator は、安いモデル（DeepSeek V4 Flash）にまず解かせ、
モデルが「自信がない」と申告したときだけ強いモデル（Claude Sonnet 5）に回す設計でした。
安く済み、難しい問いだけ高い経路に載る — そのはずでした。
タスク型別に測ると、崩れているところがありました。
| タスク型 | n | 正答率 |
|---|---|---|
| 計算（式に必要な数値が設問文にある） | 94 | 92.6% |
| 知識（言語仕様・SQLの挙動） | 30 | 96.7% |
| 表参照（表が設問文に載っている） | 41 | 68.3% |
| 記憶（法令が定める固有値を思い出す） | 17 | 62.7% |
記憶を要求する設問だけが落ちています。中身を見ると、労働基準法39条の年次有給休暇の付与日数を、 継続勤務年数にかかわらずほぼ全問「10日」と答えていました。 0.5年なら10日で正解ですが、3.5年なら14日、6.5年なら20日です。
ではエスカレーションはどうなっていたか。落とす設問58問で数えました。
安いモデル素で 39/58 67.2% 安いモデル+自己申告 38/58 65.5% エスカレーション最終 38/58 65.5% エスカレーション発火 2/58 = 3%
間違える設問の97%で、モデルは「自信あり」と申告していました。 だから一度も上がらず、高い経路は使われず、余計なコストだけが乗っていた。
途中で立てた仮説は外れました
最初は「自信を申告させる指示が、本題の指示（1円未満切り捨てなど）を薄めて回答を壊している」と考えました。 同じモデル・同じ設問で指示の有無だけを変えて測ると、91.7% → 95.0% で劣化していません。仮説が間違っていました。 真因は劣化ではなく、発火しないことでした。
聞き方を変えても直りません
「自信があるか」ではなく「記憶に頼って答えたか」と聞けば自覚できるのではないか。そう考えて変えてみました。 計算系は全面的に改善し（経理 94.2→98.6%、法務 92.9→97.6%）、しかもコストは半分になりました。 ところが記憶設問は 50.0% → 52.4% でほとんど動きません。
介入で動くのは振る舞いであり、無い知識は動かない。
2. 質問を分類すれば、94%発火する
この結果を Claude（Fable 5）に相談したとき、問いの立て方そのものを言い換えられました。
「この答えを知っているか?」はモデルに聞けないが、
「この質問は暗記知識を要求しているか?」は答えを知らなくても判定できる。
判定の対象を、自分の答え（内省）から質問の性質（観測）へ移す。
モデルには最初の行に TYPE: recall（設問文に無い固有値の想起が要る）か
TYPE: derive（設問文の情報だけで決まる）を書かせ、recall のときだけ上げます。
| タスク型 | n | 質問分類で上げる | 自己申告で上げる |
|---|---|---|---|
| 記憶（法令の固有値） | 17 | 94% | 0% |
| 計算 | 94 | 0% | 4% |
| 表参照 | 41 | 41% | 0% |
| 知識（仕様） | 30 | 33% | 0% |
必要なところで上がり、不要なところで上がらない。 純粋な計算では一度も上げないので、安い経路の利点はそのままです。 表参照と仕様で上がるのは過剰で、ここはコストが増えるだけ（精度は落ちない）。改善余地として残っています。
この指標を選んだのには理由があります。正答率ではなく判定の発火率なので、 後述する測定の揺れの影響を受けません。
3. 根拠を渡せば、問題そのものが消える
評価セットには仕掛けを入れてありました。同じ問いを「根拠の表あり」と「表なし」でペアにしてあるのです。 差がそのまま「知識の欠落の大きさ」になります。
| 戦略 | 表なし（記憶） | 表あり（読解） | 差 |
|---|---|---|---|
| 安い＋自己申告 | 62.7% | 100.0% | +37.3pt |
| 安いモデル単体 | 80.4% | 100.0% | +19.6pt |
| Claude Sonnet 5 | 90.2% | 100.0% | +9.8pt |
| 強いモデル5本＋審議（$8.24） | 100.0% | 100.0% | ±0 |
51問中51問、例外なく100%。 $8.24 かけて5本振って得られる100%を、$0.014 のモデルが出します。
ただし本物の条文では100%に届きません
上の表は私たちが整形したものです。e-Gov 法令API から本物の条文を原文のまま注入して測り直しました。
| 設問 | n | 条文なし | 条文あり（原文） |
|---|---|---|---|
| 年次有給休暇 | 21 | 14.3% | 71.4% |
| 法定労働時間 | 18 | 100.0% | 100.0% |
| 割増率 | 12 | 100.0% | 91.7% |
条文を読むと、なぜ整形済みの表（100%）に負けるのか分かります。
第三十九条 …十労働日の有給休暇を与えなければならない。 継続勤務年数一年ごとに、前項の日数に、次の表の…労働日を加算した… 一年 → 一労働日 ／ 二年 → 二労働日 ／ …
法定表は総日数ではなく加算日数を、漢数字で書いています。 モデルは「10日＋加算」を自分で計算する必要がある。
そして割増率は注入すると悪化しました（100% → 91.7%）。 労基法37条は「二割五分以上五割以下の範囲内でそれぞれ政令で定める率」としか書いておらず、 実際の25%・35%は政令にあります。モデルは記憶では知っていたのに、答えの載っていない条文を渡されて迷いました。
ここまでの結論
- 自己申告は使えない。判定対象を質問の性質に移すと機能する
- 根拠を渡せば「知らない」問題は消える。ファインチューニングの出番はない（無い知識は追加学習より参照で入れる方が速く確実）
- 素朴なRAGでは足りない。価値は条文から導出して人が検証した参照表にある
- 検索が間違った文書に当たると逆効果になる
4. 正直に言っておくべきこと — 測定そのものが揺れます
この調査の途中で、無視できないことに気づきました。 同一58問・同一モデル・temperature 0 で3回測った正答率です。
1回目 67.2% 2回目 93.1% 3回目 82.8%
n=58 の二項標準誤差は約5ポイントなので、この幅は偶然では説明できません。 空応答もAPIエラーも0件でした。原因は未特定です （同じ設問を30回投げると30回とも同一の正答を返すものもあり、設問によって性質が違います）。
つまりこの記事で戦略間の細かい順位を主張することはできません。 上で示した数字のうち、この揺れを超えて成立しているのは 「エスカレーション発火率 3% vs 94%」と「根拠を渡すと51/51で100%」の2つです。 どちらも正答率の微差ではなく、桁が違う差です。
LLMベンチマークを読むとき、反復回数と振れ幅が書かれていない順位表は、 そもそも順位を主張できていない可能性があります。私たち自身がそうでした。
揺れの中身を見ると、もっと悪い話がありました
18問を12回ずつ投げて、答えが何種類出るかを数えました。
| 設問 | 答えの種類 | 多数派 | 正答 |
|---|---|---|---|
| 税込計算（6問すべて） | 1 | 100% | 12/12 |
| 営業日計算・祝日あり | 1 | 100% | 0/12 |
| 年次有給休暇 | 1 | 100% | 0/12 |
決定的な設問は 13/18（72%）。安いモデルはランダムに間違えているのではありません。 確信を持って、一貫して、同じ間違いをします。祝日込みの営業日計算では12回中12回とも1日ずれました。
これは対策の選択を変えます
同じモデルを複数回振って多数決を取る方式（self-consistency）は、この失敗には一切効きません。 12回振っても12回同じ誤答が返るだけです。 「安いモデルを何度か振って一致したら採用」という設計は、 ランダムな取りこぼしには効きますが、体系的な誤りには無力です。 そして安いモデルの失敗の多くは後者でした。
5. ベンチマークが知識を罰していた
最後に、自分たちの評価セットに見つけた欠陥を書いておきます。 当初、こういう設問を作っていました。
報酬1,234,567円について、税率10.21%で源泉徴収税額を求めてください。 → 正解（当初）: 126,049
実際の源泉徴収は100万円を超える部分が20.42%の二段階です。正しくは149,998円。 制度を正しく知っているモデルほど不正解になる設問でした。
単段の設問は100万円以下に限定し、二段階はルールを設問文で完全に指定する形に直しました。
同じ欠陥がもう1件、高いモデルが教えてくれました
「$14の高コスト戦略が、$0.014の最安モデルに負ける」という逆転を見つけて色めき立ったのですが、 中身を見たら私たちの負けでした。
設問: 時給1450円 × 9時間 × 割増率25% 私たちの正解: 16312 （1450×9×1.25 = 16312.5 を単純に切り捨て） 強いモデル: 16317 「時間外単価 1450×1.25 = 1812.5 → 50銭以上切上げで1,813円 （昭和63.3.14 基発150号の端数処理）、1,813円 × 9時間 = 16,317円」
実務では時間単価の端数を先に処理します。そもそも私たちの設問は端数処理を一切指定していませんでした （答えが16312.5 と小数になるのに）。実務を知っているモデルが根拠つきで正しく答え、不正解と数えられていた。
計算順序と端数処理を設問文で完全に指定する形に直しました。 自動生成した設問は速く量産できますが、正解が現実と食い違っていないかは別に確かめる必要があります。 そして食い違いは、たいてい賢いモデルが落とした問題として現れます。 モデルが間違えたと思ったら、まず自分の正解を疑ったほうがいい。
この結論を、そのまま使えるようにしました
訂正（公開後に追記）
この節では当初 :verify（安く作って強く直す）を「費用対効果の最適点」として推していました。
公開後に追加検証したところ、その根拠が崩れたので撤回します。
下書きを外して同じプロンプトで比べると、下書きは精度に寄与していませんでした（むしろ下がった）。
詳細は下に残します。間違ったまま宣伝しないために、消さずに訂正します。
測って分かったことを全部入れた結果が、いまの既定です。やっていることは2つだけです。
- 質問を分類する — 設問文に無い固有値の想起が要るなら強いモデルへ、そうでなければ安いまま
- 数えるものは列挙させる — 一発で答えさせず、1件ずつ書き出させる（途中経過は返す前に剥がす）
| タスク型 | 安いモデル単体 | 本番構成 | 差 |
|---|---|---|---|
| 知識（言語仕様・SQL） | 96.7% | 100.0% | +3.3pt |
| 計算 | 92.0% | 100.0% | +8.0pt |
| 表参照（祝日込みの営業日計算など） | 73.2% | 98.8% | +25.6pt |
| 記憶（法令が定める固有値） | 61.8% | 97.1% | +35.3pt |
| 合計 | 85.7% | 99.5% | +13.8pt |
182問を2回まわした実測。強いモデルを使うのは全体の23%だけ。
比較のために書いておくと、強いモデル単体は 96.3% で $0.62、この構成は 99.5% で $0.186 です。 精度で上回り、3.3倍安い。安いモデルを主役にして、必要なときだけ上げるとこうなります。
表を渡しても使えなかった問題を、どう詰めたか
この記事を最初に公開した時点では、表参照は 68.3% のまま残っていました。 表が設問文に載っているのに解けないという、 「根拠を渡せば解決する」という結論に対する明確な反例です。
祝日込みの営業日計算で、安いモデルは12回中12回とも同じように間違えていました（正答率 0.0%）。 正解との差を数えると 24/36 件が「1日早い」。祝日を1つ数え落として早く到達しているパターンです。
| 表の渡し方 | 正答率 |
|---|---|
| A 現行（祝日17件を並べて渡す） | 0.0% |
| B 関係する祝日だけに絞る | 8.3% |
| C 祝日に曜日を付ける | 0.0% |
| D 1日ずつ列挙させる | 100.0% |
| E カレンダーを作って渡す | 100.0% |
表を絞っても曜日を付けても効かず、列挙させることだけが効きました。
安いモデルは表を使えないのではなく、一発で数えようとして落としていたのです。
途中経過は <work> の中に書かせて、利用者に返す前に剥がしています（平均出力52字）。
上げ先も実測で選びました
「強いモデル」を何にするかで、記憶設問の結果はかなり変わります。 記憶設問だけで11モデルを総当たりしました（17問 × 5回 = 935コール）。
| モデル | 記憶（法令の固有値） | カタログ単価 |
|---|---|---|
| Claude Fable 5 | 100.0% | $10 / $50 |
| Gemini 3.1 Pro（採用） | 100.0% | $1 / $6 |
| GPT-5.6 sol | 95.3% | $2.50 / $15 |
| Claude Sonnet 5（従来の上げ先） | 92.9% | $3 / $15 |
| Sakana Fugu Ultra | 89.4% | $5 / $30 |
| Qwen3.5 397B | 47.1% | $0.39 / $2.34 |
Fable 5 と Gemini 3.1 Pro が同率100%。単価が1/10の Gemini を採りました。 1段目の DeepSeek とベンダーが違うので、見落としの傾向が重なりにくいという理由もあります。 従来の Sonnet 5 に対しては精度が高く単価も安いので、変えない理由がありませんでした。
Qwen3.5 の 47.1% は、日本の法令固有値に関しては使えないという意味です。 一般的なベンチマークの順位と、この種の設問の順位は一致しません。
値下げしました
この構成の実費を計算し直したところ、それまでの価格（$3 / $9 per 1M）は取りすぎでした。 $0.57 / $3.24 に下げました。 全リクエストが上げ先に回る最悪ケースでも原価割れしない水準です。 将来モデルを差し替えたときに取りすぎ・原価割れの両方を検知するテストも入れてあります。
撤回した主張について
当初、:verify（安いモデルの下書きを強いモデルに検証させる）が
99.5% を $1.04 で出し、5本合議（99.6%・$14.15）の 1/13.6 のコストで並ぶ、と書きました。
公開後、下書きが本当に効いているのかを確かめました。
強いモデル(素のプロンプト) 56/58 96.6% 強いモデル(丁寧なプロンプト・下書きなし) 56/58 96.6% 丁寧なプロンプト + 下書きあり 55/58 94.8%
下書きは効いていません。むしろ下書きを見せると下がりました。 実際、本番で試すと下書きに引きずられます。
税込33,333円(消費税8%)の税抜金額 — 正解 30864 :verify → 30863 (安いモデルの下書きをそのまま通した) 強いモデル単体 → 30864
一方、182問のベンチマークでは検証つきが記憶設問で 97.1%、強いモデル単体が 88.2% でした。 2つの測定が矛盾しています。 この記事の後半に書いたとおり、私たちの測定は同一条件でも ±13ポイント振れます。 この精度では決着できないので、「verify が最適点」という主張は取り下げます。 モード自体は残していますが、強いモデル単体より良いという根拠は今のところありません。
使い方
# OpenAI互換 — 既定で質問分類による振り分けが効きます
curl https://teai.io/v1/chat/completions \
-H "Authorization: Bearer $TEAI_API_KEY" \
-d '{"model":"shitate/orchestrator","messages":[...]}'
# Claude Code もそのまま
ANTHROPIC_BASE_URL=https://teai.io \
ANTHROPIC_AUTH_TOKEN=$TEAI_API_KEY \
claude --model shitate/orchestrator
どう束ねたかは x-teai-orchestrator ヘッダに必ず出ます
（mode=cascade; calls=1; escalated=false）。
裏で何が起きたか分からない自動処理にはしていません。
使ったもの
- 評価セット182問。正解はすべてPythonで計算して確定（手で書いた正解は使わない）
- タスク型で層化：計算94 / 表参照41 / 記憶17 / 仕様30
- 17ペアの「根拠あり／なし」対照
- 全モデルを teai.io の同一エンドポイント経由で呼び、束ね方だけを変えて比較
- ベンチマーク実行の総額 $32.91（13,324コール）
teai.io は360モデルを一つのAPIから使えるゲートウェイです。
OpenAI互換／Anthropic互換の両対応で、Claude Code は base_url の変更だけで動きます。