🤖 AI

OR-Space: A Full-Lifecycle Workspace Benchmark for Industrial Optimization Agents

本論文は、従来の単発的な問題定式化評価を超え、永続的な多成果物環境におけるモデル構築、修正、根拠に基づく説明を含む現実的な多段階タスクにおいて産業用最適化エージェントを評価するために設計された、フルライフサイクルのワークスペースベンチマークである「OR-Space」を導入する。

原著者： Chenyu Zhou, Xinyun Lu, Jiangyue Zhao, Jianghao Lin, Dongdong Ge, Yinyu Ye

公開日 2026-05-28

📖 1 分で読めます☕ さくっと読める

CC BY 4.0

原著者： Chenyu Zhou, Xinyun Lu, Jiangyue Zhao, Jianghao Lin, Dongdong Ge, Yinyu Ye

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 ✨ これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。免責事項の全文を読む

素晴らしい新助手を工場運営のために採用すると想像してください。彼らが単に話をするだけでなく、実際にその仕事をこなせるかどうかを確認したいものです。

長らく、これらの AI アシスタント（「LLM エージェント」と呼ばれる）をテストする方法は、彼らに完璧に書かれたレシピカードを与えるようなものでした。そのカードには、「ここに問題、ここに材料、ここに数式がある。さあ、それを解決するコードを書け」と書かれていました。

AI が正しくコードを書けば、私たちはそれに金の星を与えました。しかし、現実の世界では、工場管理者は完璧なレシピカードを受け取るわけではありません。彼らが受け取るのは、付箋が貼られた散らかった机、スプレッドシート、昨年の古いコード、そして上司からの「あ、そういえば来月のルールを変更する必要がある」というメールです。

OR-Spaceは、AI がそのような散らかった現実世界の机を処理できるかどうかを確認するために設計された、はるかに困難な新しいテストです。

AI をテストする 3 つの方法

この論文は、OR-Space（Operations Research Space：オペレーションズ・リサーチ・スペース）と呼ばれるベンチマークを紹介しています。単一の質問を与えるのではなく、このベンチマークは AI に全体の「作業スペース」（ファイルが入ったデジタルフォルダ）を与え、現実の工場で起こる 3 つの異なる種類の仕事をこなすよう求めます。

構築（建築家）
- シナリオ: AI に、ビジネスメモ、数値のスプレッドシート、そして空のコードファイルが入ったフォルダを渡します。
- タスク: AI はメモを読み、数値の意味を推測し、工場の問題をゼロから解決する新しいコンピュータプログラムを書かなければなりません。
- 難所: メモは曖昧で、スプレッドシートのカラムは乱雑である可能性があります。AI は完璧なガイドなしに、テキストとデータの間のつながりを結びつけなければなりません。
修正（修理屋）
- シナリオ: 工場が方針を変更しました。もしかしたらトラックが増えたのかもしれませんし、新しい安全規則ができたのかもしれません。AI には、古いプログラムと新しい規則が与えられます。
- タスク: AI は、すでに機能している部分を壊すことなく、新しい規則に合わせて古いコードを更新しなければなりません。
- 難所: これは、人がまだ住んでいる家を改装しようとするようなものです。もし AI が、もはや意味をなさない古いコードから変数名をコピーしてしまった場合、全体がクラッシュしてしまいます。論文によると、一部の AI は古いコードに混乱してその間違いをコピーしようとし、より賢い AI は何を残し、何を捨てればよいかを知っていることがわかりました。
説明（通訳者）
- シナリオ: コンピュータは問題を解決しましたが、数学の専門家ではない工場管理者が、「なぜ南の倉庫ではなく北の倉庫にトラック 5 台を送ることにしたのですか？」と尋ねます。
- タスク: AI は、解決策、コード、そしてデータログを確認し、真実の回答を提供しなければなりません。
- 難所: AI は単に物語を捏造することはできません。その決定を強制したスプレッドシートの特定の行や、コード内の特定の規則を指摘しなければなりません。もし推測すれば、減点されます。

