コンテナランタイム代替 2026 完全ガイド - containerd・CRI-O・Podman・runc・gVisor・Kata Containers・youki・WasmEdge・Firecracker 詳細解説

プロローグ — 2026 年のランタイムが再び面白い理由

2013 年に dotCloud の Solomon Hykes が PyCon US で Docker を発表してから約 10 年間、「コンテナ = Docker」という等式はほぼ疑われなかった。しかし 2020 年 12 月に Kubernetes が 1.20 から dockershim deprecation を予告し、2022 年 4 月の 1.24 で実際に削除すると風景は変わった。

2026 年 5 月現在、大規模クラスタの既定ランタイムは containerd 2.0 もしくは CRI-O 1.31 であり、ローカル開発でも Podman 5 と Orbstack が Docker Desktop のシェアを急速に奪っている。マルチテナント SaaS とサーバーレス領域では gVisor・Kata Containers・Firecracker MicroVM が標準的な隔離手段として定着し、WebAssembly ランタイムは runwasi shim を通じて Kubernetes に正式に入り込んだ。

本稿は OCI 1.2 仕様から、低レベルランタイム(runc・crun・youki)、高レベルランタイム(containerd・CRI-O)、デーモンレス(Podman・Buildah・Skopeo)、強隔離(gVisor・Kata・Firecracker・Cloud Hypervisor)、そして Wasm ランタイム(WasmEdge・Wasmtime・Wasmer・Spin・WasmCloud)までの地図を描き、誰がどの問題を解いているのか、どのワークロードにどのランタイムを選ぶべきかを一望する。

1. OCI 仕様 — すべてのランタイムの共通基盤

Open Container Initiative(OCI)は、コンテナフォーマットを標準化するために 2015 年 6 月に Docker が Linux Foundation 配下に寄贈したプロジェクトである。2026 年 5 月時点の中核仕様は次の 3 つ。

要点 — OCI イメージは tar.gz・zstd・zstd-chunked で圧縮されたレイヤーの集合に過ぎず、OCI ランタイムの役目は config.json と rootfs を受け取って隔離されたプロセスを生成することだけ。 どんな高レベルランタイムを使っても、最下層は runc・crun・youki・runsc・kata-runtime のいずれかである。

この絵を頭に置けば、以降の章の住み分けが明確になる。

2. ランタイム階層 — 低レベルと高レベル

業界で「コンテナランタイム」と言うとき、二つの意味で使われる。

                  kubelet (CRI クライアント)
                       │
                       ▼
        ┌──────────────────────────────┐
        │  高レベルランタイム (CRI)     │
        │  containerd / CRI-O / cri-dockerd │
        └──────────────┬───────────────┘
                       │ (OCI runtime API)
                       ▼
        ┌──────────────────────────────┐
        │  低レベルランタイム (OCI)     │
        │  runc / crun / youki / runsc / kata-runtime │
        └──────────────────────────────┘

• 高レベルランタイム — イメージ pull、レイヤー unpack、ネットワーク・ボリュームのセットアップ、ライフサイクル管理。kubelet が CRI(Container Runtime Interface)で対話する相手はこれ。
• 低レベルランタイム — namespaces・cgroups・capabilities・seccomp・LSM の設定。config.json を受け取りプロセスを fork する。

containerd は高レベルだが既定で runc を呼ぶ。CRI-O は高レベルで既定は crun。誰かが「ランタイムを切り替える」と言うときは、どの階層を切り替えるのかを必ず明示してほしい。

3. runc 1.2 — リファレンスとなる OCI ランタイム

runc は、2015 年 6 月に Docker が OCI に寄贈したリファレンス低レベルランタイムである。Go で書かれ、libcontainer というライブラリを内包する。

2026 年 5 月の stable は 1.2.5。この 2 年の主な変更点。

• CRIU integration の安定化 — チェックポイント・復元がより滑らかに。
• idmapped mounts の既定有効化 — rootless コンテナ互換性が向上。
• systemd cgroup v2 の完全サポート。
• scheduling policy オプション追加 — SCHED_DEADLINE のようなリアルタイムスケジューラを指定可能。

