運用手順書（Runbook）の作り方：定常作業と障害対応を属人化させない

運用手順書（Runbook）は、「その作業を初めて担当する人が、手順書だけを見て、迷わず同じ結果を出せる」粒度で書くことが最も大切です。作った本人にとって当たり前の前提、たとえば「管理画面にログインして」の一言に含まれるアカウントの場所や権限、「ログを確認して」の一言に含まれる見るべき箇所と判断基準まで書き出して初めて、手順書は属人化を防ぐ道具になります。そして、誰でも実行できる粒度で書かれた手順は、そのまま自動化の設計図にもなります。

この記事は、自社サービスや社内システムの運用を担っている担当者、運用を特定の人に頼っている状態を変えたい事業責任者、そして「障害のたびに同じ人が呼ばれる」状況に悩んでいる方に向けて書いています。Runbookの役割と業務マニュアルとの違い、書くべき作業の選び方、手順書に含める項目、誰でも実行できる粒度の書き方、障害対応の手順書の書き方、更新し続ける仕組み、自動化へのつなげ方を順に説明します。

読み終えたときに、自社の運用作業のうち何から手順書にすべきかを決め、実際に使える手順書を一つ書き上げられることを目指しています。

運用手順書（Runbook）とは何か

Runbookとは、システムやサービスの運用で繰り返し行う作業や、障害が起きたときの対応を、手順として書き出した文書のことです。用語の詳細はRunbook（運用手順書）の解説ページにまとめています。

似た言葉に、業務全般の標準的なやり方を定めたSOP（標準作業手順書）や業務マニュアルがあります。違いを整理しておきます。

Runbookの特徴は、システムを操作する手順が中心であること、そして「うまくいかなかったときにどうするか」まで書くことです。業務マニュアルが通常の流れを説明するのに対して、Runbookは異常時の判断と対処を含めて、作業を完結させるための文書です。

Runbookがないと何が起きるか

運用作業の手順が文書になっていない会社では、次のような状況がよく見られます。

• 特定の担当者が休暇を取ると、月次の作業が止まる、あるいは休暇中に電話がかかってくる
• 障害が起きるたびに、同じベテランが呼ばれ、その人の判断と記憶に頼って復旧する
• 担当者によって手順が少しずつ違い、作業の結果にばらつきが出る
• 年に一度しかやらない作業（証明書の更新、年度切り替えなど）の手順を、毎回思い出すところから始める
• 新しく運用を担当する人の立ち上がりに時間がかかり、引き継ぎ期間が延びる

どれも、作業の手順が個人の頭の中にしかないことが原因です。業務の属人化そのものの解消については業務の属人化を解消する手順で詳しく説明していますが、システム運用の領域でその中心になるのがRunbookです。

手順書にすべき作業の選び方

すべての作業を一度に手順書にしようとすると、途中で止まります。次の観点で優先順位を付け、影響の大きいものから書き始めます。

意外に見落とされやすいのが「頻度の低い作業」です。毎日やる作業は体が覚えていますが、年に一度の作業は担当者本人でも忘れます。こうした作業こそ、実行したその日に手順を書き残しておく価値があります。

Runbookに含める項目

一つのRunbookには、次の項目を含めます。テンプレートとして用意しておくと、書く人によって抜けが出にくくなります。

• 作業名と目的：何のための作業か、実行しないと何が起きるか
• 実行のタイミング：定期（毎日・毎月○日など）か、何かが起きたとき（エラー通知を受けたとき、依頼があったとき）か
• 担当者と承認者：誰が実行し、誰の確認や承認が必要か
• 前提条件：必要な権限やアカウント、使う端末、事前に確認すべき状態
• 所要時間の目安：作業全体にかかる時間。時間がかかる作業は、途中で中断してよいかも書く
• 手順：番号付きで、一つの手順に一つの操作
• 確認方法：各手順や作業全体が正しく終わったことを、何を見て判断するか
• うまくいかなかったときの対処：よくあるエラーと対処、元に戻す方法、手に負えない場合の連絡先
• 作業後の連絡と記録：誰に報告するか、どこに記録を残すか
• 最終更新日と更新者：手順書がいつ、誰によって確認されたか

