はじめに
先日、Open Developers Conference 2026 で、NetBSD コミュニティの蛯原さんのお話をうかがう機会がありました。（👉 セミナー動画）
そのセッションでは、ジャンク品の Wii U に NetBSD を入れたものでプレゼンされていたのですが、その姿があまりにかっこよく、「これはぜひ私もやってみたい…！」となりました。
Wii U は持っていませんが、家には長いこと眠っていた Wii が。調べてみると Wii も NetBSD の対応機種だったため、実際に NetBSD を入れて起動してみました。
導入手順についてはすでに多くの情報があり、初挑戦の私でもすんなり進められたため、この記事では詳しく扱いません。代わりに、実際に動かしてみて気になった 「なぜ Wii で NetBSD が動くのか？」 を整理してみます。
任意コードはどうやって実行されるのか。NetBSD はどうやって Wii の CPU やメモリ、デバイスを扱うのか。そして、そもそもゲーム機と PC は何が違うのか。
Wii で NetBSD を動かした体験を入口に、「ゲーム機というコンピュータ」について低レイヤー初心者の目線から考えてみます。
※ 概念理解を主目的としているため、厳密には異なる部分もあるかもしれません。技術的に誤った説明がありましたら、ご指摘いただけますと幸いです。
なぜ Wii では好きなプログラムをそのまま実行できないのか？
Wii の中には CPU も RAM もあります。でもそのままでは、パソコンと同じように好きなアプリをインストールしたり動かしたりすることはできません。
でもなぜ、任意のプログラムを SD カードに置くだけでは実行できないのでしょうか。
CPU 自体が、「これは任天堂が書いたプログラム」「これは野良プログラム」と区別しているわけではありません。CPU から見れば、どちらもただの命令列です。
違うのは、その命令列が CPU に渡されるまでの経路です。
Wii では、メーカーが想定したソフトウェアだけを実行できるよう、プログラムを起動するまでの経路が制御されています。
そのため、自作プログラムを動かすためには、まず メーカーが想定した実行経路の外から、自分のコードへ実行制御を移す手段 が必要になります。
言い換えると、最初に必要なのは「NetBSDを入れる方法」ではなく、任意コードを実行できる状態を作ることです。
Wii では、この任意コード実行を可能にするための手法がいくつも知られており、その中には入力データを処理する際の脆弱性を利用するものもあります。
これらはすでに広く知られた公開情報ですが、本記事の目的は exploit の具体的な手順を解説することではないため、詳細には踏み込みません。
気になる方は「Wii Homebrew」「Wii exploit」などを手掛かりに調べてみてください。
Homebrew とは
ここでいう Homebrew は、パッケージマネージャーとして広く知られている Homebrew とは無関係で、メーカー非公式の自作ソフトウェア全般の総称です。
上の章で述べたような方法で CPU に任意コードを実行させられたとしても、毎回同じ方法で入口を作るのは大変です。そこで登場するのが Homebrew Channel です。
Wii で遊んだことがある方ならイメージしやすいと思いますが、Homebrew Channel を導入すると Wii メニュー上にひとつのチャンネルとして表示され、そこから Homebrew を簡単に起動できるようになります。
（実際の Wii メニュー画面。左下が Homebrew Channelです。時代を感じさせる桃鉄がちょっと恥ずかしい…）
Homebrew Channel は、SD カードや USB ストレージ上に置かれた自作プログラムを見つけ、「どれを起動するか」を選ばせてくれるランチャーです。
普通はここから、ゲームやツールなどの Homebrew アプリケーションを起動します。
今回の NetBSD も、見た目上は同じように Homebrew Channel の一覧から選んで起動します。
ここで、ひとつ疑問が出てきました。
Homebrew Channel から起動するものの多くは、ゲームやツールなどのアプリケーションです。では、CPU やメモリを管理する側である NetBSD のような OS も、同じように Homebrew Channel から起動できるのでしょうか。
Homebrew Channel から NetBSD へ、どうやって切り替わる？
最初、Homebrew Channel から NetBSD 用のローダーを起動し、そのローダーが別に存在する NetBSD カーネルを読み込むのだと思っていました。
ところが、実際の Wii 用 NetBSD イメージを見てみると少し違います。
Homebrew Channel が起動する apps/netbsd/boot.elf は、NetBSD を起動するためだけの別プログラムではありません。
boot.elf 自体が NetBSD カーネルです。
つまり、起動の流れはざっくりこうなります。
Homebrew Channel
↓
boot.elf をメモリへロード
↓
エントリポイントへ制御を渡す
↓
NetBSD kernel が CPU・メモリ・割り込みなどを初期化
↓
NetBSD userland
ここで面白いのは、NetBSD を起動するために Wii の電源を入れ直しているわけではない ことです。
Wii メニューから Homebrew Channel を起動し、そこから boot.elf へ制御を渡すことで、いま動いているソフトウェア環境から、そのまま NetBSD カーネルへ選手交代しています。
Homebrew Channel から見れば boot.elf は起動可能なプログラムのひとつですが、制御を受け取ったあとの NetBSD は、普通のアプリケーションとして Homebrew Channel の中で動き続けるわけではありません。
NetBSD 自身が必要な初期化を行い、CPU やメモリ、各種デバイスを管理する OS として動き始めます。
つまり、Homebrew Channel は NetBSD カーネルに制御を渡す入口 になっているわけです。
しかし、NetBSD のコードを CPU に実行させることができても、それだけで OS として動けるわけではありません。
OSとして動くには、Wii のハードウェアを知らなければならない
自分のコードを実行できることと、NetBSD のような OS が動くことは別問題です。
OS が動くには、CPU の命令セットに対応しているだけでも足りません。
メモリ、割り込み、タイマー、USB、SD カード、映像出力、電源管理などなど、その機械固有のハードウェアを OS が理解する必要があります。
Wii の CPU は PowerPC 系
PowerPC とは、CPU の命令セットアーキテクチャのひとつです。
普段使っている PC では x86-64、スマートフォンでは ARM がよく使われていますが、Wii では PowerPC 系の CPU が使われています。
CPU は、どんな命令を理解できるかがアーキテクチャごとに異なります。そのため、同じプログラムでも x86-64 向けに作られたものを、そのまま PowerPC で実行することはできません。
今回の Wii では、NetBSD から CPU を確認すると次のように表示されました。
hw.model = 750 (rev 0x7200)
Wii の CPU は PowerPC 750 系統の CPU として NetBSD から認識されています。
このため、Wii で NetBSD を動かすには、まず PowerPC という CPU アーキテクチャに対応している必要があります。
ただし、PowerPC に対応しているだけではまだ足りません。
同じ PowerPC CPU を使っていても、メモリ配置や割り込み、USB、SD カードなど、CPU の周囲にあるハードウェアは機種ごとに異なるためです。
そこで次に出てくるのが evbppc です。
NetBSD が動くために必要な「OS 移植」
NetBSD を動かすには、CPU アーキテクチャへの対応だけでなく、その機械固有のハードウェアを扱うためのコードも必要です。
NetBSD には、PowerPC 系 port が複数ありますが、Wii は evbppc port の対応機種のひとつで、Wii / Wii U 固有の対応コードが含まれています。
evbppc とは、「PowerPC CPUを載せた組み込み機器・評価ボード類をNetBSDで動かすための port（移植先プラットフォーム）」の名前です。
つまり、概念としてはざっくりこういったレイヤーに分かれています。
※ 実際のソースコードのディレクトリ構造や継承関係を表したものではありません
NetBSD共通
↓
powerpc ← PowerPC CPU まわりの共通部分
↓
evbppc ← PowerPC 系の組み込み機器を扱う共通部分
↓
Nintendo (Wii / Wii U) 向けコード ← Wii / Wii U のハードウェアに依存する部分
実際に起動した NetBSD から、
hw.ncpu = 1
hw.physmem64 = 92274688
※92274688 bytes は約 88 MiB です。
と、CPU 数や物理メモリ量を確認することができました。
つまり「PowerPCの命令を実行できる」だけではなく、「Wiiというこの機械がどれだけの物理メモリを持っているのか」をNetBSDが理解できている必要があります。
NetBSD には Wii 向けのマシン依存コードやデバイスドライバが含まれており、それらによって Wii のメモリ構成や各種ハードウェアを認識・制御できるようになっています。
shutdown -p now で Wii 自身の電源が切れる…！
個人的にいちばん感動したのがこれでした。
NetBSD の root シェルから、shutdown -p now を実行すると、Wii メニューに戻ることなく、そのまま Wii 本体の電源が切れました。
「OS がハードウェアを管理している」という教科書の言葉が、実感を伴って見えてきました。
ゲーム機と PC の境界って、結局なに？
最初、Wii に NetBSD を入れて「ゲーム機をパソコンにすること」だと思っていました。
でも、Wii は最初からコンピュータです。
メーカーがゲーム機という用途に向けてハードウェアとソフトウェアを設計し、実行できるコードも制御されているコンピュータ、と定義できるかもしれません。
では、ファミコンやスーパーファミコンはどうなのでしょう。
PC と共通する要素を多く持つ現代のゲーム機とは、何が違うのでしょうか。
ひとつの見方として、違いは 「どこまで汎用的に作られているか」 にあるのかなと思いました。
ファミコンやスーパーファミコンのような古いゲーム機では、ゲームそのものがハードウェアをかなり直接操作します。汎用 OS を載せて、複数の用途に使うことはそもそもあまり想定されていません。
ただし、ハードウェアが PC に近いからといって、自由に使えるとは限りません。現代のゲーム機では、むしろ「どのコードを実行してよいか」が厳しく制御されています。
つまり、「ゲーム機」と「PC」はまったく別のものというより、同じコンピュータを、どの用途に向けて、どこまで汎用的に使えるよう設計しているかの違いと考えると、今回の Wii の体験が少し腑に落ちました。
Wii に NetBSD を入れて「ゲーム機をパソコンに変えた」のではなく、もともとコンピュータだった Wii を、ゲーム以外の用途にも使えるようにした、のほうが正確かもしれません。
おわりに
記事の最初に「なぜ Wii で NetBSD が動くのか？」と書きました。
その答えはとても単純なのかもしれません。
「誰かが Wii で NetBSD を動かしたかったから」 なのかなと思います。
もちろん、その背景には NetBSD の移植性を重視した美しい設計があります。けれど、その設計を実際の Wii までつなげるには、ハードウェアを調べ、コードを書き、ドライバを実装し、動くところまで持っていく人が必要です。
NetBSD の代名詞ともいえる “Of course it runs NetBSD” という言葉は、NetBSD の技術的な強さだけではなく、そうしたコミュニティの執念まで含んだ言葉なのかもしれない、と今回の体験を通して感じました。
また、蛯原さんのご説明の中で「自分の気に入っているハードウェアを、ソフトウェアのサポートが切れたことなどを理由に使用をやめたくない。自分の意思で使い続けたい」といった旨の発言をされていたのがとても印象的でした。
NetBSD コミュニティの方々の目には、ジャンク品がきっと宝の山に映っているんだろうなと思うととても羨ましいです。私ももっと「技術で遊べる」ようになるためには研鑽しないといけないと襟を正す思いでございます。
おわりに の おわりに
ちなみに、蛯原さんはセッション冒頭で「SDカードは A2がいい。これが今日一番言いたいこと」とおっしゃっていました。
そのときは意味も分からぬままメモしていたのですが、実際に自分で試してみると、最初の microSD では BootMii が正常に起動せず、別の SD カードに替えたらあっさり動く、という「相性問題」に遭遇しました。
今回私が遭遇した BootMii の SD カード相性問題が、A2 推奨と同じ理由によるものかは分かりませんが、「規格上使える」と「実機でちゃんと動く」は別なんだな、と妙なところで実感しました。
追記（2026/10/13）
コメントでご質問いただいたので補足します。
最終的に使用したSDカードもA2ではありませんでした。また、最初のSDカードも仕様上は問題なさそうだったため、BootMiiが起動しなかった原因は結局不明のままです。
まさに「スペック上は問題なさそうなのに実機では動かない」あるあるですね...