LLMを使ったソフトウェア改善の自動化

最近、研究者たちはソフトウェア開発の改善に向けて大きな進展を遂げてきたんだ。問題を要約したり、バグを再現したり、欠陥を見つけたり、プログラムを修正したりするための新しいツールや手法がたくさん生まれた。それらの自動化技術は、開発者の作業量を減らすのに役立っているんだ。特に、大規模言語モデル（LLM）と呼ばれる高度なツールの登場が、ゲームのルールを変えてしまった。これらのモデルはプログラミングアシスタントとして機能し、開発者がほとんど人間の入力なしにコードを書くことを可能にしているんだ。

でも、ソフトウェアエンジニアリングは単にコードを書くことだけじゃない。ソフトウェアのメンテナンスやアップデート、つまりバグを修正したり、新しい機能を追加したりすることも含まれる。この論文では、GitHub上の問題を自動的に解決する方法について話しているんだ。これにより、プログラムが自分自身で改善される可能性があるんだ。私たちのアプローチは、LLMと高度なコード検索技術を組み合わせて、プログラムへの修正やパッチを生成することを目指している。

LLM技術にだけ焦点を当てた他のアプローチとは違って、私たちはソフトウェアエンジニアリングに重点を置いている。プログラムを単なるファイルの集合としてではなく、抽象構文木（AST）として表現することで、問題をよりよく理解でき、コード構造を深く掘り下げることができるんだ。

私たちの方法では、クラスやメソッドの形式を使って、モデルが根本的な問題を理解し、効果的に文脈を取得できるようにしている。テストスイートがある場合、スペクトルベースの故障位置特定も活用できる。この技術は、どのテストが合格または不合格かを分析することで、バグがどこにあるのかを特定するのに役立つ。私たちはSWE-bench-liteというデータセットを調べて、300の実際のGitHub問題を分析したんだ。実験の結果、私たちのアプローチは、最近のAIコミュニティの取り組みよりも22-23%効果的にこれらの問題を解決できることが分かった。驚くべきことに、67のGitHub問題をそれぞれ12分以内で解決できたのに対し、開発者は通常、同様の問題を修正するのに平均で2.77日以上かかっているんだ。2294の問題を含むより大きなデータセットでも、私たちの方法は約16%の問題を成功裏に解決し、効果と効率の両面で最近の他のAIシステムを上回った。

#自動プログラミングを超えて

ソフトウェア開発タスクを自動化するアイデアは、長い間ソフトウェアエンジニアや研究者たちを魅了してきた。大きな課題は、プログラミング中にしばしば出てくるあいまいな自然言語の要件を正確に解釈することなんだ。自動テスト生成や自動プログラム修理などの関連分野にはいくつかの進展があるけど、GitHub Copilotのようなツールの登場が自動プログラミングへの新たな関心を呼び起こしている。

これは重要な質問を引き起こす。自動生成されたコードは、既存のプロジェクトに統合する際に信頼できるのか？もし信頼できないなら、この技術を改善するためにどんな手段が考えられるのか？一つの可能性は、自動生成されたコードを修正できるシステムを作ることだ。このことから、自律的なソフトウェアエンジニアリングの全体目標を実現するためにプログラム修理タスクの自動化が必要であることが示唆される。

プログラマーが手動でバグを見つけて修正するのにどれだけ時間を費やすかを考えると、完全に自動化されたプログラム改善を調査することを目指したんだ。具体的には、既存ソフトウェアの維持のためにバグ修正と機能追加を主要な焦点として特定した。これを実現するために、私たちはLLMをコードリポジトリから得たコンテキスト知識と組み合わせたアプローチを開発した。

私たちの方法は、リアルなGitHubの問題に直面したとき、LLMがまず自然言語の説明を処理し、関連するファイル、クラス、メソッド、またはコードスニペットを示すキーワードを探すというものだ。これらのキーワードを特定すると、複数の関連するコード検索APIを同時に呼び出して、コードコンテキストを収集するための構造化された戦略を採用するんだ。これらのAPIはAST分析に基づいてローカルで実行され、クラスシグネチャやメソッド実装の詳細など、重要な情報を取得できる。

