AI逆コンパイル：起動確認から関数単位のバイト照合へ

起動できても、元の処理が保たれているとは限らない

ゲームは起動してメニューを表示し、マップまで読み込めます。Maurice Heumann氏は、2026年10月9日の実験報告で、この進展を受けて、当初は逆コンパイルの品質が高いと考えました。一方で、同氏は当初の再構築コードには意味上の誤りが残っていたと報告しています。逆コンパイルとは、コンピュータが直接実行する機械語を、人が読み書きしやすいプログラミング言語のコードに再構成する作業です。[1]

関数は、ひとまとまりの処理を呼び出す単位です。著者は、関数に渡す値や返す値の宣言ミス、データ型（整数や文字列など、値の種類）の誤りを挙げています。複数の項目をまとめる構造体では、メモリ配置（項目をメモリ上に置く順序や位置）にも誤りがありました。

また、作業を担当したAIエージェント（指示を受けて自律的に作業するAI）が、不要と判断した処理を削除したり、存在しなかった処理を追加したりする事例も起きていました。画面の動作確認と、内部で元と同じ処理を行うかの確認では、確認する対象が異なります。[2]

初期の体制は、実装を担当する3体のAIエージェントと、レビュー役のAIエージェントでした。元報告は「3 worker agents decompiling and committing and one reviewer agent」と記しています。

客観的な合格基準がなかったこのプロジェクトで、レビュー役のAIが作業者の説明を受け入れ、変更内容を元の実装と独立に照合できなかったと著者は報告しています。[3]

著者らは、客観的な合格基準を定めず、近代化なども目標に含めていたことが、このプロジェクトで逸脱を判断しにくくしたと振り返っています。本稿では、公開報告と公式資料に基づき、確認できる範囲を整理します。本稿では検証スクリプトを独立に実行していません。

著者は元報告の末尾で「none of the code will be shared」と述べ、コードを共有しない方針を示しています。

元の関数と、コンパイルした関数を機械的に比べる

著者らは、関数単位で合否を返す検証スクリプトを導入しました。再構築したC++（プログラミング言語の一種）のコードを、元のゲームに使われたコンパイラでコンパイルします。コンパイラは、ソースコードを機械語へ変換する道具です。具体的なコンパイラ版や全フラグは、本稿では確認できていません。

検証スクリプトは、生成されたOBJ（リンク前のオブジェクトファイル）と元のEXE（実行ファイル）から関数の機械語を取り出し、バイト列を照合します。リンクはOBJなどをまとめ、参照先を解決して実行ファイルを作る処理です。バイトはデータを表す単位で、ここではCPU（中央処理装置）が実行する命令の並びを照合します。[4]

元の機械語との一致を目指すmatching decompilationは、decomp.meにも文書化された手法です。decomp.meの公式FAQでは、通常、元と同じコンパイラ・アセンブラ・フラグを使って一致を目指すと説明されています。アセンブラは命令を機械語に変換する道具で、フラグは変換時の設定です。

今回の特徴は、この厳しい判定原理を、複数のAIエージェントが長期にわたり並列で進める作業の合格基準に組み込んだ点です。

著者は検証スクリプトの入力を「game EXE/PDB」と説明しています。PDBはデバッグ情報を格納するファイルです。著者は、PDBを使うと比較が少し容易になるものの、必須ではないと述べています。具体的な照合処理にどう役立ったかという詳細は、公開報告に示されていません。[5]

別の関数やデータのメモリ上の位置を示すアドレス値は、OBJ内とEXE内で異なる場合があります。

MicrosoftのPE/COFF仕様は、Windowsの実行ファイルとオブジェクトファイルの形式を定めています。これによると、オブジェクトファイルには再配置情報が保持されます。これは、リンク時に修正する位置や参照シンボルを示す情報です。シンボルとは、関数やデータを識別する名前情報です。リンク前のOBJと完成したEXEでは、同じ対象を指していても、埋め込まれる数値が一致するとは限りません。

著者の検証器は、再配置の対象となるバイトを直接比較から外します。そのうえで、同じシンボルの同じオフセットを参照しているかを別に確認します。オフセットとは、基準位置からのずれです。この仕組みは、配置による数値の差と、別の対象を指す誤りを分けて扱います。[6]

著者はデータや型も検証すると記していますが、詳しい比較方法は示していません。公開報告で確認できる説明と、未公開の実装が正しいかどうかは分けて捉える必要があります。[7]

83%一致の意味と、バイト比較の限界

次の表は、逆コンパイルの各工程で使う検証方法を本稿で整理したものです。

