Kozuchi、同一27Bコード修復エージェントをJavaへ展開、Multi-SWE-benchで128問中41問を解決

富士通の研究チームはKozuchi Agentの論文を正式に発表し、これまでPythonで公開していたコード修復の成果をJavaへ拡張した。システムの中核には、ローカルでホストされ、追加のファインチューニングを施していないQwen3.5-27Bを採用。周辺構成は単一のReActループではなく、8段階のワークフロー、ファイルベースの永続状態、決定論的なソフトウェアエンジニアリングツール、モデル非依存のアクションインターフェースから成る。CIパイプラインが推論の起動、評価、トレースの保存を担う。

Kozuchiは各問題を8回実行し、それぞれの実行でパッチとテストを同時に生成したうえで、そのテストをほかの候補パッチにも交差適用する。この選択器は非公開の評価結果を参照せず、別途学習したverifierも必要としない。SWE-bench VerifiedのPythonテスト500問では、8回の実行における平均Pass@1は67.7%、少なくとも1回成功する理論上限は81.6%だった。選択器が最終的に提出したパッチは374問、すなわち74.8%を解決し、常に最初の候補を選ぶ方式より14問多かった。一方、正しい候補がすでに存在したにもかかわらず選択できなかったケースも34問あった。

さらに注目すべきなのが、言語をまたいだ結果だ。研究チームは同じモデル、ステージグラフ、状態フォーマット、8候補戦略を維持し、テスト環境のみをMaven／Gradleに変更した。その結果、Multi-SWE-bench Javaでは128問中41問を解決し、成功率は32.03%だった。エージェントが各段階で使用したメッセージの割合は、PythonとJavaの間で差が5パーセントポイント以内に収まっており、プロセス構造自体が実際に移植できたことを示している。しかし、Javaの絶対成功率はPythonより42パーセントポイント以上低く、elastic／logstashの38ケースはすべて失敗した。このため著者らは「フレームワークは言語をまたいで利用できる」とのみ主張し、モデルが両言語で同等の習熟度を持つとはしていない。

エンジニアリングチームが留意すべき点は2つある。第一に、候補生成と選択器そのものが、基盤モデルだけでなく主要な性能調整要因になっている。第二に、論文が実施したアブレーションは候補数と選択シグナルを対応させたものに限られ、段階化、永続状態、ツールスイートそれぞれの因果的な寄与はまだ切り分けられていない。また、結果は公開ベンチマークに基づくものであり、非公開コードベースを対象にした開発者実験や本番環境のテレメトリーはまだ提示されていない。