runc（ランシー）

2025年11月5日

runc（ランシー）

英語表記: runc

概要

runcは、コンテナ技術におけるデファクトスタンダードであるOCI (Open Container Initiative) の仕様に完全に準拠した、コンテナランタイムの参照実装です。非常に軽量で、Go言語で書かれた単一の静的バイナリとして提供されています。このツールは、Dockerエコシステムにおいて、実際にコンテナを起動、停止、削除するという最も低レベルな実行タスクを担う、心臓部とも言える存在です。runcの存在のおかげで、DockerエンジンはOSのカーネル機能（cgroupsやnamespaces）を直接操作することなく、標準化された方法でコンテナを実行できるのです。

詳細解説

runcを理解する上で重要なのは、「コンテナ技術（Docker, Podman） → Docker エコシステム → Docker エンジン」という文脈における、その役割の特定です。Dockerエンジンは、ユーザーからのコンテナ操作の指示を受け付けますが、その指示を実際のOSレベルでの操作に変換する部分を、runcが担当しています。

目的と背景：標準化の担い手

かつて、Dockerが急速に普及し始めた頃、コンテナの実行方法には様々なバリエーションが存在していました。しかし、コンテナ技術がインフラの核となるにつれて、「どのツールを使っても、同じ方法でコンテナが実行されるべきだ」という標準化のニーズが高まりました。これを受けて設立されたのがOCI（Open Container Initiative）です。

runcは、このOCIが定めた「ランタイム仕様（Runtime Specification）」に準拠した最初の実装として開発され、後にDockerプロジェクトから独立してOCIに寄贈されました。これが非常に画期的な出来事だったのです。

runcの最大の目的は、OCI仕様に完全に準拠することです。これにより、Dockerエンジンは、runcという標準化されたインターフェースを通じてのみコンテナを管理すればよくなり、異なるOSや異なるコンテナ管理ツール間での互換性が飛躍的に向上しました。もしruncがなければ、Dockerエンジン自身がOSのカーネル機能と密接に結合し続けなければならず、柔軟性に欠けていたことでしょう。

Dockerエンジン内部での位置づけ

Dockerエンジンは、一般的にユーザーが直接操作する高レベルなインターフェース（docker runなどのコマンド）を提供しています。しかし、その裏側では、処理が複数のコンポーネントに分担されています。

Dockerデーモン: ユーザーからのコマンドを受け付けます。
containerd: デーモンからの指示を受けて、イメージ管理やコンテナのライフサイクル管理を行います。これは「コンテナの監督者」のような存在です。
runc: containerdから「この設定でコンテナを起動せよ」という具体的な指示を受け取り、実際にOS上でコンテナプロセスを生成します。

runcは、設定ファイル（OCI仕様に基づいたconfig.json）を読み込み、その設定に従ってLinuxカーネルのcgroups（リソース制限）やnamespaces（分離）といった低レベルな分離機能を利用して、新しいプロセスを起動します。runcは、起動に必要な処理が完了すると、そのコンテナプロセスを監督者であるcontainerdに引き渡し、自身の役目を終えます。この「仕事をしたらすぐに退場する」というシンプルさが、runcの軽量性と信頼性の源泉となっています。

低レイヤーの実行者

runcは、ネットワーク設定やボリュームマウントといった高度な機能自体を提供するわけではありません。その役割はあくまで、指定された環境とリソース制限の下で、アプリケーションのプロセスを安全かつ標準的に実行することに徹しています。この徹底した役割分担こそが、現代のコンテナ技術の安定性を支えていると言えるでしょう。

具体例・活用シーン

runcは一般ユーザーが直接操作することはほとんどありませんが、その役割を理解することで、Dockerエンジンの動作原理がクリアになります。

1. 動作フローの理解

ユーザーがdocker run <イメージ名>を実行すると、Dockerエンジン内部では以下のような流れでruncが利用されます。

Dockerデーモンがリクエストを受け取る。
containerdがイメージを準備し、OCI仕様に準拠した設定ファイル（config.json）を作成する。
containerdが、この設定ファイルを指定してruncを起動する。
runcは設定を読み込み、OSのカーネル機能（cgroups, namespaces）を操作して、コンテナとなる新しいプロセス（アプリケーション本体）を生成する。
プロセスが起動したら、runcはcontainerdに制御を返し、自身は終了する。

2. コンテナ造船所のアナロジー

runcの役割を理解するために、コンテナ船を扱う巨大な造船所をイメージしてみましょう。

Dockerエンジン（造船所の経営者）: 顧客（ユーザー）から「この設計図（Dockerfile）で船（コンテナ）を作ってほしい」という注文を受け付け、全体のスケジュール管理をします。
containerd（現場監督）: 経営者からの指示を受け、設計図に基づいた具体的な作業指示書（OCI設定ファイル）を作成し、必要な資材（イメージレイヤー）を準備します。
runc（熟練の職人／溶接ロボット）: 現場監督から渡された作業指示書に従い、実際に鉄骨を溶接し、船体（分離されたプロセス）を組み上げ、決められた区画（名前空間）に正確に配置します。

runcは、この「実際に手を動かし、物理的な作業（OSカーネル操作）を行う」職人です。彼らは、国際規格（OCI仕様）に厳密に従って作業を行うため、世界中のどの造船所（コンテナランタイム）で作られた船であっても、同じ品質と安全基準が保証されるのです。runcは、余計なことをせず、ただひたすら「実行」というタスクに集中する、真面目で重要な職人だと思っていただければ分かりやすいかと思います。

3. OCI互換性の保証

runcがOCI仕様の参照実装であるため、もし将来的にDockerエンジンが別のコンテナランタイムに置き換わったとしても、OCI仕様さえ満たしていれば、同じようにコンテナを実行できます。この標準化が、コンテナ技術の柔軟性と将来性を保証しているのです。

資格試験向けチェックポイント

runcは、特に基本情報技術者試験や応用情報技術者試験において、Dockerやコンテナ技術の内部構造を問う問題で登場する可能性があります。

必須知識

OCIとの関連性: runcは、OCI（Open Container Initiative）が定めるランタイム仕様の参照実装である、という点を必ず覚えてください。これは「標準化」の流れを理解する上で非常に重要です。
Dockerエンジン内部の階層構造: Dockerデーモン、containerd、そしてruncの関係性を理解しておきましょう。runcは「最も低いレベルで、OSカーネルと直接対話してコンテナプロセスを実行する役」です。
カーネル機能の利用: runcがコンテナの分離を実現するために利用するOSの機能は何ですか？答えはLinuxのcgroups（リソース制御）とnamespaces（プロセス分離）です。この低レイヤーの知識は、応用情報技術者試験で問われる可能性が高いです。