Docker「OCI runtime create failed」エラーの解決方法【2026年最新版】

Dockerコンテナを起動しようとした際に「Error response from daemon: OCI runtime create failed」というエラーメッセージが表示されて困っていませんか？この記事では、2026年最新の情報をもとに、このエラーの原因と具体的な解決方法を徹底解説します。初心者から上級者まで、段階的に対処できるようまとめていますので、ぜひ最後までご覧ください。

このエラーとは？発生する症状
このエラーが発生する原因
解決方法1: エラーメッセージの読み方と実行ファイルの問題を修正する（推奨）
解決方法2: パーミッション・セキュリティポリシーの修正
解決方法3: Docker/runcのアップグレードとcgroup設定の修正（上級者向け）
エラーを予防するには
まとめ
参考資料

このエラーとは？発生する症状

「OCI runtime create failed」は、Docker（またはPodman等のOCI準拠コンテナランタイム）がコンテナを作成・起動しようとした際に、低レベルのコンテナランタイムであるruncがコンテナプロセスを開始できなかったことを示すエラーです。OCI（Open Container Initiative）とは、コンテナの標準仕様を策定する業界団体であり、Dockerはこの仕様に準拠したランタイムを使用してコンテナを管理しています。

このエラーが発生すると、ターミナルには以下のようなメッセージが表示されます：

docker: Error response from daemon: OCI runtime create failed:
container_linux.go:380: starting container process caused: exec: "python":
executable file not found in $PATH: unknown.

または

Error response from daemon: failed to create shim: OCI runtime create failed:
runc create failed: unable to start container process: error during container init:
error mounting "proc" to rootfs at "/proc": permission denied

このエラーが発生すると、コンテナが一切起動しない状態になります。docker runコマンドを実行しても即座にエラーが返され、コンテナ内のアプリケーションにアクセスすることができません。開発環境だけでなく、本番環境のCI/CDパイプライン（CircleCI、GitHub Actions等）やKubernetesクラスタ上でも発生するため、デプロイがブロックされる深刻な問題です。

特に厄介なのは、エラーメッセージが長く複雑で、根本原因がすぐに分かりにくい点です。しかし、実はエラーメッセージの中の「caused:」以降の部分に重要なヒントが隠されています。この記事では、そのヒントの読み方と、パターンごとの解決方法を詳しく解説します。

このエラーが発生する原因

「OCI runtime create failed」エラーには、大きく分けて以下の5つの原因があります。それぞれのパターンを理解することで、エラーメッセージから素早く原因を特定できるようになります。

原因1: 実行ファイルが見つからない（executable file not found in $PATH）

最も多い原因の1つです。DockerfileのENTRYPOINTやCMDで指定した実行ファイルが、コンテナイメージ内の$PATHに存在しない場合に発生します。具体的には以下のケースが該当します：

コマンド名のタイプミス（例：pytohnと記述してしまった）
ベースイメージにそもそもコマンドが含まれていない（例：alpineイメージにbashが入っていない）
マルチステージビルドで最終イメージにバイナリをコピーし忘れた
WORKDIRが正しく設定されておらず、スクリプトのパスが解決できない

原因2: パーミッション・権限の問題（permission denied）

コンテナの起動プロセスがファイルやディレクトリへのアクセス権限を持っていない場合に発生します。主なケースは以下の通りです：

エントリポイントスクリプトに実行権限（chmod +x）が付与されていない
ホストマシンのSELinuxやAppArmorがコンテナのファイルアクセスをブロックしている
バインドマウントされたボリュームのラベリングが不適切
/var/lib/docker配下のファイル所有権が壊れている

原因3: Dockerやruncのバージョンが古い

Docker Engine、containerd、runcのバージョンが古いと、最新のカーネル機能との互換性問題が発生します。特にDockerバージョン25未満を使用している場合、最新のLinuxディストリビューション上で問題が起きることが報告されています。また、ホストOSのアップグレード（例：Proxmox VE 8.1→8.2）後にDockerのランタイムとの互換性が崩れるケースもあります。

原因4: cgroup v2との互換性問題

最近のLinuxディストリビューション（Ubuntu 22.04以降、Fedora 31以降等）では、cgroup v2がデフォルトで有効になっています。古いバージョンのDockerやruncはcgroup v2に対応しておらず、以下のようなエラーが発生します：

OCI runtime create failed: runc create failed: unable to start container process:
error during container init: error setting cgroup config for procHooks process

cgroup v2を使うには、カーネル4.15以上（推奨は5.2以上）が必要です。

原因5: ディスク容量不足・リソース競合