runc は依然として最も広く使われている OCI ランタイムであり、Kubernetes ディストリビューションの大多数が既定値とする。ただし Go ランタイム起動コストのためコンテナ起動に 50〜80ms かかる点が欠点として頻繁に挙げられる。Function-as-a-Service ではこの 50ms も無視できない。

4. crun — Red Hat の C 実装、runc の約 2 倍速

crun は Red Hat が 2018 年に開始した OCI ランタイム。差別点は C で書かれていること — Go ランタイムの起動コストがない。

ベンチマークは環境次第だが、一般的には次の傾向がある。

• コンテナ起動時間:runc 比で約 50% 高速。
• メモリフットプリント:約 1/3。
• 依存:glibc 程度で済む。runc は Go ランタイムを含む。

OpenShift と Podman の既定 OCI ランタイムであり、CRI-O 1.31 の既定でもある。crun 1.20 以降は WebAssembly ハンドラを通じて WasmEdge・Wasmtime を直接起動する機能も入った。

5. youki — Rust で書き直された OCI ランタイム

youki は、日本の NTT データのエンジニア小松渉が 2021 年に開始した Rust ベースの OCI ランタイムである。2026 年 5 月の stable は 0.4.x。

採用理由は通常次の三つ。

• メモリ安全性 — Rust の borrow checker により、バッファオーバーフロー類のバグがコンパイル時に捕まる。
• 性能 — runc 比で約 30% 高速な起動。
• 組み込み可能 — libcontainer-rs として Rust ライブラリ化されており、他ツールから import 可能。

AWS Bottlerocket は一部ビルドで youki を採用し、日本の楽天や韓国の NHN Cloud でも実験的導入事例がある。youki はまだ自身を production-ready とは謳っていないが、SUSE Rancher 陣営が積極的にスポンサーしている。

6. containerd 2.0 — CNCF Graduated の標準

containerd は、Docker が 2017 年に CNCF に寄贈した高レベルランタイム。2.0 は 2024 年 9 月に GA、2026 年 5 月の stable は 2.1。

主な変化(2.0 基準)。

• Image Transfer Service — イメージ pull/push を別サービスに分離し、リトライと進捗監視が単純化。
• NRI(Node Resource Interface)2.0 — プラグインがコンテナ生成時点で hook を挟み、GPU・CPU pinning を動的に調整可能。
• Sandbox API が stable — Kata Containers や gVisor のような sandbox ランタイムの統合が標準 API として定着。
• runwasi shim を正式サポート — WebAssembly モジュールを runtime class として登録し実行可能。

Kubernetes 1.24 で dockershim が削除されてから、containerd は事実上のデフォルトになった。AWS EKS、Google GKE、Azure AKS、NHN Cloud K8s、KT Cloud K-PaaS-TA はいずれも containerd を既定とする。

7. CRI-O 1.31 — Kubernetes 専用の軽量ランタイム

CRI-O は、2016 年に Red Hat が開始した「Kubernetes のためだけの OCI ランタイム」である。2026 年 5 月の stable は 1.31。

containerd と比較するとポジショニングが異なる。

• containerd は Docker 用・K8s 用の両方を狙う。CRI-O は K8s CRI のみ。
• CRI-O は Kubernetes のマイナーバージョン(1.x)と 1 対 1 でリリースされる。K8s 1.31 → CRI-O 1.31。
• メモリフットプリントが小さく依存グラフが単純なため、OpenShift の既定値となっている。

2026 年に入った興味深い変更点。

• stream isolation — コンテナのログ・exec ストリームを別プロセスに分離し、OOM の波及を遮断。
• userns auto-mode — rootless コンテナ用の UID マッピングの自動化。
• WebAssembly runtime class の正式サポート。

Red Hat OpenShift 4.16 から既定は CRI-O であり、韓国の SK テレコム 5G MEC や日本の NTT ドコモのクラスタの一部も CRI-O を採用している。

