さとまたwiki

Linuxのフォルダ構成

Linuxのディレクトリ構造を理解して、ファイル操作をマスターしよう

Linuxのディレクトリ構造

🐧 + 📁

Linuxでは全てが「/」(ルート)から始まる階層構造になっています。Windowsのように「C:」「D:」というドライブ文字は使いません。

WindowsとLinuxの違い

Windows

C:\Users\username\Desktop

Linux

/home/username/Desktop

パス区切りが \(バックスラッシュ)ではなく /(スラッシュ)です。

ルートディレクトリ(/)の構成

Linuxのディレクトリ構造

主要なディレクトリとその役割

text
/                       ← ルートディレクトリ(全ての起点)
├── bin/                ← 基本コマンド(ls, cp, mvなど)
├── boot/               ← 起動に必要なファイル
├── dev/                ← デバイスファイル(ハードウェア)
├── etc/                ← システム設定ファイル(重要!)
├── home/               ← ユーザーのホームディレクトリ(重要!)
│   └── username/       ← あなたのファイルはここ
│       ├── Desktop/
│       ├── Documents/
│       ├── Downloads/
│       └── .config/    ← アプリの設定(隠しフォルダ)
├── lib/                ← 共有ライブラリ
├── media/              ← USBやCDなどの自動マウント先
├── mnt/                ← 手動マウント用
├── opt/                ← 追加ソフトウェア
├── proc/               ← プロセス情報(仮想ファイルシステム)
├── root/               ← rootユーザーのホーム
├── sbin/               ← システム管理コマンド
├── srv/                ← サーバー用データ
├── sys/                ← システム情報(仮想ファイルシステム)
├── tmp/                ← 一時ファイル(再起動で消える)
├── usr/                ← ユーザー用プログラム
│   ├── bin/            ← ユーザーコマンド
│   ├── lib/            ← ライブラリ
│   ├── local/          ← 手動インストールしたソフト
│   └── share/          ← 共有データ
└── var/                ← 変動データ(ログなど)
    └── log/            ← システムログ
プレビュー
# よく使うディレクトリ
/home/username/
あなたのファイル
/etc/
設定ファイル
/var/log/
ログファイル

開発者が知っておくべきディレクトリ

📁 /home/username/ - ホームディレクトリ

あなたの全てのファイルが置かれる場所。Windowsの C:\Users\username に相当。

  • ~$HOME で参照可能
  • プロジェクトは通常ここに作成
  • .で始まるファイルは隠しファイル

⚙️ /etc/ - システム設定

システム全体の設定ファイルが置かれる場所。

  • /etc/hosts - ホスト名解決
  • /etc/nginx/ - Nginx設定
  • /etc/ssh/ - SSH設定
  • 編集には通常 sudo が必要

📦 /usr/local/ - 手動インストール先

パッケージマネージャを使わずに手動でインストールしたソフトウェアの場所。

  • /usr/local/bin/ - 実行ファイル
  • /usr/local/lib/ - ライブラリ
  • Node.jsのグローバルパッケージもここに入ることがある

📝 /var/ - 変動データ

ログファイルやキャッシュなど、変動するデータの場所。

  • /var/log/ - システムログ
  • /var/www/ - Webサーバーのドキュメントルート
  • /var/cache/ - キャッシュファイル

🗑️ /tmp/ - 一時ファイル

一時的なファイルを置く場所。再起動すると消えるので重要なファイルは置かない!

  • 全ユーザーが書き込み可能
  • スクリプトの一時データに便利
  • 自動削除されるので片付け不要

隠しファイルとドットファイル

ホームディレクトリの隠しファイル

.(ドット)で始まるファイルは隠しファイル

bash
# 隠しファイルを含めて表示
ls -la ~

# よくある隠しファイル/フォルダ
/home/username/
├── .bashrc           ← Bashの設定(重要!)
├── .zshrc            ← Zshの設定
├── .profile          ← ログイン時の設定
├── .gitconfig        ← Gitの設定
├── .ssh/SSH鍵(重要!)
│   ├── id_rsa        ← 秘密鍵(絶対に公開しない!)
│   ├── id_rsa.pub    ← 公開鍵
│   └── known_hosts   ← 接続したことのあるホスト
├── .config/          ← アプリの設定
│   ├── Code/VS Codeの設定
│   └── nvim/         ← Neovimの設定
├── .local/           ← ユーザーローカルデータ
│   └── bin/          ← ユーザーの実行ファイル
├── .npm/             ← npmのキャッシュ
├── .nvm/             ← Node Version Manager
└── .cache/           ← キャッシュデータ
プレビュー
# 隠しファイルを見る
ls -la
drwxr-xr-x .config
drwx------ .ssh
-rw-r--r-- .bashrc

重要なドットファイル

.bashrc:ターミナル起動時に読み込まれる設定。環境変数やエイリアスを定義。

.ssh/:SSH鍵の保管場所。権限を正しく設定しないと動かない。

.gitconfig:Gitのユーザー名やメールアドレスを設定。

パスの操作

パスの表記方法