Dockerイメージやコンテナが消費するディスク領域が不足している場合、no space left on deviceというメッセージとともにこのエラーが発生します。また、既に使用されているポートやディレクトリとの競合も原因になることがあります。

解決方法1: エラーメッセージの読み方と実行ファイルの問題を修正する（推奨）

最も重要かつ効果的なアプローチは、エラーメッセージを正確に読み解くことです。このエラーの場合、caused: 以降に具体的な失敗理由が記載されています。

手順1: エラーメッセージを分析する

まず、エラーメッセージを注意深く確認します。以下は典型的なエラーメッセージの構造です：

Error response from daemon: OCI runtime create failed:
container_linux.go:380: starting container process caused:
exec: "python": executable file not found in $PATH: unknown

この場合、caused: の後に exec: "python": executable file not found in $PATH と記載されています。これは「python」というコマンドがコンテナ内のPATHに見つからないことを意味しています。

手順2: Dockerfileを確認・修正する

エラーの原因が実行ファイル関連の場合、Dockerfileを以下の点で確認してください：

# 悪い例：alpineイメージにはpythonが含まれていない
FROM alpine:latest
CMD ["python", "app.py"]

# 良い例：Python公式イメージを使用
FROM python:3.12-slim
COPY app.py /app/
WORKDIR /app
CMD ["python", "app.py"]

bashが見つからないエラーの場合（Alpine Linuxベースのイメージでよく発生）：

# 悪い例
RUN /bin/bash -c "echo hello"

# 良い例：Alpineにはashが標準搭載
RUN /bin/sh -c "echo hello"

# または、bashをインストールする
RUN apk add --no-cache bash

手順3: コンテナ内のファイルを確認する

イメージを対話的に起動して、ファイルの存在を確認できます：

# シェルを指定してコンテナに入る
docker run --rm -it --entrypoint /bin/sh myimage:latest

# PATH内のコマンドを確認
which python
echo $PATH
ls -la /app/

注意点

マルチステージビルドを使用している場合、最終ステージに必要なバイナリがすべてコピーされているか確認してください
ENTRYPOINTとCMDの両方が設定されている場合、それらがどのように組み合わされるか（exec形式 vs shell形式）を確認してください
DockerfileのCOPY命令でファイルが正しくコピーされているか、.dockerignoreで除外されていないかも確認しましょう

解決方法2: パーミッション・セキュリティポリシーの修正

エラーメッセージに「permission denied」が含まれている場合は、権限やセキュリティポリシーに起因する問題です。

エントリポイントスクリプトの実行権限を付与する

# ローカルでスクリプトに実行権限を付与
chmod +x entrypoint.sh

# Dockerfile内で権限を付与
COPY entrypoint.sh /app/
RUN chmod +x /app/entrypoint.sh
ENTRYPOINT ["/app/entrypoint.sh"]

SELinux環境での対処

SELinuxが有効な環境（RHEL、CentOS、Fedora等）では、コンテナがホストのファイルにアクセスする際にポリシーによってブロックされることがあります。

# SELinuxの状態を確認
sestatus

# SELinux関連の拒否ログを確認
sudo ausearch -m avc -ts recent

# 方法1: ボリュームマウント時に:zまたは:Zサフィックスを付与（推奨）
docker run -v /host/data:/container/data:z myapp:latest

# 方法2: デバッグ用にSELinuxラベルを無効化（本番非推奨）
docker run --security-opt label=disable myapp:latest

:zサフィックスはボリュームを複数のコンテナで共有可能にし、:Zはそのコンテナ専用にラベリングします。本番環境では必ず:zまたは:Zを使用し、label=disableは避けてください。

AppArmor環境での対処

Ubuntu等でAppArmorが有効な場合も同様の問題が発生します。特に、2025年11月のcontainerd.io 1.7.28-2のセキュリティパッチ以降、ネストされたLXCコンテナ内でDockerを実行する際にAppArmor関連のエラーが増加しています。

# デバッグ用にAppArmorプロファイルを無効化（本番非推奨）
docker run --security-opt apparmor=unconfined myapp:latest

# AppArmorの状態を確認
sudo aa-status

ファイル所有権の修正

# /var/lib/dockerの所有権を確認
ls -la /var/lib/docker/

# 必要に応じてDockerデーモンを再起動
sudo systemctl restart docker

解決方法3: Docker/runcのアップグレードとcgroup設定の修正（上級者向け）

バージョンの互換性やカーネル設定に起因する問題は、より深いレベルでの対処が必要です。

Docker Engineのアップグレード

