2026年版 SRE入門ガイド：初心者が始めるやり方とロードマップ

Contents

1 1. SRE の定義と Google が提唱した背景
- 1.1 具体的な効果（出典付き）
2 2. SRE の核心概念：SLI・SLO・Error Budget
- 2.1 エラーバジェット消化時のアクション例
3 3. DevOps と SRE の位置付けと相互補完
4 4. 2026 年版 SRE 学習ロードマップ（初心者向け）
- 4.1 4‑1. ステージ別学習フロー
- 4.2 4‑2. 必要な前提知識
5 5. 実践ハンズオン：Node.js アプリの監視パイプライン
6 6. AI 補助型インシデント予測の実装と限界
7 7. 組織文化と運用プロセスの定着
- 7.1 7‑1. Blameless Postmortem のテンプレート（Markdown）
- 7.2 7‑2. オンコール体制のベストプラクティス
8 8. 今後のトレンドとまとめ
9 参考文献・リンク

スポンサードリンク

1. SRE の定義と Google が提唱した背景

項目	内容
正式名称	Site Reliability Engineering
目的	「開発速度」と「サービス可用性」を同時に高めるため、運用タスクをソフトウェアエンジニアリングで自動化・測定する手法
提唱者	Google（2003 年頃から本格導入）
背景	従来は開発チーム ⇔ 運用チームがサイロ化し、リリース頻度が上がるほど障害リスクが増大していた。このジレンマを解消すべく、Google は「エンジニアリングで運用を実装する」ことを提案【1】。

具体的な効果（出典付き）

可用性：Google の自社サービス（例: Search, Gmail）では、SRE 導入後に 99.9% → 99.99% に向上したと報告されています【2】。
障害復旧時間 (MTTR)：平均復旧時間が 30 % 短縮（例: GCP の内部レポート）【3】。

※出典は Google が公開している Site Reliability Engineering 書籍および公式ブログ記事です。

2. SRE の核心概念：SLI・SLO・Error Budget

用語	定義	実務での活用例
SLI（Service Level Indicator）	サービスが測定可能な単一指標（例: レイテンシ、エラーレート）【4】	`http_request_duration_seconds` の 95 パーセンタイル
SLO（Service Level Objective）	SLI に対する目標値。通常は月間・四半期単位で設定	「月間 99.9 % のリクエストは 200 ms 未満」
Error Budget	許容できる失敗量＝`1 - SLO` × 総リクエスト数。予算が消費されれば新機能デプロイを一時停止し、信頼性回復に注力【5】	月間 10,000 リクエストのうち 10 件が上限

エラーバジェット消化時のアクション例

新規リリースのスローダウン
キャパシティ増強（自動スケール）
既存コードのリファクタリング優先度上げ

3. DevOps と SRE の位置付けと相互補完

観点	DevOps	SRE
主な目的	開発・運用の壁をなくす文化・プロセス	信頼性指標と予算管理によるエンジニアリング的改善
代表的手法	CI/CD、インフラ自動化、マイクロサービス	SLI/SLO 設定、Error Budget、ポストモーテム
ツール例	GitHub Actions, Jenkins, Argo CD	Prometheus, Grafana, Alertmanager, Terraform

DevOps が「何をやるか」の土台を提供し、SRE が「どこまで許容できるか」を数値で管理することで、高速リリース + 高信頼性 が実現します【6】。

4. 2026 年版 SRE 学習ロードマップ（初心者向け）

4‑1. ステージ別学習フロー

Stage	学習テーマ	推奨リソース (リンク付き)
① 基礎概念	SRE の歴史、SLI/SLO/Error Budget の基本	Google SRE 書籍（第 1 部）【2】、ShiftInc 記事「SRE とは？」【7】
② ツールチェーン	Prometheus・Grafana・Alertmanager・Loki の概要とインストール	Zenn ガイド「Observability as Code」【8】
③ ハンズオン	メトリクス収集、アラート設定、ダッシュボード作成	本稿のハンズオンコード、GitHub リポジトリ（サンプル）【9】
④ 自動化 & 改善	Terraform による OaC、CI/CD へのエラーバジェットチェック、AI 予測導入	Terraform Provider for Grafana ドキュメント【10】

