AIエージェントは最適化の受託案件をこなせるか：論文「OR-License」の結果

工場の生産計画、配送ルート、在庫の発注点のように、条件を満たす中で一番よい答えを探す問題には、数理最適化を使います。数理最適化は、意思決定をよくするための分野であるオペレーションズ・リサーチ（OR）の代表的な手法です。生成AIで数理モデルを書かせる研究はこれまでにもありましたが、多くは「きれいに書き直された問題文」から始まります。実際の案件では、顧客から届くのは要件の文書とデータで、足りない条件は聞きに行かなければ分かりません。

論文「OR-License: Evaluating LLM Agents as Real-World Operations Research Practitioners」は、2026年10月16日にarXivへ公開されました。この「顧客の資料から納品まで」をAIエージェントに通しで任せたときの結果を測っています。要旨にある「Claude Codeの構成で88.39%」は、Claudeのモデルの点と読み違えやすい数字です。

有償案件の資料を、そのまま課題にした#

OR-Licenseの課題は、実際にお金を払って依頼された最適化の案件から作られています。課題は10業種・31件で、元になった案件の金額は合計368万ドルです。食品工場のバッチの順番、半導体の検査（バーンイン）の日程、原料の配合、供給網の在庫、株式のポートフォリオ、シェアサイクルの自転車の再配置などが並びます。課題の一覧はプロジェクトのサイトで見られます。

元の要件、入力データ、納品の形式は、社名などの身元につながる部分だけを取り除いて残しています。作業したのはORの実務経験が3年以上ある専門家です。

エージェントが最初に受け取るのは、業務の概要を書いた文書と入力ファイルだけです。足りない情報はORSimという模擬の顧客に質問して集めます。ORSimが答えるのは「顧客が知っている業務の事実」に限られ、どう定式化するか、どの解き方を選ぶかには答えません。1回の質問で明かされる事実は3つまでです。どの事実を明かしてよいかは、LLMではなくプログラムが判定します。

納品された計画はエージェントから見えない検証器にかけます。顧客の条件を1つでも破っていれば「実行不能」です。条件を満たしていれば、元の案件で顧客が受け入れた専門家の解と、目的の値（費用や利益など）を比べます。

総合点DAQは「実行不能なら0点」#

論文が主な指標にしたDAQ（Deployment-Adjusted Quality）は、課題ごとの点の平均です。計画が顧客の条件を全て満たさなければ0点、満たしていれば専門家の解と比べた品質を点にします。品質は専門家と同じなら1で、上回れば1を超えます。

専門家の解のDAQは1です。現場で使えない計画は、目的の値がどれほどよくても0点になります。このため、実行不能の計画が多いモデルは、解けた課題の品質が高くてもDAQが下がります。

結果：どのモデルも専門家に届かない#

評価したモデルは11で、課題ごとに5回ずつ動かしています。主な結果は次のとおりです（論文の表1から抜粋。値は31課題の平均）。

モデル	実行可能率	実行可能だった分の品質	DAQ
Grok 4.6	88.39%	97.92%	86.55%
GPT-5.6 Sol	84.52%	100.59%	85.02%
Gemini 3.8 Flash	82.58%	100.43%	82.94%
Qwen3.8-Max	78.71%	99.06%	77.97%
Claude Opus 5	77.42%	100.03%	77.44%
Hy3	45.16%	96.92%	43.77%

実行可能だった分の品質は、どのモデルも96.92〜101.01%の狭い幅に収まり、いくつかは専門家を上回りました。一方、実行可能率は45.16〜88.39%と、40ポイント以上の差があります。

DAQが最も高いGrok 4.6でも、専門家との差は13.45ポイントです。論文はこの差を、実行不能による11.61ポイントと、目的の値の不足による1.84ポイントに分けています。差の約86%は条件を破った計画を出したことによるものです。

「Claude Codeで88.39%」はClaudeの点ではない#

要旨には「the strongest primary Claude Code configuration achieves 88.39% strict feasibility」とあります。ここのClaude Codeは、モデルではなく実行環境（ハーネス）のことです。論文は全てのモデルを、Claude Code 2.1.278の上で動かしています。ファイルの読み書き、コードの実行、ORSimへの質問（askというコマンド）を、共通の手段にそろえるためです。88.39%はGrok 4.6の値で、Claude Opus 5の実行可能率は77.42%でした。

付録では3つのモデルを実行環境だけCodex 0.155.1に替えて、同じ課題を解かせています。

• GPT-5.6 Sol: DAQが85.02%から93.59%に上がった
• DeepSeek-V4.1-Flash: 69.28%から78.27%に上がった
• GLM-5.3-Flash: 63.21%から34.42%に下がった

論文は、どちらの実行環境が有利かはモデルによると書いています。モデルの順位を読むときは、そのモデルに合った実行環境で動かしたかどうかも合わせて見る必要がありそうです。

費用も表にまとまっています。1回あたりの平均のAPI費用は、Claude Opus 5が8.24ドル、GPT-5.6 Solが4.26ドル、Grok 4.6が14.86ドルでした。最も安いGLM-5.3-Flashは0.49ドル、最も高いDoubao-Seed-2.1-Proは49.26ドルです。

質問は最初に集中し、誤りは定式化で起きた#

論文はエージェントの作業の記録を人手で読み、いつ質問したか、どこで誤ったかも分析しています。

ORSimには作業中いつでも質問できるのに、質問の86.7〜98.3%は、解くためのコードを書く前に出ていました。ただし、後の段階の質問には、問題の解決につながった割合が高いものもありました。最初の段階の質問で問題が解決した割合は10.6〜37.0%です。一方、DeepSeek-V4.1-Flashが計画の候補を作ったあとに出した質問では約56%、Hy4 previewが検算に通る前に出した質問では約71%でした。

誤りの種類ごとに数えると、11のうち9つのモデルで、最も多い種類は実装の誤りではなく定式化の側でした。Claude Opus 5では、時間に関係しない（静的な）制約の誤りが42.7%を占めます。Grok 4.6では、目的の立て方と不確実性の扱いの誤りが合わせて69.0%でした。論文は、動くコードがあっても、業務の条件を取り違えた定式化を正しく実装しているだけなら直らない、と指摘しています。

論文は、作業の途中で調べて確かめるべき不確かな点を「調査の機会」として拾い、そのうち仮説を立てて試し、結果を見て直す、という一連の流れを最後までやり通せた割合も測っています。課題ごとに均等にした値で、モデルごとに24〜45%で、どのモデルも半分に届きませんでした。

読むときの注意#

• 課題は31件で、半分近くは食品加工（5件）とシェアサイクル（8件）に偏っています
• 実行可能率やDAQの「±」は、同じ課題を5回動かしたときのばらつきの平均です。ベンチマーク全体の平均の誤差ではないと、論文は断っています
• 著者にはTencent Hunyuanの所属の人が含まれ、評価したモデルにはTencentのHy3とHy4 previewが入っています。Hy3のDAQは11のモデルで最も低い43.77%でした
• 査読の記載はなく、arXivの版（v1）として読む論文です

課題とコードは公開されていて、リポジトリの紹介文は「専門家が先に問題を書き直さなくても、LLMのエージェントはORの実務家の仕事ができるか」という問いです。

大きなデータはHugging FaceにApache-2.0で置かれ、学習データに混ぜないよう注意書きがあります。

Claude CodeやCodexに計画づくりを任せるなら、結果が出たあとで前提を聞き直させ、目的の値より先に、条件を全て満たしているかを別の検査で確かめるとよさそうです（論文が検証した方法ではありません）。