SwitchゲームがiPhoneとMacでネイティブ動作:オープンソースプロジェクトnxnativeの技術解説#
皆さんこんにちは、紫星です。ここ2週間、私はあるオープンソースプロジェクトを注視してきました。新しいベンチマークツールではありませんが、多くのスコア以上にAppleチップの現在の立ち位置を物語る存在——それがnxnative(GitHubリポジトリ:seedds/nxnative、MITライセンス)です。このプロジェクトのスター数の伸びは、今年私が見た中で最も急な曲線です。10月19日に500を突破、10月21日に1000を突破、10月23日に2500を突破、そして10月26日時点で約3000スター。直近7日間で約2600増加、1日平均約370ペースです。リポジトリの作成日は2026年10月13日。つまり、リポジトリ作成から1000スター突破までわずか8日でした。
このプロジェクトがやっていることを一言で言えば、プレイヤー自身が所有するSwitchゲームのNSPファイルにprod.keysキーを組み合わせ、スクリプト一つでiPhone、iPad、Macにサイドロード可能な未署名IPAへ変換する——そしてゲームが自力で動くというものです。注意すべきは、公式がリポジトリ内で明確に「エミュレータではない」と記している点です。ゲーム自身のコードはAppleチップ上で直接動作し、SwitchのグラフィックスはMetalで再構築されます。長年トランスレーションレイヤーと向き合ってきた技術ライターとして、この立ち位置は真剣に受け止めるべきだと考えます。以下、私の流儀に従って、その技術アーキテクチャを三本柱に分けて一つずつ見ていきましょう。
一、まずはプロフィールから:これはどんなプロジェクトか#
| 項目 | 内容 |
|---|---|
| リポジトリ | GitHub上のseedds/nxnative |
| ライセンス | MIT |
| 入力 | プレイヤー自身が所有するゲームのNSPファイル + prod.keysキー |
| 出力 | iPhone/iPad/Macにサイドロード可能な未署名IPA |
| 立ち位置 | 公式が明確に宣言:エミュレータではなく、ゲームコードはネイティブ実行 |
| 資産の境界 | リポジトリにはゲームコンテンツを一切含まず、任天堂およびいかなるパブリッシャーとも無関係 |
「エミュレータではない」という宣言は、技術的に実質的な意味を持つものであり、宣伝文句ではありません。従来のエミュレータは、ホストデバイス上で本体のハードウェア動作を完全に再現する必要があり、その代償としてすべてのレイヤーがエミュレーションという関門を通らなければなりません。一方、nxnativeのアプローチは、ゲームそのものをAppleプラットフォームのネイティブアプリへ書き換え、システムレベルの欠落を一つのホスト層で補うというものです。この二つのルートの違いについては、後の第九節で表を使って比較します。
二、スター数の軌跡:2週間で他の1年分を走り切る#
| 時点 | 節目 |
|---|---|
| 2026-10-13 | リポジトリ作成 |
| 2026-10-19 | スター数500突破 |
| 2026-10-21 | スター数1000突破 |
| 2026-10-23 | スター数2500突破 |
| 2026-10-26 | 約3000スター、直近7日間で+2600(1日平均約370) |
中国語圏コミュニティでの拡散も、この流れを加速させています。北京郵電大学の教員「爱可可-爱生活」が10月23日にTouTiaoで紹介記事を公開し、A17 ProおよびM1以上のデバイスで複数のゲームが快適に動作し、60fpsをフルに出せることを実測で確認したと報じています。一つのプロジェクトが2週間で英語圏の開発者コミュニティと中国語圏のゲーマーコミュニティの両方を同時に突破するのは、純粋な技術プロジェクトとしては珍しいことです。
三、技術解説①:NSOリライター——ゲームバイナリをネイティブ実行形態へ書き換える#
第一の柱はNSOリライターです。SwitchゲームのコードはNSO形式のバイナリとして存在しており、このリライターの仕事は、ゲームバイナリをAppleアーキテクチャでネイティブ実行可能な形態に書き換えることです。これにより、ゲームコードはエミュレーションレイヤーを挟まず、Appleチップ上で直接動作します。
ここには、単独で触れる価値のある前提条件があります。Switch本体のプロセッサはそもそもARMアーキテクチャであり、ゲームコードは最初からARM命令セット向けにコンパイルされています。一方、Appleチップ(AシリーズとMシリーズ)が実行するのもARM64命令セットです。両者は同型であるため、リライターはアーキテクチャをまたぐ命令変換を行う必要がなく、ロード形式とバイナリレイアウトの書き換えを処理するだけで済みます。これが事実レベルで最も見落とされがちな点です。この「非エミュレーション」ルートが成立するのは、ARM64同型性の恩恵があるからです。もしターゲットプラットフォームがx86アーキテクチャのPCであれば、この同型性が欠け、ルート全体の複雑さはまったく違うものになったでしょう。だからこそ、この種のプロジェクトは他のエコシステムではなくAppleエコシステムに現れたのです。
四、技術解説②:Horizon HLEホスト層——代役のシステムサービス#
SwitchのOSはHorizonと呼ばれ、ゲームは実行時にさまざまなシステムサービスをHorizonに要求します。iPhoneやMac上に当然Horizonは存在しないため、nxnativeは第二の柱としてHorizon HLEホスト層を用意しました。これは、代役となるシステムサービス一式で本物のHorizonを置き換え、ゲームに「まだSwitch上で動いている」と思わせる仕組みです。
HLEとはハイレベルエミュレーション(High-Level Emulation)の考え方を指します。カーネルの低レベルな詳細をエミュレートするのではなく、高レベルで意味的に等価なサービスインターフェースを直接提供します。注目すべきは、このホスト層の同期セマンティクスがAtmosphèreのmesosphèreカーネルを参考にしている点です。AtmosphèreはSwitchカスタムファームウェアコミュニティで最も重要なカーネルレイヤー実装であり、そのカーネルコードによるHorizonの動作の再現は、大量の実機検証を経ています。コミュニティで長年鍛えられたオープンソース実装を参考にするのは、システムの挙動を当てずっぽうで推測するよりはるかに信頼できます。このプロジェクトのエンジニアリング判断の賢いところです。
五、技術解説③:NVN→Metalグラフィックス変換レイヤー#
第三の柱はグラフィックスを解決する部分です。SwitchのグラフィックスAPIはNVNと呼ばれ、ゲームのシェーダーはMaxwellアーキテクチャ向けに書かれています。一方、iOSとmacOSのグラフィックススタックはMetalです。この三者は、そのままでは一つも会話が成立しません。nxnativeの変換パイプラインは次のようになっています。
- ゲーム内のMaxwellシェーダーを、まずRyujinxエミュレータがMITライセンスでオープンソース化したコンバーターでSPIR-V中間表現へ変換;
- 次にSPIRV-CrossツールでSPIR-VからMetal Shading Languageソースコードへ変換;
- 最終的にMetal上でSwitchのグラフィックス描画を再構築。
このパイプラインは本質的に、SwitchのグラフィックススタックをレイヤーごとAppleのグラフィックススタックへマッピングするものです。シェーダー変換は一気通貫で行われ、テクスチャと描画のセマンティクスは変換レイヤーが補完します。オープンソースエコシステムの再利用がここでも十二分に発揮されています。シェーダー変換という一環は、車輪の再発明をせずにRyujinxの肩の上に直接乗っているのです。
六、三本柱を支えるコンポーネント群#
コアの三本柱に加えて、リポジトリにはそれぞれ役割を持つコンポーネント群があり、これらが揃って初めて完全なパイプラインになります。
| コンポーネント | 役割 |
|---|---|
| LibHac | ゲームNSPファイルの解析 |
| deko3dテクスチャレイアウト | テクスチャレイアウトアルゴリズムはSwitchプラットフォーム向けグラフィックスライブラリdeko3dから移植 |
| libvpx | 動画再生の処理 |
| stb_vorbis | 音声の処理 |
このコンポーネントリストからは作者のスタイルが読み取れます。NSP解析、テクスチャレイアウト、動画、音声、すべて成熟したオープンソース実装の再利用を優先し、本当に欠けている部分だけを自前で書いています。2週間で3000スターに達したプロジェクトとしては、この抑制の効いたエンジニアリングの趣味は、スター数そのものよりも成熟度を物語っています。
七、ハードウェア要件:なぜA17 ProとiOS 26で頭打ちになるのか#
| 要件 | 条件 |
|---|---|
| iPhone | iPhone 15 Pro以降の機種(A17 Proチップ以上) |
| iPad | M1チップ以上 |
| OS | iOS/iPadOS 26以降 |
| ストレージ | 約NSPファイルサイズの2倍 + 10 GB |
OSバージョンのこの線が厳格なのは、テクスチャが理由です。ゲームのテクスチャはBC圧縮形式を採用しており、旧デバイス(旧OS)では読み込めないため、iOS/iPadOS 26がハードな下限となります。チップの要件も同様にハードです。A17 ProとM1がリストの起点であり、柔軟な余地はありません。ストレージは「NSPの2倍 + 10 GB」を見込んでおく必要があり、これはパイプライン内の変換産物のサイズ特性と一致します。大容量のゲームをインストールする前に、この分を先に計算しておきましょう。
八、互換性の現状:どのゲームが動き、どこまで動くのか#
プロジェクトはゲームごとに個別の説明ページを用意しており、テスト済みリスト(MacまたはiPhoneでの実測)には以下が含まれます。
- 『スーパーマリオブラザーズ ワンダー』(Super Mario Bros. Wonder)(当サイトに攻略あり:『スーパーマリオブラザーズ ワンダー』)
- 『ファイアーエムブレム Engage』(Fire Emblem Engage)
- 『ゼルダの伝説 ブレス オブ ザ ワイルド』(The Legend of Zelda: Breath of the Wild)
- など数十タイトル——リストの規模はリポジトリREADMEの現在のリストを基準とし、本記事では具体的な総数を固定で記載しません
いくつかの重要な現状を整理します。
| 項目 | 現状 |
|---|---|
| フレームレート | 一部のゲームはSwitchネイティブの30fpsから60fpsへアンロック可能。ゼルダの伝説シリーズは1.2.0などの特定のアップデートバージョンが必要 |
| 操作 | タッチ操作(2D/3Dレイアウト)と外部コントローラに対応 |
| 非対応 | amiiboとオンライン機能 |
| 『ゼルダの伝説 ティアーズ オブ ザ キングダム』 | まだ移植中。現時点ではオープニングの洞窟までしか到達できない(iPhone 15 Pro以降、iOS 26)。フレームレート問題は未解決 |
| リスト外のゲーム | スクリプトが調査レポートを生成し、設定を推測してパッケージ化を試みるが、起動しない可能性がある |
最後の項目は特に注目に値します。リストにないゲームについては、パイプラインがまず調査を行ってからパッケージ化を試みます。これは「ベストエフォート」の仕組みであり、保証ではありません。ニッチなゲームでいきなり動かそうとするプレイヤーは、手を動かす前にゲームごとの説明ページを確認すれば、一晩分のビルド時間を節約できます。
九、エミュレータルートとのメカニズム比較#
nxnativeと従来のエミュレータを並べて見ると、その違いは程度の問題ではなく構造的なものです。
| 観点 | nxnative(トランスレーションルート) | 従来のエミュレータ(フルシステムエミュレーションルート) |
|---|---|---|
| 命令実行 | ゲームコードはNSOリライト後、Appleチップ上でネイティブ実行 | ホスト上で本体CPUの動作全体をエミュレート |
| グラフィックス | NVN→Metal変換レイヤーでSwitchのグラフィックスを再構築 | 本体GPUをエミュレートまたは全体をトランスレート |
| システムサービス | Horizon HLEホスト層がシステムサービスを代行 | システム環境をエミュレートまたは再構築 |
| 提供形態 | ゲームごとに独立したIPAを一つ生成 | 汎用エミュレータがゲームファイルをロード |
明確にしておくべきは、執筆時点で、nxnativeとYuzu、Ryujinxなどのエミュレータを比較した第三者機関によるパフォーマンスベンチマークデータは存在しないということです。したがって本記事ではメカニズムレベルの比較のみを行い、パフォーマンスに関する結論は出しません。「トランスレーションは必ずエミュレーションより速い」といった主張は、ベンチマークが登場するまではあくまで推測であり、ハードウェアライターとして私はそれを保証しません。
十、ソースコードからIPAまで:ビルドとサイドロードの流れ#
ビルドはMac上で行い、環境にはXcodeとHomebrewが必要です。主要な依存関係と手順は以下の通りです。
| 手順 | 内容 |
|---|---|
| 1. リポジトリをクローン | git cloneでソースコードを取得 |
| 2. ツールチェーンをインストール | brew install xcodegen zstd spirv-cross glslang。さらにdotnet-sdkとPython依存関係(lz4、capstone、fonttools、nsz)が必要 |
| 3. 入力を準備 | プレイヤー自身のNSPファイル + prod.keys。NSZ/XCZ圧縮形式の自動変換に対応 |
| 4. ビルド | 初回ビルドには約30〜60分かかり、単一のIPAが出力される |
| 5. サイドロード | AltStoreまたはSideloadly経由でデバイスへサイドロード |
| 6. カスタマイズ | 設定はデバイスのDocumentsディレクトリ下のenv.txtでカスタマイズ(フレームレート、言語など) |
コミュニティエコシステムには、単独で触れる価値のあるフォークがもう一つあります。NX2Appleです。これは独立したプロジェクトで、macOS向けのGUIアプリケーションを提供し、パッケージ化パイプライン全体を実行して、分割されたRomFSアーカイブを生成することでIPAのサイズを小さくします。コマンドラインに触れたくないユーザーはこのルートに注目するとよいでしょう。ただし、これはコミュニティの独立プロジェクトであり、メインリポジトリとは分けて評価すべき点にご注意ください。
十一、起源と法的境界:グレーゾーン上のプロジェクト#
系譜をたどると、nxnativeはd2r-mobileからフォークされています。d2r-mobileは『ディアブロII リザレクテッド』(Diablo II: Resurrected、当サイトに攻略あり:『ディアブロII リザレクテッド』)をiOS上でネイティブ動作させるプロジェクト(MITライセンス)です。d2r-mobileの汎用的な部分——NSOリライター、Horizonホスト層、NVN-on-Metalグラフィックスレイヤー、iOSアプリシェル——が切り出されて一般化され、nxnativeとなりました。現在も両プロジェクトは互いに修正を還元し合っています。「一つのゲームが動く」から「一つのフレームワークで複数のゲームが動く」へ。この方法論の再利用の道筋は、モバイルゲーム移植コミュニティにおける一貫した協力のあり方と通じるものがあります。
法的側面については、三つの事実を正直に述べなければなりません。第一に、プロジェクトはプレイヤーが合法的に所有するゲームとキーのみを扱うと宣言していること。第二に、リポジトリにはゲーム資産を一切含まないこと。第三に、プロジェクトは任天堂およびいかなるパブリッシャーとも無関係であること。この三つはリポジトリに白紙黒字で書かれた自己の立ち位置です。当サイトの観察によれば、執筆時点で任天堂側による公の行動の報道はありません。つまり、「グレーゾーン」というのは現時点では法的状態の記述であり、すでに起きた出来事についての言及ではありません。任天堂がエミュレータ分野で示してきた歴史的な権利行使の姿勢(以前のSwitchエミュレータリポジトリへのDMCA一斉削除については当サイトのまとめを参照)を考慮すると、このプロジェクトの法的な露出面はエミュレータとは異なりますが、プレイヤーは手を動かす前に、自分がどの線上に立っているのかを理解しておくべきです。
十二、紫星の判断#
最後に、私の見方を三つ挙げます。
- これはAppleチップの立ち位置への間接的な裏付けです。 「エミュレーションを行わず、直接ネイティブで動かす」というルートが成立する前提は、ターゲットチップが十分に強力で、かつ本体と同型であることです。このプロジェクトの存在そのものが、A17 ProとMシリーズチップの演算能力に関する一つの成績表なのです。
- 要件の線引きが非常に誠実です。 A17 Pro、M1、iOS/iPadOS 26。一つとして線は緩められていません。「約NSPの2倍 + 10 GB」というストレージ要件も率直に書かれています。技術プロジェクトが制限を明確に語ることは、将来性を誇示することよりも信頼に値します。
- 次のステージを見るなら、まず『ゼルダの伝説 ティアーズ オブ ザ キングダム』を見るべきです。 ティアーズ オブ ザ キングダムは現時点でオープニングの洞窟までしか到達しておらず、フレームレート問題も未解決です。この最難関ケースの進捗速度こそが、プロジェクト全体の天井を示すプログレスバーです。私はリポジトリのゲームごとの説明ページの更新を注視し続けます。
ハンドヘルドとモバイルゲームのエコシステムに関心のある読者は、当サイトの以前のSteam Deck ゲーム対応リスト 2026も併せてご覧ください。同じゲーム群について、「エミュレーション互換」と「ネイティブトランスレーション」という二つのルートの体験の境界が、ますます明確になりつつあります。
——紫星、NTGame ハードウェア編集部