各検索でコードコンテキストを徐々に引き出すことで、LLMは問題の理解を深めていく。プロジェクトのコンテキストが十分かどうかを確認した後、バグが存在する可能性のある場所を特定するための作業に進む。次に、別のLLMエージェントが問題のある場所とそれまでに集めたコンテキストに基づいて必要なパッチを構築する。

さらに、テストスイートが利用可能な場合、モデルはスペクトルベースの故障位置特定のようなデバッグ技術を活用できる。この分析はプログラム内の異なるメソッドにスコアを割り当て、それらがバグを含む可能性を示す。LLMはこの情報に基づいて特定のメソッドに焦点を当てて検索を行うことができる。

バグ修正や機能リクエストに関連する300のGitHub問題を含むSWE-bench-liteデータセットを調査したんだ。実験の結果、私たちは大規模なSWE-benchデータセット内での問題解決率が15.95%であり、SWE-bench-liteサブセット内では22.33%の成功率を達成した。全体的に、私たちの結果は、プログラム修理タスクの自動化に大いに貢献することを示している。

#関連文献

自動プログラム修理（APR）は、最近注目を集めている分野なんだ。様々な技術がバグのあるソフトウェアのパッチを生成し、与えられたテストスイートを通過させることを目指している。これには、探索ベースの手法、意味論に基づく手法、パターンまたは学習に基づく手法が含まれる。探索ベースのアプローチは、事前定義されたコード突然変異オペレーターを通じてパッチを生成することが一般的で、意味論に基づく技術はテストスイートの仕様に基づいて修理制約を定式化する。学習ベースの手法は、大規模なコードリポジトリを活用して、パッチ用の最も適切なコードトークンを予測するモデルを訓練する。

最近の研究では、自動プログラム修理にLLMを使用する方法が示されている。この方法は、バグのあるプログラムステートメントが既に知られていることを前提にしており、それらのパッチを生成することにのみ焦点を当てている。しかし、成熟したプロジェクトにおけるバグの位置を特定することは、複雑で重要な課題なんだ。

APR技術は業界で特定のドメインのバグ修正に成功しているが、リアルライフのソフトウェア問題には依然として苦しんでいるんだ。これらの技術の多くは高品質なテストスイートを必要とするが、それはすべてのケースで見つかるわけではない。さらに、自然言語の問題説明からの貴重な情報を利用していない。これらの課題に対処し、自律的なソフトウェアエンジニアリングに向けたステップを踏むために、私たちはリアルライフデータセットから引き出されたGitHubの問題の解決に焦点を当てた。

私たちのアプローチは、日常的なソフトウェアエンジニアリングタスクを効果的に処理する大規模言語モデルの能力を評価するベンチマークとして考えている。選択したデータセット内の各タスクは、特定の問題を修正する方法についての人間の開発者の洞察を含む、対応するプルリクエストとペアになったGitHubの問題を含んでいるんだ。

#モチベーションの例

私たちのアプローチがどのように機能するかを具体的な例で説明するね。Djangoのような問題追跡システムを取り上げて、新しい機能リクエストが提出されたと仮定する。このリクエストは、特定のクラスModelChoiceFieldに機能を追加することを目的としていた。この問題の説明は、「バリデーションエラーを発生させたときに無効な選択肢の値を表示するべきだ」と説明していたんだ。

この情報をもとに、私たちのツールは二段階で動作する：文脈の取得とパッチ生成だ。

最初の段階では、LLMエージェントがDjangoのコードベースから関連するコードコンテキストを収集する。問題の説明からキーナムを特定することから始めて、例えばModelChoiceFieldみたいなクラスやメソッドを見つけるんだ。可能なクラスやメソッドを特定した後、エージェントはそれらの定義や実装などの詳細情報を集めるために特定の検索APIを呼び出す。

