推論特化型LLM（推論モデル）の弱点はどこか　ステップ数より要件カバー率が成否を分ける

本記事では、推論に特化したLLMの考え方をどう評価できるかを調べた研究を紹介します。

LLMは、コード生成で高い性能を見せています。中でも特に注目されるようになったのが、思考の流れを明示するタイプのモデルです。とはいえ、その出力が本当に役に立つのかは、まだ十分に検証されていませんでした。この疑問に答えるため、6つのモデルを対象に大規模な評価が行われました。

背景

LLMは、コード生成で大きく進化しており、開発効率を高める手段として期待されています。

ただし、複雑な課題では性能が安定しないこともあります。要件の分解や例外処理、複数の概念の統合が求められると、プロンプトの工夫次第で結果が大きく変わります。失敗しても、何が原因だったのか（設計ミスか実装ミスか）を特定しにくいという問題もあります。

こうした課題に応える形で登場したのが、推論特化型モデルです。コードを実際に生成する前に、問題理解や解法の構想、制約の整理といった「思考の過程」を外に出す仕組みを備えています。

こうした過程が見えると、コードの妥当性を人が確認しやすくなり、失敗した場合の振り返りも楽になります。信頼性や改善性の向上が期待されています。

とはいえ新たな疑問もあります。出力される思考は本当に有用なのか。長ければ良いのか、簡潔な方が良いのか。論理は一貫しているか。開発者が読んで役に立つと感じるのか。こうした点はまだ十分に検証されていません。

そこで本記事では、いくつかの推論特化型のLLMを使用したコード生成実験を取り上げます。

実務に近い100の課題で、推論の質をたしかめた

BigCodeBenchから、難易度ごとに代表的な課題を選出

研究チームが使ったのは「BigCodeBench」というベンチマークです。これは現場に近いプログラミング課題を集めたテスト集で、全部で1140問あり、Pythonで書かれた関数呼び出しやライブラリ利用を含みます。計算や可視化、ネットワークなど7分野にわたる幅広い問題が含まれています。複数のライブラリを組み合わせた複雑な課題が多く、より実務に近いのが特長です。

ただ、全問を人手で評価するのは時間がかかりすぎるため、今回はその中から100問を統計的に偏りなく無作為に選びました。選定数は、信頼水準95%、誤差5%の基準に沿っています。

また、難しさの違いを反映するため、全体の13%にあたる「Hard」問題（ライブラリが2つ以上、回答が長く、正解率が50%未満）から14問、それ以外の「Full」から86問を選び、もとの比率を保ちました。

出題形式は2種類ありますが、実際の使い方に近い「Instruct」形式（自然な言葉での簡単な指示）を使ってモデルに問いかけました。

最新の推論重視モデル6つを比べた

評価対象には、2024年末〜2025年前半に登場した6つの推論特化型モデルを選びました。オープンソースとクローズドソースの両方を含み、すべて公式API経由で利用しています。

推論の流れを3772ステップ分あつめて整理

各モデルに対し、100のタスクすべてを実行させ、推論の流れと最終的なコード出力を記録しました。ただし、モデルごとに出力の形式は異なります。たとえば、以下の違いがあります。

推論文は多くが長文で構造もバラバラなため、人手で評価するには工夫が必要です。そこで、すべてのモデルに統一プロンプトを与え、<step1>や<step2>のように明確にステップを区切らせました。

データは次の3段階で収集しました。

1. 各モデルに100タスクを実行させ、推論とコードをJSON形式で保存
2. 評価用に整形し、各ファイルに10タスク×6モデルの出力を並べたテキストを作成
3. 評価の信頼性確保のため、すべての資料を3部用意し、3人の評価者が個別にチェック

最終的に、600タスク分の推論データが集まりました。推論のステップ数はモデルごとに異なり、Qwen-QwQが平均5.02ステップと最も簡潔で、Gemini-2.0-Flash-Thinkingが平均8.2ステップと最も丁寧でした。全体の平均は6.29ステップ、合計3772ステップが人手評価の対象になりました。

推論が長ければうまくいくとは限らない

推論特化型モデルを評価するには、コードの正しさだけでなく、推論の中身も見る必要があります。しかし、推論の構造や質はまだよく分かっていません。たとえば、長い推論と短い推論のどちらが有効か、モデルごとに戦略が違うのか、ステップの量と正解率が関係するのか。こうした疑問に答えるため、推論の構造を数値で分析しました。

