本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「開発運用アーキテクチャ」カテゴリ第2弾として、DevOps・SREの全体像について解説する記事です。
DevOps（2009年〜の文化運動）と SRE（2003年〜の Google 発工学手法）は同じゴールを別の道で登ったと捉えるのが実務的な見方です。本記事ではWall of Confusion／Wall of Confusionの解消・SLO・エラーバジェット・トイル削減・ポストモーテムなど両者の構成要素を扱い、「開発と運用の分離はもう古い」という現代の合意点を整理します。
本記事のテーマについてさらに詳しく知りたい方は『ITアーキテクチャのセオリー』も参考にしてみてください。
そもそもDevOps・SREとは何か
マンションの管理を想像してください。建設会社（開発）が建てたマンションを、管理会社（運用）が維持管理する──以前はこの2者が完全に分かれていました。建設会社は「建てたら終わり」、管理会社は「変更しないで」と、目標が正反対だったのです。
DevOps は建設と管理を同じチームが担当するという発想の転換です。作る人が運用まで責任を持ち、運用の知見が次の設計にフィードバックされます。SREはこの思想を Google が工学的に体系化したもので、「信頼性を数値で管理し、自動化で運用負荷を下げる」手法論です。
もしDevOps・SREの発想がなければ、開発と運用の間に壁が残り、リリースのたびに対立が起き、障害時には責任の押し付け合いが繰り返されます。
なぜDevOps・SREが必要なのか
Wall of Confusion（開発と運用の間に存在した、ゴールと評価指標が正反対の組織的分断）──開発チームは「機能を速くリリースした数」で評価され、運用チームは「システムが落ちなかった時間」で評価される。目標が構造的に相反するため、リリースのたびに「出したい開発」対「止めたい運用」の綱引きが発生し、障害時には互いの責任を押し付け合う、という文化がかつての業界標準でした。
この壁を壊すために「開発チームがデプロイと運用まで責任を持つ」「運用チームがコードで仕事をする」という、両側からの越境が起きたのがここ15年の動きです。Amazon の API Mandate（2002年）や Netflix の Freedom & Responsibility といった有名な文化改革も、この越境を先取りした事例として知られます。
| 旧世界（〜2009頃） | 新世界（DevOps／SRE 以降） |
|---|---|
| 開発は速度、運用は安定性 | 両方を同じチームが見る |
| デプロイは運用の手作業 | デプロイはパイプラインが実行 |
| 障害時は「誰の責任か」 | 障害時は「どう再発を防ぐか」 |
| 運用は夜中の電話番 | 運用はコードで自動化 |
DevOpsとSREは、別物なのか
よく混同される2つですが、起源が違い、強調点が違うと押さえると整理できます。
DevOps は文化・組織論が主戦場で、「開発と運用の協働」をゴールに CI/CD・自動化・計測・共有を広める運動です。対して SRE は Google 発の工学手法で、SLOとエラーバジェット（壊れてよい予算）を核に、運用の意思決定を数値で回す方法論です。
| 観点 | DevOps | SRE |
|---|---|---|
| 起源 | 2009 DevOpsDays（ベルギー） | 2003 Google 社内 → 2016 書籍化 |
| 主眼 | 文化・組織・協働 | 信頼性のエンジニアリング化 |
| 核となる武器 | CI/CD・自動化・計測・共有 | SLO・エラーバジェット・Toil 削減 |
| 典型的なロール | DevOpsエンジニア（横断） | SRE（信頼性専任） |
| 主戦場 | プロセス・パイプライン | 本番運用・信頼性 |
実装としての SRE は DevOps の部分集合、と Google 自身が説明しています。対立項ではなく、SREはDevOpsを実装する一つの方法です。
DORA 4指標 — 強いチームと弱いチームを分ける数字
DORAは、世界中のチームを10年近く調査して、強いチームと弱いチームの差は4つの数値に集約されると結論付けました。この4指標が、DevOps・SRE の改善成果を測る共通言語になっています。
| 指標 | 意味 | Elite（上位10%） | Low（下位30%） |
|---|---|---|---|
| デプロイ頻度 | どれだけ頻繁に本番に出るか | 日に複数回 | 月1未満 |
| 変更リードタイム | コード commit → 本番まで | 1時間未満 | 1ヶ月超 |
| MTTR | 障害発生 → 復旧までの時間 | 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 は壁を壊す運動 |
| ツール導入だけで文化を変えない | Jenkins を入れても組織が同じなら何も変わらない |
| SLOを決めずにリリース速度だけ上げる | 壊れているのに気づかない、数ヶ月後に大事故 |
| ポストモーテムで犯人探し | 以後誰も正直に報告しなくなり、再発防止が機能しない |
| DevOps＝自動化と矮小化 | Culture／Lean／Sharing を忘れると持続しない |
| 全員が全てをやるの理想化 | 認知負荷で疲弊、Platform Engineering に移行すべき |
| SRE看板で手作業運用を続ける | Toil 50%超はSRE失格、自動化の時間が取れなければ SRE ではない |
| DORA指標をゲーム化 | デプロイ頻度だけ上げて中身が空、という歪み |
| 「うちは特殊だから」で計測しない | 計測しないチームは100%改善しない |
| 「DevOpsとはDevOpsチームのこと」と専任化 | 新しいサイロが増えるだけ、DevOpsは壁を壊す運動 |
| 「100%の可用性を目指すべき」と完璧追求 | コスト無限大・開発停止、SLOで壊れてよい量を合意するのがSREの核心 |
Toil（自動化できるはずなのに手作業で繰り返している運用作業）はSREの中核概念で、チーム全体の業務時間の50%を超えたら危険水域です。
AI判断軸
| AI有利 | AI不利 |
|---|---|
| 構造化ログ + OpenTelemetry | 自然文ログ + カスタムフォーマット |
| IaC／GitOpsで宣言的 | 手動SSH + Excel手順書 |
| Markdown + Gitでドキュメント | Confluence + Wordで散在 |
| PR・Issueが意思決定の履歴 | Slackスレッドで議論が流れる |
- まずDORA 4指標を計測 — 数字で語れないチームは改善できない
- フェーズに合った投資 — 始動期でSLOは早すぎ、成熟期で手動デプロイは遅すぎ
- 「DevOpsチーム」を作らない — 壁を壊す運動に新しい壁を作らない
- 機械可読な運用データ — AI 時代のパイプラインは、そこから入る
SREの日常業務がAIによる自動化の対象になりつつある
SREの業務のうち、トイル（繰り返しの手作業）に分類される作業は、AIによる自動化の最有力候補です。証明書の更新・ディスクのクリーンアップ・不要なリソースの停止・アラート対応の初動判断――これらはRunbookとしてコード化されていれば、AIエージェントが自動実行できます。
Googleが2016年に公開した「SRE本」では「トイルは50%以下に抑える」と示されていましたが、AI時代にはさらに低い水準が目指せます。人間のSREは戦略的な信頼性改善・アーキテクチャレビュー・エラー予算の交渉に集中する方向にシフトしています。
DORA指標の自動計測とAI分析
デプロイ頻度・リードタイム・変更失敗率・MTTRの4指標は、GitHub API・CIパイプラインのログ・Observabilityツールのデータから自動計測可能です。AIはこれらの時系列データを分析し、「水曜のデプロイ頻度が低いのはレビュー待ちが原因」「変更失敗率が上がったのは特定チームのPRサイズが大きいため」のようなインサイトを提示できます。
具体数値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%以上残 |
数字で語れないチームは改善できない。まず計測、話はそれからです。
筆者メモ — 「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の全体像について、起源・SREとの関係・DORA 4指標・CALMS・SLOとエラーバジェット・Platform Engineering・歴史的事件の教訓まで含めて解説しました。如何だったでしょうか。
まずDORA 4指標を計測し、フェーズに合った投資をし、DevOpsチームを作らず、機械可読な運用データを整える。これが2026年のDevOps・SREの現実解です。
次回は構成管理（Git・ブランチ戦略・モノレポ）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は Google - Site Reliability Engineering も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（55/89）