8. Podman 5 — デーモンレス、ルートレス、そして Pod

Podman は、Red Hat が 2018 年に発表した「デーモンなしの Docker 代替」である。2026 年 5 月の stable は 5.4。

差別点。

• デーモンなし — podman run は fork-exec でコンテナを起動する。デーモンクラッシュのような単一障害点がない。
• ルートレス既定 — 一般ユーザ権限でコンテナ実行。user namespace + slirp4netns + fuse-overlayfs の組合せ。
• Pod 概念 — Kubernetes の Pod のように複数コンテナを束ねて単一の IP・ボリュームを共有。
• Docker CLI 互換 — alias docker=podman がほぼそのまま動く。
• podman kube generate — 実行中の Pod を Kubernetes YAML として export。

Buildah(ビルド専用)、Skopeo(イメージ検査・コピー)と合わせて Red Hat 生態系の三点セット。2026 年時点で Fedora・RHEL・Rocky Linux の既定コンテナツールは完全に Podman へ移行した。

Mac/Windows では Podman Desktop がシェアを急伸中。Docker Desktop の有料化に反発した企業ユーザの移行が多い。

9. Docker 27 — 依然として開発者ワークステーション 1 位

Docker Inc. は 2022 年 1 月から大企業向けに有料化を進めているが、開発者ワークステーションのシェアは依然最大である。2026 年 5 月の stable は Docker Engine 27.5、Docker Desktop 4.40。

2024〜2026 の主な変化。

• BuildKit 0.18 — 既定のビルダとして統合。キャッシュ・並列・remote builder のサポートが標準化。
• Docker Compose v2 — Python 実装の v1 を完全に置き換え。Go で再実装され docker compose サブコマンド。
• Docker Init — 新規プロジェクトの Dockerfile・compose・.dockerignore を自動生成。
• Wasm ランタイム統合(Tech Preview) — Wasmtime・WasmEdge を OCI 互換で実行。
• Docker Hub Personal/Pro/Team の分離 — pull rate limit がより厳格に。

大企業ユーザは Docker Desktop のライセンス費用を理由に Podman Desktop・Rancher Desktop・Orbstack(Mac)へ移行する例が多いが、個人開発者やスタートアップでは依然として Docker が 1 位だ。

10. gVisor — Google のユーザ空間カーネル

gVisor は、2018 年に KubeCon で Google が発表した「ユーザ空間カーネル」ベースの sandbox ランタイムである。核となる発想は — コンテナ内の syscall をホストカーネルが直接処理せず、Sentry というユーザ空間プロセスが横取りして必要分だけホストへ転送する。

   コンテナアプリ
        │ syscall
        ▼
   Sentry (gVisor ユーザ空間カーネル, Go)
        │ filtered subset
        ▼
   ホスト Linux カーネル

長所。

• 攻撃面の縮小 — コンテナ脱出 1-day が見つかっても Sentry が遮断する。
• OCI 互換 — runsc バイナリが OCI ランタイムインターフェースをそのまま実装。
• Linux 互換性 — 多くの syscall を模倣するため ELF バイナリがほぼそのまま動く。

短所。

• 性能オーバーヘッド — syscall heavy なワークロードでは 20〜50% 遅い。CPU bound にはほぼ影響なし。
• 一部 syscall 未実装 — io_uring のような新しい syscall は fallback が必要。

Google Cloud Run、App Engine Flexible、GKE Sandbox はいずれも gVisor 基盤。Fly.io Machines の一部ワークロードや、韓国の Naver Cloud のマルチテナント関数サービスでも採用されている。

11. Kata Containers 3 — VM 隔離・コンテナ UX

Kata Containers は、2017 年に Intel Clear Containers と Hyper.sh runV を統合して始まったプロジェクトである。2026 年 5 月の stable は 3.6。

要点 — 見た目はコンテナでも中身は本物の軽量仮想マシン。 Pod またはコンテナごとに別の KVM VM が立ち上がり、その中でコンテナプロセスが動く。

対応ハイパーバイザ。

