DevOps・SREツールチェーンの系統と派生

系統図として読むという視点

DevOps・SREのツールは数が多く、Jenkins・Terraform・Argo CD・Prometheus・Kubernetes……と並べても関係が見えません。しかしツールを個別の製品としてではなく「思想の派生」として読むと、一枚の系統図に整理できます。本稿の主張は単純で、過去十数年のツールチェーン進化は次の三つの軸の派生でほぼ説明できる、というものです。

• 駆動の所在：push型 → pull型（変更を外から送り込むか、内側のエージェントが取りに行くか）
• 記述の抽象度：命令型（手続き） → 宣言型（望ましい状態の宣言）
• 観測の深さ：監視（既知の指標の閾値判定） → 可観測性（未知の振る舞いの探索的分析）

この三軸は独立ではなく連動して台頭しました。宣言型は「望ましい状態」を生み、その状態へ収束させる主体としてpull型エージェントが要り、宣言と実体のズレや未知の挙動を後から問うために可観測性が要る。つまり三つは同じ思想潮流の三つの顔です。以下、年代と分岐を軸に各系譜を辿ります。

三軸の派生を一枚で

各系譜は、この表のどこを「古い極」から「新しい極」へ動かしたかで位置づけられます。重要なのは、新しい極が常に正しいわけではなく、トレードオフの選択だという点です（後述）。

系譜1：CI/CD ——ビルド自動化から宣言的デリバリへ

最初期（2000年代後半）の中心はビルドとテストの自動化でした。Jenkins に代表される世代は、ジョブを命令的に——「チェックアウトし、コンパイルし、テストを走らせ、成果物を置け」と手順で記述しました。この時点のデプロイは典型的なpush型で、CIサーバーが本番へ ssh や kubectl apply で変更を送り込みます。

世代1（命令型・push型）:
  CIサーバー: build → test → ssh/apply で本番へ送り込む
  状態の真実 = 最後にapplyした内容（その後のズレは見えない）

世代2（宣言的パイプライン）:
  パイプライン定義をコード化（YAML）し、ステージ/依存を宣言
  再現性・レビュー可能性は上がるが、デプロイはまだpush型

世代3（GitOps・pull型）:
  Gitの宣言＝望ましい状態。クラスタ内エージェントが取りに行く
  状態の真実 = Git。ドリフトを毎サイクル是正

分岐点は二つあります。第一に、パイプライン自体のコード化（pipeline-as-code）で、ジョブ設定がリポジトリに入りレビュー対象になりました。第二に、デプロイのpull型への転回＝GitOpsです。CIは成果物を作りレジストリへ置くところまでを担い、デプロイは別系統のエージェントがGitを真実として収束させる——責務が「ビルド」と「収束」に分離しました。詳しくは /devops/ci-cd/ と /devops/gitops/ を参照してください。

系譜2：IaC ——スクリプトから宣言的状態管理へ

インフラ構成も同じ軌跡を辿りました。初期は shell スクリプトや手続き的な構成管理で、「このパッケージを入れ、この行を書き換えよ」と命令的に書きました。問題は冪等性で、同じスクリプトを二度流すと壊れる、途中で失敗すると中途半端な状態になる、という不安定さがありました。

宣言型IaC（Terraform 等）はここを反転させ、「最終的にこういうリソースが存在してほしい」という望ましい状態だけを書かせ、現状との差分（plan）を計算して必要な変更だけを適用（apply）します。原理は GitOps の調整ループと同型で、望ましい状態 − 観測状態 = 差分 を縮める操作です。基礎は /devops/iac/、宣言型ゆえに不可欠なのが状態（state）の管理とドリフト・ロックで、ここが実装上の難所になります（/devops/iac-state-drift-locking/）。

派生の系統を箇条書きで俯瞰すると次のようになります。

• 命令型（〜2010頃）：手続きスクリプト。冪等でなく、再実行が安全でない。
• 宣言型・push適用（2010年代）：望ましい状態を宣言し、人/CIが apply を叩く。stateとドリフトの概念が生まれる。
• 宣言型・pull収束（2010年代後半〜）：GitOps・Operator パターンで、エージェントが望ましい状態へ継続収束させる。applyは「Gitを書く」に置き換わる。

