Tsuzura

Webサービスの最低限の運用設計

Webサービスを継続して運用するために、担当、監視、繰り返し作業、バックアップと復旧、見直しを一つの運用設計票にまとめる方法です。

公開日
更新日

サービスを公開しても、翌日から自動的に運用されるわけではありません。異常を誰が確認するのか、期限のある作業を誰が行うのか、問題が起きたときにどこまで止めてよいのかが決まっていなければ、対応はその場の判断に依存します。

運用設計は、公開後のサービスを継続して扱うための決め事です。社内向けと顧客向けのどちらも対象になります。この記事は、初めてサービスを運用する人に向けたものです。読み終えると、一つのサービスについて、対象、責任、異常の発見、繰り返し作業、復旧、見直しをまとめた運用設計票を作れます。

対象は、すでに公開済みか、公開直前の確認まで終えたサービスです。公開する版やテストの証拠が決まっていない場合は、先にサービス公開前の確認へ戻ります。

監視製品の設定、24時間の当番体制、障害対応全体、災害復旧の詳しい設計は扱いません。監視の閾値や復旧時間に、すべてのサービスに共通する固定値も置きません。

最低限の運用設計とは

最低限の運用設計では、公開済みの一つのサービスについて、担当、異常の見つけ方、最初の行動、繰り返し作業、復旧方法、見直す条件を決めます。決めた内容は、一つの主記録へまとめます。

サービス公開前の確認では、一回の変更について、公開する版、証拠、停止条件、復旧方法を決めました。運用設計では、その公開記録を入力にして、翌日以降の担当、確認、作業、連絡へ変えます。公開候補の識別や公開可否は、ここで決め直しません。

テスト、監視、繰り返し作業、障害対応にも違いがあります。

活動 確認すること 主な時点
テスト 決めた条件で期待する結果になるか 変更前後の限定した確認
監視 動いているサービスが現在どの状態か 継続、または決めた条件・間隔
繰り返し作業 期限や変更に応じた確認・更新が終わったか 期限、担当変更、構成変更等の発生時
障害対応 異常の影響をどう抑え、連絡・復旧へ進むか 異常の発見後

テストの種類や結果が未整理な場合は、テストの種類と選び方を確認します。テスト合格は、公開後の監視や担当が不要という意味ではありません。

本記事でいう「最低限」は、外部規格の固定された項目ではありません。初めて運用する人が、一つのサービスを継続して扱うための編集上の区分です。運用設計票が完成しても、障害が起きないことや、決めた時間内に必ず復旧できることまでは保証しません。

運用する対象と責任を決める

運用対象は、一つのサービスと、その稼働に直接必要な外部サービスまでに限定します。会社全体の機器、アカウント、契約を棚卸しする作業ではありません。

現在の状態と正本を決める

最初に、現在動いている版と公開記録への参照を残します。ここでいう正本とは、現在の状態を確認するときに、最新として扱う一つの記録です。同じ情報を複数の文書へ写さず、コード、設定、監視、手順の正式な保存場所へ到達できる参照先を書きます。

公開記録から受け取るのは、現在の版、公開時に選んだ監視情報、停止・復旧方法、未解決事項です。公開用の成果物を作った記録や、テストの証拠表は再掲しません。

外部の認証、データ保存、メール送信等が停止するとこのサービスも停止する場合は、その依存先を対象へ加えます。すべての契約を並べる必要はありません。対象サービスの動作、データ、復旧へ直接影響するものだけを記録します。

担当者名だけで終わらせない

責任の欄には、名前に加えて、何を判断できるか、どの操作を行えるか、通常時と緊急時にどう連絡するかを書きます。

情報処理推進機構の中小企業向けガイドラインは、責任者の責任・権限と、通常時・緊急時の連絡先を文書化し、異動・退職時にはアクセス権を見直すよう示しています。これは日本の中小企業向けの情報セキュリティ指針です。本記事では、担当が変わったときに連絡先も現在の状態へ更新する項目を加えています。

次の責任を区別します。同じ人が複数を担っても構いません。

  • 日常の確認と繰り返し作業を行う
  • サービスを停止・制限するか判断する
  • 復旧方法と利用再開を判断する
  • セキュリティ、個人情報、契約等の専門的な判断を引き受ける