• Firecracker — AWS の MicroVM、最も軽量。
• Cloud Hypervisor — Intel/Cloud Hypervisor コミュニティの Rust VMM。
• QEMU — 互換性が最も高く、最も重い。

2026 年時点の Kata 3.x の主な機能。

• VFIO-AP — IBM s390x で暗号カードのパススルー。
• Confidential Containers 統合 — AMD SEV-SNP・Intel TDX・IBM SE をサポート。
• runD shim 統合 — Alibaba Cloud が貢献した shim が containerd に取り込まれた。

採用先:Alibaba Cloud の ECI の一部、Yahoo! Japan、Microsoft Azure Container Instances の一部、GKE Sandbox(gVisor の代わりに Kata を選択可能)。

12. Firecracker 1.10 — AWS Lambda を支える MicroVM

Firecracker は、AWS が 2018 年の re:Invent で発表したミニマリスト VMM である。Rust で書かれ、KVM 上で動く。2026 年 5 月の stable は 1.10。

設計原則。

• 最小限のデバイスモデル — virtio-net、virtio-block、virtio-vsock、シリアルコンソールのみ。PCI もない。
• 125ms 未満の起動 — 5MB の microVM バイナリが 5MB のメモリで起動。
• REST API — 外部の fc-control plane が microVM を操作。

主な用途。

• AWS Lambda バックエンド — cold start を抑えるため。
• AWS Fargate の一部ワークロード。
• Fly.io Machines — グローバルエッジのコンテナを microVM で隔離。
• Kata Containers のハイパーバイザ選択肢。
• Northflank、Koyeb など新興 PaaS の隔離バックエンド。

Firecracker は直接使うより、その上に wrapper(Kata、Ignite、Firepilot)を載せるのが一般的である。

13. Cloud Hypervisor 42 — Rust 陣営のもう一つの VMM

Cloud Hypervisor は、Intel が 2018 年に開始したもう一つの Rust ベース VMM である。Firecracker と比べてより幅広いデバイスモデルをサポートする。2026 年 5 月の stable は 42。

Edera Protect — 2024 年に etcd 出身者が立ち上げたスタートアップ — は「GPU と confidential computing を同時にサポートする sandbox プラットフォーム」を Cloud Hypervisor 上に構築している。

14. WebAssembly ランタイム — runwasi shim で K8s に進入

2024 年に containerd が runwasi shim を正式サポートして以降、WebAssembly モジュールも OCI イメージとして Kubernetes にデプロイ可能になった。

代表的な Wasm ランタイム 3 つ(2026.5)。

WebAssembly コンテナの長所。

• 起動時間 < 1ms — 真の cold start が 1 ミリ秒未満。
• メモリ < 1MB — 関数あたり数十 KB。
• 言語非依存ポータビリティ — Rust・Go・C・Python(Pyodide)すべて可能。

短所。

• WASI 標準がまだ進化中 — ネットワーク・ファイルシステムがコンテナほど豊富でない。
• GPU・ハードウェアアクセス制限 — WASI-NN で推論はできるが、学習は困難。

Spin(Fermyon)・WasmCloud・Wasmer Edge のような Wasm-first PaaS がこの上で育っている。

15. Confidential Containers — メモリまで暗号化

Confidential Containers(CoCo)は、2022 年に開始した CNCF Sandbox プロジェクトで、2026 年後半に GA 予定。核心は — ホストカーネルやハイパーバイザですらコンテナメモリを読めない。

基盤ハードウェア。

• AMD SEV-SNP — Secure Encrypted Virtualization with Secure Nested Paging。
• Intel TDX — Trust Domain Extensions、2024 年の Xeon 第 5 世代から本格化。
• Arm CCA — Confidential Compute Architecture、2025 年の Neoverse V3 で一部対応。
• IBM Z SE — Secure Execution。

流れ。

1. Kata Container を起動する際、ハイパーバイザが SEV-SNP または TDX VM を作成。
2. attestation サーバが起動時の測定値を検証。
3. 検証通過後に secret を注入。