このテストが異なる理由（「ワークスペース」対「プロンプト」）

著者らは、以前のテストはフラッシュカードのようだったと主張しています。AI に清潔で孤立した問題を見せ、答えさせるのです。

OR-Space は実際のオフィスのようです。

ファイルは別々: 要件は Word ドキュメントに、数値は CSV ファイルに、コードは Python ファイルに入っています。AI はそれらすべてを開き、読み、それらがどのように結びついているかを理解しなければなりません。
「グラウンディング」の問題: フラッシュカードテストでは、AI は単語を認識しているため、正解を推測するかもしれません。しかし、OR-Space では、AI がメモ内の「capacity（容量）」という単語を、スプレッドシート内の「max_load（最大荷重）」というカラムに正しくリンクできなければ、失敗します。論文はこのことを「グラウンディング（接地）」と呼び、単語を実際のデータに結びつけることを指します。

彼らが発見したこと（結果）

研究者たちは、この新しいテストで 20 種類の異なる AI モデル（利用可能な「最も賢い」もの）をテストしました。以下がその結果です。

見た目よりも難しい: 最高の AI でさえ苦労しました。「フラッシュカード」版の問題を解決できた AI も、ファイルの散らかったフォルダをナビゲートしなければならないと、しばしば失敗しました。
古いコードは両刃の剣: AI がモデルを修正するのを助けるために古いコードを与えられたとき、最も賢い AI は、古いコードを有益なヒントとして利用したため、性能が向上しました。しかし、より弱い AI は、古いコードの間違い（もはや存在しない変数を使おうとするなど）を盲目的にコピーしたため、性能が低下しました。
「説明」のギャップ: 一部の AI はコードを書くのが得意でしたが、それを説明するのは苦手でした。彼らは数学を解くことができましたが、持っていたファイルに基づいて、なぜその選択をしたのかを説明できませんでした。
「ファイルシステム」のペナルティ: 論文は、AI が実際にフォルダを移動しファイルを読み取る必要がある場合（「ファイルシステム」モード）、同じ情報が 1 つの巨大なテキストのブロックに貼り付けられた場合よりもパフォーマンスが低下することを発見しました。これは、情報を発見し整理すること自体がスキルであり、単なるフォーマットの問題ではないことを証明しています。

結論

この論文は、完璧なプロンプトからコードをどの程度書けるかだけで AI をテストすることはできないと結論付けています。現実の産業（物流、製造、金融など）で有用であるためには、AI は以下の能力についてテストされる必要があります。

散らかった書類の山から正しい情報を見つけること。
壊すことなく古いシステムを更新すること。
作り話ではなく、実際のファイルからの証拠を用いて、その決定を説明すること。

OR-Space は、これらの AI エージェントに対する新しい「運転免許試験」であり、彼らをパーキングエリア（完璧なプロンプト）から、混雑した都市の通り（実際の作業スペース）へと移動させるものです。

技術的サマリー：OR-Space

問題定義

オペレーションズリサーチ（OR）における大規模言語モデル（LLM）エージェントの既存ベンチマークは、実世界の産業ワークフローの複雑さを過度に抽象化している。現在の評価は通常、OR タスクを「ワンショット」問題に還元し、エージェントが自己完結型のテキストプロンプトを数学的定式化またはソルバーコードに変換するものとしている。このアプローチは、産業用 OR を特徴づける 2 つの特性を捉え損なっている：

ワークスペース設定：実世界のエージェントは、ビジネス要件、構造化データ（CSV/JSON）、コード成果物、ソルバーからのフィードバック、そして複数のファイルに分散したステークホルダーとの相互作用を含む、永続的でマルチアーティファクトな環境内で動作する。
ライフサイクル設定：産業用 OR は反復的である。エンジニアは単に一度だけ解を生成するのではなく、初期モデルを構築し、変化するビジネスルールやソルバーからのフィードバックに応じてそれを修正し、結果としての意思決定を非専門家であるステークホルダーに説明する。

