運用設計書の書き方｜項目一覧と記入例付きテンプレート

運用設計書とは、システムをリリースした後に「誰が・いつ・何を・どの基準で」動かし、守り、直すのかを、運用が始まる前に決めてまとめた文書です。 監視の閾値、バックアップの目標（RPO/RTO）、障害時の連絡先と判断基準、日次・週次・月次の定期作業、アカウントの棚卸し、変更とリリースのルール、そしてサービスを終える手順まで、「運用中に判断を迫られること」を先に決めておくのが役割です。

この記事では、15項目の「決めること・記入例・決めていないと起きること」の早見表、Markdownでそのままコピペできる目次テンプレート、架空の会員制タスク管理サービスの記入例を丸ごと1本（監視項目と閾値の表、バックアップ設計表、連絡体制表、定期作業カレンダー、SLO表）、根拠つきの監視閾値の例、上流工程との関係の図、レビュー観点チェックリストをまとめました。閾値の根拠は公式ドキュメントで確認し、RTOの見積もりに使うリストア時間は PostgreSQL 16 で実測しています。

運用設計書の項目早見表（決めること・記入例・決めていないと起きること）

まずこの表を埋めれば、運用設計書の骨子ができあがります。 右端の列は「決めていないとどうなるか」を事実として書いたもので、レビューのときに「この項目は空でよいか」を判断する材料になります。

運用設計書とは何か：要件定義書・基本設計書・運用手順書との違い

運用設計書は、上流工程で決めた「非機能要件」と「システム構成」を受け取り、運用手順書やリリース手順書に渡す中間の文書です。 要件定義で「稼働率 99.9%」「RPO 5分」と決まれば、それを満たす監視とバックアップの方針を運用設計書で決め、具体的なコマンドや画面操作は運用手順書に書きます。

flowchart LR
    A["要件定義書<br/>非機能要件：稼働率・RPO/RTO・運用時間"] --> B["基本設計書<br/>システム構成・外部連携・バッチ"]
    B --> C["運用設計書<br/>監視・バックアップ・障害対応・定期作業の方針と判断基準"]
    C --> D["運用手順書<br/>コマンド・画面操作の手順"]
    C --> E["リリース手順書"]
    C --> F["障害報告書の様式・連絡先"]
    D --> G["運用（日次・週次・月次・年次）"]
    G -. "振り返り：閾値や手順の見直し" .-> C

近い名前の文書との違いは、「答える問い」と「読み手」で整理すると迷いません。 要件定義書・基本設計書・詳細設計書・障害報告書は別の記事で詳しく扱っているので、ここでは違いの表だけ示します。

書く時期は「リリース直前」ではなく「基本設計と並行」が目安です。 監視に必要なログの出力形式、バックアップに必要なストレージ、権限分離に必要なアカウント設計は、基本設計で決める内容に影響するためです。

運用設計書の目次テンプレート（Markdownコピペ用）

次のテンプレートをそのままコピーして、見出しの下を埋めていけば運用設計書になります。 表の列は、後の章の記入例と同じ構成にしてあります。使わない章は削除せず「対象外（理由）」と書き残すと、レビューのときに「検討漏れ」と「意図的な対象外」を区別できます。

# ○○システム 運用設計書

| 項目 | 内容 |
|---|---|
| 版 | 1.0 |
| 作成日 / 更新日 | YYYY-MM-DD / YYYY-MM-DD |
| 作成者 / 承認者 | 氏名 / 氏名 |
| 関連文書 | 要件定義書 vX.X、基本設計書 vX.X、運用手順書（リンク） |

## 1. 概要と対象範囲
- 目的：
- 対象システム・対象外：
- 運用時間（サービス提供時間 / 有人対応時間）：
- 前提とする非機能要件（要件定義書の要件IDを引用）：

## 2. システム構成と運用上の役割
| 構成要素 | 役割 | 冗長化 | 管理者 | 備考 |
|---|---|---|---|---|
| | | | | |

## 3. 体制と連絡先
| 役割 | 担当（主 / 副） | 連絡手段 | 対応時間帯 |
|---|---|---|---|
| | | | |

## 4. 監視
| 監視項目 | 対象 | 警告 | 重大 | 通知先 | 対応 |
|---|---|---|---|---|---|
| | | | | | |

