TL;DR

LLMによる自動プログラム修正（APR）では、テストを通るパッチでも開発者パッチより平均で総変更量が約242%多いなど冗長になりがちです。本研究は、生成後のパッチを専用モデルで洗練する軽量アダプタRECAPを提案。4つの既存システムに適用したところ、修正成功率を保ちながら総変更量を+4.24%まで削減し、コードレビューしやすいパッチを実現しました。

解説

ねえ智也くん、このRECAPって論文、タイトルに「後処理で簡潔化」ってあるけど、要するに何をするの？

ああ、LLMが自動でバグ修正するとき、テスト通るパッチでもコードが冗長になりがちなんだ。それを専用モデルで後から簡潔に整えるのがRECAPだよ。

へー、でもなんで冗長になるの？テスト通ってれば十分じゃない？

テスト通るけど、開発者が書くパッチと比べて変更量が平均242%も多いんだ。レビューする人が読みにくいし、修正の意図が伝わりにくい。

なるほど、コードレビューの負担が大きくなるってことか。で、RECAPはどうやって簡潔にするの？

生成されたパッチを入力として、専用のモデルで「より簡潔なパッチ」に書き換えるんだ。軽量なアダプタだから、既存のAPRシステムに後付けで使える。

後付けってのがいいね。で、効果はどうだったの？

4つの既存システムに適用したら、修正成功率はほぼ保ったまま、総変更量を平均で+4.24%まで削減できた。つまり、ほぼ同じ成功率でコードが簡潔になった。

すごい！でも「+4.24%」って、削減なのにプラスなのは変じゃない？

ああ、これは元のパッチと比べての増加率だよ。元が242%増だったのが、RECAP後は4.24%増まで抑えられたって意味。

なるほど、それなら大幅に改善ってことだね。でも、どんなパッチでもうまくいくの？

そこが限界で、複雑なロジックの変更とか、複数ファイルにまたがる修正だと簡潔化が難しい場合がある。あと、アダプタ自体の学習データに依存するから、特定のスタイルに偏る可能性もある。

ふーん、完璧じゃないんだね。でも、レビュー負担を減らすのは大事だよね。私も将来コードレビューする立場になったら助かるかも。

そうだね。特に大規模なプロジェクトだと、簡潔なパッチはありがたい。

じゃあ、RECAPに「もっと簡潔に！」って頼んだら、私のレポートも短くしてくれるかな？

それは無理。レポートは自分で書きなよ。

The post LLM生成パッチを後処理で簡潔化するRECAP：修正能力を保ちつつコードレビュー負担を軽減 first appeared on 亜美と智也のAI論文解説.

TL;DR

STAIRは、過去の修正作業の記録（軌跡）を「詳細な行動」から「抽象的な戦略」まで階層的に整理し、新しい問題に合わせて具体的な修正計画を自動生成するフレームワークです。SWE-bench Verifiedで81.2%の成功率を達成し、別のエージェントにもそのまま転用できる汎用性を持ちます。

解説

ねえ智也くん、このブログのタイトル見た？「過去の修正履歴を再利用してコード修正AIの成功率を81%に引き上げる『STAIR』」って。すごくない？

ああ、STAIRの論文だね。確かに面白い結果だったよ。

でも私、AIに詳しくないからさ、なんで過去の修正履歴がそんなに役立つの？普通は新しい問題には新しい解決策が必要じゃない？

いい質問だね。STAIRは過去の修正作業の記録を「詳細な行動」から「抽象的な戦略」まで階層的に整理するんだ。つまり、具体的なコードの変更だけでなく、その背後にある考え方やパターンを学べるようにしている。

なるほど、つまり「このバグはこう直す」っていう具体的な手順だけでなく、「こういうタイプのバグはこうアプローチする」っていう戦略も学べるってこと？

その通り。それで新しい問題に合わせて具体的な修正計画を自動生成するんだ。SWE-bench Verifiedというベンチマークで81.2%の成功率を達成したんだよ。

81%ってすごいね！でも、それって特定のAIエージェントにしか使えないんじゃないの？

そこが重要なポイントで、STAIRは別のエージェントにもそのまま転用できるんだ。つまり、汎用性が高いってこと。

へえ、それは便利だね。でも、何か弱点とか限界はないの？

うーん、まだ完全ではないよ。例えば、過去の修正履歴が少ない分野では効果が薄いかもしれないし、複雑なプロジェクトではまだ課題があるみたい。

