📦

【2026年1月】コンテナランタイム周辺の調査メモ：Docker以外に何があるのか、今どうなっているのか

2026/01/04に公開

この記事について

コンテナランタイムについて調べ直したのでメモを残します。

「コンテナランタイム」という言葉は文脈によって指すものが異なります。低レベルのOCI Runtime、高レベルのCRI Runtime、Docker/Podmanのようなエンジン全体。このあたりを整理しつつ、2026年1月時点の状況をまとめました。

コンテナ技術のレイヤー構造

コンテナ技術は大きく3層に分かれている。

ユーザー向けレイヤー

ユーザーが直接操作するツール群。docker run や podman build などのコマンドを提供する。

高レベルランタイム（CRI Runtime）

CRI（Container Runtime Interface）はKubernetesがコンテナランタイムと通信するための標準インターフェース。containerdやCRI-Oがこれを実装している。

低レベルランタイム（OCI Runtime）

OCI（Open Container Initiative）はコンテナの標準仕様を策定する団体。OCI Runtime Specに準拠したランタイムが実際にコンテナを起動する。

Linuxカーネル

namespaces: プロセス、ネットワーク、ファイルシステムなどを隔離するLinuxカーネルの機能
cgroups: CPU、メモリなどのリソース使用量を制限するLinuxカーネルの機能
seccomp: システムコール（カーネルへの命令）を制限するセキュリティ機構
SELinux: アクセス制御を強制するセキュリティモジュール

各レイヤーの役割

レイヤー	役割	具体例
コンテナエンジン / CLI	ユーザーインターフェース、イメージのpull/push/build、ネットワーク設定、ボリューム管理	Docker, Podman, nerdctl
高レベルランタイム (CRI)	コンテナのライフサイクル管理、イメージ取得、Kubernetes連携	containerd, CRI-O
低レベルランタイム (OCI)	コンテナの起動・停止、namespace/cgroups操作	runc, crun, gVisor, Kata

低レベルランタイム（OCI Runtime）

OCI標準

2015年にDocker社がOpen Container Initiative (OCI) を設立。コンテナ技術の標準化が目的。

OCI Runtime Specification: コンテナの起動・停止・管理の仕様
OCI Image Specification: コンテナイメージのフォーマット仕様

これにより、異なるランタイム間でもイメージやコンテナの互換性が保たれる。

主要なOCI Runtime：標準実装

runc

OCIのリファレンス実装（公式の参照実装）
多くの環境でデフォルトとして使われる代表的なOCI Runtime
Go言語で記述

主要なOCI Runtime：パフォーマンス重視

crun

Red Hat開発、C言語実装
runcより起動が速い傾向があり、リソース効率の観点で選ばれることがある

youki

Rust製、日本人開発者が主導
メモリ安全性重視（Rustの特性を活かしてメモリ関連のバグを防ぐ）
Podmanで利用可能
実験段階

主要なOCI Runtime：セキュリティ重視

gVisor (runsc)

Google開発
ユーザー空間でLinuxカーネルを再実装し、システムコール（アプリがカーネルに送る命令）を傍受・処理
カーネル脆弱性の影響を受けにくい
一部システムコール未実装など互換性の制約があり、ワークロードによってはオーバーヘッドが出る
Google Cloud Run、GKE Sandboxで使用されている

gVisorのアーキテクチャ

Sentry: ユーザー空間で動作する擬似カーネル。アプリからのシステムコールを受け取り、大部分を自前で処理する
Gofer: ファイルシステムへのアクセスを代理で行うプロセス

Kata Containers

各コンテナが独自カーネルを持つ軽量VM（microVM）として動作
ハードウェアレベルの隔離（VMと同等のセキュリティ）
強い分離が必要なワークロードでの選択肢になる
AWS Firecracker（Lambda基盤）も同様の思想
Confidential Computing（後述）と組み合わせる構成もある

通常のコンテナとKata Containersの違い