したがって、現在のベンチマークでは、エージェントがマルチアーティファクト・ワークスペース全体およびモデリングライフサイクルの複数の段階にわたって信頼性の高い最適化作業を実行できるかどうかを判断できない。

手法

著者は、産業用最適化エージェントを評価するために設計された、フルライフサイクルのワークスペースベンチマークであるOR-Spaceを導入する。この手法は、永続的な実行可能ワークスペースとライフサイクル指向のタスクパイプラインという 2 つの中核軸を中心に構成されている。

1. OR ワークスペースの形式化

OR ワークスペース（ $W$ ）は、構造化され、永続的で、実行可能な環境として定義される：
$W = \langle D, P, S, E, M \rangle$

$D$ （ドキュメント）：目標と要件を記述する自然言語アーティファクト（例：business_requirement.md）。
$P$ （パラメータ）：数値入力を含む構造化データファイル（CSV、JSON）。これらは通常、クリーニングとスキーマの整合性を取る必要がある。
$S$ （コード）：ヒューリスティックスクリプト、部分的なテンプレート、またはレガシー実装を含むコードアーティファクト。
$E$ （環境）：ファイル入出力、ソルバー実行（Gurobi、COPT、PuLP、HiGHS）、およびリソース制約をサポートする Docker ベースのサンドボックス。
$M$ （メトリック）：ベンチマークハーネスによって使用される評価指標（エージェントからは非公開）。

すべてのコンテキストを単一のプロンプトにシリアライズする先行ベンチマークとは異なり、OR-Space はエージェントに、これらの分散されたアーティファクト全体にわたって情報を検索し、接続し、根拠付けることを要求する。

2. ライフサイクル指向タスクモード

OR-Space は、IndustryOR ベンチマークから拡張された 100 の基本問題に由来する、3 つの逐次タスクモードを定義する：

構築（ $T_{Build}$ ）：エージェントは、ビジネスドキュメントとデータファイルを使用して、空のコードスケッフォールドからソルバー対応の最適化モデルをゼロから構築する。
修正（ $T_{Revise}$ ）：エージェントは、更新された要件のもとで既存の最適化ワークフローを修正する。これには、Revise-code（レガシーコードの修正）、Revise-model（定式化のみを修正）、Revise-all などのバリエーションが含まれる。エージェントは、新しい制約や変数を統合しつつ、有効な以前のロジックを保持しなければならない。
説明（ $T_{Explain}$ ）：エージェントは、ドキュメント、データ、コード、およびソルバー出力（例：双対変数、スラック値）に分散された証拠を用いて、解、制約、およびビジネスへの影響に関する根拠のある質問に回答する。

3. 評価プロトコル

構築および修正：ソルバーによるスコア付けメトリックを通じて評価される。提出物がエラーなく実行され、「Optimal（最適）」ステータスを返し、真のオラクルに対する相対的な目的関数の誤差が 1% 以下であれば、正解とみなされる。
説明：根拠に基づいた「LLM-as-judge（LLM を審判とする）」ルビリックを使用して評価される。スコアは、正確な網羅性（35%）、推論（35%）、根拠付け（20%）、回答の質（10%）、および幻覚ペナルティ（最大 -12）に基づいている。
失敗分析：フレームワークは、実行エラー、実行不可能な定式化、誤った目的関数、および忠実でない説明を含む、特定の失敗モードを記録する。

主要な貢献

限界の特定：既存の OR ベンチマークは、自己完結型のワークスペース設定とワンショットタスク設定に依存しており、実世界の産業ワークフローのマルチアーティファクトかつライフサイクル指向の本質を過小評価していることが特定された。
OR-Space ベンチマーク：要件、データ、コード、およびソルバー出力が複数のファイルに分散する、永続的な実行可能ワークスペースを中心に構築された新しいベンチマーク。
タスクモード：モデルの構築、保守、およびコミュニケーションを捉える、3 つのライフサイクル指向モード（構築、修正、説明）の定義。
評価フレームワーク：データ根拠付け、修正の一貫性、および説明の忠実性を含む、ワークスペースに根ざしたタスクにおけるエージェントの能力と失敗モードを分析するためのプロトコル。

