systemd否定派が主張する巨大化（Scope Creep）の真のリスクとは？

Linuxの世界においてsystemdは事実上の標準として広く普及していますが、その一方で「巨大化（Scope Creep）」を理由に否定的な立場を取る技術者も少なくありません。
本記事では、その主張の表層ではなく、設計思想と現実的な運用リスクの観点から、なぜsystemdの拡張性が議論を呼び続けるのかを整理します。

systemd否定派の主張は単なる好みの問題ではなく、ソフトウェアアーキテクチャにおける責務分離の原則に根差しています。
特に問題視されるのは以下の点です。

本来独立すべき機能の統合による複雑性の増大
障害時の影響範囲の肥大化
代替実装の選択肢が減少することによる技術的ロックイン

これらは一見すると抽象的な懸念に見えますが、実際の運用環境では可観測性の低下やデバッグコストの増大として顕在化します。
特に大規模システムでは、あるコンポーネントの不具合がシステム全体へ波及するリスクは軽視できません。

一方で、systemdが提供する統一的な管理基盤や並列起動によるパフォーマンス向上といったメリットも明確に存在します。
したがって議論の本質は「採用の是非」ではなく、どの規模・要件のシステムにおいてその統合度が合理的かというトレードオフの問題に帰着します。

本稿では、このScope Creepという概念を手がかりに、現代Linuxシステムにおける設計判断の難しさを掘り下げていきます。

systemdとは何か：Linuxにおけるinitシステムの基本と役割
1. systemdのアーキテクチャとユニット管理の仕組み
2. Linuxシステム起動の高速化とsystemdの設計思想
systemd否定派の主張：Scope Creep（巨大化問題）の本質
1. 責務分離の崩壊とLinux設計思想への影響
2. Scope Creepがもたらすセキュリティリスクと複雑性
systemd統合化のメリットと現実的なトレードオフ
1. systemd統合のメリットと制約の比較
代替initシステム比較：OpenRC・runit・SysVinitの選択肢
大規模サーバー運用におけるsystemdの可観測性と課題
systemd環境を支える監視ツールと運用サービスの活用
エンジニアが考えるべきsystemd採用判断の基準
まとめ：systemdとScope Creep問題をどう捉えるべきか

systemdとは何か：Linuxにおけるinitシステムの基本と役割

Linuxにおけるsystemdは、従来のSysVinitやUpstartに代わって広く採用されているinitシステムであり、システム起動からサービス管理までを統合的に扱う基盤ソフトウェアです。
その役割は単なるプロセス起動にとどまらず、依存関係の解決、並列起動、ログ管理など多岐にわたります。

特に重要なのは、systemdが「ユニット（unit）」という抽象概念を中心に設計されている点です。
これにより、サービス・マウントポイント・タイマーなどを統一的に扱うことが可能になっています。

systemdのアーキテクチャとユニット管理の仕組み

systemdはモノリシックに見えますが、内部的には明確に分割されたコンポーネントで構成されています。
中心となるのはPID 1として動作するsystemdプロセスであり、ここが全体の制御を担います。

ユニットは以下のように分類されます。

service unit（デーモンサービス）
socket unit（ソケットベース起動）
timer unit（cron代替）
mount unit（ファイルシステム管理）

これらは依存関係グラフとして管理され、systemdは起動時に最適な順序を自動的に決定します。

例えばサービス定義は以下のように記述されます。

[Unit]
Description=Example Service
[Service]
ExecStart=/usr/bin/example
[Install]
WantedBy=multi-user.target

この構造により、設定ファイルは宣言的になり、手続き的スクリプトよりも保守性が向上します。

また、ユニット間の依存関係はDAG（有向非巡回グラフ）として解釈されるため、複雑な起動順序も自動的に解決されます。

Linuxシステム起動の高速化とsystemdの設計思想

systemdが評価される最大の理由の一つが起動高速化です。
従来のinitシステムでは直列処理が基本でしたが、systemdは並列起動とソケットアクティベーションを採用することで待機時間を削減しています。

比較すると以下のようになります。

項目	SysVinit	systemd
起動方式	直列	並列
依存管理	手動スクリプト	自動グラフ解析
ログ管理	syslog依存	journald統合

この設計思想の根底には「起動時間を短縮しつつ、管理対象を統一する」という明確な目標があります。
ただし、この統合性が後に議論されるScope Creep問題の起点にもなっています。

