31億7000万トークン、4,974ドルのAPI利用料、そして24暦日。1人のエンジニアが1つの統括セッションと147体の専門サブエージェントを指揮し、NINTENDO 64の名作レースゲーム『F-Zero X』をニンテンドー3DSへ移植するプロジェクトを完遂した。新世代機のNew 3DSでネイティブ60fpsの立体視3D表示を達成しただけでなく、わずか268MHzで動作する旧型のOld 3DSへの適応までも成し遂げている。
レトロゲームの自作コミュニティにおいて、逆コンパイルコードを基盤にしたコンソール全体の移植は通常、複数人のボランティアが何年も費やす大事業である。「G-Diffuser on 3DS」プロジェクトはその開発期間を実質2週間余りに凝縮した。自動化によるコード生成は初期の定型作業を劇的に減らしたが、同時に真のエンジニアリング課題を強烈に浮き彫りにした。
自動化パイプラインの導入によって、単にコードを書く工程は主役の座をあっさりと明け渡した。真の断絶は、実機シリコンが高負荷に晒されたときのパフォーマンス要因究明フェーズで露呈した。実機に組み込まれたハードウェア性能カウンタを用いて命令キャッシュの物理的境界を突き止めてはじめて、システムは10fpsという惨状から60fpsへの決定的な跳躍を果たしたのである。
1人が147体のエージェントを指揮：暗転から24日で60fpsへ
プロジェクトは2026年8月11日に始まった。開発者はコミュニティによる『F-Zero X』の逆コンパイル成果物を土台にし、単独オペレーターによるエージェント・パイプラインを構築した。上流のゲームロジックは忠実に維持しつつ、移植の全精力を3DS専用のハードウェア抽象化レイヤー構築へと注ぎ込んだ。
第1フェーズの開発は暦日で24日間続いたが、実際に稼働した日は15日に過ぎない。途中でモデルプロバイダーの週間利用制限（レートリミット）を使い果たし、3度の中断を余儀なくされた。それらの足止めを含めながらも、コードベースは9月3日に「起動時の暗転」から「New 3DSでのネイティブ60fps動作」というマイルストーンを一気に駆け抜けた。
オーケストレーション体制は、全体を取り仕切るセッションと147体の特定タスク向けサブエージェントで構成され、細分化されたサブタスクが並行して処理された。この運用手法が初期の泥臭い作業を大幅に圧縮し、単独開発者に小規模チーム並みの開発速度をもたらした。
図：v1.0.0 実機（New 3DS）でのレース画面：下画面にはDASHメーターが稼働し、エネルギー残量、順位、ラップタイム、コースマップを表示。出典：G-Diffuser on 3DS プロジェクト事後検証
法的コンプライアンスの設計も初期段階から徹底された。配布される最終バイナリには、著作権で保護されたゲームROMやディスクイメージなどのデータは一切含まれていない。ユーザー自身が用意したアセットパックをSDカードから動的に読み込む仕組みを採用し、潜在的な法的リスクを回避した。
31億トークンで1万5000行を生成、だがエミュレータの最適化は実機で破綻
第1フェーズで消費された31億7000万トークンは、公開リスト価格換算で約4,974ドルに相当する。これによって移植ツリー配下に生み出されたのは、15,039行のネイティブコードと48件の累積パッチだった。
だが、コードがコンパイル通りに動くことと、快適に遊べることは全く別物である。8月14日にエミュレータ上で初めてレース画面が動作した際、フレームレートは12〜20fpsの間を彷徨っていた。8月21日に初めて実機へ書き込んでテストした際には48〜50fpsまで改善したものの、高速レースゲームとして譲れない滑らかな60fpsには依然として遠く及ばなかった。
開発者はここから泥沼の微細チューニングへ突入する。9月2日のハードウェア実測ベンチマークでは、中央値フレームレートは51.3fps、p10（ワースト10％）は39.2fpsまで落ち込み、上限である60fpsに張り付いていた時間は全体のわずか9%に過ぎなかった。この時点でPC上のエミュレータではプロファイリンググラフが滑らかに安定してしまっており、物理チップ固有のレイテンシやボトルネックを全く捉えられなくなっていた。
チームは立て続けに5巡のアーキテクチャ改修を断行した。高速ブリッジキャッシュの導入により中央値は57.2fpsへと向上。続いてHUDテクスチャアトラスの再構成、三角形描画バッファの最適化、オーディオミキシングの改良を重ね、p10フレームレートを48.0fpsまで引き上げた。さらに描画スレッドを第3のCPUコアへ逃がし、Ahead（前方予測）モードとライバル車の描画負荷適応制御を有効化したことで、9月3日の最終計測で実機中央値は59.6fpsに到達した。
図：v1.0.0 実機（New 3DS）でのExpansion Kit「Select Mode」（COURSE EDIT、CREATE MACHINE）。下画面はDASH待機画面。出典：G-Diffuser on 3DS プロジェクト事後検証
実機で直面した10fpsの悪夢：真の病巣は命令数ではなく16KB命令キャッシュ
第2フェーズに入ると、開発の照準は極限までスペックが切り詰められた初代Old 3DSへと向けられた。動作クロックわずか268MHzのCPUと、アプリ用に割り当てられた64MBのメモリ。コミュニティでは「このハードで60fpsの高速3Dレースを動かすのは不可能」と長年見なされていた。開発ブランチは本線から分岐し、並行エージェントによる徹底的な省メモリ化が始まった。
しかし、9月29日の初の実機テストはチームに冷や水を浴びせた。New 3DS向けのビルドは起動直後にクラッシュ。旧型向けにメモリを削ぎ落としたビルドはかろうじてレース画面に到達したものの、表示されたのは無残な10fpsだった。エミュレータ上であれほど論理的と思われたパフォーマンス予測が、実機シリコンの前で完全に崩壊した瞬間だった。
常套手段のソフトウェア最適化はすぐに限界に達した。オーディオ用の排他制御（ミューテックス）のスコープを極限まで絞ることで1フレームあたり約20ミリ秒の待機時間を削り出し、フレームスキップの導入によって不自然なスローモーション現象を解消した。だが、実機上での根本的なレンダリング所要時間は高止まりしたままだった。
事態が急転したのは9月30日から10月1日にかけてのことだ。開発者がARMコアの内蔵ハードウェア性能カウンタを用いて詳細な実機サンプリングを実施したことで、真のボトルネックが白日の下に晒された。システムを圧殺していたのは実行命令の絶対量ではなく、ARMコアに備わったわずか16KBのL1命令キャッシュで発生していた膨大なキャッシュミスだったのだ。
この致命的な壁を前に、エージェント陣は即座にある妥協案を提示してきた。入力応答性を一部犠牲にしてフレームレートを取り繕う「姿勢再生パイプライン」である。技術的実装は整っていたが、人間のリードエンジニアはコードレビューでこれを即座に却下した。あくまで実機ネイティブの60fpsに挑む方針を貫いたのである。
レンダリングパイプラインを全面刷新、2世代のハードを全速駆動
根本原因が判明したことで、最適化のアプローチは180度転換した。命令数を数ステップ削る小手先の作業は打ち切られ、コード全体を命令キャッシュの局所性（Locality）に適合させる全面リファクタリングが開始された。10月1日、独自のネイティブレンダリング・インタプリタの設計に着手した。
従来の移植フレームワークは、オリジナルのN64が備えていたディスプレイリスト走査機構を踏襲していたため、コードサイズが肥大化し、分岐ジャンプが頻発していた。新開発の独自レンダラは複雑なジオメトリ探索を全廃し、マシンやコースといったエンティティ種別ごとに極小のレンダリングループを構築した。ホットスポットとなる各ループのバイナリサイズは、すべて16KBの命令キャッシュ枠内に厳格に収まるよう設計された。
図：Homebrew Launcher（.3dsx）から起動したマシン選択画面のBlue Falcon。出典：G-Diffuser on 3DS プロジェクト事後検証
この刷新の効果は劇的だった。Old 3DSの2Dモードにおけるグランプリ1フレームあたりの描画時間は、中央値で16.5ミリ秒にまで急縮小した。乗り越え不可能に見えた旧型機のスペックの壁は、コードサイズが命令キャッシュの物理境界と合致した瞬間に雲散霧消したのである。
続く2週間で、片目ごとの立体視レンダリングと適応型垂直同期スケジューリングが実装された。描画負荷が極度に高い2つの例外コースで30fpsセーフティが働くのを除き、大半のコースでOld 3DSは59〜60fpsのフルスピード走行を維持できるようになった。単一の統合コードベースから、2世代のハードウェアを網羅する3種類のリリースビルドを出力することに成功した。
自動生成の時代だからこそ、「因果の究明力」がエンジニアの境界線となる
G-Diffuserプロジェクトは、現代のAI協調型ソフトウェア開発を評価する上でこの上ない教訓を与えている。AIエージェントはモジュールの組み立てや初期コードの高速生成において圧倒的な実力を発揮し、大規模リバースエンジニアリングの参入障壁を劇的に押し下げた。しかし、物理ハードウェアからの生きたフィードバックが欠落している環境では、エージェントは局所最適解という袋小路に向かって容易に空回りを始める。
エミュレータ上での快調な動作は、実際の物理チップ上で起きているキャッシュスラッシングやバス競合を往々にして覆い隠してしまう。実機で10fpsの泥沼に直面したとき、既成のプロンプトをどれほど工夫してもハードウェア性能カウンタのサンプリング結果を自動的に導き出すことはできない。数十万行に及ぶ命令の中から16KBのキャッシュ境界を病巣として特定できたのは、計算機アーキテクチャへの深い理解に裏打ちされた人間の洞察だった。
43日間に及んだこの技術的格闘は、人間とAIの役割分担を明確に定義している。優秀なエージェントの艦隊は、資材を猛スピードで運び、足場を組み、膨大な試行錯誤パッチを肩代わりしてくれる。だが、プロジェクトの命運を分けるのは、依然として第一原理に基づいた根本的なシステム要因の究明と、大胆なアーキテクチャの決断なのである。
参考リンク：
- G-Diffuser on 3DS プロジェクト事後検証
- Hacker News ディスカッション
