夜のオフィスで障害対応をしながら、モニターの横に開いたメモ用のウィンドウに一行ずつ記録を書き足している保守運用の担当者
ドキュメント・引き継ぎ約14分

障害対応中のメモの取り方｜あとで報告に使える時系列の記録術

深夜のアラートから2時間。ようやくエラーが止まり、グラフも平常に戻りました。ほっとして、報告書のテンプレートを開きます。

「検知は……2時10分だったかな。再起動したのは何時だっけ。その前にキャッシュを消したんだっけ、消してないんだっけ」

ターミナルの履歴をさかのぼり、チャットを読み返し、監視のグラフとにらめっこして、時刻をつなぎ合わせる。対応そのものより、思い出す作業のほうが疲れる夜があります。

でも、覚えていないのは当たり前です。障害対応の最中、人の頭は「いま何が起きているか」でいっぱいになります。記録まで気が回らないのは、ちゃんと目の前の障害に集中していた証拠です。

だから、覚えておこうとがんばるのではなく、対応しながら、片手間で残せる形を先に用意しておく。この記事では、そのやり方を一緒に整えていきます。

結論：やることは4つです。①対応を始めた瞬間に、メモ用のファイルを1つ開く（場所と名前を決めておく）、②「時刻＋1行」で書き足していく（清書しない。箇条書きで十分）、③「見たこと」「やったこと」「考えたこと」を書き分ける（あとで報告と振り返りに分けやすくなる）、④コマンドの記録は仕組みに任せる（script と履歴の時刻表示）。上手に書く必要はありません。時刻が残っていれば、報告書はあとから組み立てられます。

なお、ここで紹介するコマンドはLinuxのbashを前提にしています。サーバーのOSやシェル、会社のルールによって使える道具は変わるので、自分の現場に置き換えながら読んでみてください。

何が起きているのか：記憶は「対応の順番」を残してくれない

障害対応が終わったあと、困るのはたいていこの3つです。

情報がないわけではありません。ターミナルの画面、チャット、監視のグラフ、ログ。あちこちに散らばっているだけです。散らばった情報を、あとからつなぎ直すのが大変なのです。

だから、対応中に1か所へ「時刻と1行」を落としておく。それだけで、あとの作業が大きく変わります。

メモの型：「見たこと・やったこと・考えたこと」を書き分ける

障害対応中のメモを、画面で確認した事実の「見たこと」、打ったコマンドや操作の「やったこと」、その時点の判断や推測の「考えたこと」の3種類に書き分ける考え方を示した図
1行ごとに「見た・やった・考えた」を分けておくと、報告書にも振り返りにもそのまま使える

メモは、1行に「時刻」と「何があったか」を書くだけです。そのうえで、行の頭に印をつけて3種類に書き分けます。

書き分ける理由は、あとで使う場所が違うからです。「見たこと」と「やったこと」は報告書の時系列にそのまま入り、「考えたこと」は振り返り（ポストモーテム）の材料になります。とくに「考えたこと」は、推測が外れたときほど価値があります。「なぜそこを疑ったのか」が残っていれば、次の自分が同じ回り道をしなくて済みます。

印は、打ちやすいもので構いません。この記事では「見」「打」「考」の1文字にしていますが、[見] のような括弧つきでも、記号でも大丈夫です。続けられる形がいちばんです。

ステップ1：対応を始めた瞬間に、メモ用ファイルを1つ開く

アラートを見て「これは障害だ」と思ったら、調査より先に、まずメモを1つ開きます。ここで迷わないように、置き場所と名前は平常時に決めておきます。

置き場所：~/incident/（または共有フォルダの「障害メモ」）
名前　　：YYYY-MM-DD_対象_症状.md
例　　　：2026-09-27_web01_502多発.md

中身の最初は、このテンプレートをコピーするだけにしておくと楽です。

# 障害メモ：（対象・症状をひとこと）
- 検知：（時刻）／ きっかけ：（監視アラート・問い合わせ など）
- 影響：（誰が・何をできないか。分かる範囲で）
- 状態：対応中

## 時系列（見＝見たこと／打＝やったこと／考＝考えたこと）
- 02:10 見 監視アラート「HTTP 502」 web01
-

## 戻すもの・あとでやること
-

## まだ分かっていないこと
-

いちばん下の2つの欄が、あとで効いてきます。「戻すもの」は、応急処置で一時的に変えた設定や止めたバッチ。「まだ分かっていないこと」は、中間報告で「調査中の点」としてそのまま使えます。

「ファイルを開く余裕なんてない」という夜もあると思います。そのときは、チャットの自分宛てのメモや、紙1枚でも構いません。大事なのは、時刻と1行が、どこか1か所にたまっていくことです。

ステップ2：「時刻＋1行」で書き足していく

書き方のルールは、ひとつだけです。きれいに書かない。

- 02:10 見 監視アラート「HTTP 502」 web01
- 02:12 見 トップページ502。管理画面も502。静的ファイルは表示される
- 02:14 考 Webサーバーは生きてる。裏側（php-fpmかDB）っぽい
- 02:15 打 sudo tail -n 100 /var/log/nginx/error.log
- 02:16 見 upstream timed out が大量。02:05ごろから
- 02:18 打 関係者チャットに第一報
- 02:20 見 php-fpmのプロセス数が上限に張りついている
- 02:21 考 重い処理で詰まってる？ DBの接続数は平常なのでDB障害ではなさそう
- 02:25 見 スロークエリログに02:03開始の集計処理
- 02:27 打 集計バッチを停止（←あとで戻す）
- 02:31 見 502が止まった。応答時間も平常に戻った
- 02:40 打 復旧の連絡。原因調査は明日の日中に