代替担当を一律に求めるものではありません。担当者が一人なら、不在時にサービスを継続するのか、利用を止めるのか、外部の窓口へ連絡するのかを記録します。24時間対応も必須ではありません。対応できる時間帯と、対応できない間に起きた異常の扱いを決めます。

外部事業者へ運用を委ねても、内部の判断者は残ります。NIST SP 800-61r3は、第三者と連携する場合も、情報の流れ、調整方法、第三者が使える権限と制限を明確にするよう示しています。米国の任意指針であり、日本の契約や報告義務を置き換えるものではありません。

記録項目 書く内容
対象 サービス名、目的、利用者、現在動いている版・環境
参照先 公開記録、運用情報の正本、停止・復旧方法
日常の担当 担当する作業、必要な権限、連絡方法
判断者 停止・制限・復旧・利用再開の判断範囲
対応時間 対応できる時間帯、不在時の連絡・利用制限
直接依存 外部サービス、社内担当、障害窓口、復旧・契約終了時の自分たちと相手の担当範囲

異常の見つけ方と最初の行動を決める

異常を見つけるには、利用者にとって重要な結果を先に決めます。その結果を見る場所、異常とする条件、通知先、最初の行動、担当を一つの行にまとめます。

監視とは、決めた情報を継続または一定の条件で確認し、正常と異常を見分けられる状態にすることです。アラートは、人の対応が必要な条件で送る通知です。監視しているだけでは、必要な相手へ通知が届くとは限りません。

利用者にとって重要な結果から選ぶ

内部の数値だけを見ても、利用者がサービスを使えているかは判断できません。まず、サービスの目的を達成できたかを判断でき、成功と失敗の両方を確認できる結果を一つ選びます。その結果が決まっていない場合は、先に要件と受入条件の決め方へ戻ります。

次に、利用者に見える症状と、原因を調べるための内部情報を分けます。Google SREの「Monitoring Distributed Systems」も、この二つを異なる目的の監視として説明しています。

利用者向けサービスで、最初の監視情報を絞るときは、次の4種類が候補になります。

監視する情報 確認できること
遅延 処理を始めてから結果が返るまでの時間
処理量 リクエストや処理がどれだけ発生しているか
エラー 期待した結果を返せなかった割合や件数
処理能力の余力 容量や処理能力が上限へ近づいているか

Google SREはこれらを、遅延、Traffic、Error、Saturationと呼んでいます。ただし、すべてのサービスをこの4種類だけで監視できるわけではありません。重要な処理の成否、定期処理の失敗、データが最後に更新された時刻等、サービス固有の重要な結果は別に加えます。4種類すべてを人へのアラートにする必要もありません。

手動確認と自動通知を分ける

異常条件を決めたら、手動で確認するか、自動で通知するかを選びます。影響がすぐには広がらず、決めた時点で担当者が確認できるなら、手動確認も選べます。対応の遅れによって影響が広がる場合は、自動通知と受信後の担当が必要です。

人へ送るアラートには、対応手順、担当、より広い影響や強い権限を扱う判断者へ渡す条件を結び付けます。GoogleとAWSの公式資料も、対応できない通知を増やさず、アラートごとに更新された手順と責任者を持たせるよう案内しています（Google SRE「Incident Management Guide」、AWS Well-Architected Framework「OPS10-BP02」）。

通知を受け取る人がいない時間帯も記録します。自動通知を設定しても、その時間に対応できる人がいなければ、早い復旧は保証されません。24時間対応が必要かは、利用時間と異常時の影響から決めます。

最初の行動と引き継ぐ条件を決める

最初の行動には、現在の影響を確認し、必要な記録を残し、事前に許可された範囲で影響を抑えるところまでを書きます。原因を推測したまま本番環境を変更する手順にはしません。

担当者だけで判断できない状態も先に定義します。セキュリティやプライバシーに関わる疑いがある場合は、通常の障害対応だけで完結させず、事前に決めた責任者や専門窓口へ渡します。NIST SP 800-61r3とIPAの中小企業向けガイドラインは、セキュリティ事故を主な対象にしています。すべての運用障害へ同じ調査手順を適用する意味ではありません。

