systemd以外の選択肢は今どうなっているか｜代替initの現況まとめ

「systemd以外」の議論はなぜ続くのか

Linuxのinitシステムとしてsystemdが主要ディストリビューションに採用されてから10年以上が経ちます。Red Hat系・Debian系・Arch系がそろってsystemdを標準とした現在、代替initの話題はニッチに見えるかもしれません。しかし、現場では「systemdを使わない選択」を意図的に取るケースが一定数残っており、その理由は単なるノスタルジーではありません。

批判の多くは設計思想に向けられています。「1つのデーモンが多くの責務を持ちすぎる」「ログがバイナリ形式（journald）になることで従来のテキストベース運用ツールと相性が悪い」「起動時の依存解決が複雑で障害切り分けが難しい」という声は、特にコンテナ・組み込み・セキュリティ重視の環境を担う運用者から今も聞かれます。加えて、Unixの「1つのプログラムは1つのことをうまくやる」という哲学との摩擦感を重視する層も存在します。

2026年時点で代替initプロジェクトの状況はどうなっているか。それぞれの成熟度・採用実績・今後の見通しを順に整理します。

主要な代替initの現況（2026年）

OpenRC

GentooとAlpine Linuxが採用するOpenRCは、代替initの中で最も実運用実績が厚いプロジェクトです。スクリプトベースで依存関係を管理し、sysvinitの後継として設計されているため、既存のSysVスクリプトとの親和性が高い点が評価されています。

2026年時点でも開発は継続しており、Alpine Linux 3.x系での採用が続いています。Alpine Linuxはコンテナイメージの軽量化需要を背景に広く使われているため、OpenRCに触れる運用者は思いのほか多い状況です。ただし、Alpine自体のコンテナ用途では起動スクリプトを最小化する構成が一般的であり、OpenRCの全機能が活用されているわけではありません。

runit

runitはVoid Linuxの標準initとして知られ、「起動・サービス監視・ログ管理」の3ステージ構成がシンプルな設計で人気があります。プロセス監視デーモン（runsv）が各サービスを独立して監視するため、systemdのような中央集権的なユニット管理とは発想が異なります。

Void Linuxの開発は2026年現在も継続していますが、メンテナのリソース不足が課題として指摘される時期があり、コミュニティの動向には注意が必要です。runit単体はDebian上でもパッケージ提供されており、sysvinitやsystemdと並行してインストールして試す環境を作ることは可能です。

s6とs6-rc

Laurent Bercot氏が開発するs6は、Unixの設計原則を徹底したsupervisionスイートです。s6単体はプロセス監視に特化し、サービス依存関係の管理はs6-rcが担当します。学習コストは高めですが、極小フットプリントと決定論的な動作が求められるセキュリティ重視環境や組み込みLinuxで採用例があります。

Artix Linux（Arch派生）のs6フレーバーや、一部のコンテナベースイメージ（just-containers/s6-overlayなど）がs6を組み込む形で利用されており、特にDockerコンテナ内でのマルチプロセス管理用途として根強い需要があります。

dinit

比較的新しいinitとして注目されているのがdinitです。C++で実装されており、サービス依存関係の定義をシンプルなテキストファイルで行える点がsystemdのユニットファイルに慣れた運用者にも取り組みやすいとされています。Chimera Linuxが採用しており、ドキュメントの整備も着実に進んでいます。

2026年現在、dinitはまだ採用ディストリが限られる成長段階にありますが、設計の明快さからコミュニティでの評価は高まっています。今後の採用動向が注目されるプロジェクトです。

コンテナ・組み込み環境での別の流れ

コンテナ環境では「initそのものを使わない」あるいは「最小限のsupervisionだけ使う」という構成が標準的です。Dockerの公式推奨はコンテナ1プロセス原則であり、フォアグラウンドで単一プロセスを動かす構成ではinitの出番はありません。

一方、コンテナ内でNginx＋PHP-FPMのように複数プロセスを管理したい場合、supervisordや前述のs6-overlayが使われることがあります。supervisordはPythonベースで可読性の高い設定ファイルを持ち、コンテナ運用者にとって導入障壁が低いという理由で今も広く使われています。