通常のコンテナ（runc）:

Kata Containers:

通常のコンテナは1つのカーネルを共有するが、Kata Containersは各コンテナが独自のカーネルを持つ。

選択基準

要件	選択肢
特になし	runc
起動速度・リソース効率	crun
マルチテナント・セキュリティ強化	gVisor
最高レベルの分離	Kata Containers
Rust・特定のエコシステム	youki

高レベルランタイム（CRI Runtime）

KubernetesとCRIの経緯

Kubernetesは当初Dockerに直接依存していたが、柔軟性のためCRI（Container Runtime Interface）を導入した。

dockershim: KubernetesがDockerと通信するためのアダプター。CRI導入後は不要になり削除された。

dockershim削除前のアーキテクチャ

kubelet（Kubernetesのノードエージェント）がdockershimを経由してDockerを呼び出し、さらにcontainerdを経由するという冗長な構成だった。

dockershim削除後のアーキテクチャ

kubeletがcontainerdまたはCRI-Oと直接通信する構成になった。

containerd

元Dockerの内部コンポーネント、CNCF（Cloud Native Computing Foundation）に寄贈
v2.0でメジャーアップデート（設定フォーマットの見直し等）
GKE、EKS、AKS等のマネージドKubernetesで使用
Kubernetesで広く使われているCRI Runtimeの一つ

gRPC: Googleが開発した高速なRPC（リモートプロシージャコール）フレームワーク
CNI: Container Network Interface。コンテナのネットワーク設定を行う標準インターフェース
スナップショット: ファイルシステムの差分を効率的に管理する仕組み

containerd 2.x（設定まわりの要点）

containerdは設定ファイルにバージョンがあり、2.xではversion = 3が推奨。

Version 3（containerd 2.xで推奨）: containerd 2.0で導入。プラグインIDなどが一部変更
Version 2（containerd 1.xで推奨）: containerd 1.3で導入。2.xでもサポート
Version 1（デフォルト）: containerd 1.0で導入。containerd 2.0で削除

また、NRI（Node Resource Interface）などの機能は「利用できる機能」として把握し、実際に有効化されるか・既定値がどうかは導入環境と設定で確認するのが安全。

CRI-O

Red Hat主導
Kubernetes専用設計、最小限の機能
Kubernetesリリースサイクルと同期
OpenShift（Red HatのKubernetesディストリビューション）で標準使用

containerdとCRI-Oの比較

観点	containerd	CRI-O
汎用性	Kubernetes以外でも使用可	Kubernetes専用
機能	多機能	最小限
採用	マネージドK8sの大半	OpenShift中心
アタックサーフェス	標準的	小さい（機能が少ない分、攻撃対象も少ない）

RuntimeClass

Kubernetes 1.14で導入。Pod単位でランタイムを選択可能。

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: gvisor
handler: runsc
---
apiVersion: v1
kind: Pod
metadata:
  name: untrusted-workload
spec:
  runtimeClassName: gvisor
  containers:
    - name: app
      image: nginx

用途別のランタイム選択例

コンテナエンジン / CLI

Docker Desktop有料化

2021年8月にライセンス変更。従業員250人以上または年間売上1,000万ドル以上の企業は有料。個人・小規模企業・教育・OSSは無料継続。

主要なコンテナエンジン

デスクトップ向けGUI

CLI

バックエンド

Docker Engine / Docker Desktop

dockerd: Docker Daemon。常駐プロセスとしてコンテナを管理する
BuildKit: 次世代のイメージビルドエンジン
エコシステムが充実、ドキュメントが豊富
Docker EngineはApache 2.0ライセンスのOSS

Podman

デーモンレスアーキテクチャ。各コンテナが独立したプロセスとして動作。

Dockerの場合

Podmanの場合

デーモンレス: 常駐プロセスが不要。dockerdのような単一障害点がない
conmon: Container Monitor。各コンテナの監視プロセス

