1. はじめに
「自分の書いたコードだけでハードウェアを動かしてみたい」 「OSの仕組みをブラックボックスのまま終わらせず、自分の手で実装してみたい」
低レイヤープログラミングやOS自作に興味を持つと、誰もが一度は抱く強い憧れです。しかし、いざ自作OSの世界へ足を踏み入れようとしたとき、最初に立ちはだかる最大の壁が**「開発環境の構築」**ではないでしょうか。
ベアメタル（OSなしの生ハードウェア）をターゲットにするため、普段のWeb開発やアプリ開発のように「フレームワークを入れてすぐ実行」とはいきません。クロスコンパイル環境、UEFIファームウェア、エミュレータ、デバッガ……と聞き慣れないツールが並び、コードを1行も書く前に挫折してしまったという声も少なくありません。
そこで本記事では、2026年現在の最新メジャーバージョンをフル活用し、もっともストレスフリーでモダンな自作OS開発環境をゼロから構築します。
土台となるのは、2026年秋に登場した**「WSL 3.0」と長期サポート版の最新OS「Ubuntu 26.04 LTS」。そしてエディタには、Windowsとシームレスに統合できる「Visual Studio Code（VS Code）」**を採用します。
対象読者と本記事のゴール
- 対象読者:
- Windows環境をメインで使いながら、本格的なRust製x86_64自作OSに挑戦したい方
- 仮想マシンソフト（VirtualBoxやVMware）を使わず、WSL上で快適に低レイヤー開発を行いたい方
- 将来的に「自作UEFIブートローダー」と「独自カーネル」の両方を自作したいと考えている方
- 本記事のゴール:
- コードを書き始める直前の**「開発ツールチェーン・エディタ環境」が完全に整った状態**になること
- WSLgによるQEMU 11の画面描画や、VS Code上での
rust-analyzerによる快適なコード補完環境が完成すること
※本記事では「環境構築」に集中するため、OS本体（ブートローダーやカーネル）のソースコード実装は行いません。万全の土台を整えるところまでを丁寧に進めていきます。
2. 開発環境（2026年11月現在）
本記事で構築する開発環境のバージョン一覧です。2026年秋現在の最新メジャーバージョンを採用しています。
| ツール / レイヤー | 採用バージョン | 役割 |
|---|---|---|
| ホストOS | Windows 11 (24H2 / 2026 Update) | 開発PCの母艦環境 |
| WSL | WSL 3.0.x（2026年9月GA） ※WSLg必須 | 最新の仮想化サブシステム（GUIウィンドウ統合が必須） |
| ディストリビューション | Ubuntu 26.04 LTS (Resolute Raccoon) | Linux開発環境本体 |
| エディタ | Visual Studio Code (最新版) | ソースコード編集・デバッグ |
| VS Code拡張機能 | WSL, rust-analyzer, CodeLLDB | リモート開発・言語サーバー |
| 言語ツールチェーン | Rust 1.99.0 / nightly (Edition 2024) | コンパイラ・ビルドツール |
| ターゲット triple | x86_64-unknown-uefix86_64-unknown-none | 自作ブートローダー用 独自カーネル用 |
| 仮想化 / エミュレータ | QEMU 11.1.x (qemu-system-x86_64) | 仮想マシン上でのOS実行 |
| ファームウェア | OVMF (EDK2) | x86_64向けUEFIファームウェア |
| 補助ツール | mtools, dosfstools, gdb, build-essential | FAT32ディスク生成・デバッグ用 |
3. 全体像とツールの役割分担
環境構築に入る前に、各ツールがどのような関係で連携しているのか、全体像を整理しておきましょう。
今回の自作OS開発では、ブートローダーにも既存のものは使わず、「自作UEFIブートローダー」から「ELF64独自カーネル」までをすべてRustで自作する構成を前提としています。
そのため、Rustには以下の2つのターゲットを導入します：
x86_64-unknown-uefi: UEFIファームウェア上で直接動作する実行可能ファイル（.efi）を作るためのターゲット（ブートローダー用）x86_64-unknown-none: OSが存在しない生のマシン上で動作する純粋なELF64バイナリを作るためのベアメタルターゲット（カーネル用）
開発全体のアーキテクチャは以下の図のようになります。
+-----------------------------------------------------------------------+
| Windows 11 (Host) |
| |
| +--------------------+ +--------------------------+ |
| | VS Code (UI) | | QEMU 11 Display (WSLg) | |
| +---------+----------+ +------------+-------------+ |
| | (WSL Remote Connection) | |
|=============|=======================================|=================|
| WSL 3.0 (Ubuntu 26.04 LTS) | |
| v | |
| +--------------------+ | |
| | VS Code Server | | |
| +---------+----------+ | |
| | | |
| v v |
| +--------------------+ Disk Build +------------------+ |
| | Rust (nightly) | --------------------> | QEMU 11 Emulator | |
| | - uefi target | (mtools / FAT32) | + OVMF (UEFI) | |
| | - none target | +------------------+ |
| +--------------------+ |
+-----------------------------------------------------------------------+
エディタの操作や画面表示はWindows 11側で快適に行い、コンパイル、ファイルシステムの組み立て、エミュレータの実行はすべてWSL 3.0のLinux環境側で完結させます。
なぜ自作OS開発において「WSLg」が必須なのか？
本プロジェクトの開発仕様書（Phase 2：画面・文字表示）では、UEFIのGOP（Graphics Output Protocol）からフレームバッファ情報を取得し、ピクセル描画や文字描画、画面コンソールを実装していきます。
そのため、**「OSが描画したグラフィック画面をWindowsデスクトップ上で視覚的に確認できるGUI環境」**が絶対に欠かせません。
従来のWSLでは、別途サードパーティ製のX Serverソフト（VcXsrvなど）を手動導入・設定する必要があり、描画が崩れたり接続設定でつまずく大きな原因になっていました。しかし、WSL 3.0に標準搭載されている「WSLg」を活用すれば、Linux側で起動したQEMUのGUIウィンドウがそのままWindowsネイティブアプリのように自動でポップアップ表示されます。この快適な視覚的フィードバック環境を構築するため、本連載ではWSLgの動作を必須要件として位置づけています。
QEMU と KVM って何が違うの？（初心者のためのやさしい解説）
仮想化の話になると必ずセットで登場する**「QEMU」と「KVM」ですが、最初は違いが分かりにくいと感じるかもしれません。たとえるなら、「QEMUはパソコン全体のパーツ担当」、「KVMは本物の超強力なエンジン」**という関係です。
【QEMU 単体の場合】（すべてを1人でこなすシミュレーター）
QEMUが「CPUの計算」も「画面の表示」も「メモリの読み書き」も
ぜんぶソフトウェアで真似して1人でこなす。
⇒ なんでも動かせるけれど、CPUの計算を1行ずつ翻訳するので【少し遅い】。
【QEMU ＋ KVM の場合】（最強のタッグ結成！）
・CPUの計算 ───> 【KVM】経由で、本物のパソコンのCPUが直接爆速で計算！
・画面やメモリ管理 ───> 【QEMU】が引き続き周辺パーツとして担当。
⇒ 実機とほぼ同じスピードで【爆速】で動く！
- QEMU（キューエミュ）: マザーボード、メモリ、キーボード、グラフィックカードなど、パソコン丸ごとのパーツをソフトウェア上で本物そっくりに作り出すツールです。
- KVM（Kernel-based Virtual Machine）: あなたのPCのCPU（Intel CoreやAMD Ryzen）が持っている「仮想化専用機能（VT-x / AMD-V）」を、Linuxカーネル経由で直接仮想マシンに使わせる仕組みです。
最初はQEMU単体でも十分軽快に動きますが、OS開発が進んでタイマー割り込みやマルチタスクなどの複雑な処理をテストするようになると、KVM（-enable-kvm）をONにして本物のCPUパワーで爆速実行する場面が出てきます。そのため、最初からKVMをいつでも使えるように設定しておくのがおすすめです。
4. WSL 3.0 ＆ Ubuntu 26.04 LTS のセットアップ
まずは開発の土台となるWSL 3.0とUbuntu 26.04 LTSを準備します。
Step 1: WSLを最新のバージョン3系へアップデートする
管理者権限でPowerShell（またはWindows Terminal）を開き、WSLを最新バージョンへ更新します。
💻 実行場所: Windows (PowerShell)
# WSLを最新版に更新
wsl --update
# バージョンを確認
wsl --version
実行結果に以下のように表示され、WSL本体が 3.0.x 以上であること、そして**「WSLg バージョン」の項目が確実に表示されていること**を確認してください。
>wsl --version
WSL バージョン: 3.0.5.0
カーネル バージョン: 6.18.58.1-1
WSLg バージョン: 1.0.79
MSRDC バージョン: 1.2.7391
Direct3D バージョン: 1.611.1-81528511
DXCore バージョン: 10.0.26100.1-240331-1435.ge-release
Windows バージョン: 10.0.26300.9818
[!IMPORTANT] 自作OSの画面描画を行うために、
WSLg バージョンの表示が必須です。もしWSLgの行が表示されない場合は、Windows 11が最新の状態に更新されているか確認し、グラフィックドライバ（GPUドライバ）を最新版に更新した上で、再度wsl --updateを実行してください。
[!NOTE] もし社内ネットワークやプロキシ環境で
wsl --updateが失敗する場合は、Microsoft公式のWSL GitHubリポジトリ（Releasesページ）から最新の.msiインストーラーを直接ダウンロードしてインストールすることも可能です。
Step 2: Ubuntu 26.04 LTS のインストール
続いて、最新の長期サポート版であるUbuntu 26.04 LTSを導入します。
💻 実行場所: Windows (PowerShell)
# 利用可能なディストリビューションの一覧を確認
wsl --list --online
# Ubuntu 26.04 をインストール（未導入の場合）
wsl --install -d Ubuntu-26.04
インストールが完了すると初期ユーザー名とパスワードの設定が求められるので、任意のものを設定してください。
すでに既存のUbuntu環境がある場合は、WSLターミナルに入り、以下のコマンドでOSバージョンを確認できます。
🐧 実行場所: Ubuntu (WSLターミナル)
lsb_release -a
Step 3: 必須パッケージのインストール
Ubuntu 26.04のシェルに入り、自作OS開発に必要なツール群を一括でインストールします。
（推奨）aptの取得先を国内の高速ミラーサーバーに変更する
Ubuntuの初期状態では海外のメインサーバーを参照している場合があり、パッケージのダウンロードに時間がかかったり接続が不安定になったりすることがあります。日本国内の高速ミラーサーバー（理研: RIKEN など）に切り替えておくと、今後のパッケージ取得が格段にスムーズになります。
Ubuntu 26.04ではリポジトリ設定が deb822 形式（/etc/apt/sources.list.d/ubuntu.sources）になっているため、バックアップを取りつつ以下のワンライナーで置換できます：
🐧 実行場所: Ubuntu (WSLターミナル)
# 設定ファイルのバックアップを作成
sudo cp /etc/apt/sources.list.d/ubuntu.sources /etc/apt/sources.list.d/ubuntu.sources.bak
# 国内ミラー（理研）へURLを一括置換
sudo sed -i -E 's#(https?://)(archive|security)\.ubuntu\.com/ubuntu/?#\1ftp.riken.jp/Linux/ubuntu/#g' /etc/apt/sources.list.d/ubuntu.sources
[!TIP] JAIST（北陸先端科学技術大学院大学）のミラーを利用したい場合は、置換先を
\1ftp.jaist.ac.jp/pub/Linux/ubuntu/に指定してください。
パッケージリストの更新と必須ツールの導入
ミラーの設定が完了したら、パッケージリストを最新化したうえでツール群を導入します。
🐧 実行場所: Ubuntu (WSLターミナル)
# パッケージリストの更新とアップグレード
sudo apt update && sudo apt upgrade -y
# 必須ツールのインストール
sudo apt install -y \
build-essential \
curl \
git \
qemu-system-x86 \
ovmf \
mtools \
dosfstools \
gdb
各ツールの役割は以下の通りです：
build-essential: Cコンパイラ（gcc）やmakeなど、基本的なビルド環境qemu-system-x86: x86_64マシンをエミュレートするQEMU本体（最新のQEMU 11系）ovmf: x86_64用のUEFIファームウェアバイナリ（EDK2）mtools/dosfstools: root権限（sudo）なしでFAT32のディスクイメージ（EFIシステムパーティション）を作成・操作するためのユーティリティgdb: カーネルのデバッグを行うGNUデバッガ
Step 4: ユーザー権限とグループ設定（パーミッション事故の防止）
Ubuntu環境の初期セットアップにおいて、ユーザーとグループの扱いには2点だけ大切なポイントがあります。
1. root ユーザーで開発作業をしないこと
WSLをデフォルトの root ユーザーのまま使ったり、sudo cargo build のようにビルドを実行してしまうと、生成されたファイル（target/ 配下や生成イメージ）の所有者がすべて root:root になってしまいます。
その結果、「VS Codeで編集して保存しようとすると Permission denied（権限エラー）になる」「rust-analyzer がキャッシュを読めずに構文エラーを出す」 といった典型的なパーミッション問題に直面します。
日常の開発やビルド作業は、必ずUbuntuセットアップ時に作成した一般ユーザーで行ってください。本記事でディスク生成に mtools を採用しているのも、一般ユーザー権限のまま sudo なしで安全にFAT32イメージを生成できるようにするためです。
2. 将来のQEMU高速化を見越して kvm グループに追加しておく（特急レーンの通行証）
第3章で解説した通り、QEMUに本物のCPUパワーを使わせるアクセル機能が「KVM」です。
Linuxでは、この本物のCPUへアクセスするための専用ドアとして /dev/kvm という特別なファイルが用意されています。
[ あなたの書いた自作OS ]
│
▼
[ QEMU ]
│ 「CPUの計算は本物に任せたい！」
▼
[/dev/kvm] ─── (鍵がかかっている！)
│
▼
[ 本物のCPU ]
セキュリティ上の理由から、この /dev/kvm のドアにはカギがかかっており、「kvm グループに所属しているユーザー」しか通ることができません。
もし一般ユーザーが kvm グループに入っていないまま高速化オプション（-enable-kvm）を付けてQEMUを動かそうとすると、
Could not access KVM kernel module: Permission denied（KVMへのアクセス権限がありません）
というエラーで怒られてしまいます。このトラブルを未然に防ぐために、あらかじめ自分自身に「通行証（グループ権限）」を渡しておきましょう：
🐧 実行場所: Ubuntu (WSLターミナル)
# 現在のユーザーを kvm グループに追加
sudo usermod -aG kvm $USER
# 所属グループの確認（一旦WSLターミナルを再起動すると反映されます）
groups
実行後、groups コマンドの結果に kvm が含まれていれば設定完了です。これで、将来KVMによる高速化を使いたくなった際にも、パーミッションエラーでつまずく心配が一切なくなります。
5. Rustツールチェーンと自作OS用ターゲットの導入
自作OS開発では、まだ安定版（stable）に入っていないコンパイラフラグや、特殊なターゲットライブラリの再ビルド機能（build-std）を頻繁に利用します。そのため、nightly ツールチェーンを使用します。
Step 1: rustup のインストール
公式インストーラを使ってRustを導入します。WSLのターミナルで実行してください。 rustのインストールで、選択肢が出ますが、default で問題ないので、そのまま Enter でかまいません。
🐧 実行場所: Ubuntu (WSLターミナル)
# rustupのインストール（デフォルトの1を選択して進める）
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
# 現在のシェルに環境変数を反映（即時反映）
source "$HOME/.cargo/env"
# バージョン確認
rustc --version
cargo --version
[!NOTE]
source "$HOME/.cargo/env"は、ターミナルを一度閉じて開き直す手間を省き、「いま開いているそのターミナルセッションですぐにcargoやrustcを使えるようにするため（即時反映）」 に実行しています。インストーラがシェルの設定ファイル（~/.bashrc等）に自動追記してくれるため、次回以降ターミナルを新しく起動した際は手動で実行する必要はありません。
Step 2: nightly ツールチェーンの設定
自作OS開発では必須となるnightlyを導入し、デフォルトに設定します。
🐧 実行場所: Ubuntu (WSLターミナル)
# nightlyツールチェーンのインストール
rustup toolchain install nightly
# デフォルトをnightlyに切り替え
rustup default nightly
Step 3: デュアルターゲットの追加
仕様書で定めた「自作UEFIブートローダー」と「ベアメタルカーネル」のために、2つのターゲットを追加します。
🐧 実行場所: Ubuntu (WSLターミナル)
# 1. 自作UEFIブートローダー向けターゲット
rustup target add x86_64-unknown-uefi
# 2. ベアメタルカーネル向けターゲット
rustup target add x86_64-unknown-none
Step 4: 必須コンポーネントの追加
カーネルをコンパイルする際、標準ライブラリ（std）が存在しない環境で core や alloc をソースからビルドするために rust-src が必要になります。また、オブジェクトファイルの解析に役立つLLVMツール群も一緒に追加しておきます。
🐧 実行場所: Ubuntu (WSLターミナル)
# core / alloc 再コンパイル用のソースコード
rustup component add rust-src
# LLVMツール群（llvm-objdump, llvm-nm など）
rustup component add llvm-tools-preview
これで、コンパイラ側の準備は完璧です！
6. VS Code のセットアップと自作OS向け設定
次に、Windows側からWSL内のコードをシームレスに編集・デバッグできるように、VS Code環境を整えます。
Step 1: Windows側にVS CodeとWSL拡張機能を導入
まだVS Codeをインストールしていない場合は、Windows側にインストールしておきます。
その後、VS Codeの「拡張機能」タブ（Ctrl + Shift + X）を開き、以下の拡張機能をインストールします。
WSL（識別子:ms-vscode-remote.remote-wsl/ Microsoft公式）
Step 2: WSL環境をVS Codeで開く
WSLターミナルで開発用ディレクトリを作成し、code . と入力すると、Windows側のVS CodeがWSLに接続した状態で立ち上がります。
🐧 実行場所: Ubuntu (WSLターミナル)
# 開発用ワークスペースの作成
mkdir -p ~/workspace/aogane-os
cd ~/workspace/aogane-os
# VS Codeを起動（初回はVS Code Serverが自動ダウンロードされます）
code .
VS Codeの左下（ステータスバー）に WSL: Ubuntu-26.04 と表示されていれば、リモート接続成功です。
Step 3: WSL環境へ必須拡張機能をインストール
VS Code内で、WSL環境側に以下の拡張機能をインストールします（拡張機能タブを開くと「WSL: UBUNTU-26.04 にインストール」というボタンが表示されます）。
rust-analyzer(rust-lang.rust-analyzer): Rustの高度なコード補完・型推論・エラー検知CodeLLDB(vadimcn.vscode-lldb): QEMUと接続したブレークポイントデバッグEven Better TOML(tamasfe.even-better-toml):Cargo.tomlのシンタックスハイライト・バリデーション
Step 4: 自作OS特有の rust-analyzer 設定（超重要！）
普通のRust開発と自作OS開発の最大の違いは、**「ターゲットが通常のホストOS（x86_64-unknown-linux-gnu）ではない」**という点です。
何も設定しないと、rust-analyzer が標準ライブラリ（std）を探そうとして赤い波線（エラー）を大量に出したり、補完が効かなくなったりします。
これを防ぐため、プロジェクトルートに .vscode/settings.json を作成し、特殊ターゲットと build-std に対応した設定を記述しておきます。
🐧 実行場所: Ubuntu (WSLターミナル)
mkdir -p .vscode
作成した .vscode/settings.json に以下の設定を記述します：
{
// 保存時の自動チェックに cargo check を使用
"rust-analyzer.check.command": "check",
// すべてのターゲット・クレートを解析対象にする
"rust-analyzer.check.allTargets": false,
// デフォルトのターゲットをカーネル向けに設定（またはブートローダー向け）
"rust-analyzer.cargo.target": "x86_64-unknown-none",
// coreクレート等のソースコードを補完対象に含める
"rust-analyzer.cargo.sysrootSrc": "discover",
// build-std を使用する場合に標準ライブラリの未解決エラーを防ぐ
"rust-analyzer.cargo.cfgs": [
"target_os=none"
],
// 編集体験の向上
"editor.formatOnSave": true,
"editor.inlayHints.enabled": "on"
}
この設定を入れておくことで、後から no_std のベアメタルコードを書いても、VS Code上でスムーズかつ正確な型補完・シンタックスチェックが機能するようになります。
7. 開発ツールの疎通確認とトラブルシューティング
すべてのツールが正しく動作するか、最終チェックを行いましょう。
疎通チェックリスト
WSLのターミナルで以下のコマンドを順に実行し、パスが通り正常に応答するか確認します。
🐧 実行場所: Ubuntu (WSLターミナル)
# 1. Rustコンパイラとターゲットの確認
rustc --version
rustup target list | grep installed
# 2. QEMUのバージョン確認（QEMU 11系であることを確認）
qemu-system-x86_64 --version
# 3. OVMF（UEFIファームウェア）の存在確認（Ubuntu 26.04では4M版が標準）
ls -l /usr/share/OVMF/OVMF_CODE_4M.fd
# 4. ディスク作成ツールの確認
mformat -V
QEMUのGUI起動テスト（WSLgの動作確認・必須）
本連載の自作OS開発では、自作した画面表示やグラフィックコンソールを直接目で見て確認するため、「WSLg（Windows Subsystem for Linux GUI）によるGUIウィンドウの表示」を必須要件としています。
WSL 3.0では、特別なX Serverソフト（VcXsrv等）を別途用意しなくても、WSLgの標準機能によってLinux側のGUIウィンドウがWindowsデスクトップ上に直接ポップアップします。
以下のコマンドを実行して、QEMUがWSLg経由で正しくウィンドウを表示できるかテストしてみましょう。 （※近年のUbuntuに同梱されている4MB版OVMFはサイズ制限があるため、従来の -bios ではなく -drive if=pflash を指定してフラッシュメモリとして読み込みます）
🐧 実行場所: Ubuntu (WSLターミナル)
qemu-system-x86_64 -drive if=pflash,format=raw,readonly=on,file=/usr/share/OVMF/OVMF_CODE_4M.fd
コマンドを実行すると、Windows上に黒い画面のQEMUウィンドウが開き、「TianoCore」のロゴやUEFI Interactive Shellが立ち上がれば成功です！
確認できたら、QEMUウィンドウの「×」ボタンで、閉じて終了してください。
よくあるトラブルと対処法
実際に環境を構築する中でハマりやすいポイントと、その解決策をまとめました。
トラブル1: QEMUを実行してもウィンドウが開かない / エラーが出る
- 原因: WSLgが有効になっていないか、グラフィックドライバが古い可能性があります。
- 対処法:
- Windows側で最新のGPUドライバ（NVIDIA / AMD / Intel）を適用してください。
- PowerShellで
wsl --updateを再実行し、WSL 3.0のコンポーネントがすべて最新になっているか確認してください。 - WSL内で
echo $DISPLAYを実行し、:0などの値が入っているか確認してください。
トラブル2: could not load PC BIOS エラーが出る / OVMFが見つからない
- 原因:
qemu: could not load PC BIOS ...とエラーが出る場合、-biosオプションに4MB版のファームウェア（OVMF_CODE_4M.fd）を指定していることが原因です。-biosにはROM容量制限（通常2MB程度）があるため、4MB規格のイメージは-drive if=pflash,...で指定する必要があります。- ファイル自体が見つからない場合は、
ovmfパッケージが未インストールであるか、ディストリビューションのバージョンによって配置パスが異なる場合があります（古いUbuntu環境ではOVMF_CODE.fdや/usr/share/ovmf/OVMF.fdの場合があります）。
- 対処法:
- 起動オプションを
-biosではなく-drive if=pflash,format=raw,readonly=on,file=/usr/share/OVMF/OVMF_CODE_4M.fdに変更してください。 - ファイルが見つからない場合は、以下のコマンドでWSL内の配置場所を検索してください：🐧 実行場所: Ubuntu (WSLターミナル)
dpkg -L ovmf | grep -i "\.fd"もし教材や既存スクリプトとの互換性などの理由で/usr/share/OVMF/OVMF_CODE.fdという名前で扱いたい場合は、シンボリックリンクを作成すると便利です：🐧 実行場所: Ubuntu (WSLターミナル)sudo ln -s /usr/share/OVMF/OVMF_CODE_4M.fd /usr/share/OVMF/OVMF_CODE.fd
- 起動オプションを
トラブル3: VS Codeで「GLIBCXXが見つからない」などのエラーが出る
- 原因: Ubuntu 26.04が最新すぎるため、古い拡張機能のバイナリとlibcの互換性問題が稀に発生することがあります。
- 対処法: 拡張機能を最新バージョンにアップデートするか、VS Code本体を最新リリース（2026年秋以降のビルド）に更新してください。
8. まとめと振り返り
お疲れ様でした！これで、Rustによるx86_64自作OS開発をスタートするためのすべての土台が完成しました。
今回構築した環境をチェックリストとして振り返っておきましょう。
- [x] WSL 3.0 ＆ Ubuntu 26.04 LTS: 最新の仮想化環境とLinux OSが動作している
- [x] ユーザー権限: 一般ユーザー環境でセットアップされ、
kvmグループへの追加も完了している - [x] Rust (nightly):
x86_64-unknown-uefiとx86_64-unknown-noneのデュアルターゲットが導入済み - [x] コンパイラソース:
build-stdに必要なrust-srcが揃っている - [x] QEMU 11 ＆ OVMF: WSLg経由でUEFIファームウェアのGUIウィンドウ起動が確認できている（必須要件）
- [x] VS Code: WSLリモート接続と、自作OS向けの
rust-analyzer設定が完了している
数年前までは、Windows上で自作OSを開発しようとすると「VirtualBoxを入れて、共有フォルダの設定をして、VcXsrvでX11を転送して……」と非常に手間がかかり、それだけで丸一日が潰れてしまうことも珍しくありませんでした。
しかし今や、WSL 3.0 と WSLg、そしてVS Codeのリモート開発機能のおかげで、Windowsの快適なデスクトップ体験をそのまま活かしながら、ネイティブLinuxと変わらない速度と柔軟性でOS開発を行える時代になりました。
次回への展望
万全の開発環境が整いました。次回はいよいよ、この環境を使って**「自作UEFIブートローダー」の第一歩（Phase 0のコード実装）**に入っていきます！
Cargo Workspaceを構成し、UEFI画面に文字を出力してQEMU上で動かす手順をステップバイステップで解説していきますので、ぜひお楽しみに！
コメント