はじめに
Nintendo 64の名作『スーパーマリオ64』をNintendo 3DS向けに有志が移植した話題のプロジェクトが、「Super Mario 64 3DS Port Ultimate(スーパーマリオ64 3DS ポート アルティメット)」です。
本プロジェクトは、3DSの下画面タッチインターフェース、カメラ操作の拡張、立体3D表示、各種ゲームプレイ拡張要素などを備えており、3DSのハードウェア特性に合わせて非常に丁寧に作り込まれています。また、日本版ROM(VERSION=jp)のビルドにも対応しており、日本語テキストでプレイ可能なCIAファイルを生成できます。
今回は、この「スーパーマリオ64 3DS ポート アルティメット」を、Synology NASのContainer Manager(Docker環境)上でビルドする方法を詳しく解説します。
今回のビルド環境における最大のポイントは、単にGitHubからツール類をダウンロードして使うのではなく、bannertoolとmakeromをDockerコンテナ内でソースコードからコンパイルする点です。これにより、Linux環境で頻発するGLIBCのバージョン不整合(互換性エラー)を根本から回避し、安定したビルド環境を構築します。
「スーパーマリオ64 3DS ポート アルティメット」の概要

「Super Mario 64 3DS Port Ultimate / スーパーマリオ64 3DS ポート アルティメット」は、Epic0522氏によって公開・管理されている3DS向けの移植プロジェクトです。
主な特徴と機能
公式READMEによると、以下のような3DS固有の拡張機能が実装されています。
- 下画面インターフェース:タッチ操作でミニメニューを開き、各種設定の変更が可能。

- 拡張されたカメラ・操作系:Xボタンでカメラ切り替え、Yボタンで視点リセット、C-Stick(New 3DS)による自由なカメラ操作に対応。
- グラフィック&物理設定:Dynamic Shadow(動的影)やラグドール(物理演算)関連のパラメータ調整機能。
- 立体3D表示対応:3DS本体の立体視機能に対応。
動作推奨環境とフレームレートの目安
本ポートは、処理能力の高いNew Nintendo 3DSでのプレイが推奨されています。
- New Nintendo 3DS:拡張エフェクト有効時で 40~60 FPS 程度
- Old Nintendo 3DS:400px軽量設定時で 25~30 FPS 程度
※上記数値は公式READMEに記載されている目安であり、ゲーム内の場面や設定によって変動します。
ビルドに必要な環境と事前準備
今回の作業で手元に用意する環境・ファイルは以下の通りです。
動作環境
- Synology NAS(Container Managerが動作するモデル)
- Container Manager(DSM上のDocker管理パッケージ)
- カスタムファームウェア(CFW)導入済みの3DS本体(New 3DS推奨)
※3DSへのCFW導入方法については、こちらの記事をご参照ください。
対応するROMファイルについて
ビルドには元となる『スーパーマリオ64』のN64 ROMファイルが必要です。公式READMEで対応しているROMファイル名は以下の通りです。
baserom.us.z64(北米版)baserom.eu.z64(欧州版)baserom.jp.z64(日本版)baserom.sh.z64(振動パック対応版)
今回は日本版のCIAファイルを生成するため、吸い出したbaserom.jp.z64を使用します。
※著作権法に基づき、ROMファイルはご自身が所有する実機から吸い出したものをご用意ください。プロジェクト側からは配布されていません。
Synology NAS上のディレクトリ構造
Synology NASのdocker共有フォルダ内に、作業用ディレクトリを作成します。
今回は以下の構成を作成します。
/docker/sm64-3ds/
├── docker-compose.yml
├── Dockerfile
└── source/
└── baserom.jp.z64