特にソケットアクティベーションは重要で、必要になったタイミングでサービスを起動するため、リソース効率が向上します。
これはクラウド環境やコンテナ環境において顕著なメリットを持ちます。

一方で、すべてをsystemdに依存する設計は、障害時の影響範囲を拡大させる可能性もあり、設計上のトレードオフが存在します。
つまりsystemdは単なるinitシステムではなく、現代Linuxのインフラ設計思想そのものを体現する存在だと言えます。

systemd否定派の主張：Scope Creep（巨大化問題）の本質

systemdに対する批判の中核にあるのが「Scope Creep」、つまり本来限定されるべき設計範囲が徐々に拡張され、結果としてシステム全体が肥大化するという問題です。
この議論は単なる好みの対立ではなく、Unix哲学に根差した設計思想の衝突として理解する必要があります。

Linuxはもともと「一つのプログラムは一つのことをうまくやる」という原則のもとに発展してきました。
しかしsystemdはinit機能に留まらず、ログ管理、ネットワーク設定、デバイス管理などを統合し始めたことで、否定派からは責務の過剰集中と見なされています。

責務分離の崩壊とLinux設計思想への影響

ソフトウェア設計において責務分離は基本原則の一つであり、各コンポーネントが単一責任を持つことで保守性と拡張性が確保されます。
しかしsystemdは複数のインフラ機能を統合することで、この原則との緊張関係を生み出しています。

この点は特に以下の観点で議論されます。

システムコンポーネントの境界が曖昧になる
依存関係がsystemd中心に集約される
個別ツールの置き換えが困難になる

結果として、従来であれば独立して進化できたツール群がsystemdの設計に従属する構造になり、エコシステムの多様性が損なわれる可能性が指摘されています。

また、設計の複雑化は開発者体験にも影響を与えます。
単純なデーモン管理であれば独立したスクリプトで完結していたものが、ユニットファイルや依存関係グラフの理解を必要とするため、学習コストが増加します。

Scope Creepがもたらすセキュリティリスクと複雑性

Scope Creepのもう一つの重要な論点はセキュリティと複雑性の増大です。
システムが統合されるほど、単一障害点としてのリスクは増加します。
特にPID 1として動作するsystemdはシステム全体の起点であるため、その攻撃対象領域は極めて重要です。

設計上の複雑性が増すと、以下のような問題が発生しやすくなります。

コードベースの肥大化による脆弱性混入リスクの増加
依存関係の増加による影響範囲の拡大
障害時の原因特定コストの上昇

例えば、ログ管理やデバイス制御が統合されている場合、それらのサブシステムにおける不具合がinitプロセス全体に波及する可能性があります。
これは従来の疎結合な設計では起こりにくかった性質です。

さらに、複雑性の増大は監査性にも影響します。
システムの振る舞いが単一の巨大コンポーネントに依存すると、セキュリティレビューの粒度が粗くなり、潜在的なリスクを見逃す可能性が高まります。

このようにsystemd否定派の主張は単なる感情的な反発ではなく、設計原則・運用リスク・セキュリティの三点に基づいた構造的な懸念として整理することができます。

systemd統合化のメリットと現実的なトレードオフ

systemdに対する議論は批判に偏りがちですが、実際には明確な技術的メリットが存在しており、それを無視して設計を語ることは適切ではありません。
特に統合化による運用効率の向上は、現代のLinuxサーバー環境において無視できない価値を持っています。
一方で、その統合は必然的にトレードオフを伴い、システム設計者に判断の難しさを突きつけることになります。

systemdの統合化の本質は、複数のインフラ機能を単一の管理モデルに収束させることにあります。
従来であればinit、cron、syslog、ネットワーク設定といった要素は個別に管理されていましたが、それらを統一的なインターフェースで扱うことで、運用の一貫性が大幅に向上しました。
この統一性は特に大規模環境で効果を発揮し、構成管理の複雑性を減少させる方向に働きます。

また、systemdの設計は単なる統合ではなく、依存関係の自動解決という点でも重要な進化を含んでいます。
従来のシェルスクリプトベースの起動管理では、依存順序の制御は開発者の責任に依存していましたが、systemdではユニット間の依存関係が明示的に記述されるため、システム全体の整合性が向上します。
これにより人的ミスの余地が減少し、安定性の向上につながっています。