## 5. ログ
| ログ種別 | 出力元 | 保持期間 | 保管先 | 個人情報の扱い |
|---|---|---|---|---|
| | | | | |

## 6. バックアップと復旧（RPO / RTO）
| 対象 | 方式 | 頻度 | 保持 | RPO | RTO | 保管先 | 復元テスト |
|---|---|---|---|---|---|---|---|
| | | | | | | | |

## 7. 障害対応とエスカレーション
| 重大度 | 定義 | 初動（着手まで） | 連絡手段 | エスカレーション先 | 目標復旧時間 | 利用者告知 |
|---|---|---|---|---|---|---|
| | | | | | | |

## 8. 定期作業（日次 / 週次 / 月次 / 年次）
| 周期 | 作業 | 実施日・時刻 | 担当 | 手順書 |
|---|---|---|---|---|
| | | | | |

## 9. アカウントと権限
| ロール | 対象 | 付与の条件 | 承認者 | 棚卸し周期 |
|---|---|---|---|---|
| | | | | |

## 10. 変更管理とリリース
- 変更の分類（通常 / 緊急 / 標準）と承認者：
- リリース方式・時間帯・判定基準・切り戻し条件：

## 11. セキュリティ更新
- 情報源：
- 適用判断の基準と期限：

## 12. 容量管理とコスト
| 指標 | 現在値 | 増加予測 | 増設の判断点 | リードタイム |
|---|---|---|---|---|
| | | | | |

## 13. SLO / SLA
| SLI | SLO | 計測方法 | ウィンドウ | バジェット消費時の対応 |
|---|---|---|---|---|
| | | | | |

## 14. ドキュメント更新・IaC と構成管理
- 更新のトリガーと担当：
- コード化の範囲と手動変更の扱い：

## 15. 廃止手順
- 判断者・告知期間・データの返却と削除・契約解除・記録：

## 改訂履歴
| 版 | 日付 | 変更内容 | 変更者 |
|---|---|---|---|
| | | | |

項目ごとの決め方：監視・ログ・バックアップ・障害対応

15項目のうち、障害の影響に直結する4つは「数字」と「名前」で決めます。 「適切に監視する」「速やかに連絡する」のような形容詞だけの記述は、運用が始まると判断の材料になりません。

監視：閾値は「対応に必要な時間」から逆算する

• 警告と重大の2段階にします。 警告は「翌営業日までに対処すれば間に合う」、重大は「今すぐ人を呼ぶ」ラインです。
• 閾値は、気づいてから対処が終わるまでの時間（リードタイム）から逆算します。 ディスクの増設に2週間かかるなら、2週間後に満杯になる使用率で警告を出します。
• 通知先と通知手段は重大度ごとに分けます。 全部をチャットに流すと、重大な通知が日常の通知に埋もれます。

ログ：保持期間は「使う目的」ごとに決める

• 目的を3つに分けると保持期間が決まります。 障害調査用（アプリログ：90日程度）、分析や問い合わせ対応用（アクセスログ：1年程度）、誰が何を変えたかの記録用（監査ログ：契約や社内規程に合わせて数年）。
• 個人情報をログに出さない方針を先に決めます。 後から消すより、出さない設計のほうが確実です。ログレベルの使い分けは別記事で扱っているので、運用設計書では「どのレベルを本番で出すか」だけ決めます。

バックアップ：RPO と RTO を先に数字で決める

• RPO（Recovery Point Objective）は「どこまでのデータを失ってよいか」、RTO（Recovery Time Objective）は「どれだけの時間で復旧するか」です。 RPOが5分なら、5分おきに復元可能な状態を作る方式（WALアーカイブなど）が必要で、日次バックアップだけでは要件を満たせません。
• 復元テストの周期と担当を書きます。 バックアップは「取れたこと」ではなく「戻せたこと」で成功と判断します。
• RTOはリストア時間に、検知・判断・復旧後の確認を足して見積もります。 後述の実測では50MBのテーブルのリストアは1.0秒でしたが、RTOはそれより桁違いに長くなります。

障害対応：重大度の定義と「誰に・何分以内に・何で」連絡するか

