OSの歴史と進化

OSの歴史は「抽象化の積み重ね」の歴史である -- ハードウェアの複雑さから人間を解放する戦いの記録。

この章で学ぶこと

• OSの進化の主要なマイルストーンを知る
• バッチ処理→タイムシェアリング→GUIの流れを理解する
• 現代OSのルーツを辿れる
• 各時代のOS設計思想がなぜ生まれたかを理解する
• Unix/Linux/Windowsの歴史的背景を詳しく知る

前提知識

このガイドを読む前に、以下の知識があると理解が深まります:

• 基本的なプログラミングの知識
• 関連する基礎概念の理解
• OSとは何か の内容を理解していること

1. OSの進化年表

1.1 1940-1950年代: OS以前の時代

コンピュータの黎明期:

  1943-1945: ENIAC（Electronic Numerical Integrator and Computer）

1949: EDSAC（Electronic Delay Storage Automatic Calculator）
  → ストアードプログラム方式の実用化
  → プログラムをメモリに格納して実行
  → フォン・ノイマン・アーキテクチャの実装

  1950年代前半の典型的なコンピュータ利用:

この問題を解決するために、最初のOSが生まれた。

1.2 1950年代後半: バッチ処理の時代

1950年代: バッチ処理の時代

バッチ処理OSの仕組み:

1959: SHARE Operating System (SOS)
  → IBM 709用のバッチ処理OS
  → ユーザーコミュニティSHAREが開発

  バッチ処理OSの限界:
  - CPUがI/O待ちの間、完全にアイドル
  - 対話的な操作が不可能
  - デバッグが極めて困難（結果は翌日返却）
  → これを解決するのがマルチプログラミング

1.3 1960年代: マルチプログラミングとタイムシェアリング

1960年代: マルチプログラミングとタイムシェアリング

マルチプログラミングの原理:

1964: Multics（MULTiplexed Information and Computing Service）

1964: IBM OS/360

1965: THE（Technische Hogeschool Eindhoven）
  → Dijkstraによる階層構造OS
  → セマフォの発明（同期プリミティブ）
  → 構造化プログラミングの提唱
  → OSの設計をソフトウェア工学的に捉えた最初の例

1.4 1970年代: Unixの誕生

1970年代: Unixの誕生

Unixの分裂（Unix Wars）:

1979: Unix Version 7
  → 「最後の真のUnix」と呼ばれる
  → 最も影響力のあるバージョン
  → awk, make, tar, cpio 等のツールを含む
  → 多くのUnix系OSの基盤となった

1.5 1980年代: PCとGUI

1980年代: PCとGUI

GUIの系譜:

1.6 1990年代: Linux, Windows, Web

1990年代: Linux, Windows, Web

1990年代のオープンソース運動:

1.7 2000年代以降: モバイルとクラウド

2000年代〜: モバイルとクラウド

2. 重要な概念の進化

2.1 マルチタスクの進化

マルチタスクの進化:

  バッチ処理（1950s）:
  Job1 ──────→ Job2 ──────→ Job3
  → 1つずつ順番に実行

  マルチプログラミング（1960s）:
  Job1 ██░░██░░██
  Job2 ░░██░░██░░
  → I/O待ちの間に他のジョブを実行

  タイムシェアリング（1960s）:
  User1 █░░█░░█░░
  User2 ░█░░█░░█░
  User3 ░░█░░█░░█
  → 各ユーザーに短い時間を交互に割り当て

  協調的マルチタスク（1980s-90s）:
  → プロセスが自発的にCPUを譲る
  → Windows 3.x, Classic Mac OS
  → 1プロセスが暴走すると全体がフリーズ

  プリエンプティブマルチタスク（1990s〜）:
  → OSがプロセスを強制的に切り替え
  → 1つのプロセスが暴走しても他に影響しない
  → 現代の標準
  → Unix (1969), Windows NT (1993), macOS (2001)

  リアルタイムマルチタスク:
  → 期限（デッドライン）内に確実にタスクを完了
  → Rate Monotonic Scheduling, Earliest Deadline First
  → VxWorks, QNX, FreeRTOS

2.2 メモリ管理の進化

メモリ管理の進化:

  1. 固定パーティション（1950s-60s）:

     ┌────────────────┐
     │ OS             │ 固定サイズ
     ├────────────────┤
     │ パーティション1│ 32KB
     ├────────────────┤
     │ パーティション2│ 64KB
     ├────────────────┤
     │ パーティション3│ 128KB
     └────────────────┘

