DevOps-Gym: Benchmarking AI Agents in Software DevOps Cycle
本論文は、AIエージェントをフルDevOpsワークフローにおいて評価するために、30以上のJavaおよびGoプロジェクトにわたる700以上の実世界のタスクで構成される初のエンドツーエンドのベンチマークであるDevOps-Gymを紹介し、現在の最先端モデルが、問題解決、テスト生成、モニタリング、ビルド構成といった複雑なタスクにおいて著しく苦戦することを明らかにしている。
原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む
想像してみてください。あなたは、個々の文章や段落を書くことに関しては驚くほど優秀な、素晴らしい新人見習いを持っています。あなたは彼に物語を書くよう頼み、彼は実に見事な仕事を成し遂げました。しかし今、あなたは彼が出版社全体を運営できるかどうかを見極めたいと考えています。これには、単に物語を書くだけでなく、印刷機をセットアップし、機械がオーバーヒートしていないか監視し、機械が詰まったときに修理し、次回の本で同じような詰まりが発生しないようにチェックリストを作成することまで含まれます。
これは、まさに論文「DEVOPS-GYM」がテストしていることです。
大きなアイデア： 「書き手」から「工場長」へ
長い間、AIは（見習いが文章を書くように）コードを書くことには長けてきました。しかし、実際のソフトウェアは単に書くだけではありません。それは、ビルド、モニタリング、デバッグ、テストといった、DevOpsとして知られるライフサイクル全体のプロセスです。これには以下が含まれます：
- ビルド（構築）: コードをコンパイルして実行できるようにすること。
- モニタリング（監視）: 実行中のプログラムを観察し、異常がないか（機械がオーバーヒートしていないかのように）確認すること。
- 修正: プログラムの問題をデバッグし、パッチを当てること。
- テスト: 修正が実際に機能し、他の部分を壊していないかを確認すること。
研究者たちは、700以上の実世界の課題を備えた巨大な「ジム（訓練場）」である「DEVOPS-GYM」を構築しました。彼らは、AIエージェントが単なる「書き手」ではなく、これら4つのステップすべてをこなすフルタイムの「工場長」として振る舞えるかどうかを調べたかったのです。
「ジム」の構成
研究者たちは、JavaとGo（AIの学習によく使われるPythonとは異なり、大企業で一般的な2つの言語）で書かれた実世界のソフトウェアプロジェクトを用いて、現実的な環境を作成しました。
彼らはAIのために4種類のワークアウトを設計しました：
- 「セットアップ」ワークアウト（ビルドと設定）: AIは、乱雑なプロジェクトを受け取り、それを正しくビルドできるようにしなければなりません。これは、説明書なしで複雑な家具を組み立てたり、道具のブランドを切り替えたりすることに似ています。
- 「サーベイランス（監視）」ワークアウト（モニタリング）: AIは実行中のプログラムを監視し、メモリリーク（プログラムがコンピュータのメモリを徐々に消費していく現象）やネットワークの遅延といった、微妙な問題を特定しなければなりません。これは、地下室が浸水する前に配管のわずかな漏れに気づかなければならない警備員のようなものです。
- 「リペア（修理）」ワークアウト（問題解決）: AIは、レポートに記載されたバグを見つけ出し、コードを修正しなければなりません。
- 「クオリティ・チェック（品質確認）」ワークアウト（テスト生成）: AIは、バグが解消されたことを証明するためのテストを作成しなければなりません。
さらに、彼らは「エンド・トゥ・エンド・パイプライン」タスクも作成しました。これはリレーレースのようなものです。AIは、セットアップを完了させ、次にサーベイランスを行い、次にリペアを行い、最後にクオリティ・チェックを行うという一連の流れを、バトンを落とすことなく一度に完遂しなければなりません。
結果： 見習いはまだ「初心者マネージャー」に過ぎない
研究者たちは、現在利用可能な最もスマートなAIエージェント（ClaudeやOpenAIのo4-miniなどのモデルを使用）をテストしました。その結果、以下のことが判明しました。
- 「セットアップ」は困難: 最善のAIであっても、プロジェクトを正しくビルドさせることに苦戦しました。AIは、コードをコンパイルするための複雑なルールに混乱することがよくありました。最高のエージェントでも成功率は約**52%**にとどまりました。
- 「サーベイランス」は悪夢: これが最大の失敗でした。AIは実行中のシステムを監視することに極めて弱かったのです。AIは問題を察知できなかったり、注意が逸れたりすることがよくありました。成功率は衝撃的に低く、しばしば**0%から20%**でした。それは、まるで警備員が居眠りをしたり、間違ったカメラを見ていたりするようなものです。
- 「リペア」は言語に依存する: AIは（学習中に多く目にする）Pythonのバグを修正することには長けていましたが、JavaやGoに切り替えるとパフォーマンスが著しく低下しました。これは、フランス語は完璧に話せるが、ドイツ語のテクニカルマニュアルの翻訳を頼まれるとつまずいてしまう翻訳者のようです。
- リレーレースは完全に失敗した: 4つのステップを連続して行うよう求められたとき、AIエージェントの成功率は**0%**でした。彼らは全体像を把握し続けることができませんでした。ビルドは修正できても、モニタリングの確認を忘れたり、バグを直してもテストの作成に失敗したりといったことが起こりました。
なぜ失敗したのか？
論文では、これらの「工場長」がまだ準備できていない理由として、いくつかの要因を挙げています。
- ツールを知らない: AIは、特定のシステムツール（メモリ使用量のチェックやビルドファイルの管理など）の使い方について、十分に学習されていません。
- 注意が逸れる: システムを長時間監視している間、AIは注視している対象を見失ってしまいます。システムが数時間にわたって稼働し続けるという「長い物語」を扱うことができません。
- 深い知識が欠如している: 単純なタイポ（打ち間違い）は直せても、大規模なソフトウェアシステムがどのように構築され、どのように動作するかという、深く複雑なルールを理解していません。
結論
DEVOPS-GYMは、現実を突きつける「リアリティ・チェック」です。AIはコードの断片を書くことには驚異的な能力を発揮しますが、現在のところ、ソフトウェア工場全体を自律的に運営する準備はできていません。AIは、実世界のソフトウェアをビルドし、監視し、修正し、テストするという、乱雑で複雑かつ長期的なタスクに苦戦しています。研究者たちは、AIが真にソフトウェア開発の全サイクルを自動化できるようになるには、さらなる多くの作業が必要であると述べています。
自分の分野の論文に埋もれていませんか？
研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。