採用先:Azure Confidential Containers、IBM Cloud Hyper Protect、そして韓国・日本の金融コンプライアンスワークロード。Edera Protect は GPU ノードまで confidential 化する野心で進行中。

16. イメージ形式 — OCI v1.1 と zstd-chunked

2026 年 5 月時点のコンテナイメージ形式の主な進化。

• OCI image-spec 1.1 — 2024 年 GA。artifact manifest が正式サポートされ、Helm chart・SBOM・署名を同じレジストリに格納可能。
• OCI image-spec 1.2 RC — 圧縮アルゴリズム交渉を標準化、zstd-chunked を明示。
• zstd-chunked — Red Hat が貢献。partial pull が可能になり大規模イメージで大きな効果。1GB のイメージから変更された 80MB のみを受け取るシナリオが現実的に。
• ORAS(OCI Registry As Storage) — コンテナイメージ以外の任意ファイルも OCI レジストリに格納。Helm chart、Tekton task、AI モデル weights を docker.io や ghcr.io に push 可能。

Docker v2.2(legacy)イメージは deprecated 表示済みで、2026 年内に多くのレジストリで新規 push が遮断される予定。

17. ローカル開発 — Docker Desktop・Podman Desktop・Rancher Desktop・Orbstack 比較

Mac 開発者のあいだで 2025 年から最もよく聞かれる名前は Orbstack。独自実装の軽量ハイパーバイザにより、Docker Desktop 比でメモリ 1/3、起動時間 1/5 を謳う。

Linux 開発者には Desktop ツールは特に不要 — ネイティブで Podman または Docker Engine を入れれば済む。

18. CI 環境 — Sysbox・DinD・Kaniko

CI でコンテナをビルド・実行するときの「ホスト権限の露出」は長年の悩み。

• Docker-in-Docker(DinD) — docker:dind イメージを sidecar として立てる。最も簡単だが privileged コンテナが必要。
• Kaniko — Google 製のビルドツール。root 権限なしで Dockerfile をビルドして push。
• Buildah / podman build — rootless ビルドの標準。
• Sysbox — Nestybox(2022 年 Docker 買収)製のランタイム。コンテナ内で systemd・Docker を安全に動かせる。2026 年に Apache 2.0 でオープンソース化。
• BuildKit + rootless — 最も一般的な組合せ。

GitHub Actions・GitLab CI・Jenkins・Tekton のすべてが 2026 年に rootless ビルドを既定推奨へ移行した。

19. サーバーレス — Lambda Firecracker・Fly Machines・Cloud Run gVisor

サーバーレス/エッジ陣営の隔離バックエンドマッピング。

サーバーレスの隔離モデルは microVM と V8 isolate の二陣営に収束しつつある。コンテナは重すぎ、V8 isolate は Node.js・WASM に制限される、というトレードオフ。

20. 韓国・日本陣営 — 誰が何を使っているか

韓国

• NHN Cloud — containerd を既定、一部ノードで youki 実験。Confidential Container の PoC が進行中。
• KT Cloud — K-PaaS-TA 上で containerd。CRI-O オプションも提供。
• Naver Cloud — 独自コンテナサービス NCS に containerd、マルチテナント関数には gVisor。
• SK テレコム — 5G MEC の一部ノードで CRI-O、Confidential Container 導入計画。
• Samsung SDS — 社内 Brity Container Platform が containerd と Kata オプション。

日本

• NTT データ / NTT コミュニケーションズ — youki をスポンサー、CRI-O も一部導入。
• 楽天 — モバイル RAN のコンテナに containerd + Kata。
• サイバーエージェント — AKE(Adtech Container Engine)で containerd。
• ヤフー / LINE — マルチテナントの一部で Kata。
• AWS 東京 / GCP 東京 / Azure 東京 — グローバルと同一スタック。

注目すべきは youki が日本発のプロジェクトであり、日本のクラウド企業によるスポンサーが手厚いという点だ。

21. どのランタイムを選ぶか — 意思決定ツリー