絶対パスと相対パス

bash
# 絶対パス(/から始まる完全なパス)
cd /home/username/projects/my-app

# 相対パス(現在地からの相対位置)
cd projects/my-app      # 現在地から「projects/my-app」へ
cd ..                   # 一つ上のディレクトリへ
cd ../..                # 二つ上のディレクトリへ
cd ./src                # 現在地の「src」フォルダへ(./は省略可能)

# 特殊なパス表記
cd ~                    # ホームディレクトリへ(/home/username)
cd ~/projects           # ホームのprojectsフォルダへ
cd -                    # 直前にいたディレクトリへ戻る

# 現在地を確認
pwd                     # /home/username/projects/my-app
プレビュー
$ pwd
/home/username/projects
$ cd my-app
$ pwd
/home/username/projects/my-app

パス記号の意味

/:ルートまたはパス区切り

~:ホームディレクトリ

.:現在のディレクトリ

..:親ディレクトリ

環境変数

$HOME:ホームディレクトリ

$PWD:現在のディレクトリ

$PATH:コマンド検索パス

$USER:ユーザー名

基本的なファイル操作コマンド

ファイル・ディレクトリ操作

よく使うコマンド

bash
# ディレクトリ操作
mkdir my-folder              # フォルダ作成
mkdir -p a/b/c               # 深い階層を一度に作成
rmdir my-folder              # 空のフォルダを削除

# ファイル操作
touch file.txt               # 空ファイル作成
cp file.txt copy.txt         # コピー
cp -r folder/ backup/        # フォルダをコピー(-r: 再帰的)
mv file.txt newname.txt      # 移動・リネーム
rm file.txt                  # ファイル削除
rm -r folder/                # フォルダ削除(-r: 再帰的)
rm -rf folder/               # 強制削除(確認なし、危険!)

# ファイル内容表示
cat file.txt                 # 全内容を表示
head -n 10 file.txt          # 先頭10行を表示
tail -n 10 file.txt          # 末尾10行を表示
tail -f log.txt              # リアルタイムで末尾を監視
less file.txt                # ページャーで表示(qで終了)

# 検索
find . -name "*.js"          # 現在地以下の.jsファイルを検索
grep "keyword" file.txt      # ファイル内のキーワード検索
grep -r "keyword" ./         # フォルダ内を再帰検索
プレビュー
$ mkdir -p projects/my-app
$ cd projects/my-app
$ touch index.js
$ ls
index.js

危険なコマンドに注意!

rm -rf /:システム全体を削除(絶対に実行しない!)

rm -rfは確認なしで削除されるので、パスを必ず確認してから実行してください。

ファイル権限(パーミッション)

権限の確認と変更

ls -lで権限を確認

bash
# 権限を確認
ls -l
# -rw-r--r-- 1 user group 1234 Jan 1 12:00 file.txt
# drwxr-xr-x 2 user group 4096 Jan 1 12:00 folder/

# 権限の読み方(10文字)
# d rwx r-x r-x
# │ └─┬─┘└─┬─┘└─┬─┘
# │   │    │    └── その他ユーザーの権限
# │   │    └─────── グループの権限
# │   └──────────── 所有者の権限
# └──────────────── d=ディレクトリ, -=ファイル, l=シンボリックリンク

# r=read(読み取り), w=write(書き込み), x=execute(実行)

# 権限を変更
chmod 755 script.sh          # rwxr-xr-x(実行可能にする)
chmod 644 file.txt           # rw-r--r--(一般的なファイル)
chmod +x script.sh           # 実行権限を追加
chmod -w file.txt            # 書き込み権限を削除

# 所有者を変更
chown user:group file.txt    # 所有者とグループを変更
sudo chown root file.txt     # rootに変更(sudo必要)
プレビュー
$ ls -l
-rw-r--r--
user user file.txt
drwxr-xr-x
user user folder/

よく使う権限の数字

755:実行ファイル
644:通常ファイル
700:プライベート
600:SSH鍵など

計算方法:r=4, w=2, x=1 の合計。例:rwx=7, rw-=6, r-x=5, r--=4

LinuxとRust:C言語からの移行

🦀 C

Linux 6.1(2022年12月11日リリース)で、RustがLinuxカーネルの公式言語になりました。C言語、アセンブリに次ぐ3番目の言語です。2025年12月には実験的ステータスからカーネルのコア部分に昇格しました。

🛡️ メモリ安全性 - 脆弱性の70%を防ぐ

MicrosoftとGoogleの調査によると、C/C++での脆弱性の約70%がメモリ安全性の問題です。Rustはこれらをコンパイル時に防ぎます:

  • バッファオーバーフロー:配列の境界外アクセス
  • Use-after-free:解放済みメモリへのアクセス
  • 二重解放(double free):同じメモリを2回解放
  • NULLポインタ参照:無効なポインタへのアクセス

出典:Microsoft Security Response Center (2019)、Google Chromium Security

⚡ 並行処理の安全性

Rustの所有権システムにより、データ競合(data race)をコンパイル時に検出。マルチスレッドプログラミングが安全に。

