【インフラ現場直伝】迷わない手順書の書き方｜オペミスを根絶する5原則

深夜2時の本番メンテナンス。ターミナルに向かう作業者が緊張で指先を強張らせながらEnterキーを叩く。次の瞬間、チャットツールに流れる「アラート検知」「サービス応答なし」の通知——。

インフラエンジニアやシステム運用担当者にとって、オペミス（誤操作）は常に隣り合わせにある最大の恐怖です。そして事故が起きるたび、現場では次のような「再発防止策」が繰り返されてきました。

• 「指差し確認とダブルチェックを徹底する」
• 「本番作業時はもっと緊張感と集中力を持って臨む」
• 「作業チェックリストの確認項目を増やす」

断言しますが、これらは本質的な対策ではありません。精神論や個人の注意力でヒューマンエラーを防ぐことは不可能です。

人間は疲労しますし、深夜には認知機能が低下し、障害対応のプレッシャー下では誰でも視野狭窄に陥ります。

事故を招く真の原因は、作業者のスキル不足ではなく「迷いや誤認の余地を残した手順書そのものの記述不備（ライティングの欠陥）」にあります。

この記事では、「設計書」と「手順書」の本質的な違いを整理したうえで、誰が実行しても100%同じ結果を再現できる手順書のライティング5大原則と、現場ですぐに使える作業指示書テンプレートを解説します。

設計書と手順書の違いとは？混同がオペミスを生む理由

多くの現場でオペミスが減らない根本原因の一つに、「設計書の延長線上で手順書を書いてしまう」という構造的な問題があります。

まずは、この2つの文書が持つ役割と前提の違いを明確にしましょう。

設計書は「思考を促す文書」です。一方で、手順書は「作業者の思考や迷いを極限まで排除し、行動を正しく縛る文書」でなければなりません。

手順書の中に「適宜バックアップを取得する」「状況に応じてサービスを再起動する」といった表現が混ざっている現場は危険信号です。

「適宜」の判断基準が作業者任せになっている時点で、その手順書はすでに安全装置としての機能を果たしていません。

手順書を開いた作業者に「これってどういう意味だろう？」「どのサーバーで打てばいいんだ？」と考えさせてはいけません。作業者が疑問を持った瞬間、その手順書には不備があると考えましょう。

💡 あわせて読みたい

システムの仕様やアーキテクチャの妥当性を関係者に正しく伝えるための「設計書」の書き方については、以下の記事で詳しく解説しています。

あわせて読みたい

システム設計書の読み方・書き方完全ガイド｜新人インフラエンジニアが最短で成長する4ステップ 配属初日に手渡される、鈍器のような厚さのPDFファイルや、無数に並んだExcelシート。 「とりあえず今の作業に関係がありそうなパラメータシートから見よう」 その気持…

オペミスを誘発する手順書のアンチパターン5選

現場で実際に発生したインシデントを分析すると、事故を誘発する手順書には共通する「悪手」が存在します。

①【対象の曖昧化】代名詞や省略が多い

• NG例：先ほどログインしたサーバーで、設定ファイルを編集する
• リスク：メンテナンス中は複数のターミナル（踏み台、Web-01、Web-02、DB-01など）を同時に開くことが一般的です。「先ほどのサーバー」「該当ホスト」といった代名詞は、別ウィンドウでの誤爆（本番とステージングの取り違えなど）を直接引き起こします。

②【認知負荷過多】1ステップに複数アクションを詰め込む

• NG例：/etc/nginx/nginx.conf を開き、worker_connections を 2048 に変更して構文チェックを行い、サービスを再起動する。
• リスク：1つのステップに「開く」「編集する」「構文チェック」「再起動」の4アクションが含まれています。これでは確認者もどのタイミングでチェックすべきか分からず、構文エラーを見落としたまま再起動をかけてサービス停止を招きます。

③【結果のブラックボックス】確認基準・期待値がない

• NG例：サービスを起動し、正常に起動したことを確認する。
• リスク：「正常」の定義が書かれていません。プロセスが存在すれば正常なのか、ログに特定のエラーが出ていないことが条件なのか、ポートがLISTENしていれば良いのかが作業者の知識レベルに依存してしまいます。

④【コピペ事故】作業中の「手動置換」を要求する

