関数単位の修正箇所特定によるリポジトリレベルのバグ修正

日本において、IT人材の不足は深刻な問題であり、2030年には最大で79万人が不足するとされている1）。この課題を解決する方法の1つとして、LLMを用いたソフトウェア開発支援が考えられる。ソフトウェア開発は主にリポジトリレベルで行われており、ソースコードの管理や共同開発の効率化のためにGitHubなどのサービスが広く利用されている。開発中に発生する問題の管理・共有にはGitHubIssue（以下、Issue）が提供されており、開発者はバグの報告などを行うことができる。実在するリポジトリのIssueを集めた、Issue解決ベンチマークSWE-bench[1]を基に、LLMを活用した多くの手法が提案されている[2,3,4,5,6,7,8,9]。これらの手法は、LLMをエージェント化してIssue解決を指示する手法と、LLMエージェントを用いずにシステムを構築してIssue解決を試みる手法の二種類に分類される。本研究ではエージェントを用いない手法に注目する。エージェントを用いないシステムでは、コード1）https://www.meti.go.jp/policy/itpolicy/jinzai/houkokusyo.pdfベースから必要なファイルを検索し、修正箇所を特定し、修正する3ステップで処理されることが多い。従来の手法では、ファイルの検索や修正箇所の特定にリポジトリのグラフ情報[2]やモンテカルロ法[3]などを活用したものが提案されている。また、修正箇所の特定は行単位、クラス単位、関数単位など、多様な粒度で行われてきた。本研究では、LLMの並列性とSWE-benchLiteにおける正解データのパッチ(バグ修正に適用されるコード変更であり、修正前後の差分）の修正箇所が少ないという特性に着目し、LLMエージェントを用いない新たな手法を提案する。我々の検索手法では、グラフ情報などを用いずに、複数のLLMの結果をアンサンブルするシンプルな手法によって、高精度なファイル検索および関数単位の修正箇所の特定を実現する。また、特定した関数を、独立に修正する手法を提案する。SWE-benchLiteにおいて、本手法は25.3%のIssue解決率を達成した。ファイルの検索と関数の特定は高精度であったが、バグ修正の精度は他の手法と比較して、大きな改善は見られなかった。