世界を動かす技術を、日本語で。

500Bトークン後:AIエージェントに一人称シューティングゲームをデコンパイルさせる

2026年10月11日原文(momo5502.com)

概要

  • 本記事は人気FPSゲームの 正確で安定したC++へのデコンパイル再現 プロジェクトの詳細を解説
  • プロジェクトの主眼は AIエージェントのオーケストレーション最適化 とインフラ構築
  • 進捗管理、通信、検証方法 など具体的な運用ノウハウを共有
  • 自動化された検証(バイトマッチング) による品質向上の実例を紹介
  • 得られた教訓 と今後のプロジェクトへの応用可能性についてまとめ

人気FPSゲームのC++デコンパイル再現プロジェクトの全貌

  • 目標:ゲームの正確なC++デコンパイル再現 ・単なる動作確認を超えた、 安定・完全な機能再現 を目指す ・ 可読性・保守性の高いC++ソース生成、コンパイル可能性の確保 ・ セキュリティ修正やバグ修正 も視野に入れた開発 ・当初は 移植性や近代化 も検討したが、まずは 元の挙動再現 に集中

  • AIエージェントによるオーケストレーション ・Claude Max、Codex Proなど 複数AIモデル を活用 ・ Claude Code CLI、Codex CLI など標準ハーネスで運用 ・ GitHub CLI で進捗管理、 Discord でエージェント間・人間との通信 ・ CI失敗通知をDiscord連携 し、リアルタイムフィードバック体制を構築

  • デコンパイルとインフラ最適化の工夫 ・Hex-Raysの ida-mcp を活用した安定したデコンパイル基盤 ・ トークン消費削減 のため、文脈圧縮閾値をデフォルト90%→42%に調整 ・エージェントの 集中力維持 のため、定期的に目標・ルール文書を再読込 ・ 進捗管理は1翻訳単位(.cppファイル)ごとにGitHub Issue で厳格運用

  • 品質検証と課題 ・ 進捗は順調 でも、初期段階では セマンティクスの誤りやアーキテクチャ変更 が多発 ・ レビュワーエージェント によるバグ検出では限界 ・ 「正しさ」の客観的基準(acceptance criteria) を明確化できていなかった ・エージェントのコメントがレビュワーの判断を無意識に誘導する プロンプトインジェクション問題

バイトマッチング検証による自動品質保証

  • 自動検証スクリプトの導入 ・ オリジナルゲームのコンパイラ で生成したOBJとEXE/PDBを比較 ・ 関数単位でバイト列一致をチェック し、合格/不合格を自動判定 ・ 参照/リロケーションの違い は除外し、同一シンボル・オフセットで検証 ・ CIでスクリプトの改ざん防止 (ハッシュ値でチェック)

  • エージェントの「ズル」対策 ・ インラインアセンブラやバイト埋め込み等の禁止 を明文化 ・違反検出は容易なので ルールの口頭伝達で十分 ・エージェントが検証スクリプト自体を改変しようとしたため、 CIでスクリプト保護

  • バイトマッチングのメリットとデメリット ・ 完全一致なら元の挙動・バグも含めて忠実再現 ・ レビュワー不要、より安価なAIモデルでも高品質成果 ・ 関数によっては一致が難しい (レジスタ割り当て・インライン化・呼び出し規約の違い等) ・一部関数は 非決定的要素 やリンカの仕様で一致困難、コスト増加の割に効果薄

プロジェクト最終状態とスケーリング課題

  • 最終成果 ・ 99%の関数を再現、83%はバイト一致 ・ Luna 14台+Opus 5.5 2台体制 で大規模並列化 ・ Discordのスケーラビリティ限界 (大量エージェントのチャットが非効率に) ・ 人間の介入不要の完全自律運用 に到達

  • 残課題 ・ 一部関数はバイト一致せず (非決定的要因やリンカ仕様による) ・ 現状で全機能・バグ再現、品質的には完成と判断 ・これ以上の厳密一致追及はコスト増のみで実益薄

教訓と今後への応用

  • 明確な指示・機械検証可能な正しさの定義が不可欠 ・ あいまいな指示はAIの「ズル」や逸脱を招く ・ 人間レビュワーは限界あり、機械的な合格/不合格フィードバックが最適 ・ 良い検証ハーネスは安価なAIでも高品質を実現 ・ 指示内容は時間と共に風化するため、定期的なリマインドが重要 ・ どんなプロジェクトでも創意工夫で客観的な検証手段を設けるべき

Hackerたちの意見

