デコンパイラのAI化、テストを通してもなお『本物と違う』

『デコンパイル』って、要するにプログラムの逆算作業みたいなもの？なぜそんなことをする必要があるの？

デコンパイルは、ざっくり言うと「プログラムの逆算」です。ただし、その用途を考えるとセキュリティの世界で必須の作業になってるんですよね。 企業のソフトウェアが被害を受けたときや、マルウェアが出回ったとき、手元にあるのは実行ファイル（機械語）だけ。元のソースコードはないわけです。そこを読み解かないと、どこが悪いのか、何をやってるのか分かりようがない。だから逆算してコードに戻す必要がある。 また、セキュリティ研究では「このソフトウェア、実は危ない機能を隠してるんじゃないか」という疑いを検証するときにも使われます。ソースコードが公開されていないなら、機械語から復元して調べるしかない。 問題は、AIが出すデコンパイル結果が「見た目は正しそうだし、テストも通る」なのに、実は元と微妙に違う動作をしている点。検証者が「これで安全だ」と判断してしまうと、隠れた脆弱性まで見過ごされる可能性がある。つまり、信頼できるコードに見えることが、かえって危険を高めてしまってるわけです。

スマートフォンアプリやPCのソフトをダウンロードして使ってる側としては、このデコンパイルの不具合って何か影響があるんですか？

デコンパイルが影響するのは、主にセキュリティ調査や脆弱性診断の場面です。サイバーセキュリティ研究者が、不正なアプリやマルウェアを分析するとき、機械語を読みやすいコードに戻す作業をする。その際にAIが勝手に埋め込んだコードが原因で、本当の危険性を見落とすリスクがあるわけです。つまり「このアプリは安全だ」という判定が間違える可能性が高まる。 ユーザー側への直接的な害というより、守り手である研究者の目が曇るという構図ですね。テストに通ったからOKと思い込んで、実は隠れた脆弱性がある悪質なアプリを見逃してしまう。その結果、あなたのスマホにそのアプリがインストールされ、個人情報が盗まれる可能性が高まるという遠回りな経路で影響が及ぶ形になります。直接的ではないにせよ、セキュリティの砦が甘くなることで、最終的には一般ユーザーが被害を受けやすくなってしまう側面があるのかもしれません。

AIのデコンパイラが『綺麗なコードを出す』ようになったのは最近なの？従来のツールとは何が違うのか、どうやって改善したの？

従来のデコンパイラは、機械語の構造をルールベースで逆算していました。「このバイト列は〇〇という命令だ」という辞書引きに近い。だから、ルールで説明できない部分は空白のままになる。読みづらくて、不完全なコードが出来上がるわけです。 AIデコンパイラ（LLM ベース）の改善点は、「大量のコード例から、言語としてのパターンを学んだ」という一点に尽きます。機械語 → ソースコードの対応関係を、統計的に学習する。「この流れなら、ここは『ループ』と解釈するのが自然だな」という確率的な推論ができるようになった。だから綺麗なコードが出る。 ただし、ここが落とし穴です。ルール外のコーナーケースや、元のプログラムの細かい癖まで、LLM は「もっともらしく補完」してしまう。テストに通るのは、その補完が「大多数の入力では正しいから」に過ぎません。13%の不具合が隠れるのは、そういう構造的な隙間なのだと言えそうです。

これって『AIが得意そうに見えても、細部では人間（や従来ツール）に劣る部分がある』って話なの？他の分野にも当てはまりそう？

確かにその側面もあるんですが、もう一段階深いところがあるかもしれません。 AIが「綺麗なコードを出す」というのは、見た目や読みやすさでは本当に従来ツールを上回っている。ただ、その読みやすさという利点が、テストという検証プロセスの盲目性を誘発してしまう。つまり「きちんと整形されている」ことに安心して、実際の動作検証を手を抜く側に人間が傾く、という部分も大きいのかもしれません。 医療診断の場面を考えると似た構造が見えます。AIが「確度95%の診断」と明示すれば、医者は慎重になる。でも「自然な診断結果」として出されると、その信頼度を過度に買ってしまう。コードの「見た目の完成度」も同じ効果を持つわけです。 だから本来必要な検証作業が『AIなら大丈夫』と軽視されやすくなる。AIが劣ってるというより、AIの出力の「説得力」が検証を骨抜きにしてる側面が大きいのかもしれません。

テストに通ったコードでも13%が実は違う動作をしてるなら、逆にセキュリティ研究者とか悪意のある人がそこをついて、わざと『テストを通すけど隠れた不具合を埋め込む』ことって可能ってこと？

その通り、理論的には十分可能なシナリオです。実は、その危険性は「サプライチェーン攻撃」という名前で既に現実化しています。 オープンソースライブラリの開発者が、テストには通るけれど隠れた脆弱性を仕込むコードを投入する事例が報告されています。悪意のある開発者なら、わざと曖昧な部分を狙って、テストでは検出されない動作を埋め込める。AIデコンパイラはそこに新しい抜け穴を与えてしまった格好です。 ただ実際には、セキュリティ研究者側も守りの工夫をしています。重要なコードなら複数の検証方法を重ねたり、デコンパイル結果を人間が読み直したり、今回の論文のようにファジングで入念にテストしたりする。完全な防御ではないですが、「テストだけで信頼する」という単純な思考は既に古くなっている状態かもしれません。 むしろ問題は、AIが「読みやすさ」を提供したことで、検証の手を抜きやすくなった点にありそうです。綺麗に見えるコードほど、疑いの目を向けにくくなる心理的な罠とも言えます。