この中で最も抜けやすいのが「確認方法」と「うまくいかなかったときの対処」です。手順だけが書かれた手順書は、うまくいっているうちは役に立ちますが、想定外のことが起きた瞬間に読む人を置き去りにします。

誰でも実行できる粒度で書くコツ

手順書の価値は、書いた人以外が使えるかどうかで決まります。誰でも実行できる粒度にするために、次の点を意識します。

一つの手順に一つの操作を書く

「管理画面で対象の顧客を検索し、契約状況を確認して、問題なければ更新する」は、三つの操作と一つの判断が混ざっています。これを分けて番号を振り、判断の部分には基準を書きます。

場所と名前を具体的に書く

「管理画面」ではなく、どの管理画面か、どのメニューのどの項目か。「設定ファイル」ではなく、どこにある何という名前のファイルか。画面のボタン名や項目名は、実際の表示どおりに書きます。

判断には基準を添える

「問題がなければ次へ進む」と書くなら、何をもって問題なしとするかを書きます。「処理件数が前月と大きく違わなければ」よりも、「処理件数が前月の件数と比べて極端に少ない、または0件の場合は作業を止めて担当者に連絡する」の方が、初めての人でも判断できます。

期待する結果を書く

各手順の後に「この操作をすると、画面に完了のメッセージが表示される」「数分後に、チャットに完了通知が届く」のように、正しく進んだときに何が起きるかを書きます。期待する結果と違うことが起きたら、その時点で立ち止まれます。

危険な操作を目立たせる

本番データの削除、顧客への送信、取り消せない操作の前には、太字で注意書きを入れ、確認すべきことを書きます。

初めての人に試してもらう

書いた手順書は、作業に慣れていない人に実際に使ってもらい、迷った箇所、分からなかった言葉を聞き取って直します。この一手間で、手順書の実用性は大きく変わります。

書き方の例：粗い手順と使える手順

架空の作業「月初の請求データ作成」を例に、粗い書き方と使える書き方を比べてみます。

粗い書き方は次のようなものです。

管理画面から請求データを作成し、件数を確認して問題なければ確定する。

これを、初めての人でも実行できる粒度に直すと、次のようになります。

1. 社内の管理画面に、運用用の共有アカウントでログインする（認証情報はパスワード管理ツールの「運用」フォルダにある）。

2. 左メニューの「請求」から「請求データ作成」を開く。

3. 対象月の欄に前月を選び、「下書きを作成」を押す。数分後、画面上部に「下書きを作成しました」と表示される。

4. 下書きの一覧で、件数と合計金額を確認する。前月の確定分と比べて件数が極端に少ない、または0件の場合は、ここで作業を止めて技術担当に連絡する。

5. 問題がなければ「確定」を押す。確定すると顧客に請求メールが送信され、取り消せない。 押す前に対象月をもう一度確認する。

6. 作業記録のシートに、実行日、件数、合計金額、実行者を記入する。

文字数は増えますが、迷う余地はほとんどなくなります。手順書の長さは、読み手が迷わないための必要経費と考えましょう。

障害対応のRunbookの書き方

定常作業の手順書とは別に、障害が起きたときの対応の手順書も用意します。障害対応では、落ち着いて考える時間が少ないため、判断の分かれ道をあらかじめ書いておくことが特に重要です。

障害対応のRunbookは、次の流れで書くと使いやすくなります。