収集したコンテキストを用いて、エージェントは二番目の段階に進む：パッチ生成だ。前のステップから得た情報を使って、必要な機能を組み込んだパッチを書くんだ。

最終的なパッチの書き方は開発者のパッチと異なるかもしれないけど、同じ目的を達成し、関連するテストケースを通過する必要があるんだ。

#AIプログラム改善フレームワーク

私たちのアプローチは、リアルライフのソフトウェア開発の文脈で機能するように設計されている。ユーザーがソフトウェアリポジトリ内のバグに関連する問題を報告すると、私たちのシステムは自動的にこれらの問題を分析し、関連するコードコンテキストを取得してパッチを生成する。これらのパッチは、最終的に人間の開発者によって検証されるんだ。もし私たちが開発者が現在扱っている問題のかなりの割合を自動化できれば、手作業を減らし、全体的な効率を改善できる。

全体的なワークフローは、いくつかの段階を含んでいる。まず、問題報告を受け取って、それにタイトルと説明を含め、対応するソフトウェアプロジェクトのコードベースも一緒に分析する。自然言語の文から要件を分析して、主に二つのタスクを実行する。最初は文脈の取得で、LLMエージェントを使って、大規模なコードベースを横断して関連するスニペットを見つける。これを実現するために、私たちは文脈取得APIのシリーズを開発したんだ。

これらのAPIは、クラスシグネチャやメソッドの実装に関するプロジェクトの重要な情報を収集できるようにする。文脈取得エージェントは、検索をナビゲートし、利用可能な文脈に基づいて各ステップで使用すべきAPIを決定するんだ。

検索が制御され、効果的に感じられるように、私たちは取得APIを呼び出すための層別戦略を考案した。このアプローチによって、LLMエージェントは既に収集された情報に基づいて意思決定を行いながら、探索方法を精緻化していくことができる。

十分なコンテキストを収集したら、次にパッチ生成段階に移行する。ここで、別のLLMエージェントが正確なコードスニペットを抽出し、初期の問題に対処するパッチを作成する。生成されたパッチが問題に遭遇すると、エージェントは事前定義された形式に従って有効なパッチを再試行することができる。

私たちのワークフローはテストスイートを必要としないが、テストが存在する場合には大きく恩恵を受けることができる。テストが存在することで、有用な実行ベースのフィードバックを提供し、関連するコードの探索や生成されたパッチの検証に影響を与えることができる。

#コンテキスト取得API

コンテキスト取得段階は、LLMエージェントがコードベースから関連スニペットを収集するために使用するAPIのシリーズに依存している。ユーザーは問題の説明に手がかりを提供することが多く、それはメソッドやクラス、ファイルの名前、あるいは短いコードスニペットであることがある。これらの手がかりは、正確な修正場所を直接示すわけではないが、問題に対する重要なコンテキストを明らかにすることができる。

LLMエージェントがこれらのAPIを呼び出すと、コードベース内のクラスやメソッド、コードスニペットを検索して、関連する結果を返す。文脈を管理し、焦点を絞るために、必要な情報のみを出力として返す。たとえば、クラス定義全体を取得するのではなく、クラスシグネチャだけを提供してエージェントを圧倒しないようにするんだ。

エージェントは、問題の説明と期待される出力をプロンプトにフィードバックすることで、これらのAPIとインターフェースする。エージェントがAPIを使用することを決定すると、API名のリストとそれに対応する引数を返す。これらのAPIからのレスポンスは、LLMエージェントが作業するコードコンテキストを構築するために収集される。

#層別コンテキスト検索