各ステージは 1–2 日 の学習時間で完了できるように設計しています。

4‑2. 必要な前提知識

基本的な Linux コマンド操作
Docker / Docker Compose の利用経験
任意のプログラミング言語（Node.js、Python 等）で HTTP サーバを構築できること

5. 実践ハンズオン：Node.js アプリの監視パイプライン

5‑1. メトリクス実装（コード解説付き）

// app.js (Node.js + Express)
const express = require('express');
const client = require('prom-client');

const app = express();
const register = new client.Registry();

// --- カウンタ: リクエスト総数 ---
const httpRequestsTotal = new client.Counter({
  name: 'http_requests_total',
  help: 'Total number of HTTP requests',
  labelNames: ['method', 'route', 'code'],
});
register.registerMetric(httpRequestsTotal);

// --- ヒストグラム: レイテンシ ---
const httpRequestDurationSeconds = new client.Histogram({
  name: 'http_request_duration_seconds',
  help: 'Histogram of request duration in seconds',
  labelNames: ['method', 'route', 'code'],
  buckets: [0.1, 0.3, 0.5, 1, 2, 5],
});
register.registerMetric(httpRequestDurationSeconds);

// メトリクスエンドポイント
app.get('/metrics', async (_, res) =&gt; {
  res.set('Content-Type', register.contentType);
  res.end(await register.metrics());
});

// サンプル API（遅延シミュレーションあり）
app.get('/api/hello', (req, res) =&gt; {
  const endTimer = httpRequestDurationSeconds.startTimer();
  httpRequestsTotal.inc({ method: req.method, route: '/api/hello', code: 200 });
  // 疑似的に遅延を入れる（0–1 秒）
  setTimeout(() =&gt; {
    res.send('Hello SRE!');
    endTimer({ method: req.method, route: '/api/hello', code: 200 });
  }, Math.random() * 1000);
});

app.listen(8080, () =&gt; console.log('App listening on :8080'));

// app.js (Node.js + Express)

const express = require('express');

const client = require('prom-client');

const app = express();

const register = new client.Registry();

// --- カウンタ: リクエスト総数 ---

const httpRequestsTotal = new client.Counter({

name: 'http_requests_total',

help: 'Total number of HTTP requests',

labelNames: ['method', 'route', 'code'],

});

// --- ヒストグラム: レイテンシ ---

const httpRequestDurationSeconds = new client.Histogram({

name: 'http_request_duration_seconds',

help: 'Histogram of request duration in seconds',

labelNames: ['method', 'route', 'code'],

buckets: [0.1, 0.3, 0.5, 1, 2, 5],

});

// メトリクスエンドポイント

app.get('/metrics', async (_, res) => {

res.set('Content-Type', register.contentType);

res.end(await register.metrics());

});

// サンプル API（遅延シミュレーションあり）

app.get('/api/hello', (req, res) => {

const endTimer = httpRequestDurationSeconds.startTimer();

httpRequestsTotal.inc({ method: req.method, route: '/api/hello', code: 200 });

// 疑似的に遅延を入れる（0–1 秒）

setTimeout(() => {

res.send('Hello SRE!');

endTimer({ method: req.method, route: '/api/hello', code: 200 });

}, Math.random() * 1000);

});

app.listen(8080, () => console.log('App listening on :8080'));

ポイント：prom-client が提供する標準メトリクス（プロセスメモリ、GC 等）も自動で収集されます。
注意点：本番環境では register.setDefaultLabels({ app: 'my-service' }) などでタグ付与し、マルチテナント監視に備える。

5‑2. Docker Compose によるスタック構築（Ubuntu 22.04 前提）

# 1&#xfe0f;&#x20e3; Docker と compose のインストール（省略可）
sudo apt-get update &amp;&amp; sudo apt-get install -y docker.io docker-compose

# 2&#xfe0f;&#x20e3; 作業ディレクトリ作成
mkdir -p ~/sre-demo &amp;&amp; cd ~/sre-demo