→ ジョブをサイズに合うパーティションに配置
     → 内部フラグメンテーション（余った部分が無駄）

  2. 可変パーティション（1960s）:
     → ジョブのサイズに合わせてパーティションを動的に作成
     → 外部フラグメンテーション（隙間が散在）
     → コンパクション（ジョブを詰め直す）で解決

  3. ページング（1960s-70s）:

4. 仮想メモリ（1960s〜現在）:
     → 物理メモリ + ディスク（スワップ）= 巨大なアドレス空間
     → デマンドページング: 使われたページだけメモリに読む
     → ページフォルト: アクセスされたページが物理メモリにない
       → OSがディスクから読み込んで続行
     → 各プロセスが独立した広大なアドレス空間を持つ

  5. 現代のメモリ管理技術:

2.3 ファイルシステムの進化

ファイルシステムの進化:

  1950s: 磁気テープ（シーケンシャルアクセスのみ）
  1960s: FAT（Floppy Disk用、フラットな構造）
  1970s: Unix File System（inode、階層構造）
  1980s: FAT16（MS-DOS）、HFS（Macintosh）
  1990s: ext2（Linux）、NTFS（Windows NT）
  2000s: ext3/ext4（ジャーナリング）、ZFS（Sun）
  2010s: Btrfs（Linux）、APFS（Apple）
  2020s: bcachefs（Linux 6.7で統合）

  ジャーナリングファイルシステムの革新:

Copy-on-Write (CoW) ファイルシステム:

2.4 セキュリティの進化

OSセキュリティの進化:

  1960s: パスワード認証（CTSS で初めて導入）
  1970s: Unix権限モデル（owner/group/other、rwx）
  1980s: アクセス制御リスト（ACL）
  1990s: ファイアウォール、暗号化ファイルシステム
  2000s: SELinux（NSA）、ASLR、DEP/NX
  2010s: サンドボックス、コンテナ隔離、UEFI Secure Boot
  2020s: ゼロトラスト、eBPF によるセキュリティ監視

  現代OSのセキュリティ機能:

3. OSの系譜図

Multics (1964)
    │
    ├──→ Unix (1969) ──────────────────────────────────┐
    │      ├── BSD (1977) ──→ FreeBSD ──→ macOS/iOS   │
    │      │                 → OpenBSD（セキュリティ重視）
    │      │                 → NetBSD（移植性重視）     │
    │      ├── System V ──→ Solaris, AIX, HP-UX       │
    │      └── Philosophy ──→ GNU (1983)               │
    │                          └── + Linux (1991)      │
    │                               ├── Ubuntu         │
    │                               ├── RHEL           │
    │                               ├── Android        │
    │                               ├── Chrome OS      │
    │                               └── SteamOS        │
    │
  CP/M (1974) ──→ MS-DOS (1981) ──→ Windows 95/98/Me │
                                                       │
  VMS (1977) ──→ Windows NT (1993) ──→ Win 2000/XP    │
                                    ──→ Win 7/10/11    │
                                                       │
  Xerox Alto (1973) ──→ Macintosh (1984)               │
                    ──→ Windows GUI                     │
                                                       │
  NeXTSTEP (1989) ──→ Mac OS X (2001) ──→ macOS       │
                                                       │
  新しい流れ:                                          │
  Linux Kernel ──→ Android (2008)                      │
  Linux Kernel ──→ Chrome OS (2011)                    │
  Zircon (μkernel) ──→ Fuchsia (Google, 2016-)        │
  Redox (Rust) ──→ 次世代Unix-likeOS                   │

各OSの影響関係:

4. OSの未来

現在進行中の変革:

  1. AI統合OS:

2. Rust製OS:

3. WebAssembly (Wasm) OS:

4. Unikernel と MicroVM:

実践演習

演習1: [基礎] -- OS情報の確認

# 自分のOSの情報を確認
# Linux:
uname -a
cat /etc/os-release
cat /proc/version
hostnamectl  # systemd環境
 
# macOS:
sw_vers
uname -a
system_profiler SPSoftwareDataType
 
# カーネルバージョン、ビルド日、アーキテクチャを記録せよ
 
# カーネルの設定を確認（Linux）
cat /boot/config-$(uname -r) | grep CONFIG_PREEMPT
# → プリエンプションモデルの確認
 
# ブートログの確認
dmesg | head -50
journalctl -b | head -50  # systemd環境
 
# ハードウェア情報
lscpu          # CPU情報
lsblk          # ブロックデバイス
lspci          # PCIデバイス
lsusb          # USBデバイス

演習2: [応用] -- Unix哲学の実践

# パイプで小さなツールを組み合わせて以下を実現せよ:
 