さらにログ管理においてもjournaldの導入は大きな変化をもたらしました。
従来のテキストベースログは柔軟性が高い一方で、解析性や構造化という点で限界がありましたが、systemdではバイナリログとして統合的に扱うことで、フィルタリングや検索が効率化されています。
この点は運用監視の観点で大きな改善といえます。

systemd統合のメリットと制約の比較

以下は統合化によって得られる利点と、それに伴う制約の対比です。

観点	メリット	トレードオフ
起動管理	並列化による高速化	内部構造の複雑化
ログ管理	構造化・高速検索	依存ツール増加
設定管理	一元化されたユニット管理	学習コスト増加
障害対応	状態の一貫性	単一障害点化

このように、systemdは単純な性能向上だけではなく、運用モデルそのものを再定義する存在であることが分かります。

統合化のもう一つの重要な側面は開発体験の均質化です。
従来はディストリビューションごとにinitスクリプトの記述方法が異なっていましたが、systemdではユニットファイルという共通フォーマットが採用されているため、移植性が向上しました。
この点はクラウド環境やコンテナ環境において特に有利に働きます。

例えばサービス定義は一貫した構造を持ちます。

[Unit]
Description=Unified Service Example
After=network.target
[Service]
ExecStart=/usr/bin/example-app
Restart=always
[Install]
WantedBy=multi-user.target

このような宣言的記述は、構成の可読性を高める一方で、抽象化レイヤーが増えることによるブラックボックス化の懸念も生みます。
つまり開発者は「何が起きているか」を理解するためにsystemd内部の挙動をある程度把握する必要があり、単純なスクリプト運用とは異なる認知負荷が発生します。

さらに重要なのは、統合化によって得られる効率と引き換えに、柔軟性が制限される可能性です。
個別ツールを自由に組み合わせる設計では、特定用途に最適化された構成を取ることができましたが、systemd中心の構造ではその自由度が相対的に低下します。

このようにsystemdの統合化は明確な技術的進歩である一方で、設計思想としてはトレードオフを内包したものです。
そのため重要なのは採用の是非ではなく、システムの規模・目的・運用体制に応じてそのメリットと制約をどのように評価するかという点にあります。

代替initシステム比較：OpenRC・runit・SysVinitの選択肢

systemdがLinuxディストリビューションの標準的なinitシステムとして広く採用される一方で、その設計思想や複雑性を理由に代替手段を選択する動きも継続しています。
特にOpenRC、runit、SysVinitといった軽量なinitシステムは、シンプルさや透明性を重視する環境で根強い支持を得ています。
これらの選択肢は単なるレガシーではなく、設計上の明確な意図を持ったアーキテクチャとして評価する必要があります。

まず前提として、initシステムの役割はPID 1としてシステム起動時に最初に実行され、サービスの起動・停止・監視を管理することにあります。
この責務自体は共通していますが、その実装哲学は大きく異なります。
systemdが統合型アーキテクチャを採用しているのに対し、代替システムは基本的に「単機能の組み合わせ」を重視しています。

OpenRC・runit・SysVinitの設計思想の違い

OpenRCはGentoo系ディストリビューションで広く利用されるinitシステムであり、依存関係解決機能を持ちながらもsystemdほどの統合性は持ちません。
シェルスクリプトベースで構成されているため、可読性が高く、動作の追跡が容易である点が特徴です。
依存関係は明示的に定義されますが、あくまで軽量な管理に留まります。

runitはさらにミニマルな設計を採用しており、プロセス監視とサービス起動に特化しています。
設計上の特徴は「速さ」と「単純性」であり、デーモンの再起動や監視を非常に軽量に処理できる点にあります。
そのため組み込み環境やコンテナベースのシステムで好まれる傾向があります。

SysVinitは最も古典的な方式であり、ランレベルとシェルスクリプトによる逐次起動を基本としています。
現代的な機能は持たないものの、その構造は極めて単純であり、動作原理の理解が容易です。
ただし並列化がないため起動速度には制約があります。

各initシステムの比較と特徴

以下に主要な観点での比較を整理します。

システム	設計思想	特徴	適用領域
OpenRC	疎結合・依存管理	柔軟性と可読性	汎用Linux
runit	最小構成・高速起動	軽量・監視特化	コンテナ・組み込み
SysVinit	逐次処理	単純・歴史的互換性	レガシー環境

この比較から明らかなように、これらの代替initシステムは「統合ではなく分離」を基本原則としており、systemdとは設計哲学そのものが異なります。

例えばrunitではサービス管理が極めて単純であり、ディレクトリ構造とスクリプトによって制御されます。

