BC-Bench: Evaluating Agentic Engineering in a Domain-Specific Language for ERP
本論文は、Microsoft Dynamics 365 Business Central用のALドメイン固有言語を用いた101の現実世界のタスクで構成される新しいベンチマークであるBC-Benchを紹介し、汎用的なベンチマークにおけるエージェンティック・エンジニアリングの性能が、エンタープライズERPの文脈に確実に反映されるわけではないことを示し、ドメイン特化型の評価の極めて高い必要性を強調するものである。
原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む
現代のソフトウェアの世界では、新しい種類の労働者が登場しました。それは、コードを書き、エラーを修正し、自律的にプログラムを構築できる人工知能です。これらのシステムは、しばしば「コーディング・エージェント」と呼ばれ、人間が書いた膨大な指示のライブラリに基づいて学習しており、Pythonのような汎用プログラミング言語において驚異的なスキルを発揮しています。彼らは、かつて人間のエンジニアが解明するのに数時間を要したパズルを解くことができます。しかし、ビジネス・ソフトウェアの現実世界は、これほど単純ではありません。世界の商業を支える重要なインフラの多くは、ルールが異なり、ツールが独特で、リスクが高い、特定の業界向けに設計された専門的な言語に依存しています。その一つが、企業が在庫管理から給与計算まであらゆる事象を管理する、エンタープライズ・リソース・プランニング（ERP）の世界です。ここでは、MicrosoftのBusiness Centralシステムを動かすために使用される、ALと呼ばれる特殊な方言（言語）が話されています。長年、これらの強力なAIエージェントが、この複雑で独自の領域をナビゲートできるのか、あるいは、彼らの汎用コーディングにおける成功は、現実のビジネス上の制約に直面した際に消え去ってしまう現象なのかが不明確でした。
この問いに答えるため、Microsoftの研究者たちは、BC-Benchと呼ばれる新しいテスト環境を構築しました。彼らは理論的なパズルを考案したのではなく、実際のビジネスを動かしている2つの大規模なソフトウェア・リポジトリの、生きたコードを掘り下げました。これらのデジタルアーカイブから、エンジニアが過去に解決した101個の特定のタスクを慎重に選出しました。これらは作り物の例ではなく、顧客レコードの失敗を引き起こしたバグ、売上レポートにおける機能の欠落、あるいはエラーを検知するために記述する必要があったテストといった、本物の問題でした。研究者たちはその後、世界で最も高度なAIエージェントのいくつかに、これらと同じタスクへの挑戦を求めました。エージェントには、エラーのスクリーンショットが含まれることもある元の問題の説明と、修正前のコードのスナップショットが与えられました。彼らの目標は、人間のエンジニアが行うのと全く同じように、問題を解決するために必要な正確なコード変更を記述することでした。その後、システムはシミュレーション環境内でソフトウェアを実行し、新しいコードが他の部分を壊すことなく、実際に問題を解決したかどうかを確認しました。
結果は、AIモデルの「アイデンティティ」が、作業を行うために使用する特定のツールよりもはるかに重要であることを明らかにしました。研究者たちが異なるバージョンのエージェントを比較した際、エージェントの「脳」である大規模言語モデルの選択が、それを導くソフトウェアのラッパー（「ハーネス」）の選択よりも、成功に大きな影響を与えることが分かりました。例えば、最新のモデルの一つであるClaude Opus 4.6は、標準的なツールと組み合わせた場合にバグ修正タスクの約69パーセントを解決しましたが、同じモデルの古いバージョンでは約58パーセントしか解決できませんでした。対照的に、モデル自体は同じままツールを入れ替えても、統計的に有意な差は見られませんでした。このことは、これらの複雑なビジネス・タスクにおいては、モデルの知能こそが成功の主要な原動力であり、コードにアクセスするための特定のインターフェースではないことを示唆しています。
最も衝撃的な発見はおそらく、一般的なコーディングテストで見られる改善が、この専門的な世界に自動的に翻訳されるわけではないということでした。より広いソフトウェア・エンジニアリングの世界では、新しいモデルは以前のモデルに対して、着実で予測可能な進歩を示すことがよくあります。しかし、この特定のビジネス環境においては、一般的なベンチマークで前身のモデルを上回った最新モデルが、同様の優位性を示さないことがありました。一般的なタスクにおいて大幅に向上したあるモデルは、これらのビジネス・ロジックのパズルに直面した際、その優位性を示すことができなかったのです。これは、汎用的なPythonスクリプトを修正するために必要なスキルと、専門的なビジネス・システムにおける財務計算を修正するために必要なスキルは異なるということを示しています。データの流れやビジネス・ロジックの検証方法に関する厳格なルールを持つ専門的な言語の性質が、汎用的なトレーニングだけでは容易に克服できない障壁を生み出しているのです。
研究者たちはまた、エージェントが失敗した理由についても詳しく調査しました。彼らは、マシンがソフトウェアを構築できなかったり、コードがコンパイルできなかったりといった理由で失敗することは稀であることを見出しました。それらの技術的なハードルは容易にクリアされました。むしろ、失敗のほとんどは「問題の理解」に関するものでした。失敗した試みのほぼ半分において、エージェントは全く異なる部分のコードを見ており、エラーとは無関係なファイルを編集していました。また、別の大きな失敗グループでは、エージェントは正しいファイルと正しいコードセクションを見つけてはいたものの、依然として誤ったロジックを適用しており、見た目は正しくても実際のビジネス・ルールを修正できていない解決策を実装していました。例えば、エージェントは顧客の注文番号が欠落していることを正しく特定しながらも、誤った種類の番号を割り当てるコードを書き、結果としてシステムを壊れたままにしてしまうといったケースです。これらのエラーは、エージェントが企業の運営方法を定義する深く相互に関連したビジネス・ルールの網をナビゲートすることに苦慮しており、人間のエンジニアであれば即座に把握できるはずの微妙な文脈を見落としていることを示唆しています。
タスクの複雑さも決定的な役割を果たしました。修正が必要な箇所が単一のファイルや少数の行だけであった場合、エージェントは非常に高い成功率を誇りました。しかし、解決策が複数のファイルを変更したり、数十行以上のコードを書いたりする必要がある段階になると、成功率は急激に低下しました。この低下は劇的であり、タスクが複数のファイルに関わる場合、精度は20パーセント以上も下落しました。これらのエージェントは、孤立した小さな修理には対応できるものの、大規模で相互に関連したシステム全体にわたる変更を調整することには依然として苦戦しているようです。さらに、ビジネス領域の種類も影響していました。エージェントは倉庫ロジスティクスよりも在庫管理における問題の修正において高い成功率を示しており、これは彼らのトレーニング・データが特定のビジネス・ドメインにおいてより豊富であった可能性を示唆しています。
本研究は、人工知能が一般的なコーディングにおいて驚異的な進歩を遂げている一方で、専門的なビジネス環境における完全な自律的エンジニアリングへの道筋は、まだ明確ではないと結論付けています。ツールは存在し、モデルも強力ですが、汎用的な能力とドメイン固有の習熟度の間の溝は依然として広いです。研究者たちは、前進するためには、一般的なテストに頼るのではなく、これらの専門的なベンチマークに焦点を当てる必要があると強調しています。また、現在の限界は単なる生の知能の問題ではなく、文脈を理解し、複雑なコードベースをナビゲートし、正しいビジネス・ロジックを適用する能力の問題であると指摘しています。これらのシステムが進化したとき、彼らが現在一般的なプログラミングで見せているような容易さで、ビジネス・ソフトウェアの複雑なルールをナビゲートできるようになることが期待されますが、今のところ、人間のエンジニアは現実世界の複雑さを導くために不可欠な存在であり続けています。
自分の分野の論文に埋もれていませんか？
研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。