# 1. /etc/passwdからシェルの使用統計を取る
cat /etc/passwd | cut -d: -f7 | sort | uniq -c | sort -rn
 
# 2. アクセスログからステータスコード別の集計
cat access.log | awk '{print $9}' | sort | uniq -c | sort -rn
 
# 3. ディレクトリ内のファイルサイズトップ10
du -sh * 2>/dev/null | sort -rh | head -10
 
# 4. プロセスのメモリ使用量ランキング
ps aux --sort=-%mem | awk 'NR<=11{printf "%-10s %5s %s\n", $1, $4, $11}'
 
# 5. ネットワーク接続の状態別カウント（Linux）
ss -tan | awk 'NR>1{print $1}' | sort | uniq -c | sort -rn
 
# 6. 自分で同様のパイプラインを3つ考えて実行せよ
# ヒント: ps, netstat, df, du, wc, grep, awk, find, xargs を活用

演習3: [応用] -- OS歴史の調査レポート

以下のいずれかのテーマについて、2000字以上のレポートを書け:

1. Unix戦争（BSD vs System V）の経緯と影響
   - 技術的な違い
   - ライセンスの問題
   - POSIXによる統一
   - 現代への影響

2. Linux vs MINIX 議論（Tanenbaum-Torvalds debate）
   - モノリシック vs マイクロカーネルの議論
   - 両者の主張
   - 30年後の評価
   - 現代のOS設計への影響

3. Windowsの進化（MS-DOS → Windows 11）
   - アーキテクチャの変遷
   - GUI の進化
   - NT カーネルの設計思想
   - WSL2 による Linux との融合

4. Apple のOS戦略（Classic Mac OS → macOS → iOS）
   - NeXT買収の意義
   - Unix基盤への移行
   - iOSとmacOSの統合（Apple Silicon）
   - エコシステムの強さ

演習4: [発展] -- 各世代のOSをエミュレータで体験

以下のOSをエミュレータで体験し、操作感の変化を記録せよ:

1. SIMH（System Simulator）:
   → PDP-11上のUnix V6を体験
   → ed エディタでのファイル編集
   → シェルの操作（Thompson shell）

2. DOSBox:
   → MS-DOS 6.22を体験
   → コマンドライン操作（dir, copy, type, edit）
   → 640KBメモリの制約を体感

3. PCem / 86Box:
   → Windows 3.1 の GUI を体験
   → ファイルマネージャ、ペイントブラシ

4. QEMU:
   → Linuxの初期バージョン（0.01は無理だが1.0系）を起動
   → 最小構成のLinuxの動作を確認

5. ブラウザベースのエミュレータ:
   → copy.sh/v86/ でWindows 95, Linux等を体験
   → archive.org の各種OSエミュレーション

各OSについて以下を記録:
- 起動にかかる時間
- 利用可能なコマンド/操作
- メモリ管理の違い
- マルチタスクの有無
- 現代のOSとの比較

トラブルシューティング

よくあるエラーと解決策

デバッグの手順

1. エラーメッセージの確認: スタックトレースを読み、発生箇所を特定する
2. 再現手順の確立: 最小限のコードでエラーを再現する
3. 仮説の立案: 考えられる原因をリストアップする
4. 段階的な検証: ログ出力やデバッガを使って仮説を検証する
5. 修正と回帰テスト: 修正後、関連する箇所のテストも実行する

# デバッグ用ユーティリティ
import logging
import traceback
from functools import wraps
 
# ロガーの設定
logging.basicConfig(
    level=logging.DEBUG,
    format='%(asctime)s [%(levelname)s] %(name)s: %(message)s'
)
logger = logging.getLogger(__name__)
 
def debug_decorator(func):
    """関数の入出力をログ出力するデコレータ"""
    @wraps(func)
    def wrapper(*args, **kwargs):
        logger.debug(f"呼び出し: {func.__name__}(args={args}, kwargs={kwargs})")
        try:
            result = func(*args, **kwargs)
            logger.debug(f"戻り値: {func.__name__} -> {result}")
            return result
        except Exception as e:
            logger.error(f"例外発生: {func.__name__}: {e}")
            logger.error(traceback.format_exc())
            raise
    return wrapper
 
@debug_decorator
def process_data(items):
    """データ処理（デバッグ対象）"""
    if not items:
        raise ValueError("空のデータ")
    return [item * 2 for item in items]

パフォーマンス問題の診断

パフォーマンス問題が発生した場合の診断手順:

