yuzu - finm137.wiki【9/12更新】

概要

yuzuは、Nintendo Switchの動作をPCなどの別ハードウェア上で再現することを目的として開発されていた、オープンソースのNintendo Switchエミュレーターである。

ニンテンドー3DSエミュレーター「Citra」の開発者らによって開発され、主にC++で実装されていた。WindowsやLinuxなどに対応し、ソースコードはGPLライセンスの下で公開されていた。初期の公式READMEでも「experimental open-source emulator for the Nintendo Switch」と説明されている。 (GitHub)

開発が進むにつれて多数の市販Nintendo Switchタイトルが動作するようになり、OpenGLやVulkanによるGPUレンダリング、高解像度化、シェーダーキャッシュ、コントローラー入力、セーブデータ、MODなど多数の機能に対応していた。

しかし2024年2月、Nintendo of Americaが開発元Tropic Haze LLCを米国で提訴した。

同年3月にはTropic Haze側が任天堂との和解に合意し、240万ドルを支払うとともにyuzuの開発・配布を終了した。 (Ars Technica)

エミュレーターとは

エミュレーターとは、あるハードウェアやソフトウェア環境の挙動を、異なるハードウェア上で再現するプログラムである。

yuzuの場合は、

• Nintendo SwitchのCPU
• GPU
• メモリ
• ファイルシステム
• OSサービス
• 入力装置
• オーディオ
• Nintendo Switch特有の各種API

などの動作をPC上で再現する。

単純に「Switchの画面をPCへ転送する」ソフトではなく、Switch用ソフトが要求する処理をPC側で解釈・変換して実行する。

どのようにNintendo Switchをエミュレーションするのか

yuzuは複数のエミュレーション用サブシステムを組み合わせてSwitch環境を再現している。

大まかには、

Switch用ゲーム
↓
ゲームデータ・実行ファイルの読み込み
↓
CPU命令の変換
↓
OS・システムサービスの再現
↓
GPU命令・シェーダーの変換
↓
PC側のCPU・GPU・入力・音声へ出力

という流れになる。

CPUエミュレーション

Nintendo SwitchにはARM系CPUが搭載されている。

一方、一般的なWindows PCではx86-64系CPUが広く使用されているため、そのままSwitch用ARM命令を実行できない。

yuzuでは主にDynarmicと呼ばれる動的リコンパイラが使用された。

DynarmicはARM命令を読み取り、それをホストPCで実行可能な命令へ動的に変換するJIT（Just-In-Time）方式のリコンパイラである。Dynarmic自身も「Fast dynamic binary translation via Just-in-Time compilation」を特徴としている。 (GitHub)

概念的には、

ARM64命令
↓
命令を解析
↓
中間表現へ変換
↓
最適化
↓
x86-64などのホストCPU命令へ変換
↓
PCで実行

という処理となる。

一度変換したコードはコードキャッシュへ保存することで、毎回すべての命令を解釈するより高速に実行できる。

yuzuの開発報告でもDynarmicのコードキャッシュやx64命令への変換について説明されている。 (yuzu)

JIT

JITとは「Just-In-Time compilation」の略。

ゲームを起動する前にSwitch用コードをすべて変換するのではなく、実行中に必要になったコードを順番に変換する方式である。

これにより、

• 必要なコードだけ変換できる
• 変換済みコードをキャッシュできる
• CPU固有の最適化が可能
• 単純な逐次命令解釈より高速化できる

といった利点がある。

GPUエミュレーション

Switch用ゲームはNVIDIA Tegra X1を前提として描画命令を発行する。

PC側ではこれをそのまま使用できないため、yuzuのGPUエミュレーション層がゲーム側の描画処理を解析し、PC側で利用可能なグラフィックスAPIへ変換する。

yuzuは主として、

• OpenGL
• Vulkan

に対応していた。

特にVulkan対応は、Windows環境のAMD GPUなどでOpenGLドライバー性能が問題となっていたことを背景として開発された。yuzu開発チーム自身も、AMD環境での性能改善をVulkan実装の大きな目的として説明している。 (yuzu)

シェーダー

ゲーム内の光、影、材質、エフェクトなどには「シェーダー」と呼ばれるGPU用プログラムが利用される。

Switch用シェーダーとPC用GPU APIでは仕様が異なるため、yuzu側で変換処理が必要になる。

ゲーム中に初めて登場したシェーダーをその場で変換すると一時的な処理落ちが発生することがある。

そのためyuzuでは変換結果をキャッシュし、再利用する仕組みが改良されていた。

2023年の開発報告では、Vulkanのパイプラインキャッシュをyuzu側で独自に保存する改善についても説明されている。 (yuzu)

ファイルシステム

Nintendo Switchにはゲーム本体、更新データ、DLC、セーブデータなどを管理する独自のファイルシステム構造が存在する。