Docker 25以上にアップグレードすることで、多くの互換性問題が解決します。

# 現在のDockerバージョンを確認
docker version

# Ubuntu/Debianの場合：Dockerの公式リポジトリからアップグレード
sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# CentOS/RHELの場合
sudo yum update docker-ce docker-ce-cli containerd.io

runcの個別アップグレード

runcだけをアップグレードすることも可能です：

# runcのバージョン確認
runc --version

# 最新版のruncをインストール（GitHubリリースから）
wget https://github.com/opencontainers/runc/releases/download/v1.2.5/runc.amd64
sudo install -m 755 runc.amd64 /usr/local/sbin/runc

cgroup v2の互換性対応

cgroup v2に関連するエラーが発生している場合：

# 現在のcgroupバージョンを確認
stat -fc %T /sys/fs/cgroup/
# "cgroup2fs"と表示されればv2が有効

# カーネルバージョンを確認（5.2以上推奨）
uname -r

方法A: Docker daemonの設定を変更する

# /etc/docker/daemon.jsonを編集
sudo tee /etc/docker/daemon.json <<EOF
{
  "default-cgroupns-mode": "host",
  "exec-opts": ["native.cgroupdriver=systemd"]
}
EOF

# Dockerを再起動
sudo systemctl daemon-reload
sudo systemctl restart docker

方法B: cgroup v1にフォールバックする（非推奨だが緊急時に有効）

GRUBの起動パラメータに以下を追加することで、cgroup v1を強制できます：

# /etc/default/grubを編集
GRUB_CMDLINE_LINUX="systemd.unified_cgroup_hierarchy=0"

# GRUBを更新して再起動
sudo update-grub
sudo reboot

ディスク容量の確認と解放

# Dockerが使用しているディスク容量を確認
docker system df

# 未使用のイメージ、コンテナ、ボリュームを一括削除
docker system prune -a --volumes

# 特定のダングリングイメージを削除
docker image prune

systemdサービスの設定確認

一部の環境では、Dockerのsystemdユニットファイルの設定が問題になります：

# Dockerサービスのユニットファイルを確認
sudo systemctl cat docker.service

# MountFlags=slaveが設定されている場合は削除
sudo systemctl edit docker.service
# [Service]
# MountFlags=

# 設定を反映
sudo systemctl daemon-reload
sudo systemctl restart docker

エラーを予防するには

「OCI runtime create failed」エラーを未然に防ぐために、以下のベストプラクティスを実践しましょう。

1. Dockerfileのベストプラクティスに従う

公式イメージをベースにする
マルチステージビルドでは最終ステージに必要なファイルが揃っているか確認する
ENTRYPOINTとCMDの違いを正しく理解して使い分ける
.dockerignoreファイルを適切に設定する

2. ローカルでの事前テストを徹底する

# ビルドしたイメージが正しく起動するかローカルでテスト
docker build -t myapp:test .
docker run --rm myapp:test

3. Docker環境を最新に保つ

Docker Engine、containerd、runcを定期的にアップデートしましょう。特にセキュリティパッチが含まれるマイナーアップデートは速やかに適用することを推奨します。

4. ディスク容量を定期的に監視する

# cronで定期的にディスク使用量をチェック
docker system df
# 未使用リソースの定期クリーンアップ
docker system prune -f --filter "until=168h"

5. CI/CDパイプラインでのDockerバージョン固定

CI/CDでDockerを使用する場合、Dockerのバージョンをピンすることで予期しない互換性問題を防ぎます。

まとめ

Dockerの「OCI runtime create failed」エラーは、一見複雑に見えますが、エラーメッセージのcaused:以降を注意深く読むことで、原因の特定は比較的容易です。

主要な対処ポイントをまとめると：

実行ファイルが見つからない場合 → DockerfileのENTRYPOINT/CMDを確認し、正しいパスとコマンドを指定する
パーミッションエラーの場合 → スクリプトの実行権限、SELinux/AppArmorの設定を確認する
バージョン互換性の問題の場合 → Docker、runc、カーネルを最新バージョンにアップグレードする
cgroup関連の問題の場合 → daemon.jsonでcgroup設定を調整する
ディスク容量不足の場合 → docker system pruneで不要なリソースをクリーンアップする

もしこの記事の方法で解決できない場合は、以下を試してみてください：

Docker公式フォーラム（forums.docker.com）に質問を投稿する
GitHubのmoby/mobyリポジトリでIssueを検索する
docker infoとdocker versionの出力を添えてStack Overflowに質問する

エラーメッセージの全文をコピーして検索することが、最も効率的な解決の第一歩です。