報告先や期限は、扱うデータ、契約、業種、地域によって変わります。本記事の運用設計票だけで、法的な報告の要否は判断できません。

通知が届くところまで確認する

監視値が表示されても、通知設定が正しいとは限りません。Google SRE Workbookの「Monitoring」は、次の3段階を分けて確認する方法を示しています。

  1. 対象の値が想定した条件で変化する
  2. 通知ルールがその値を判定して発火する
  3. 通知が予定した相手や窓口へ届く

実際の異常を安全に再現できない場合は、監視製品のテスト機能や、結果が分かっているテスト用の信号を使います。障害を意図的に起こす必要はありません。

通知先、判定ルール、担当が変わったときは、予定した相手に届くまで確認し直します。アラートが届いた記録は設定の確認にはなりますが、すべての異常を検知できることや、一定時間内に復旧できることまでは保証しません。

重要な利用者結果 見る情報 閲覧先 異常とする条件 手動確認／自動通知 最初の行動 担当 判断を引き継ぐ条件

分からない項目は推測で埋めず、「未確認」とします。通知経路を確認した場合は、確認日、使った信号、発火したルール、実際の通知先、受信結果も残します。

繰り返す作業を決める

繰り返す作業は、日次・週次・月次の固定分類ではなく、期限または発生条件から決めます。実際のサービスに関係しない確認を増やす必要はありません。

一件の作業に、次の情報をまとめます。

項目 記録する内容
作業 何を確認・更新するか
期限・発生条件 いつ、または何が変わったときに行うか
担当 誰が行い、誰が結果を判断するか
証拠 実施日、結果、記録の保存先
未実施時の扱い 影響、連絡先、停止・制限の要否

対象候補は、現在使っている仕組みと、期限・変更がサービスに与える影響から選びます。

  • 運用者とサービス用アカウントのアクセス権
  • サービスを動かす環境、利用中のソフトウェア部品、外部サービスの保守・提供終了
  • 外部サービスへ接続する鍵や認証用の値等、秘密情報の更新・失効
  • 直接依存する外部サービスの変更、契約、サポート窓口
  • ドメイン、証明書、保存容量、利用上限等の期限・条件
  • 後述するバックアップと復元確認

NIST Cybersecurity Framework 2.0は、アクセス権を必要最小限に管理し、運用中も見直すことに加え、ソフトウェアをリスクに応じて保守・交換・削除する成果を示しています。固定の更新頻度や特定の製品を指定する資料ではありません。

秘密情報については、OWASPのSecrets Management Cheat Sheetが、用途、利用主体、更新・失効方法、漏えい等の事故時の連絡先を記録対象として示しています。運用設計票には秘密情報の値を書かず、安全な保管先の参照名だけを残します。

外部サービスについては、用途、影響する機能・データ、社内の担当、障害時の連絡先を確認します。復旧時の自分たちと相手の担当範囲や、契約終了時のデータとアクセス権の扱いも対象です。IPAの中小企業向けガイドラインとNIST Cybersecurity Framework 2.0も、外部サービスの一覧、契約上の要件、事故・復旧時の役割、利用終了後の処理を管理対象に含めています。すべての外部サービスに代替事業者や複数のクラウドを用意する意味ではありません。

作業が終わらなかった場合は、期限だけを先へ動かしません。未実施と記録し、サービスへの影響、判断する人、次に確認する条件を残します。主記録で履歴を追いにくくなった場合だけ、繰り返し作業表を別紙にします。

データがある場合の復旧を決める

サービスの停止後も必要になるデータがあるなら、バックアップの有無だけでなく、必要な時点まで、許容できる時間内に、使える状態へ戻せるかを決めます。

NIST Cybersecurity Framework 2.0は、バックアップの作成・保護・試験を挙げています。復元前後のデータに必要な内容が欠けたり壊れたりしていないかと、通常のサービスへ戻ったことの確認も対象です。IPA「中小企業の情報セキュリティ対策ガイドライン 第4.0版」は、対象、頻度、保管場所、異なる時点のバックアップを何回分・どのくらいの期間残すか、復元手順を決めるよう示しています。実際に復元できるかを確かめることも示しています。バックアップ処理の成功表示だけで、復旧可能とは判断しません。

