「Unikernels were hard. Key word: were. Now we have AI.」
2026年10月、Geoffrey Huntleyは技術対談の場でこう断言しました。向かいに座るのは、MirageOSの初期コア開発者であるJustin Cormack。10年前、仮想マシン上でアプリケーションを直接稼働させるため、チームはNetBSDからデバイスドライバを抽出し、そのC言語コードを手作業でユーザー空間へと移植していました。
ユニカーネル（Unikernel）は単一アドレス空間アーキテクチャを採用しています。アプリケーションそのものがオペレーティングシステムであり、イメージ内には独立したプロセス分離も、対話型のシェルも存在しません。パケットの送受信やDNSの名前解決を行う際、外部のホスト環境に依存することはできず、あらゆる低レベルドライバとプロトコルスタックを単一のバイナリイメージ内に直接コンパイルして組み込む必要があります。
過去10年間、急峻なツールチェーンの学習コストとエコシステムの欠如により、この技術は長らく冷遇されてきました。今日、大規模言語モデルの登場により専用ライブラリを記述する敷居は劇的に下がりました。しかし、開発コストの低下は、このアーキテクチャが本質的に抱えるセキュリティの議論を解消したわけではありません。
図：ユニカーネルを極限まで削ぎ落とされたデジタルコアとして描いたコンセプトイラスト。出典：ghuntley.com
モデルの重みが肩代わりするドライバ記述の重荷
Huntleyの目には、ソフトウェア業界が長年「Nixは難しい」「Bazelは難しい」「ユニカーネルも難しい」といった一連のドグマに縛られてきたと映っています。しかしこれらの困難は、本質的には実装の詳細が生み出した知識の壁にすぎません。
モデルの重みは、型理論や長年の研究論文を吸収しています。かつて数か月を要した低レベルの足場作りも、今やいくつかのプロンプトを投げるだけで完了します。熟練エンジニアであっても、C言語のドライバコードを1行ずつ手作業で移植する必要はもうありません。
Huntleyはわずか1週間で「Spaceleans」プロトタイプを構築しました。彼はMicrosoftのOrleans分散アクターシステムをOCaml環境へ移植し、ユニカーネルイメージとして仕上げました。このシステムは複数の物理マシンを単一のアドレス可能なヒープへと統合し、アクターインスタンスをストレージから随時オンデマンドで復元します。
このプロトタイプを動作させるには、ランタイムの基盤をゼロから揃える必要がありました。コード生成を活用することで、彼はネットワークスタック、DNSリゾルバ、HTTPクライアントをわずか7日間で書き上げました。さらに続けてNTP時刻同期、LLMクライアント、分散トレーシング機能も補完。かつては専門のシステムチームが必要だった低レベルのインフラ構築を、個人開発者が数日で組み上げたのです。
エコシステムの欠如という従来の反論も、コード生成の前では説得力を失いつつあります。「OCamlには決済SDKが存在しない」といった理由でユニカーネル採用が見送られていた時代もありました。しかし自律型エージェントループを走らせれば、既存のGo製ライブラリを数時間でOCamlモジュールへと書き換えることが可能です。
Rustによる専用ツールチェーンを数時間で再現
Cormack自身のエンジニアリング実践でも、同様のパラダイムシフトが起きていました。単一アプリケーション向けの軽量Linuxイメージを構築する際、彼は極限のフットプリント削減を追求していました。従来のアプローチでは、ディスクを初期化するためだけに巨大なxfsprogsツール一式をイメージ内に含める必要がありました。
彼はその代わりに、モデルを用いてRustで専用のmkfs.xfsツールを再実装させる道を選びました。既存のネイティブツールを「正解オラクル（golden oracle）」として扱い、モデルが生成したコードの出力をバイト単位でネイティブ出力と比較検証し、多様なブロックサイズでのテストを通過させました。引数のパースからディスク構造の書き込みまで、完成に要した時間はわずか数時間でした。
このワークフローは、専用システムツールの開発手法を根本から変革します。かつて低レベルツールの軽量化には多大なメンテナンス負担が伴い、開発者は肥大化したユーザースペースを甘受せざるを得ませんでした。コード生成と差分オラクル検証の組み合わせにより、カスタムツールの制作コストは実質的に無視できる水準へと低下しました。
クラウドネイティブなインフラの進化も、ローカルファイルシステムへの依存度をさらに押し下げています。「turbopuffer」のようなモダンアーキテクチャでは、オブジェクトストレージを主永続化層として直接利用し、ローカルのNVMeドライブはブロックキャッシュと破棄ロジックの役割に特化させています。永続化をクラウドに委ねることで、ローカルに複雑なジャーナリングファイルシステムを用意する必要はなくなり、オブジェクトストレージを基盤とした大規模ステート管理が成立します。
図：「Unikernels in 2026」対談動画のサムネイル。出典：YouTube / Geoffrey Huntley チャンネル
OSの外殻を剥ぎ取っても攻撃面が消えるわけではない
開発コストが下がったことで、セキュリティに関する議論はむしろ先鋭化しています。Huntleyは、マルチユーザーOSを「ダム端末時代の遺物」と捉えています。専用マイクロサービスには余計な操作シェルは不要であり、シェルやシステムインタプリタがなければ、侵入者は足がかりや横展開の踏み台を得られず、無差別スキャン攻撃も標的を失うと主張します。
しかし、Cormackはその場ですぐに慎重な見解を示しました。彼は、コミュニティにおける「攻撃面の削減」という理解が長らく抽象的なスローガンにとどまっていると指摘します。コンテナから/bin/shを削除することは容易ですが、実行環境それ自体がチューリング完全な解釈能力を備えています。ファイルシステムの書き込みを無効化したとしても、メモリ破壊やROPチェーンによってプログラムの制御フローを乗っ取ることは依然として可能です。
Huntleyも、初期の設計がアプリケーションとカーネルを同一の特権リングに配置していた点は認めつつも、2026年の現在においてはリング分離を補完することなど「プロンプトひとつで指示できる距離」にすぎず、実効性においてもsystemdのcgroup設定の正しさに祈りを捧げる運用より遥かに安全だと反論しました。Cormackはそれ以上議論を深掘りしませんでしたが、「攻撃面」という概念が無批判にスローガン化されている点への懸念を崩しませんでした。
下層のハイパーバイザーによるサンドボックスでさえ、現実的な突破リスクが存在します。対談の収録と同じ週、セキュリティ研究者がKVMのエスケープ脆弱性を実証し、クラウド事業者から5万ドルの報奨金を獲得しました。この種の欠陥は、マルチテナントホスティングの根幹を揺るがすものです。極めて高いセキュリティを求めるのであれば、seL4のような検証可能な基盤へ移行すべきであり、単一イメージ化に過度な期待を寄せることはリスクの所在をずらすだけにすぎません。
ローカルコンパイルの遅延がモデル推論の速度を侵食する
プログラミング言語の選定は、自動化された開発効率に直結します。HuntleyはOCamlを高く評価しています。明確なインターフェースがコンパクトなコンテキストを提供し、コンパイラはわずか数秒で型検証を完了します。
一方、Rustエコシステムを採用したCormackは顕著な障壁に直面しました。Rustの厳格な型システムは推論との相性が極めて良好ですが、重厚なビルドオーバーヘッドが試行錯誤のテンポを削ぎ落とします。モデルが低レベル実装を探索する過程でハルシネーションが発生することは避けられず、ビルド完了までの長い待ち時間が試行コストを急激に押し上げます。
数百万行規模のプロジェクトでは、コンパイル処理がマシンリソースを完全に枯渇させる事態にも至りました。4つのモデルエージェントがRustコードを並行してコンパイルした結果、ディスクI/OとCPUキューが一瞬で飽和しました。高速なサーバー環境であっても、コンパイル待ちにかかる時間はモデルのトークン生成時間を日常的に上回ったのです。
この現実は、従来の開発論理を逆転させています。人間のエンジニアは「実行時の安全性の対価として遅いコンパイルを受け入れる」というトレードオフに慣れ親しんできました。しかしエージェント主導の試行錯誤ループにおいては、コンパイル遅延こそがシステム進化のボトルネックとなっています。
エンジニアリングの摩擦が消え、純粋なアーキテクチャの選択が露わになる
単一アドレス空間という構想は、決して時代遅れではありません。型理論と学術論文を消化したAIモデルは、かつてのエンジニアリングギャップを急速に埋め合わせています。ドライバやネットワークスタックの自動生成は、専用システムを組み上げる期間を劇的に短縮しました。
しかし、実装摩擦の解消は、コンピュータアーキテクチャの基本法則を書き換えるものではありません。足場を取り払った後に開発者の前に現れるのは、ユニカーネルが持つありのままの輪郭です。それは依然としてハードウェアレベルの特権リング分離を持たず、メモリ安全性に極めて敏感な単一プロセスのサンドボックスにすぎません。
AIが引き下げたのは、単に入場チケットの価格です。開発者が手作業でドライバを書く苦痛から解放されたとしても、単一特権ドメインがもたらすリスクには正面から向き合う必要があります。従来のオペレーティングシステムが培ってきたデバッグや監視のエコシステムを手放すか否かは、依然として熟慮を要するエンジニアリングの意思決定です。
参考リンク：
- Ignore Previous Directions: Unikernels in 2026 (Justin Cormack)
- Geoffrey Huntley: Unikernels were hard. Key word: were.
- Spaceleans プロジェクト設計メモと MirageOS 振り返り