ポイント:sourceフォルダの役割
後述する docker-compose.yml で、ホスト(NAS)側の ./source フォルダをコンテナ内部の /sm64 へボリュームマウントします。
また、/sm64/Makefile が存在しない(初回起動時)場合は、コンテナ起動時にGitHubから自動的にソースコードをクローンするスクリプトを組み込んでいます。
Dockerfileの作成(GLIBCエラー回避の仕組み)
以下の内容で /docker/sm64-3ds/Dockerfile を作成します。
FROM devkitpro/devkitarm:latest
# 1. 依存パッケージおよびビルドツールの導入
RUN apt-get update && apt-get install -y \
git \
build-essential \
python3 \
libaudiofile-dev \
pkg-config \
bsdextrautils \
bsdmainutils \
cmake \
g++ \
libmbedtls-dev \
&& rm -rf /var/lib/apt/lists/*
# 2. 3DS開発基本パッケージの導入
RUN dkp-pacman -Syu --noconfirm 3ds-dev
# 3. bannertool を自動コンパイルして配置
RUN git clone --recursive https://github.com/carstene1ns/3ds-bannertool.git /tmp/bannertool && \
cd /tmp/bannertool && \
cmake -B build -DCMAKE_BUILD_TYPE=Release && \
cmake --build build -j$(nproc) && \
cp build/bannertool /usr/local/bin/bannertool && \
rm -rf /tmp/bannertool
# 4. makerom を自動コンパイルして配置
RUN git clone --recursive https://github.com/3DSGuy/Project_CTR.git /tmp/Project_CTR && \
cd /tmp/Project_CTR/makerom && \
make deps && \
make && \
cp bin/makerom /usr/local/bin/makerom && \
rm -rf /tmp/Project_CTR
WORKDIR /sm64
なぜ bannertool と makerom をソースからビルドするのか?
ここが今回の技術的アプローチにおける最も重要なポイントです。
通常、CIAファイルのビルドには3DS用アイコン・バナーを生成するbannertoolと、CIA形式にパッケージングするmakeromが必要です。これらはGitHub Releases等で事前ビルド済みのバイナリ(Linux用)が配布されています。
しかし、配布されているLinux用バイナリを実行しようとすると、コンテナのベースOSとの間で次のようなエラーが発生することがあります。
GLIBC_2.39 not found
これは、バイナリが要求するC標準ライブラリ(GLIBC)のバージョンが、実行環境(コンテナ内)のGLIBCバージョンよりも新しい場合に発生する不整合です。実際にbannertoolの公式リリースノートにも「GNU/Linux向けバイナリはglibc 2.39以上が必要」と明記されています。
そこで本手順では、以下のプロセスを採用しています。
- ベースとなるDockerコンテナ(
devkitarm)を起動 - コンテナ内のGLIBC環境下で、
bannertoolとmakeromのソースコードを取得 - コンテナ内で直接コンパイルして実行バイナリを生成
- 同一コンテナ内でマリオ64本体のビルドを実行
このアプローチにより、実行環境とツールのライブラリ依存関係が100%合致するため、GLIBC不整合エラーを完全に防ぐことができます。
docker-compose.ymlの作成
続いて、以下の内容で /docker/sm64-3ds/docker-compose.yml を作成します。
version: '3.8'
services:
sm64-3ds:
build: .
container_name: sm64-3ds-builder
network_mode: bridge
volumes:
- ./source:/sm64
tty: true
stdin_open: true
command: >
bash -c "
if [ ! -f /sm64/Makefile ]; then
echo '=== SM64 ソースコードを自動クローン中... ===';
git clone https://github.com/Epic0522/Super-Mario-64-3ds-port---Ultimate.git /tmp/sm64-repo &&
cp -r /tmp/sm64-repo/. /sm64/ &&
rm -rf /tmp/sm64-repo;
fi &&
if [ ! -f /sm64/baserom.jp.z64 ]; then
echo '===================================================';
echo 'エラー: baserom.jp.z64 が見つかりません!';
echo '/docker/sm64-3ds/source/ に ROM ファイルを配置してください。';
echo '===================================================';
exit 1;
fi &&
echo '=== CIAのビルドを開始します... ===' &&
make VERSION=jp cia -j$$(nproc) &&
echo '=== ビルドが正常に完了しました! ==='
"
コマンドとオプションの解説
- ソースコードの自動取得:
/sm64/Makefileの有無を判定し、存在しない場合は自動的にGitHubリポジトリをクローンして/sourceフォルダ(ホスト側)に展開します。 - ROMファイルの存在チェック:
/sm64/baserom.jp.z64が配置されているかを事前確認します。ROMがないまま無駄なコンパイル処理が走るのを防ぎます。 make VERSION=jp ciaの意味:VERSION=jp: 日本版指定オプション。Makefile内でVERSION_JP定義が有効化され、日本語テキストデータが読み込まれます。cia: 生成ターゲットにCIA形式を指定します。内部でmakeromが呼び出され、最終的なインストール用ファイルが構築されます。
-j$$(nproc)(マルチスレッド並列処理):$(nproc)でNASのCPUコア数を取得し、並列コンパイルを行うことでビルド時間を大幅に短縮します。なお、docker-compose.yml内で環境変数として誤認識されるのを防ぐため、$$と2重エスケープを施しています。
Container Managerでのプロジェクト作成とビルド実行
ファイル準備が整ったら、Synology NASのGUI(DSM)から操作を行います。
① プロジェクトの作成手順
- DSM上で Container Manager を開きます。
- 左メニューから 「プロジェクト」 を選択し、「作成」 をクリックします。
- 以下の各項目を設定します:
- プロジェクト名:
sm64-3ds(任意の分かりやすい名称) - パス:
/docker/sm64-3ds
- プロジェクト名:
- 既存の
docker-compose.ymlを使用するか訊かれるので、そのまま「OK」をクリックします。
- 全般設定画面が表示されたら内容を確認して「次へ」をクリックします。

- Webポータル設定は不要なためそのまま「次へ」をクリックします。

- 設定サマリーを確認し、「完了」 をクリックします。

② ビルドの開始とログ確認
プロジェクトの作成完了と同時に、コンテナのビルドおよびコマンド実行が自動開始されます。
初回実行時は以下の工程が順次行われるため、NASのスペックによっては数分~十数分程度時間がかかります。
- Dockerイメージのビルド(依存ライブラリのインストール)
bannertoolおよびmakeromのソースコンパイル- ソースコードの自動クローン
- アセット(テクスチャ・サウンド・テキスト)の展開とマリオ64本体のコンパイル
- CIAファイルのパッケージング
ログ画面の最後に以下のメッセージが出力されれば、ビルド成功です!
=== ビルドが正常に完了しました! ===

生成されたCIAファイルの確認とインストール
ビルド完了後、NASのファイルステーションから以下のパスを確認します。
/docker/sm64-3ds/source/build/jp_3ds/sm64.jp.aev64u6.cia
sm64.jp.aev64u6.cia が正しく出力されていれば完成です。
3DS本体への導入
- 生成された
.ciaファイルをSDカードにコピーします。 - Custom Firmware(Luma3DS等)導入済みの3DSを起動し、FBI(インストーラー)を立ち上げます。
- SDカード内の
.ciaファイルを選択し、「Install and delete CIA」 を実行します。 - ホーム画面にプレゼント箱が表示されればインストール完了です!

おわりに
今回は、Synology NASの「Container Manager」を活用して、『スーパーマリオ64 3DS ポート アルティメット』の日本版CIAファイルをビルドする方法をご紹介しました。
本手順の最大の強みは、開発ツール(bannertool / makerom)からゲーム本体に至るまで、全てのコンパイル工程を同一のDockerコンテナ内で完結させている点にあります。これにより、Linux環境特有のGLIBC依存関係エラーをスマートに回避できます。
Synology NASをお持ちの方は、単なるデータストレージとしてだけでなく、こうしたレトロゲームの移植プロジェクトやホームブリューのビルドサーバーとして活用してみるのも大変面白い試みかと思います。
今回構築したDocker環境のノウハウは、他の3DS向けポートプロジェクトをビルドする際にも広く応用できますので、ぜひチャレンジしてみてください!

コメント