// Rustでは不正なデータ共有はコンパイルエラー

// C言語では実行時に謎のバグとなる

🚀 ゼロコスト抽象化

高レベルな抽象化を使っても、C言語と同等の実行速度を実現。

  • ガベージコレクションなし(GCによる停止がない)
  • コンパイル時に最適化
  • C言語と同等かそれ以上のパフォーマンス

📦 モダンなツールチェーン

C言語の古いビルドシステムと比べて、開発体験が大幅に向上:

  • Cargo:統一されたビルド・パッケージマネージャ
  • crates.io:公式パッケージレジストリ
  • rustfmt:自動フォーマッタ
  • clippy:リンター

🐧 LinuxでのRust採用状況

  • Linux 6.1(2022年12月):Rustサポート開始、約12,500行のコード
  • Linux 6.8(2024年3月):最初のRustドライバが正式採用
  • 2025年12月:Rustが実験的ステータスからカーネルのコア部分に昇格

🍎 Asahi Linux - 世界初のRust製GPUドライバ

Apple Silicon(M1/M2/M3)用のGPUドライバがRustで実装されました。これはLinux史上初のRust製GPUドライバです。

  • OpenGL 4.6 / OpenGL ES 3.2に完全準拠
  • Vulkanドライバも開発中
  • 一部ベンチマークでmacOSを上回る性能(Xonotic: 800+ FPS vs macOS 600 FPS)
  • DRM(グラフィックスサブシステム)の抽象化で約1,500行のRustコードを追加

「Rustの安全性機能により、設計が自然とスレッドセーフでメモリセーフになる」- Asahi Lina(開発者)

📱 Android - Rustで脆弱性を68%削減

GoogleはAndroidでメモリ安全性の脆弱性を大幅に削減しました:

  • 2019年:脆弱性の76%がメモリ安全性の問題
  • 2024年末:24%まで減少
  • 2025年:初めて20%を下回る
  • Android 12/13:Rustコードからのメモリ脆弱性はゼロ

Android 13ではネイティブコードの21%がRust(UWB、DNS-over-HTTP3、Keystore2など)。2025年にはC++より多くのRustコードが追加されました。

C言語 vs Rust の比較

同じ処理でもRustはより安全

rust
// C言語での危険なコード例
// char *ptr = malloc(10);
// free(ptr);
// printf("%s", ptr);  // Use-after-free!クラッシュ or セキュリティホール

// Rustでは所有権システムにより、上記は不可能
fn main() {
    let data = String::from("Hello");
    let reference = &data;

    // drop(data);  // これはコンパイルエラー!
    // referenceがまだdataを参照しているため

    println!("{}", reference);  // 安全にアクセス
}

// Rustの効果(Google調査結果)
// - ロールバック率がC++の半分以下
// - コードレビュー時間が25%短縮
// - 修正回数がC++より20%少ない
プレビュー
// Rustのコンパイラが守ってくれる
error[E0505]:
cannot move out of 'data'
because it is borrowed

なぜ完全移行ではなく段階的か?

  • Linuxカーネルは3000万行以上のC言語コード
  • 既存のCコードとRustは相互運用可能(FFI)
  • 新規開発やセキュリティクリティカルな部分から順次Rust化
  • C言語の知識は引き続き重要(既存コードの理解・保守)

Project Hayabusa:統一カスタムLinux OS

🦅

Project Hayabusa

隼 - 既存Linuxベースの統一カスタムOS

既存の軽量Linuxをベースに、PC・タブレット・スマホで動く統一UIを構築。 Flutter Embedded Linuxのように、Linuxカーネル + カスタムUIレイヤーで開発効率を最大化。

1 要件定義

要件内容優先度
ターゲットデバイスPC、ノートPC、タブレット、スマートフォン必須
アーキテクチャx86_64(PC)、ARM64(モバイル)必須
起動時間5秒以内(コールドブート)重要
メモリ使用量アイドル時 256MB以下重要
UIフレームワークFlutter / 独自Rust GUI必須
開発方式Claude Code + vibe coding必須

2 アプローチ選定:ゼロから vs フォーク

❌ ゼロからカーネル開発

  • • 開発期間:数年〜10年以上
  • • ドライバ開発が膨大(GPU、WiFi、Bluetooth等)
  • • 1人での完成は現実的でない
  • • Redox OSでも10年で実用レベルに未到達

✅ 既存Linuxベース + カスタムUI

  • • 開発期間:数ヶ月〜1年
  • • 既存ドライバをそのまま活用
  • • Flutter Embedded Linux方式で効率的
  • • 実際にデバイスで動作可能

結論

既存Linuxベース + カスタムUIレイヤーを採用。 カーネル開発の労力をUIと統一体験に集中させる。 Sony の Flutter Embedded Linux と同様のアプローチ。

3 言語選定:RustかCか

なぜ言語選定が重要か

OS開発において言語選定は安全性・パフォーマンス・開発効率の全てに影響する。 特にメモリ安全性は、脆弱性の70%がメモリ関連という事実(Microsoft、Google調査)から極めて重要。