• NG例：# iptables -A INPUT -p tcp -s <許可IP> --dport 22 -j ACCEPT
• リスク：<許可IP> の部分を作業者がテキストエディタ等で手動置換してから貼り付ける運用です。深夜作業では <許可IP> という文字列のまま叩いて構文エラーを起こすか、誤ったIPを入力して即座にSSHセッションを遮断される悲劇を生みます。

⑤【退路の未定義】切り戻し（ロールバック）の基準がない

• NG例：エラーが発生した場合は元に戻すこと。
• リスク：何をもって作業失敗とみなすのか、いつまでに復旧できなければ切り戻すのか（Go/No-Go判断基準）、そして「具体的にどの手順をどの順で実行すれば元に戻るのか」が定義されていません。トラブル発生時、人はパニックになり、アドリブで打った復旧コマンドによって二次災害を引き起こします。

誤操作をゼロにする「手順書の書き方」5大原則

オペミスを構造的に排除するため、記述時に徹底すべき5つの原則を解説します。Linux環境はもちろん、AWS CLIやAzure CLI、Windows（PowerShell）の現場でもすべて共通する原則です。

原則1：1ステップ・1アクション（1行1動作）を徹底する

1つの項番で行う動作は、必ず「1つ」に限定します。人間のチェック機能は、1つの動作ごとにしか正確に働きません。

Before（NG）：

1. 設定ファイルをバックアップし、設定を書き換えてサービスをリロードする。

After（OK）：

1. 設定ファイルのバックアップを取得する。
2. 設定ファイルのパラメータを変更する。
3. 設定ファイルの差分を確認する。
4. 設定ファイルの構文テストを実施する。
5. サービスをリロードする。

このように分解されていれば、作業者も確認者も「今どのステップにいるのか」を完全に見失わずに進められます。

原則2：主客の完全分離（作業場所・プロンプト・対象の明示）

「どこで」「誰が」「何を対象に」実行するのかを、全ステップで機械的に明示します。ターミナルのプロンプト表示まで指定するのが最も確実です。

# NG: どこで叩くのかが文脈依存
systemctl restart nginx

# OK: 対象ホスト、カレントディレクトリ、権限をプロンプトで明示
[ops-user@web-prod-01 ~]$ sudo systemctl restart nginx

複数サーバーを扱う作業では、ステップごとに「作業端末」「踏み台サーバー」「ターゲットサーバー」を明確にラベリングします。

【作業対象】：本番WEBサーバー1号機 (web-prod-01)
【実行ユーザー】：app-admin (sudo権限あり)

[app-admin@web-prod-01 ~]$ pwd
/home/app-admin

原則3：【実行】→【確認】→【期待値】の3点セット化

コマンドを1行叩いたら、必ず「正しく反映されたか」をその場で検証するコマンドと、画面に出るべき「正しい出力結果（期待値）」をセットで記載します。

3.2. Nginxの構文チェック

1. 【実行】構文エラーがないかテストコマンドを実行する。Bash[ops-user@web-prod-01 ~]$ sudo nginx -t
2. 【確認】出力結果を確認する。
3. 【期待値】出力の末尾2行が以下と完全に一致すること。Plaintextnginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful ※上記以外の文字列、または test failed と表示された場合は直ちに作業を中断し、切り戻し手順 4.1 へ進む。

期待値が具体的な文字列として示されていれば、初見の担当者であっても「一致しているか否か」を目視判定するだけで合否が判断できます。

原則4：コピペ安全設計（コピー＆ペーストで完結させる）

人間がキーボードを叩いて文字を入力する回数を減らせば減らすほど、ミスはゼロに近づきます。

• プロンプト記号（$ や #）をコマンド本文に入れない
  コピー時に記号まで巻き込んで構文エラーになるのを防ぐため、コマンドブロックには実行するコマンド実体のみを記載します。
• 変数はスクリプト冒頭で環境変数化する
  手順の途中で <対象IP> などを手作業で打ち替えさせてはいけません。冒頭で環境変数として一度だけ定義させ、以降は変数参照で実行します。

# 手順の冒頭（事前準備フェーズ）で一度だけ定義
export TARGET_IP="192.0.2.10"
export BACKUP_DIR="/var/backup/20261024"

# 以降の手順ではそのままコピペで実行可能にする
sudo rsync -avz /etc/app/ "${BACKUP_DIR}/"
ssh "admin@${TARGET_IP}"

※ PowerShellの場合も同様に $TargetIP = "192.0.2.10" のようにスクリプト冒頭で定義させます。