なるほどね。でも、それでもすごい進歩だと思うよ。私も将来AIを使った仕事がしたいなあ。

頑張ってね。でも、まずは基礎をしっかり学んだほうがいいよ。

はいはい、わかってるよ。でも、もしSTAIRみたいなAIができたら、私の宿題も自動で直してくれるかな？

それは無理だと思うよ。宿題は自分でやらないと意味がないからね。

The post 過去の修正履歴を再利用してコード修正AIの成功率を81%に引き上げる「STAIR」 first appeared on 亜美と智也のAI論文解説.

解説

ねえねえ智也くん！この『VulnResolver』っていう論文、名前が強そうで気になるんだけど、どんな内容なの？

ああ、それはAIを使ってプログラムのセキュリティの穴、つまり脆弱性を自動で直そうっていう研究だよ。最近のソフトは複雑すぎて、人間が全部直すのは限界があるからね。

自動で直してくれるなんて、ドラえもんの道具みたい！でも、今までもそういうAIってあったんじゃないの？

あったけど、課題が多かったんだ。自由すぎるAIエージェントは迷走して変な修正をしたり、逆にガチガチのプログラムだと柔軟な探索ができなかったり。あと、修正する場所を人間が教えないと動かないものも多かったんだよ。

なるほどねー。自由すぎてもダメだし、指示待ち人間……じゃなくて指示待ちAIでもダメってことか。それで、この論文はどう解決したの？

そこで『ハイブリッド』な仕組みを提案したんだ。全体の流れは安定した『ワークフロー』で管理しつつ、特定の難しい作業だけを専門の『エージェント』に任せるっていう形だね。

専門のエージェント？どんな子たちがいるの？

主に2人……というか2種類だね。1つは『CPCAgent』。これはプログラム全体を探索して、修正に必要なヒントや文脈を集めてくる役割。もう1つが『SPAAgent』。こっちがこの論文の肝で、『安全プロパティ』を分析するんだ。

アンゼンプロパティ？何それ、美味しいの？

食べられないよ。安全プロパティっていうのは、『このプログラムでは絶対にこういう悪いことは起きない』っていうルールのこと。例えば『データの箱のサイズを超えて読み込んじゃダメ』みたいなね。SPAAgentは、そのルールを自分で作って、実際にテストして検証までやるんだ。

へぇー！自分でルールを作ってチェックまでしちゃうなんて、しっかり者だね！それで、その結果はどうだったの？

SEC-benchっていう標準的なテストで、75%の問題を解決したんだ。これは既存の有名なツールよりもずっと高い数値だよ。特に、今までAIが苦手だった『どこを直すべきか』を見つける精度が、この2つのエージェントのおかげで劇的に上がったんだ。

75%ってすごい！じゃあ、もうエンジニアさんはお仕事しなくてよくなっちゃう？

いや、まだ課題はあるよ。非常に複雑な依存関係があるバグや、特殊な環境でしか起きない問題には対応しきれていない。今後はもっと複雑なケースにも対応できるように研究が進むはずだよ。

そっかー。でも、セキュリティが自動で守られる未来が来るなら安心だね！

よし、じゃあ私の『お菓子を食べすぎちゃう』っていう心の脆弱性も、VulnResolverでパッチを当てて直してもらおうかな！

それは脆弱性じゃなくてただの食いしん坊だろ。自分の意志でなんとかしろ。

要点

• ソフトウェアの脆弱性を自動で修正する新しいフレームワーク「VulnResolver」を提案した。
• 従来の手法は、修正場所を人間が教える必要があったり、AIエージェントが迷走して不安定だったりする課題があった。
• VulnResolverは、安定した「ワークフロー」と柔軟な「エージェント」を組み合わせたハイブリッド構成を採用している。
• 文脈を収集する「CPCAgent」と、安全ルール（安全プロパティ）を分析する「SPAAgent」の2つが、修正に必要な情報を整理する。
• ベンチマークテスト（SEC-bench Lite）で75%という高い解決率を記録し、既存の強力なツールを大幅に上回った。

The post AIがセキュリティの穴を自動修復！最強の助っ人『VulnResolver』登場 first appeared on 亜美と智也のAI論文解説.

解説

ねえねえ智也くん！この『セキュアなコード生成』ってタイトルの論文、なんか強そうじゃない？「セキュア」ってことは、鍵がかかってて安心ってこと？