観点C言語Rust
メモリ安全性❌ 手動管理(バグの温床)✅ コンパイル時に保証
パフォーマンス◎ 最速(直接メモリ操作)◎ C同等(ゼロコスト抽象化)
既存資産✅ 50年の蓄積(Linux, ドライバ)△ 発展途上(約10年)
Linuxカーネル主要言語(95%以上)Linux 6.1から公式サポート
学習コスト中(ポインタ理解が必要)高(所有権・ライフタイム)
並行処理❌ データ競合が起きやすい✅ コンパイル時に防止

❌ 全てRustで書く

  • • Linuxカーネル自体はC(書き換え不可能)
  • • 既存ドライバは全てC(再実装は非現実的)
  • • Redox OSが10年かけても完成していない
  • • ハードウェア対応が極めて限定的になる

❌ 全てCで書く

  • • メモリ安全性の問題が常に付きまとう
  • • 脆弱性の70%がメモリ関連
  • • 並行処理のバグが発生しやすい
  • • 現代的な開発体験が得られない

✅ Hayabusaの戦略:ハイブリッドアプローチ

「Cの資産を活かしつつ、新規開発はRustで」

レイヤー言語理由
カーネルC(既存Linux)書き換え不要。安定・実績あり
カーネルモジュールRust可Linux 6.1以降で公式サポート
ユーザーランドツールRustuutils(coreutils互換)を採用
システムデーモンRust新規開発。安全性重視
UIレイヤーDart/RustFlutter or iced/egui
アプリケーションRust/任意開発者の選択に委ねる

なぜ新規開発にRustを選ぶか

1. メモリ安全性

  • • Use-after-free、バッファオーバーフローを防止
  • • コンパイル時に検出(実行時ではない)
  • • CVEの大部分を事前に防げる

2. 並行処理の安全性

  • • データ競合をコンパイル時に検出
  • • 「Fearless Concurrency」
  • • マルチコア時代に必須

3. 現代的なツールチェーン

  • • Cargo(パッケージマネージャ)
  • • 統合テスト・ドキュメント生成
  • • エラーメッセージが親切

4. 業界の採用

  • • Linux カーネル(6.1〜)
  • • Android(一部コンポーネント)
  • • Windows(書き換え進行中)
  • • AWS、Cloudflare、Discord

結論

カーネル=C(Linux)、それ以外=Rustというハイブリッド戦略。 これにより、Linuxの安定性・ハードウェア対応を享受しつつ、 ユーザースペースの安全性と開発効率を最大化する。

出典: Microsoft MSRC - 70% of vulnerabilities are memory safety issues

4 ベースOS選定

候補言語サイズARM対応学習コストカスタマイズ性評価
BuildrootC / Make最小◎ 完全制御推奨
YoctoC / Python小〜中◎ 企業向け複雑
Alpine LinuxC (musl/busybox)130MB代替案
Void LinuxC (xbps)○ musl対応代替案
Tiny CoreC (busybox)16MB特殊用途
Redox OSRust◎ 独自カーネルRust純粋
MaestroRust極小○ Linux互換Rust純粋

各選択肢の詳細解説

Buildroot(推奨)

なぜ推奨か:

  • Makefile + Kconfigベースで構造がシンプル。Linuxカーネルの設定と同じ方式
  • 1つのmake コマンドで完全なルートファイルシステムを生成
  • ドキュメントが充実(公式マニュアル約200ページ、例も豊富)
  • Raspberry Pi、BeagleBone等の実績多数でコミュニティが活発
  • Flutter Embedded Linux(Sony製)との組み合わせ事例あり

学習コスト「中」の理由:

  • Makefileの基礎知識が必要
  • クロスコンパイルの概念理解が必要
  • ただしYoctoに比べると概念が少なく、1〜2週間で基本を習得可能

Yocto(複雑)

なぜ複雑か:

  • 独自のビルドシステム「BitBake」を使用(Pythonベース)
  • 「レイヤー」「レシピ」「クラス」等の独自概念が多い
  • 初回ビルドに数時間〜半日かかる(Buildrootの3〜5倍)
  • ドキュメントは膨大だが、どこから始めるか分かりにくい

学習コスト「高」の理由:

  • 習得に1〜3ヶ月かかることが多い
  • トラブル時のデバッグが難しい(ログが複雑)
  • ただし企業向け長期サポートには最適(LTS、セキュリティ更新)

Alpine Linux(代替案)

なぜ代替案か:

  • 既製のディストリビューションなのですぐ使える
  • musl libc + busyboxで軽量(Docker公式イメージでも採用)
  • apkパッケージマネージャーで簡単にソフト追加可能

推奨しない理由:

  • 「完全カスタム」には向かない(不要なパッケージを削除する作業が発生)
  • ARM64対応はあるがモバイル向けの最適化は自分で行う必要あり
  • アップストリームとの同期を維持するのが面倒

Void Linux(代替案)

特徴:

  • 独自パッケージマネージャーxbps(高速)
  • runit init(systemdより軽量)
  • glibc版とmusl版を選択可能

