SREプラクティス ― Toil削減とカオス演習 ― 生成AI時代のアーキテクチャ超入門

本記事について

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

SREは運用を排除するエンジニアリング──手作業の削減こそが本業です。本記事ではトイル削減・SLOによる優先順位・エラーバジェット運用・カオスエンジニアリング・オンコールローテーション・チームトポロジー（Embedded SRE / Platform SRE）まで、Google発の運用工学を実務に落とす設計を扱います。

本記事のテーマについてさらに詳しく知りたい方は『ITアーキテクチャのセオリー』も参考にしてみてください。

そもそもSREプラクティスとは何か

工場の生産管理を想像してください。優れた工場は、作業員が毎回手作業で品質チェックするのではなく、検査の自動化・不良品の早期発見・ラインの停止基準・改善サイクルを仕組みとして持っています。個人の腕に頼らず、仕組みで品質を保つのが生産管理の本質です。

SREプラクティスはシステム運用における生産管理手法です。Google が体系化したトイル（手作業）の削減・SLOによる優先順位づけ・エラーバジェット運用・カオスエンジニアリングなどの具体的な手法群で、運用の品質を属人性なく維持・改善します。

もしSREプラクティスがなければ、運用は終わりのない手作業の繰り返しになります。エンジニアはアラート対応に追われ、本質的な改善に時間を割けなくなります。

なぜSREが必要か

クラウド・マイクロサービスで運用が複雑化

数百サービスが動く現代システムを、従来の「手作業ベースの運用」で管理するのは不可能です。コードで運用するSRE のアプローチが必須になります。

開発速度と信頼性の両立

従来のオペレーションチームは「変更を止めて安定化」を好みがちで、開発と対立しました。SRE はエラー予算という数値で両者を調停します。

エンジニアの運用負担を減らす

手作業のオンコール・アラート対応はエンジニアを消耗させます。SRE は自動化で負担を減らし、本質的な問題解決にフォーカスさせます。

SREの主要プラクティス

Google SRE の書籍で体系化された主要な8つのプラクティスです。これらを組み合わせて運用文化を作ります。

Toil（トイル）の削減

繰り返しの手作業・自動化可能な運用作業を Google では Toil と呼び、SRE時間の50%以下に抑えるという明示的な目標があります。50% を超えると SRE が開発できなくなり、組織として価値を生めなくなります。

Toilは悪ではないが、成長しない仕事です。SRE はこれを排除するコードを書くのが本業で、月20%以上を自動化に投資するのが理想です。

エラー予算の運用

SRE の中核は SLOに対するエラー予算で運用を律することです。エラー予算が残っているうちは開発を加速、枯渇したら信頼性投資に回す、という明示的な切替をします。

エラー予算残 70% ─▶ 新機能をバンバン出す
エラー予算残 30% ─▶ 慎重に・注意深く
エラー予算残 5%  ─▶ リリース凍結・安定化
エラー予算残 0%  ─▶ 新機能停止・品質集中

この仕組みは開発チームと運用チームの対立を解消します。「リリース止めろ」ではなく「予算が枯渇した」という客観的事実で判断できるためです。

カオスエンジニアリング

意図的に本番で障害を起こし、システムの耐障害性を検証する手法です。Netflix の Chaos Monkey が起源で、「本番でインスタンスをランダムに落とす」ことで、常に障害に耐える設計を強制します。

「障害は起きる前提」のシステムアーキテクチャが前提で、壊れる練習を定期的に実施することで、本番障害時に慌てない組織を作ります。

SLO文化の浸透

SLO を入れるだけでは機能しません。組織文化としての定着が必要で、以下の習慣が重要です。

「100%稼働＝理想」の発想を捨てるのが文化変革の核心です。SLO は「完璧を目指さず、十分を目指す」の象徴です。

キャパシティ計画

将来のトラフィック増に備えた計画です。後手に回ると障害・機会損失に直結するため、SRE が継続的に取り組む重要領域です。

急激な成長が見込まれるサービスほど、余裕を多めに持つのが安全策です。

