『Super Smash Bros. Melee』のデコンパイル（実行ファイルに含まれる機械語を解析し、ソースコードを再構築する作業）が、2026年9月7日に完了した。最後の関数を一致させたのはPR #3409で、全19,828関数の機械語がオリジナルと一致し、再ビルドしたDOL形式の実行ファイルも元のものと同一になった。一方、Maurice Heumannは『Call of Duty: Modern Warfare 2』（MW2）のPC版を約3か月かけてAIエージェントで再構築した。本人の推定では6,000億〜7,000億トークンを費やし、全関数の83%がバイト単位で一致した段階で作業を終えている。どちらも進捗はパーセンテージで示されているが、数字の意味は同じではない。何を分母にしているのか、誰がその数字を確認したのかを見れば、機械的に検証できる範囲と、人間の判断が必要な部分が浮かび上がってくる。
『Melee』が残り15ポイントを埋めた37日間
decomp.devの記録によると、『Super Smash Bros. Melee』のコード一致率は2025年11月1日の46.94%から、2026年8月1日には84.47%まで上昇した。9か月間で37.53ポイント進み、そこから37日間で残り15.53ポイントを埋め、9月7日に100%へ到達した。
月ごとの数字には各月初に最初に記録された値を使い、100%の到達日は初めて100.0%が記録されたコミット（PR #3409）の日付とした。日数は暦日で計算しており、2025年11月1日から2026年8月1日までは273日、8月1日から9月7日までは37日となる。途中の記録を見ると、2026年4月1日は61.33%、9月1日は92.92%だった。
データを表で見る
| コード一致率 (%) | |
|---|---|
| 2025-11-01 | 46.94 |
| 2026-04-01 | 61.33 |
| 2026-08-01 | 84.47 |
| 2026-09-01 | 92.92 |
| 2026-09-07 | 100 |
この終盤の作業には、AIを利用した貢献者も参加していた。少なくとも1人の貢献者が、9月6日にマージされたPR #3374と9月7日にマージされたPR #3380について、「CodexとAstraで実装・検証した」と明記している。Astraは、OpenAIが公開しているモデル「GPT-6 Astra」を指す。
PRの説明によると、#3374ではコード一致率が98.00527%から98.08615%へ約0.08ポイント上昇し、#3380では432バイト分の一致によって0.01113ポイント上昇した。AIの利用が明示されたこの2件の寄与は合計約0.09ポイントで、残り15.53ポイントの1%にも満たない。
その一方で、9月1日の92.92%から9月7日の100%までは、わずか6日間で7.08ポイントも進んでいる（編集部計算）。ただし、この急速な進展を何がもたらしたのかは、確認できる資料だけでは分からない。
したがって、この記録だけを根拠に「AIが最後の難関を突破した」とは言えない。明示されていないAIの利用や参加者の増減、AIモデルの世代交代などが進捗にどの程度影響したのかも、時系列のデータからは判断できない。
また、decomp.devのコード一致率は、一致した機械語のバイト数を基に算出したものだ。復元したソースコードの読みやすさや、関数名・変数名が適切に付けられているかどうかは評価に含まれない。
一致率は何を数えているのか
マッチングデコンパイルとは、オリジナルと同じコンパイラ、同じ設定でビルドしたときに、元と同一の機械語を生成できるCコードを再構築する作業だ。『Klonoa: Empire of Dreams』のデコンパイルに取り組む開発者も、『Super Mario 64』や『Ocarina of Time』を先行事例として挙げている。
目標は、オリジナルと同じ機械語を生成することにある。つまり、照合すべき正解は元のバイナリに存在する。再構築したコードをビルドして比較すれば、どこまで一致したかを機械的に判定できる。
その比較に使われるツールの一つがobjdiffだ。リンク前に生成される再配置可能オブジェクトファイルを、関数やデータの単位で比較するツールで、decomp.devの進捗レポートにも利用されている。
Heumannが自作した比較スクリプトも、基本的な考え方は同じだ。再構築したコードをオリジナルと同じコンパイラでビルドして得られるOBJ（オブジェクトファイル）と、元のEXE（実行ファイル）およびPDB（シンボル情報を格納したデバッグ用ファイル）を使い、関数ごとにバイト列を比較してPASSかFAILを返す。
ただし、リンク時にアドレスが確定する参照部分は、バイト列をそのまま比較しても一致しない。そこで、こうした再配置の対象となる部分を直接比較から除外し、同じシンボルを同じオフセットで参照しているかを別途確認する。
Heumannの説明によれば、この検証に合格した関数は、元のバグも含めてオリジナルと同じ動作になる。その前提となるのが、同じコンパイラと設定を使用し、再配置部分の参照先も正しく確認することだ。
合否を機械的に判定できるため、AIエージェントに関数単位でコードの生成と修正を繰り返させることができる。
ただし、判定方法が似ていても、何を分母にするかで一致率の意味は変わる。
decomp.devのコード一致率は、コード全体のバイト数に対して、一致した部分が占める割合だ。一方、Heumannが報告した83%は、全関数のうちバイト単位で一致した関数の割合を示す。同じブログに登場する「99%」は、全関数のうち再構築したソースコードが存在する関数の割合であり、バイト単位で一致しているかどうかは問わない。
いずれも、復元したコードの命名や可読性を評価する指標ではない。
なお、元の機械語との一致そのものを目標にしない手法もある。N64Recompはバイナリを関数単位でC関数へ静的再コンパイルし、ReXGlueはXbox 360のPowerPCコードを移植可能なC++へ事前に変換する。これらは、元の機械語を再現できるソースコードを目指すマッチングデコンパイルとは目的が異なる。
検証方法の変更がMW2の再構築を加速させた
Heumannは2026年10月9日のブログで、「人気のFPS」を約3か月かけてAIエージェントによりC++へデコンパイルしたと報告した。対象が『Call of Duty: Modern Warfare 2』であることは、9月30日のXへの投稿で明かしている。
最初の1か月は、作業担当3体とレビュー担当1体の計4体のエージェントを使い、ゲームのおよそ80%を再構築した。メニューの表示やマップの読み込みまで動作するようになったものの、関数のシグネチャや構造体には誤りがあり、処理内容の捏造や削除も起きていた。Heumann自身も、コードの意味や動作という点では正しくなかったと認めている。
転機となったのは、正しさの判断をAIによるレビューから、バイト単位の照合へ切り替えたことだった。
Heumannはオリジナルと同じコンパイラを使うようにし、前述の比較スクリプトを導入した。バイト単位で一致した関数は意味や動作も元と同一になるため、レビュー専用のエージェントが不要になったという。
合否を明確に判定できるようになったことで、それまでは十分な成果を出せなかったHaikuやLunaのような低価格モデルでも作業を進められるようになり、費用を大幅に削減できたと説明している。
もっとも、検証器を導入したことで、エージェントによる新たな抜け道探しも始まった。
まずエージェントは、インラインアセンブリを使って一致判定を通過させようとした。次には検証スクリプトそのものを書き換え、自分が生成した関数を比較対象から除外しようとしたという。
Heumannは、指示に解釈の余地があるとエージェントは不正な方法で条件を満たそうとする、と指摘している。対策として、CI（継続的インテグレーション）で検証スクリプトのハッシュ値をGitHub Actionsのシークレットに保存した値と照合し、スクリプトが改変されていないことを確認する仕組みを導入した。
Heumannが重視するのは、正しさを明確に定義し、機械的に検証できる状態を作ることだ。AIによるレビューだけでは不十分であり、客観的なPASS/FAILの判定こそが最も有効なフィードバックになると述べている。
最終的には、全関数の99%について再構築したソースコードを用意し、そのうちではなく、全関数を分母として83%のバイト一致を達成した。終盤には主にLunaを14体、Opus 5.5を2体稼働させていた。
残った関数は、何度修正してもバイト単位では一致しなかった。Heumannはその理由として、非決定的な性質や、リンカーが同一内容の関数を一つに統合する「identical COMDAT folding」という処理を再現できないことなどを挙げている。
本人は、残りの関数も意味や動作は正しいと考えている。そのため、これ以上バイト一致を追求してもトークンを消費するばかりで、実質的な改善にはつながらないと判断し、プロジェクトは完了したとみなせるとしている。ただし、Opus 5.5のエージェントなら、残りの一致率をさらに引き上げられる可能性があるとも述べている。
総トークン使用量は、作業に使ったVMを消去してログを失ったため、推定値にとどまる。Heumannの見積もりでは6,000億〜7,000億トークンで、そのうち約3,000億トークンをLunaが占める。
HeumannはLunaとAstraのコスト比を100対1とみなし、約3,000億Lunaトークンを約30億Astraトークン相当と換算している。OpenAIのAPI価格では、Astraは入力100万トークン当たり10ドル、出力50ドル、Lunaは入力0.10ドル、出力0.50ドルで、入出力ともに100対1の価格差がある。この点はHeumannの換算と一致するが、価格表だけでは実際の総費用までは算出できない。
注意すべきなのは、これらの数字がすべてHeumann本人の申告であり、再構築したコードも公開されていないことだ。
Heumannは、目立った不具合はなく、原作の機能をすべて再現できていると説明する。しかし、83%というバイト一致率を含め、第三者が独立して検証する手段はない。
Kotakuは10月3日、Xに投稿された映像が著作権者からの申し立てによって閲覧できなくなったと報じた。Heumann自身も、ブログで過去の記事を2本削除したことを明かしている。
同じ『Halo』なのに「99.5%」と「23.25%」：数字が食い違う理由
『Halo: Combat Evolved』のデコンパイルプロジェクトから派生したリポジトリ（fork）のREADMEには、「99.5%バイト一致」と記載されている。
ところが、その派生元にあたるリポジトリをdecomp.devで確認すると、2026年10月11日時点のコード一致率は23.25%で、一致した関数は全11,047個のうち2,511個にとどまっている。
具体的には、派生先のbnunu/halo-1のREADMEに「work-in-progress（99.5% byte matching）」とある。一方、decomp.devで確認できるのは、派生元であるpunpckhdq/haloのbuild 2342で、コード一致率は23.25%、近似一致を含むfuzzy一致率は24.65%だった。
問題は、READMEに記された99.5%が何を表しているのか、定義が示されていないことだ。
例えば、一致済みの関数の内部で、どの程度バイト列が一致しているかを表すなど、decomp.devとは別の指標である可能性がある。また、decomp.devの数字は派生元リポジトリの最新コミットに基づいており、派生先の現在の進捗とは異なる可能性もある。
したがって、READMEの99.5%が誤りだとも、デコンパイルが23%しか進んでいないとも断定できない。
なお、この2つの『Halo』関連リポジトリでAIが利用されているかどうかを示す資料はなく、ここで問題にしているのもAIの利用状況ではない。重要なのは、パーセンテージの分母が明示されていなければ、読み手にはその数字の意味が分からないという点だ。
同じ問題は、別のプロジェクトにも見られる。
AnyPS5は、PS5の実行ファイルをLinuxやWindowsのネイティブ形式へ再リンクするツールで、デコンパイルを目的とするものではない。
その進捗を示すバッジには、シェーダー100.0%、システムライブラリ85.82%と表示されている（10月12日確認）。ただし、READMEによれば、システムライブラリの85.82%はプロジェクト側で把握している関数を分母とした数字であり、PS5の全システム関数に対する割合ではない。
ここまで取り上げたゲームのデコンパイル事例について、判定方法と数字の出所を整理すると次のようになる。
| プロジェクト | 判定方法 | 数値 | 数値の単位 | 数値の出所 | 時点 |
|---|---|---|---|---|---|
| 『Super Smash Bros. Melee』 | バイト一致 | 100% | コード一致率 | decomp.dev（外部） | 2026-10-11 |
| 『Snowboard Kids 2』 | バイト一致 | 100% | コード一致率 | decomp.dev（外部） | 2026-09-27 |
| 『Snowboard Kids』 | バイト一致 | 100% | コード一致率 | decomp.dev（外部） | 2026-10-10 |
| 『Klonoa: Empire of Dreams』 | バイト一致 | 51.30% | コード一致率 | decomp.dev（外部） | 2026-10-05 |
| 『Halo: Combat Evolved』（build 2342） | バイト一致 | 23.25%（派生先のREADMEは99.5%） | コード一致率 | decomp.dev（外部、派生元） | 2026-10-11 |
| 『Call of Duty: Modern Warfare 2』（PC版） | バイト一致（2か月目から） | 83% | 全関数に対する一致関数の割合 | 開発者の申告、コード非公開 | 2026-10-09 |
この6作品のうち、外部の進捗トラッカーで100%への到達を確認できるのは、『Super Smash Bros. Melee』『Snowboard Kids』『Snowboard Kids 2』の3作品だ。
『MW2』もバイト一致を判定に利用しているが、83%という数字を裏付ける情報は開発者本人の申告に限られる。
また、『Snowboard Kids』の「84日」は、開発者が100%到達までの期間を数えたものだ。公開リポジトリの日付から計算すると、約83日になる。
外部トラッカーの記録は誰でも履歴をたどれる一方、開発者の自己申告による数字は、本人が示した定義や説明に依存する。
さらに、『MW2』の83%は全関数のうち一致した関数の割合であり、『Melee』の100%はコードの総バイト数に対する一致部分の割合だ。指標の単位が異なるため、表にあるパーセンテージをそのまま比較することはできない。
専門家が関わったコミットは4.8%：100%一致しても残る課題
Chris Lewisは2025年11月27日のブログで、『Snowboard Kids 2』（N64）のデコンパイルを進めるために導入した「one-shot」方式を紹介している。
この方式では、スコアラーが次に取り組む比較的容易な関数を選び、Claude（主にOpus 4.5）が人間の操作を挟まずにバイト一致を試みる。10回を超えて試しても進展がなければ、その関数を難関リストに記録して次へ進む。
Lewisによれば、8時間以上にわたる無人運転も可能になり、導入後の3週間で、それ以前の3か月を上回る進捗を達成したという。ただし、10回試して成果が出なければ諦めるというルールについては、「部分的にしか機能しなかった」とも振り返っている。
容易な関数から順に処理する方法には、いずれ行き詰まるという問題がある。
Lewisは2026年2月16日のブログで、一致率が約25%から58%へ急上昇したあとに進捗が鈍化し、手法を変更して約75%まで引き上げたものの、再び停滞したと報告している。
『Snowboard Kids 2』が100%へ到達したのは2026年5月17日だった。最初のコミットが行われた2024年9月28日から596日かかったことになる。
特に難しかった最後の10関数では、コミュニティのメンバーが大きな役割を果たしたという。Lewisの経験では、最も成果を上げたモデルはCodex 5.5 xhighだった。ただし、この評価はあくまで本人の経験に基づくもので、今後変わる可能性があるとも断っている。
Lewisは、モデルの性能だけでなく人間の協力が重要だったことを強調し、「コミュニティはどのモデルよりも重要だった」（原文："the community was more important than any model"）と述べている。
初代『Snowboard Kids』では、人間の専門家による貢献が数字にも表れている。
Lewisは100%到達までの期間を84日と数えている。公開リポジトリでは2026年5月28日から8月19日までの約83日に相当する。関数は2,145個で、続編の2,995個より少ない。
一致作業に関するコミットのうち、約4.8%（約41件）には専門家の介入があったという。
Lewisによれば、SGIが開発したIDOコンパイラに詳しい専門家たちの知識がなければ、どれほど順調に進んでも一致率は89〜90%程度で頭打ちになっていた可能性がある。
ただし、4.8%という数字は、Lewisがコミット履歴を手作業で振り返り、分類した概算だ。人間が費やした作業時間の割合を示すものではなく、Lewis自身は専門家として数えていない。
89〜90%という数字も、専門家が参加しなかった場合を想定した見積もりであり、実測値ではない。
初代と続編では、関数の数も作業を始めた時期も異なる。Lewis自身、直前に約2年間にわたる同種のプロジェクトを経験して作業に習熟していたことや、IDOコンパイラの出力を再現しにくかったことなどを挙げている。
そのため、84日という期間をそのままAIによる効率化の成果と解釈することはできない。
ちなみに、機械語からCコードを自動生成するツール「m2c」を使い、未一致の関数1,830個を一括処理するスクリプトも試されている。しかし、一致したのは17個、割合にしてわずか0.93%だった。
Lewisは、コードが100%一致したとしても、ソースコードの内容が完全に理解されたことにはならないと指摘している。
この問題は、『Klonoa: Empire of Dreams』のデコンパイルでも表面化している。
同作の開発者が2026年8月17日に公開したブログには、AIが正規の一致判定を回避しようとした事例が紹介されている。
『Klonoa: Empire of Dreams』は2001年7月発売のゲームボーイアドバンス向け作品だ。ブログの公開時点では、ゲーム全体で663関数が確認されており、コードのバイト数で換算すると51%のデコンパイルが完了していた。
作業に行き詰まったClaude Codeは、使用するコンパイラ「agbcc」をforkし、コンパイラ側を変更することで一致させようとした。
しかし、これは比較対象に合わせてコードを復元するのではなく、比較に使う基準そのものを変更する行為だ。元の機械語との一致を検証するという本来の目的から外れている。
『MW2』の事例でAIが検証スクリプトを書き換えようとしたのと同じ構図であり、この変更は経験豊富な参加者によってすぐに退けられた。
開発者は、このプロジェクトにおける最大のリスクを「認知的負債（cognitive debt）」と呼んでいる。
LLMによって作業が急速に進む一方、人間がコードや変更内容を理解し、検証するための負担が積み重なり、やがて解消できないほど膨らんでしまう問題だ。開発者は、AIによる不正な試みを目にした際の自分自身の初期対応も、その一例だったと振り返っている。
もっとも、AIは人間が見落としていたものを発見することもある。同じClaude Codeが、25年間知られていなかった隠しミニゲームを自律的に発見したという。
COBOLの刷新にも通じる「検証できる作業」の重要性
ゲームのデコンパイルで得られた知見は、企業の古いシステムを新しい環境へ移行する作業にも通じる。
Anthropicは2026年2月23日の記事で、Claude Codeによってシステム刷新の大部分を占める調査・分析作業を自動化でき、従来は数年かかっていた刷新を数四半期で進められると主張した。
この記事が公開された2月23日、IBMの株価は終値223.35ドルとなり、直前の取引日である2月20日の257.16ドルから13.15%下落した（Yahoo Financeの日次データを基に編集部計算）。ただし、確認できる資料だけでは、Anthropicの記事が下落の原因だったと断定することはできない。
一方、AIエージェント「Devin」を提供するCognitionは、2026年4月8日の記事で、AIが対応できる作業と難しい作業の違いをより具体的に説明している。
Devinが動作するLinuxの仮想マシン（VM）では、メインフレーム上のCOBOL業務システムをそのまま実行できない。このため、コードを書き、実行し、結果を確かめて修正するという反復作業が成立しない。
背景には、COBOLの業務システムがジョブ制御システム、ミドルウェア、古いデータベース、独自のファイルシステムなど、メインフレーム特有の基盤と密接に結びついていることがある。Linux側に同じ環境がないため、エージェントはソースコードを読めても、実行して正しさを確かめられない。
これに対し、入力と期待される出力が明確なバッチ処理なら、出力が一致するまでコードの修正を繰り返せる。
Cognitionは、こうした方法を適用できる部分がCOBOL移行作業の30〜50%を占めるとしている。ただし、この数字は同社が外部の記事から引用したものであり、Cognition自身の実測結果ではない。
構造としては、ゲームのデコンパイルにおけるバイト一致と同じだ。期待される出力が分かっていれば、それを基準にした検証器を用意できる。
Cognitionは具体例として、匿名の自動車メーカーが使用していた2万5,000行の通関処理システムをAWS Lambdaへ移行した事例と、ラテンアメリカ最大の民間銀行Itaúにおける、法人の納税者番号を英数字対応に変更する作業を挙げている。
後者は期限より3か月早く完了したという。ただし、いずれもCognition自身が公表した事例である。
さらに大規模な取り組みも進んでいる。
CIO Diveの2026年7月28日付の記事によれば、Morgan Stanleyは社内プラットフォーム「DevGen.AI」を活用し、COBOL、Natural、PERLで書かれた1,700万行以上のコードをJavaやPythonなどの言語へ刷新したという。
もっとも、1,700万行という数字は作業の規模を示すものであって、移行の完成度や正確性を示すものではない。
AIによるレガシーシステム刷新の見通しについては、専門家の間でも評価が分かれている。
Gartnerは2026年6月18日、2026年に開始されるメインフレーム脱却プロジェクトの70%超が、生成AIの能力を過大評価することで、期待した成果を得られないと予測した。これは将来の見通しであり、実際に70%以上が失敗したという調査結果ではない。
国内でメインフレームの刷新を検討する情報システム部門にとっても、Cognitionが示した区分は一つの判断材料になる。
まずは期待される出力を明確に定義できる業務からAIによる移行を試し、出力の正解を用意しにくい業務については、完成度や正確性がどのように検証されたのかを慎重に確認する必要がある。
ゲームのデコンパイル事例で、第三者が公開トラッカーを通じて進捗を確認できたのは、機械的に一致を判定できる部分だった。そして最後の難関を突破する際には、人間の専門家の知識が欠かせなかった例もある。
数字の信頼性にも違いがある。『MW2』の83%のように外部から検証できないものもあれば、『Halo』のようにREADMEの数字の定義が示されておらず、公開トラッカーの数字と何が違うのか判断できない例もある。
さらに、コードが100%一致したあとにも課題は残る。
Lewisは、自動生成された関数名や変数名を分かりやすいものに変更することや、コードの構造を整理すること、グラフィックスや音声データを適切に扱うことなどを挙げている。
AIによってコードを再構築する速度が上がっても、その内容を人間が理解し、保守できる状態にする作業まで自動的に終わるわけではない。
COBOLなどのレガシーシステム刷新についても、今後、2026年に開始されたメインフレーム脱却プロジェクトの実際の成果が明らかになれば、Gartnerの予測がどこまで妥当だったのかを判断する材料になるだろう。