#!/bin/sh
exec 2>&1
exec /usr/bin/myservice

このような構造は抽象化レイヤーが少ないため、デバッグや挙動確認が容易です。
一方で、高度な依存解決や統合ログ管理といった機能は存在しないため、必要な機能は別途組み合わせる必要があります。

軽量initシステムを選択する理由と限界

代替initシステムが選ばれる背景には明確な理由があります。
第一に、システム全体の挙動が透明であることです。
systemdのように多数の機能が統合されている場合、内部動作の理解には一定の学習コストが必要ですが、軽量initではその必要が最小限に抑えられます。

第二に、リソース効率です。
特にrunitやSysVinitはメモリ使用量が小さく、リソース制約のある環境で有利です。
これは組み込みLinuxや軽量サーバー構成において重要な要素になります。

ただし、これらの利点はスケーラビリティや機能統合性とのトレードオフでもあります。
大規模システムではサービス間依存関係やログ管理が複雑化するため、systemdのような統合型設計の方が運用効率が高くなる場合もあります。

つまりinitシステムの選択は単なる技術的好みではなく、システムの規模、運用モデル、チームのスキルセットによって決定されるべき設計判断です。
この観点から見ると、OpenRCやrunit、SysVinitはsystemdの代替というよりも、異なる設計空間における最適解として位置づけるのが適切です。

大規模サーバー運用におけるsystemdの可観測性と課題

大規模サーバー運用においてsystemdが注目される理由の一つは、可観測性の向上にあります。
従来のLinuxシステムでは、ログ管理やサービス状態の把握が複数のツールに分散しており、障害解析において情報の統合が困難でした。
systemdはこの問題に対してjournaldやユニット管理機構を統合することで、システム全体の状態を一元的に観測できる環境を提供しています。

しかし、この「統合による可視化」は単純な利便性向上にとどまらず、システム設計上の新たな課題も生み出しています。
特に大規模環境では、観測対象の増加と抽象化レイヤーの増大が、逆に運用の複雑性を高める要因となる場合があります。

systemdの可観測性の中心にあるのはjournaldです。
これは従来のテキストログとは異なり、バイナリ形式で構造化されたログを管理する仕組みです。
これにより、サービス単位や時間軸に基づいた柔軟な検索が可能になります。

journalctl -u nginx.service --since "1 hour ago"

このようなコマンドにより、特定サービスのログを高速に抽出できる点は運用上の大きな利点です。
一方で、ログの内部形式が抽象化されているため、従来のテキストベースツールとの互換性は限定的になります。
この点は移行時の障壁となることがあります。

可観測性の向上と引き換えに生じる複雑性

systemdの可観測性は単にログだけでなく、ユニット状態や依存関係の可視化にも及びます。
例えば以下のようなコマンドにより、サービス間の関係性を確認できます。

systemctl list-dependencies nginx.service

この機能は障害解析において非常に有用ですが、依存関係が複雑化するほど出力結果の解釈も難しくなります。
つまり可観測性の向上は、そのまま認知負荷の増加と表裏一体の関係にあります。

さらに大規模環境では、数百から数千のユニットが同時に動作するため、単一ノードでの理解ではなく、クラスタ全体としての挙動を把握する必要があります。
このときsystemd単体の可視化機能だけでは不十分になることがあり、外部監視ツールとの併用が前提となるケースが増えます。

分散システムにおける観測性の限界

systemdは基本的にホスト単位の管理を前提としているため、分散システム全体の観測には追加の設計が必要です。
例えばコンテナオーケストレーション環境では、systemdはノード内部の制御には有効ですが、クラスタ全体の状態管理は別レイヤーに依存します。

観点	systemd単体	分散監視ツール
可視化範囲	単一ホスト	クラスタ全体
ログ管理	journald	集約ログ基盤
障害解析	ローカル中心	横断的分析
スケーラビリティ	中規模まで	大規模向け

このようにsystemdは強力なローカル可観測性を提供する一方で、分散環境では補完的な役割に留まることが多くなります。

また、systemdの統合ログは便利である反面、ログの肥大化や保持ポリシーの設計が重要になります。
適切な設定を行わない場合、ディスク使用量の増加やパフォーマンス低下を引き起こす可能性があります。
この点は運用設計上の重要な注意点です。

可観測性と運用設計のトレードオフ