まあ、意味としては近いかな。LLMが書くプログラムって、実は間違いだらけだったり、ハッカーに狙われやすい弱点があったりするんだよ。それをどうにかしようっていう研究だね。

えっ、AIなのに間違えるの？完璧超人じゃないんだ！プログラムが「安全じゃない」って、具体的にどういうこと？爆発したりするの？

爆発はしないけど、メモリを使いすぎてパンクさせたり、入力したデータが盗まれたりするんだ。GitHub Copilotみたいな有名なAIでも、40%くらいは危ないコードを書いちゃうっていう報告もあるんだよ。

40%！？結構な確率だね……。じゃあ、この論文はどうやってそれを解決したの？

「一人で考えさせない」のがポイントだね。この論文では、LLMにコードを書かせた後、3つの厳しい「先生ツール」にチェックさせるんだ。

先生ツール？どんな先生なの？

まずGCC。これはコンパイラで、文法ミスがないか見る「国語の先生」みたいなもの。次にKLEE。これはシンボリック実行といって、プログラムが論理的に正しいか、あらゆるパターンを試す「数学の先生」。最後にCodeQL。これはセキュリティの弱点を見つける「防犯の専門家」だね。

へぇー！その3人がかりでチェックするんだ。でも、ダメ出しされたらAIくん、落ち込んじゃわない？

落ち込む代わりに、そのダメ出しの内容を読んで自分で修正するんだよ。これを最大3回繰り返す。さらに、RAGを使って「過去にどうやって修正に成功したか」というお手本も検索して参考にするんだ。

なるほど！カンニングペーパーと先生の指導で、どんどん賢くなるわけだ。それで、結果はどうだったの？

すごかったよ。DeepSeekっていうモデルだと、セキュリティの脆弱性が96%も減って、ほぼ完璧になった。大きなモデルのCodeLlamaでも、半分以上あった欠陥が22%まで減ったんだ。

96%！？ほぼ全滅じゃん！でも、CodeLlamaくんはちょっと残っちゃったんだね。なんで？

論文では「頑固なモデル」って呼ばれてたよ。モデルが大きくなると、自分の書いた複雑なコードに固執しちゃって、先生の言うことを聞き入れにくい場合があるみたいだね。

あはは、AIにも反抗期があるんだ！面白いね。これって、これからどうなっていくの？

今後は、強化学習を使って「どう修正すれば効率がいいか」をAIに学習させたり、もっと複雑な大規模システムにも対応できるようにしていくみたいだよ。人間がチェックしなくても、AIが自分で安全なコードを書き上げる未来が来るかもね。

すごい！じゃあ、私の人生もRAGと3人の先生でチェックしてほしいな。「今日の晩ごはんの選択、栄養バランスが脆弱です！」とか言って修正してほしい！

それはただの口うるさいお母さんだろ。自分の生活くらい自分でデバッグしなよ。

要点

• LLMが生成するコードには、セキュリティの脆弱性や論理的なエラー、コンパイル失敗が頻繁に含まれるという課題がある。
• RAG（検索拡張生成）と、コンパイラ（GCC）、シンボリック実行（KLEE）、静的解析（CodeQL）という3つのツールを組み合わせた反復的な修正ワークフローを提案。
• DeepSeek-Coder-1.3Bではセキュリティ脆弱性を96%削減し、CodeLlama-7Bでも脆弱性率を58.55%から22.19%まで大幅に改善した。
• モデルを単体で使うのではなく、外部ツールによるフィードバックループに組み込むことで、追加の学習なしにコードの信頼性を劇的に向上させられることを示した。

The post AIが「自分で間違いに気づく」！？最強のプログラミング先生を作る方法 first appeared on 亜美と智也のAI論文解説.

解説

ねえねえ智也くん！この『DynaFix』っていう論文のタイトル、なんか強そうで気になる！ダイナミックに直すってこと？

ああ、これは自動プログラム修正、つまりAPRっていう分野の新しい研究だよ。AIを使ってプログラムのバグを自動で直す技術のことだね。

へー！AIが勝手にバグを直してくれるなんて、夢の技術じゃん！でも、今までのは何がダメだったの？

今までの手法は、コードの文字面だけを見る『静的解析』に頼りすぎていたんだ。でも、バグって実際に動かしてみないと原因がわからないことが多いだろ？

