株式会社renue
renueについて
renueは、AIで業務を実装する会社です
AIコンサルティングから図面AI・広告運用エージェント・コールセンターAIまで、実際に動いているサービスをご覧いただけます。renueが何をしている会社か、まずはサービス一覧からご確認ください。
SREとは？Googleが生んだ信頼性エンジニアリングの新標準
SRE（Site Reliability Engineering：サイト信頼性エンジニアリング）は、Googleで2003年に始まった実践に由来するソフトウェアエンジニアリングのアプローチで、システムの信頼性を維持・向上させながら、開発速度の低下を防ぐことを目的としています。従来の「運用チーム」が手作業でシステムを維持するモデルから、「ソフトウェアエンジニアリングで運用の課題を解決する」パラダイムへの転換です。
Catchpoint「The SRE Report 2025」は、2024年7〜8月の6週間に世界のIT・信頼性実務者から集めた301件の回答に基づきます。「今後12か月に組織が導入を優先すべきもの」でSREを選んだ割合が41%、サービスレベル目標または体験レベル目標（SLO／XLO）が40%でした。すでに最優先事項として導入済みの組織割合ではありません。また、53%が「性能低下は停止と同程度に悪い」という考えにおおむね同意しました。これは回答者の認識を示す調査であり、企業全体の割合や実損害の同等性を実証するものではありません。
SREの核心概念：SLI・SLO・エラーバジェット
SLI（Service Level Indicator）
SLIは、サービスの信頼性を定量的に測定する指標です。ユーザーの体験に直結する指標を選定します。
| SLI | 定義 | 測定例 |
|---|---|---|
| 可用性 | リクエストが正常に処理された割合 | 成功と定義したリクエスト数 ÷ SLOの評価対象リクエスト数 |
| レイテンシ | リクエストの処理にかかった時間 | 95パーセンタイルのレスポンスタイム |
| スループット | 単位時間あたりの処理能力 | 1秒あたりのリクエスト処理数 |
| エラー率 | SLOで失敗と定義した応答の割合 | 失敗リクエスト数 ÷ 評価対象リクエスト数。5xxや4xxの扱いは仕様と利用者影響で定義する。入力誤り等の想定した4xxを一律にサービス障害と数えない（GoogleのSLI設計例） |
| 正確性 | レスポンスの正確さ | 正しいデータを返した割合 |
SLO（Service Level Objective）
SLOは、SLIに対する目標値です。「評価期間の対象リクエストの99.9%が成功」「95パーセンタイルのレイテンシ200ms以内」のように、対象・測定方法・期間を定義します。時間ベースの稼働率とリクエスト成功率は異なる指標です。下表は時間ベースで24時間連続稼働するサービスについて、365日または30日の全時間×（1−目標値）で求めた計算例です。リクエスト成功率から無条件に停止時間へ換算はできません。サービス種別だけで必要なSLOも決まりません。
| SLO | 365日間の許容停止時間 | 30日間の許容停止時間 | 対象の例（必要水準は個別判断） |
|---|---|---|---|
| 99% | 3.65日 | 7.2時間 | 内部ツール、バッチ処理 |
| 99.9% | 8.76時間 | 43.2分 | 一般的なWebサービス |
| 99.95% | 4.38時間 | 21.6分 | ECサイト、SaaSプロダクト |
| 99.99% | 52.6分 | 4.32分 | 決済システム、医療系 |
エラーバジェット
エラーバジェットは、評価期間中にSLOが許容する失敗の割合・量です。99.9%のリクエスト成功率SLOなら、対象リクエストの0.1%が予算で、100万件なら1,000件です。43.2分となるのは、30日間を時間ベースで評価する稼働率99.9%の場合です。残量と消費速度を見ながら、リリースと信頼性改善の優先順位を決めます。Googleのポリシー例では、直近4週間の予算を超過するとP0対応・セキュリティ修正を除く変更を停止します。これは事前に合意する運用ルールの一例です。
エラーバジェットの革新的な点は、「開発速度と信頼性のトレードオフ」を定量的に管理できることです。開発チームは「もっと速くリリースしたい」、運用チームは「もっと安定させたい」という従来の対立を、エラーバジェットという共通言語で解消します。
SREの主要プラクティス
1. Toil（トイル）の削減
Googleの定義するToilは、手作業・反復・自動化可能といった性質があり、永続的な改善価値を生まず、サービス規模に応じて増える運用作業です。Catchpointの2025年版報告書で25%から30%へ増えたのは、オンコールではない通常週に運用活動へ使う時間割合の中央値です。Toilを直接問う別設問の中央値は、2024年版14%から2025年版20%でした。両指標を混同せず、前年版との比較として読みます。同資料は「5年ぶりの増加」と説明しますが、掲載表だけから毎年連続して減少したとは判断できません。GoogleはSREのToilを50%以内に抑え、少なくとも半分を継続的な改善につながるエンジニアリングへ確保する方針を示しています。全組織共通の達成済み水準ではなく、自社の実測と改善方針に用いる目安です。
2. ポストモーテム（振り返り）
障害発生後に「何が起きたか」「なぜ起きたか」「どう防ぐか」を体系的に振り返るプラクティスです。個人を責めない「ブレームレス」が原則であり、組織全体の学習を促進します。ポストモーテムのドキュメントは全社に公開し、同種の障害の再発防止に活用します。
3. インシデント管理
インシデントの検知→トリアージ→対応→解決→ポストモーテムのフローを標準化します。オンコールのローテーション設計、エスカレーションルール、コミュニケーション手順を事前に整備してください。
4. キャパシティプランニング
現在のトラフィック推移とビジネスの成長計画に基づき、将来必要なリソース（コンピュート、ストレージ、ネットワーク）を予測し、事前にプロビジョニングします。オートスケーリングと組み合わせて、コスト効率と可用性を両立させます。
5. カオスエンジニアリング
意図的にシステムに障害を注入し、レジリエンス（回復力）を検証するプラクティスです。Netflix発祥のChaos Monkeyが有名で、Gremlin、Litmus Chaosなどのツールが利用されます。本番環境での実施にはリスクが伴うため、段階的に導入してください。
SRE導入のステップ
ステップ1: SLI/SLOの定義
最も重要なユーザー体験に基づいてSLIを選定し、適切なSLOを設定します。最初は2〜3のコアSLI（可用性、レイテンシ、エラー率）から始め、運用に慣れてから拡張してください。GoogleのSLO設計では、一般的なサービスに100%の信頼性目標を置くことを勧めていません。100%では許容する失敗の予算がなくなり、変更リスクと機能開発のバランスを取りにくくなります。ただし、有限の観測期間に失敗が0件となることはあり、「実測100%は常に不可能」「開発速度が必ずゼロになる」という意味ではありません。安全性や業務影響、利用者の要求を踏まえて目標を決めます。
ステップ2: エラーバジェットの運用開始
SLOに基づくエラーバジェットを算出し、開発チーム・運用チーム間でエラーバジェットポリシーを合意します。例えば「予算残量と消費速度を見て通常のリリースを判断」「予算の枯渇・超過や急速な消費で信頼性改善を優先」と定め、セキュリティ修正等の例外と再開条件も明文化します。一部を消費しただけで一律にリリースを止めるルールではありません。
ステップ3: オブザーバビリティ基盤の構築
SLI/SLOを計測・監視するためのオブザーバビリティ基盤（メトリクス、ログ、トレース）を構築します。Prometheus + Grafana、Datadog、New Relicなどのツールを活用し、SLOダッシュボードを構築してリアルタイムにエラーバジェットの消費状況を可視化します。
ステップ4: Toilの計測と自動化
現在のToilの割合を計測し、最も時間を消費している手作業を特定して自動化を進めます。デプロイ作業、証明書更新、ログローテーション、アラート対応などが典型的な自動化対象です。
ステップ5: SRE文化の定着
SREは特定のチームだけのプラクティスではなく、開発組織全体の文化です。ブレームレスポストモーテム、SLOベースの意思決定、自動化への投資を組織文化として定着させます。
SREチームのモデル
| モデル | 概要 | 適したケース |
|---|---|---|
| 専任SREチーム | 独立したSRE組織がインフラ・信頼性を担当 | 大規模組織、複雑なシステム |
| エンベデッドSRE | SREエンジニアがプロダクトチームに常駐 | プロダクトチームの自律性を重視 |
| イネーブリングSRE | SREチームが他チームのSRE導入を支援 | SRE文化の全社展開フェーズ |
| DevOps with SRE Practices | DevOpsチームにSREプラクティスを導入 | 小規模組織、SRE専任者不在 |
SLO移行で期待される効果
一般に、サーバーメトリクス中心の監視からユーザージャーニーベースのSLOへ移行することで、次のような改善が期待されます。
- インシデント対応件数の削減: ユーザー影響の大きい真の問題に集中
- MTTRの短縮: SLOベースのアラートで迅速な検出と対応
- オンコール負荷の軽減: 不要なアラートの削減
よくある質問（FAQ）
Q. SREとDevOpsの違いは何ですか？
DevOpsは「開発と運用の文化的な統合」を目指す哲学・運動であり、SREは「信頼性をソフトウェアエンジニアリングで解決する」具体的なプラクティスセットです。Google「The Site Reliability Workbook」第1章では、SREをDevOpsというインターフェースの実装にたとえています。DevOpsが「何を目指すか」を示すのに対し、SREは「どう実現するか」を提供します。両者は対立するものではなく、SREはDevOpsを実践する一つの方法論です。
Q. SREチームは何名から始めるべきですか？
最初の1〜2名から始められます。専任のSREエンジニアを配置するか、既存のインフラエンジニア・バックエンドエンジニアがSREプラクティスを兼任する形からスタートします。まずはSLI/SLOの定義とエラーバジェットの運用から始め、チームの成熟に合わせて専任化・拡大してください。
Q. SLOはどの程度の高さに設定すべきですか？
SLOは「ユーザーが満足する最低限の信頼性」に設定すべきです。過剰なSLO（例: 99.999%）はエラーバジェットが極端に少なくなり、開発速度を著しく制限します。99.9%を30日間の時間ベース稼働率に適用した計算例では、許容停止時間は43.2分です。リクエスト成功率99.9%の予算は対象リクエストの0.1%であり、停止時間とは直結しません。99.95〜99.99%も例示値で、決済・医療などの名称だけで妥当性は決まりません。許容できる利用者影響とシステムの要件から判断します。運用データを蓄積しながら段階的に調整してください。
まとめ：SREで信頼性と開発速度を同時に高める
SREは、SLI/SLO/エラーバジェットという共通言語で「開発速度と信頼性のトレードオフ」を定量管理する、現代のシステム運用の標準アプローチです。Toilの削減、ブレームレスポストモーテム、カオスエンジニアリングのプラクティスを組み合わせ、組織全体の信頼性文化を構築しましょう。
renueでは、SREプラクティスの導入からオブザーバビリティ基盤の構築、信頼性改善まで、企業のシステム運用を包括的に支援しています。システムの信頼性向上や運用効率化でお悩みの方は、ぜひお気軽にご相談ください。
株式会社renueでは、AI導入戦略の策定からDX推進のコンサルティングを提供しています。お気軽にご相談ください。