推奨しない理由:

  • コミュニティが小さく、情報が少ない
  • Alpine同様、完全カスタムには向かない
  • モバイルデバイス向けの事例がほぼない

Tiny Core(特殊用途)

なぜ特殊用途か:

  • 16MBという極小サイズはRAMディスクで完全動作を想定
  • 再起動で全てリセットされる設計(キオスク端末向け)
  • ARM対応が限定的(Raspberry Pi以外はほぼなし)

学習コスト「高」の理由:

  • 独自の拡張機能(TCZ)の仕組みを理解する必要あり
  • 永続化の設定が特殊
  • ドキュメントが少なく、古い情報も多い

Redox OS(Rust純粋)

Rustで書かれている理由:

  • 2015年から開発。「Rustで安全なOSを作る」という目標
  • マイクロカーネル設計でドライバもユーザースペースで動作
  • メモリ安全性をコンパイル時に保証

推奨しない理由:

  • 10年開発しても実用レベルに未到達
  • 対応ハードウェアが極めて限定的(仮想マシンが主)
  • ドライバがほぼない(WiFi、Bluetooth、GPU等)
  • ARM対応は実験的

出典: Redox OS 公式サイト

Maestro(Rust純粋)

特徴:

  • Linux ABI互換を目指す(Linuxバイナリがそのまま動く)
  • モノリシックカーネル設計
  • 2023年から活発に開発中

推奨しない理由:

  • 新興プロジェクトで安定性が未知数
  • x86/x86_64のみ対応(ARM未対応)
  • 実機での動作実績がほぼない
  • 1人開発者のプロジェクト

出典: GitHub - maestro-os

コード量・シンプルさ・Claude Code開発適性の検証

対象コード行数マルチアーキClaude Code適性
Linux Kernel4,000万行◎ 全対応❌ 理解不可能
Yocto (BitBake)6万行(Python)△ 複雑すぎる
Buildroot (コア)約1,000行✅ 最適
Redox OS(カーネル)1.6〜3万行△ 限定的△ Rust学習必要
Maestro OS4.8万行❌ x86のみ△ 1人開発
Minimal Linux Liveシェルスクリプト数百行✅ 教育向け

Claude Code開発適性の判断基準:

✅ 適している条件

  • • コード行数が少ない(1万行以下が理想)
  • • 設定ファイルベース(コード生成不要)
  • • ドキュメントが充実
  • • エラーメッセージが明確
  • • 段階的に構築可能

❌ 適していない条件

  • • 巨大なコードベース
  • • 独自DSL・複雑な抽象化
  • • ドキュメント不足
  • • デバッグが困難
  • • 依存関係が複雑

検証結論:Buildrootが最適

  • 1. コア1,000行:Claude Codeが全体を把握可能
  • 2. Makefile + Kconfig:標準的な形式でAIが理解しやすい
  • 3. 段階的構築:`make menuconfig`で対話的に設定
  • 4. エラーが明確:ビルドエラーの原因特定が容易
  • 5. マルチアーキ:x86_64、ARM64、RISC-V全対応

英語圏コミュニティの動向(2024-2025)

「Vibe Coding」とOS開発

Vibe Codingとは、OpenAI共同創設者のAndrej Karpathyが2025年2月に提唱した概念。 自然言語でAIに指示し、コードを生成させる開発スタイル。

Linus Torvaldsの見解

"Vibe codingは学習や自力で完成できないタスクには良いが、 Linuxカーネルのようなコアシステムには適用すべきでない"

→ カーネル本体はC(既存Linux)を使い、ユーザーランドやUI層でAI開発を活用するアプローチが現実的

出典: The Register - Linus Torvalds: Vibe coding is fine, but not for production

LinuxカーネルメンテナのAI活用

NVIDIAのSasha Levinが開発したAUTOSEL(Rustで書かれたツール):

  • LLMを使ってパッチのバックポートを自動化
  • 複数のLLMを組み合わせてエラーと幻覚を軽減
  • 「非常に退屈で時間のかかる」作業を自動化

出典: The New Stack - How AI Helps Maintain the Linux Kernel

NixOS + LLM開発の動き

  • Nixified.ai:1つのnixコマンドでAIツールをインストール・実行
  • nixos-llm-dev:LLM推論環境のNixOS設定(Ollama + CUDA)
  • 再現可能なビルドでLLM環境を共有可能

「標準的なLinuxツールを使うので、LLMがCLIと出力を理解しやすい」

出典: Quesma Blog - 60-Second Linux Analysis with Nix and LLMs

Hacker News / Redditでの評価

Buildroot

  • • 「新しいパッケージ追加が簡単」
  • • 「Yoctoより結果が同等か上」
  • • 「基本システムが15-30分で完成」
  • • IRC/メーリングリストでサポートあり

Yocto

  • • 「より強力でカスタマイズ可能」
  • • 「学習曲線が非常に急」
  • • 「企業向けには最適」
  • • 初回ビルドに数時間

出典: Hacker News - Buildroot Making Embedded Linux Easy