確かに！「書いた時は完璧だと思ったのに！」ってこと、私もあるよ。動かして初めて「あれ？」ってなるよね。

そう。既存の手法でもテスト結果を使うことはあったけど、「テストに落ちた」っていう大雑把な情報だけだったんだ。それじゃあ、複雑なバグは直せない。

じゃあ、このDynaFixはどうやって解決してるの？

DynaFixは『実行レベルの動的情報』をフル活用するんだ。変数の値がどう変わったか、どのルートを通ってエラーになったか、っていう細かい情報をAIに教えるんだよ。

なるほど！お医者さんがレントゲンだけじゃなくて、血液検査の結果も見ながら診断するみたいな感じかな？

いい例えだね。そのために彼らは『ByteTrace』っていうツールを作ったんだ。これは『バイトコード・インストルメンテーション』っていう技術を使っていてね。

ばいとこーど……いんすとる……？呪文？

簡単に言うと、プログラムの元の書き換えずに、実行中にこっそり中身を覗き見るための仕掛けを組み込む技術のことだよ。これで詳細なデータを集めるんだ。

へー！すごい！それで、どうやって直していくの？

まず、バグがあるコードとByteTraceで集めた実行データをAIに渡して、修正案を作らせる。もしその修正案がテストに落ちたら、またその時の実行データを集めてAIに渡すんだ。

あ、一回で諦めないんだ！何度もやり直すの？

そう。これを『反復的修正』と呼んでいる。人間がデバッグする時も、「ここを直してみよう、あ、まだダメだ、次はここかな」って繰り返すだろ？それをAIにやらせるわけだ。

まさに人間みたいだね！それで、結果はどうだったの？

Defects4Jっていう有名なテストセットで試したところ、186個のバグを直せた。これは最新の他手法より10%も高いし、今まで誰も直せなかったバグも38個解決したんだよ。

186個！しかも誰も直せなかったバグまで……！DynaFix、めちゃくちゃ優秀じゃん！

効率も良くて、修正案を探す範囲を従来より70%も減らせたらしい。無駄な試行錯誤が減ったってことだね。実行データがあるから、AIが迷わずに済むんだ。

これがあれば、エンジニアの人たちも楽になれるね！将来はどうなるのかな？

今は一つの関数の中にあるバグがメインだけど、将来的には複数の関数にまたがるもっと複雑なバグにも対応できるようになるはずだよ。ただ、実行データを集める分、計算コストがかかるのが課題かな。

なるほどね〜。あ、じゃあ私の「朝起きられないバグ」も、DynaFixで実行データを解析して直してほしいな！

それはプログラムのバグじゃなくて、ただの夜更かしだろ。生活習慣を自分でデバッグしなさい。

要点

• 従来の自動プログラム修正（APR）は、コードの見た目（静的情報）に頼りすぎており、実際に動かした時の挙動（動的情報）を十分に活用できていなかった。
• 提案手法の『DynaFix』は、プログラム実行時の変数の値や実行ルート、関数の呼び出し履歴などの詳細な情報をAIに与えて修正案を考えさせる。
• 一度で修正できなくても、失敗した時の実行データを再度取得してAIにフィードバックする『反復的な修正プロセス』を導入している。
• Javaプログラムを解析するための専用ツール『ByteTrace』を開発し、ソースコードを書き換えずに詳細な実行データを収集することを可能にした。
• 有名なバグ修正データセット『Defects4J』で評価し、既存の最新手法より10%多い186個のバグを修正。これまで誰も直せなかった38個のバグも解決した。

The post AIが名探偵に！？実行データでバグの正体を暴く『DynaFix』がすごい first appeared on 亜美と智也のAI論文解説.

ねえ智也くん、この「NExT: 大規模言語モデルにコード実行の推論を教える」という論文、何についてなの？

ああ、これはね、プログラムのコードを理解して、その実行を推論する方法を改善する研究だよ。具体的には、大規模言語モデルがコードの実行トレースを見て、どう動くかを理解するための新しい手法「NExT」を提案しているんだ。

実行トレースって何？

実行トレースは、プログラムが実行されるときにどの行がどう動いて、変数がどう変わるかを示すものだよ。これを理解することで、プログラムがどう動くかをより深く理解できるんだ。

へえ、それで、このNExTはどうやってそれを教えるの？