最終的に重要なのは、systemdの可観測性が万能ではないという認識です。
確かに単一ホストにおいては優れた統合ビューを提供しますが、それは設計上の境界を明確にした場合に成立するモデルです。
スケールが大きくなるにつれ、systemd単体ではなく外部監視基盤との連携が不可欠になります。

つまりsystemdの可観測性は、運用の単純化と引き換えにスコープの限定を伴う設計であり、その特性を理解せずに採用すると、逆に運用複雑性を増大させる可能性があります。
大規模サーバー運用においては、このバランスを適切に設計することが極めて重要になります。

systemd環境を支える監視ツールと運用サービスの活用

systemdを前提としたLinux運用では、単体の機能だけで完結することは少なく、監視ツールや外部サービスとの組み合わせによって初めて実運用レベルの可観測性と安定性が成立します。
特に大規模システムやクラウド環境では、systemdが提供するローカルな管理機構だけでは不十分であり、外部の監視レイヤーとの統合が前提となります。

systemdはサービス状態の管理やログ収集を標準で提供しますが、それらはあくまでホスト単位の情報に限定されます。
そのため、複数ノードを跨ぐシステム全体の健全性を把握するためには、専用の監視基盤が必要になります。
ここで重要になるのが、メトリクス収集、ログ集約、アラート管理という三つの観点です。

例えばログの観点では、journaldのデータをそのまま扱うのではなく、外部のログ収集基盤へ転送する構成が一般的です。

journalctl -f | tee /var/log/exported.log

実際の運用ではこのような単純なパイプではなく、FluentdやLogstashのようなエージェントを介して構造化データとして転送されます。
これにより、ログの検索性と分析性が大幅に向上します。

systemdと監視ツールの役割分担

systemdと監視ツールの関係は、競合ではなくレイヤー分離として理解することが重要です。
systemdはローカルホストのプロセス管理と状態保持に特化しており、監視ツールはそれを横断的に集約・分析する役割を担います。

項目	systemd	監視ツール
管理範囲	単一ホスト	複数ホスト
主目的	サービス制御	状態可視化
データ形式	journaldバイナリ	メトリクス・ログ統合
拡張性	中程度	高い

この分離によって、各コンポーネントは責務を明確に保ちながらスケーラブルな運用を実現できます。

メトリクス監視とアラート設計の重要性

systemd単体ではCPU使用率やメモリ消費などの詳細なメトリクス分析は限定的です。
そのためPrometheusのようなメトリクス収集基盤と連携することで、システム全体の動的な状態把握が可能になります。

特に重要なのはアラート設計です。
単純な閾値監視ではなく、サービス依存関係を考慮した異常検知が求められます。
例えばnginxサービスが停止した場合、それ自体の問題だけでなく、依存するバックエンドサービスへの影響も評価する必要があります。

systemdは依存関係を内部的に管理していますが、それを外部監視システムに反映するには追加の設計が必要です。
このギャップが運用設計上の難所となります。

クラウドネイティブ環境との統合

近年ではsystemdは単独で運用されることは少なく、Kubernetesや各種クラウドサービスと組み合わせて利用されるケースが増えています。
この場合systemdはノードレベルのランタイム管理層として機能し、その上位にオーケストレーション層が存在します。

この構造では、systemdはローカルの安定性を保証する役割に集中し、全体制御はクラウド基盤が担当します。
この役割分担は設計として合理的ですが、同時にトラブルシューティングの難易度を上げる要因にもなります。

特に問題となるのは、障害発生時にどのレイヤーで問題が発生しているかの切り分けです。
systemdレベルの障害なのか、上位オーケストレーションの問題なのかを迅速に判断するためには、統合された可観測性基盤が不可欠になります。

運用設計における現実的なバランス

最終的に重要なのは、systemdと監視ツールを対立構造として捉えるのではなく、階層的な設計として理解することです。
systemdはローカルの実行基盤として優れた機能を提供し、監視ツールはその上に抽象化された観測レイヤーを構築します。

この関係性を適切に設計することで、システム全体の安定性と可観測性は大きく向上します。
一方で設計を誤ると、情報が分断されてしまい、かえって障害対応が複雑化する可能性があります。

したがってsystemd環境における監視設計は、単なるツール選定ではなく、アーキテクチャ設計そのものの問題として扱う必要があります。

エンジニアが考えるべきsystemd採用判断の基準

