うん、でも正確には、LLMが静的解析で見つけた脆弱性の候補を、実際に動かして確認できるかどうかを試したんだ。対象はAutowareっていう自動運転のオープンソーススタック。

Autowareは複雑な依存関係があって、ビルド環境を整えるのが難しいんだ。LLMはコードの断片は書けるけど、プロジェクト全体のビルド設定を理解して統合するのが苦手みたい。

そう言えるね。論文では、ビルド統合が最大の壁だと結論づけてる。現状ではLLM単独での動的確認は信頼できないから、静的解析による安全性レビューの方が有効だって。

確かに。だからこそ、人間のレビューが重要だって論文も言ってる。LLMはあくまで補助ツールとして使うのが現実的だね。

まあ、ビルドができれば苦労しないよ。でも、そのうちできるようになるかもしれないけどね。

簡単に言うと、悪意のあるNPMパッケージを検出するための手法だよ。従来の静的解析だけじゃなくて、動的解析も組み合わせて行動グラフを作るのがポイント。

パッケージが実行する処理の流れをグラフ構造で表現したもの。例えば、ファイルにアクセスする、ネットワーク通信する、みたいな動作をノードにして、その順序をエッジでつなぐんだ。

まずコードをスライスして、それぞれに証拠を付与する。その後、ローカル判断とグローバル判断をLLMエージェントが行って、さらに自己無撞着検証で整合性を確認する。最後に動的補完で実際に動かして確認するんだ。

そうだね。LLMに依存してるから、モデルが更新されたりバイアスがあったりすると結果が変わる可能性がある。それと、動的解析の部分で実行環境が必要だから、リソースが限られてると難しいかも。

いやいや、まだ人間の判断が必要なケースもあるよ。それに、悪意パッケージを作る側も進化するから、いたちごっこだよ。

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

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

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

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

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

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

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

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

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

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

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

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