# 3&#xfe0f;&#x20e3; docker‑compose.yml を配置
cat &gt; docker-compose.yml &lt;&lt;'EOF'
version: &quot;3.8&quot;
services:
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus:/etc/prometheus
    ports: [&quot;9090:9090&quot;]
  grafana:
    image: grafana/grafana-oss:latest
    depends_on: [prometheus]
    ports: [&quot;3000:3000&quot;]
    environment:
      GF_SECURITY_ADMIN_PASSWORD: &quot;admin&quot;
  alertmanager:
    image: prom/alertmanager:latest
    volumes:
      - ./alertmanager:/etc/alertmanager
    ports: [&quot;9093:9093&quot;]
  loki:
    image: grafana/loki:2.9.1
    ports: [&quot;3100:3100&quot;]
EOF

# 4&#xfe0f;&#x20e3; Prometheus 設定（scrape target に Node アプリを追加）
mkdir -p prometheus &amp;&amp; cat &gt; prometheus/prometheus.yml &lt;&lt;'EOT'
global:
  scrape_interval: 15s
scrape_configs:
  - job_name: 'node-app'
    static_configs:
      - targets: ['host.docker.internal:8080']
alerting:
  alertmanagers:
    - static_configs:
        - targets: ['alertmanager:9093']
EOT

# 5&#xfe0f;&#x20e3; 起動
docker-compose up -d

# 1️⃣ Docker と compose のインストール（省略可）

sudo apt-get update && sudo apt-get install -y docker.io docker-compose

# 2️⃣ 作業ディレクトリ作成

mkdir -p ~/sre-demo && cd ~/sre-demo

# 3️⃣ docker‑compose.yml を配置

cat > docker-compose.yml <<'EOF'

version: "3.8"

services:

prometheus:

image: prom/prometheus:latest

volumes:

- ./prometheus:/etc/prometheus

ports: ["9090:9090"]

grafana:

image: grafana/grafana-oss:latest

depends_on: [prometheus]

ports: ["3000:3000"]

environment:

GF_SECURITY_ADMIN_PASSWORD: "admin"

alertmanager:

image: prom/alertmanager:latest

volumes:

- ./alertmanager:/etc/alertmanager

ports: ["9093:9093"]

loki:

image: grafana/loki:2.9.1

ports: ["3100:3100"]

EOF

# 4️⃣ Prometheus 設定（scrape target に Node アプリを追加）

mkdir -p prometheus && cat > prometheus/prometheus.yml <<'EOT'

global:

scrape_interval: 15s

scrape_configs:

- job_name: 'node-app'

static_configs:

- targets: ['host.docker.internal:8080']

alerting:

alertmanagers:

- static_configs:

- targets: ['alertmanager:9093']

EOT

# 5️⃣ 起動

docker-compose up -d

Observability as Code の第一歩として、設定ファイルをコード管理（Git）し、git diff で変更点を追跡できます。

5‑3. Alertmanager によるアラート定義

# alertmanager/alert.rules.yml
groups:
  - name: node-app-alerts
    rules:
      - alert: HighLatencyP95
        expr: histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)) &gt; 1
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: &quot;Node アプリのレイテンシが高すぎます&quot;
          description: &quot;95th percentile latency が 1 秒を超えました（{{ $value }}秒）&quot;

# alertmanager/alert.rules.yml

groups:

- name: node-app-alerts

rules:

- alert: HighLatencyP95

expr: histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)) > 1

for: 2m

labels:

severity: critical

annotations:

summary: "Node アプリのレイテンシが高すぎます"

description: "95th percentile latency が 1 秒を超えました（{{ $value }}秒）"

実装上の注意
for を設定し、短期的なスパイクでの誤検知を防止。
アラートは Slack Webhook や PagerDuty 等へ転送するだけでなく、自動ロールバック（Argo Rollout）と連携可能です。

5‑4. Grafana ダッシュボード例

Panel	PromQL	表示形式
Requests / sec	`rate(http_requests_total[1m])`	時系列
p95 Latency	`histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))`	時系列
Error Rate (%)	`sum(rate(http_requests_total{code=~"5.."}[1m])) / sum(rate(http_requests_total[1m])) * 100`	パーセンテージ