• 重大度は「利用者への影響」で定義します。 「DBサーバーが落ちた」はシステムの状態です。「全利用者がログインできない」のように書くと、判定が人によってぶれません。
• 連絡表には主担当と副担当、電話番号の置き場所、連絡がつかないときの次の宛先と待ち時間（例：10分）を書きます。
• 障害報告書の様式と出すタイミング（初報・中間・最終）は運用設計書で決め、書き方は障害報告書の記事に任せます。 重大度ごとの初動・連絡手段・エスカレーション先・目標復旧時間の表は、記入例の 7 項にあります。

残りの11項目（定期作業、権限、変更管理、リリース、セキュリティ更新、容量、SLO/SLA、コスト、ドキュメント更新、IaC、廃止）は、早見表の「決めること」をそのまま見出しにして、記入例の章と同じ表の形で埋めます。 年次作業はカレンダーへの登録、権限は「剥奪の手順」、リリースは「切り戻し条件の数字」、SLAは「SLOより緩い値」を忘れずに書きます。

監視閾値の例と根拠

閾値は「よく使われる数字」ではなく、「なぜその値か」を書き添えると、環境が変わったときに自分たちで調整できます。 次の表は、小規模なWebサービスを想定した例と、その根拠です。

ディスク使用率の根拠：ext4 の root 予約 5% を実測する

ext4 で作ったファイルシステムは、既定で全ブロックの 5% が root 専用に予約されます。 256MB のイメージを mkfs.ext4 で作り、tune2fs -l で確認した結果です（Ubuntu 24.04）。

$ tune2fs -l fs.img | grep -E '^(Block count|Reserved block count|Block size):'
Block count:              65536
Reserved block count:     3276
Block size:               4096

3276 ÷ 65536 = 約 5.0% です。一般のプロセスはこの予約分を使えないため、df の使用率が 95% に達した時点で書き込みが止まります。 警告 80%・重大 90% は、この 95% のラインより手前で増設の作業時間を確保するための値です。

証明書の残日数：監視スクリプトの例（実行結果つき）

証明書の残日数は openssl だけで確認でき、終了コード 0/1/2（OK/WARNING/CRITICAL）で監視ツールに渡せます。 90日の自己署名証明書で動作を確認しました（OpenSSL 3.0.13）。

#!/bin/bash
# 使い方: ./cert_days.sh ファイル.pem  （WARN・CRIT は環境変数で変更可）
set -eu
TARGET="$1"; WARN=${WARN:-14}; CRIT=${CRIT:-7}
END=$(openssl x509 -in "$TARGET" -noout -enddate | cut -d= -f2)
DAYS=$(( ($(date -d "$END" +%s) - $(date +%s)) / 86400 ))
if   [ "$DAYS" -le "$CRIT" ]; then echo "CRITICAL: $TARGET expires in $DAYS days ($END)"; exit 2
elif [ "$DAYS" -le "$WARN" ]; then echo "WARNING: $TARGET expires in $DAYS days ($END)";  exit 1
else echo "OK: $TARGET expires in $DAYS days ($END)"; exit 0; fi

$ openssl req -x509 -newkey rsa:2048 -nodes -keyout key.pem -out cert.pem -days 90 -subj "/CN=example.test"
$ ./cert_days.sh cert.pem; echo "exit=$?"
OK: cert.pem expires in 89 days (Dec 30 03:34:29 2026 GMT)
exit=0
$ WARN=100 ./cert_days.sh cert.pem; echo "exit=$?"
WARNING: cert.pem expires in 89 days (Dec 30 03:34:29 2026 GMT)
exit=1

公開サーバーの証明書を見るときは、END= の行の openssl x509 -in "$TARGET" を echo | openssl s_client -servername ホスト名 -connect ホスト名:443 2>/dev/null | openssl x509 に置き換えます。

5xx 率の根拠：SLO からエラーバジェットと閾値を計算する

5xx 率の閾値は、SLO から逆算すると説明できる数字になります。 可用性 SLO 99.9%（30日）のとき、許容できるエラー率（エラーバジェット）は 0.1% です。Google SRE Workbook の「Alerting on SLOs」が示す多段バーンレート（バジェットを消費する速さ）を掛けると、通知の閾値が決まります。

"""SLO からエラーバジェットと 5xx 率のアラート閾値を求める（Python 3.11）"""
SLO = 0.999          # 可用性 SLO 99.9%（30日ウィンドウ）
WINDOW_DAYS = 30

