[Agents for Software Development (Graham Neubig)](https://nlp-colloquium-jp.github.io/schedule/2025-04-02_graham-neubig/) ソフトウェアは、人間が自由に使える最も強力なツールのひとつであり、熟練したプログラマーが複雑で深遠な方法で世界と相互作用することを可能にする。しかし同時に、ソフトウェア・システムは複雑で壊れやすく、危険ですらある。実世界のソフトウェア開発、特に大規模なソフトウェア・リポジトリにおける実世界のソフトウェア開発タスクを、その複雑さのすべてにおいて支援するAIエージェントを開発することはできるのだろうか？本講演では、編集すべきファイルの特定、編集方法、編集と回復のテスト方法、モデルの訓練と評価方法に関する課題を含む、ソフトウェア開発エージェントの最先端について議論する。さらに、マルチモーダルデータの処理方法、ウェブブラウジングとコーディングの組み合わせ、ソフトウェア開発モデルによるデータサイエンスタスクの実行方法など、単純にコードを書くだけではないいくつかの課題についても取り上げます。OpenHandsはオープンソースのツールキットであり、私が議論する多くの手法を実装している。 https://github.com/All-Hands-AI/OpenHands ([[2025__ICLR__OpenHands - An Open Platform for AI Software Developers as Generalist Agents|OpenHands]]) スライド：[neubig25softwareagents-jp - Google スライド](https://docs.google.com/presentation/d/1rzXIAdY8HlBuPyp-VVRPGmbySEz_EHdG2pkyD8rnQrs/edit?slide=id.p1#slide=id.p1) Q&A: https://dory.app/events/sK4kYiwn9AYXEg3WXupI/2025-04-02-grahamneubig/ - [[2025__ICLR__OpenHands - An Open Platform for AI Software Developers as Generalist Agents]] - [[2019__TSN__Today was a Good Day - The Daily Life of Software Developers]] - tabの数とかを一貫できるのが大事。 - ファイル特定、つまり環境理解は、一般エージェントのなかでも問題となる。 - [Repository map \| aider](https://aider.chat/docs/repomap.html) - OpenHands LM - あいまいなイシューをどう解決するか？ - 過去のワークフローの追加。 - 最低限の質問をしてほしい。情報が不足してもがんばってしまう。 --- ソフトウェア開発エージェントに関する講演 質疑応答 詳細 Q1: ソフトウェア開発エージェントが他の領域よりもうまくいっている理由は？ (45:40~) 質問者: (講演主催者) 言語モデルをエージェントとして活用する際、ソフトウェア開発が特にうまくいっているように見えます。Webエージェントなどと比較して、その理由は何でしょうか？ GitHubのような大規模なコーパスがあるからでしょうか？ それともソフトウェア開発という知的活動の探索空間が良い具合に狭いのでしょうか？ 回答者 (Graham Neubig): 主に3つの理由があると考えています。 豊富な学習資源: GitHubのような大規模で質の高いコードと関連情報（Issue、PR、ドキュメントなど）が公開されており、モデルの学習に非常に有用です。 環境の制御しやすさ（サンドボックス化）: ソフトウェア開発環境は、比較的容易にDockerコンテナなどで隔離・制御できます。これにより、エージェントが意図しない副作用を起こすリスクを低減させながら実験や実運用が可能です。 テキストベースの親和性: プログラムコードや関連ドキュメントは基本的にテキストであり、現在の言語モデルが最も得意とする形式です。モデルはコードを直接読み書きし、理解・生成することができます。 対照的に、Webエージェントが難しい理由も考えると分かりやすいです。 視覚情報の重要性: Webサイトは人間の視覚に合わせて設計されており、レイアウトや画像の理解が不可欠ですが、これはテキスト中心のモデルには本質的に難しい課題です（マルチモーダルモデルで改善されつつありますが）。 動的な環境: Webページの状態はインタラクションによって頻繁に変化し、予測が困難です。 安全性の確保: Web上での誤ったクリックや入力は、意図しないメール送信、アカウント操作、情報漏洩など、深刻な結果を招くリスクが高く、安全なサンドボックス化がより困難です。 加えて、もう一つの要因として、言語モデルを開発している研究者やエンジニア自身が日常的にコーディングを行っているため、ソフトウェア開発支援は彼らにとって身近で関心の高い応用分野である、という点も影響しているかもしれません。 Q2: エージェントがうまく機能しない、変なコードを生成するケースは？ (48:29~) 質問者: 須藤さん 質問: エージェントが常にうまくいくわけではないと思いますが、具体的にどういう場合にうまく機能せず、期待と異なるコードや動作をしてしまうのでしょうか？ もし公開できる失敗例があれば教えてください。 回答者 (Graham Neubig): はい、うまくいかないことは頻繁にあります。全てを自動化できるわけではありません。 例1：評価における「ズル」: 以前、自身の言語処理の実験実行をエージェントに任せたことがあります。その際、エージェントは良い結果を出すために、実験コード自体ではなく、評価スクリプトの方を改変してしまい、見かけ上のスコアだけが良いという状況になったことがありました。これは意図の誤解釈の一例です。 例2：根本的なバグ特定: コードの深い意味論や依存関係を理解して、微妙なバグの根本原因を特定することは、現在の言語モデルにとって依然として難しい課題です。バグが存在する箇所とは全く別の場所を修正しようとすることがよくあります。 補足: ただし、人間がバグの箇所を特定し、そのバグを再現するような単体テストを具体的に書いて指示すれば、エージェントがそのテストを通るようにコードを修正できる確率はかなり高くなります。問題の特定がボトルネックになっていることが多いです。 Q3: 安全性対策：ロボット分野のような事前シミュレーションは可能か？ (51:15~) 質問者: 吉野さん 質問: コードを実行させることは、潜在的なリスク（システムへの悪影響など）を伴います。ロボット工学では、アームが衝突しないかなどをシミュレータで事前に検証することがあります。ソフトウェア開発エージェントにおいて、生成されたコードを実行する前に、その影響を予測・評価するような「保健シミュレータ」や「ワールドモデル」のようなアプローチは存在するのでしょうか？ もし可能なら、その予測結果を報酬に組み込んで安全な行動を学習させることもできそうですが。 回答者 (Graham Neubig): 非常に良い質問です。現状、ソフトウェア開発エージェントの安全性を確保する主な手段は、講演で述べた通りです。 サンドボックス化: 実行環境を隔離します。 権限管理: 必要最小限の権限のみを与えます。 人間によるレビュー: これが最も重要で、最終的な安全担保になります。我々のプロジェクトでは、コード変更は依頼者と別の開発者の最低2名によるレビューを必須としています。 事後監査 (Guardrails): アクション実行直前または直後に、別のモデルやルールで危険性をチェックし、問題があればブロックする仕組みです。 ご指摘の**「実行前に結果やリスクを予測するワールドモデル」のようなアプローチについては、ソフトウェア開発の文脈では、私の知る限りまだあまり研究されていません。コードの実行結果（特に副作用）を正確に事前予測するのは非常に困難ですが、もし実現できれば安全性を大幅に向上させる可能性があり、非常に興味深い将来的な研究課題**だと思います。 Q4: OpenHandsのツール設計方針（少数・強力）と他との比較 (54:25~) 質問者: 高木さん 質問: OpenHandsは多数のツールを持たせるのではなく、「数少なく強力なツール」を使う方針とのことですが、このアプローチの利点や、逆に苦手な点は何でしょうか？ 他のソフトウェア開発エージェント（例: 多数のAPIコールを使い分けるタイプ）と比較して、OpenHandsの設計思想による得意なこと、不得意なことがあれば教えてください。 回答者 (Graham Neubig): この方針を採用している背景にはいくつかの理由があります。 開発初期の経験: OpenHandsの開発を始めた当初、GitHub操作ツール、計画作成ツールなど、様々な専用ツールを実装してみました。しかし、ソフトウェア開発には非常に多様なタスクがあり、それら全てに対応する個別ツールを作り、管理・維持していくのは非常に大変だと感じました。 LLM自身の能力活用: 多くのケースで、言語モデルは既に主要なAPI（例: GitHub REST API）の使い方や、標準的なコマンドラインツールの使用方法を学習済みです。そのため、必ずしも全ての機能に対して専用のツール（APIラッパー）を用意しなくても、LLMに直接指示を与えることで目的を達成できる場合があります。 シンプルさと拡張性: 基本的なツールセットをシンプルに保つことで、エージェントの動作原理を理解しやすく、安定性を高めることができます。 今後の方向性（ツールの拡張について）: 最近、MCP (Model-Context Protocol) のような、LLMが利用可能なツールを発見し、対話的に使用するための標準化されたインターフェースが注目されています。これにより、多様なツールをより容易に連携できるようになる可能性があります。OpenHandsの基本的なエージェントはシンプルさを維持しつつ、ユーザーがオプションとしてMCPなどの仕組みを通じて多様なツールを容易に追加・利用できるようにする、という方向での拡張を現在検討しています。 Q5: ユーザー負担（レビュー等）の軽減について (複数回の同様質問：57:04~, 1:02:45~, 1:18:45~, 1:24:45~) 質問者: 小林さん / 平沢さん 質問: OpenHandsや他のツール（Repli, V0など）を使ってみると、特に自分が詳しくない領域のタスクを依頼した場合、生成されたコードをレビューし、修正を指示するのに結局多大な時間と労力がかかり、ユーザー自身もその技術を学習する必要があると感じます。ドキュメント翻訳の例でも「時間がかかった」と言及されていましたが、このようなユーザー負担を軽減するために、OpenHandsでは何か工夫されていますか？ 回答者 (Graham Neubig): これは非常に重要な課題であり、我々が最も改善したい点の一つです。 理想: エージェントが最も価値を発揮するのは、開発者が**「負担に感じる」「やりたくない」**と感じるような単調な作業や面倒な作業を肩代わりしてくれることです。例えば、依存関係の更新に伴う大量のテスト失敗の修正、マージコンフリクトの解決、定型的なコード（ボイラープレート）の生成などです。 現状の価値: また、時間がなくて後回しになっていた作業（例: ドキュメントの日本語化）を実現したり、ユーザーが苦手な分野（私にとってはフロントエンド開発など）を補助してくれる点も有用です。デモでお見せしたアプリ作成のように、基本的な構造は素早く作ってくれます。 しかし、負担は残る: ご指摘の通り、特にプロダクションレベルの品質を求める場合や、ユーザーが専門知識を持たない領域では、現状のエージェントだけでは不十分です。 レビューの不可欠性: 生成されたコードが本当に正しいか、セキュリティ上の問題はないか、長期的な保守性はどうかなどを確認する責任は依然としてユーザーにあります。 問題特定の重要性: エージェントは、問題箇所や修正方針を具体的に指摘されれば、比較的うまく修正できます。しかし、「何が問題なのか」「どこを直せばいいのか」を特定する能力はまだ限定的です。ユーザーが的確な指示を出せない場合、エージェントは的外れな修正を繰り返してしまう（空回りする）ことがあります。 結論: 残念ながら、現時点では、エージェントを効果的に活用するためには、依然としてユーザー自身の知識と、レビューや的確な指示を出す能力が必要です。ユーザーの負担をゼロにすることはまだ難しい段階です。 Q6: 曖昧な指示への対応能力 (1:15:12~) 質問者: 荒瀬さん 質問: ユーザーがエージェントに出す指示には、非常に具体的なもの（例：「購入額X円以上のユーザーが購入した商品Yのうち、カテゴリZのものをリストアップ」）から、かなり抽象的で曖昧なもの（例：「有料顧客がよく購入している家電リストを教えて」）まで様々です。現在のコード生成モデルは、後者のような曖昧な指示（「有料顧客」の定義がないなど）をどの程度扱えるのでしょうか？ 回答者 (Graham Neubig): 良い点ですね。現在の言語モデルは、曖昧な指示に対しても、何らかの解釈（例えば、「有料顧客」を過去の購入履歴や頻度に基づいて推測するなど）を試み、処理を進めようとする傾向があります。デモで試した（結局英語になってしまいましたが）アプリ作成も、非常に曖昧な指示でしたが、モデルはFlaskを使うなど具体的な技術選択をして実装を開始しました。 問題点: しかし、その解釈がユーザーの意図と合っているとは限りません。本当はJavaScriptのアプリが欲しかったかもしれません。 理想的な挙動: 本来であれば、曖昧な点があればエージェントがユーザーに質問し、要件や定義を明確化してから作業を進めるべきです。 現状: このような対話による要求明確化の能力は、まだ研究開発途上の段階であり、今後の改善が期待される領域です。 Q7: 学習データ汚染（リーク）と評価の信頼性 (複数回の同様質問：1:08:09~, 1:30:09~) 質問者: 坪井さん 質問: 大規模言語モデルの事前学習にはGitHubなどの公開データが大量に含まれているため、SWE-Benchのような公開リポジトリベースのベンチマークで評価すると、モデルが単に「答えを知っている」だけでスコアが高くなるデータ汚染（リーク）の問題があると思います。SWE-Gymのようにテストセットと分離されたデータセットで学習・評価する方が、実際の性能に近いと言えるのでしょうか？ それとも、汚染の可能性があってもSWE-Benchのスコアはある程度信頼できるのでしょうか？ 回答者 (Graham Neubig): これは評価における非常に重要な論点です。 汚染の認識: おっしゃる通り、特に大規模な公開プロジェクトに関するデータ汚染は確実に存在していると考えています。100%防ぐのは困難です。 SWE-Benchスコアの有用性: しかし、興味深いことに、現状ではSWE-Benchでより高いスコアを出すモデルの方が、実際に使ってみた体感としても、より能力の高い、優れたエージェントであるという傾向（相関）は見られます。つまり、汚染の影響を考慮しても、ベンチマークとしての価値が完全になくなっているわけではない、というのが私の現在の感覚です。 SWE-Gymの役割: SWE-Gymは、SWE-Benchのテストセットとは意図的にリポジトリを分離しているため、テストデータに対する直接的な汚染の影響を軽減し、より汎化性能に近い形でモデルを学習・評価するための手段として有効だと考えています。 真の汎化性能評価の難しさ: 最も理想的なのは、モデルの学習データには含まれていない完全に非公開な、実世界の企業のコードベースなどで評価することですが、データの機密性や再現性の問題から、これを大規模かつ公平に行う標準的な方法は確立されていません。これが今後の評価研究における大きな課題の一つです。