これで十分です。文章になっていなくても、主語がなくても、報告書を書くときの材料としてはもう揃っています。

時刻は、パソコンの時計を見て手で書くのがいちばん確実です。コマンドを打つ手が忙しいときは、ターミナルで date +%H:%M を打って、出た時刻をそのまま使っても構いません。

書くタイミングの目安は、「何かを打つ前」と「何かを見つけたとき」です。とくに再起動・設定変更・バッチ停止のような戻せない（戻すのに手間がかかる）操作の前は、必ず1行。あとから「どれが効いたのか」を判断するときの、いちばん大事な手がかりになります。

ステップ3：コマンドの記録は、仕組みに任せる

打ったコマンドまで全部手で書き写すのは、さすがに無理があります。ここは道具に任せましょう。

3-1. script でターミナルの画面をまるごと残す

対応を始めるときに、最初にこれを打っておくと、以降のターミナルの入出力がファイルに記録されます。

mkdir -p ~/incident
script -a -f ~/incident/2026-09-27_web01.log
# ……ここから普段どおり調査・対応する……
exit    # 記録を終える

-a は追記、-f はこまめにファイルへ書き出すオプションです（util-linux の script の場合）。対応のあとで「あのときのエラーメッセージ、正確には何だったか」を確かめたくなったら、このファイルを見れば残っています。

1つだけ気をつけたいのが、画面に表示されたものは全部記録されることです。設定ファイルを cat で表示すれば、そこに書かれたパスワードやAPIキーもログに入ります。記録ファイルは自分だけが読める権限（chmod 600）にして、共有する前には中身を確かめてください。秘密の情報の扱いはパスワードとAPIキーの平文放置をなくすでも整理しています。

3-2. シェルの履歴に時刻をつけておく

script を打ち忘れる夜もあります。その保険として、bashの履歴に時刻がつくようにしておきます。~/.bashrc に1行足すだけです。

# ~/.bashrc に追記
export HISTTIMEFORMAT='%F %T '

こうしておくと、history を打ったときに、各コマンドの実行時刻が表示されます。

history | tail -n 30
#  512  2026-09-27 02:15:03 sudo tail -n 100 /var/log/nginx/error.log
#  513  2026-09-27 02:27:41 sudo systemctl stop report-batch.timer

ただし、これは平常時に設定しておくものです。複数のターミナルを開いていると履歴が上書きされることもあるので、あくまで「メモの抜けを埋める保険」と考えてください。主役は、手で書く「時刻＋1行」のメモです。

ステップ4：節目で読み返して、報告に使う

メモは、書きっぱなしにせず、報告の節目で一度読み返します。

対応が終わったら、メモの「状態」を「復旧」に変えて、そのまま保存しておきます。清書は翌日で大丈夫です。 深夜のうちに無理に報告書まで仕上げようとしなくていい。時刻と1行が残っていれば、明日の自分がちゃんと組み立てられます。

具体例：メモがあった夜と、なかった夜

同じ「502エラーが30分続いた」障害でも、翌日の報告はこう変わります。

違いは、対応の腕前ではありません。対応中に1行ずつ書いていたかどうかだけです。

影響：メモを取るようになると、何が変わるか

明日やること

次の障害に備えて、平常時のうちにこれだけ準備しておきましょう。

  1. メモの置き場所を決める。~/incident/ でも共有フォルダでも。名前は「日付_対象_症状」。
  2. テンプレートを1つ保存する。この記事のものをコピーして、自分の現場に合わせて直すだけで十分です。
  3. ~/.bashrc に HISTTIMEFORMAT を足す。よく入るサーバーから順に。
  4. script の打ち方を、runbookの1行目に書いておく。対応の最初の一手として、手が勝手に動くように。
  5. 次の小さなトラブルで、一度試してみる。大きな障害の前に、軽い問い合わせ対応で「時刻＋1行」を練習しておくと、本番でも自然に書けます。

今日やるのは、1の「置き場所を決める」だけでも十分です。開く場所が決まっているだけで、次の夜の最初の一手が迷わなくなります。

障害対応メモのチェックリスト

全部できなくても大丈夫です。「時刻を書いた」の1つだけでも、翌日の報告はずいぶん楽になります。

よければ、こちらも

翌朝の明るいオフィスで、前夜の障害メモを見ながら落ち着いて報告書をまとめ、ほっとした表情を浮かべている保守運用の担当者

障害対応のメモは、誰かに見せるための文章ではありません。慌ただしい夜のあとに、明日の自分が困らないように置いておく、小さな置き手紙のようなものです。

うまく書けなくても、途中で途切れても大丈夫です。時刻が3つ残っているだけで、何も残っていない夜とはまるで違います。あの夜、あなたが一人でちゃんと向き合っていたことも、その数行がきちんと証明してくれます。

まずは平常時のうちに、メモの置き場所を1つ決めるところから始めてみてください。

ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。

関連用語