Nintendo Switchエミュレーターのsuyuは、最終公開版となる0.04にRecompiler mode（静的再コンパイルモード）を加えた。Switch向けのAArch64ゲームコードを、PCで広く使われるx86-64の実行形式へあらかじめ変換するという。実行しながら命令を翻訳する従来の方式から、重い仕事の一部を起動前へ移す試みである。
Wccftechはこれを「ネイティブ」PC性能への飛躍と報じ、CPU負荷やシェーダーコンパイル時のカクつきが減る可能性を挙げた。仕組みには期待できる。だが、suyuの公開資料が確認するのは機能の説明までで、速度向上を測った数字はない。いま分けて考えるべきなのは、静的再コンパイルが持つ理論上の利点と、suyu 0.04が実際に達成した性能だ。
「ネイティブPC版」が生まれたわけではない
suyuのREADMEは、ゲームを動かす方法を二つに分けている。従来のエミュレーションモードは、GPUやCPUに加え、音声とサービスをsuyuのコアで扱う。新しい静的再コンパイルモードは、AArch64のゲームコードをx86-64実行形式へ事前変換し、suyuのHLE（高水準エミュレーション基盤）と組み合わせる。
この説明で注目すべき言葉は「組み合わせる」だ。CPUが実行するゲームコードの一部をx86-64へ変換しても、Switchの動作環境そのものがWindowsやLinuxへ変わるわけではない。ゲームはSwitchのOSサービスを呼び、独自のメモリ配置や同期の前提で動く。GPUへ送る命令も、PC側のVulkanなどへ橋渡ししなければならない。入力、音声、時間管理も残る。
したがって、生成されたCPUコードがPCのプロセッサで直接動くという意味では「ネイティブ」と呼べても、ゲーム全体のネイティブPC移植とは違う。通常のPC移植なら開発者がソースコードを別環境へ適応させ、描画や入出力まで作り直す。suyuはバイナリからCPUコードを変換し、残りをエミュレーター側の互換機構で受け止める。速くなる余地はあるが、エミュレーションが消えるわけではない。
JIT、静的再コンパイル、ARMでの直接実行
三つの方式は、Switchの命令を「いつ」「どのCPUで」扱うかが異なる。x86-64 PCで一般的なJITは、ゲームを実行しながらAArch64のコードブロックを見つけ、x86-64命令へ変換して保存する。最初に通る経路では翻訳の費用が生じるが、実際に使われたコードへ絞れ、実行時に分かった情報も最適化へ使える。
静的再コンパイルは、その変換を実行前へ動かす。あらかじめコードを解析し、x86-64実行形式を作っておけば、同じ箇所を遊ぶたびに変換する必要を減らせる。実行中の翻訳器やコードキャッシュ管理が担っていた仕事の一部を外へ出せるため、CPU負荷やフレーム時間の揺れを抑える可能性がある。ここまでは方式から導ける。効果の大きさは別問題だ。
一方、yuzuがAndroid向けに進めたNative Code Execution（ネイティブコード実行、NCE）は、さらに条件が違う。Switchも多くのAndroid端末も64ビットARM系の命令を使うため、対応するゲームコードを別の命令へ翻訳せず、ARMプロセッサで直接走らせる発想である。x86-64 PCはAArch64命令をそのまま実行できない。suyuの静的方式では翻訳が依然として必要で、その時点を前へずらす。
2023年にyuzuが報告した60〜70％の改善も混同できない。この数字は、ARM64ホストで32ビット版『マリオカート8デラックス』を動かす際、Dynarmicのblock linkingを有効にした結果だった。suyu 0.04のAArch64からx86-64への静的再コンパイルを測った値ではない。同じエミュレーターの系譜にある技術でも、対象CPUと変更箇所が違えば、そのまま性能の根拠にはならない。
事前変換が減らせる負担、増やす負担
事前にすべて変換できるなら、実行中の仕事は軽くなる。ところが、ゲームの機械語は必ずしも上から順番に実行されない。間接分岐では行き先がメモリ上の値で決まり、実行時に生成または書き換えられるコードもあり得る。プログラムが実際に走る前に、到達する命令を完全に見つけるのは難しい。
静的再コンパイラーは、見つけられなかった経路をどう処理するかという設計を迫られる。安全な補助機構へ戻るのか、未対応として止めるのか。SwitchのOSサービスを呼ぶ境界では、元の処理をsuyu側の実装へ正しくつなぐ必要もある。変換できた命令の割合だけでなく、補助機構へ戻る頻度が実際の速度と互換性を左右する。suyuのREADMEは、この範囲を開示していない。
負担が消えるのではなく、場所も変わる。利用者はゲームを始める前に変換を待ち、生成物を保存する容量を用意する。ゲーム本体の更新やDLC、改造でコードが変われば、どこまで作り直すかを判断しなければならない。JITなら遊んだ経路だけを順次変換できるが、静的方式は実行前に広い範囲を読むほど時間と容量を使う。どちらが有利かは、ゲームの構造とPCの性能、実装の完成度で変わる。
シェーダーのカクつきもCPUコードだけの問題ではない。ゲームが使うGPUシェーダーをPC向けへ変換し、描画パイプラインをドライバーが作る場面で待ち時間は発生する。CPU側の実行経路が事前に分かれば準備を進めやすくなる可能性はあるが、suyuの資料はGPU側をどこまで前処理するかを説明していない。「静的再コンパイルだからシェーダーのカクつきもなくなる」とは、まだ言えない。
「速くなるはず」と「速くなった」の間にある6つの空白
suyu 0.04の公開資料には、比較FPS、フレーム時間、テスト用PC構成、対応ゲーム一覧、変換時間、生成ファイル容量という6項目の測定情報がない。 これは2026年9月15日に取得した公式README全文を対象に、性能と互換性を第三者が追試するための項目を個別に確認した結果である。README以外や後続フォークにデータが存在する可能性は残るため、不記載は機能が動かない証明ではない。
平均FPSだけでも足りない。JITの翻訳負荷やカクつきを論じるなら、同じゲーム、同じ場面、同じPC、同じ設定でフレーム時間の分布を比べる必要がある。平均値が同じでも、長いフレームが減れば操作感は改善する。反対に、平均FPSが上がっても変換漏れで停止するなら、利用者にとって完成した高速化にはならない。
対応ゲーム一覧は効果の範囲を決める。数本のタイトルが起動することと、複雑な大作を長時間安定して遊べることは違う。事前変換に何分かかり、生成物が何GBになるかも、実行時の速度と交換する費用である。さらに、同じゲームでも更新版やDLCでコードは変わる。バージョンを固定しなければ比較結果を再現できない。
Wccftechは中級クラスのPCやオープンワールド作品が恩恵を受けると予測したが、記事にはその比較表や試験手順がない。現時点で確認できるのは、有望な構成が公開されたことだ。どのPCで何％速くなったかは確認できない。
最終版の価値と、止まった検証
suyu 0.04には、性能評価とは別の難しさがある。プロジェクトは今回を最終公開版とし、リポジトリをアーカイブした。READMEには今後の開発やダウンロードを予定しないとある。Windows、Linux、Android向けビルドを挙げる一方、macOSとiOSは対象外だ。新しい方式が公開された直後に、公式の改良と不具合修正が止まる。
利用者の報告も、再現性が固まっていないことを示す手掛かりになる。suyuの利用者コミュニティでは、静的再コンパイルを試したゲームがクラッシュしたとして、動作例を求める投稿が出た。別の利用者は後続フォークを案内している。ただし、PC構成とビルドは統制されていない。ゲームデータや設定も不明なため、これをsuyu全体の失敗率にはできない。
それでも、静的再コンパイルを既存のSwitchエミュレーターへ組み込み、高水準エミュレーション基盤と接続する設計を公開した意味は小さくない。コードがアーカイブとして残れば、後続の開発者は変換できる範囲を広げ、補助機構を整え、測定を積み上げられる。v0.04は完成品というより、検証可能な出発点である。
この方式が「ネイティブ性能」と呼べる段階へ進んだかは、同一条件で測ったフレーム時間、CPU使用率、事前変換の所要時間、対応率、補助機構へ戻る割合で判断できる。その測定で速度と安定性の改善が確認され、低価格なPCでも同じ結果を再現できれば、静的再コンパイルは看板ではなく実用的な選択肢になる。