私たちのコンテキスト取得プロセスは、単一のAPI呼び出しに限られているわけではない。例えば、問題がメソッド名を言及している場合、そのメソッドの実装を検索するのが十分だと思えるかもしれない。しかし、一つのメソッドに焦点を当てると、不完全なコンテキストにつながるかもしれない。一方で、エージェントがすべてのAPI呼び出しを一度に実行すると、処理するのが難しいほどの膨大なコンテキストを受け取る可能性がある。

その代わりに、私たちは層別検索プロセスを推奨している。これにより、エージェントは必要に応じてAPIを反復的に呼び出すことができる。各層は現在のコンテキストから始まり、新しいコードスニペットが返されるたびに、既存のコンテキストに取り入れていく。

この反復的なプロセスは、問題の理解を徐々に深め、エージェントが関連するクラスやメソッドに焦点を当てるのを助け、最終的にコード内の問題のある場所を特定することにつながるんだ。

#分析強化型コンテキスト取得

プログラム分析技術を取り入れることで、私たちのワークフローを強化できると信じている。特に、スペクトルベースの故障位置特定（SBFL）は、合格したテストと不合格なテストの制御フローの違いに基づいて、コード内の潜在的な故障位置を明らかにする技術なんだ。テストスイートが利用可能な場合、私たちの手法と合わせてSBFLを使用するのが役立つ。

私たちの既存のコンテキスト取得戦略を置き換える代わりに、SBFLを補助的なステップとして利用している。LLMエージェントがコンテキスト取得フェーズに入る前に、SBFLによって特定されたメソッドを提供して、コード検索をサポートするんだ。この追加情報は、問題の説明に合致する疑わしいコードの場所をエージェントに通知することができる。

SBFL分析結果と現在の問題説明をクロスリファレンスすることで、LLMエージェントはより関連するメソッドに対する検索を優先することができる。結果的に、この組み合わせは、問題を解決するためのより正確なコンテキストを収集するのに役立つ。

#パッチ生成

十分なコンテキストが収集されたら、パッチ生成段階に入る。ここで、LLMエージェントは集めたコードコンテキストを活用して、問題文で示された問題に対処するパッチをドラフトする。エージェントは、特定のバグのある場所から具体的なコードスニペットを取得し、パッチを生成するための再試行ループに入る。

生成されたパッチが期待される形式に合わない場合や、構文エラーのために元のコードに適用できない場合、エージェントは適切なパッチを再試行する。プロセス中にインデントエラーなどの特定の問題をチェックするために、リントツールを取り入れるんだ。

エージェントは、事前定義された試行回数までパッチ生成を再試行できる。再試行ループを抜けると、プロセス全体で最も有望なパッチを返すんだ。

#実験設定

私たちのアプローチの効果を評価するために、最近の手法に対してベンチマークを行い、リアルライフのソフトウェア問題をどれだけ解決できるかを確認した。SWE-benchとSWE-bench-liteデータセットを利用し、それぞれ2294件と300件のGitHub問題を含んでいる。

評価では、元のGitHub問題に提供された自然言語の説明だけを考慮し、対応するバグのあるコードリポジトリと比較した。効果を評価するために、二つの確立されたシステムと私たちのパフォーマンスを比較した。

信頼性のある結果を得るために、実験を何度も行い、その結果を平均化した。評価指標には、解決されたインスタンスの割合、平均時間コスト、および平均トークンコストを含め、リアルワールドの問題を解決する際の効果と効率を反映させた。

#全体的な効果

私たちは、解決されたタスクインスタンスの数に関するアプローチの全体的な効果を測定することから始めた。現在のAIシステムがどれだけ自動的に日常的なソフトウェアの問題を解決できるのかを調べたんだ。

実験では、フルSWE-benchデータセット内での問題解決率が15.95%だったのに対し、SWE-bench-liteサブセット内では22.33%の成功率を達成し、私たちのメソッドの効果を示した。私たちの結果は、他のシステムと比較しても、効果と時間効率の両面で優れていることが分かった。