原則5：危険コマンドに対する「安全弁（フェイルセーフ）」の埋め込み

rm -rf、reboot、DROP TABLE、クラウドのセキュリティグループ変更などの破壊的操作には、二重三重の安全弁を手順の中に組み込みます。

1. 破壊的コマンドの直前に警告アラートを配置する
2. --dry-run（テスト実行）を必須ステップにする
3. バックアップ取得コマンドを実行手順の直前に強制配置する

⚠️ 【重要警告・破壊的操作】

次のコマンドを実行すると、旧世代ログファイルが完全削除されます。カレントディレクトリが /var/log/app/archive であることを指差し確認してください。

1. 【Dry-Run】削除対象ファイルを事前にリストアップして確認する。Bashfind /var/log/app/archive/ -type f -mtime +30 -name "*.log.gz"
2. リストアップされたファイル数が想定（約15ファイル）と一致することを確認する。
3. 【実行】実削除を実行する。Bashfind /var/log/app/archive/ -type f -mtime +30 -name "*.log.gz" -delete

💡【現場コラム】「Excel方眼紙の手順書」とどう向き合うべきか？

クラウド時代・IaC全盛の現在でも、エンタープライズの現場では「顧客指定でExcel手順書を使わざるを得ない」ケースが多々あります。

Excel手順書をゼロにできない環境であっても、本質的なライティング原則は変わりません。

• 1セル・1アクション
  「B列：作業内容」「C列：実行コマンド」「D列：確認コマンド」「E列：期待値」と列を明確に分ける
• スクショの貼りすぎをやめる
  画面全体のエビデンス画像を無秩序に貼るとファイルサイズが肥大化し、スクロールで現在地を見失います。期待値判定に必要な「ダイアログのメッセージ部分」だけをトリミングして配置する
• コマンド用セルは折り返しなし・等幅フォント
  コピペ時に余計な改行やダブルクォーテーションが混入しないよう、セルの書式設定を整える

形式がExcelであれMarkdownであれ、「作業者の認知負荷を極限まで下げる」というゴールは同一です。

そのまま使える標準手順書・作業指示書テンプレート（Markdown）

現場でそのままコピーして使える、標準作業指示書の書式テンプレートです。

# 【作業指示書】◯◯システム 本番環境パッケージアップデート

| 項目 | 内容 |
| :--- | :--- |
| 作業管理番号 | WO-20261024-001 |
| 作業予定日時 | 2026年10月24日（土）02:00 〜 04:00 |
| 主作業者 | 山田（インフラ運用担当） |
| 作業確認者 | 佐藤（インフラリード） |
| 作業目的 | セキュリティパッチ適用に伴うミドルウェア更新 |
| サービス影響 | 作業中、最大5分間の瞬断が1回発生（事前告知済） |

---

## 1. タイムラインとロールバック判定基準

| 時間 | フェーズ | 判定ポイント（Go / No-Go） |
| :--- | :--- | :--- |
| 02:00 | 事前点検・現局確認 | 全ノードの健全性OKで本作業へGo |
| 02:15 | パッチ適用作業 | エラー発生時は03:00までに解消しない場合切り戻し |
| 03:00 | デッドライン（切り戻し判断時刻） | 未完了の場合は無条件でロールバック開始 |
| 03:30 | 事後健全性確認・疎通テスト | サービス正常性を確認し完了報告 |
| 04:00 | メンテナンスウィンドウ終了 | 予備時間終了 |

---

## 2. 作業前の事前準備

### 2.1. ログ記録の開始（作業端末で実行）
script -t 2> ~/logs/work_$(date +%Y%m%d_%H%M%S).timing -a ~/logs/work_$(date +%Y%m%d_%H%M%S).log

### 2.2. 作業変数の定義（作業端末で実行）
export TARGET_HOST="web-prod-01.internal"
export APP_SERVICE="nginx"

---

## 3. 本作業手順

### ステップ1：現状のサービス状態確認
1. 【実行】対象サーバーのサービス稼働状態を確認する。
   ssh ops-user@${TARGET_HOST} "systemctl status ${APP_SERVICE}"
2. 【期待値】出力の中に以下が含まれていること。
   Active: active (running)

### ステップ2：設定ファイルの事前バックアップ取得
1. 【実行】設定ディレクトリの退避アーカイブを作成する。
   ssh ops-user@${TARGET_HOST} "sudo tar -czvf /var/backup/nginx_conf_$(date +%Y%m%d).tar.gz /etc/nginx/"
