AIがコードを「正しく読めてる」は本当か？

LLMを使ってコードを逆コンパイル（機械語から元のソースコードへ復元）する技術が急速に進化している。Ghidraなど従来ツールが「読めない部分はそのまま空欄にする」だったのに対し、LLMベースのツールは見た目にも自然なCコードを生成できる。問題は、この「きれいさ」が盲点を生んでいる点だ。

今回の研究が示したのは、LLMが復元したコードがビルドに成功し、付属テストもすべて通過しながら、それでも元のコードとは異なる動作をするケースが存在するという事実。研究者が独自に用意した入力パターンで検証したところ、テスト通過済みのコードでも全体の約4.9〜13%が元の挙動から逸脱していた。さらに深刻なのは、実際のセキュリティ脆弱性がLLMの「補完」によって静かに消えてしまうケースも確認されている点だ。バグが修正されたのではなく、単に見えなくなっただけ、という状況だ。

これはLLMのコード生成全般にも通じる話で、AIエージェントがテスト合格だけでは不十分な理由でも触れたように、「動いているように見える」と「正しく動いている」は別物だという問題が、今度はコード解析の領域でも浮上してきた。

LLMがコードを復元するとき、実質的にやっていることは「このバイナリはこういう意図で書かれたはずだ」という推測の補完だ。その補完は人間が読んでも自然に見えるし、代表的な入力パターンでは正しく動作する。だがオリジナルコードが持っていた細かい境界値の扱いや、特定条件下でのエラー処理まで忠実に再現できているとは限らない。

たとえば、整数のオーバーフローが起きたときだけ特定の挙動をするコードがあったとする。LLMはその部分を「不自然に見えるから」として整理・省略してしまうことがある。テスト側がそのオーバーフロー条件を試していなければ、テストはすべてグリーン、しかし挙動は別物、というシナリオが成立する。

研究チームはこの問題に対して「Decompile-Diverge」というアプローチを提案している。あらかじめ用意した固定テストではなく、元のコードと復元コードに同じ入力を大量に流し込んで出力を比較するというファジング（意図的に境界値や異常値を試す手法）ベースの検証手法だ。「テストが通るかどうか」ではなく「元の動きと一致するかどうか」を直接確かめるアプローチで、再現性の精度を測る軸が変わっている。