データの管理方法を分ける

ここでいうデータは、サービスを止めた後も業務や利用を続けるために残す情報です。最初に現在の管理方法を分けます。

現在の状態 記録する内容
データを保存していない その判断を確認した人と見直す条件
安全に再生成できる 正しい元データ、再生成手順、必要な権限、再生成後の確認方法
外部事業者が管理している 契約・プランの範囲、保持条件、復元の依頼方法、社内担当、連絡先
自分たちが管理している バックアップ対象、取得・保管・保持・保護、復元手順、復元確認

データを保存していない場合は、バックアップ・復元票を作らなくても構いません。ただし、アプリ、設定、外部サービスとの接続を戻す手順まで不要になるわけではありません。

分からない項目を「データなし」や「該当なし」にしません。「未確認」とし、確認する担当と期限を付けます。外部事業者を使っている場合も、誰が復元を依頼し、どこまでを相手が担当するかは社内側で把握します。

RTOとRPOを決める

RTOとRPOは復旧の目標です。自社の目標は、実際に達成できた値や、外部事業者との契約値と自動的に同じになるものではありません。契約に値が定められている場合は、自社の目標との差を確認します。

  • RTO（Recovery Time Objective、目標復旧時間）：サービスが止まってから、重要な業務を再開するまでに許容できる時間。データを戻す時間だけでなく、アプリを起動し、データと機能を確認する時間も含めます。
  • RPO（Recovery Point Objective、目標復旧時点）：障害直前までのデータのうち、最大でどれだけの時間分を失っても業務を続けられるかを表す目標。

バックアップの取得間隔を書いただけでは、RPOを満たした確認にはなりません。実際にどの時点のデータへ戻せたかを復元確認で確かめます。

RTOとRPOに全サービス共通の値はありません。停止やデータ損失による業務への影響、復旧に使える費用、現在の構成で実現できるかを確認して決めます。機能ごとに影響が異なるなら、同じ値へ揃える必要もありません。

Microsoft Azureの事業継続・災害復旧ガイドとGoogle CloudのDisaster recovery planning guideも、業務への影響を基にRTO・RPOを決め、小さい値ほど費用と構成の複雑さが増える点を説明しています。値を決められない場合は推測で埋めず、止まる業務と失われるデータを業務の判断者へ確認します。

実際に復元して確認する

バックアップ処理の成功表示は、復旧できた証拠ではありません。本番へ影響しない方法・環境でバックアップから復元し、次を記録します。

  1. 復元したデータを読み取れ、必要な内容が欠けたり壊れたりしていないか
  2. アプリを起動し、復旧対象の機能を使えるか
  3. どの時点のデータまで戻り、決めたRPO内だったか
  4. 復元を始めてから確認を終えるまでの時間が、決めたRTO内だったか

確認できなかった項目があれば、復旧成功とは扱いません。データの上書き・削除が起き得る、必要な権限がない、手順と実際の構成が異なる場合も作業を止めます。

復旧手順書を作る

復旧手順書は、復旧時に実行する操作と判断を順番に記録したものです。Runbookとも呼ばれます。担当者名だけの連絡表ではありません。

手順書には、始める条件、開始の判断者、必要な権限と前提、具体的な操作を書きます。操作ごとの期待結果、作業を止めて判断を引き継ぐ条件、復旧後の確認と連絡も必要です。Microsoft Azureの公式ガイドは、復旧計画を明確で実際に試せる状態にするよう案内しています。Google Cloudの公式ガイドは、復旧作業を具体的で曖昧でない操作として書くよう案内しています。

担当者、連絡先、権限、アプリ、データの構造が変わったときは、手順書も見直します。外部事業者、契約、復旧方法の変更も見直す条件です。文書を渡すだけでなく、次の担当が必要な権限を使え、手順の場所を見つけられるかも確認します。

データがある場合の別紙は、少なくとも次を記録します。

# バックアップ・復元票

## 対象と責任
- データの状態（保存なし・再生成・外部管理・自社管理・未確認）:
- 復旧対象の機能・データ:
- データの管理責任者:
- 復旧の判断者と連絡方法:

## 復旧目標
- RTOと業務上の理由:
- RPOと業務上の理由:
- 目標を承認した人:

