TL;DR
- 汎用ベンチマークのスコアで LLM を選ぶのは危険
- コード生成1位のモデルが、Agentic RAG では8位に転落する
- Thinking/Reasoning モードは万能ではなく、タスクによって逆効果になる
- タスクごとに最適モデルを組み合わせたらコスト79%削減 & 品質3%p向上を達成
- GPT の Reasoning モードは空応答率21〜23%でプロダクション使用に要注意
はじめに
「MMLU で○○%」「HumanEval で1位」——こうしたベンチマークスコアを見てモデルを選んでいませんか？
私たちは QueryPie AI の開発チームです。最近私たちが進めたAX (AI Transformation) プロジェクトにおいて、日本の給与システムという、複雑な社会保険制度・年末調整・住民税特別徴収が絡む専門ドメインで、エージェントを作成するためにLLMを活用しています。
今回のプロジェクトを進めるにあたり、エージェントの役割に応じて、コスト／性能が最適化されたモデルを見つけるために、Anthropic（Claude）・Google（Gemini）・OpenAI（GPT）の 13モデル構成を、実際のプロダクションパイプラインで比較評価しました。
結論から言うと、汎用ベンチマークの順位と実タスクの順位は全然違いました。
本記事はその検証レポートです。
検証環境
対象システム：AI Check
AI Checkとは、給与担当者が自然言語（日本語）で記述した給与検査観点（CheckPoint）を、実行可能なSQLクエリへ自動変換するシステムです。ユーザーが複雑なSQL文法を知らなくとも、自然言語で検査条件を記述すれば、当該条件に合致する対象者をデータベースから抽出できるようにします。
対象データベースは300以上のテーブル、1,350以上のカラムで構成されており、カラム名は FPPAR03, FRPAP15 のような内部コード（MFID）形式です。LLMが自然言語から直接正確なSQLを生成するのは困難なため、問題を3段階に分離するパイプライン設計を採用しています。
自然言語（日本語）
↓ [Stage 1] NL to Pseudocode Agent（コード生成）
CTE形式の擬似コード
↓ [Stage 2] MFID Mapping Agent（Agentic RAG）
MFID がマッピングされた擬似コード
↓ [Stage 3] Query Translation Agent
実行可能 SQL
今回の評価対象は Stage 1（コード生成） と Stage 2（Agentic RAG） です。
評価対象モデル（13構成）
| プロバイダー | モデル | Think/Reasoning |
|---|---|---|
| Anthropic | Claude Haiku | 基本 / Extended Thinking |
| Claude Sonnet | 基本 / Extended Thinking | |
| Claude Opus | 基本 / Extended Thinking | |
| Gemini 3 Flash | 基本 / Thinking | |
| Gemini 3 Pro | 基本 / Thinking | |
| OpenAI | GPT-5.2 | 基本 / Reasoning |
| GPT-5 Mini | 基本のみ |
データセット
| タスク | サンプル数 | 内容 |
|---|---|---|
| コード生成 | 175件 | 自然言語 → CTE 擬似コード変換 |
| Agentic RAG | 93件 | ドメイン用語 → MFID マッピング |
評価指標
コード生成：
- 伝統的指標：BLEU、ROUGE-L、BERT-F1
- LLM-as-a-Judge（GPT-4）：構文正確性・意味等価性・条件完全性・構造的類似性の4次元×5点 = 20点満点
Agentic RAG：
- Recall@K、MRR（Mean Reciprocal Rank）
- ツール呼び出し効率性
結果①：コード生成タスク
品質ランキング（LLM-as-a-Judge 基準）
| 順位 | モデル | スコア |
|---|---|---|
| 1 | Claude Sonnet（Think） | 67.3% |
| 2 | Claude Sonnet | 66.1% |
| 3 | Claude Opus | 65.9% |
| 4 | Claude Opus（Think） | 65.4% |
| 5 | Gemini 3 Pro（Think） | 65.1% |
Claude が上位を独占。GPT 勢はこのタスクでは下位に沈みました。
Thinking モードの効果
| モデル | 基本 → Think | 変化 |
|---|---|---|
| Claude Sonnet | 66.1% → 67.3% | +1.2%p ✅ |
| Gemini 3 Pro | 64.0% → 65.1% | +1.1%p ✅ |
| Claude Haiku | — | -1.8%p ❌ |
| GPT-5.2 | — | -10.6%p ❌❌ |
GPT-5.2 の Reasoning モードで -10.6%p は衝撃的でした。 Thinking = 常に良い、ではありません。
空応答率（プロダクション観点で最重要）
| モデル | 空応答率 | 判定 |
|---|---|---|
| Claude 全モデル | 0% | ✅ プロダクション OK |
| Gemini 全モデル | 0% | ✅ プロダクション OK |
| GPT-5.2 | 2.3% | ⚠️ 注意 |
| GPT-5.2（Reasoning） | 21.1% | ❌ プロダクション不可 |
| GPT-5 Mini | 23.4% | ❌ プロダクション不可 |
品質スコアがどれだけ良くても、5回に1回応答しないモデルは使えません。タイムアウト300秒でこの結果です。
コスト効率性
| モデル | 1Kリクエストあたりコスト | 品質 | 効率性 |
|---|---|---|---|
| Gemini 3 Flash | $16.13 | 61.7% | 3.83点/$ |
| Gemini 3 Pro（Think） | $75.56 | 65.1% | 0.86点/$ |
| Claude Sonnet（Think） | $133.00 | 67.3% | 0.51点/$ |
コスパ最強は Gemini 3 Flash。品質差5.6%pに対してコストは1/8。
結果②：Agentic RAG タスク
品質ランキング（MRR 基準）
| 順位 | モデル | MRR |
|---|---|---|
| 1 | Claude Opus | 78.9% |
| 2 | Claude Opus（Think） | 72.3% |
| 3 | GPT-5.2（Reasoning） | 66.9% |
| 4 | Gemini 3 Pro（Think） | 59.9% |
| 5 | GPT-5.2 | 59.3% |
注目すべきは GPT-5.2（Reasoning）の3位。 コード生成では12位だったモデルが、ここでは3位に浮上しています。
Thinking モードの効果（コード生成と正反対）
| モデル | コード生成での効果 | RAG での効果 |
|---|---|---|
| GPT-5.2 | -10.6%p ❌ | +7.6%p ✅ |
| Gemini 3 Flash | — | +8.1%p ✅ |
| Claude Opus | -0.5%p | -6.6%p ❌ |
| Claude Sonnet | +1.2%p | -5.6%p ❌ |
GPT-5.2 は完全に正反対のパターンを記録しました。Reasoning モードは複雑な検索推論には向いているが、定型的なコード生成には向いていない、ということです。
最もインパクトのある発見：タスク別モデル順位の激変
| モデル | コード生成順位 | RAG 順位 | 変動 |
|---|---|---|---|
| Claude Sonnet（Think） | 1位 | 8位 | ↓7 |
| GPT-5.2（Reasoning） | 12位 | 3位 | ↑9 |
| Claude Opus | 3位 | 1位 | ↑2 |
同じモデルがタスクによってここまで順位が変わる。 これがベンチマークだけでモデルを選んではいけない最大の理由です。
実践：異種モデルパイプラインでコスト79%削減
169通りの組み合わせからパレート最適を導出
13モデル × 13モデル = 169 の組み合わせを分析しました。
推奨構成
| シナリオ | コード生成 | Agentic RAG | コスト | 品質 |
|---|---|---|---|---|
| 現行 | Claude Sonnet | Claude Sonnet | $277 | 62% |
| 予算重視 | Gemini 3 Flash | Gemini 3 Flash（Think） | $23（-92%） | 54% |
| バランス | Gemini 3 Flash | Claude Haiku（Think） | $58（-79%） | 65%（+3%p） |
| 最高品質 | Claude Sonnet（Think） | Claude Opus | $356 | 74%（+12%p） |
🎯 バランス構成が最もおすすめ。 コスト79%削減しながら品質が上がるという、単一モデルでは不可能な結果です。
まとめ：LLM 選定で気をつけるべき5つのこと
1. ベンチマークスコアを鵜呑みにしない
汎用ベンチマークの順位と、自分のタスクでの順位は別物です。自分のドメイン、自分のタスクで評価しましょう。
2. Thinking/Reasoning モードは万能ではない
タスクによっては10%以上スコアが下がります。必ず有効/無効の両方をテストしてください。
3. 空応答率を必ず測定する
品質スコアだけでなく、実際に応答が返ってくるかを測定しましょう。GPT の Reasoning モードは21〜23%が空応答でした。
4. 異種モデルパイプラインを検討する
タスクごとに最適なモデルが異なるなら、パイプラインの各段階に別のモデルを使うのは合理的です。同じモデルを全段階に使い続ける必要はありません。
5. コスト効率性を指標に含める
最高品質モデルが常にベストとは限りません。品質/コストの比率で評価すると、見えてくる景色が変わります。
詳細データについて
本記事は検証結果の要約版です。
13モデルの全比較データ、評価フレームワークの設計詳細、パイプラインアーキテクチャの図表を含む完全版ホワイトペーパーを公開しています。
LLM をプロダクションに組み込もうとしている方の参考になれば幸いです。
本研究は QueryPie AI の開発者 Edwin Park が執筆し、CEO の Brant がnoteで要約を紹介しています。