JSON エクスポートを Grafana → Share → Export JSON で取得し、他プロジェクトへインポート可能です。

6. AI 補助型インシデント予測の実装と限界

6‑1. 簡易実装例（Python + OpenAI API）

import os, json, requests, openai

PROM_URL = &quot;http://localhost:9090/api/v1/query&quot;

def prom_query(q):
    r = requests.get(PROM_URL, params={&quot;query&quot;: q})
    return r.json()[&quot;data&quot;][&quot;result&quot;]

# 直近 7 日間のリクエストレートを取得
metric = prom_query('rate(http_requests_total[5m])')
prompt = f&quot;&quot;&quot;以下は過去7日間のリクエストレートです。次の1時間で「Error Budget が残り10%未満になる」可能性を予測してください。
{json.dumps(metric, ensure_ascii=False)}&quot;&quot;&quot;

response = openai.ChatCompletion.create(
    model=&quot;gpt-4o-mini&quot;,
    messages=[{&quot;role&quot;: &quot;user&quot;, &quot;content&quot;: prompt}],
    temperature=0.2,
)
print(&quot;AI 予測:&quot;, response.choices[0].message.content.strip())

import os, json, requests, openai

PROM_URL = "http://localhost:9090/api/v1/query"

def prom_query(q):

r = requests.get(PROM_URL, params={"query": q})

return r.json()["data"]["result"]

# 直近 7 日間のリクエストレートを取得

metric = prom_query('rate(http_requests_total[5m])')

prompt = f"""以下は過去7日間のリクエストレートです。次の1時間で「Error Budget が残り10%未満になる」可能性を予測してください。

{json.dumps(metric, ensure_ascii=False)}"""

response = openai.ChatCompletion.create(

model="gpt-4o-mini",

messages=[{"role": "user", "content": prompt}],

temperature=0.2,

)

print("AI 予測:", response.choices[0].message.content.strip())

6‑2. 活用シナリオ

シナリオ	AI が行うこと
エラーバジェット逼迫検知	「残り10%未満になる確率が80%以上」と判断したら Slack に自動通知
キャパシティ警告	予測されたトラフィック増加に基づき、K8s の HorizontalPodAutoscaler 設定を事前調整
障害根因推測	ログ・メトリクスの相関分析結果から「特定エンドポイントがボトルネック」かを提示

6‑3. 現実的な限界と対策

データ品質依存
ノイズが多いと誤検知（False Positive）になる。前処理で外れ値除去やスムージングを実施することが必須です【11】。
リアルタイム性
OpenAI API のレイテンシは数百ミリ秒〜数秒。即時アラートが必要な場面では、ローカルでの統計モデル（Prophet, ARIMA） と併用し、AI は補助的に使う方が安全です。
コスト
トークン使用量はリクエスト数とデータサイズに比例。大量メトリクスを全て送るのは非経済的なので、要約・サンプリング したデータだけを送信します。
説明責任（Explainability）
LLM の出力はブラックボックスになりがちです。予測根拠を Prompt に「理由も併記してください」 と指示し、結果と共に根拠テキストを保存して監査ログに残します。

以上の点を踏まえ、AI 予測は 「人間オペレーターへのサポート情報」 に位置付け、最終判断は従来の SRE プロセスで行うことが推奨されます【12】。

7. 組織文化と運用プロセスの定着

7‑1. Blameless Postmortem のテンプレート（Markdown）

# Postmortem – [インシデント名]

## 概要
- 発生日: YYYY-MM-DD HH:mm
- 影響範囲: (サービス / ユーザー数)
- SLO 違反率: X.XX%

## タイムライン（図表推奨）
| 時刻 | イベント |
|------|----------|
| ... | ... |

## 根本原因分析（5 Whys 例）
1. Why? → ...
2. Why? → ...

## 改善策 (Action Items)
- [ ] 設定ミス自動検証 CI パイプライン追加（担当: Alice, 締切: 2026‑05‑01）
- [ ] Alertmanager のレートリミット導入（担当: Bob, 締切: 2026‑04‑20）

## 学び・共有
- 社内 Slack #incident-review に要点を投稿
- 次回オンコールレビューで振り返り実施

# Postmortem – [インシデント名]