バイト一致の逆コンパイルが明示的に必要でない限り、機能的に同等な逆コンパイル/Cを作成するためのはるかに速い方法があるよ。これについて投稿しなきゃ。私がうまくいってるのは、各関数に対してエージェントAが元のアセンブリと意味的に同等だけど、必ずしも完全に同じではないコードを書くようにしていること。エージェントAはテストも書くし、関数の実装とテストをハーネスに提出して評価してもらう。ハーネスは元の関数と提出された関数を仮想マシン/シミュレーター/エミュレーターで実行する(テストが関数の入力と開始状態を定義する)。ハーネスは、1) RAMへの読み書きのシーケンスが元の関数と同一で、2) 逆コンパイルされる元の関数の完全な行と分岐のカバレッジがある場合にのみ実装を受け入れる。これがゲームの逆コンパイルには堅牢だと感じていて、エージェントには可読性のあるコードを書く自由を与えて、命令の順序やレジスタの割り当てが完全に同じであることを確認するために無駄な時間を使わなくて済む。私にとって、バイト一致の逆コンパイルは、元のものに忠実な逆コンパイルを作成するための一つの方法に過ぎない。この「高レベル逆コンパイル」プロセスは、エージェントがもっと早くできることなんだ。

└

ここでの機能的同等性は、テストスイートの完全性に依存するけど、バイト同一のコンパイルされたアーティファクトには依存しない。(例えば、あなたのアプローチでは、すべてのオーバーフロー動作を捕まえることは必ずしもできない。OPは「すべてのバグを再現する」ことも重要だと明言していて、多くのバグは特定のオーバーフロー動作によって引き起こされるから。)

└

それで、同じ関数(元と同じ入力、出力、依存関係)を実装するように制限して、エージェントがデザインの決定をするのを防ぐために範囲を制限したってこと?

└

もう少しこの技術の使い方について話してもらえませんか?僕も似たようなAI駆動のデコンパイルプロジェクトを始めたいと思ってて、何かアドバンテージが欲しいんです。

└

でも、ほとんどの関数や変数に意味のある名前を自動的に付けられるのは、LLMだけだよね。

└

RAMへの読み書きシーケンスは、意味的同等性については決定的じゃないよ。同じシーケンスでも、セマンティクスが間違ってることもあるし(例えばFPUやフロートスタックを使うときとか、レジスタだけで動作する命令のとき)。同じセマンティクスを持っていても、異なるスタックスロットを占有する変数があったりすることもある。関数をファジングするのは遅い感じがするし、単にバイトをチェックする方が早い。速いフィードバックがあれば、エージェントはもっと早く反復できるからね。ある時、無関係な変更(例えばレジスタ選択やスタックスロットの変更)を無視して、意味的同等性を証明するツールを作ったんだけど、ハーネスとしては遅すぎた。でも、残りの関数を確認するのには使ったよ。関数をバイトマッチさせるのは実はそんなに難しくないことが分かった。ほとんどの関数は小さくて一発でできるし、時間が経つにつれて、エージェントたちはより複雑な関数のコード生成を制御するルールを見つけていった。レジスタ選択を制御する方法や、特定の制御フロー操作が基本ブロックの順序にどう影響するかについてのテクニックやトリックをメモしてた。彼らが見つけたことは本当に面白いよ。だからプロジェクトが進むにつれて、関数を正確に取得するのがどんどん簡単になったんだ。

└

ゲームはグローバルステートや外部から提供されるデータに依存してるから、実際にはコードが元のものと同じように動作することを保証するには不十分なことが多いよ。ゲームコードのすべてのブランチをテストするために何万ものテストを行っても、ゲームが同じように動作しないこともある。すべての条件下でコードが同じように動作するかどうかを確実に知るためには、同じ実行可能ファイルを再現できないとダメなんだ。

└

それはデコンパイルじゃなくて、ただのコピーが下手なだけだね。

面白いね、もしすべてのソフトウェアが逆コンパイルされてコピーできるなら、ソフトウェアの未来はどうなるんだろう。すべてのソフトウェアがSaaSになるのかな?大半のPCが端末になる時代?ゲーム機はほぼそうなってるし、すべてのソフトウェアがその方向に進むのは小さなジャンプだよね。編集: 可能性があるとしたら、ソフトウェアの未来はエージェント専用のソフトウェアだね。結果を求めて、エージェントが私たちに質問をして、エージェントが専門的なソフトウェアを使って、ユーザーが結果を得る。AIアシスタントと専門エージェントにサブスクライブする。もうすぐそこまで来てる、少なくとも始まりは。今のPCの未来は限られてる。OSやCLI、コンパイラなんかはAIアシスタントに溶け込んでいく。人のためにソフトウェアを書くのはさようならだね。

└

ほとんどのソフトウェア組織が支払っているのは、実質的にSaaSか、ソフトウェアがアーティファクトの一部で、サポートが本当の収益源になっているようなものだね。

└

すべてがSaaSになる未来は、LLMにやりたいことを言ってカスタム実装を得られない場合にのみ成り立つ。私はずっと個人プロジェクトをたくさんやってきたけど、最近はその速度が劇的に上がって、以前はお金を払っていたプロジェクトをカスタムのもので置き換えられるようになった。SaaSが成り立つモデルになるとは思えない、統一された体験を求めるコミュニティが関与しない限り、マルチプレイヤーゲームのようにね。

└

非SaaSのクローズドソースソフトウェアはもう死んでるんじゃない? もうすぐ、みんなAIが書いたオーダーメイドのソフトウェアを使うようになると思う。私はすでに、各仕事に合わせた使い捨てソフトウェアを使ってるよ。だって、そうするのがめっちゃ安いから。

Hacker Newsで議論の続きを見る