## バックアップまたは再生成
- 対象・取得方法・頻度:
- 保管先・保持期間・異なる時点のバックアップを何回分残すか:
- 保護方法とアクセスできる人:
- 外部事業者の責任範囲・依頼方法・連絡先:

## 復旧手順書
- 手順書の場所と現在の版:
- 開始条件と判断者:
- 必要な権限・設定・ソフトウェア・成果物:
- 作業の停止条件と連絡先:
- データとサービスの確認方法:

## 最終復元確認
- 確認日・環境・対象:
- 復元できたデータの時点とRPOとの比較:
- 復元開始から確認完了までの実測時間とRTOとの比較:
- 必要なデータが欠けたり壊れたりしていないかと、サービスの動作結果:
- 証拠の保存先:
- 未確認、RTO・RPOを満たせなかった結果、対応担当、期限:

この別紙は、項目を埋めただけでは完成ではありません。復元したデータとサービスを確認し、その結果をRTO・RPOと比べられたところまでが「確認済み」の範囲です。

運用設計票を作り、見直す

運用設計票は、一つのサービスにつき一つの主記録にします。物理的な紙一枚に収めることより、現在の状態を一か所から確認できることが重要です。

まず次のテンプレートを複製し、「対象」から「見直し」まで順に記入します。空欄は残さず、確認できていない項目は「未確認」、対象外と判断できた項目は「該当なし」と理由を書きます。最後に「運用を続けられるか確認する」の6問へ答え、票の状態を判定します。

# 運用設計票

## 1. 対象
- サービス名・目的・利用者:
- 現在動いている版・環境:
- 公開記録:
- 運用情報の正本:
- 直接必要な外部サービス:
- 外部サービスごとの自分たちと相手の担当範囲:
- 外部依存表の参照先（必要な場合）:

## 2. 責任
- 日常の担当:
- 各担当に許可された操作・必要なアクセス権:
- 停止・制限を判断する人:
- 復旧・利用再開を判断する人:
- 通常時・緊急時の連絡方法:
- 対応できる時間帯:
- 対応できない間の扱い:

## 3. 異常の発見
- 利用者にとって重要な結果:
- 確認する情報・閲覧先:
- 異常と判断する条件:
- 手動確認または自動通知の方法:
- 通知先・確認担当:
- 通知が予定した相手に届いた確認日・受信結果・証拠:
- 最初の行動と判断を引き継ぐ条件:

## 4. 繰り返し作業
- 作業:
- 期限または発生条件:
- 担当・証拠の保存先:
- 未実施時の影響・連絡・判断:

## 5. 復旧
- 保存データの有無と管理主体:
- サービスを戻す方法の参照先:
- バックアップ・復元票の要否:
- 最終復元確認の日付・結果・証拠:
- 未確認の場合の担当と期限:

## 6. 見直し
- 未解決事項:
- 該当なしとした項目と理由:
- 期限を過ぎた項目:
- 必要な別紙:
- 次に見直す日または変更条件:
- 運用を続けられない条件:
- 最終更新日・変更理由・確認者:
- 過去の変更履歴の参照先:

本記事では、票の状態を次のように区別します。これは外部規格の区分ではありません。

状態 判断
確認済み 該当する欄を根拠とともに確認し、末尾の6問へ答えられる
暫定 未確認項目はあるが、その影響を確認し、担当・期限・利用範囲を判断者が決めている
運用開始・継続不可 影響が大きい項目で、異常の発見、連絡、利用制限、復旧の入口または判断者を確認できない

暫定は完成ではありません。決めた期限か見直し条件に達したら、未確認項目を判断し直します。

主記録だけで判断できない場合に限り、別紙を追加します。