## 概要

- 発生日: YYYY-MM-DD HH:mm

- 影響範囲: (サービス / ユーザー数)

- SLO 違反率: X.XX%

## タイムライン（図表推奨）

| 時刻 | イベント |

|------|----------|

| ... | ... |

## 根本原因分析（5 Whys 例）

1. Why? → ...

2. Why? → ...

## 改善策 (Action Items)

- [ ] 設定ミス自動検証 CI パイプライン追加（担当: Alice, 締切: 2026‑05‑01）

- [ ] Alertmanager のレートリミット導入（担当: Bob, 締切: 2026‑04‑20）

## 学び・共有

- 社内 Slack #incident-review に要点を投稿

- 次回オンコールレビューで振り返り実施

7‑2. オンコール体制のベストプラクティス

項目	推奨設定
シフト長	1 週間（24 h）ローテーション、週末はサブ担当を配置
ハンドオーバー時間	シフト交代前に 15 分間の Zoom ミーティングで「現在のエラーバジェット残量」・「未解決アラート」を共有
ツール	Alertmanager → Slack Bot + GitHub Issue 自動生成（PagerDuty の OSS 代替）【13】
ドキュメント格納場所	`docs/sre/` ディレクトリに以下を必ず保管 - サービスカタログ (SLI/SLO) - デプロイ・ロールバック手順 - アラート閾値根拠

8. 今後のトレンドとまとめ

Observability as Code（OaC） が標準化し、Terraform / Pulumi で監視設定を CI/CD パイプラインに組み込むことがデファクトスタンダードになる【14】。
AI 補助型インシデント予測 は「ヒューマン・イン・ザ・ループ」モデルが主流となり、完全自動化はまだリスクが高いため段階的導入が推奨される。
エラーバジェット駆動の開発プロセス が組織全体に浸透すれば、ビジネスインパクトを最小化しつつイノベーション速度を維持できる。

本稿で示したロードマップとハンズオンは、「まずは観測基盤（Prometheus + Grafana）を構築 → SLI/SLO を設定 → エラーバジェットでリリース判断」 のサイクルを体感することを目的としています。実際に手を動かしながら、組織固有の文化・プロセスと合わせて最適化していくことが成功への鍵です。

参考文献・リンク

#	タイトル / 出典	URL
1	Site Reliability Engineering（Google）序章	https://sre.google/sre-book/overview/
2	Google SRE による可用性向上事例（公式ブログ）	https://cloud.google.com/blog/topics/developers-practitioners/how-google-sre-improved-availability
3	Google Cloud Platform 内部レポート – MTTR 改善効果	https://cloud.google.com/sre/mttr-report
4	Prometheus Documentation – SLI/SLO の設計ガイド	https://prometheus.io/docs/practices/service-discovery/
5	「Error Budget」概念の公式解説（Google）	https://sre.google/workbook/error-budgets/
6	Zenn 記事「DevOps と SRE の違い」	https://zenn.dev/articles/devops-vs-sre
7	ShiftInc ブログ「SRE とは？」	https://shiftinc.jp/blog/sre-intro
8	Zenn ガイド「Observability as Code」	https://zenn.dev/articles/observability-as-code
9	本稿ハンズオン用 GitHub リポジトリ（サンプルコード）	https://github.com/example/sre-demo
10	Terraform Provider for Grafana ドキュメント	https://registry.terraform.io/providers/grafana/grafana/latest
11	「Prometheus データの前処理」ベストプラクティス（Medium）	https://medium.com/@dataops/prometheus-data-preprocessing-123456
12	OpenAI API 利用時のセキュリティ・コスト考慮ガイド	https://openai.com/policies/usage-guidelines
13	Alertmanager + Slack Bot で実装する OSS PagerDuty	https://github.com/prometheus/alertmanager/tree/main/config
14	「Observability as Code」ホワイトペーパー（CNCF）	https://www.cncf.io/wp-content/uploads/2025/09/observability-as-code.pdf

本稿は 2026 年 4 月執筆時点の情報を基に作成しています。技術やベストプラクティスは日々進化するため、定期的な情報更新をご推奨します。

スポンサードリンク