LLMが複雑なコードを理解しようとするときの失敗18パターン

本記事では、LLMのコード推論能力を実世界のプログラムで検証した事例を紹介します。

LLMはコード生成やバグ検出などのプログラミングタスクで目覚ましい成果を上げています。しかし、その評価に使われているベンチマークの多くは、単純で短いプログラムが中心です。そのため、LLMが実際の開発現場で扱うような複雑なコードをどこまで理解できるのか、正確には分かっていません。

背景

LLMは、コードの生成やバグの検出など、さまざまなプログラミング作業で高い成果を示しています。こうした力の基盤となっているのが、コード推論と呼ばれる能力です。コードが何をしているのかを正しく理解する力を指します。

たとえば、ある入力を与えたときにプログラムがどのような出力を返すかを予測したり、特定の出力を得るためにはどんな入力が必要かを逆に考えたりする力です。

LLMのコード推論能力評価に現在よく使われている指標として、CRUXEvalやHumanEvalといったベンチマークがあります。CRUXEvalやHumanEvalは最新のLLMは非常に高いスコアを出していますが、比較的短く単純なプログラムを対象としています。
一方で、実際のソフトウェア開発で扱われるコードは、これほど単純ではありません。複数のメソッドやクラスが相互に呼び出されていたり、外部ライブラリのAPIを利用していたり、条件分岐やループが何重にも入れ子になっていることも珍しくありません。
既存のベンチマークにはこうした複雑さがほとんど含まれていないため、そこで得られる高いスコアが、実務での能力を正確に表しているのかどうかには疑問が残ります。

そこで本記事では、実際に使われているオープンソースプロジェクトから複雑なコードを抽出し、より現実に近い条件で評価した事例を取り上げます。LLMのコード推論能力をより実践的な状況で検証しています。

評価の枠組み

評価用のコード内容

研究チームはまず、Avatar、ClassEval、CRUXEval、HumanEvalといった既存のベンチマークから問題を収集しました。これらを合計すると1,450件にのぼりますが、前述のとおり、内容は比較的短く単純なプログラムが中心です。

そこで、より現実に即した複雑なコードを含めるため、SWE-benchというデータセットを利用しました。SWE-benchは、GitHub上の実在するオープンソースプロジェクトから集められたバグ修正タスクの集合です。この中からさらに、バグ修正時に変更されたメソッドを取り出し、重複しているものや、入力引数や戻り値を持たないものなどを除外しました。その結果、991件の新たな推論問題が得られています。

複雑な変数の扱い

実際のプログラムでは、入力や出力が単純な数値や文字列ではなく、複雑なオブジェクトであることが多くあります。たとえば、あるメソッドがWidgetというクラスのインスタンスを受け取り、その内部にさらに別のクラスのインスタンスが含まれている、といったケースです。

こうした複雑なデータ構造を扱うために、本研究ではオブジェクトを再帰的に分解し、JSON形式に変換する仕組みを採用しています。

難易度の分類

集められた推論問題は、9種類のコード複雑度メトリクスに基づいて、EasyとHardの2段階に分類されています。評価に用いられる指標には、分岐の多さを示す循環的複雑度、andやorで構成される条件式の数、処理のネストの深さ、サードパーティAPIの呼び出し回数、クラス内やクラス間の依存関係の数などが含まれます。

各メトリクスについて、値が上位25%に入るものはHigh、下位25%に入るものはLowと判定されます。そして、9つのうち6つ以上がHighであればHard、6つ以上がLowであればEasyと分類されます。どちらにも明確に当てはまらない中間的な問題は除外され、難易度がはっきり分かれた2つのカテゴリだけが残されます。

このような厳密な手順を経て、最終的に1,101件の推論問題が評価対象として選ばれました。その内訳は、Easyが946件、Hardが155件であり、Hardに分類された問題の83%以上はSWE-bench由来の実世界のコードです。

実験と評価

実験の設計

評価対象のモデル

本研究では、合計6種類のLLMを評価しています。推論に特化したモデルとしてo4-mini、Gemini-2.5-Pro、DeepSeek-R1の3つ、汎用モデルとしてGPT-4.1、Gemini-1.5-Pro、DeepSeek-Coder-Inst-33Bの3つが選ばれました。推論特化型モデルとは、回答を出す前に比較的長い内部的な思考過程を持つよう訓練され、複雑な問題への対応力を高めたモデルを指します。

なお、実験の再現性を高めるため、ほとんどのモデルではtemperatureを0に設定しています。temperatureは生成結果のランダム性を調整するパラメータで、0にすると最も安定した出力が得られます。

評価タスク

評価には、2種類のタスクが用いられています。

これらのタスクが選ばれた理由は三つあります。第一に、先行研究から、これらのタスクで高い性能を示すモデルであっても、他の推論課題では必ずしも良い結果を出せないことが分かっており、コード推論能力の限界を測る指標として適しているためです。第二に、コードの入力から出力までを一貫して扱うため、実世界の複雑さを反映した評価が可能である点です。第三に、最新のLLMを評価する際に、現在最も広く使われているタスクであることが挙げられます。

プロンプトの設計

LLMの性能は、与えられるプロンプトの設計に大きく影響されます。その点を踏まえ、いくつかの工夫を取り入れたプロンプトが使用されています。

まず、In-Context Learningの例を含めています。本番の問題を解かせる前に、似た形式の例題を提示し、モデルにタスクの意図を理解させる方法です。加えて、推論を段階的に進めるよう明示的に指示しています。

