本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「開発運用アーキテクチャ」カテゴリ第2弾として、DevOps・SREの全体像について解説する記事です。
DevOps（2009年〜の文化運動）と SRE（2003年〜の Google 発工学手法）は同じゴールを別の道で登ったと捉えるのが実務的な見方です。本記事ではWall of Confusion／Wall of Confusionの解消・SLO・エラーバジェット・トイル削減・ポストモーテムなど両者の構成要素を扱い、「開発と運用の分離はもう古い」という現代の合意点を整理します。
このカテゴリの他の記事
「動いた」と「動き続ける」の間に、昔は国境があった
Wall of Confusion（開発と運用の間に存在した、ゴールと評価指標が正反対の組織的分断）──開発チームは「機能を速くリリースした数」で評価され、運用チームは「システムが落ちなかった時間」で評価される。目標が構造的に相反するため、リリースのたびに「出したい開発」対「止めたい運用」の綱引きが発生し、障害時には互いの責任を押し付け合う、という文化がかつての業界標準でした。
この壁を壊すために「開発チームがデプロイと運用まで責任を持つ」「運用チームがコードで仕事をする」という、両側からの越境が起きたのがここ15年の動きです。Amazon の API Mandate（2002年）や Netflix の Freedom & Responsibility といった有名な文化改革も、この越境を先取りした事例として知られます。
| 旧世界（〜2009頃） | 新世界（DevOps／SRE 以降） |
|---|---|
| 開発は速度、運用は安定性 | 両方を同じチームが見る |
| デプロイは運用の手作業 | デプロイはパイプラインが実行 |
| 障害時は「誰の責任か」 | 障害時は「どう再発を防ぐか」 |
| 運用は夜中の電話番 | 運用はコードで自動化 |
DevOpsとSREは、別物なのか
よく混同される2つですが、起源が違い、強調点が違うと押さえると整理できます。
DevOps は文化・組織論が主戦場で、「開発と運用の協働」をゴールに CI/CD・自動化・計測・共有を広める運動です。対して SRE は Google 発の工学手法で、SLO（Service Level Objective＝信頼性の数値目標）とエラーバジェット（壊れてよい予算）を核に、運用の意思決定を数値で回す方法論です。
| 観点 | DevOps | SRE |
|---|---|---|
| 起源 | 2009 DevOpsDays（ベルギー） | 2003 Google 社内 → 2016 書籍化 |
| 主眼 | 文化・組織・協働 | 信頼性のエンジニアリング化 |
| 核となる武器 | CI/CD・自動化・計測・共有 | SLO・エラーバジェット・Toil 削減 |
| 典型的なロール | DevOpsエンジニア（横断） | SRE（信頼性専任） |
| 主戦場 | プロセス・パイプライン | 本番運用・信頼性 |
実装としての SRE は DevOps の部分集合、と Google 自身が説明しています。対立項ではなく、SREはDevOpsを実装する一つの方法です。
DORA 4指標 — 強いチームと弱いチームを分ける数字
DORA（DevOps Research and Assessment＝Nicole Forsgren 博士らが率いる研究チーム、2018年に書籍『Accelerate』で体系化）は、世界中のチームを10年近く調査して、強いチームと弱いチームの差は4つの数値に集約されると結論付けました。この4指標が、DevOps・SRE の改善成果を測る共通言語になっています。
quadrantChart
title DORAの発見「速度と安定性は両立する」
x-axis 安定性低 --> 安定性高
y-axis スピード遅 --> スピード速
quadrant-1 Elite (理想)
quadrant-2 不安定で遅い
quadrant-3 Low (最悪)
quadrant-4 慎重派
Elite (上位10%): [0.9, 0.9]
High: [0.7, 0.7]
Medium: [0.5, 0.5]
Low (下位30%): [0.2, 0.2]| 指標 | 意味 | Elite（上位10%） | Low（下位30%） |
|---|---|---|---|
| デプロイ頻度 | どれだけ頻繁に本番に出るか | 日に複数回 | 月1未満 |
| 変更リードタイム | コード commit → 本番まで | 1時間未満 | 1ヶ月超 |
| MTTR（Mean Time To Recovery＝平均復旧時間） | 障害発生 → 復旧までの時間 | 1時間未満 | 1ヶ月超 |
| 変更失敗率 | デプロイが問題を起こす割合 | 0〜15% | 46〜60% |
注目すべきは速度と安定性は両立するという DORA の発見です。頻繁にリリースするチームほど失敗率が低く、復旧も速い。遅くて壊れにくいではなく、速くて壊れにくいのが Elite の姿、というのがこの研究の最大のインパクトでした。
CALMS — DevOpsの5本柱
DevOps を「文化運動」として整理するときの標準的な枠組みが CALMS です。各項目がどの章の記事に対応するかを書いておきます。
| 柱 | 意味 | この章での対応 |
|---|---|---|
| Culture | 失敗を罰しない・共有する文化 | ポストモーテム・Blameless |
| Automation | 手作業を自動化 | CI/CD・IaC・GitOps |
| Lean | 小さく速く流す | Trunk Based・Feature Flag |
| Measurement | 全てを計測する | DORA・SLO・オブザーバビリティ |
| Sharing | 学びを共有 | Runbook・ドキュメント・PR |
特に Measurement が欠けると、残り4つも「気分で回る運動」になります。まず計測が DevOps の第一歩です。
段階別の実務 — チームの成熟度で優先することは変わる
「全部やれ」は誰も実行できないので、成熟度ごとに優先順位を切り分けます。現時点での実務的な標準は以下のようになります。
| フェーズ | チーム規模 | 最優先で整えること | 到達目標（DORA換算） |
|---|---|---|---|
| ①始動期 | 〜10人 | CI（テスト自動実行）・構成管理・README | リリース2時間以内／MTTR 1日以内 |
| ②成長期 | 10〜50人 | CD自動化・監視・アラート・オンコール | デプロイ日1回／MTTR 1時間 |
| ③成熟期 | 50〜200人 | SLO運用・エラーバジェット・Feature Flag | 日複数デプロイ／MTTR 30分 |
| ④大規模期 | 200人〜 | Platform Engineering／内部開発者基盤 | 日数十デプロイ／MTTR 15分 |
①始動期でSLOを議論するのは時期尚早、逆に③成熟期でまだ手動デプロイなのは怠慢。フェーズが早すぎる投資も遅すぎる投資も事故、というのが実務の感覚です。
9割のチームはフェーズ①〜②、Elite の多くがフェーズ③、Platform Engineering（④）は現時点でもまだ少数派です。
Platform Engineering — 近年の主戦場
Platform Engineering（プラットフォームエンジニアリング）は2020年頃から急速に広まった DevOps の次の波で、核心は「内部開発者基盤（IDP＝Internal Developer Platform）を専門チームが作り、アプリ開発者はそこに乗るだけにする」という考え方です。
かつて「開発チームが全部やる」というのが DevOps の理想でしたが、現場では認知負荷が上がりすぎて破綻するチームが続出しました。Platform Engineering は「開発者体験（DX＝Developer Experience）を専門に設計するプラットフォームチームを置こう」という、役割の再発見の動きです。
| 観点 | 旧来のDevOps | Platform Engineering |
|---|---|---|
| 誰が | 各開発チームが | プラットフォームチームが |
| 何を | 全部自前で | 共通基盤を提供 |
| 使う側 | 全員が全てを把握 | 開発者はAPIで使う |
| 代表事例 | 〜2019頃のNetflix | SpotifyのBackstage |
Backstage（Spotify が OSS 化した IDP フレームワーク、2020年公開）が Platform Engineering の象徴です。
SLOとエラーバジェット — SREの核心を1枚で
SLO を「月間可用性 99.9%」と決めれば、月に約43分は止まってよいという計算が自動で出ます。この「止まってよい時間」がエラーバジェット（Error Budget）で、予算内なら攻めてよい・超過したら守りに回る、という速度と安定性のトレードオフを数値で回せるようになります。
| 状態 | 判断 |
|---|---|
| エラーバジェット余裕あり | 積極的にリリース、実験もOK |
| エラーバジェット残20%未満 | 新機能を抑え、安定性向上に投資 |
| エラーバジェット使い切り | リリース凍結、インシデント再発防止に集中 |
これが SRE の決定的な発明です。「安定性と速度、どちらを優先しますか」という不毛な議論が、数値で自動的に解決される。詳細は別記事で扱います。
100%の可用性は目標ではない。目指した瞬間にコストが無限に膨らむ──これが SRE 思想の逆説です。
歴史的事件 — 全部DevOps／SREの教訓になっている
DevOps／SRE の各原則は、実際に起きた大事故から逆算して作られています。章全体を貫く教訓として、3つだけポイントを示します（事件の詳細は付録「重大インシデント事例集」）。
| 事件 | DevOps/SREへの教訓 |
|---|---|
| Knight Capital 2012年（45分・4.4億ドル損失・倒産） | Feature Flag使い回し禁止／Canary Release／Kill Switch必須 |
GitLab 2017年（本番DBでrm -rf・バックアップ5つ中4つ壊れ） | リストア訓練を定期実施／取れただけでなく戻せることを確認 |
| Slack 2022年（新年初日にAWS設定変更で数時間停止） | 依存先の冗長化と自前SLOの独立／マルチテナント時代の連鎖障害 |
現代の DevOps／SRE の原則は、過去の惨事から逆算した処方箋です。読まずに原則だけコピーしても、なぜそれが必要かの肌感が持てません。
DevOpsの鬼門・禁じ手
「DevOps をやっている」と言いながら、本質から外した形骸化を何度も見かけます。避けるべき地雷を列挙します。
| 禁じ手 | なぜダメか |
|---|---|
| 専任のDevOpsチームを作る | 新しいサイロが増えるだけ。DevOps は壁を壊す運動 |
| ツール導入だけで文化を変えない | Jenkins を入れても組織が同じなら何も変わらない |
| SLOを決めずにリリース速度だけ上げる | 壊れているのに気づかない、数ヶ月後に大事故 |
| ポストモーテムで犯人探し | 以後誰も正直に報告しなくなり、再発防止が機能しない |
| DevOps＝自動化と矮小化 | Culture／Lean／Sharing を忘れると持続しない |
| 全員が全てをやるの理想化 | 認知負荷で疲弊、Platform Engineering に移行すべき |
| SRE看板で手作業運用を続ける | Toil 50%超はSRE失格、自動化の時間が取れなければ SRE ではない |
| DORA指標をゲーム化 | デプロイ頻度だけ上げて中身が空、という歪み |
| 「うちは特殊だから」で計測しない | 計測しないチームは100%改善しない |
Toil（自動化できるはずなのに手作業で繰り返している運用作業）はSREの中核概念で、チーム全体の業務時間の50%を超えたら危険水域です。
具体数値Gate — DevOps健康診断の閾値
抽象論に流れがちなこの領域で、現時点の数値目安をまとめます。「うちはどこ？」の自己診断に使ってください。
| 項目 | 危険水域 | 許容 | 目指すべき値 |
|---|---|---|---|
| デプロイ頻度 | 月1未満 | 週1 | 日複数回 |
| リードタイム（commit → 本番） | 1ヶ月超 | 1週間 | 1時間未満 |
| MTTR | 1日超 | 1時間 | 30分未満 |
| 変更失敗率 | 30%超 | 15% | 5%未満 |
| Toil比率 | 50%超 | 30% | 20%未満 |
| CI実行時間（PR時） | 30分超 | 10分 | 5分未満 |
| 本番SLO準拠率（直近30日） | SLO未達成 | 達成 | エラーバジェット50%以上残 |
数字で語れないチームは改善できない。まず計測、話はそれからです。
AI時代の視点
AI 駆動開発（バイブコーディング）が前提になると、DevOps／SRE はAIがパイプラインの1ノードとして参加する段階に入ります。現時点で実務化が進んでいるのは、AI による障害解析ファーストレスポンダー（ログを数秒で読み、仮説を立てる）・PRレビューの初手（typo・明らかな不備を潰す）・ポストモーテム下書きの3つです。
前提として機械可読な運用データが揃っていることが条件になります。構造化ログ・OpenTelemetry・IaC／GitOps が敷けているチームは AI の恩恵を直接受け、Confluence に散らばった口伝知識や自然文ログしかないチームは AI 時代に取り残されます。
| AI時代に強いチーム | AI時代に弱いチーム |
|---|---|
| 構造化ログ + OpenTelemetry | 自然文ログ + カスタムフォーマット |
| IaC／GitOpsで宣言的 | 手動SSH + Excel手順書 |
| Markdown + Gitでドキュメント | Confluence + Wordで散在 |
| PR・Issueが意思決定の履歴 | Slackスレッドで議論が流れる |
AIが読めるログを書く。AIが動かせるランブックを書く。それが次世代の DevOps／SRE の出発点です。
よくある勘違い
この領域は誤解が多く、非エンジニア職だけでなく開発者自身も踏みやすい地雷があります。
DevOpsとは「DevOpsチーム」のこと
真逆です。DevOps は開発と運用の壁を壊す運動で、新しい専任チームを作った瞬間に新しいサイロが増え、形骸化します。
SREは運用が上手い人のこと
SRE は信頼性を数値で工学的に扱う方法論。ベテランの勘で運用する人は SRE ではなく、従来の優秀な運用者です。
100%の可用性を目指すべき
100%は目標ではない。目指した瞬間にコストが無限投資になり、開発も止まります。SLO で「壊れてよい量」を合意するのが SRE の核心です。
DevOps＝自動化
自動化は CALMS の A だけ。Culture・Measurement・Sharing が揃わないと、自動化されたパイプラインも1年で腐ります。
DORA指標はEliteを目指せばいい
全チームが Elite である必要はありません。自社のフェーズと比較して Elite かが本質で、始動期のチームに成熟期の数字を求めるのは別種の地雷です。
DevOps／SRE の失敗の9割は、「形だけ真似た」に集約されます。
筆者メモ — 「DevOpsチーム」を作った中堅SIerのその後
業界で繰り返し観察される典型事例を紹介します。
ある中堅SIerが「DevOps化を推進する」と掲げて専任のDevOps推進部を20人規模で立ち上げ、Jenkins・Terraform・Kubernetes を全社導入──ここまでは勢いよく進みました。しかし半年後には、開発チームは「DevOps 部に CI 直してと頼んでも3日待たされる」、DevOps 部は「開発が Terraform を覚えないから全部こっちに流れてくる」と、双方が不満を抱えた新しいサイロが固定化したと報告されています。ツールは揃ったのに、壁は一つ増えた、という DevOps のアンチパターンど真ん中の顛末です。
対照的に、同時期に「DevOpsという言葉を使わない」ことを徹底し、各開発チームがデプロイまで責任を持つ＋横断プラットフォームチームが基盤を提供という Platform Engineering 型に寄せた企業群は、2〜3年かけて静かに DORA Elite に到達した、というケースが複数知られます。DevOpsは看板を掲げると形骸化する、看板を掲げずに原則だけ徹底するのが本命です。
業界で繰り返し観察される法則として、DevOpsの成功事例は、DevOpsという単語をあまり使っていないというものがあります。名乗らずに実践するチームほど、結果として DevOps の原則に忠実になっている、という逆説です。
決めるべきこと — あなたのプロジェクトでの答えは？
以下の項目について、あなたのプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- 現在のチームはDORA 4指標のどの水準か（まず計測）
- どのフェーズ（①始動期〜④大規模期）に今いるか
- SLOを業務部門と数値合意できるか／まだ早いか
- ポストモーテムをBlamelessで運用できる文化があるか
- Platform Engineeringに踏み込むか（200人超が目安）
- 機械可読な運用データ（構造化ログ・IaC・Markdown Runbook）が揃っているか
- DevOpsチームという専任組織を作らずに済ませられるか
最終的な判断の仕方
DevOps／SRE で問われているのは開発と運用を1つのループで回す覚悟です。2009年の DevOpsDays 以来15年以上かけて、「速度と安定性は両立する」という DORA の発見が繰り返し検証され、SLO／エラーバジェットで信頼性を数値で扱う工学手法が Google から広まりました。開発は速くしたい、運用は止めたくないという古い対立は、現代のアーキテクトが設計する対象ではなく、最初から存在しない前提で組むべき領域です。
もう一つの軸は、AIが読める形で運用データを整えること。構造化ログ・IaC／GitOps・Markdown ランブックが揃っていれば、AI エージェントは障害解析・PR レビュー・ポストモーテム下書きで直接戦力になります。逆に自然文ログと手動 SSH の組織は、AI 時代に急速に負債化します。
選定の優先順位
- まずDORA 4指標を計測 — 数字で語れないチームは改善できない
- フェーズに合った投資 — ①始動期で SLO は早すぎ、③成熟期で手動デプロイは遅すぎ
- 「DevOpsチーム」を作らない — 壁を壊す運動に新しい壁を作らない
- 機械可読な運用データ — AI 時代のパイプラインは、そこから入る
「速度と安定性は両立する」DORA と SLO がそれを証明しています。
まとめ
本記事はDevOps・SREの全体像について、起源・SREとの関係・DORA 4指標・CALMS・SLOとエラーバジェット・Platform Engineering・歴史的事件の教訓まで含めて解説しました。如何だったでしょうか。
まずDORA 4指標を計測し、フェーズに合った投資をし、DevOpsチームを作らず、機械可読な運用データを整える。これが2026年のDevOps・SREの現実解です。
次回は構成管理（Git・ブランチ戦略・モノレポ）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（55/89）