組み込みLinux（Yocto・BuildrootベースのIoTデバイスなど）では、起動時間と消費リソースの観点からsystemdを避ける設計判断が行われることがあります。BusyBoxのinitやrunit、OpenRCが選ばれるケースは組み込み領域では依然として実務上の選択肢として機能しています。

代替initを採用するディストリビューションの現状

代替initを採用する主要ディストリビューションを整理すると、以下のような状況です。

• Alpine Linux（OpenRC）：コンテナ用途での普及が安定しており、サーバー・組み込み向けにも使われています。軽量さを優先する選択肢として2026年現在も現役です。
• Void Linux（runit）：独自のパッケージマネージャ（XBPS）とrunitを組み合わせた個性的なディストリです。デスクトップ用途にも一定の利用者がいます。
• Artix Linux（OpenRC / runit / s6 / dinit）：Arch Linuxからsystemdを除いた派生ディストリで、複数のinit選択肢を提供しています。Arch系の使い勝手を保ちながら代替initを試したい層に支持されています。
• Devuan（sysvinit / OpenRC / runit）：systemd排除を明確な方針とするDebian派生ディストリです。古い構成を維持したいサーバー環境での採用例があります。
• Chimera Linux（dinit）：Alpine系のベースにLLVMツールチェインとdinitを組み合わせた新興ディストリです。設計の一貫性が評価されています。

これらはいずれも主流のディストリではありませんが、それぞれが明確な設計思想と利用目的を持って維持されています。

代替initを選ぶべき場面・選ばない場面

代替initを積極的に検討する根拠が明確に存在する場面は次のようなケースです。

• 組み込みデバイスや極小コンテナイメージで、systemdの依存ライブラリ群がフットプリントの制約に抵触する場合
• journaldのバイナリログではなく、従来のテキストログ（syslog）をそのまま使いたい運用ポリシーがある場合
• 既存のSysVスクリプト資産を大量に引き継ぐ必要があり、移行コストを最小化したい場合
• セキュリティ上の理由からD-Busや関連コンポーネントを除外したいアーキテクチャの場合

一方、以下の状況では代替initの採用は慎重に判断すべきです。

• Kubernetes・Ansible・Puppetなどの構成管理ツールがsystemdユニットを前提とした設計になっている場合（サポート外の動作になるリスクがあります）
• 商用サポート付きのOSを使う必要があるエンタープライズ環境（サポート契約がsystemd前提のことが多いため）
• チームにinitシステムを深く理解したメンバーがおらず、トラブル時の対応ができない場合

「systemdが嫌いだから」という感情的な理由だけで代替initを選ぶと、運用で想定外のコストが発生することがあります。目的と制約を先に整理することが重要です。

2026年時点での見通しと実務への示唆

現状を率直に言えば、汎用サーバー・デスクトップ用途においてsystemdの支配的な地位は2026年時点でも揺らいでいません。UbuntuもFedoraもDebian 12（Bookworm）もsystemdを標準としており、主要なエコシステムはsystemdを前提として設計されています。代替initプロジェクトの多くは小規模コミュニティで維持されており、エンタープライズ採用に十分な商用サポートを持つものは現状では存在しません。

ただし、代替initの存在意義は「systemdを倒す」ことではなく、特定の設計制約や思想に適した環境を提供することにあります。Alpine LinuxがDockerエコシステムで広く使われているように、用途が明確な場面では代替initを軸にしたディストリが現役で機能しています。

運用の現場では「なぜinitを変える必要があるのか」を先に問うことが適切です。フットプリント・ログ形式・起動時間・依存ライブラリのいずれかに具体的な制約がある場合に初めて、代替initの選定が意味を持ちます。その制約が明確であれば、OpenRC・runit・s6・dinitのいずれかが要件に合う選択肢として機能するでしょう。

今後の動向として注目すべきは、dinitのような新世代プロジェクトがどこまで採用を広げるかと、Chimera Linuxのような設計一貫性を重視するディストリが開発者コミュニティでどう評価されるかという点です。代替initを巡る議論はOSSの設計思想論として根強く続きますが、それが実務の選択を左右するかは個々の要件次第です。