調査では三つの点が確認されました。

1. 推論の平均ステップ数と成功率の関係
2. ステップを増減させたときの変化
3. 各ステップの長さ（単語数）が成功に関係するか

分析では、全モデルに100タスクを実行させて平均ステップ数と正解率を記録し、ステップ数と成功率の関係を測定しました。

ステップの数と正解率の関係はモデルによって違う

まず、ステップ数と成功率の関係には、モデルごとに大きな違いが見られました。

難しいタスクでは、Gemini-2.0-Flash-Thinkingが明確な傾向を示しました。成功時の平均ステップ数は13.75、失敗時は8.10で、スピアマン係数は0.79。ステップが多いほど成功しやすく、正解率も28.57%と高めでした。

反対に、DeepSeek-R1とQwen-QwQは、ステップが少ないと成功しやすく、増えるとかえって失敗が多くなる傾向がありました。スピアマン係数はそれぞれ−0.579と−0.52でした。簡潔に考える方がうまくいくモデルといえます。

Claude-3.7-Sonnet-Thinkingなどは、ステップ数と成功率にほとんど関係が見られませんでした。推論の長さが性能に影響していない可能性があります。

通常レベルのタスクになると、どのモデルでも相関はほぼゼロに近づきました。正解率も上がり、成功と失敗でステップ数の差も小さくなっています。

難易度が低ければ、推論の長さはあまり重要ではなく、難しい問題になるほどモデルの差が表れる

ようです。

ステップを増やしても正解率は必ずしも上がらない

次に、失敗したタスクに対してステップ数を増やす「Think Deeper」実験を行いました。元のステップ数を10%から100%まで段階的に増やし、正解率の変化を調べました。

結果は一様ではありませんでした。多くのケースで、ある程度までは改善するものの、その後は効果が頭打ちになったり、逆に下がることもありました。

通常タスクでは、Gemini-2.5-FlashやGemini-2.0-Flash-Thinkingが50〜60%増でわずかな改善を示しましたが、上昇は続きませんでした。DeepSeek-R1は80%増で改善、Claude-3.7-Sonnet-Thinkingはほぼ変化がありませんでした。

難しいタスクでは変動がより大きくなりました。Claude-3.7-Sonnet-Thinkingは70%増で大きく改善し、o3-miniも80%増で大幅に上がりましたが、Gemini-2.0-Flash-Thinkingはどの段階でも改善が見られませんでした。これは、難タスクの評価件数が少なく、少数の変化が結果に強く影響するためと考えられます。

あるタスクでは、6ステップで失敗していたものが、9ステップに増やすことで成功しました。追加された内容には、エラー処理や条件分岐の工夫が含まれており、考慮漏れが補われていました。

ただし、効果が出る増加幅はモデルや問題によって異なり、

単純にステップを長くすれば良いというものではない

ことが分かりました。

ふつうのタスクはステップを1〜3割減らしても問題ない

成功したタスクのステップ数を減らす「Reduce Steps」実験も行いました。推論にどれだけ無駄があるかを見るための検証です。

結果はタスクの難易度によって大きく分かれました。通常タスクでは、多くのモデルが10〜40％の削減に耐えました。Gemini-2.5-Flashは広い範囲で成功率を保ち、Gemini-2.0-Flash-Thinkingも中程度までは安定していました。o3-miniは20％までは持ちこたえましたが、それ以上では崩れやすくなりました。DeepSeek-R1、Qwen-QwQ、Claude-3.7-Sonnet-Thinkingは早い段階で失敗が増えました。

一方、難タスクでは10％削っただけで多くのモデルが大きく性能を落としました。Claude-3.7-Sonnet-Thinking、Gemini-2.5-Flash、Qwen-QwQはほぼ削減に耐えられず、Gemini-2.0-Flash-Thinkingとo3-miniだけが20〜40％の範囲でわずかに粘りました。

この結果から、

通常タスクではある程度の冗長なステップが含まれており、多少減らしても問題ない

ことが分かります。一方で

難タスクでは、ほぼすべてのステップが重要であり、削減は失敗につながりやすい

です。