英語圏コミュニティの結論

  • 1. OS開発でのVibe Codingは実験段階だが試みる人が増加中
  • 2. カーネル本体はAI開発に不向き(Torvaldsも警告)
  • 3. ユーザーランド・UI層はAI開発に適している
  • 4. Buildrootは「シンプル」「簡単」と高評価
  • 5. NixOSは再現性でLLM開発環境に注目
  • 6. 標準的なLinuxツールはLLMが理解しやすい

フレームワーク選定の考え方(SvelteKit的な美しさ)

Webフレームワークに例えると:

Yocto = Next.js

高機能だが複雑。企業向け。設定ファイルが多い。学習曲線が急。

Buildroot = SvelteKit

シンプルで美しい。必要なものだけ。設定が直感的。すぐ動く。

Alpine/Void = Express.js

既存のものを組み合わせる。楽だが自由度に限界。

Buildrootを選ぶ理由:SvelteKitがReactの複雑さを排除したように、 BuildrootはYoctoの過剰な抽象化を排除。make menuconfig 一つで全てが完結する美しさ。

独立運用について(Ubuntuフォーク vs Buildroot)

❌ Ubuntuフォーク方式

  • • 例:Linux Mint, Pop!_OS, elementary OS
  • • Ubuntuのパッケージに依存し続ける
  • • 上流の変更に振り回される(GNOME→Unity→GNOME等)
  • • セキュリティパッチの適用が遅れがち
  • • 独自パッチのメンテナンスコストが高い

✅ Buildroot方式

  • • 依存なし:必要なソースを直接ビルド
  • • 上流から独立:Linuxカーネルのバージョンも自分で選択
  • • セキュリティ:必要な時に必要なパッチを適用
  • • 設定ファイル(defconfig)だけで再現可能
  • • Buildrootの更新は任意(固定も可能)

Hayabusaの独立運用戦略

  • 1. Buildrootをサブモジュールとして固定:特定バージョンにロック
  • 2. Linuxカーネルも固定:LTS(6.6、6.12等)を使用
  • 3. 独自overlay:Hayabusa固有のファイルを分離管理
  • 4. 更新は計画的に:セキュリティ修正のみ取り込み、機能追加は慎重に

結論:Buildroot + Rustユーザーランド

  • ベース:Buildroot(実績・ドキュメント・ARM対応が充実)
  • UIレイヤー:Flutter または Rust GUI(iced, egui等)
  • ユーザーランド:uutils(GNU coreutilsのRust実装)で段階的にRust化
  • 将来:Linuxカーネル自体もRustドライバが増加中(Linux 6.1以降)

出典: Incredibuild - Yocto vs Buildroot

5 アーキテクチャ

Hayabusa OS アーキテクチャ

Buildroot + Flutter/Rust UIレイヤー

text
┌─────────────────────────────────────────────────────────────────┐
│                      Hayabusa UI Layer                          │
│  ┌─────────────────────────────────────────────────────────────┐│
│  │  Flutter App / Rust GUI (統一UI)                            ││
│  │  - ホーム画面、設定、アプリランチャー                        ││
│  │  - タッチ/マウス/キーボード対応                              ││
│  └─────────────────────────────────────────────────────────────┘│
├─────────────────────────────────────────────────────────────────┤
│                    Display Backend                               │
│  ┌──────────────┐  ┌──────────────┐  ┌────────────────────────┐│
│  │   Wayland    │  │   DRM/KMS    │  │   Weston/Sway (opt)    ││
│  └──────────────┘  └──────────────┘  └────────────────────────┘│
├─────────────────────────────────────────────────────────────────┤
│                    Linux Kernel (Buildroot)                      │
│  • デバイスドライバ(既存を活用)                                │
│  • ファイルシステム、ネットワーク、電源管理                      │
├─────────────────────────────────────────────────────────────────┤
│                    Hardware                                      │
│  ┌──────────────┐  ┌──────────────┐  ┌────────────────────────┐│
│  │   x86_64     │  │    ARM64     │  │      RISC-V            ││
│  │  PC/Laptop   │  │ Tablet/Phone │  │      (Future)          ││
│  └──────────────┘  └──────────────┘  └────────────────────────┘│
└─────────────────────────────────────────────────────────────────┘
プレビュー
Flutter/Rust UI
Wayland / DRM
Linux Kernel (Buildroot)
x86_64 | ARM64

6 プロジェクト構造

Hayabusa プロジェクト構造

Buildroot + Flutter UI