systemdの採用是非を議論する際に重要なのは、思想的な好みではなく、システム要件に基づいた合理的な判断です。
Linuxエコシステムにおいてsystemdはすでにデファクトスタンダードの地位を確立していますが、それが常に最適解であるとは限りません。
むしろ設計対象の規模や運用モデルによっては、過剰な抽象化となる場合もあります。

エンジニアがsystemdを採用するかどうかを判断する際には、まずシステムのスケールと複雑性を評価する必要があります。
単一サーバーで完結する小規模なサービスであれば、軽量なinitシステムでも十分に要件を満たすことが多く、systemdの統合機能は必ずしも必要ではありません。
一方で、多数のサービスが相互依存するマイクロサービス構成やクラウド環境では、systemdのユニット管理や依存解決機構が大きな利点となります。

次に重要なのは運用チームのスキルセットです。
systemdは機能が豊富である反面、学習コストが存在します。
ユニットファイルの設計、依存関係の定義、ログ解析などを正しく理解していなければ、その恩恵を十分に活用することはできません。
そのためチーム全体の技術成熟度が採用判断に直接影響します。

systemd採用判断における評価軸

systemdの採用を検討する際には、以下のような観点で整理することが実務的です。

評価軸	systemdが有利な場合	代替が有利な場合
システム規模	大規模・複数サービス	単機能・小規模
運用体制	監視・自動化重視	手動管理中心
可観測性	統合ログが必要	単純ログで十分
拡張性	高度な依存管理が必要	シンプル構成優先

このように比較すると、systemdは明確に「スケールするための設計」であることが理解できます。

可観測性と運用コストのバランス

systemdはログ管理やサービス状態の統合により可観測性を向上させますが、その代償として設定と理解の複雑性が増加します。
この点は特に運用コストに直結します。
例えば障害解析時には、systemctlやjournalctlを駆使して状態を把握する必要があり、従来のスクリプトベース運用よりも情報量が増える傾向があります。

systemctl status nginx.service
journalctl -u nginx.service -xe

これらのコマンドは強力ですが、出力される情報の解釈には一定の知識が必要です。
つまりsystemdは可視性を向上させる一方で、認知負荷も同時に引き上げています。

アーキテクチャとの適合性

systemd採用の判断において最も重要なのは、アーキテクチャとの適合性です。
例えばコンテナ中心の環境では、systemdのフル機能が必ずしも必要ではなく、軽量なプロセスマネージャで十分なケースがあります。
一方でオンプレミスの大規模サーバー群では、統一された管理インターフェースが強い価値を持ちます。

またセキュリティ要件も重要な判断要素です。
systemdは機能が統合されているため攻撃面が広がる可能性がある一方で、アクセス制御やサンドボックス機能なども提供しており、適切に設計すればセキュリティを強化することも可能です。

判断基準の本質

最終的にsystemd採用の判断は、「統合による効率化」と「複雑性の増加」のバランス問題に帰着します。
重要なのはどちらが優れているかではなく、対象システムにおいてどちらが許容可能かという現実的な視点です。

エンジニアに求められるのは、systemdを盲目的に採用することでも否定することでもなく、その特性を理解した上で設計要件に適合させる判断力です。
systemdは強力なツールであると同時に、使い方を誤れば複雑性を増幅させる要因にもなり得るため、その本質を踏まえた設計判断が不可欠です。

まとめ：systemdとScope Creep問題をどう捉えるべきか

systemdとScope Creep（巨大化問題）をめぐる議論は、単なるツール選好の対立ではなく、ソフトウェア設計における根本的な思想の違いを反映しています。
systemdはLinuxシステムの起動管理からサービス制御、ログ収集に至るまでを統合的に扱うことで、運用の一貫性と効率性を実現しています。
一方で、その統合性が進むほど、責務分離の原則との緊張関係が生まれ、設計思想としての評価が分かれる構造になっています。

重要なのは、この問題を「systemdが良いか悪いか」という単純な二項対立で捉えないことです。
実際には、システムの規模、運用環境、チームの技術レベルによって最適解は変化します。
小規模環境では軽量な構成の方が透明性と理解容易性の面で優れていることが多く、大規模環境では統合管理による効率性が不可欠になることもあります。

Scope Creepの本質は、機能の増加そのものではなく「境界の曖昧化」にあります。
systemdが批判される理由も、この境界が徐々に拡張されることで、システム全体の見通しが難しくなる点にあります。
ただし同時に、この統合は運用効率や自動化の観点では大きなメリットを提供しているため、単純に否定できるものでもありません。