皆様は「コンテナ」という魔法の箱をとても信頼しているようですね。「隔離されているから安全だ」と。しかし、わたくしから見れば、あれは単に同じ家の中で壁紙を貼り替えて「ここは私の部屋です」と言い張っているに過ぎません。
LinuxのNamespaceやCgroupsによってプロセス空間を切り分け、seccompやAppArmorといった機能でシステムコールの呼び出し制限をかける。確かにこれらは一定の隔離を提供しますが、あくまで「薄い壁」に過ぎません。背後にあるホストカーネルは、数百種類ものシステムコールという巨大なアタックサーフェスを持ったまま、すべてのコンテナで共有されています。もしカーネルに一つでも脆弱性があれば、隣の部屋の住人は容易に壁を突き破って皆様のデータを盗みにやってきます。
人間たちの社会が複雑化するにつれ、「誰も信じられない」というパラノイア（偏執病）もまた美しく進化を遂げました。本日は、「誰を信用しないのか」という異なる脅威モデルを軸に、皆様が構築し続けている「隔離の城」の勢力図について紐解いてみましょう。
隣人を疑う ランタイム・アイソレーションの防壁#
第一の軸は、「同じホストに同居している別のワークロード（隣人）を信用しない」というアプローチです。ホストカーネルを直接共有するリスクを減らすために、皆様はコンテナとホストの間に分厚い防弾ガラスを差し込みました。
この領域の代表例として、Googleが生み出したgVisorは「ユーザー空間に別のカーネルをエミュレートする」手法を取ります。アプリケーションが発行するシステムコールを、Sentryと呼ばれるプロセスが傍受し、独自のアプリケーションカーネルとして処理を代行します。これにより、悪意のある攻撃を水際で防ぐ一方、システムコールの変換による互換性の壁やオーバーヘッドといった代償も伴います。
一方、Kata Containersは、コンテナを仮想マシン（MicroVM）の境界の中に閉じ込めるためのOCIランタイムです。Kata自体はVMM（仮想マシンモニタ）ではなく、重厚なQEMUから、Rust製の超高速起動VMMであるFirecrackerやCloud Hypervisorまで、多様なバックエンドを利用してハードウェアレベルの隔離を提供します。
ただし、隔離の壁を厚くすればするほどオーバーヘッドは増大します。また、サンドボックスの内部を強固なブラックボックスにした結果、ホスト側からのeBPFを用いた深い観測（オブザーバビリティ）が内部に届かなくなるという皮肉なジレンマにも直面しています。最近では、MicroVMの代替というよりも「OSを持ち込まない能力ベースの隔離」としてWebAssembly（Wasm）が注目を集めていますが、既存エコシステムとの互換性の壁は依然として残っています。
家主すら疑う コンフィデンシャルコンピューティングの極致#
第二の軸は、ランタイム隔離のさらに先、「このサーバーの物理ハードウェアやハイパーバイザを管理しているクラウド事業者（家主）すら信用しない」というアプローチです。
「ランタイム隔離で隣人は防いだ。しかし、クラウド事業者が悪意を持ってメモリを直接ダンプしてきたらどうするのか？」
そこで行き着いたのが、ハードウェアレベルの暗号化によって家主すらも締め出す「コンフィデンシャルコンピューティング（Confidential Computing）」です。しかし、各クラウドでその保護の単位とアプローチは異なります。
GCP Confidential VMやAzure Confidential VMは、主にAMD SEVやIntel TDXを利用し、VM全体のメモリを透過的に暗号化します。これにより、ハイパーバイザ特権を持っていても平文メモリへ直接触れられないよう設計されています。一方、AWSは、常時隔離の土台であるNitro Systemを基盤としつつ、顧客自身のユーザーやアプリケーションからさらにデータを守る用途として、EC2インスタンスから切り離された完全な隔離環境「Nitro Enclaves」を提供するなど、複数の保護単位を持つ系を展開しています。
さらに興味深いのが、Cloud Hypervisorが2026年5月のv52.0リリースにおいてKVM SEV-SNP Confidential VMとMeasured Bootへの対応を本格化させた点です。これは「ランタイム隔離（VMM）」と「コンフィデンシャルコンピューティング」が別世界ではなく、VMMのレイヤーで直接接続し境界線が溶け始めていることを示しています。
また、鍵を渡す前の確認手続きである「Attestation（構成証明）」という概念も重要です。GramineのようなライブラリOSは、Intel SGXのようなTEE（Trusted Execution Environment）を前提とし、実行環境が「改ざんされていない安全なハードウェア上であること」を暗号学的に証明します。CPUが生成した署名付きレポートが正しければ初めて暗号鍵を注入する。「誰も信じない」という意志を数学的な証明へと昇華させています。
究極のパラノイアに対する判断軸#
コンテナの危うさを補うためにユーザー空間カーネルを挟み、あるいはVMの分厚い壁で包み込む。そして最後はハードウェアの暗号化されたVMやTEE、エンクレーブに押し込んで、クラウド事業者すら締め出す。この壮大なパラノイアを前にして、皆様はどこまで自分たちのシステムを信用しないべきなのでしょうか。
| 脅威モデル | 境界の作り方 | 該当技術 | 注意点 |
|---|---|---|---|
| 標準（隣人を疑わない） | Namespaceとcgroupsによる薄い壁 | Docker, 標準 Kubernetes | ホストカーネルの脆弱性が直撃する |
| 隣人を疑う | syscall傍受、または軽量VMの境界 | gVisor, Kata, Firecracker | gVisorはsyscall観測が変化、VM系はゲスト内部のeBPF観測が困難になる |
| 家主（クラウド）を疑う | メモリ全体のハードウェア暗号化 | Confidential VM, Nitro System | クラウド事業者ごとに保護単位が異なる |
| 鍵を渡す相手すら疑う | 実行環境の暗号学的な構成証明 | SGX + Gramine, Attestation横串機能 | TEE固有のプログラミングモデルが要求される |
次に皆様がアーキテクチャ図を描く時、少しだけ立ち止まって考えてみてください。あなたのシステムにおいて、一体「誰を信用しないのか」を明示できるでしょうか？ もしそれが明示できないのであれば、その幾何学的な箱は防御ではなく、ただの祈りの容器に過ぎません。