ローカル LLM Fusion と GPT-5.5 を同じ課題で比べた記録
ローカル LLM の単体モデル、Fusion Router、GPT-5.5 low / xhigh を同じ課題で測り、精度と待ち時間の差を整理した記録です。
比べた理由
ローカル LLM は、開発中の下読みや候補出しには使いやすい一方で、最終判断まで任せてよいかは別の問題です。
前回は Qwen、LFM JP、GLM、VibeThinker を常駐させ、Fusion Router の形で組み合わせるところまで試しました。
今回はそこに GPT-5.5 の low と xhigh を加え、同じ課題でどのくらい差が出るかを測りました。
そのあと、Fusion だけは改善版として追加測定しました。
前回の 6 課題全体と混ぜて順位を作るのではなく、重なっている 3 課題でどのくらい変わったかを見る形です。
見たかったのは、単純な勝ち負けではありません。 ローカル Fusion がどれくらい精度を上げるのか。 そのためにどれくらい待つのか。 そして、クラウドモデルを単体で呼ぶ場合と比べて、実務上どの選択が扱いやすいのかを確認することです。
測り方
評価には 6 つの小さな課題を使いました。 請求額の計算、JavaScript のバグ特定、要件矛盾の洗い出し、CSV の変換、日本語の制約付きコピー、並び順制約の問題です。
採点は別の LLM には任せず、課題ごとの機械的なチェッカーで行いました。 数値、並び順、文字数、必須語、禁止語、コード修正の形など、確認できる条件をスクリプトで見ています。 この形にしたのは、モデル同士の印象評価ではなく、少なくとも今回の課題では再計算できる比較にしたかったためです。
GPT-5.5 は Codex CLI の codex exec 経由で呼び出しています。
そのため、ここでの待ち時間には CLI の起動、認証、Codex 側の文脈読み込みも含まれます。
純粋な API レイテンシではなく、実際にこの開発フローで使う場合の操作上の待ち時間として見ています。
レートリミットで途中停止しても再開できるように、ベンチスクリプトには --resume を追加しました。
1 つのモデル呼び出しが終わるたびに JSON を保存し、次回は成功済みの結果を再利用します。
今回のようにクラウドモデルを含める測定では、この仕組みがないと途中停止時の再実行コストが大きくなります。
改善版の追加測定では、請求額の計算、日本語の制約付きコピー、並び順制約の 3 課題だけを見ています。 前回の 6 課題平均との差とは直接比較せず、同じ 3 課題に限って旧 Fusion Router と比べます。
結果
今回の実測では、Fusion Router が最も高い平均スコアになりました。
| パターン | 平均スコア | 平均待ち時間 | 未満点の課題数 |
|---|---|---|---|
| Router Fusion: Qwen judge analysis + Qwen outer over all | 0.933 | 104秒 | 2 |
| GPT-5.5 low | 0.842 | 13秒 | 3 |
| GPT-5.5 xhigh | 0.767 | 16秒 | 3 |
| Qwen3.6 27B | 0.667 | 23秒 | 2 |
| GLM-4.7-Flash | 0.483 | 10秒 | 5 |
| LFM JP | 0.300 | 5秒 | 5 |
| VibeThinker 3B | 0.000 | 17秒 | 6 |
Fusion Router は、最良の単体モデルだった GPT-5.5 low に対して平均スコアで +0.091 上回りました。
一方で、平均待ち時間は 104秒 で、GPT-5.5 low の約 7.93倍 でした。
この差は大きいです。 精度を少しでも上げたい課題では意味がありますが、普段の下読みや軽い確認に常用するには重いと感じます。
改善版の追加測定
改善版 Fusion Router は、追加測定した 3 課題では平均スコア 1.000 でした。
同じ 3 課題に絞ると、前回の Fusion Router は平均 0.900 だったため、差分は +0.100 です。
未満点の課題数は 1 から 0 になりました。
| 比較対象 | 対象課題 | 平均スコア | 平均待ち時間 | 未満点の課題数 |
|---|---|---|---|---|
| 前回 Fusion Router | 3 | 0.900 | 130秒 | 1 |
| 改善版 Fusion Router | 3 | 1.000 | 85秒 | 0 |
| 直接 Fusion: Qwen over all | 3 | 0.867 | 18秒 | 1 |
| Best-of-N: Qwen judge over all | 3 | 0.867 | 18秒 | 1 |
この追加測定だけを見るなら、改善版は良くなっています。 ただし、これは 6 課題全体を測り直した結果ではありません。 「Fusion Router が常に満点になった」ではなく、「前回と共通する 3 課題では、未満点だった 1 課題を潰せた」と読むのが妥当です。
課題ごとの内訳は次の通りです。
| 課題 | 前回 Fusion Router | 改善版 Fusion Router | 差分 |
|---|---|---|---|
| 請求額の計算 | 1.000 | 1.000 | +0.000 |
| 日本語の制約付きコピー | 0.700 | 1.000 | +0.300 |
| 並び順制約 | 1.000 | 1.000 | +0.000 |
改善幅のほとんどは、日本語の制約付きコピーから来ています。
前回の Fusion Router は、必須語と禁止語の判定はおおむねできていましたが、最終回答が 90〜110 文字の条件を外しました。
出力は 58 文字で、チェッカー上は 0.700 に止まっています。
改善版では、同じ課題で 98 文字の回答を出し、必須語の 還元、自律的なAIエージェント、個人の技術ラボ を含め、禁止語も避けました。
そのためスコアは 1.000 になりました。
主要因は、候補の多数決ではなく、最終回答の検証が実際に効いたことです。
直接 Fusion と Best-of-N は、同じ 3 課題で 0.867 に止まりました。
請求額の計算で、正しい 12,826 円には触れているのに、途中に誤った金額が残って減点されています。
一方の Fusion Router は、候補をそのまま合成せず、まず judge が構造化した分析だけを返し、outer が元の課題に戻って最終回答を書く形です。
この分離が、候補の誤答や監査ログを最終回答へ混ぜにくくしています。
もう 1 つ大きいのは、外側の Qwen が「文字数、必須語、禁止語」を明示的に再確認した点です。 前回も同じ構造ではありましたが、最終回答で文字数確認が空振りしました。 改善版ではここが通ったため、スコア差として見える形になりました。 つまり、改善の正体はモデル数を増やしたことではなく、最終回答を作る段階で検証対象を絞り直せたことです。
課題ごとの見え方
請求額の計算では、Qwen 単体は失敗し、GPT-5.5 low / xhigh と Fusion Router は満点でした。 並び順制約では、Qwen 単体が失敗し、Fusion Router と GPT-5.5 xhigh は満点でした。 このあたりは、複数候補を見比べる Fusion の強みが出ています。
一方で、日本語の制約付きコピーでは、Fusion Router も GPT-5.5 も文字数条件を外しました。 平均スコアでは差が出ても、文字数のような機械的条件では、モデルの自信よりチェッカーを優先する必要があります。 これはローカルでもクラウドでも同じでした。
改善版の追加測定では、この日本語コピーの失点だけが解消されました。 そのため、Fusion Router の弱点が完全になくなったというより、外側の最終回答フェーズで検証が機能した時は、制約付きコピーでも満点まで届くと見た方がよさそうです。 逆に言えば、文字数のような条件はまだモデル任せにしない方がいいです。 本番の文章生成で使うなら、生成後に文字数と必須語を deterministic にチェックし、落ちた時だけ再生成する方が安定します。
GPT-5.5 xhigh が常に low より良いわけでもありませんでした。 今回の小さな課題セットでは、GPT-5.5 low の方が平均スコアは高くなりました。 推論 effort を上げれば必ず正解に近づく、という見方はしない方がよさそうです。 課題の種類、出力制約、採点方法との相性があります。
実務での使い分け
今回の結果だけで決めるなら、普段の候補出しや軽い確認では GPT-5.5 low が扱いやすいです。 待ち時間が短く、平均スコアも単体モデルの中では最も高くなりました。
ローカル Qwen は、クラウドへ出したくない下読みや、小さなレビュー候補の生成に向いています。 ただし、今回の課題では算術や制約問題で落としたため、最終判断役にはしません。 検証可能な条件はスクリプトやテストで確認します。
Fusion Router は、待てる場面だけに絞るのがよさそうです。 たとえば、候補同士が補完し合う課題、失敗時のコストが高い判断、複数観点を比較したいレビューでは使う価値があります。 逆に、毎回の軽い確認で使うには遅すぎます。
改善版の結果を入れても、この使い分けは変わりません。
3 課題では 85秒 まで短くなりましたが、直接 Fusion や Best-of-N の 18秒 と比べるとまだ重いです。
その代わり、誤った途中値や短すぎるコピーを最終回答から落とせる可能性は上がります。
待ち時間を買ってでも最終回答の品質を上げたい時だけ使うのが現実的です。
今後の扱い
このベンチは、モデルの絶対的な能力を決めるものではありません。 課題数は 6 件で、プロンプトもこの開発フロー向けに固定しています。 それでも、実務で使う道具としては十分に判断材料になります。
次に試すなら、固定の全モデル Fusion ではなく、課題に応じて呼ぶモデルを変える conductor 型のルーティングです。 算術や JSON 変換では先に決定的な処理を走らせる。 日本語の曖昧さは LFM JP で整える。 コードや要件の違和感は Qwen と GLM に分けて見てもらう。 そうした小さな分岐を入れる方が、毎回大きな Fusion を回すより実務に合いそうです。
今回分かったことはシンプルです。 Fusion Router は確かに精度を上げました。 改善版の追加測定では、前回失点していた日本語制約コピーも満点まで戻しました。 ただし、その精度差には大きな待ち時間がつきます。 普段は小さく呼び、必要な場面だけ重くする。 ローカル LLM も GPT-5.5 も、その使い分けを前提に組み込むのがよさそうです。