1. ボトルネックの特定: プロファイリングツールで計測
2. メモリ使用量の確認: メモリリークの有無をチェック
3. I/O待ちの確認: ディスクやネットワークI/Oの状況を確認
4. 同時接続数の確認: コネクションプールの状態を確認

設計判断ガイド

選択基準マトリクス

技術選択を行う際の判断基準を以下にまとめます。

アーキテクチャパターンの選択

トレードオフの分析

技術的な判断には必ずトレードオフが伴います。以下の観点で分析を行いましょう:

1. 短期 vs 長期のコスト

• 短期的に速い方法が長期的には技術的負債になることがある
• 逆に、過剰な設計は短期的なコストが高く、プロジェクトの遅延を招く

2. 一貫性 vs 柔軟性

• 統一された技術スタックは学習コストが低い
• 多様な技術の採用は適材適所が可能だが、運用コストが増加

3. 抽象化のレベル

• 高い抽象化は再利用性が高いが、デバッグが困難になる場合がある
• 低い抽象化は直感的だが、コードの重複が発生しやすい

# 設計判断の記録テンプレート
class ArchitectureDecisionRecord:
    """ADR (Architecture Decision Record) の作成"""
 
    def __init__(self, title: str):
        self.title = title
        self.context = ""
        self.decision = ""
        self.consequences = []
        self.alternatives = []
 
    def set_context(self, context: str):
        """背景と課題の記述"""
        self.context = context
        return self
 
    def set_decision(self, decision: str):
        """決定内容の記述"""
        self.decision = decision
        return self
 
    def add_consequence(self, consequence: str, positive: bool = True):
        """結果の追加"""
        self.consequences.append({
            'description': consequence,
            'type': 'positive' if positive else 'negative'
        })
        return self
 
    def add_alternative(self, name: str, reason_rejected: str):
        """却下した代替案の追加"""
        self.alternatives.append({
            'name': name,
            'reason_rejected': reason_rejected
        })
        return self
 
    def to_markdown(self) -> str:
        """Markdown形式で出力"""
        md = f"# ADR: {self.title}\n\n"
        md += f"## 背景\n{self.context}\n\n"
        md += f"## 決定\n{self.decision}\n\n"
        md += "## 結果\n"
        for c in self.consequences:
            icon = "✅" if c['type'] == 'positive' else "⚠️"
            md += f"- {icon} {c['description']}\n"
        md += "\n## 却下した代替案\n"
        for a in self.alternatives:
            md += f"- **{a['name']}**: {a['reason_rejected']}\n"
        return md

実務での適用シナリオ

シナリオ1: スタートアップでのMVP開発

状況: 限られたリソースで素早くプロダクトをリリースする必要がある

アプローチ:

• シンプルなアーキテクチャを選択
• 必要最小限の機能に集中
• 自動テストはクリティカルパスのみ
• モニタリングは早期から導入

学んだ教訓:

• 完璧を求めすぎない（YAGNI原則）
• ユーザーフィードバックを早期に取得
• 技術的負債は意識的に管理する

シナリオ2: レガシーシステムのモダナイゼーション

状況: 10年以上運用されているシステムを段階的に刷新する

アプローチ:

• Strangler Fig パターンで段階的に移行
• 既存のテストがない場合はCharacterization Testを先に作成
• APIゲートウェイで新旧システムを共存
• データ移行は段階的に実施

シナリオ3: 大規模チームでの開発

状況: 50人以上のエンジニアが同一プロダクトを開発する

アプローチ:

• ドメイン駆動設計で境界を明確化
• チームごとにオーナーシップを設定
• 共通ライブラリはInner Source方式で管理
• APIファーストで設計し、チーム間の依存を最小化

# チーム間のAPI契約定義
from dataclasses import dataclass
from typing import List, Optional
from enum import Enum
 
class Priority(Enum):
    LOW = "low"
    MEDIUM = "medium"
    HIGH = "high"
    CRITICAL = "critical"
 
@dataclass
class APIContract:
    """チーム間のAPI契約"""
    endpoint: str
    method: str
    owner_team: str
    consumers: List[str]
    sla_ms: int  # レスポンスタイムSLA
    priority: Priority
 
    def validate_sla(self, actual_ms: int) -> bool:
        """SLA準拠の確認"""
        return actual_ms <= self.sla_ms
 
    def to_openapi(self) -> dict:
        """OpenAPI形式で出力"""
        return {
            'path': self.endpoint,
            'method': self.method,
            'x-owner': self.owner_team,
            'x-consumers': self.consumers,
            'x-sla-ms': self.sla_ms
        }
 
