LLMにスケジューリングアルゴリズム、ビンパッキング、経路計画のコードを書かせる――これは非常に自然なユースケースに思える。しかし、ペンシルベニア大学（Dan Roth氏ら）による新論文は次のように警告している。安易に最適化を任せると、かえって状況を悪化させる可能性がある。
3つのアプローチ、どれが最適か？
論文では『CP-SynC-XL』というベンチマークを構築し、100の組合せ最適化問題、4,577のインスタンスを対象に、LLMに3つの異なるパラダイムでソルバーを生成させた。
- 純Pythonアルゴリズム探索：LLMが探索アルゴリズムのPythonコードを直接記述
- Python + OR-Tools制約モデリング：LLMがOR-ToolsのPython APIを用いてモデリングし、ソルバーを呼び出す
- MiniZinc + OR-Tools宣言型モデリング：LLMが宣言型言語MiniZincでモデリングし、OR-Toolsで求解させる
結果は非常に興味深いものだ。
Python + OR-Tools が最高勝率――複数のLLMにおいて最高レベルの正答率を記録した。MiniZinc + OR-Tools は同じOR-Toolsバックエンドを使用しながらも、カバレッジは低かった――宣言型言語の抽象化が、かえってLLMのエラーを誘発しやすくなったのだ。純Pythonは、「スキーマ検証は通過するが、実際のテストでは失敗する」解を最も生成しやすい傾向があった。
この発見は、「より高度な抽象化（MiniZinc）＝より良い結果」という直観を真っ向から覆すものだ。実際には、LLMにとってAPIレベルの制約モデリング（Python + OR-Tools）の方が最も信頼性が高いことが示された。
ヒューリスティックトラップ：最適化への欲求がモデルを台無しにする
続いては、論文の最も核心的な発見である。
研究者は、LLMにソルバー生成時に探索最適化（枝刈り戦略、ヒューリスティック関数、バウンド設定など）の追加を試みるよう促した。その結果はどうなったか？
- 中央値での加速比はわずか 1.03〜1.12倍――ほぼ効果なし
- 明確な二峰性分布を示す――多くのインスタンスでかえって速度が低下
- ロングテールな問題では正答率が急激に低下
なぜこのような結果になったのか？研究者がコードレベルの精査を行った結果、繰り返し現れるパターンを発見し、それを**ヒューリスティックトラップ（heuristic trap）**と名付けた。
- 純Pythonパスでは、LLMが完全な探索の代わりに局所近似を用いる可能性がある
- Python + OR-Toolsパスでは、LLMが検証されていないバウンド制約を注入する可能性がある
- MiniZinc + OR-Toolsパスでは、LLMが冗長な宣言型構造を追加し、かえってソルバーに過負荷をかける可能性がある
つまり、LLMの「最適化」に関する理解はしばしば誤っているということだ。高速化を図っているつもりが、実際にはバグを導入したり、問題のセマンティクス（意味）を変えてしまったりしている。
「形式化に徹し、最適化するな」
これらの発見に基づき、論文は保守的ながら実用的な設計原則を提案している。
LLMには主に形式化（変数、制約、目的関数の定義）を担当させ、求解は検証済みのソルバーに委ねる。LLMが記述した探索最適化は、利用前に必ず個別に審査する必要がある。
これは一歩引いた戦略と言える。LLMがモデリング（「何が解くべきか」の定義）には有用だが、アルゴリズムの最適化（「どう探索するか」の決定）では信頼性に欠けることを認めているのだ。この2つを切り離し、LLMには得意分野を担当させ、最適化は成熟した求解エンジンに任せるのが得策である。
AIエージェント開発への示唆
この発見は、AIコーディングエージェントの開発者にとって直接的な価値を持つ。
多くのエージェントツール（Cursor、Claude Code、Copilotなど）は、LLMにコードの生成や修正を任せている。もしLLMが探索や最適化に関連するアルゴリズムを記述している場合、エージェントは次の点を認識すべきだ：独立した検証メカニズムがない限り、LLMの「最適化提案」を安易に受け入れてはならない。
また論文は、より広範なパターンを示唆している。LLMは「問題構造の記述」において、「求解戦略の設計」よりも信頼性が高いという点だ。この区別は他の多くの分野でも当てはまる可能性がある――例えばデータベースクエリ最適化、コンパイラ最適化、さらにはネットワークルーティング戦略などである。
論文URL：arXiv:2605.12421