コンポーネント

コンポーネント	役割
podman	メインCLI、Docker互換コマンド
conmon	コンテナごとの監視プロセス
crun	デフォルトOCIランタイム
Buildah	イメージビルドツール
Skopeo	イメージ転送・検査ツール
Podman Desktop	GUIツール

Pod機能

KubernetesのPod（複数コンテナをグループ化する単位）と同じ概念をローカルで再現できる。

# Podを作成
podman pod create --name myapp -p 8080:80

# Podにコンテナを追加
podman run -d --pod myapp nginx
podman run -d --pod myapp redis

# Kubernetes用YAMLを生成
podman generate kube myapp > myapp.yaml

# YAMLからPodを起動
podman play kube myapp.yaml

Rootless

設計段階からRootless前提。コンテナ内rootはホスト上の非特権ユーザーにマッピング。

コンテナ内でrootとして動作しても、ホスト上では一般ユーザー権限。万が一コンテナから脱出されてもホストのroot権限は奪われない。

Quadlet

Podman 4.4以降。systemd（Linuxのサービス管理システム）のユニットファイルとしてコンテナを管理。

# ~/.config/containers/systemd/nginx.container
[Container]
Image=docker.io/nginx:latest
PublishPort=8080:80

[Service]
Restart=always

[Install]
WantedBy=default.target

採用状況

RHEL系を中心に標準ツールとして採用されることが多い
Podman Desktopのプロジェクト区分（CNCF等）は都度公式発表を要確認

nerdctl

containerd用Docker互換CLI。

機能	説明
Docker CLIと同じコマンド体系	学習コストが低い
Compose対応	docker-compose.ymlがそのまま使える
lazy-pulling	eStargz形式によりイメージ全体をダウンロードせずにコンテナを起動可能
暗号化イメージ	OCICryptによるイメージの暗号化に対応
Wasmネイティブサポート	WebAssemblyをコンテナとして実行可能

Rancher Desktop、Lima、Finchで使用されている。

Colima

macOS向け軽量ツール。Lima（Linux virtual machine）ベース。

brew install colima docker
colima start
colima start --runtime containerd
colima start --cpu 4 --memory 8 --disk 100
colima start --kubernetes

OrbStack

macOS専用、パフォーマンス特化。

特徴	説明
起動約2秒	Docker Desktopより高速
動的メモリ管理	使用量に応じてメモリを確保・解放
ドメインアクセス	`container-name.orb.local` でコンテナにアクセス可能
Docker互換	Docker CLI、Composeがそのまま動作
価格	有料（個人は無料）

Rancher Desktop

特徴	説明
ランタイム選択	containerd/dockerdを切り替え可能
Kubernetes統合	k3s（軽量Kubernetes）によるローカルK8s環境

LXC / LXD (Incus)

システムコンテナ。Docker/Podmanの「アプリケーションコンテナ」とは異なる。

観点	アプリケーションコンテナ	システムコンテナ
起動対象	単一プロセス	完全なOS（init含む）
用途	マイクロサービス	VM代替、開発環境
ライフサイクル	短命（使い捨て）	長寿命（アップデートして使い続ける）

2023年にCanonicalの方針変更によりIncusがフォーク。

機能比較

機能	Docker	Podman	nerdctl	LXD
Rootless	後付け対応	設計時から対応	対応	限定的
デーモンレス	×	○	○	×
Pod	×	○	○	×
Compose	○	○	○	×
K8s YAML生成	×	○	○	×
systemd統合	限定的	Quadlet	限定的	○

選択基準：macOS

選択基準：Linux

選択基準：Windows

イメージビルドツール

統合型

スタンドアロン

転送・検査

BuildKit

Docker 18.09以降に搭載された次世代ビルドエンジン。