実際、あるタスクでは7ステップから4ステップに減らしたところ、JSONの読み込みやファイル書き込みなどの処理が抜け落ち、失敗に終わりました。必要な操作まで省くと、正解にたどり着けなくなるということです。

冗長な説明が役に立つかどうかもモデルによって違う

最後に、1ステップあたりの単語数と成功率の関係、つまり推論の冗長さが調べられました。ステップ数が「広さ」を、冗長性は「深さ」を表すと考えられます。

Gemini-2.0-Flash-Thinkingは、短いステップを多く重ねる戦略でした。成功時は平均44語、失敗時は66語で、スピアマン係数は−0.67。簡潔に分けて考えると成功しやすく、失敗時は一部のステップが冗長になっていました。

Claude-3.7-Sonnet-Thinkingも同様の傾向がありましたが、変化はやや小さめでした。

一方、Qwen-QwQは難しいタスクで逆のパターンを示しました。成功時は1ステップ42語、失敗時は29語で、係数は0.71。少数のステップに詳しく書く方が成功しやすく、失敗時は浅いステップが並ぶ傾向が見られました。ただし、この傾向は難タスクに限られ、通常タスクでは現れませんでした。

DeepSeek-R1とGemini-2.5-Flashは成功・失敗を問わずステップが冗長でしたが、難タスクの正解率はどちらも低く、冗長なだけでは効果がないことも分かりました。

この結果から、

ステップ数と冗長性のバランスはモデルごとに異なり、多ければ良い、長ければ良いとは言えません。

短いステップを多く使う戦略も、少ないステップで深く書く戦略も、それぞれに有効な場面があるということです。

一番の課題は完全性の欠如で、全体の44.5%を占めた

ステップの数や長さを見るだけでは、推論の質は分かりません。そこで研究者らは、開発者の視点に近い人手評価を行い、推論内容の質を確認しました。評価は3つの基準に基づき、問題のあるパターンも分類しました。

21人の評価で結果の信頼性を確認

評価には、PythonとLLMの経験がある大学院生21人が参加しました。評価の統一性を保つため、手順や具体例を盛り込んだ詳細なガイドをあらかじめ用意しました。

評価基準は次の3つです。

評価前に全員が10分のトレーニングを受け、基準と例を共有しました。各人には10タスクが割り当てられ、1タスクにつき6モデルの推論を評価しました。すべてのタスクは3人の評価者によって個別に審査され、バイアスが出にくいように設計されています。

評価には1タスクあたり約12〜15分かかり、参加者あたり合計2〜2.5時間の作業でした。

エッジケースへの対応不足が最も多く32.17%

600タスク（100タスク×6モデル）の推論内容を分析した結果、問題のある出力が分類されました。この分類は「タクソノミー」として整理され、3つの大分類とそれぞれの中分類・小分類に分かれています。

最も多かったのは「完全性の問題」で、全体の44.5％を占めました。推論が問題のすべてをカバーできていない場合です。

完全性の問題には3つの主なパターンがあります。

次に多かったのは「効率性の問題」で、全体の33.5％を占めました。正しい答えにたどり着いても、無駄が多く非効率な推論です。効率性の問題には2つあります。

3つ目は「論理の問題」で、全体の7％でした。数は少ないですが、推論の信頼性に関わる深刻なミスです。

論理の問題には2つのパターンがあります。

モデルごとに見ると、いくつかの特徴がありました。

効率性は全体的に良好だが、Gemini-2.5-Flashはやや劣る

ほとんどのモデルで高い効率性（全ステップのうち実際に必要なステップの割合）が確認されました。OpenAI-o3-mini（0.971±0.049）、Gemini-2.0-Flash-Thinking（0.949±0.077）、DeepSeek-R1（0.948±0.131）は安定しており、集中した推論を行っていました。

一方、Gemini-2.5-Flash（0.796±0.363）は効率性が低くばらつきも大きい結果でした。推論の途中終了や冗長な説明が多く、これがスコア低下の要因と考えられます。

この傾向は、ステップ数の増減実験とも一致しています。ステップを少し減らしても正解が保たれるのは、もともと十分な内容を含んでいる場合です。逆に、単にステップを増やしても改善しないのは、長さが効率を保証しないためです。

論理の流れは概ね正しく、問題は7.5%だけ