yuzuはSwitch内部のNANDやSDカードに相当する仮想ディレクトリをPC上に作り、Switchに近いファイル配置を再現する。

旧yuzu Wikiではユーザーディレクトリ内に、

• config
• nand
• sdmc

などが存在すると説明されていた。 (GitHub)

OS・サービスの再現

Nintendo Switch用ゲームはCPUやGPUだけを直接操作しているわけではない。

ゲームはOS側に、

• ファイルを開く
• メモリを確保する
• コントローラー情報を取得する
• 音を再生する
• 画面を表示する
• 時間を取得する

といった処理を要求する。

yuzuはこれらSwitch OSのサービスの挙動を再実装し、ゲームから見るとSwitch上で動いているように見える環境を構築する。

このためyuzuは単なるCPUエミュレーターではなく、CPU・GPU・メモリ・ファイルシステム・OSサービスなどから構成される大型ソフトウェアである。

MODとの関係

yuzuはNintendo SwitchゲームのMOD利用との相性が良く、エミュレーター側からMODを適用できる仕組みを備えていた。

主として、

• RomFS系MOD
• ExeFS系MOD
• IPS系パッチ
• pchtxt系パッチ

などが利用された。 (DeepWiki)

RomFS MOD

RomFSはゲームが使用するデータファイルを格納する領域。

ここを上書きするタイプのMODでは、

• テクスチャ
• モデル
• 音声
• ゲーム内データ
• UI
• 各種設定ファイル

などを変更できる。

yuzuでは元のゲームファイルそのものを書き換えず、MOD側のファイルを優先的に読み込ませるLayeredFS方式が利用可能だった。 (DeepWiki)

概念としては、

ゲームが data/example.bin を要求
↓
MOD側に同名ファイルが存在するか確認
↓
存在する
↓
MOD版を読み込む
↓
存在しない
↓
元ゲームのファイルを読み込む

という仕組みである。

この方式ではゲーム本体を直接改変しないため、MODの有効・無効を比較的簡単に切り替えられる。

ExeFS MOD

ExeFSはゲームの実行コードなどに関係する領域。

ExeFS系MODではプログラムコードの一部を変更することができ、

• FPS上限変更
• 解像度関連変更
• 描画処理変更
• ゲームロジック調整
• 特定処理の無効化

などに利用されることがある。

過去にyuzuが公開していたMOD一覧にも、60FPS化、解像度固定、アウトライン除去などのMODが登録されていた。 (GitHub)

60FPS MOD

Switch用ゲームには30FPSを前提として作られている作品が多い。

MODによってゲームのFPS制限や時間処理を書き換え、60FPS以上で動作させる例が存在する。

ただしゲームによっては、

• ゲーム速度が倍になる
• 物理演算がおかしくなる
• アニメーション速度が変化する
• イベントの同期が崩れる

こともある。

実際、旧yuzu MODデータベースでも一部の60FPS MODについて「60FPSではゲーム速度が倍になる」などの注意が記載されていた。 (GitHub)

MODフォルダ

yuzuではゲームごとにMOD用ディレクトリを持つことができ、

MOD名/
├─ romfs/
└─ exefs/

のような構造で管理されていた。

旧公式FAQでも、

「mod name/romfs」
「mod name/exefs」

という構造が案内されていた。 (yuzu)

ゲーム本体を直接改造するのではなく、yuzuが起動時にMODファイルを重ね合わせる方式である。

MOD制作との相性

PC上で動作するため、

• ファイル差し替え
• テクスチャMOD
• 高解像度化
• フレームレート変更
• デバッグ
• パッチの有効・無効切り替え

などが比較的行いやすく、SwitchゲームのMOD研究でも使用されていた。

一方でゲームのアップデートによって実行コードやデータ配置が変化すると、古いMODが動作しなくなる場合がある。

そのため特にExeFS系パッチではゲームのバージョンごとに対応MODが分かれていることが多い。旧yuzu MOD一覧でも対応バージョンが個別に指定されていた。 (GitHub)

任天堂との訴訟

提訴
2024年2月26日、Nintendo of Americaは米ロードアイランド州連邦地方裁判所において、yuzuの開発元Tropic Haze LLC**を提訴した。

任天堂側は主に、

• DMCAの技術的保護手段回避規定
• コピー防止技術の回避
• 著作権侵害の助長
• 海賊版利用への寄与

などを問題とした。 (Scribd)

なぜ任天堂ともめたのか

重要なのは「エミュレーターだから即違法」という単純な事件ではないことである。

過去の米国判例では、互換環境を構築するためのリバースエンジニアリングやエミュレーターそのものが直ちに違法になるとは限らない。

yuzuの場合、任天堂が強く問題視したのはSwitchゲームの暗号化を解除して実行する仕組みだった。

Nintendo Switchの市販ゲームには暗号化が施されている。

