1970年代、OS設計は一つの問いに直面していました。
「安全性をどこまで構造に埋め込むべきか？」
理想を極限まで追うのか、現実に合わせて妥協するのか。この分岐が、その後50年の計算機基盤を決定づけました。
1. PSOS｜形式検証という理想の重さ
PSOS（Provably Secure Operating System）は、OSを数学的な「正しさ」から構築しようと試みました。
設計思想
- 数理論理での記述: 仕様を数式で定義。
- 実装の証明: 実装が仕様を満たすことを論理的に証明。
- 原理的排除: バグが入り込む余地を理論上ゼロにする。
比喩で理解する：
PSOSは「一分の狂いもない精密な設計図で建てられた金庫室」です。一度建てたら、鍵穴一つ変えるのにも設計図全体の再証明が必要になります。
抽象の一段下：現実は残酷だった
安全性を最大化しようとすると、「変更コスト」が爆発的に増加します。
- コード変更 ＝ 証明の再実行: 1行の修正が、膨大な数式の再計算を強いる。
- 証明爆発: モジュール間の依存関係が増えるほど、証明の手間が指数関数的に増大。
安全性を追求しすぎた結果、進化速度が最小化しました。市場は、動かない（進化できない）「正しさ」よりも、不完全でも「動くこと」を選んだのです。
2. Multics｜リング保護という構造的防御
Multicsは、ハードウェアの力を借りて「構造」の中に防御を組み込もうとしました。
具体設計：リング保護モデル
内側ほど高い権限を持つ階層構造（Ring 0〜7）を採用し、権限のないアクセスを物理的に遮断します。
- Ring 0: カーネル（最深部）
- 外側リング: ユーザーアプリケーション
このモデルは後のx86アーキテクチャ（CPU設計）に多大な影響を与えましたが、専用の大型機を前提としたため、経済性と拡張性の壁にぶつかり、汎用OSとしての覇権を逃しました。
3. Unix｜「書き直せる」という最強の武器
Unixは方向を180度反転させ、理想よりも「軽さ」と「移植性」に全振りしました。
抽象の一段下：Unixの生存戦略
- C言語での記述: どんなハードウェアにも移植可能。
- 統一抽象: 「Everything is a file（すべてはファイルである）」。
- シンプルな権限: ユーザー/グループ/その他の3段階パーミッション。
セキュリティは完璧ではありませんでした。しかし、「パッチが出せる（直せる）」という柔軟性と、ハードウェアを選ばない移植性が爆発的な普及を招きました。安全性より「変更可能性」を優先したことが、結果として最強の武器となったのです。
4. 三者比較（構造レベル）
| 評価軸 | PSOS (理想主義) | Multics (官僚主義) | Unix (現実主義) |
|---|---|---|---|
| 安全性 | 極大 | 高 | 中 |
| 変更コスト | 極大 | 高 | 低 |
| 移植性 | 低 | 低 | 高 |
| 普及度 | 失敗 | 限定的 | 覇権 |
勝者は、最も安全な設計ではありませんでした。最も「修正しやすい」設計だったのです。
5. 現代との接続：クラウド設計の正体
現在のクラウド設計は、Unix思想の正統な進化系にあります。
- マイクロサービス: 被害を一部に閉じ込める（局所化）。
- CI/CD: 「安全に壊し、爆速で直す」サイクルの最大化。
- 自動テスト: 数学的な証明の代わりに、膨大なテストコードで安全を補完。
かつての理想（形式検証）は消えていません。しかし、現在は「認証基盤」や「暗号アルゴリズム」など、絶対に外せない急所にのみ限定して適用される「現実解」に落ち着いています。
6. 実務への落とし込み：現代版「変更可能性」の実装手順
PSOSのような「ガチガチの固定」を避け、Unix的な「柔軟な防御」を現代の環境で実現するための3つのプラクティスです。
① インフラのコード化（IaC）
セキュリティ設定をTerraformなどのコードで管理します。
- メリット: 設定ミスが起きても、1世代前のコードに戻す（ロールバック）だけで数秒で復旧可能。
- 思想: 構造を固定するのではなく、「何度でも同じ形に作り直せる」状態を維持します。
② サービスメッシュによる「爆破区画」の構築
システムをマイクロサービス化し、その通信をIstio等で制御します。
- メリット: 1つのサービスが突破されても、隣への通信を瞬時に遮断。
- 思想: ソフトウェアレイヤーで動的に「保護リング」を形成します。
③ 「自動バリデーション」による局所的な形式検証
PSOSが目指した数学的証明を、CI/CDの中で自動実行します。
- 具体例: AWSの「Zelkova」などは、S3のポリシーが「意図せず公開されていないか」を数理的に自動検証します。
- 思想: 全部を証明するのではなく、「急所」だけに検証を絞り込みます。
7. 向いている人／向いていない人
- ◎ 向いている人
- 変化の激しいWebサービス、SaaSの開発者。
- ゼロトラスト環境の構築を目指すセキュリティエンジニア。
- 「止まらないシステム」より「すぐ直るシステム」に価値を感じるチーム。
- × 向いていない人
- 原子力、軍事、航空制御など、一瞬のミスが物理的破壊に直結する領域。
- （ここでは今もPSOS的な「形式手法」が必須です）
8. 歴史から抽出できる設計原則
- 完全性は変更速度を超えられない
- ハードウェア依存は長期戦で不利になる
- 「修正可能性」こそが最大の防御である
結論
PSOSは「正しさ」を選び、Multicsは「構造的堅牢性」を選び、Unixは「進化」を選びました。
現代のセキュリティ設計の本質は、「どれだけ守れるか」ではなく「どれだけ速く、正確に直せるか」にあります。
抽象を一段下げると、勝敗は思想の優劣ではなく、その構造が持つ「修正への柔軟性」で決まっていたのです。
歴史を味方につけ、あえて「壊れることを前提に、爆速で直す」構造を設計してください。それこそが、UNIXが50年かけて証明した唯一の正解です。
