ジャスティン・コーマック氏による対談：AI 時代における「ユニカーネル」の再評価

ジャスティン・コーマック氏（旧ミラージュ OS、ユニカーネル・システムズ）との対談録です。AI の登場により、「ユニカーネル」概念は困難から解放され、新たな可能性を開いています。

1. ユニカーネルの歴史的困難と現代での再解釈

2015 年頃にハスキー言語（OCaml ベース）を通じてミラージュ OS と出会いました。当時は以下の理由から開発が困難でした。

• アプリケーション即ち OS: ユーザランド（一般ユーザ空間）が存在せず、Web サーバーや DNS、メール送信などもライブラリとして実装する必要がありました。
• インフラの不足: TCP/HTTPS スタックはあったものの、ストレージドライバがほぼ存在せず、NetBSD のものをユーザ空間で実行させる必要がありました。
• 業界の教条: 「ニックスは難しい」「ユニカーネルは難しい」という偏見が存在しました。

しかし現在では状況が変わりました。

• AI とモデル重み: これらの困難な概念は、LLM の重みに組み込まれています。
• 認知の変化: プロンプトで記述すればよく、「それらは難しい」という教条を手放せば構いません。

2. オペレーティングシステム：設計上の負債（テクニカルデット）

従来のアーキテクチャは「アプリケーション」と「OS」の二重構造ですが、これは40 年前のヒューマン・オペレーター時代の名残です。

シェル残留とデータ漏洩リスク

• 従来の OS: ユーザランドアプリが消滅するとシェルが残ります。
  • シェルは「データ漏洩のための VIP バターサービス（執事サービス）」となります。
• ユニカーネル: アプリケーションの中に機能を内包するため、攻撃対象領域（アタック・サーフェス）が格段に小さくなります。

完全なゼロへの道とモデル重み

ジャスティン氏は「攻撃対象領域の削減限界」を指摘しましたが、以下が重要な鍵となります。

• シェルなし状態: シェルやインタプリタがない場合、モデルは**「次に何をすべきか」を理解できません**。
• 攻撃ベクトルの変化: ランダムな Drive-by 攻撃から、ソースコードが必要な標的型攻撃へ移行させられます。

歴史的教訓

• 「コンパイラを本番環境に置くな」という格言から始まって、ビルド用コンテナを経てChainguardのようなアプローチまで進んできました。
• しかし依然として、「攻撃対象領域をゼロにする」方向へ完全に進むことは困難でした。

3. 開発の加速：ライブラリの自動移植と S3 アプローチ

かつて「OCaml にライブラリがない」という問題に対し、現在では以下のように解決可能です。

ライブラリのループ移植

• Go ライバーリを OCaml へループで移植するだけで、ユニカーネル版の Stripe が作れます。
• オラクル（正解）の利用: 元のツールが正解であれば、差分テストを行い自動化することで移植がトリビアルになります。

ストレージ戦略：ターボパフ（Turbo-Puff）

クラウドおよびオンプレミスワークロードに共通するアプローチです。

• 一次ストレージ: S3 を採用し、無限に拡張可能な設計とします。
• キャッシュ層: ローカルの NVMe ブロックキャッシュと LRU アルゴリズムでホットデータに対応します。
• 結論: レイテンシーが制約にならない限り、S3 で全てを構築可能です。

4. ニックス・OS とエージェントによるオーバーレイ

ジャスティン氏はニックス（Nix）の実験も行いましたが、以下の知見を得ています。

• フレーク問題: エージェントに OS プロトタイプを構築させると、テストがすべてフレーク（不安定）になることが判明しました。
• ニックスの真価: 「ニックス・pkg」自体は素晴らしいですが、「ニックス・OS マシンテスト」こそ最高です。
  • テストで機械の艦隊を立ち上げ、ネットワークルールとアプリの相互作用を確認します。
• オーバーレイのパッチ化: アップストリームへの依存やサプライチェーン問題を単なるオーバーレイとして扱います。「世界を修正」しましょう。
• 人間依存からの脱却: 「親愛なる開発者（Dear Maintainer）」へのツールコールは、休暇中の担当者による待機時間を招きます。再帰的なプロダクトとして、サードパーティバイナリではなくファーストパーティのソースコードで修正する能力が必要です。

5. セキュリティとアーキテクチャ：seL4 vs ユニカーネル

セキュリティを重視する場合、二つの選択肢しかありません。

1. 正式に検証された OS: seL4 を使用します（ただしオーストラリア政府がチームを解散させた経緯があります）。
2. ユニカーネル: 他の人がユニカーネルを検討すべきです。ハッキングしやすいものを強化するのではなく、別の設計思想から再構築します。

リング分離とパッチ管理の現実

• 権限リング: 初期の設計で全てを同一権限で行うのは危険ですが、AI エイジにいればプロンプト一つで解決可能です。systemd の cgroup に祈る必要はありません。
• 週次カーネルパッチ: Linux ではアップストリームへのパッチ適用が週単位で義務化されています。
  • KVM（Firecracker）の抜け出し事件で、Vercel 他から 50,000 ドルを集めるような大規模なセキュリティリスクが発生しています。
• 結論: エンタープライズはパッチ適用に多大なコストを払っており、ユニカーネルの方が安全かつ効率的です。

6. Spaceleans: 分散型ユニカーネルの実証

7 ヶ月前に行われた調査では、ミラージュフォルダに全ての機能を有するシステムが発見されました。Spaceleans（OCaml への Microsoft Orleans の移植）は以下の機能を持ちます。