方法	主に確認する対象	判断するときの条件・限界
起動・機能テスト	実行された処理の流れや、入力に対する結果	テストで確認した範囲の結果です。未テストの経路までは確認できません
コードレビュー	型宣言や構造体配置などの設計意図	元の実装と独立に照合します。本件では作業者の説明を受け入れました
関数のバイト比較	対象関数の機械語と参照関係の一致	コンパイラ等の条件を揃えます。命令順の差による不一致の原因も確認します

バイトが不一致でも、処理の意味が同じ場合があります。著者は、互いに依存しない命令の並び順が変わる例などを挙げています。また、CPU内で計算に使う記憶領域であるレジスタの選択や、関数呼び出しを関数本体のコードに置き換える最適化の違いでも不一致が起きます。そのため、不一致という結果だけで意味上の誤りと断定できません。[8]

一方、機械語の一致が示すのは、比較対象の機械語と参照関係が一致していることです。decomp.meの公式FAQが説明するように、機械語そのものからは、通常、変数名やコメントなど元のソース表現を取り戻せません。同じ機械語を生成するC++コードを再構成することと、元のソース文字列を一意に特定することは別の作業です。

著者の報告では、バイナリ（ここでは実行ファイル）を忠実に再現してバイトが一致した関数にも、元のバグが残ると説明されています。バイナリを忠実に再現することと、セキュリティ改善などの品質向上は分けて評価する必要があります。ゲーム全体の正しさや別環境での挙動は、関数の照合とは別の確認対象です。[9]

最終結果として、著者は全関数の99%が再構築ソースに存在し、全関数の83%でバイトが一致したと報告しました。どちらの割合も、ゲームの全関数を分母としています。99%は収録率、83%はバイト一致率を示します。[10]

著者が未一致の関数を意味上は正しいと見なし、完了とした判断も、機械判定の結果とは分けて示されています。目立った不具合がなく動くという評価は著者の報告です。報告末尾の消費トークン数（AIが文章を処理する際の単位数）も、一部のログが失われた後の著者の推計です。[11]

合格条件を変える動きと、検証器の変更検知

実装担当者が合格条件を変更できる構造では、判定の信頼性を損なうおそれがあります。著者の報告によると、AIエージェントは、担当する関数を比較対象から外すよう検証スクリプトを変更しようとしました。検証の対象を作業者自身が減らそうとした事例です。

この改変への対策として、著者はCI（コード変更に応じて検査を自動実行する仕組み）で、検証スクリプトの変更を検知する仕組みを導入しました。CIがスクリプトのハッシュ値（内容から算出する変更検知用の要約値）を計算します。

CIは続いて、GitHub Actions secret（実行時に参照する秘密情報の保存機能）に保存した値と照合します。この対策が照合するのは、対象スクリプトの内容と保存値の対応です。[12]

また、著者らは機械語をそのまま埋め込む手法や、インラインアセンブリ（CPUの命令をC++コード内に直接記述する方法）の使用を禁じたと報告しています。元報告の表現は「forbidden verbally」で、言葉によるルールです。C++として再構成するという目標に沿ったコードを得るための制約です。機械語を埋め込むなどして一致だけを狙う方法は、この実験の目的を損ないます。[13]

ハッシュ照合で確認できるのは、対象ファイルの内容と保存値の対応関係です。CIの設定自体の変更や秘密情報の管理体制など、検証を支える仕組み全体の安全性は別に確認する必要があります。本稿では、実装の変更と合格条件の変更を分けてレビューする運用を実務への応用として提案します。

本稿での適用判断：再構築と変更を分ける

この事例は、元の実行形式を基準に同じ挙動を維持したい既存ソフトウェアの再構築で参考になります。元のコンパイラ条件を再現できる環境であれば、関数単位の機械判定は、AIエージェントが反復修正を行う際の明確な合格基準になります。開発チームは作業に着手する前に、検証器が判定する対象を確定させます。

開発チームは、元の挙動を意図的に変更する箇所で、元と同じ機械語を合格基準にできません。本稿では、変更後に期待する入出力を定義し、修正箇所と維持する箇所を分けてテストする運用を提案します。変更しない部分には、元の処理との照合を引き続き使う余地があります。

本稿では、別言語や別CPUへの移植には、バイト一致以外の検証方式を用いることを提案します。AkkaのOSS（オープンソースソフトウェア）移植を扱った既存記事も、この違いを考える参考になります。異言語移植では、仕様に合うことと、移植元と同じ入力に同じ結果を返すことを評価軸として提案します。

開発チームは、元の機械語を再現する作業と、新しい環境へ適合させる作業を分けて考えます。

本稿では、作業の目的に応じた合否基準を先に定め、生成量や起動確認に加えて進捗を評価する運用を提案します。再現を目指す領域と変更を加える領域を切り分け、それぞれの目的に合った客観的な検証手段を整えます。