yuzu本体にはNintendo Switch固有の復号鍵は含まれていなかったものの、ゲーム実行にはユーザー側が用意する暗号鍵が必要だった。

任天堂は、yuzuがそれらの鍵を利用してゲームを実行時に復号することが、DMCAで禁止された技術的保護手段の回避に当たると主張した。 (Ars Technica)

prod.keys問題

yuzu本体にはSwitchの「prod.keys」そのものは収録されていなかった。

ユーザー側が別途用意する設計だった。

この点は任天堂側の訴状でも認識されている。 (Ars Technica)

しかし任天堂側は、

「鍵を同梱していないから問題ない」

とは考えず、yuzuがその鍵を利用して暗号化されたNintendo Switchソフトを復号し実行する機能自体を問題視した。

Quickstart Guide

任天堂は、yuzu公式サイトに存在したQuickstart Guideについても問題視した。

同ガイドではSwitch本体から必要なデータを取得し、yuzuで市販ゲームを動作させるための手順が説明されていた。

任天堂側は、こうした説明や関連ツールへの案内も、保護技術回避を支援している証拠の一つとして主張した。 (Ars Technica)

ゼルダの伝説 ティアーズ オブ ザ キングダム

訴訟では『ゼルダの伝説 ティアーズ オブ ザ キングダム』の発売前流出も大きく取り上げられた。

任天堂側は、発売前の同作がインターネット上で100万回以上ダウンロードされたと主張。

さらに同時期にyuzuのPatreon有料会員が数千人規模で増加したとして、yuzuと海賊版利用との関係を訴状で指摘した。 (Ars Technica)

ただし「海賊版がyuzu開発者によって配布された」という意味ではなく、任天堂側が海賊版利用を容易にした・助長したと主張したものである。

和解と開発終了

提訴から約1週間後の2024年3月、Tropic Hazeと任天堂は和解案に合意した。

Tropic Hazeは任天堂へ240万ドルを支払うことに同意した。 (Ars Technica)

また恒久的差止命令により、Tropic Haze側にはyuzuについて、

• 公開
• 提供
• 宣伝
• 販売
• テスト
• ホスティング
• 配布
• ソースコードや機能の提供

などを行わないことが求められた。 (Ars Technica)

これを受けてyuzu公式プロジェクトは終了した。

Citraへの影響
同じ開発者らが関係していたNintendo 3DSエミュレーターCitra**についても公式開発・サポートが同時期に終了した。 (Soylent News)

エミュレーターそのものは違法なのか

yuzu事件を

「任天堂が裁判でエミュレーターそのものを違法と認定させた」

と説明するのは正確ではない。

この事件は本格的な判決まで争われず、両者が早期に同意判決・和解へ進んだ。

そのため、

「Nintendo Switchエミュレーターはすべて違法である」

という一般的な司法判断が示された事件ではない。

一方、yuzuについては、暗号化されたSwitchソフトを実行するための復号処理や技術的保護手段の回避が中心的な争点となり、最終的にTropic Haze側が任天堂に有利な同意判決を受け入れた。 (Ars Technica)

オープンソースとその後

yuzuは長期間オープンソースで公開されていたため、公式プロジェクト終了時点ですでに多数のソースコードのコピーや派生版が存在した。

公式終了後にはyuzuを基にした複数の派生プロジェクトも登場した。

任天堂はその後もSwitchの復号・エミュレーションに関連するプロジェクトに対してDMCA申立てなどを行っている。 (Ars Technica)

技術的意義

yuzuはNintendo Switchエミュレーターとしてだけではなく、

• ARM64動的リコンパイル
• GPU API変換
• Vulkan
• シェーダーコンパイル
• 仮想ファイルシステム
• OSサービス再実装
• LayeredFS
• JIT
• マルチコアエミュレーション

など、多数の低レイヤー技術を組み合わせた大規模なオープンソースプロジェクトでもあった。

特にDynarmicによるARM命令の動的変換や、VulkanによるSwitch GPU処理の再現、LayeredFS方式によるMOD適用などは、エミュレーター内部構造を学ぶ題材としても興味深い。

MODとエミュレーションの違い

MODとエミュレーターは同じものではない。

エミュレーター
Switch本体のハードウェア・OS環境そのものを別の機械上で再現する。

MOD
ゲームのデータやプログラムの一部を変更する。

yuzuではこの2つを組み合わせることができ、

Switchゲーム
↓
yuzuによるハードウェア・OS再現
↓
LayeredFS等でMODを重ねる
↓
PC上で変更されたゲームとして実行

という構成が可能だった。

関連項目

• Nintendo Switch
• 任天堂
• エミュレーター
• Citra
• Ryujinx
• Vulkan
• OpenGL
• ARM
• JIT
• Dynarmic
• MOD
• LayeredFS
• ROM Hack
• DMCA
• 著作権