例えば、私たちは67件の問題をそれぞれ12分以内で解決した。一方で、開発者は通常、同様の問題を修正するのに平均で2.77日以上かかっているんだ。私たちの結果は、ソフトウェア修理プロセスの自動化の潜在的な利点を明らかにしている。

#妥当で適切なパッチ

生成されたパッチの質は、自動プログラム修理において重要な考慮事項なんだ。妥当なパッチは関連するテストスイートを通過し、適切なパッチは開発者の意図した修正と意味的に同等であることが求められる。パッチの質を評価するために、私たちのアプローチによって生成されたパッチの正確性を手動で確認した。

分析の結果、私たちのシステムが生成したパッチの約65.7%が正確であり、他のものは期待される基準を満たさなかった。これに対し、ベースラインシステムはわずかに高い正確性を示していた。これは、私たちの方法が有望である一方で、高品質なパッチ生成にはまだ改善の余地があることを示している。

#SBFLの効果

SBFLのようなプログラム分析技術を使用することの利点を理解するために、文脈取得フェーズでSBFL情報の有無による比較実験を行った。結果は、SBFLを組み込むことでタスク解決の成功率が向上することを示した。

SBFLの洞察が利用可能な場合、私たちのアプローチは生成されたパッチの検証にのみ依存する場合よりも、より多くのユニークなタスクインスタンスを解決できた。このことは、複数の技術を組み合わせることで良い結果が得られ、最終的にプログラム改善がより効果的になることを示唆している。

#リアルライフタスクの課題

成功しなかったタスクインスタンスを調査し、課題を分類して、完全自動化されたソフトウェア改善を達成する上での実際の困難を明らかにした。

私たちの分類では、故障位置特定ステージとパッチ生成ステージの両方で問題が発生していることが強調された。生成されたパッチが正しいメソッドを修正したが、有効な結果を生成できなかったケースが多く見られた。これは、今後の改善のために、より詳細な分析と指導が必要であることを示している。

誤った場所でパッチが生成されたり、不適切なファイルに対する修正が行われるといった追加のカテゴリーも出てきた。これらの失敗は、問題説明の情報が不十分であることに起因し、これらの複雑なケースに対処するために一定の人間の関与が有用かもしれない。

#改善に向けた議論

私たちのシステムの将来的な改善の可能性について考えを巡らせると、成長と進展のためのいくつかの分野を特定できる。例えば、一つの有望な方向は、初期の問題説明に基づいてバグ再現テストを作成することだ。このテストは生成されたパッチの正確性を検証し、必要に応じて再生成プロセスをトリガーできるかもしれない。

さらに、プログラムの意味論をより効果的に活用して、文脈取得プロセスを情報提供するために静的分析ツールを利用して、追加の関連メソッドを特定することができる。高度なコーディングツールを統合することで、文脈取得エージェントはコードベースをより効率的にナビゲートできる。

最後に、LLMエージェントと人間の開発者の協力的な関係を育むことが、全体的なワークフローを改善するために重要なんだ。意思決定プロセスに人間の入力を許可することで、システムは障害を克服し、挑戦的な問題により効果的に対処できるようになる。

#結論

ソフトウェアエンジニアリングにおけるLLM技術の統合は、ソフトウェア開発やメンテナンスの向上に向けた強力な機会を提供している。バグ修正や機能追加などのプログラム改善の重要な側面を自動化することにより、開発者の負担を大幅に軽減し、ワークフローを効率化できるんだ。

私たちの提案したアプローチは、プログラム表現、反復的なコード検索、テストに基づく故障位置特定を活用して、自動プログラム修理の効率と効果を高めることに焦点を当てている。私たちの結果は相当な可能性を示しているが、パッチの質や文脈取得能力のさらなる改善が必要だ。

AI駆動のツールにますます依存するソフトウェア業界に進む中で、これらのシステムが人間の開発者と自動化されたエージェントとの間で信頼と協力を促進することが重要であり、ソフトウェア開発の未来をより効率的にする道を切り拓くことができる。