質問 1. どの環境?
  ├─ Kubernetes クラスタ
  │    ├─ Red Hat 生態系? → CRI-O + crun
  │    └─ それ以外 → containerd + runc
  ├─ ローカル開発 (Mac)
  │    ├─ 速さ重視 → Orbstack
  │    ├─ オープンソース優先 → Podman Desktop
  │    └─ 互換性最優先 → Docker Desktop
  └─ ローカル開発 (Linux) → Podman または Docker Engine

質問 2. 隔離はどれくらい強く?
  ├─ 一般的な隔離 → runc / crun (namespaces + cgroups)
  ├─ マルチテナント SaaS → gVisor または Kata
  ├─ メモリも保護 → Confidential Containers (Kata + SEV-SNP/TDX)
  └─ 最速起動 → Firecracker MicroVM または Wasm

質問 3. ワークロード特性?
  ├─ FaaS / 短命関数 → Wasm (WasmEdge, Spin) または Firecracker
  ├─ 長時間稼働サービス → 通常コンテナ (containerd + runc)
  ├─ データ集約 → 通常コンテナ、syscall heavy なら gVisor を避ける
  └─ AI/ML 推論 → 通常コンテナ + GPU operator

22. むすび — 2026 年のランタイム風景

2026 年 5 月時点を整理すると次のとおり。

1. クラスタ標準は containerd 2.0 — Kubernetes ディストリビューション大多数の既定。
2. Red Hat 生態系は CRI-O + crun + Podman — OpenShift ユーザにとって一貫した選択。
3. ローカル開発は多様化 — Docker Desktop、Podman Desktop、Rancher Desktop、Orbstack が並走。
4. マルチテナントは gVisor または Kata — クラウド事業者によって異なる。
5. サーバーレスは Firecracker MicroVM または V8 isolate — コンテナは重すぎる。
6. Wasm が本格進入を開始 — runwasi shim のおかげで K8s に正規ルートで入れる。
7. Confidential Containers は 2026 年後半に GA 見込み — AMD SEV-SNP・Intel TDX が十分成熟。
8. youki・crun のような代替 OCI ランタイムが育ち中 — Rust・C 陣営が下から runc を揺さぶる。

ランタイム選択は「性能 vs 隔離 vs 互換性」の三角形である。唯一の答えはない。しかし本稿の地図を持っていけば、どの頂点に向かうかを 5 番目の質問あたりで決められるはずだ。

参考資料 (References)

1. Open Container Initiative — https://opencontainers.org/
2. OCI Runtime Specification — https://github.com/opencontainers/runtime-spec
3. OCI Image Specification — https://github.com/opencontainers/image-spec
4. OCI Distribution Specification — https://github.com/opencontainers/distribution-spec
5. runc — https://github.com/opencontainers/runc
6. crun — https://github.com/containers/crun
7. youki — https://github.com/youki-dev/youki
8. containerd — https://containerd.io/
9. CRI-O — https://cri-o.io/
10. Podman — https://podman.io/
11. Buildah — https://buildah.io/
12. Skopeo — https://github.com/containers/skopeo
13. Docker — https://www.docker.com/
14. BuildKit — https://github.com/moby/buildkit
15. gVisor — https://gvisor.dev/
16. Kata Containers — https://katacontainers.io/
17. Firecracker — https://firecracker-microvm.github.io/
18. Cloud Hypervisor — https://www.cloudhypervisor.org/
19. WasmEdge — https://wasmedge.org/
20. Wasmtime — https://wasmtime.dev/
21. Wasmer — https://wasmer.io/
22. runwasi — https://github.com/containerd/runwasi
23. Spin (Fermyon) — https://www.fermyon.com/spin
24. WasmCloud — https://wasmcloud.com/
25. Confidential Containers — https://github.com/confidential-containers
26. Edera Protect — https://edera.dev/
27. Kubernetes CRI — https://kubernetes.io/docs/concepts/architecture/cri/
28. Orbstack — https://orbstack.dev/
29. Rancher Desktop — https://rancherdesktop.io/
30. Sysbox — https://github.com/nestybox/sysbox