ユニカーネルとライブラリOSの設計思想

OSを「アプリにリンクするライブラリ」と見る

通常のOSは、アプリとカーネルの間に強固な壁を引きます。アプリはユーザー空間で動き、ファイルやネットワークに触れるたびにシステムコールで特権モードのカーネルへ制御を移す。この境界が安全と多重化（多数のプロセスを同時に走らせる）を支えますが、同時に境界越えのコストを生みます。

ユニカーネルはこの前提を反転させます。「このマシンでは信頼できる単一アプリしか動かさない」と割り切れば、壁はそもそも要らない——アプリと、そのアプリが実際に使うOS機能だけを、1つのアドレス空間に静的リンクして単一の起動イメージにする。これがユニカーネルであり、その思想的な土台がライブラリOSです。OS機能をカーネルに閉じ込めず、アプリにリンクされるライブラリとして提供する、という発想が出発点になります。

特権境界そのものの意味は カーネルモードとユーザーモード を、何をカーネルに置くかという軸は マイクロカーネルとモノリシックカーネルの設計比較 を前提にすると、本稿の位置づけが掴みやすくなります。

Exokernel：機構とポリシーを引き剥がす

系譜の起点は、1990年代半ばMITの Exokernel です。その主張は明快でした——OSの抽象化（プロセス、仮想メモリ、ファイルなど）はアプリごとに最適なものが違うのに、従来のカーネルはそれを1つに固定して押し付けている。だからカーネルは抽象化を提供すべきではない、と。

Exokernelが残すのは、ハードウェア資源を安全に多重化して保護する機構だけです。「このメモリページを誰に割り当てるか」「どのディスクブロックに誰がアクセスできるか」という保護はカーネルが担う一方、「そのページをどう使うか」「ブロックをどうファイルとして束ねるか」という抽象化＝ポリシーは、アプリ側にリンクされた**ライブラリOS（libOS）**に委ねます。

従来のカーネル:
  アプリ --syscall--> [カーネル：保護 + 抽象化(FS,VM,...)]

Exokernel:
  アプリ + libOS(FS,VM,... の実装)
    --低レベルな安全呼び出し--> [Exokernel：保護/多重化のみ]

この分離が決定的です。libOSはアプリと同じアドレス空間にいるただのコードなので、ファイルシステムやTCPスタックの呼び出しが、特権境界を越えないただの関数呼び出しになる。アプリは自分専用にOSをチューニングでき、不要な抽象化のコストも払いません。Exokernel自体は商用には広がりませんでしたが、「機構とポリシーの分離」と「OSをライブラリ化する」という二つの遺伝子が、後のユニカーネルへ受け継がれました。

ユニカーネル：単一アドレス空間に畳み込む

Exokernelがハードウェアの直上を想定したのに対し、現代のユニカーネルの多くはハイパーバイザの上で動きます。隔離はVM境界（ハイパーバイザ）が担保するので、ユニカーネル内部ではもう壁を立てなくてよい。そこでアプリとlibOSを1つのアドレス空間に静的リンクし、それ自体を1つのVMイメージとして起動するのがユニカーネルです。

ここから利点が直接導けます。第一に極小。リンカが実際に到達するコードしか含めないため（デッドコード除去）、使わないドライバ・ファイルシステム・プロトコルがイメージに残りません。第二に高速起動。汎用OSの初期化やデバイス列挙の大半が不要で、起動がミリ秒級になりえます。第三に小さな攻撃面。シェルも未使用のシステムコールも、そもそもイメージに存在しないので攻撃に使えません。

静的リンクで関数呼び出しに畳み込む発想自体は新しくありません。共有ライブラリの遅延解決と対をなす 動的リンクと共有ライブラリ の逆を、OS全体に適用したものと読めます。

MirageOS：型安全な言語でlibOSを書く

ユニカーネルの代表例が、ケンブリッジ発の MirageOS です。特徴は、OS機能（TCP/IPスタック、TLS、ストレージ、デバイスドライバ）を関数型言語 OCaml のライブラリ群として実装し、アプリと一緒にコンパイル・リンクして1つのVMイメージを吐く点にあります。

ここで言語選択が効いてきます。ユニカーネルは単一アドレス空間ゆえ、メモリ破壊バグが起きればプロセス境界に守られず全体が即座に壊れます。MirageOSはメモリ安全で強い静的型を持つOCamlを使い、Cで書かれた巨大なドライバ群を排除することで、この危うさを言語レベルで抑えます。実行時に使うコンポーネントはビルド時のリンク構成で確定するため、設定ファイルを読む汎用コードすら省けます。

他にも、Linuxアプリを大きく書き換えず動かすことを狙う Unikraft や、未改変のLinuxバイナリをユニカーネル風に走らせる OSv など、設計思想の異なる系統が並びます。「フルスクラッチで型安全に作り直す（MirageOS）」のか「既存資産の再利用を優先する（Unikraft/OSv）」のかは、特化の度合いをどこに置くかの選択です。

特化と汎用のトレードオフ

利点はそのまま制約の裏返しです。設計上の代償を正面から押さえます。

つまりユニカーネルは汎用OSの対極です。汎用OSは「何でも動く」ために多重化・分離・豊富な抽象化を抱え込み、その分だけ太く遅く攻撃面も広い。ユニカーネルは「1つのことだけを最速・最小で」と割り切り、そのために汎用性と内部隔離を手放します。どちらが優れているかではなく、ワークロードが単一アプリに固定でき、隔離を外側（ハイパーバイザ）に任せられるかが分岐点です。

適材適所の典型は、ネットワーク機能（DNSやTLSの終端、リバースプロキシ、ファイアウォール）や、特定のマイクロサービスなど、機能が絞られ・大量に・短命に立ち上げたい用途です。汎用サーバーの全面置き換えではなく、特化領域での尖った選択肢として位置づけるのが実務的な理解です。

まとめ

• ユニカーネルは、アプリと実際に使うOS機能だけを単一アドレス空間に静的リンクした専用イメージで、特権境界とプロセス分離を捨てて境界越えコストを消す。
• 系譜は Exokernel の「機構（保護・多重化）とポリシー（抽象化）の分離」に始まり、OS機能を再リンク可能なライブラリOSへ追い出す発想が、MirageOS などに結実した。
• 得るのは極小・高速起動・最小の攻撃面、失うのは汎用性と内部隔離で、ワークロードを単一アプリに固定でき隔離を外側に任せられる場面でのみ成立する特化のトレードオフである。

入口の特権境界は カーネルモードとユーザーモード、設計軸の対比は マイクロカーネルとモノリシックカーネルの設計比較、静的・動的リンクの基礎は 動的リンクと共有ライブラリ も合わせてどうぞ。