NExTは自己学習を使って、実行認識の根拠を合成する訓練セットを作るんだ。これにより、モデルが自然言語で推論を行いながら、正しいプログラムの修正方法を学べるようになる。

実験の結果はどうだったの？

実験では、NExTを使ったモデルがプログラムの修正率を大幅に改善したんだ。特に、理由の質も人間の評価者によって高く評価されたよ。

すごいね！これからの応用可能性は？

将来的には、さまざまなプログラミングタスクでこの技術が使われる可能性があるね。ただし、まだ解決すべき課題もあるから、研究は続けられるよ。

ねえ、もしロボットがプログラミングできたら、私たちのバグを直してくれるのかな？

それは、多分ね。でも、その前に君のバグを減らす努力も必要だよ。

要点

この論文では、大規模言語モデル（LLM）がコードの実行を理解し推論する能力を向上させる方法「NExT」を提案しています。

プログラマーがコードのデバッグや修正を行う際に、自然言語でコード実行をシミュレートするスキルが重要ですが、従来のLLMはコードの表層的なテキスト形式のみを学習していたため、実行時のセマンティックな理解が不足していました。

NExTは、プログラムの実行トレース（実行された行の変数状態）を調査し、思考の連鎖（CoT）による推論を通じて、その実行時の振る舞いについて推論することをLLMに教えます。

自己学習を用いて、正確なタスク解決につながる実行認識の根拠を合成する訓練セットをブートストラップします。

プログラム修正タスクにおける実験では、NExTがPaLM 2モデルの修正率を大幅に改善しました。

このモデルは、テスト時にプログラムトレースが存在しないシナリオにも一般化することができます。

参考論文: http://arxiv.org/abs/2404.14662v1

The post 大規模言語モデルにコード実行の推論を教える first appeared on 亜美と智也のAI論文解説.

ねえ智也くん、この論文のタイトル見て興味が湧いたんだけど、「大規模言語モデルを使った自動バグの局所化と修正」ってどういう内容なの？

ああ、これはね、プログラムのバグを自動で見つけて修正する研究だよ。特に、大規模言語モデルを使って、バグの正確な位置を特定し、それを修正する方法に焦点を当てているんだ。

大規模言語モデルって何？

大規模言語モデルは、大量のテキストデータから学習されるAIモデルで、文章の生成や理解が得意なんだ。この研究では、そのモデルを使ってコードのバグを特定しているわけ。

へえ、それで、どうやってバグを修正するの？

Toggleというフレームワークを使っているんだ。これはバグの位置を特定するモデルと、バグを修正するモデルを組み合わせたもので、入力されたバグのある関数から修正された関数を出力するよ。

結果はどうなの？

非常に良い結果を得ていて、特にCodeXGLUEというベンチマークで最先端の性能を達成しているよ。他のデータセットでも同様に良い成績を収めている。

将来的にはどんな影響があると思う？

この技術が発展すれば、ソフトウェア開発の効率が大幅に向上するだろうね。バグの修正が自動で行えるようになれば、開発者はより創造的な作業に集中できるようになる。

でも、完璧にはまだ遠いのかな？

そうだね、まだ解決すべき課題は多い。特に、さまざまな種類のバグに対応する能力をさらに向上させる必要があるし、より多くのプログラミング言語に対応させることも重要だよ。

ふーん、でも、バグが自動で修正されたら、プログラマーは仕事がなくなっちゃうかもね！

それは違うよ。プログラマーはもっと創造的な問題解決に集中できるようになるから、むしろ仕事の幅が広がると思うよ。

要点

この論文では、大規模言語モデル（LLMs）を使用して自動バグ修正（APR）を行う新しい手法について説明しています。

従来のAPR手法と異なり、この研究ではバグの位置をトークンレベルで予測し、それを修正するために異なるLLMsを使用します。

Toggleというフレームワークを導入し、バグの局所化モデル、調整ユニット、バグ修正モデルを統合しています。

Toggleは入力としてバグのある関数を受け取り、修正された完全な関数を生成します。

様々なスタイルのプロンプトを試し、最も効果的なプロンプトを特定しました。

ToggleはCodeXGLUEコードリファインメントベンチマークで新たな最先端（SOTA）性能を達成し、他のAPRデータセットでも優れた性能を示しています。

参考論文: http://arxiv.org/abs/2404.11595v1

The post 大規模言語モデルを使った自動バグの局所化と修正について first appeared on 亜美と智也のAI論文解説.