# 使用例
contracts = [
    APIContract(
        endpoint="/api/v1/users",
        method="GET",
        owner_team="user-team",
        consumers=["order-team", "notification-team"],
        sla_ms=200,
        priority=Priority.HIGH
    ),
    APIContract(
        endpoint="/api/v1/orders",
        method="POST",
        owner_team="order-team",
        consumers=["payment-team", "inventory-team"],
        sla_ms=500,
        priority=Priority.CRITICAL
    )
]

シナリオ4: パフォーマンスクリティカルなシステム

状況: ミリ秒単位のレスポンスが求められるシステム

最適化ポイント:

1. キャッシュ戦略（L1: インメモリ、L2: Redis、L3: CDN）
2. 非同期処理の活用
3. コネクションプーリング
4. クエリ最適化とインデックス設計

FAQ

Q1: なぜLinuxには多くのディストリビューションがあるのか？

Linuxカーネルはオープンソースであるため、誰でもカーネル+独自のパッケージ管理+独自の設定を組み合わせてディストリビューションを作れる。目的に応じた最適化が異なるため多様性が生まれた（サーバー向けRHEL、デスクトップ向けUbuntu、セキュリティ向けKali、教育向けEdubuntu等）。これは「自由」の証であり、同時に初心者を混乱させる原因でもある。主要なディストリビューションは10程度に集約されつつある。

Q2: macOSはなぜUnixベースなのか？

Apple がNeXT社を買収（1997年）した際に、Steve Jobsが開発したNeXTSTEP（Mach+BSD）が基盤となった。Darwin（macOSのカーネル）はMachマイクロカーネル+FreeBSDコンポーネントで構成され、正式にUNIX 03認証を取得している。Classic Mac OS（System 1-9）は独自OSだったが、モダンなメモリ保護やプリエンプティブマルチタスクを持たず限界があった。NeXTSTEPの採用により、macOSは安定したUnix基盤と美しいGUIを両立できるようになった。

Q3: Windows NTとWindows 95は何が違ったのか？

Windows 95はMS-DOS上に構築された16/32bitハイブリッドで不安定だった。一方Windows NTはVMS設計者Dave Cutlerがゼロから設計した完全な32bit OSで、メモリ保護、プリエンプティブマルチタスク、NTFSを備えた。NT系は企業向け（NT 4.0, 2000）として位置づけられ、コンシューマー向け（95, 98, Me）と別ラインだった。Windows XP（2001年）でこの2つのラインが統合され、コンシューマーもNTカーネルの恩恵を受けるようになった。

Q4: BSDとLinuxは何が違うのか？

技術的には両方ともUnix系OSだが、主要な違いは以下の通り:

1. カーネル: BSDはカーネル+ユーザーランドが一体開発。Linuxはカーネルのみ（ユーザーランドはGNU等）
2. ライセンス: BSDライセンス（寛容）vs GPL（コピーレフト）
3. 開発モデル: BSDはコア開発チームが統制。Linuxは分散的（Linusが最終決定）
4. ドライバ: Linuxの方がハードウェアサポートが豊富
5. 用途: FreeBSDはネットワーク機器（Netflix, WhatsApp）、OpenBSDはセキュリティが重要な用途に強い

Q5: 次世代のOSはどのようなものになるか？

いくつかの方向性が議論されている:

1. マイクロカーネルの復権: seL4（形式検証）、Fuchsia（Zircon）
2. Rust製OS: メモリ安全性を言語レベルで保証
3. AI統合: OSがユーザーの意図を理解し、自律的に最適化
4. Wasm OS: WebAssemblyベースのポータブルなOS環境
5. 量子OS: 量子コンピュータのリソースを管理するOS（研究段階）
6. 脳コンピュータOS: BCIからの入力を処理するOS（将来）

まとめ

次に読むべきガイド

参考文献

1. Ritchie, D. & Thompson, K. "The UNIX Time-Sharing System." CACM, 1974.
2. Raymond, E. "The Art of Unix Programming." Addison-Wesley, 2003.
3. Campbell-Kelly, M. "From Airline Reservations to Sonic the Hedgehog: A History of the Software Industry." MIT Press, 2003.
4. Brinch Hansen, P. "Classic Operating Systems: From Batch Processing to Distributed Systems." Springer, 2001.
5. Brooks, F. "The Mythical Man-Month." Anniversary Edition, Addison-Wesley, 1995.
6. Ceruzzi, P. "A History of Modern Computing." MIT Press, 2003.
7. Salus, P. "A Quarter Century of UNIX." Addison-Wesley, 1994.
8. DiBona, C. et al. "Open Sources: Voices from the Open Source Revolution." O'Reilly, 1999.