本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「開発運用アーキテクチャ」カテゴリ第13弾として、SREプラクティスについて解説する記事です。
SREは運用を排除するエンジニアリング──手作業の削減こそが本業です。本記事ではトイル削減・SLOによる優先順位・エラーバジェット運用・カオスエンジニアリング・オンコールローテーション・チームトポロジー（Embedded SRE / Platform SRE）まで、Google発の運用工学を実務に落とす設計を扱います。
このカテゴリの他の記事
なぜSREが必要か
クラウド・マイクロサービスで運用が複雑化
数百サービスが動く現代システムを、従来の「手作業ベースの運用」で管理するのは不可能です。コードで運用するSRE のアプローチが必須になります。
開発速度と信頼性の両立
従来のオペレーションチームは「変更を止めて安定化」を好みがちで、開発と対立しました。SRE はエラー予算という数値で両者を調停します。
エンジニアの運用負担を減らす
手作業のオンコール・アラート対応はエンジニアを消耗させます。SRE は自動化で負担を減らし、本質的な問題解決にフォーカスさせます。
SREの主要プラクティス
Google SRE の書籍で体系化された主要な8つのプラクティスです。これらを組み合わせて運用文化を作ります。
flowchart TB
SRE([SRE実装])
subgraph MEAS["測る"]
SLO[SLO/エラー予算]
CAP[キャパシティ計画]
end
subgraph REDUCE["減らす"]
TOIL[Toil削減<br/>繰り返し作業の自動化]
CHAOS[カオスエンジニアリング]
end
subgraph LEARN["学ぶ"]
PM[ポストモーテム<br/>Blameless]
PRR[Production<br/>Readiness Review]
end
subgraph RESPOND["備える"]
IR[Incident Response]
ON[オンコール設計]
end
SRE --> MEAS
SRE --> REDUCE
SRE --> LEARN
SRE --> RESPOND
classDef sre fill:#fef3c7,stroke:#d97706,stroke-width:2px;
classDef m fill:#dbeafe,stroke:#2563eb;
classDef r fill:#dcfce7,stroke:#16a34a;
classDef l fill:#fae8ff,stroke:#a21caf;
classDef p fill:#f0f9ff,stroke:#0369a1;
class SRE sre;
class MEAS,SLO,CAP m;
class REDUCE,TOIL,CHAOS r;
class LEARN,PM,PRR l;
class RESPOND,IR,ON p;| プラクティス | 内容 |
|---|---|
| SLO／エラー予算 | 数値で信頼性を管理 |
| Toil削減 | 繰り返し作業を自動化 |
| ポストモーテム | Blameless 振り返り |
| オンコール設計 | ローテーション・負荷管理 |
| キャパシティ計画 | スケール予測と備え |
| Incident Response | 障害対応の仕組み化 |
| カオスエンジニアリング | 意図的に壊して学ぶ |
| Production Readiness Review | 本番投入前の審査 |
Toil（トイル）の削減
繰り返しの手作業・自動化可能な運用作業を Google では Toil と呼び、SRE時間の50%以下に抑えるという明示的な目標があります。50% を超えると SRE が開発できなくなり、組織として価値を生めなくなります。
| Toilの例 | 自動化への道 |
|---|---|
| サーバー再起動 | 自動復旧 |
| ログ調査 | オブザーバビリティ基盤 |
| 権限付与 | セルフサービス化 |
| マイグレーション | CI/CD |
| アラート対応 | Runbook の自動実行 |
Toilは悪ではないが、成長しない仕事です。SRE はこれを排除するコードを書くのが本業で、月20%以上を自動化に投資するのが理想です。
エラー予算の運用
SRE の中核は SLOに対するエラー予算で運用を律することです。エラー予算が残っているうちは開発を加速、枯渇したら信頼性投資に回す、という明示的な切替をします。
エラー予算残 70% ─▶ 新機能をバンバン出す
エラー予算残 30% ─▶ 慎重に・注意深く
エラー予算残 5% ─▶ リリース凍結・安定化
エラー予算残 0% ─▶ 新機能停止・品質集中この仕組みは開発チームと運用チームの対立を解消します。「リリース止めろ」ではなく「予算が枯渇した」という客観的事実で判断できるためです。
カオスエンジニアリング
意図的に本番で障害を起こし、システムの耐障害性を検証する手法です。Netflix の Chaos Monkey が起源で、「本番でインスタンスをランダムに落とす」ことで、常に障害に耐える設計を強制します。
| ツール | 用途 |
|---|---|
| Chaos Monkey | インスタンス停止 |
| Gremlin | 商用・総合的 |
| Chaos Mesh | K8s 向け OSS |
| LitmusChaos | K8s・CNCF |
| AWS FIS | AWS 統合サービス |
「障害は起きる前提」のシステムアーキテクチャが前提で、壊れる練習を定期的に実施することで、本番障害時に慌てない組織を作ります。
SLO文化の浸透
SLO を入れるだけでは機能しません。組織文化としての定着が必要で、以下の習慣が重要です。
| 習慣 | 内容 |
|---|---|
| SLOレビュー | 四半期に目標見直し |
| 週次SLI確認 | 実測値のトレンド監視 |
| 予算枯渇対応 | 計画的な凍結・安定化 |
| ステークホルダー合意 | ビジネス側との協議 |
「100%稼働＝理想」の発想を捨てるのが文化変革の核心です。SLO は「完璧を目指さず、十分を目指す」の象徴です。
キャパシティ計画
将来のトラフィック増に備えた計画です。後手に回ると障害・機会損失に直結するため、SRE が継続的に取り組む重要領域です。
| ステップ | 内容 |
|---|---|
| 需要予測 | ビジネス計画とトラフィック |
| 現状把握 | リソース利用率・余裕 |
| ボトルネック特定 | 最初に詰まる箇所 |
| 調達計画 | クラウド予約・契約 |
| 負荷試験 | 予測値での検証 |
| 定期見直し | 月次・四半期 |
急激な成長が見込まれるサービスほど、余裕を多めに持つのが安全策です。
Production Readiness Review
新サービスを本番投入する前の審査を行う仕組みです。Google では PRR（Production Readiness Review）と呼ばれ、SRE チームが開発チームのサービスを評価します。
| 観点 | 内容 |
|---|---|
| 可観測性 | メトリクス・ログ・トレース整備 |
| SLO定義 | 目標値と測定方法 |
| キャパシティ | 想定負荷への耐性 |
| デプロイ戦略 | 安全なリリース手順 |
| 災害対策 | 障害時の復旧手順 |
| オンコール体制 | 対応者・手順書 |
PRRを通過しないサービスは本番投入しないというゲートがあることで、品質が担保されます。
DevOpsとの関係
SRE は DevOpsの具体的な実装と位置付けられます。DevOps が理念・文化なら、SRE は実務の型です。
| DevOps | SRE | |
|---|---|---|
| 位置付け | 思想・文化 | 具体的プラクティス |
| 起源 | 2009年頃・Patrick Debois | 2003年・Google |
| 焦点 | 開発と運用の統合 | 運用をエンジニアリングで解く |
| 指標 | DORA 4指標 | SLO・エラー予算 |
| 役割 | 明確な役割なし | SRE エンジニア |
「DevOpsは理想、SREは実装パターン」と言われることもあります。
プラットフォームエンジニアリング
SRE の思想を発展させ、社内の開発者体験を向上させる専門チームが Platform Engineering です。Internal Developer Platform（IDP）を提供し、各開発チームが自律的に・安全にデプロイ・運用できる環境を整えます。
| 提供物 | 内容 |
|---|---|
| セルフサービスポータル | デプロイ・環境作成 |
| Golden Path | 標準的な技術スタック |
| 自動化ツール | CI/CD・IaC |
| 監視基盤 | 共通オブザーバビリティ |
Backstage（Spotify 製 OSS）が代表的な IDP で、多くの企業で採用されています。
判断基準①：組織規模
SRE の導入レベルは組織規模で決まります。全社 SRE チームを作るのは中堅以上の企業で、スタートアップは兼任で始めるのが現実的です。
| 規模 | 推奨 |
|---|---|
| スタートアップ | 開発者が SRE 兼任 |
| 中堅 | SRE チーム（2〜5名） |
| 大企業 | 組織ごとに SRE 配置 |
| グローバル | 中央 SRE + 各事業 SRE |
判断基準②：組織の成熟度
SRE は段階的に導入するのが現実的です。全てを一度に始めると混乱します。
| Phase | 内容 |
|---|---|
| Phase 1 | メトリクス・ログ基盤 |
| Phase 2 | SLI 測定・SLO 試験運用 |
| Phase 3 | エラー予算運用 |
| Phase 4 | Toil 自動化投資 |
| Phase 5 | カオスエンジニアリング |
ケース別の選び方
個人開発・小規模チーム
開発者が SRE 兼任 + Phase 1〜2のみ。メトリクス基盤（CloudWatch 等）を整え、SLI 測定まででOK。SLO 運用・エラー予算・PRR は組織成熟後に。Toil は「月2時間以上の手作業」を見つけて自動化する程度で十分です。
スタートアップ・成長期SaaS
SRE 兼任エンジニア1〜2名 + SLO 試験運用 + Toil 削減文化。Phase 3まで推進、エラー予算でリリース判断、Runbook を Git 管理。Backstage でセルフサービスポータルを作り始めると開発速度が上がります。
中堅企業・マイクロサービス運用
専任 SRE チーム3〜10名 + PRR + カオス演習。Phase 5まで全実施、LitmusChaos／AWS FIS で月次カオス演習、Platform Engineering チームで IDP を構築。Toil 削減 KPI（Key Performance Indicator＝重要業績評価指標）を組織目標に含めます。
大企業・規制業種
中央 SRE + 事業部 SRE の二層構造 + AIOps。全社標準（Golden Path）は中央が提供、事業部は独自 SLO 運用。Datadog Bits AI／Resolve AI でルーチン対応を自動化し、人間は戦略・改善設計に集中します。
よくある勘違い
SREはインフラ運用者のこと
違います。ソフトウェアエンジニアリングで運用問題を解く専門家です。コードを書かないSREは価値が低い。
SLOを決めればSRE
SLO は手段の一つ。文化・プロセス・自動化の総体が SRE です。
Toilはゼロにすべき
現実には無理。50%以下が Google の指針。新機能の必要な手作業はあります。
SREは運用チームの新しい名前
看板を掛け替えるだけでは機能しません。権限・文化・採用基準から変革が必要です。既存の運用チームに「SRE」という名前を付けただけで、やることは深夜の手作業オンコールのまま、コードを書く時間も権限も与えられず、1年経っても Toil 率は95%だった、という笑えない事例は日本企業を中心に数多く語られています。看板ではなく、時間の使い方が SRE を定義します。
SRE成熟度の段階別ロードマップ
SRE は一夜で実現しない文化変革です。Google SRE Workbook に準拠した段階的導入が現実的です。
| フェーズ | 期間目安 | 実装内容 | 必要なSRE人員 |
|---|---|---|---|
| Phase 1: 計測基盤 | 〜6か月 | Prometheus／Datadog 導入、メトリクス・ログ整備 | 0〜1人（兼任） |
| Phase 2: SLO試験運用 | 〜1年 | SLI 選定、実測、目標値の仮設定 | 1〜2人 |
| Phase 3: エラー予算運用 | 〜1.5年 | 予算枯渇でリリース凍結ルール、四半期見直し | 2〜5人 |
| Phase 4: Toil削減文化 | 〜2年 | Toil 50%以下目標、自動化投資20%、Runbook as Code | 3〜10人 |
| Phase 5: カオス・IDP | 〜3年 | カオスエンジニアリング月次、Backstage等IDP構築 | 5人〜 |
| Phase 6: AIOps | 〜5年 | PagerDuty AIOps／Resolve AI等で一次対応自動化 | Prompt + Systems Engineer |
Toilの目標ラインは、SRE 時間の50%以下が Google 公式の指針。50%超えるとSRE が開発できず、組織として価値を生めません。月20%を自動化投資に割り当てるのが、Toil を維持可能なレベルに抑える経験則です。
SRE は看板ではなく時間の使い方。Toil 50%超えたら看板だけ、本物の SRE ではありません。
SRE運用の鬼門・禁じ手
SRE 導入で事故る典型パターン。どれも看板を掛け替えただけで中身が変わらない構造を持ちます。
| 禁じ手 | なぜダメか |
|---|---|
| 既存運用チームの名刺をSREに変えるだけ | 1年経っても Toil 率95%、コードを書かない SRE は価値ゼロ |
| SREにコードを書く権限・時間を与えない | 運用屋のまま、本質的価値を生まない |
| SLOを決めて放置 | 誰も見ない、四半期見直し必須 |
| Toilをゼロにしようとする | 現実的に無理、50%以下が Google の指針 |
| カオスエンジニアリングを本番未経験で開始 | 初回で大事故、まずステージングで練習 |
| PRR（Production Readiness Review）なしで新サービス投入 | 監視・SLO・Runbook 未整備のサービスが本番へ |
| エラー予算枯渇でもリリース継続 | 信頼性崩壊、エラー予算運用の意味なし |
| オンコール負荷を測定しない | 月5回以上の深夜呼び出しで SRE 疲弊・離職 |
| 独立したSREチームを作らない | 開発チームの下請けに堕ちる |
| Platform Engineering／IDPの投資を先送り | 各チームが独自運用、標準化されず非効率 |
日本企業のSRE看板問題（既存運用チームに「SRE」という名前を付けただけ、やることは深夜の手作業オンコールのまま、コードを書く時間も権限もなく、1年経っても Toil 率95%）は、「看板ではなく、時間の使い方がSREを定義する」という教訓を突きつけます。Netflix は2010年代から Chaos Monkey で本番をランダムに殺し続け、AWS 部分障害でも平然とサービス継続──この差が「本物の SRE」と「名前だけ」の違いです。
SRE はToilを殺しに行くエンジニアリング。手作業で回っているなら、まだスケールしていない証拠です。
AI時代の視点
AI 駆動開発（バイブコーディング）と AI 活用が前提になると、SRE はAIエージェントと協働する運用へと進化します。Toil 削減の究極形は AI が自律的に運用判断を下すことで、Datadog Bits AI・PagerDuty AIOps・Resolve AI 等が既に商用化されています。
| AI時代に有利 | AI時代に不利 |
|---|---|
| Runbook のコード化 | 手順が人の頭の中 |
| 構造化ログ・メトリクス | 文字列ログ中心 |
| 自動化済みの Toil | 手作業残留 |
| 定量的な信頼性管理 | 感覚的な運用 |
SRE の将来像はAIエージェントを管理する人間です。AI が一次対応し、人間はエージェントの学習・判断基準の設計に集中します。AI 時代の SRE は Prompt Engineer + Systems Engineer の融合職になりつつあります。
AI 時代の SRE は運用の自動化をAIに委ね、戦略設計に集中します。
決めるべきこと — あなたのプロジェクトでの答えは？
以下の項目について、あなたのプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- SRE組織の配置（中央／分散）
- SLO管理プロセス（設定・見直し頻度）
- エラー予算の運用ルール（凍結基準）
- Toil削減目標（50%以下・自動化投資率）
- カオスエンジニアリング（頻度・範囲）
- PRRプロセス（新サービス投入審査）
- AIツール採用（AIOps・自動診断）
筆者メモ — 「SRE看板」と「本物のSRE」の違いが可視化された事例
SRE が表面的な看板か、本物の文化変革かで、組織の運命は大きく分かれます。
Google が2003年に SRE チームを立ち上げ、2016年の書籍『Site Reliability Engineering』でその実践が公開されて以降、世界中の企業が追随しました。ところが日本企業を中心に、既存の運用チームの名刺を「SRE」に変えただけで、実態は手作業の夜間オンコールと電話対応のまま、という事例が相次ぎました。コードを書く時間も権限も与えられず、1年経っても Toil 率は95%、SLO は形だけ定義されたまま誰も見ていない、という笑えない現場は今でも繰り返し語り草になっています。
対照的に、Netflix は SRE 思想の徹底で有名です。Netflix は2010年代から Chaos Monkey で本番インスタンスをランダムに殺し続けており、本番で壊れる前提の設計が当たり前になりました。その結果、AWS の部分障害が起きても Netflix だけは平然とサービスを続ける、という事例が何度も観測されています。ここで見えるのは「SREは看板ではなく、時間の使い方と文化の問題である」という事実です。
「SREと名乗れば SRE になる」のではなく、Toil削減にコードで立ち向かう時間を持てるかだけが SRE の本質を決めます。
最終的な判断の仕方
SRE の核心は運用をエンジニアリングで解くという発想です。従来の手作業ベースの運用は、マイクロサービス数百の現代システムではスケールしません。Google が確立した SRE は、SLO・エラー予算・Toil 削減・ポストモーテム・カオスエンジニアリングなど、運用をコード化・数値化するプラクティスの総体で、個々のツールではなく文化・プロセス・自動化の組み合わせで機能します。「SRE は運用チームの看板を掛け替えたもの」という誤解は最も多いアンチパターンで、権限・文化・採用基準から変革が必要になります。
もう一つの決定的な軸はAIエージェントを管理するSREへの進化です。Datadog Bits AI・PagerDuty AIOps・Resolve AI が一次対応・根本原因候補提示・Runbook 自動実行を担う時代に、人間の SRE はエージェントの学習・判断基準の設計、戦略的な信頼性投資、組織文化の醸成に集中します。Prompt Engineer と Systems Engineer の融合職が、AI 時代の SRE 像です。
選定の優先順位
- 段階的に導入する — Phase 1（計測基盤）→ Phase 5（カオス）の順、一度に全部やらない
- Toilを50%以下に抑える — 超えたらSREが開発できない、自動化に月20%投資
- エラー予算で開発／信頼性のバランス調停 — 残量別にリリース加速／凍結を客観判断
- AIOpsでルーチン対応を委譲 — 人間は戦略・改善設計・エージェント管理に集中
「運用をコードで解き、AIに委ね、戦略に集中する」これが現代の SRE 像です。
まとめ
本記事はSREプラクティスについて、主要プラクティス・Toil削減・エラー予算運用・カオスエンジニアリング・PRR・Platform Engineering・AIOps協働まで含めて解説しました。如何だったでしょうか。
段階的に導入し、Toilを50%以下に抑え、エラー予算でバランス調停、AIOpsでルーチンを委譲する。これが2026年のSREプラクティスの現実解です。
次回はドキュメンテーション（README・ADR・Runbook）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（66/89）