2. 【確認】バックアップファイルが存在し、サイズが0でないことを確認する。
   ssh ops-user@${TARGET_HOST} "ls -lh /var/backup/nginx_conf_$(date +%Y%m%d).tar.gz"
3. 【期待値】指定したファイルが表示され、サイズが数十KB〜数MB程度存在すること。

---

## 4. 切り戻し（ロールバック）手順

※ 03:00時点で正常完了しなかった場合、または作業続行不能と判断された場合に即座に実行する。

1. 【実行】退避しておいたバックアップから設定を展開・リストアする。
   ssh ops-user@${TARGET_HOST} "sudo tar -xzvf /var/backup/nginx_conf_$(date +%Y%m%d).tar.gz -C /"
2. 【実行】サービスを再起動する。
   ssh ops-user@${TARGET_HOST} "sudo systemctl restart ${APP_SERVICE}"
3. 【確認】サービスが復帰していることを確認する。
   ssh ops-user@${TARGET_HOST} "systemctl is-active ${APP_SERVICE}"
4. 【期待値】標準出力に active とのみ返ること。

---

## 5. 緊急連絡先・エスカレーションフロー

* インフラ責任者：鈴木（090-XXXX-XXXX）
* システムオーナー（情シス）：田中（Teams通話 / 内線: XXXX）
* 連絡基準：
  * 02:45時点でステップ2が完了していない場合 → 責任者へ第一報
  * 切り戻しを実施する場合 → 直ちにシステムオーナーへ架電

手順書を形骸化させないレビューとバージョン管理の運用法

どれほど優れたフォーマットを策定しても、メンテナンスされない手順書はすぐに陳腐化して事故の引き金になります。チームとして品質を維持するための3つの運用ルールを導入しましょう。

①「書いた本人」が検証作業をしてはいけない

手順書を作成した本人は、無意識のうちに自分の「暗黙知」で手順の抜け漏れを脳内補完してしまいます。そのため、作成者自身によるテストでは記述の致命的な穴に気づけません。

ステージング環境や検証環境でのリハーサルは、「手順を作成した本人以外のメンバー（新任や初見のメンバー）」に担当させてください。

作業中に少しでも「これってどういう意味ですか？」「パスが見当たりません」と質問が出た場合、それは作業者のスキル不足ではなく手順書のバグです。その場ですぐに手順書の記述を修正します。

② 障害振り返りに「手順書レビュー」を必須化する

障害やヒヤリハットが起きた際、「作業者が慎重さを欠いていた」で終わらせてはいけません。

• 手順書のどの文言が誤認を生んだか？
• 期待値の記述が曖昧ではなかったか？
• コピペしにくいレイアウトになっていなかったか？

これらを事後検証の必須項目として組み込み、手順書そのものを継続的にアップデートするカルチャーを醸成します。

③「野良手順書」を撲滅し、Gitや社内Wikiで一元管理する

個人のデスクトップに放置されたExcelや、更新日が数年前で止まっている手順書は現場の地雷です。

• 手順書はMarkdown等のプレーンテキストで記述する
• 社内Wiki（Confluence、Notion等）またはGitリポジトリで一元管理する
• 「どのコミットID／リビジョンの手順書を使って作業したか」を作業記録に残す

手順書をコードと同様にバージョン管理することで、「古い手順書を参照して事故が起きた」という悲劇を完全に防ぐことができます。

まとめ：迷いのない手順書は、作業者を守る最大の防護壁である

システム運用において、作業者を最も苦しめるのは「失敗したらどうしよう」という強いプレッシャーです。そして、行間や解釈の余地を残した曖昧な手順書は、そのプレッシャーを何倍にも増幅させます。

ミスが起きたとき、「慎重さが足りない」「もっと集中しろ」と作業者個人を責めても根本解決にはなりません。オペミスを防ぐ本質は、人の注意力に依存しない記述設計にあります。

「行間をなくし、1動作1行で書き、期待値を添え、コピペで安全に動くようにする」

このライティング原則を徹底することは、システムの稼働率を担保するだけでなく、深夜やトラブル対応時に最前線でキーボードを叩く仲間を守ることに他なりません。

作業者の注意力という不確実なリソースに依存する運用から脱却し、手順書のライティングという「仕組み」で安全を担保する体制を作っていきましょう。