Linuxのフォルダ構成
Linuxのディレクトリ構造を理解して、ファイル操作をマスターしよう
Linuxのディレクトリ構造
Linuxでは全てが「/」(ルート)から始まる階層構造になっています。Windowsのように「C:」「D:」というドライブ文字は使いません。
WindowsとLinuxの違い
Windows
C:\Users\username\DesktopLinux
/home/username/Desktopパス区切りが \(バックスラッシュ)ではなく /(スラッシュ)です。
ルートディレクトリ(/)の構成
Linuxのディレクトリ構造
主要なディレクトリとその役割
/ ← ルートディレクトリ(全ての起点)
├── 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/ - ホームディレクトリ
あなたの全てのファイルが置かれる場所。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/ - 一時ファイル
一時的なファイルを置く場所。再起動すると消えるので重要なファイルは置かない!
- 全ユーザーが書き込み可能
- スクリプトの一時データに便利
- 自動削除されるので片付け不要
隠しファイルとドットファイル
ホームディレクトリの隠しファイル
.(ドット)で始まるファイルは隠しファイル
# 隠しファイルを含めて表示
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/ ← キャッシュデータ重要なドットファイル
.bashrc:ターミナル起動時に読み込まれる設定。環境変数やエイリアスを定義。
.ssh/:SSH鍵の保管場所。権限を正しく設定しないと動かない。
.gitconfig:Gitのユーザー名やメールアドレスを設定。
パスの操作
パスの表記方法
絶対パスと相対パス
# 絶対パス(/から始まる完全なパス)
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パス記号の意味
/:ルートまたはパス区切り
~:ホームディレクトリ
.:現在のディレクトリ
..:親ディレクトリ
環境変数
$HOME:ホームディレクトリ
$PWD:現在のディレクトリ
$PATH:コマンド検索パス
$USER:ユーザー名
基本的なファイル操作コマンド
ファイル・ディレクトリ操作
よく使うコマンド
# ディレクトリ操作
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" ./ # フォルダ内を再帰検索危険なコマンドに注意!
rm -rf /:システム全体を削除(絶対に実行しない!)
rm -rfは確認なしで削除されるので、パスを必ず確認してから実行してください。
ファイル権限(パーミッション)
権限の確認と変更
ls -lで権限を確認
# 権限を確認
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必要)よく使う権限の数字
755:実行ファイル644:通常ファイル700:プライベート600:SSH鍵など計算方法:r=4, w=2, x=1 の合計。例:rwx=7, rw-=6, r-x=5, r--=4
LinuxとRust: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はより安全
// 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%少ないなぜ完全移行ではなく段階的か?
- Linuxカーネルは3000万行以上のC言語コード
- 既存のCコードとRustは相互運用可能(FFI)
- 新規開発やセキュリティクリティカルな部分から順次Rust化
- C言語の知識は引き続き重要(既存コードの理解・保守)
参考資料
• InfoQ - Linux 6.1 Officially Adds Support for Rust in the Kernel
• Microsoft Security Response Center - A Proactive Approach to More Secure Code
• Asahi Linux - Paving the Road to Vulkan
• Google Security Blog - Memory Safe Languages in Android 13
• Google Security Blog - Rust in Android: Move Fast and Fix Things (2025)
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以降で公式サポート |
| ユーザーランドツール | Rust | uutils(coreutils互換)を採用 |
| システムデーモン | Rust | 新規開発。安全性重視 |
| UIレイヤー | Dart/Rust | Flutter 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対応 | 学習コスト | カスタマイズ性 | 評価 |
|---|---|---|---|---|---|---|
| Buildroot | C / Make | 最小 | ◎ | 中 | ◎ 完全制御 | 推奨 |
| Yocto | C / Python | 小〜中 | ◎ | 高 | ◎ 企業向け | 複雑 |
| Alpine Linux | C (musl/busybox) | 130MB | ○ | 低 | ○ | 代替案 |
| Void Linux | C (xbps) | 小 | ○ | 中 | ○ musl対応 | 代替案 |
| Tiny Core | C (busybox) | 16MB | △ | 高 | △ | 特殊用途 |
| Redox OS | Rust | 小 | △ | 高 | ◎ 独自カーネル | Rust純粋 |
| Maestro | Rust | 極小 | △ | 高 | ○ 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人開発者のプロジェクト
コード量・シンプルさ・Claude Code開発適性の検証
| 対象 | コード行数 | マルチアーキ | Claude Code適性 |
|---|---|---|---|
| Linux Kernel | 4,000万行 | ◎ 全対応 | ❌ 理解不可能 |
| Yocto (BitBake) | 6万行(Python) | ◎ | △ 複雑すぎる |
| Buildroot (コア) | 約1,000行 | ◎ | ✅ 最適 |
| Redox OS(カーネル) | 1.6〜3万行 | △ 限定的 | △ Rust学習必要 |
| Maestro OS | 4.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に指示し、コードを生成させる開発スタイル。
- DEV Community: Vibe coding an Operating System - 実際にOS開発を試みた記事
- LinkedIn: Vibe coding an OS kernel into existence
- Y Combinator 2025年冬バッチの25%のスタートアップが95%以上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を組み合わせてエラーと幻覚を軽減
- 「非常に退屈で時間のかかる」作業を自動化
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
- • 「より強力でカスタマイズ可能」
- • 「学習曲線が非常に急」
- • 「企業向けには最適」
- • 初回ビルドに数時間
英語圏コミュニティの結論
- 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以降)
5 アーキテクチャ
Hayabusa OS アーキテクチャ
Buildroot + Flutter/Rust UIレイヤー
┌─────────────────────────────────────────────────────────────────┐
│ 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) ││
│ └──────────────┘ └──────────────┘ └────────────────────────┘│
└─────────────────────────────────────────────────────────────────┘6 プロジェクト構造
Hayabusa プロジェクト構造
Buildroot + Flutter UI
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.md7 開発手順
開発環境セットアップ
Buildroot + Flutter Embedded Linux
# 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-linux8 Claude Codeでの開発ガイド
開発フロー概要
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 を分析して改善点を提案して"
$ claude "今日の変更をコミットして。メッセージは内容から自動生成して"
9 ディストロのフォークは必要か?
結論:フォーク不要
Buildrootは「ディストリビューション」ではなく「ビルドシステム」のため:
- フォーク不要:設定ファイル(defconfig)でカスタマイズ
- オーバーレイ:独自ファイルを追加可能
- パッケージ追加:外部パッケージディレクトリで拡張
- アップストリーム追従:Buildroot本体の更新を簡単に取り込める
Alpine/Voidなどの「ディストリビューション」をフォークすると、アップストリームとの同期が大変。 Buildrootなら設定ファイルの管理だけで済む。
開発プロジェクトの配置
おすすめのプロジェクト配置
ホームディレクトリでの整理方法
/home/username/
├── projects/ ← 開発プロジェクトをまとめる
│ ├── work/ ← 仕事関連
│ │ ├── client-a/
│ │ └── client-b/
│ ├── personal/ ← 個人プロジェクト
│ │ ├── my-blog/
│ │ └── portfolio/
│ └── learning/ ← 学習用
│ ├── typescript-practice/
│ └── sveltekit-tutorial/
│
├── .local/
│ └── bin/ ← 自作スクリプトを置く
│
└── .config/ ← エディタやツールの設定まとめ
- Linuxは全て
/(ルート)から始まる階層構造 - ホームディレクトリは
/home/username/または~ - パス区切りは
/(スラッシュ) .で始まるファイルは隠しファイル- 権限(パーミッション)を理解して適切に設定する
- プロジェクトは
~/projects/にまとめると管理しやすい