budget = 1 - SLO     # 許容できるエラー率（エラーバジェット）
print(f"SLO {SLO:.1%} → エラーバジェット = {budget:.3%}")
print(f"30日の許容停止時間 = {WINDOW_DAYS*24*60*budget:.1f} 分")

# Google SRE Workbook「Alerting on SLOs」の多段バーンレート例
# (バーンレート, 評価ウィンドウ, 30日バジェットの消費率)
for burn, window_h, consumed in [(14.4, 1, "2%"), (6, 6, "5%"), (1, 72, "10%")]:
    print(f"バーンレート {burn:>4} × {window_h:>2}時間窓: "
          f"5xx率 {burn*budget:.2%} 以上が続くと通知（バジェット {consumed} 消費）")

SLO 99.9% → エラーバジェット = 0.100%
30日の許容停止時間 = 43.2 分
バーンレート 14.4 ×  1時間窓: 5xx率 1.44% 以上が続くと通知（バジェット 2% 消費）
バーンレート    6 ×  6時間窓: 5xx率 0.60% 以上が続くと通知（バジェット 5% 消費）
バーンレート    1 × 72時間窓: 5xx率 0.10% 以上が続くと通知（バジェット 10% 消費）

SRE Workbook は、長いウィンドウの 1/12 の短いウィンドウ（1時間なら5分）でも同じ閾値を超えていることを条件に加えることを勧めています。 「今も消費が続いている」ときだけ通知され、収束後は止まります。SLO が 99.5% ならバジェットは 0.5% なので、同じ式で計算し直します。

記入例：会員制タスク管理サービス「ToDoNest」の運用設計書

ここからは、架空の小規模Webサービスの運用設計書を丸ごと1本、記入例として示します。 会員制タスク管理サービス「ToDoNest（架空）」は、Webアプリ2台・PostgreSQL（プライマリ＋スタンバイ）・オブジェクトストレージという構成です。数字と名前を自社に置き換えて使ってください。

1. 概要と対象範囲

2. システム構成と運用上の役割

3. 体制と連絡先

電話番号はアクセス制限つきの連絡簿に置き、この文書には役割だけを書きます。連絡がつかない場合は10分待って次の宛先（副担当 → 運用責任者 → 事業責任者）に進みます。

4. 監視項目と閾値

5. ログ

6. バックアップ設計（RPO / RTO）

RTO 2時間の内訳は、検知 15分、判断 15分、リストア 30分（実測値に余裕を見た値）、復旧後の確認 30分、予備 30分です。 リストア時間は、本番と同じサイズのダンプを検証環境で復元して計測し、年2回更新します。

7. 障害対応と連絡体制（エスカレーション）

障害報告書は、Sev1・Sev2 で作成し、初報は復旧後 1営業日以内、最終報告は 5営業日以内に出します。

8. 定期作業カレンダー

9. SLO

SLA（利用規約で約束する値）は 99.5% とし、SLO より緩い値にしています。SLO は内部の目標、SLA は外部への約束で、SLA は未達時の対応（返金など）を伴うため SLO より緩くします。

10. アカウントと権限

共有アカウントは使いません。退職・異動の当日に、人事連絡を受けた運用責任者が全ロールを剥奪します。

11. 変更管理・リリース・セキュリティ更新

• 変更の分類：通常変更（週次の変更会議で承認）、緊急変更（運用責任者の口頭承認で実施し、24時間以内に記録）、標準変更（オートスケール上限の変更など、事前承認済みの定型作業）。
• リリース：火曜 10:00 に段階リリース（1台 → 全台）。リリース後 30分間の 5xx 率が 0.5% 超、または p95 が 1,800ms 超なら切り戻します。手順はリリース手順書 REL-01。
• セキュリティ更新：情報源はディストリビューションの告知と週次の依存パッケージスキャン。深刻度「高」以上は 7日以内、それ以外は月次の定期作業で適用します。

12. 容量管理とコスト

13. ドキュメント更新・IaC と構成管理・廃止手順

