AIBR プレミアム
拓海先生、お忙しいところすみません。部下から『コードのバグは「不自然な書き方」で見つかる』と聞いて驚きました。これって要するに、機械が文章の違和感を見つけるのと同じようにコードの違和感を見つけられるということですか？
素晴らしい着眼点ですね！その通りです。研究では、人が読む自然言語の「違和感」に相当する指標を、ソースコードに対して機械で計算してバグを検出できるかを調べているんですよ。
なるほど。ただ、我々の現場は古いコードが多く、パターンもばらばらです。投資対効果の観点で、本当に導入する価値がありますか？
大丈夫、一緒に評価すれば必ずできますよ。要点は三つです。第一に、モデルは過去のコードから『よくある書き方』を学ぶこと、第二に、その観点から外れた行を高いエントロピー（不確実性）として検出すること、第三に、それを優先順位付けに使えば検査工数を減らせることです。
ほう、過去のコードから学ぶということは、我々の古いリポジトリでも学習は可能ということですね。ただ、具体的にはどんな技術が良いのですか？
ここが肝心ですね。昔は『n-gram（エヌグラム）言語モデル』が多かったのですが、今回の研究は『LSTM（Long Short-Term Memory）長短期記憶』と呼ぶ再帰型ニューラルネットワークを使っています。簡単に言えば、遠く離れた関係も覚えられる仕組みです。
これって要するに、関係性の遠い部分まで覚えられるから、大きな関数やファイルでもおかしな所を見つけやすくなるということですか？
その通りですよ。良い理解です。加えて、研究では『エントロピー（entropy）』という数値でその『違和感』を定量化しており、高いエントロピーは『モデルから見て予測しにくい行』、すなわちバグの候補になりうるとしています。
実務では誤検知も怖いです。検出したものを全部調べる余力はありません。誤検知を減らす工夫や評価はどうしているのですか？
良い質問です。研究では評価にAUC（Area Under the Curve、曲線下面積）を使っており、LSTMは従来のn-gramモデルに比べてわずかに高いAUCを示しました。運用では閾値を調整して上位から優先的にレビューする運用設計が現実的です。
つまり、すべてを自動で直すのではなく、検査の優先順位を付けるのが現実的だと。わかりました、最後に要点を私の言葉で整理してもよろしいですか？
ぜひお願いします。どんな表現でも構いませんから、自分の言葉でまとめてくださいね。
承知しました。要するに、過去のコードから『普通の書き方』を学ばせて、そこから外れる場所を機械が高い『違和感スコア』として示す。重要な箇所だけを上から点検する運用にすれば、工数を抑えつつバグ発見の効率が上がる、ということですね。