論理の一貫性に関しても、ほとんどのモデルで高い一貫性が確認されました。o3-mini（0.976±0.038）、Gemini-2.0-Flash-Thinking（0.969±0.059）、Claude-3.7-Sonnet-Thinking（0.963±0.066）、DeepSeek-R1（0.965±0.096）はいずれも0.96以上と安定していました。

Qwen-QwQ（0.930±0.206）はやや低くばらつきも見られましたが、全体としては高水準でした。一方、Gemini-2.5-Flash（0.842±0.316）は最も低く、ばらつきも大きい結果でした。

論理の問題は全体の7.5％にとどまり、明確な論理ミスはまれでした。多くのモデルで基本的な推論の流れは保たれていますが、論理が正しくても必ずしも成功につながるとは限らないことが分かりました。

成否を分けたのは完全性であり、モデル間の差も大きい

完全性の欠如（問題に出された要件のうち、推論でどれだけ扱えていたか）は全体の44.5%を占めていました。推論の質における中心的な課題と言えます。

モデル別では、Gemini-2.0-Flash-Thinking（0.994±0.024）が最も高く、ばらつきもほとんどありませんでした。DeepSeek-R1（0.989±0.041）、o3-mini（0.977±0.033）、Claude-3.7-Sonnet-Thinking（0.958±0.058）も安定して高スコアを記録しています。

一方で、Gemini-2.5-Flash（0.830±0.339）は全モデル中で最も低く、要件の見落としや条件の扱い漏れが目立ちました。

推論が要件を十分にカバーできていないことが原因です。ステップを増やしても、必要な要素に触れていなければ改善にはつながりません。逆に、完全性が高ければ、多少ステップを減らしても正解にたどり着きやすくなります。

難しいタスクほど、完全性が結果に強く影響する

最後に、タスクのむずかしさが、推論の質や正解率にどう関係するかを調べました。

タスクがむずかしくなるほど、要件をどれだけ丁寧に拾えているかが大事になるということが分かりました。難しい問題では、見落としや抜けがあると失敗につながりやすく、簡単な問題では多少の抜けはカバーされやすい、という違いが見えてきました。

正解率で見ると、モデルごと・タスクごとに差がはっきり出ました。もっとも高かったのはo3-miniで、難しいタスクで35.70%、ふつうのタスクで55.81%を記録しました。これに続いたのが、Gemini-2.0-Flash-Thinking、Qwen-QwQ、DeepSeek-R1（ふつうのタスク）です。一方で、Gemini-2.5-FlashとDeepSeek-R1（難しいタスク）は、ともに14.29%と低くなりました。

また、むずかしくなったときにどれだけスコアが落ちるかもモデルで差がありました。DeepSeek-R1とo3-miniは、それぞれ22.92ポイント、21.30ポイント下がっていて、大きな変化が見られました。逆にClaude-3.7-Sonnet-Thinkingは、わずか7.64ポイントの下げにとどまり、最も安定していました。

この結果から、正解率が高いモデルが必ずしもむずかしい問題に強いわけではないこと、そしてモデルごとに「むずかしさへの耐性」が大きく違うことが分かりました。

まとめ

推論に特化したLLMの思考プロセスを、数と質の両面から評価した体系的な調査を取り上げました。6モデル・100タスク・3772ステップを分析し、いくつかの重要な発見が得られました。

まず、推論ステップの多さと成功率は必ずしも比例せず、モデルごとに傾向が異なることが分かりました。通常のタスクではステップを10〜30%減らしても影響は小さめですが、難しいタスクでは10%の削減でも性能が大きく落ちてしまいます。

中でも注目すべきは、「完全性」の不足が全体の44.5%にのぼり、成功・失敗を分ける大きな要因だったことです。とくに例外処理の抜けが32.17%と多く、ファイルアクセスや入力検証、境界値、大量データなど実務で必要な配慮が抜けがちでした。論理の一貫性に大きな問題はなく（7.5%のみ）、効率性もおおむね高水準でしたが、要件の取りこぼしが目立ちました。

実務で使う際は、出力されたコードだけでなく、推論の流れも確認する必要があります。とくに例外や境界条件がちゃんと考慮されているかをチェックすべきです。推論が長く見えても、必要な要素が抜けていれば安心できません。