このpull収束の極致が Kubernetes の調整ループであり、その一般論は /devops/reconciliation-control-loop/ にまとめています。

系譜3：監視から可観測性へ

第三の系譜は観測です。古い極は監視（monitoring）で、Nagios 世代の「ホストが生きているか」「CPUが閾値を超えたか」という既知の指標の閾値判定でした。前提は「何を見るべきかを事前に知っている」こと。次の世代はメトリクスの時系列化（Prometheus 等）で、多次元のラベル付き時系列を集計・アラートできるようになりましたが、依然として事前に決めた質問に答える構造です。

転回点は可観測性（observability）という概念で、「内部状態を外部出力から推測できる度合い」と定義されます。狙いは未知の未知（unknown unknowns）——計装時に予期しなかった質問に、事後に答えられること。これを可能にするのが、高カーディナリティ・高次元の構造化イベントを保持し、後から任意の軸で絞り込む探索的分析です。

監視（既知の質問）:
  事前にダッシュボードとアラートを定義 → 閾値超過で発火
  「想定済みの障害」には強いが、想定外には盲目

可観測性（未知の質問）:
  高カーディナリティの構造化イベントを保持
  事後に任意の軸（user_id, build_id, region…）で切り直して問い合わせ
  「なぜ特定ユーザーだけ遅いか」を計装後に答えられる

可観測性は三つの柱（メトリクス・ログ・トレース）として語られがちですが、本質は柱の数ではなく高カーディナリティを保持したまま相関できるかにあります。トレース（/devops/distributed-tracing/）はリクエストの因果を、構造化ログは個別事象の文脈を、メトリクスは集計を担い、これらを横断する計装標準が OpenTelemetry です（内部は /devops/opentelemetry-internals/）。総論は /devops/observability/ を参照してください。

なぜ三軸は連動したのか

ここまでを統合すると、三つの系譜が同じ思想の三面であることが見えます。

1. 宣言型が「望ましい状態」という概念を導入する。
2. その望ましい状態へ実体を継続的に収束させる主体として、pull型エージェントが要る（push型は単発イベントで収束を保証しない）。
3. 宣言と実体のズレ（ドリフト）、収束の失敗、そして宣言からは読めない実行時の振る舞いを後から問うために、可観測性が要る。

つまり「望ましい状態を宣言し、エージェントが収束させ、未知の挙動を後から問い合わせる」という一貫した世界観が、CI/CD・IaC・観測の三系統を同時に新しい極へ引っ張ったのです。コンテナオーケストレーション（Kubernetes）はこの世界観をOSとして体現した存在で、全リソースを宣言的に記述し、コントローラ群が pull 型で収束させ、その内部状態を可観測性で覗く、という三軸の合流点に位置します。

まとめ

• DevOps・SREツールチェーンの進化は、**push→pull（駆動の所在）・命令型→宣言型（記述の抽象度）・監視→可観測性（観測の深さ）**という三軸の派生で一望できる。ツールはこの思想の実装差として比較する。
• CI/CDはビルド自動化→宣言的パイプライン→GitOps（pull型）へ分岐し、責務が「ビルド」と「収束」に分離した。IaCは命令型スクリプト→宣言的状態管理へ移り、stateとドリフトという代償を生んだ。
• 観測は既知メトリクスの監視→未知の未知に答える可観測性へ転回し、本質は高カーディナリティを保持した相関にある。
• 三軸は独立でなく連動して台頭した。望ましい状態を宣言し、pull型エージェントが収束させ、可観測性で実行時を問う、という一貫した世界観の三面であり、Kubernetesはその合流点。
• ただし新しい極は万能でなく、誤った状態への忠実な収束・最終的整合・観測コストというトレードオフを伴う。系統図は優劣のランキングではなく、軸をどちらへ動かしたかを示す地図である。