text
hayabusa-os/
├── buildroot/                    # Buildrootサブモジュール
│   └── (git submodule)
│
├── configs/                      # Buildroot設定
│   ├── hayabusa_x86_64_defconfig # PC/ノートPC用
│   ├── hayabusa_aarch64_defconfig # タブレット/スマホ用
│   └── hayabusa_rpi4_defconfig   # Raspberry Pi 4用
│
├── overlay/                      # ルートファイルシステムオーバーレイ
│   ├── etc/
│   │   ├── init.d/               # 起動スクリプト
│   │   └── hayabusa/             # 設定ファイル
│   └── usr/
│       └── bin/                  # カスタムバイナリ
│
├── flutter-ui/                   # Flutter UIアプリ
│   ├── lib/
│   │   ├── main.dart             # エントリーポイント
│   │   ├── screens/              # 画面
│   │   └── widgets/              # ウィジェット
│   └── pubspec.yaml
│
├── packages/                     # カスタムパッケージ
│   └── hayabusa-launcher/        # ランチャーアプリ
│
├── scripts/                      # ビルドスクリプト
│   ├── build.sh                  # ビルド実行
│   ├── flash.sh                  # デバイスへ書き込み
│   └── qemu-run.sh               # QEMUで実行
│
└── docs/                         # ドキュメント
    └── INSTALL.md
プレビュー
hayabusa-os/
├── buildroot/
├── configs/
├── flutter-ui/
└── scripts/

7 開発手順

開発環境セットアップ

Buildroot + Flutter Embedded Linux

bash
# 1. 依存関係インストール(Ubuntu/Debian)
sudo apt install build-essential git wget cpio unzip rsync bc \
    libncurses5-dev python3

# 2. Buildrootをクローン
git clone https://github.com/buildroot/buildroot.git
cd buildroot

# 3. 設定(x86_64の例)
make qemu_x86_64_defconfig
make menuconfig  # カスタマイズ

# 4. ビルド(時間がかかる)
make -j$(nproc)

# 5. QEMUで実行
output/host/bin/qemu-system-x86_64 \
    -M pc \
    -kernel output/images/bzImage \
    -drive file=output/images/rootfs.ext2,format=raw \
    -append "root=/dev/sda rw console=ttyS0" \
    -serial stdio

# Flutter Embedded Linuxは別途設定
# https://github.com/sony/flutter-embedded-linux
プレビュー
$ make qemu_x86_64_defconfig
$ make -j$(nproc)
Building...

8 Claude Codeでの開発ガイド

開発フロー概要

1. 環境構築
2. Buildroot設定
3. カーネルビルド
4. UI開発
5. 統合テスト

Phase 0 開発環境の選択:Windows vs Linux

項目Windows (WSL2)Linux ネイティブ
Buildrootビルド○ WSL2経由で可能◎ ネイティブ最速
ビルド速度△ I/Oボトルネック
(Windowsファイルシステム跨ぎで遅い)
◎ 高速
QEMU実行○ WSL2内で動作◎ KVM加速で高速
USB/実機書き込み△ WSLからデバイス認識が困難
(usbipd-win必要)
◎ 直接アクセス可能
Claude Code◎ Windows版フル対応◎ Linux版フル対応
VS Code連携◎ Remote-WSL拡張で快適◎ ネイティブ動作
推奨度学習・検証向け本格開発推奨

Windows + WSL2での開発

メリット:

  • 普段使いのWindows環境を維持したまま開発可能
  • VS Code Remote-WSLで快適なエディタ体験
  • Claude CodeのターミナルからWSL2に直接接続可能

注意点:

  • /mnt/c/(Windowsドライブ)上で作業すると極端に遅い → WSL内(~/)で作業
  • 実機テスト時はusbipd-winでUSBパススルー設定が必要
  • メモリ割り当てを.wslconfigで調整(8GB以上推奨)

Linux ネイティブでの開発(推奨)

メリット:

  • 最速のビルド速度(WSL2比で2〜3倍速いことも)
  • KVM加速でQEMUが高速に動作
  • USB/SDカードへの書き込みが容易
  • Linuxツールチェーンのネイティブ動作

推奨ディストリビューション:

  • Ubuntu 22.04/24.04 - Buildrootの公式テスト環境
  • Fedora - 最新パッケージで開発体験良好
  • Arch Linux - 最新環境が欲しい人向け

結論:おすすめの構成

初心者・学習目的: Windows + WSL2 (Ubuntu 22.04) で十分

本格開発: Linux ネイティブ または デュアルブート

最強構成: メインPC(Windows) + 開発用PC/VM(Linux) の2台体制

※ Claude Codeはどちらの環境でも同じように動作するため、OS選択はビルド環境の都合で決めてOK

Phase 1 環境構築

# Claude Codeへの指示例

プロンプト 1.1: プロジェクト初期化

"Hayabusa OS用のプロジェクトディレクトリを作成して。
hayabusa-os/という名前で、buildroot/をgit submoduleとして追加、
configs/, overlay/, scripts/, flutter-ui/のディレクトリ構造を作って。"

プロンプト 1.2: 依存関係

"Ubuntu 24.04でBuildrootをビルドするための依存パッケージを
インストールするスクリプトを作成して。scripts/install-deps.shに保存。"

Phase 2 Buildroot設定

プロンプト 2.1: defconfig作成

"x86_64向けのBuildroot defconfigを作成して。
要件:
- Linux kernel 6.6 LTS
- musl libc
- BusyBox
- Wayland + weston
- 最小構成(GUI起動まで)
configs/hayabusa_x86_64_defconfigに保存。"