また、実世界のコードでは、入出力が複雑なオブジェクトであることが多いため、構造に関するヒントも与えられています。たとえば、Widgetクラスのインスタンスを予測させる場合、そのオブジェクトのJSON形式での構造をあらかじめ示し、モデルには具体的な値だけを埋めさせます。

評価指標

評価には二つの指標が用いられています。

主要な実験結果

難易度による性能差

実験の結果、すべてのモデルに共通して、Easy問題からHard問題になると性能が大きく低下することが確認されました。

入力予測では、平均RSが77.74%から26.24%へと51.50ポイント下がっています。部分的な正解率を示すRSpartialでも、88.93%から61.57%へと27.36ポイントの低下が見られました。

出力予測でも同様の傾向があり、平均RSは78.49%から36.34%へと42.15ポイント低下しています。RSpartialも79.86%から46.50%へと33.36ポイント下がっています。

推論特化型モデルと汎用モデルの比較

推論特化型モデルであるo4-mini、Gemini-2.5-Pro、DeepSeek-R1は、汎用モデルと比べて、RSで平均11.45%、RSpartialで9.82%高い性能を示しました。推論に特化した訓練がコード推論にも有効であることが分かります。

ただし例外も見られました。Gemini-2.5-Proは、Hard問題の入力予測において、前の世代であるGemini-1.5-Proを下回る結果となっています。研究チームは、これはモデル更新に伴う能力の変化、いわゆるcapability driftが起きている可能性を示していると考えています。

入力予測と出力予測の比較

全体として、LLMは入力予測（コードと出力が与えられた状態から、入力を推測するタスク）よりも出力予測（コードと入力が与えられたときに、その実行結果を予測するタスク）の方が得意であることが明らかになりました。全問題を通した成功率は、出力予測が57.53%、入力予測が51.99%となっています。

この差は直感的にも理解できます。出力予測では、与えられた入力からコードを順に追っていけばよいのに対し、入力予測では、望ましい出力から逆に入力を考える必要があり、より複雑な推論が求められるためです。

入力予測における偽陰性

入力予測には、正解が一つとは限らないという特有の難しさがあります。異なる入力であっても同じ出力が得られる場合があるため、正解と異なる入力を出していても、実際には正しい推論である可能性があります。

そこで研究者らは、モデルが予測した入力を用いて実際にコードを実行し、期待する出力が得られるかどうかを確認することで、こうした偽陰性を検出しています。その結果、とくにCRUXEvalのような単純なプログラムで多くの偽陰性が見つかりました。単純なロジックほど、入力と出力の対応関係が一対多になりやすいためです。

推論を困難にする要因

プログラム構造の影響

どのようなプログラム構造が推論を難しくするのかを調べるため、ExerScopeという静的解析ツールが用いられました。その分析から、

• 条件分岐が深く入れ子になっているコード
• ループが多重にネストされたコード
• 例外処理を含むコード

は、入力予測・出力予測のいずれにおいても特に難易度が高いことが分かりました。

呼び出しチェーンの影響

実世界のコードでは、あるメソッドが別のメソッドを呼び出し、さらにその先で別のメソッドが呼ばれるといった連鎖的な構造が一般的です。呼び出しチェーンの長さと推論性能の関係を調べたところ、推論に失敗した問題では、平均して呼び出しチェーンが長い傾向があることが確認されました。

一方で、出力予測に成功した問題の呼び出しチェーンの平均長は、入力予測に成功した問題よりも長くなっています。LLMが逆方向よりも順方向の推論を得意としており、長い処理の流れでも追跡できていることを示唆しています。

推論失敗の分析

研究チームは、推論が失敗するパターンを整理するため、まず九つの複雑度メトリクスと推論成功率の関係を分析しました。その結果、ほぼすべての指標において、コードの複雑さが増すほど推論成功率が下がるという、中程度から強い負の相関が確認されています。

この分析をもとに、推論失敗は十八のカテゴリに分類されました。

条件文に関する失敗

再帰・ループに関する失敗

構造的複雑さに関する失敗

呼び出し依存関係に関する失敗

型に関する失敗

LLM固有の問題

アブレーション研究

プロンプト設計のどの要素が性能に寄与しているかを調べるため、アブレーション研究も行われています。

構造ヒントを取り除くと、RSで平均7.43%、RSpartialで9.88%の性能低下が確認されました。とくにHard問題で影響が大きく、複雑なオブジェクトを予測する際には、構造情報の提示が重要であることが示されています。

一方、ステップバイステップで考えるよう促す推論指示を除去した場合、RSは2.56%、RSpartialは3.22%低下しました。ただし、DeepSeek-Coder-Inst-33Bでは、Hard問題で逆に性能が向上するケースも見られました。推論過程で同じ内容を繰り返し生成してしまうハルシネーションが抑えられたためだと考えられています。

まとめ

本記事では、LLMのコード推論能力を、実際のプログラムに近い条件で評価した研究を紹介しました。

従来のベンチマークでは高い評価を得ているLLMであっても、オープンソースプロジェクトから抽出された複雑なコードを対象にすると、性能が大きく下がることが示されています。とくに入力予測では51.50ポイント、出力予測でも42.15ポイントという大きな低下が確認されました。

推論に特化したモデルは汎用モデルより良い結果を出していますが、それでもHard問題に十分対応できているとは言えません。条件分岐やループが深く入れ子になった構造、例外処理を含むコード、そして長い呼び出しチェーンを持つコードでは、推論が難しくなる傾向が明らかになっています。

現在のLLMが持つコード推論能力が、従来の評価によって実態以上に高く見積もられている可能性を示しています。実際の開発現場でLLMをコード関連の作業に用いる際には、複雑なコードに対しては限界があることを前提に活用する姿勢が重要だと言えそうです。