• ドキュメント更新：構成変更の PR に運用設計書と手順書の差分を含め、レビュー観点に「運用文書の更新」を入れます。障害の振り返りで閾値や手順を変えた場合は、最終報告の提出時に改訂します。
• IaC と構成管理：インフラは Terraform で管理し、手動変更は Sev1 対応時のみ許可して 24時間以内にコードへ反映します。週次で terraform plan の差分（ドリフト）を確認します。
• 廃止手順：事業責任者が判断し、3か月前に利用者へ告知します。停止後 30日間はデータ出力の要望に応じ、その後に削除して証跡を保管します。監視・定期作業・契約を停止し、廃止記録を残します。

RTO を見積もるにはリストアを実測する（PostgreSQL 16）

RTO の「リストア時間」は推測ではなく実測で埋めます。 記入例と同じ構造のテーブルに 50万行を入れ、pg_dump -Fc で取得したダンプを、テーブル削除後に pg_restore で戻した所要時間です（PostgreSQL 16.13、同一ホスト）。コマンドの詳細は pg_dump/pg_restore の記事で扱っているので、ここでは時間だけ示します。

tasks テーブル: 500000 行 / 50 MB（pg_total_relation_size）
pg_dump 実時間 0.7 秒      （-Fc、ダンプサイズ 4.2MB）
DROP TABLE                 （障害を模擬）
pg_restore 実時間 1.0 秒
500000                     （復元後の件数）

50MB のテーブルで 1秒でも、RTO は「検知 → 判断 → リストア → 確認」の合計です。 本番サイズのダンプではリストアに数十分かかることも多く、別リージョンからのダウンロード時間も加わります。実測値に余裕を見て書き、年2回の復元テストで更新します。

レビュー観点チェックリスト

運用設計書のレビューは「形容詞を数字と名前に置き換えられているか」を確認する作業です。 次のチェックリストを、レビュー依頼時に添えてください。

よくある質問

Q. 運用設計書と運用手順書は、どちらか1つにまとめてはいけませんか？ A. 小規模なら1つの文書に章を分けて書いても構いません。ただし「方針と判断基準（運用設計）」と「操作手順（運用手順）」は更新の頻度と読み手が違うので、章を分け、手順の章だけ頻繁に更新できるようにしておくと長く使えます。

Q. 監視の閾値は、記事の値をそのまま使ってよいですか？ A. 出発点としては使えますが、根拠の部分を自社の条件に置き換えてください。たとえばディスクの警告 80% は「増設に2週間かかる」前提の値なので、即日増設できる環境なら 85〜90% でも間に合います。四半期ごとに「鳴ったけれど対応しなかったアラート」を見直すと、閾値が自社に合っていきます。

Q. アジャイル開発やクラウドのマネージドサービスでも運用設計書は必要ですか？ A. 必要です。マネージドサービスはバックアップやフェイルオーバーの「手段」を提供しますが、「RPO/RTO をいくつにするか」「誰が復旧を判断するか」「権限を誰に与えるか」は利用者側が決める項目です。アジャイルなら、運用設計書もスプリントごとに差分更新する文書として扱います。

まとめ

• 運用設計書は、リリース後に「誰が・いつ・何を・どの基準で」行うかを運用前に決めた文書で、要件定義の非機能要件を受け取り、運用手順書やリリース手順書へ渡します。
• 15項目（監視、ログ、バックアップ、障害対応、定期作業、権限、変更管理、リリース、セキュリティ更新、容量、SLO/SLA、コスト、ドキュメント更新、IaC、廃止）を表で埋めると骨子ができます。
• 形容詞を数字と名前に置き換えるのが核心です。「速やかに」は「15分以内に電話」、「定期的に」は「月次、第1営業日、運用担当」と書きます。
• 監視の閾値には根拠を添えます。 ext4 の root 予約 5%、SLO から計算したバーンレート、Let's Encrypt の更新推奨タイミングのように、再計算できる形で残します。
• RTO はリストア時間の実測に、検知・判断・確認の時間を足して見積もり、復元テストで更新します。
• レビューでは要件との対応、閾値の2段階と根拠、復元テスト、重大度の定義、年次作業、権限の剥奪、切り戻し条件、廃止手順を確認します。
• 基本設計と並行して書き始め、構成変更の PR で差分更新すると、実環境とずれない文書になります。

株式会社RJCでは、運用設計書のように「リリース後に効いてくる設計」を、監視やバックアップの実測結果と根拠をもとにプロジェクトの中で仲間と学び合っています。こうした知識を共有しながら、日々技術を磨いています。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。