1. 症状の確認：どんな通知や連絡で障害に気づくか。影響の範囲（全利用者か、一部か、特定の機能か）をどう確かめるか。
2. 初動の連絡：誰に、どの経路で、どんな内容を知らせるか。利用者への告知が必要かどうかの判断基準。
3. 切り分け：よくある原因の候補と、それぞれを確かめる方法。「外部サービスの障害情報を確認する」「直近のリリースや設定変更がなかったか確認する」など。
4. 暫定対応：サービスを早く元に戻すための手段。再起動、直前の版に戻す、機能を一時的に止める、手作業で代替する、など。それぞれの実行条件と手順。
5. エスカレーション：自分で対応できないと判断する基準と、次に連絡する相手（社内の技術者、開発会社、外部サービスの窓口）。
6. 復旧の確認と報告：復旧したと判断する基準、関係者と利用者への報告。
7. 記録：何が起きて、どう対応したかを残す場所と項目。

連絡体制や復旧手順を事前に決める方法はシステム障害時の対応フローでも詳しく解説しています。また、障害が収まった後は、原因と再発防止策を振り返るポストモーテムを行い、その結果をRunbookに反映します。障害のたびに手順書が少しずつ良くなっていく流れを作ることが、運用を強くする近道です。

手順書を更新し続ける仕組み

手順書は、書いた時点から古くなり始めます。古い手順書は、手順書がない状態より危険なこともあります。書いてあるとおりに操作したのに、画面が変わっていて別の操作をしてしまう、といった事故が起きるからです。

更新し続けるために、次の仕組みを用意します。

• 作業のたびに手順書を見ながら実行する：慣れた人も手順書を見ながら作業し、違っていた箇所はその場で直す。これが最も確実な更新の方法です。
• システム変更の確認項目に手順書の更新を入れる：画面の変更、設定の変更、新機能の追加の際に、影響する手順書を洗い出して更新する。
• 最終更新日を表示し、古いものを定期的に見直す：一定期間更新されていない手順書を一覧にして、担当者に確認してもらう。
• 頻度の低い作業は、実行前に予行演習する：年に一度の作業は、本番の少し前に手順書を読み合わせ、変わっている点がないか確認する。
• 副担当に実行してもらう機会を作る：定期的に、正担当ではない人が手順書だけを見て作業する。分かりにくい箇所が見つかる。

Runbookから自動化へつなげる

誰でも実行できる粒度で書かれた手順書は、自動化の設計図でもあります。一つの手順に一つの操作、判断には基準、期待する結果が書かれていれば、それはそのまま「コンピューターに何をさせるか」の仕様になるからです。

手順書を自動化につなげるときは、次の順で考えます。

1. 判断を含まない手順から自動化する：決まった操作を決まった順番で行うだけの手順は、自動化しやすい。
2. 確認方法を自動のチェックにする：「処理件数が0件なら止める」のような確認は、自動化の中に組み込める。
3. 判断が必要な箇所は人に残す：基準が曖昧な判断、例外の多い判断は、自動化の途中で人に確認を求める形にする。
4. 自動化した後も手順書を残す：自動化が止まったときに手作業で代替する手順、自動化を止める方法、再実行の方法を手順書として残す。

特に4が重要です。自動化すると手順書が不要になると思われがちですが、実際には「自動化が動いていないときにどうするか」の手順書が新たに必要になります。夜間バッチなど定期処理の失敗検知と再実行の設計については、夜間バッチ・定期処理の設計で詳しく説明しています。

よくある失敗とその避け方

• 詳しい人が書いて、前提が抜ける：書いた手順書を、作業に慣れていない人に試してもらい、迷った箇所を直す。
• 手順だけで、異常時の対処がない：テンプレートに「確認方法」と「うまくいかなかったときの対処」の欄を設け、空欄のままにしない。
• 完璧を目指して書き終わらない：まず最低限の手順と連絡先だけで公開し、作業のたびに足していく。
• 置き場所がばらばらで、緊急時に見つからない：Runbookの置き場所を一か所に決め、障害通知やチャットの固定メッセージからすぐ開けるようにする。
• 自動化したら手順書を捨てる：自動化が止まったときの代替手順と再実行の方法を残す。

具体的な場面の例

架空の一般的な例で考えます。

