ilreb と名乗る開発者が、1996年に登場したゲームエンジン『Quake』を現代のWebブラウザ上で動作させた。「Quake-SRP」（slop rust port）と名付けられたこのプロジェクトは、外部依存ライブラリを一切持たず、コードベース全体で unsafe の使用を一箇所も許可していない。30年前のC言語コードは安全なRustへと全量移植され、WebAssemblyへとコンパイルされてバックグラウンドのWeb Worker内で実行される。ユーザーはローカルディスクにある無改造の pak1.pak や公式ミッションパック、さらにはCD音源をブラウザへ直接ドラッグ＆ドロップしてプレイ可能であり、すべての処理は端末内のみで完結する。
C言語の全ソースをWASM化し、Web Workerで駆動する
id Softwareが1996年にオープンソース化したQuakeのソースコードは、手動のメモリ管理とポインタ演算が複雑に入り組んだ迷宮そのものである。本移植において、作者はWebGLやWebGPUによる現代的なGPUアクセラレーションをあえて採用せず、オリジナルのWinQuakeが備えていたCPUソフトウェアレンダラーと8ビットカラーパレットを忠実に維持した。WebGL2が担うのは、演算済みのフレームバッファを画面に転送する最後のBlit処理のみである。第2章から第4章を含む pak1.pak やミッションパックの pak0.pak、さらにはCDオーディオトラックまで、ブラウザにドロップするだけでローカルに読み込まれる。
ハードウェアとの密接なやり取りに依存していた往年のエンジンをWeb Worker環境に収めることは、アーキテクチャの根本的な刷新を意味する。WebAssemblyの全ロジックはバックグラウンドスレッドでCPUの1コアをフル稼働させて走り、メインスレッドはマウスやキーボードの入力イベントの伝達と、共有メモリ（SharedArrayBuffer）からの描画ピクセルおよびオーディオデータの受け取りに専念する。GPUハードウェアパイプラインを捨て、ブラウザのCPU単核性能で30年前のソフトウェアラスタライザを力技で回す判断は、実行環境の差異に起因する不確実性を極限まで削ぎ落とすことに寄与した。 一見無骨にも思えるこの選択が、脱線しやすい長大なクロスプラットフォーム再構築を、純粋な入力と出力の変換問題へと単純化させた。
1フレーム単位のピクセル照合という絶対基準
Quake-SRPの真の技術的支柱は、自動化された検証システムにある。大規模言語モデルによる移植作業の精度を保証するため、プロジェクトはオリジナルのWinQuakeのCコードからヘッドレス版バイナリを単独でビルドし、テストスイート全体の唯一の真実（オラクル）として配置した。テストスイートは9つのマップ、2つの解像度でモンスターが徘徊する状態のまま数百フレームを実行し、新エンジンが出力する描画ピクセル、UI表示、オーディオ波形サンプル、デモ再生時のゲーム内部状態を、リファレンス実装とフレーム単位で照合する。READMEには既知の差異が客観的に記録されており、実証されていない同一性を軽々しく主張することはない。
エミュレータ開発の領域において、画像比較テスト自体は珍しいものではなく、Dolphinなどのプロジェクトでも包括的なビジュアルCIが長年運用されてきた。しかし、3Dゲームプレイの一連のシーケンスを1ピクセル単位で追跡し、ミップマップのサンプリング境界やライティングの微小な差異まで突き合わせる検証は、フロントエンド開発におけるDOMスナップショットテストとは比較にならない難度を伴う。モデルが一度のプロンプトでどれだけ多くのコードを生成できるかは成功の本質ではなく、機械がピクセル単位の差異を自律的に識別できるかどうかが、コード生成を現実の動作へと結びつけるアンカーとなる。 リファレンスオラクルが合格判定を出さない限り、構文がいかに美しくとも採用されない。
図：ClassicプリセットにおけるE1M1の描画画面（1280×960）。オリジナルのWinQuakeの挙動を厳密に再現している。出典：quake-srp リポジトリのスクリーンショット
図：デフォルトプリセットでの同一マップ（1920×1080）。ワイドスクリーンの視野角とフレームレート制限解除が適用されている。出典：quake-srp リポジトリのスクリーンショット
全テスト合格時のみブランチを統合する調整エージェント
リポジトリのREADMEには、この人間と機械による協業プロセスの責任分担が明記されている。Claude（Claude Code経由）がコード本体、リファクタリング、ドキュメントの主たる執筆を担当し、人間のエンジニアは制約条件の設定、実機プレイによる挙動確認、問題の報告、そしてGitブランチ間でのタスク調整役に徹した。さらにプロジェクト内には「調整役（chair）」エージェントが配置され、すべての自動テストと画像照合をパスした場合にのみブランチをマージする体制が取られた。
この分担構造によって、正しさの検証という最も負荷の高い作業が確定的なリファレンス実装へと委ねられ、人間が機械の生成したコードを行ごとにレビューする負担から解放された。本作には原作の挙動を忠実に再現する ?classic モードに加え、ワイドスクリーン表示やフレームレート制限解除を施したデフォルトの ?slop モードが用意されている。人間は最終成果物としてのゲームプレイ体験の品位にのみ責任を負い、試行錯誤やメモリリーク、ポインタ境界エラーの修正コストは生成器側のループで完全に消費された。
図：透視テクスチャマッピングの画面間アライメント照合図。プロジェクト独自の画像照合ツールが稼働した際のスライス。出典：quake-srp リポジトリのスクリーンショット
メインフレームのCOBOL刷新へと通じる検証パイプライン
Quakeエンジンの再構築は、レトロゲームの再現にとどまらず、ソフトウェア業界が抱える最も重い歴史的負債の解消に向けたワークフローとしてエンジニアたちの注目を集めた。Hacker Newsの議論では、同様のエンジンリバースエンジニアリングにClaudeを活用した開発者が経験を共有している。モデルが自律的にリプレイ用スクリプトを走らせ、定期的なスクリーンショットを取得して双方向検証を行い、原版コードを解析して状態マシンを決定論的な挙動へとパッチ修正したという。機械主導の検証と書き換えの信頼性が立証されたことで、議論は現在も金融機関の基幹系で稼働し続けるCOBOLメインフレームの移行問題へと自然に波及した。
人手による膨大な検証コストと、網羅が困難なエッジケースの存在こそが、こうしたレガシーシステムがクラウドネイティブ環境へと移行できない真の要因である。業務ロジック自体は古いコードの中に記述されているものの、複雑に絡み合った依存関係ゆえに誰も書き換えのリスクを背負えない。これこそが、高精度なオラクルによる並行検証システムが最も価値を発揮する領域だ。高精度な入出力比較フレームワークが確立されれば、メインフレームの刷新はエンジニアのキャリアを賭けた危険な冒険から、計算資源と時間を投じてリスクを相殺する計画的なコードヘッジへと変貌する。
制御プロトコルの偽造へ転用され得る二面性
だが、この能力がもたらす影響は一方向にとどまらない。生成モデルと自動検証器によるフィードバックループが、試行錯誤と差分修正の繰り返しによって1990年代の複雑なゲームエンジンを無欠損で翻訳できるのであれば、それは未知のクローズドなシステムが持つ内部状態遷移ルールを読み解き、完全再現する能力をも併せ持つことを意味する。議論のもう一つの焦点は、この技術が秘める攻撃的な側面に向けられた。高精度なブラックボックスリバースエンジニアリングが悪用された場合、重要インフラの防御層を欺瞞する偽造コマンドや偽装インターフェースが容易に生成されかねないという懸念だ。「再現できる程度のシステムは『隠蔽によるセキュリティ』に甘えていただけだ」とする反論に対し、産業用制御システム（HMI）などのコマンド体系がクローンされた場合の破壊的影響は、金融取引の不整合とは桁が違うという指摘が即座に返された。
差異の特徴を自動検出し、論理の欠落を埋めていくモデルの本質は、計算可能な論理空間を収束させていく最適化エンジンであり、解析対象が娯楽用のオープンソースソフトウェアか、堅牢に保護された産業基盤かを区別することはない。Quake-SRPの取り組みに立ち返れば、unsafeゼロのコードが示した教訓は明快だ。長大で難解なレガシーコードの迷宮を前にしたとき、人間がAIの生成したコードの海で不具合を手作業で捜索するよりも、まず極めて精緻な自動ピクセル検証器を仕立てることこそが最優先されるべきだ。この検証装置は、過去のコードを再生させる原動力であると同時に、コード生成AIの手綱を握る強固なガードレールでもある。
参考リンク：
- GitHub リポジトリ概要
- Quake-SRP オンラインデモ
- Hacker News コミュニティディスカッション