Production Readiness Review

新サービスを本番投入する前の審査を行う仕組みです。Google では PRR（Production Readiness Review）と呼ばれ、SRE チームが開発チームのサービスを評価します。

PRRを通過しないサービスは本番投入しないというゲートがあることで、品質が担保されます。

DevOpsとの関係

SRE は DevOpsの具体的な実装と位置付けられます。DevOps が理念・文化なら、SRE は実務の型です。

「DevOpsは理想、SREは実装パターン」と言われることもあります。

プラットフォームエンジニアリング

SRE の思想を発展させ、社内の開発者体験を向上させる専門チームが Platform Engineering です。Internal Developer Platform（IDP）を提供し、各開発チームが自律的に・安全にデプロイ・運用できる環境を整えます。

Backstage（Spotify 製 OSS）が代表的な IDP で、多くの企業で採用されています。

判断基準①：組織規模

SRE の導入レベルは組織規模で決まります。全社 SRE チームを作るのは中堅以上の企業で、スタートアップは兼任で始めるのが現実的です。

判断基準②：組織の成熟度

SRE は段階的に導入するのが現実的です。全てを一度に始めると混乱します。

ケース別の選び方

個人開発・小規模チーム

開発者が 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を組織目標に含めます。

大企業・規制業種

中央 SRE + 事業部 SRE の二層構造 + AIOps。全社標準（Golden Path）は中央が提供、事業部は独自 SLO 運用。Datadog Bits AI／Resolve AI でルーチン対応を自動化し、人間は戦略・改善設計に集中します。

SRE成熟度の段階別ロードマップ

SRE は一夜で実現しない文化変革です。Google SRE Workbook に準拠した段階的導入が現実的です。

Toilの目標ラインは、SRE 時間の50%以下が Google 公式の指針。50%超えるとSRE が開発できず、組織として価値を生めません。月20%を自動化投資に割り当てるのが、Toil を維持可能なレベルに抑える経験則です。

SRE は看板ではなく時間の使い方。Toil 50%超えたら看板だけ、本物の SRE ではありません。

やってはいけないこと

SRE 導入で事故る典型パターン。どれも看板を掛け替えただけで中身が変わらない構造を持ちます。

日本企業のSRE看板問題（既存運用チームに「SRE」という名前を付けただけ、やることは深夜の手作業オンコールのまま、コードを書く時間も権限もなく、1年経っても Toil 率95%）は、「看板ではなく、時間の使い方がSREを定義する」という教訓を突きつけます。Netflix は2010年代から Chaos Monkey で本番をランダムに殺し続け、AWS 部分障害でも平然とサービス継続──この差が「本物の SRE」と「名前だけ」の違いです。

SRE はToilを殺しに行くエンジニアリング。手作業で回っているなら、まだスケールしていない証拠です。

AI判断軸

1. 段階的に導入する — Phase 1（計測基盤）→ Phase 5（カオス）の順、一度に全部やらない
2. Toilを50%以下に抑える — 超えたらSREが開発できない、自動化に月20%投資
3. エラー予算で開発／信頼性のバランス調停 — 残量別にリリース加速／凍結を客観判断
4. AIOpsでルーチン対応を委譲 — 人間は戦略・改善設計・エージェント管理に集中

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が実行できるケースが増えています。自動化の投資対効果が大幅に改善されたと言えます。

決めるべきこと — 自分のプロジェクトでの答えは？

以下の項目について、自分のプロジェクトの答えを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プラクティスについて、主要プラクティス・Toil削減・エラー予算運用・カオスエンジニアリング・PRR・Platform Engineering・AIOps協働まで含めて解説しました。如何だったでしょうか。

段階的に導入し、Toilを50%以下に抑え、エラー予算でバランス調停、AIOpsでルーチンを委譲する。これが2026年のSREプラクティスの現実解です。

次回はドキュメンテーション（README・ADR・Runbook）について解説します。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

本記事で扱った内容の詳細は Google SRE Workbook も合わせて参考にしてください。

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