会員制のWebサービスを運営する小さな会社で、月初の請求データ作成、会員の退会処理、外部の決済サービスとの売上の突き合わせを、技術担当の一人が手作業と簡単なスクリプトで行っていたとします。その担当者が長期休暇を取ることになり、代わりの人が作業しようとしたところ、どのスクリプトをどの順番で動かせばよいか、結果が正しいかをどう確かめればよいかが分からず、作業を休暇明けまで延期することになりました。

この会社は休暇明けに、まず月初の請求データ作成から手順書にしました。担当者が実際に作業しながら画面と操作を記録し、各手順の後に「何が表示されれば正しいか」を書き加えました。処理件数の確認方法と、件数がおかしいときの連絡先も明記しています。翌月は、別の社員が手順書だけを見て作業し、担当者は横で見守る形で、分かりにくかった箇所を直しました。

手順書が安定した後、件数の確認や突き合わせのように判断を含まない部分から自動化を進めています。自動化した部分についても、止まったときに手作業で代替する手順は手順書に残しました。

Runbook作成のチェックリスト

• 手順書にすべき作業の一覧と、優先順位がある
• 手順書のテンプレートがあり、確認方法と異常時の対処の欄が含まれている
• 一つの手順に一つの操作が書かれている
• 画面名、項目名、ファイルの場所が具体的に書かれている
• 判断が必要な箇所には、基準が書かれている
• 取り消せない操作の前に、注意書きがある
• 作業に慣れていない人が、手順書だけで実行できることを確かめた
• 障害対応の手順書に、初動の連絡、切り分け、暫定対応、エスカレーションが含まれている
• 手順書に最終更新日と更新者が表示されている
• 自動化した作業についても、止まったときの代替手順が残っている

よくある質問

Q. 手順書は画面のスクリーンショットを多用した方がよいですか？

分かりやすさは増しますが、画面が変わるたびに撮り直しが必要になり、更新の負担が大きくなります。重要な画面や間違えやすい箇所に絞って使い、基本はボタン名や項目名を文字で正確に書く方が、長く保守しやすくなります。

Q. 作業の担当者が手順書を書く時間を取れません。どうすればよいですか？

作業中に画面共有をしながら、別の人が操作を記録する方法があります。担当者は普段どおりに作業し、聞き手が「今のは何を確認したのですか」と質問しながら書き取ります。担当者が一人で書くより短時間で、前提の抜けも少ない手順書になります。

Q. 手順書はどのツールで管理するのがよいですか？

社内で普段使っている文書管理の仕組みで十分です。大切なのは、緊急時にすぐ開けること、更新履歴と最終更新日が残ること、運用に関わる全員が閲覧できることの三点です。システムが止まったときにも見られるよう、対象のシステムとは別の場所に置いておくことも忘れないでください。

Q. 開発会社が作ったシステムの運用手順書は、誰が書くべきですか？

システムの操作や障害時の技術的な対応は開発会社が、業務上の判断や社内の連絡体制は自社が書くのが一般的です。保守契約を結ぶ際に、手順書の作成と更新をどちらがどこまで担うかを決めておくと、後で抜けが生じにくくなります。

Otsumuに相談できること

運用作業の数が限られていて、作業の中身を説明できる担当者が社内にいるなら、この記事のテンプレートと書き方を使って、自社でRunbookを整えることは十分可能です。まずは失敗の影響が大きい作業か、特定の一人しかできない作業を一つ選び、慣れていない人に試してもらうところまでやってみてください。

一方で、作業の中身を説明できる人がもういない、スクリプトや設定が複雑で手順として書き起こすこと自体が難しい、手順書を整えたうえで自動化まで進めたい、といった場合は、システムの中身を読み解ける技術者と一緒に進めた方が早く確実です。

Otsumuでは、運用作業の棚卸しと優先順位付けから、手順書の作成支援、障害対応フローの整備、手順書をもとにした自動化と監視の仕組みづくりまでを一貫して支援しています。詳しくは自社サービス運用の自動化コンサルティングやシステム保守・運用のページをご覧ください。

どの作業から手を付けるべきか迷っている段階でも構いません。30分の無料相談で、現状の運用を伺いながら一緒に整理します。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01