• アーキテクチャ: 分散型アクターシステムであり、トランザクションを備えたユニカーネルとして動作します。
• 永続性: 多くの物理マシンを一つのアドレス可能なヒープにマージします。アクターは常に存在し、メモリ外の場合はストレージプロバイダーから再水化されます。
• 機能内包: NTP クライアント/サーバー、TigerBeetle 時間処理、DNS、HTTP、ロギング、PII ラッパー、Anthropic/OpenAI クライアント、決済などがプラグ可能に実装されています。
• 結論: エージェントは**「Erlang 風（エールラング的）」な分散型ユニカーネル OS**を実証しました。

7. 言語とバックプレッシャー：OCaml, Rust, Zig の比較

AI エージェント環境下での言語選択において、以下の要素が重要です。

OCaml の強み

• 関手（Functors）: モジュール間の結合が強力で、

  .mli

  ファイルがエージェントに効率的なコンテキストを提供します。
• エコシステム: Opam と Dune が成熟しており、Hindley–Milner 型システムはモデルの理解を助けます。

Rust の課題

• バックプレッシャー（コスト）: コンパイル時間が長く、LLM の幻覚が高価になります（コンパイルが遅いと試行回数が減るため）。
  • 例：100 万行の Rust コードを持つ S3 クローンでは、4 つのエージェントによる同時コンパイルで CPU ディスクを争います。
• コスト比較: トークン料よりもマシンの性能向上費用の方が高くなることがあります。

ハスキーと依存型型

• 空間漏れ（Space Leak）はランタイムの状態空間に居住し、本番環境でのみ現れます。
• Rust の線形型はハスキーの論文から派生しており、Zig は「最初から割り当てて再び割り当てない」80/90 年代のゲーム開発手法です。
• 将来: **依存型型（Dependent Types）**こそが次世代言語の勝者だと考えられます。型にコード化できるほどバックプレッシャーは増大します。

8. エージェント用言語の開発：Cursed との教訓

言語開発のペースは人間学習速度に制限されていましたが、エージェントなら PLT（プログラミング言語理論）を頼りにできます。

Cursed の開発プロセス

• 背景: Claude をループで走らせ、GenZ プログラミング言語「Cursed」を作成しました。「sus, slay, vibes」でコーディングできる唯一のコンパイル型言語です。
• 費用対効果: C → Rust → Zig と移行しましたが、Zig は失敗（約 6,000 ドル×3 回）。Go の費用と比較しても合理的ではありませんでした。
• 驚異的事実: コンテキストウィンドウを適切に割り当てれば、モデルの重みにない言語でもプログラミング可能です。

開発への提言

• 破壊的変更: Python 2→3 のような「非破壊」ルールは通用しません。スキルパック（機能パック）と共に破壊的変更を配送し、エージェントに自動移行させましょう。
• コンパイル型言語: オープンモデルのファインチューニングではなく、T-ダイアグラム（墓石図）方式で文法と語彙を固定し、セルフホスティングコンパイラへの到達を目指します。

9. まとめ：AI 時代の行動指針

パブでの議論最終盤、以下の結論に達しました。

• リーダーシップの転換: 6 ヶ月以内に、組織は「人々の活力曲線（vitality curve）」へ配置されるよう求められるでしょう。
• 雇用の必須条件: AI を実験せずに「通常の作業」で忙しいチームは、置換される準備ができています。
• 好奇心: 雇用可能性のためだけでなく、好奇心を持ってエージェントを構築し、素晴らしいものを作り出しましょう。

結論として： もし安全なシステムを構築したい場合は、真剣にユニカーネルを検討してください。 私たちの間では文芸復興（ルネサンス）期にいます。経験が多いほどサンプリングできるものは増えますが、全てがリリースされるわけではありません。好奇心を失わないでください。

---

対談の章目リスト

• 0:21

  — ユニカーネルの発見：ハスキーから OCaml へミラージュへ

• 0:55

  — ユニカーネルとは何か、そしてなぜ困難だったのか

• 2:45

  — 困難は過去形（ハード・パスト・テンス）

• 3:33

  — なぜオペレーティングシステムが必要なのか？

• 4:17

  — シェルはデータ漏洩のための執事サービス

• 5:12

  — アタックサーフェスの削減は漠然としている

• 7:26

  — コンパイラを本番環境に置くな

• 9:13

  — Stripe をユニカーネルへ移植する

• 9:54

  — 最小限の Linux と Rust による mkfs.xfs

• 12:22

  — S3 で全てのこと

• 13:48

  — ニックス、マシンテストとオーバーレイ

• 15:28

  — 人間をツールコールすることは AGI ではない

• 15:53

  — seL4 またはユニカーネル

• 16:56

  — 権限リング（プリビレッジ・リング）

• 18:24

  — 週次カーネルパッチと KVM エスケープ

• 19:38

  — デモ：ミラージュフォルダ、NTP と時刻

• 22:05

  — Spaceleans：OCaml としてのユニカーネルで動作するオルラン

• 25:31

  — 歴史をサンプリングする

• 26:52

  — これを試させる方法：ただやってみる

• 28:57

  — OCaml と OxCaml

• 31:45

  — Rust のコンパイル時間とバックプレッシャー

• 33:06

  — ハスキー、空間漏れと依存型型

• 35:13

  — メモリ戦略：Rust、Zig とゲーム開発者

• 36:10

  — エージェント用に設計された言語

• 37:41

  — 破壊的変更とスキルパック

• 38:53

  — カーズド（Cursed）

• 42:36

  — カーズドから学んだこと

• 46:47

  — 次に什么：AI の活用は必須