コード生成およびAgentic RAGタスクを中心とした特定ドメインのためのLLM比較評価
副題：LLMのベンチマークを信じないでください。ドメインに最適化されたLLMを自ら評価・選定しましょう。
最近私たちが進めたAX (AI Transformation) プロジェクトにおいて、給与ドメインに最適化されたモデルを見つけるために、さまざまなLLMをエージェントの役割に応じてコスト／性能を最適化するためのベンチマークテストをしました。
本ペーパーは、QueryPie AIの開発者であるEdwinが執筆しました。
社内ドキュメントとして寄稿したものですが、他の企業の皆さまにとっても非常に有益だと思い、共有いたします。
多くの方々のお役に立てれば幸いです。
🚨 まだLLMのベンチマークを信じていますか？
よく聞かれます。
「Claudeが一番賢いですか？」
「GeminiのReasoningモードが最強ですよね？」
「GPT-5が安定してますよね？」
LLMのベンチマークは、皆さんも見ていますよね。
「このモデルはMMLUで○○%」「あのモデルがHumanEvalで1位」——
こうした数字を見て、モデルを選定していませんか？
正直に言うと…ベンチマークスコアは、ほとんど意味を持ちません。
なぜなら、LLMは
特定タスク × 特定ドメイン × 特定パイプライン構造
の中で、全く異なる挙動を示すからです。
率直に言います。
汎用ベンチマークのスコアだけでモデルを選ぶのは、危険です。
私たち開発チームは、日本の給与システムという、極めて専門的なドメインでLLMを活用しています。そこで13のモデル構成を実際に評価した結果、驚くべきことがわかりました。
あるモデルは、コード生成では1位なのに、検索タスクでは8位に転落する
「Thinking」モードをオンにしたら、むしろ10%以上スコアが下がるケースがある
ベンチマークでは好成績のモデルが、実運用では20%以上の確率で応答しない
つまり、自分たちのドメイン、自分たちのタスクで実際に試さない限り、本当に最適なモデルは見つからないということです。
そしてもうひとつ。
パイプラインの各段階に異なるモデルを組み合わせることで、品質を維持しながらコストを79%削減することができました。
これは単一モデルを盲目的に全段階に使い続けていたら、絶対にたどり着けなかった結論です。
🔬 私たちが検証した環境
単なるQ&Aではありません。
自然言語 → SQL擬似コード変換
ドメイン用語 → DBフィールド（MFID）マッピング
実行可能SQL生成
Agentic RAGによるツール選択
マルチステップ推論
本番環境でのエラー制御
特に日本の給与ドメインのような、複雑な社会保険制度・年末調整・住民税特別徴収が絡む領域では、LLMは単なる文章生成モデルではなく、システムロジック生成エンジンになります。
🔬 実験で分かったこと
Reasoningモードが常に優れているわけではない
コード生成では強いが、Agentic RAGでは不安定なモデルも存在
高品質だがコストが3倍以上のケース
空レスポンスやエラー率が本番では致命的要因
結論は明確でした。
❗「最強のLLM」は存在しない
✅「タスクに最適なLLM構成」が存在するだけ
私たちの戦略：
単一モデルは選びませんでした。タスクごとに最適モデルを分離し、3段階パイプラインとして統合しました。
結果は、
✔ 品質維持
✔ コスト79%削減
✔ 応答安定性向上
ベンチマークよりも、設計思想のほうが重要でした。
この経験は、なかなか得られるものではありません。
LLMを「機能追加」ではなく、エンタープライズの中核ロジック生成基盤として扱った実証例だからです。
📖 本編はQueryPie AI公式サイトで公開しています
本ペーパーは、図表付きのホワイトペーパーとしてQueryPie AIの公式サイトに掲載しました。
序論、関連研究、AI Checkのパイプライン構造、13モデルの評価設計を詳述しています。
コード生成・Agentic RAGの実験結果、Thinkingモードの影響分析、コスト最適化戦略、最終推奨事項を取り扱っています。
この研究が、LLMを実際のプロダクションに組み込もうとしている企業の皆さまにとって、「自社でも評価をやろう」と思うきっかけになれば、これほど嬉しいことはありません。
AIの時代は、
「どのモデルが賢いか」ではなく「誰が最適構成を設計できるか」です。
ぜひ、皆さまの事業におけるLLM選定の参考にしていただければ幸いです。
ご質問やフィードバックがあれば、いつでもお気軽にお寄せください。