プロンプト 2.2: ARM64対応

"x86_64のdefconfigをベースに、ARM64(aarch64)版を作成して。
Raspberry Pi 4とgeneric ARM64の両方で動くように。
configs/hayabusa_aarch64_defconfigに保存。"

Phase 3 カーネル・システム構築

プロンプト 3.1: ビルドスクリプト

"Buildrootのビルドを実行するスクリプトを作成して。
引数でターゲット(x86_64/aarch64)を指定できるように。
エラーハンドリングとログ出力も追加。scripts/build.shに保存。"

プロンプト 3.2: オーバーレイ設定

"Hayabusa OS用のrootfsオーバーレイを作成して。
含めるもの:
- /etc/hostnameを'hayabusa'に
- 自動ログイン設定
- Waylandセッション自動起動
overlay/ディレクトリに配置。"

プロンプト 3.3: QEMU実行

"ビルドしたイメージをQEMUで実行するスクリプトを作成して。
グラフィック出力あり/なしを選択可能に。
scripts/qemu-run.shに保存。"

Phase 4 UI開発(Flutter / Rust)

プロンプト 4.1: Flutter UIプロジェクト

"Hayabusa OS用のFlutterプロジェクトを作成して。
機能:
- フルスクリーンランチャー
- アプリグリッド表示
- 設定画面(WiFi, Bluetooth, 明るさ)
- ダークモード対応
flutter-ui/に作成。flutter-embedded-linux対応で。"

プロンプト 4.2: Rust代替(iced)

"Flutterの代わりにRust + icedでシンプルなランチャーを作成して。
機能:アプリ一覧表示、クリックで起動、時計表示。
rust-ui/に作成。クロスコンパイル対応で。"

Phase 5 統合・デバッグ

プロンプト 5.1: エラー解決

"Buildrootのビルドで以下のエラーが出た。原因と解決策を教えて:
[エラーメッセージをペースト]"

プロンプト 5.2: パッケージ追加

"Buildrootに新しいパッケージを追加したい。
パッケージ名: uutils-coreutils(Rust製coreutils)
packages/uutils/に必要なファイルを作成して。"

プロンプト 5.3: 実機書き込み

"ビルドしたイメージをUSBメモリに書き込むスクリプトを作成して。
安全のため、確認プロンプトを表示。
scripts/flash-usb.shに保存。"

効果的なプロンプトのコツ

✅ 良いプロンプト

  • 具体的な要件を列挙する
  • 出力先ファイルパスを指定する
  • ターゲットアーキを明示する
  • エラーメッセージは全文貼る
  • 段階的に依頼する(一度に全部やらない)

❌ 避けるべきプロンプト

  • • 「OSを作って」(範囲が広すぎ)
  • • 「動かない」(情報不足)
  • • 「最適化して」(基準が不明)
  • • 複数の無関係なタスクを同時に依頼
  • • コンテキストなしで続きを依頼

Claude Code実行コマンド例

# プロジェクトディレクトリで起動
$ cd hayabusa-os && claude
# 特定のタスクを直接実行
$ claude "scripts/build.sh x86_64 を実行して結果を教えて"
# ファイルを読み込んで分析
$ claude "configs/hayabusa_x86_64_defconfig を分析して改善点を提案して"
# Git操作も可能
$ claude "今日の変更をコミットして。メッセージは内容から自動生成して"

9 ディストロのフォークは必要か?

結論:フォーク不要

Buildrootは「ディストリビューション」ではなく「ビルドシステム」のため:

  • フォーク不要:設定ファイル(defconfig)でカスタマイズ
  • オーバーレイ:独自ファイルを追加可能
  • パッケージ追加:外部パッケージディレクトリで拡張
  • アップストリーム追従:Buildroot本体の更新を簡単に取り込める

Alpine/Voidなどの「ディストリビューション」をフォークすると、アップストリームとの同期が大変。 Buildrootなら設定ファイルの管理だけで済む。

開発プロジェクトの配置

おすすめのプロジェクト配置

ホームディレクトリでの整理方法

text
/home/username/
├── projects/                    ← 開発プロジェクトをまとめる
│   ├── work/                    ← 仕事関連
│   │   ├── client-a/
│   │   └── client-b/
│   ├── personal/                ← 個人プロジェクト
│   │   ├── my-blog/
│   │   └── portfolio/
│   └── learning/                ← 学習用
│       ├── typescript-practice/
│       └── sveltekit-tutorial/
│
├── .local/
│   └── bin/                     ← 自作スクリプトを置く
│
└── .config/                     ← エディタやツールの設定
プレビュー
# プロジェクト作成の例
mkdir -p ~/projects/personal
cd ~/projects/personal
npx sv create my-app

まとめ

  • Linuxは全て/(ルート)から始まる階層構造
  • ホームディレクトリは/home/username/または~
  • パス区切りは/(スラッシュ)
  • .で始まるファイルは隠しファイル
  • 権限(パーミッション)を理解して適切に設定する
  • プロジェクトは~/projects/にまとめると管理しやすい