結果

著者は、20 のモデル（クローズドソースの最先端モデル、小規模な API ベースモデル、オープンソースモデル）をベンチマーク全体で評価した。主な知見は以下の通りである：

ワークスペース根拠付けの難しさ：最先端のエージェントでさえ、ワークスペースに根ざしたモデル構築には苦労している。最高の構築スコアは 72.0%（gemini-3.1-pro）であり、ほとんどの最先端モデルは 53〜68% の範囲にとどまった。これは、クリーンなプロンプトと比較して、分散されたアーティファクトからデータスキーマとビジネスセマンティクスを復元することの難しさを浮き彫りにしている。
シグナル対ノイズとしてのレガシーコード：Revise タスクにおいて、強力なモデル（例：gpt-5.4、claude-opus-4-6）は、レガシーコードをシグナルとして活用することでパフォーマンスを向上させることが多かった（例：gpt-5.4 は 59% から 79% に改善）。一方、弱いモデルや「フラッシュ」モデルは、パフォーマンスが低下する傾向があった（例：gemini-3-flash は 23 ポイント低下）。これは、それらが実装の詳細をノイズとして扱ったり、ソルバーではないインポートをコピーしたりしたことを示唆している。
説明可能性の独立性：Explain におけるパフォーマンスは、Build および Revise のスコアとは弱い相関しか示さなかった（ $r \approx 0.16-0.28$ ）。実行可能なモデルを構築した一部のモデルは、それらを忠実に説明できなかった（例：gemini-2.5-pro は修正インスタンスの 69% を解決したが、説明スコアは 32.2 にとどまった）。
インターフェースの影響：フラットなプロンプトのシリアライズと比較して、ファイルシステムインターフェースを使用することは、コード生成タスク（構築および修正）のパフォーマンスをそれぞれ平均 8.2 ポイントおよび 12.2 ポイント低下させた。これは、ファイルの発見とスキーマの検査が、単なる表面的な問題ではなく、実質的な難しさであることを示している。
コンテキスト感受性：コードコンテキストに形式化された定式化を追加することは、一般的に強力なモデルには役立ったが、軽量モデルには悪影響を及ぼすことがあった。定式化のみのコンテキストは、コードベースのコンテキストよりも脆いことが判明した。

意義と主張

本論文は、孤立したテキスト生成から、堅牢でソルバーに根ざしたエンジニアリングワークフローへと、評価パラダイムを転換させる必要があるものとして OR-Space を位置づけている。著者は以下を主張する：

信頼性のギャップ：オープンでマルチアーティファクトなワークスペースをナビゲートすることは、現在の LLM エージェントにとって依然として極めて困難であり、テキストのみのベンチマークが大半を隠蔽しているデータマッピングと制約の根拠付けにおけるシステム的な失敗を露呈している。
実用性への準備：OR-Space は、産業用 OR の反復的かつ多段階的な性質をシミュレートすることで、最適化エージェントの実用性への準備度を測定するための厳密な基盤を提供する。
失敗モード：このベンチマークは、数学的モデリングエラー、データ根拠付けエラー、および幻覚された制約を区別する、失敗の微細な帰属を可能にする。これは、エージェントを実世界に展開する上で極めて重要である。

本研究は、LLM が孤立した定式化タスクでは有望な成果を示しているものの、永続的なワークスペースおよびフルライフサイクルにわたって信頼性の高い OR エンジニアリングを実行する能力は現在限られており、エージェントの信頼性、失敗モード、およびワークスペース相互作用に関するさらなる研究が必要であると結論づけている。