AIBR プレミアム
拓海先生、最近部下から「過去のコード履歴を使って自動でバグを直せる」って話を聞きまして。要するに、コンピュータに過去の直し方を教えればうちの現場でも役に立つという理解で合っていますか。
素晴らしい着眼点ですね！大筋ではその通りです。論文はNeural Machine Translation (NMT) ニューラル機械翻訳を使い、過去のバグ修正例を学習して「バグのあるコード→直したコード」を“翻訳”するようにしていますよ。
「翻訳」ですか。翻訳という比喩は分かりやすい。けれど、うちの製造現場のソフトは特殊で、ROIが気になります。導入してどれだけ人手を減らせるんでしょうか。
いい質問ですよ。結論を3点で示します。1) 大量の過去修正があればまず候補を高速に出せる、2) 完全自動で全て直すわけではなく提案精度が主眼である、3) 工程の早い段階で煩雑な修正候補を絞れることでレビュー負荷を下げられる、です。
なるほど。しかしうちのコードはテストが少ない。論文の手法はテストをたくさん回す必要があるのですか。
これも鋭い点ですね。従来のgenerate-and-validate（生成して検証）方式はテスト実行が必須ですが、NMTベースのこの手法は候補生成時にテストを回さず提案を行えます。テストは最終的な採用判断の段階で使えば良く、導入コストを下げられるんです。
そもそもデータはどうやって集めるのですか。うちには過去のコミットはあるがゴチャゴチャしています。
論文ではGitHubにある何百万という修正履歴からバグ修正コミットを抽出しました。現実のデータはノイズも多いのですが、適切な抽象化とフィルタリングを行えば有用な学習データになりますよ。抽象化とはコードの変数名などを一般化する処理です。
抽象化ですか。これって要するに「個別の表現を一般形に直して学習する」ということ？
まさにその通りですよ。具体的な変数名やリテラルを置き換えて、モデルが構造的な変更を学べるようにします。その結果、式やAPI利用の一般的な直し方を学習しやすくなるのです。
実際の効果はどれくらいなんですか。現場で使える数字感が欲しいです。
論文では、モデルが開発者と同じ修正を上位候補の中に9%から50%の確率で含めたと報告しています。候補数を増やすほど採択率は上がりますが、現場では上位数件を人がレビューする運用が現実的です。
分かりました。要するに「大量の過去修正を一般化して学ばせ、修正候補を高速に提示する」技術ということですね。自分の言葉で言うと、まず候補を出して人が最終判断するというハイブリッド運用が基本、という理解で合っていますか。
その通りですよ、田中専務。導入の鍵はデータ整備と運用ルールの設計です。一緒に段階的に進めれば必ず形になりますよ。大丈夫、一緒にやれば必ずできますよ。