機能	説明
並列ビルド	DAG（有向非巡回グラフ）に基づいて依存関係のないステップを並列実行
効率的なキャッシュ	レイヤー単位でキャッシュを再利用
シークレットマウント	秘密情報をビルド時のみ利用可能にし、イメージには含めない
SSHエージェント転送	SSH鍵をイメージに残さずにプライベートリポジトリからクローン可能
マルチプラットフォーム	複数アーキテクチャ（amd64、arm64等）向けに同時ビルド

# syntax=docker/dockerfile:1
FROM golang:1.21

# シークレットマウント：ビルド時のみ利用可能
RUN --mount=type=secret,id=github_token \
    GITHUB_TOKEN=$(cat /run/secrets/github_token) \
    go get private-repo.com/pkg

# キャッシュマウント：ビルドキャッシュを永続化
RUN --mount=type=cache,target=/root/.cache/go-build \
    go build -o /app

Buildah

Red Hat製のイメージビルド専用ツール。

特徴	説明
デーモン不要	dockerdなしでビルド可能
Dockerfileなし	シェルスクリプト的にイメージを構築可能
中間イメージなし	ディスク効率が良い

container=$(buildah from fedora)
buildah run $container dnf install -y nginx
buildah config --cmd "/usr/sbin/nginx -g 'daemon off;'" $container
buildah commit $container my-nginx

Kaniko

Kubernetes環境向けビルドツール。Googleがメンテナンスしているが、近年はBuildKitやkoの利用が拡大している。ただし、特権を持たない特定のCI環境では依然として重要な選択肢である。

特徴	説明
特権不要	Docker daemonやroot権限なしでビルド
K8sネイティブ	Kubernetesのジョブとして実行可能

apiVersion: v1
kind: Pod
metadata:
  name: kaniko-build
spec:
  containers:
  - name: kaniko
    image: gcr.io/kaniko-project/executor:latest
    args:
    - "--dockerfile=Dockerfile"
    - "--context=git://github.com/myrepo/myapp"
    - "--destination=myregistry.com/myapp:latest"

ko

Go専用ビルドツール。

# Dockerfileなしでビルド＆プッシュ
ko build ./cmd/myapp

# Kubernetesマニフェストに直接埋め込んでデプロイ
ko apply -f deployment.yaml

GoのソースコードからDockerfileを書かずに直接コンテナイメージを生成できる。

Skopeo

イメージの転送・検査専用ツール。

# レジストリ間でイメージをコピー（ローカルにpull不要）
skopeo copy docker://docker.io/nginx docker://myregistry.com/nginx

# イメージのメタデータを確認（pull不要）
skopeo inspect docker://docker.io/nginx

# マルチアーキテクチャのマニフェストを確認
skopeo inspect --raw docker://nginx | jq

ここ数年の流れ

時系列

現在の市場

※利用状況の割合は出典により大きく変動するため、本記事では断定的な割合は置かない。

領域	主な選択肢	理由
本番Kubernetes	containerd	軽量・高速、CNCF標準
開発環境	Docker	エコシステム、ドキュメント
セキュリティ重視	Podman	Rootless・デーモンレス
OpenShift	CRI-O	Red Hat標準

セキュリティランタイムのレベル

レベル	ランタイム	ユースケース
標準	runc	一般ワークロード
強化	gVisor	マルチテナント
最強	Kata	金融・医療
機密	Confidential Containers	AI/ML機密データ

Confidential Computing: ハードウェアレベルでメモリを暗号化し、クラウド事業者でさえもデータにアクセスできないようにする技術。Intel SGX、AMD SEV、ARM CCAなどが対応。NVIDIAがKata Containers + Confidential ContainersでGPUワークロード保護を進めている。

WebAssembly（Wasm）

コンテナの次世代技術として注目されている。

観点	コンテナ	WebAssembly
サイズ	数百MB〜GB	KB〜数MB
起動時間	数百ms	数ms
隔離方式	OS namespace	サンドボックスVM
ポータビリティ	OS/アーキテクチャ依存	完全ポータブル
言語	制限なし	Rust, Go, C/C++等

