本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「開発運用アーキテクチャ」カテゴリ第13弾として、SREプラクティスについて解説する記事です。
SREは運用を排除するエンジニアリング──手作業の削減こそが本業です。本記事ではトイル削減・SLOによる優先順位・エラーバジェット運用・カオスエンジニアリング・PRR・Platform Engineeringまで、Google発の運用工学を実務に落とす設計を扱います。
本記事のテーマについてさらに詳しく知りたい方は『ITアーキテクチャのセオリー』も参考にしてみてください。
この記事の結論
- プラクティスは段階的に導入する
- Toil（手作業）を50%以下に抑える
- ルーチン作業はAIOpsに委譲していく
この記事を読む前に
本記事は開発・テスト・リリース・監視といった、サービスを作って動かし続ける工程の話が中心です。IT用語にあまり馴染みがない方は、基礎編の「開発から運用までの流れ」を先に読んでおくと格段に分かりやすくなると思います。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそもSREプラクティスとは何か
工場の生産管理を想像してください。優れた工場は、作業員が毎回手作業で品質チェックするのではなく、検査の自動化・不良品の早期発見・ラインの停止基準・改善サイクルを仕組みとして持っています。個人の腕に頼らず、仕組みで品質を保つのが生産管理の本質です。
SREプラクティスはシステム運用における生産管理手法です。Googleが体系化したトイル（手作業）の削減・SLOによる優先順位づけ・エラーバジェット運用・カオスエンジニアリングなどの具体的な手法群で、運用の品質を属人性なく維持・改善します。
もしSREプラクティスがなければ、運用は終わりのない手作業の繰り返しになります。エンジニアはアラート対応に追われ、本質的な改善に時間を割けなくなります。
なぜSREが必要か
第一に、クラウド・マイクロサービスで運用が複雑化したからです。数百サービスが動く現代システムを手作業ベースで管理するのは不可能で、コードで運用するアプローチが必須です。第二に、開発速度と信頼性の両立のためです。従来のオペレーションチームは「変更を止めて安定化」を好みがちで開発と対立しましたが、SREはエラー予算という数値で両者を調停します。第三に、手作業のオンコール・アラート対応はエンジニアを消耗させるからです。自動化で負担を減らし、本質的な問題解決にフォーカスさせます。
SREの主要プラクティス
Google SREの書籍で体系化された主要な8つのプラクティスです。これらを組み合わせて運用文化を作ります。
| プラクティス | 内容 |
|---|---|
| SLO／エラー予算 | 数値で信頼性を管理 |
| Toil削減 | 繰り返し作業を自動化 |
| ポストモーテム | Blameless 振り返り |
| オンコール設計 | ローテーション・負荷管理 |
| キャパシティ計画 | スケール予測と備え |
| Incident Response | 障害対応の仕組み化 |
| カオスエンジニアリング | 意図的に壊して学ぶ |
| Production Readiness Review | 本番投入前の審査 |
SLO・エラー予算・ポストモーテム・インシデント対応は各記事で詳述したので、本記事では残りを中心に扱います。
Toil（トイル）の削減 — SREの本業
繰り返しの手作業・自動化可能な運用作業をGoogleではToilと呼び、SRE時間の50%以下に抑えるという明示的な目標があります。50%を超えるとSREが開発できなくなり、組織として価値を生めなくなります。
典型的なToilは、サーバー再起動（→自動復旧へ）、ログ調査（→オブザーバビリティ基盤へ）、権限付与（→セルフサービス化へ）、アラート対応（→Runbookの自動実行へ）です。Toilは悪ではないが、成長しない仕事です。SREはこれを排除するコードを書くのが本業で、月20%以上を自動化に投資するのが経験則です。
エラー予算の運用はその調停装置です。
エラー予算残 70% ─▶ 新機能をバンバン出す
エラー予算残 30% ─▶ 慎重に・注意深く
エラー予算残 5% ─▶ リリース凍結・安定化
エラー予算残 0% ─▶ 新機能停止・品質集中「リリース止めろ」ではなく「予算が枯渇した」という客観的事実で判断できるため、開発チームと運用チームの対立が解消されます。
カオスエンジニアリングとPRR
カオスエンジニアリングは、意図的に本番で障害を起こしてシステムの耐障害性を検証する手法です。NetflixのChaos Monkeyが起源で、「本番でインスタンスをランダムに落とす」ことで、常に障害に耐える設計を強制します。ツールは商用総合のGremlin、K8s向けOSSのChaos Mesh / LitmusChaos、AWS統合のAWS FISが定番です。壊れる練習を定期的に実施することで、本番障害時に慌てない組織を作ります。ただし本番未経験でいきなり始めるのは危険で、まずステージングで練習します。
PRR（Production Readiness Review）は、新サービスを本番投入する前の審査です。可観測性（メトリクス・ログ・トレース）・SLO定義・キャパシティ・デプロイ戦略・災害対策・オンコール体制の6観点をSREチームが評価し、通過しないサービスは本番投入しないというゲートで品質を担保します。
キャパシティ計画も継続的な取り組みです。ビジネス計画からの需要予測→現状のリソース余裕の把握→最初に詰まるボトルネックの特定→調達計画→負荷試験→月次・四半期の見直し、というサイクルを回します。急成長が見込まれるサービスほど余裕を多めに持つのが安全策です。
Platform Engineering — SREの発展形
SREの思想を発展させ、社内の開発者体験を向上させる専門チームがPlatform Engineeringです。Internal Developer Platform（IDP）としてセルフサービスポータル（デプロイ・環境作成）・Golden Path（標準技術スタック）・自動化ツール・共通監視基盤を提供し、各開発チームが自律的に・安全にデプロイ・運用できる環境を整えます。Spotify製OSSのBackstageが代表的なIDPです。位置づけの詳細はDevOps・SREの全体像を参照してください。
3つのシナリオで考える
個人開発・小規模チームの場合
開発者がSREを兼任して、Phase 1〜2だけやれば十分です。CloudWatchなどでメトリクス基盤を整えて、SLIの測定までできれば上出来だと思います。SLO運用やエラー予算、PRRは組織が成熟してからで構いません。Toilについては「月2時間以上の手作業」を見つけて自動化する、という程度で問題ないでしょう。
中小SaaS企業の場合
SRE兼任のエンジニア1〜2名でSLOの試験運用とToil削減文化を育てる段階です。Phase 3まで推進して、エラー予算でリリース判断を行い、RunbookをGitで管理します。専任チーム化（3名〜）ができたら、PRRや月次のカオス演習、BackstageでのIDP構築に進むと開発速度が上がってきます。
大企業・規制業種の場合
中央SREと事業部SREの二層構造にAIOpsを組み合わせる形になります。全社標準（Golden Path）は中央が提供して、事業部は独自のSLOを運用します。Datadog Bits AIやResolve AIなどでルーチン対応を自動化して、人間は戦略と改善設計に集中できる体制を目指したいところです。
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公式の指針。月20%を自動化投資に割り当てるのが、Toilを維持可能なレベルに抑える経験則です。SREは看板ではなく時間の使い方──Toil 50%を超えたら看板だけで、本物のSREではありません。
AI判断軸 ― AIOpsが第3段階へ進みつつある
AIOpsが段階的に導入されている現実の構成
2026年時点で実用レベルのAIOps導入は以下の3段階で進んでいます。
- 第1段階：異常検知の自動化（メトリクスのベースライン逸脱をAIが検知→人間にアラート）
- 第2段階：根本原因の推定（ログ・トレース・メトリクスを横断してAIがRCA→Slackに通知）
- 第3段階：自動復旧（Runbookに従ってAIが復旧操作を実行→人間は事後確認）
多くの組織は第1〜2段階にいますが、第3段階に進むには信頼できるRunbookのコード化と、AIの操作権限をIAMで厳密に制御する設計が前提です。
Toil自動化のROIがAIで変わった
従来、Toilの自動化は「自動化スクリプトの開発コスト vs 手作業の繰り返しコスト」で判断していました。AIがRunbookを読んで自動実行する構成では、自動化スクリプトをゼロから書く必要がなく、Markdownの手順書を整備するだけでAIが実行できるケースが増えています。自動化の投資対効果が大幅に改善されたと言えます。
やってはいけないこと
SRE導入で事故る典型を、特に危険な6つに絞ります。どれも看板を掛け替えただけで中身が変わらない構造を持ちます。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
| 既存運用チームの名刺をSREに変えるだけ | 1年経ってもToil率95%のまま → コードを書く時間と権限をセットで与える |
| SLOを決めて放置 | 誰も見ない飾りになる → 四半期レビューを必須にする |
| Toilをゼロにしようとする | 現実的に無理で疲弊する → 50%以下がGoogleの指針 |
| 本番未経験でカオスエンジニアリング開始 | 初回で大事故になる → まずステージングで練習する |
| PRRなしで新サービス投入 | 監視・SLO・Runbook未整備のまま本番へ → 投入前審査をゲート化する |
| オンコール負荷を測定しない | 月5回以上の深夜呼び出しでSREが離職 → 呼び出し回数を計測し削減目標を持つ |
筆者メモ — 「SRE看板」と「本物のSRE」の違いが可視化された事例
Googleが2003年にSREチームを立ち上げ、2016年の書籍『Site Reliability Engineering』でその実践が公開されて以降、世界中の企業が追随しました。ところが日本企業を中心に、既存の運用チームの名刺を「SRE」に変えただけで、実態は手作業の夜間オンコールと電話対応のまま、という事例が相次ぎました。コードを書く時間も権限も与えられず、1年経ってもToil率は95%、SLOは形だけ定義されたまま誰も見ていない、という笑えない現場は今でも繰り返し語り草になっています。
対照的に、NetflixはSRE思想の徹底で有名です。2010年代からChaos Monkeyで本番インスタンスをランダムに殺し続けており、本番で壊れる前提の設計が当たり前になりました。その結果、AWSの部分障害が起きてもNetflixだけは平然とサービスを続ける、という事例が何度も観測されています。
「SREと名乗ればSREになる」のではなく、Toil削減にコードで立ち向かう時間を持てるかだけがSREの本質を決めます。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- SRE組織の配置（中央 / 分散 / 兼任）
- SLO管理プロセス（設定・見直し頻度）
- エラー予算の運用ルール（凍結基準）
- Toil削減目標（50%以下・自動化投資率）
- カオスエンジニアリング（頻度・範囲）
- PRRプロセス（新サービス投入審査）
- AIツール採用（AIOps・自動診断）
この記事に関連する記事
まとめ
本記事はSREプラクティスについて、主要プラクティス・Toil削減・エラー予算運用・カオスエンジニアリング・PRR・Platform Engineering・AIOps協働まで含めて解説しました。如何だったでしょうか。
段階的に導入し、Toilを50%以下に抑え、エラー予算でバランス調停、AIOpsでルーチンを委譲する。これが2026年のSREプラクティスの現実解です。
次回はドキュメンテーション（README・ADR・Runbook）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は Google SRE Workbook も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（72/95）