DevOps・SREの全体像 ― 速度と安定性は両立する ― 生成AI時代のアーキテクチャ超入門

本記事について

当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「開発運用アーキテクチャ」カテゴリ第2弾として、DevOps・SREの全体像について解説する記事です。

DevOps（2009年〜の文化運動）とSRE（2003年〜のGoogle発工学手法）は同じゴールを別の道で登ったと捉えるのが実務的な見方です。本記事では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といった有名な文化改革も、この越境を先取りした事例として知られます。

DevOpsとSREは、別物なのか

よく混同される2つですが、起源が違い、強調点が違うと押さえると整理できます。

DevOpsは2009年のDevOpsDays（ベルギー）に始まる文化・組織論が主戦場で、「開発と運用の協働」をゴールにCI/CD・自動化・計測・共有を広める運動です。対してSREは2003年にGoogle社内で生まれ2016年に書籍化された工学手法で、SLOとエラーバジェット（壊れてよい予算）を核に、運用の意思決定を数値で回す方法論です。前者の主戦場はプロセスとパイプライン、後者の主戦場は本番運用と信頼性。実装としてのSREはDevOpsの部分集合、とGoogle自身が説明しています。対立項ではなく、SREはDevOpsを実装する一つの方法です。

DORA 4指標 — 強いチームと弱いチームを分ける数字

DORAは、世界中のチームを10年近く調査して、強いチームと弱いチームの差は4つの数値に集約されると結論付けました。この4指標が、DevOps・SREの改善成果を測る共通言語になっています。

注目すべきは速度と安定性は両立するという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）の5つで、それぞれこの章の各記事に対応しています。

特にMeasurementが欠けると、残り4つも「気分で回る運動」になります。まず計測がDevOpsの第一歩です。

段階別の実務 — チームの成熟度で優先することは変わる

「全部やれ」は誰も実行できないので、成熟度ごとに優先順位を切り分けます。現時点での実務的な標準は以下のようになります。

①始動期でSLOを議論するのは時期尚早、逆に③成熟期でまだ手動デプロイなのは怠慢。フェーズが早すぎる投資も遅すぎる投資も事故、というのが実務の感覚です。9割のチームはフェーズ①〜②、Eliteの多くがフェーズ③、Platform Engineering（④）は現時点でもまだ少数派です。

Platform Engineering — 近年の主戦場

Platform Engineeringは2020年頃から急速に広まったDevOpsの次の波で、核心は「内部開発者基盤（IDP＝Internal Developer Platform）を専門チームが作り、アプリ開発者はそこに乗るだけにする」という考え方です。

かつて「開発チームが全部やる」のがDevOpsの理想でしたが、現場では認知負荷が上がりすぎて破綻するチームが続出しました。Platform Engineeringは、各開発チームが全部自前で持つ代わりに、プラットフォームチームが共通基盤を提供し、開発者はAPIとして使う──「開発者体験（DX＝Developer Experience）を専門に設計するチームを置こう」という役割の再発見の動きです。SpotifyがOSS化したIDPフレームワークBackstage（2020年公開）がその象徴です。

SLOとエラーバジェット — SREの核心を1枚で

SLOを「月間可用性99.9%」と決めれば、月に約43分は止まってよいという計算が自動で出ます。この「止まってよい時間」がエラーバジェット（Error Budget）です。予算に余裕があれば積極的にリリースして実験もOK、残り20%を切ったら新機能を抑えて安定性向上に投資、使い切ったらリリース凍結して再発防止に集中──予算内なら攻めてよい・超過したら守りに回るが数値で自動的に決まります。

これがSREの決定的な発明です。「安定性と速度、どちらを優先しますか」という不毛な議論が、数値で自動的に解決される。100%の可用性は目標ではない──目指した瞬間にコストが無限に膨らむ、というのがSRE思想の逆説です。詳細はSLOとSLIの記事で扱います。

歴史的事件 — 全部DevOps／SREの教訓になっている

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の原則は、過去の惨事から逆算した処方箋です。原則だけコピーしても、なぜそれが必要かの肌感が持てません。

具体数値Gate — DevOps健康診断の閾値

※ 2026年4月時点の業界相場値です。

抽象論に流れがちなこの領域で、現時点の数値目安をまとめます。「うちはどこ？」の自己診断に使ってください。

Toil（自動化できるはずなのに手作業で繰り返している運用作業）はSREの中核概念で、チーム全体の業務時間の50%を超えたら危険水域です。数字で語れないチームは改善できない。まず計測、話はそれからです。

AI判断軸 ― SREのトイルがAIの守備範囲になる

SREの日常業務がAIによる自動化の対象になりつつある

SREの業務のうち、トイルに分類される作業はAIによる自動化の最有力候補です。証明書の更新・ディスクのクリーンアップ・不要なリソースの停止・アラート対応の初動判断──これらはRunbookとしてコード化されていれば、AIエージェントが自動実行できます。

Googleが2016年に公開した「SRE本」では「トイルは50%以下に抑える」と示されていましたが、AI時代にはさらに低い水準が目指せます。人間のSREは戦略的な信頼性改善・アーキテクチャレビュー・エラーバジェットの交渉に集中する方向にシフトしています。

DORA指標の自動計測とAI分析

デプロイ頻度・リードタイム・変更失敗率・MTTRの4指標は、GitHub API・CIパイプラインのログ・Observabilityツールのデータから自動計測可能です。AIはこれらの時系列データを分析し、「水曜のデプロイ頻度が低いのはレビュー待ちが原因」「変更失敗率が上がったのは特定チームのPRサイズが大きいため」のようなインサイトを提示できます。前提はどちらも、運用データが機械可読な形（構造化ログ・IaC・Markdown Runbook・PR / Issue履歴）で存在することです。

やってはいけないこと

「DevOpsをやっている」と言いながら本質から外れる形骸化の典型を、6つに絞ります。

なおSRE看板で手作業運用を続けるのも要注意です。Toilが50%を超えて自動化の時間が取れない状態は、名前が何であれSREではありません。

筆者メモ — 「DevOpsチーム」を作った中堅SIerのその後

ある中堅SIerが「DevOps化を推進する」と掲げて専任のDevOps推進部を20人規模で立ち上げ、Jenkins・Terraform・Kubernetesを全社導入──ここまでは勢いよく進みました。しかし半年後には、開発チームは「DevOps部にCI直してと頼んでも3日待たされる」、DevOps部は「開発がTerraformを覚えないから全部こっちに流れてくる」と、双方が不満を抱えた新しいサイロが固定化したと報告されています。ツールは揃ったのに、壁は一つ増えた、というアンチパターンど真ん中の顛末です。

対照的に、同時期に「DevOpsという言葉を使わない」ことを徹底し、各開発チームがデプロイまで責任を持つ＋横断プラットフォームチームが基盤を提供というPlatform Engineering型に寄せた企業群は、2〜3年かけて静かにDORA Eliteに到達した、というケースが複数知られます。業界で繰り返し観察される法則として、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 も合わせて参考にしてください。

それでは次の記事も閲覧いただけると幸いです。