WASI: WebAssembly System Interface。ファイルやネットワークなどのシステムリソースにアクセスするための標準API
WASI 0.2（Component Model/WIT 系）などの動きが進んでいる

プロジェクト	状況
wasmCloud	継続的に開発が進む（プロジェクト区分は要確認）
containerd	Wasmサポート追加（実験的）

eBPF

eBPF（extended Berkeley Packet Filter）がコンテナのネットワーキング・可観測性で標準化。

eBPF: カーネル内でプログラムを実行できる技術。ネットワーク処理やセキュリティ監視を高速に行える
iptables: 従来のLinuxファイアウォール/パケット処理機構。ルールが複雑になると性能が低下

Cilium、CalicoなどのCNIプラグインがiptablesの代替としてeBPFを使用。

今後について

トレンド

トレンド	内容
マルチランタイム	runc/gVisor/Kata/Wasmの併用が標準化
Confidential Computing	AI/MLでハードウェア暗号化が標準化
WebAssembly	エッジ・サーバーレスでコンテナの代替
サプライチェーンセキュリティ	イメージ署名、SBOM、attestationが必須化

SBOM: Software Bill of Materials。ソフトウェアの部品表。含まれるライブラリやその依存関係を一覧化したもの
attestation: 証明。ビルド環境やプロセスが改ざんされていないことを検証可能にする仕組み

開発環境

本番K8s

エッジ/サーバーレス

OCI Runtime

まとめ

標準化完了: OCI/CRIでコンポーネント交換可能
棲み分け: 開発はDocker、本番はcontainerd、セキュリティはPodman
セキュリティ選択肢: Rootless → gVisor → Kata → Confidential Computing
次世代移行: Wasmがエッジ・サーバーレスから浸透
可観測性進化: eBPFによるカーネルレベル監視が標準化

ユースケース	構成
スタートアップ・個人	Docker Desktop / Colima
エンタープライズ開発	Podman + Podman Desktop
本番Kubernetes	containerd
マルチテナントSaaS	containerd + gVisor
金融・医療	containerd + Kata Containers
エッジ・IoT	WebAssembly
AI/ML機密処理	Kata + Confidential Containers

この記事について

目次

コンテナ技術のレイヤー構造

ユーザー向けレイヤー

高レベルランタイム（CRI Runtime）

低レベルランタイム（OCI Runtime）

Linuxカーネル

各レイヤーの役割

低レベルランタイム（OCI Runtime）

OCI標準

主要なOCI Runtime：標準実装

runc

主要なOCI Runtime：パフォーマンス重視

crun

youki

主要なOCI Runtime：セキュリティ重視

gVisor (runsc)

Kata Containers

選択基準

高レベルランタイム（CRI Runtime）

KubernetesとCRIの経緯

dockershim削除前のアーキテクチャ

dockershim削除後のアーキテクチャ

containerd

containerd 2.x（設定まわりの要点）

CRI-O

containerdとCRI-Oの比較

RuntimeClass

コンテナエンジン / CLI

Docker Desktop有料化

主要なコンテナエンジン

デスクトップ向けGUI

CLI

バックエンド

Docker Engine / Docker Desktop

Podman

コンポーネント

Pod機能

Rootless

Quadlet

採用状況

nerdctl

Colima

OrbStack

Rancher Desktop

LXC / LXD (Incus)

機能比較

選択基準：macOS

選択基準：Linux

選択基準：Windows

イメージビルドツール

統合型

スタンドアロン

転送・検査

BuildKit

Buildah

Kaniko

ko

Skopeo

ここ数年の流れ

時系列

現在の市場

セキュリティランタイムのレベル

WebAssembly（Wasm）

eBPF

今後について

トレンド

開発環境

本番K8s

エッジ/サーバーレス

OCI Runtime

まとめ

参考リンク

Discussion