別紙 作る条件 最小の内容
監視表 重要な結果・利用者群で閲覧先や担当が異なる 対象、情報、閲覧先、異常条件、通知先、最初の行動
繰り返し作業表 主記録だけで期限・履歴を追えない 作業、期限・発生条件、担当、証拠、未実施時の扱い
バックアップ・復元票 失うと困るデータ、再生成手順、外部への復元依頼がある 対象、RTO・RPO、取得・保管、復旧手順書、最終復元確認
障害初動手順 最初の行動、停止・制限、連絡、復旧を数行で説明できない 発動条件、確認、記録、利用制限、連絡、復旧へ移る条件
外部依存表 外部サービスの停止・変更が直接影響する 用途、社内担当、状態確認先、障害窓口、期限・上限、停止時の扱い
権限・秘密情報表 管理用・サービス用アカウントや秘密情報がある 所有者、利用主体、権限範囲、見直し・更新・失効方法。値は書かない
連絡表 障害時に社外または複数部門へ連絡が必要になる 判断者、連絡先、連絡手段、承認経路

「将来必要になるかもしれない」だけでは別紙を作りません。現在のデータ、依存先、利用者影響から必要なものだけを追加します。

未確認、該当なし、期限超過を分ける

  • 未確認：必要な情報、証拠、判断がまだない。確認する担当と期限を書きます。
  • 該当なし：現在のサービスには必要でない。対象外と判断した理由と見直す条件を書きます。
  • 期限超過：予定した作業が終わっていない。新しい期限だけで上書きせず、影響と判断を残します。

現在の運用設計票と、過去の変更履歴も分けます。現在の担当・条件・手順を一か所で読めるようにし、変更した日、理由、確認者は履歴に残します。

AIに下書きを任せる範囲

承認された運用記録を読めるAIは、参照先の整理、空欄の検出、更新候補の一覧化を補助できます。ただし、読み取れることと、外部AIへ情報を渡してよいことは別です。組織で承認されたAIと接続先だけを使い、個人情報、顧客情報、機密情報、秘密値を除外します。

AIには、読み取ってよい記録と返答形式を指定します。本番サービスの停止・再起動、データ変更、アクセス権の変更、秘密値の取得、復旧の最終判断は対象外にします。指示文に禁止事項を書くことと、AIが実際に操作できないよう権限を制限することも別です。

OpenAIのCodex向け権限ガイドでは、Sandboxが操作できる範囲を、Approval policyが承認判断を必要とする地点を制御します。これはCodex固有の仕組みです。ChatGPT、Gemini、Claude等を使う場合も、そのAIが持つ実際の読取・書込・通信・承認の制御を個別に確認します。

次の空欄を使うと、運用設計票の下書きだけをAIへ依頼できます。

# 運用設計票の整理依頼

## 読み取ってよい記録
- 対象と参照先:
- 除外した情報:

## 整理する項目
- 6つの区分の各欄に対応する根拠と参照先:
- 情報が矛盾する欄:
- 未確認の欄と、確認に必要な情報:
- 必要条件がある別紙候補:

## 禁止する操作
- ファイル・設定・データの変更:
- 本番サービスの停止・再起動:
- 権限変更・秘密値取得・外部への連絡:

## 返答
- 根拠から下書きできる欄:
- 下書きできない欄と理由:
- AIが追加した仮定（運用設計票へ転記せず、未確認として人が判断する）:
- 人が確認する記録・設定・証拠:

人は、AIの下書きに書かれた参照先を開き、現在の担当・連絡先・権限、通知が予定した相手に届いた記録、最終復元確認の証拠を確かめます。AIが出した原因候補や復旧案を、確認せず本番操作の理由にしません。

運用を続けられるか確認する

完成した運用設計票について、次を説明できるか確認します。

  • 現在のサービスと運用情報の正本はどこか
  • 誰が日常の確認を行い、誰が停止・復旧を判断するか
  • 利用者にとって重要な結果を何で確認し、異常時に最初に何を行うか
  • 次の期限・変更で行う作業と、未実施時の扱いは何か
  • データがある場合、誰がどの手順で復元し、最後にどの証拠で確認したか
  • 未確認、該当なし、期限超過の項目と、次に判断する人・条件は何か

サービスの影響が大きいのに、異常の発見、連絡、利用制限、復旧の入口を説明できない場合は、推測で運用開始済みにしません。利用範囲を制限するか、必要な責任者や専門家へ判断を渡します。

担当、連絡先、アクセス権、データ、外部サービス、復旧方法が変わったときは、主記録と必要な別紙を更新します。公開後や障害後に前提が変わったとき、繰り返し作業が期限を過ぎたときも見直しの契機です。

出典