この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
障害対応の技術力は十分でも、第一報の書き方ひとつで「冷静なエンジニア」に見えるか「慌てているだけ」に見えるかが決まります。
この記事では、20年以上Linuxサーバーを運用してきた経験から、障害発生時の第一報を「現場で信頼されるレベル」に引き上げるための型と、avoid すべき NG パターンを解説します。
この記事のポイント
・第一報の質はエンジニアの評価を大きく左右する
・「事象・影響・初動・次の連絡」の4要素で第一報を組み立てる
・dmesg・journalctl・uptimeで初動の事実を素早く集める手順
・3,100名を指導してきた経験から見たNGパターンと改善例
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
なぜ第一報の書き方が「技術力」と同じくらい評価されるのか
現場でよく見かけるのが、技術力は確かなのに障害発生時の連絡が下手なエンジニアです。「サーバーが落ちました」「メールが届きません」「DBに繋がらないようです」——こういった一行だけのメッセージを受け取った側は、必ず追加の質問を返さなければなりません。
私がSE時代に経験した話をひとつしましょう。
ある夜中の障害対応で、若手メンバーから「Webサーバーが応答しないです」とだけメッセージが届きました。私はその時点で何も判断できません。「全停止なのか一部のページなのか」「ユーザー影響は出ているのか」「いつから起きているのか」「本人は今何をしているのか」——確認のために5往復ほど質問することになり、初動の30分を会話だけで失いました。
障害対応で本当に重要なのは「復旧するまでの時間」です。第一報の質が低いと、その後のやり取りで時間を消費してしまう。これは技術力以前の問題で、現場の信頼を直接的に損なう要因になります。
受講生からよく聞かれる質問が、「障害対応中に冷静でいるコツは何ですか」というものです。私の答えはいつも同じで、「冷静に見える書き方を先に覚えること」です。書き方の型があると、混乱した頭でも事実を整理できる。型は心の余裕を作ります。
第一報を組み立てる4要素｜「事象・影響・初動・次の連絡」
私が現場で実践し、セミナーの受講生にも伝えている第一報の型は、たった4要素で構成されます。1. 事象（何が起きているか）
事実だけを書きます。「思う」「ようです」「かもしれません」といった推測表現は使いません。事象は観測した結果そのもの、もしくは具体的な現象を記載します。NG: 「Webサーバーが落ちたかもしれません」
OK: 「Webサーバー(web01)のHTTP応答が10:35頃から無応答。pingは通る。HTTP 500ではなくタイムアウト。」
2. 影響（誰がどう困っているか）
障害が業務にどう影響しているかを書きます。技術用語ではなく業務用語で表現するのが鉄則です。NG: 「Apacheがダウンしています」
OK: 「お客様の問い合わせフォーム送信が10時35分から不可。メルマガ会員ページのログインも不可。」
3. 初動（自分が今何をしているか）
「自分が手を動かしている」と相手に明確に伝えます。沈黙は「何もしていない」と受け取られます。NG: 「対応中です」
OK: 「現在 dmesg と /var/log/messages を確認中。OOM Killer の発動有無を5分以内に判定する。」
4. 次の連絡(いつ続報を出すか)
これが最も重要で、最も忘れられがちな要素です。「いつ次の連絡をするか」を明示するだけで、上司や顧客の不安は大幅に減ります。NG: （次の連絡時刻の言及なし）
OK: 「11:00 に進捗を再連絡します。それまでに復旧した場合は即時報告します。」
第一報を5分で書くための事実収集コマンド
第一報を素早く書くには、事実を素早く集める必要があります。私が必ず最初に叩く5つのコマンドを紹介します。# 1. サーバーがいつから動いているか確認（再起動の有無） uptime # 出力例: 11:42:18 up 14 min, 2 users, load average: 8.42, 6.18, 3.05 # ↑ 「14 min」で予期せぬ再起動の可能性 # 2. 直近のシステムメッセージを確認(OOMやパニック検出) dmesg -T | tail -50 # 出力例: [Sun May 4 10:34:21 2026] Out of memory: Killed process 12345 (httpd) # 3. systemd管理下のサービス障害を一覧で確認 systemctl --failed # 出力例: # UNIT LOAD ACTIVE SUB DESCRIPTION # httpd.service loaded failed failed The Apache HTTP Server # 4. ディスク逼迫の確認(障害原因の上位) df -h # 出力例: /dev/sda1 50G 49G 500M 99% / # 5. プロセス・CPU負荷の即時確認 top -b -n 1 | head -20
20年以上サーバーを運用してきた経験から言うと、初動で焦って解決策を探すより、まず事実を5分で集めて第一報を出す方が、結果的に復旧は速くなります。なぜなら、上司や同僚が並行して別の角度から調べてくれるからです。
「冷静に見える」第一報のテンプレート例
実際に使えるテンプレートを示します。Slack や メール どちらでも使えます。# 第一報テンプレート(コピーして使える) 【障害第一報】Webサーバー無応答(web01) ■事象 10:35頃から web01.example.com への HTTP応答が無応答。 ping は通る。SSH ログイン可。Apache プロセスは稼働中だが応答せず。 ■影響 お客様の問い合わせフォーム(/contact)が送信不可。 メルマガ会員ページ(/member)のログインも不可。 社内向け管理画面(/admin)は別サーバーのため影響なし。 ■初動 dmesg / journalctl / df -h を確認中。 OOM Killer ログを発見(httpd プロセス11時前にKill)、メモリ起因と仮判定。 Apache の再起動を11:50に実施予定。 ■次の連絡 11:00 に進捗を再連絡。それまでに復旧時は即時報告。 担当: 宮崎
私のセミナーで3,100名以上を指導してきた中で、「障害対応の度胸がついた」と言われる受講生は、ほぼ全員このテンプレートを自分なりにカスタマイズして手元に置いています。
NGパターン4つと改善例
私が現場や受講生のレポートでよく見かける NG パターンを4つ紹介します。| NGパターン | なぜダメか | 改善例 |
|---|---|---|
| 「サーバーが落ちました」だけ | 事象も影響も初動も不明で追加質問が必須 | 4要素を1メッセージで送る |
| 「対応中です」だけの定期連絡 | 進捗不明で受け手が判断できない | 「何を確認したか・次の判断ポイント」を添える |
| 推測と事実の混在 | 受け手が誤った判断をする原因になる | 「事実」「仮説」を明示的に分けて書く |
| 長文すぎる経緯説明 | 重要情報が埋もれて読まれない | 結論先出し・詳細は後段に分離 |
特に3つ目の「推測と事実の混在」は危険です。「DBが原因かもしれません」と書くと、受け手は DB チームを呼んでしまうかもしれない。仮説を書くなら「仮説:DB起因の可能性。確認のため slow query log を取得中」のように、仮説であることを明示しましょう。
第一報を改善するための練習法
第一報の書き方は、本番で慌てて学ぶものではありません。日常的に練習しておくことで、本番でも自然に書けるようになります。私が受講生に勧めている練習法は3つです。
・毎日の作業ログを「事象・影響・対応」の型で書く: ちょっとした設定変更や検証作業も、業務メールと同じ型で記録する習慣をつけると、本番でも自然に出せます
・過去の障害ポストモーテムを書き直す: 自分が関わった過去の障害を、今ならどう第一報するか書き直してみる練習
・テンプレートを手元に置く: メモアプリや Obsidian、社内 Wiki など、いつでも参照できる場所にテンプレートを保管する
書き方は技術と同じで、繰り返すほど洗練されていきます。最初から完璧を目指さず、まず4要素を埋める習慣から始めるのが現実的です。
まとめ
障害発生時の第一報は、エンジニアの技術力と同じくらい現場の評価を左右します。| やること | 目的 |
|---|---|
| 第一報を「事象・影響・初動・次の連絡」の4要素で書く | 受け手が追加質問なしで状況を把握できる |
| uptime / dmesg / systemctl --failed / df -h / top で事実を5分で集める | 推測ではなく事実をベースに第一報を出す |
| テンプレートを手元に置いて空欄を埋める | 頭が回らない深夜の対応でも安定した第一報を出せる |
| 事実と仮説を明示的に分けて書く | 受け手が誤った判断をする事故を防ぐ |
| 日常的な作業ログから型で書く練習をする | 本番で慌てずに型通り書けるようになる |
障害の度胸とは「動じないこと」ではなく、「動じても型通り書けること」です。20年以上の現場で私が得た実感は、技術力は経験で身につくが、第一報の質は意識的に型を持つかどうかで決まる、ということです。
この考え方をより体系的に学びたい方は、以下の記事も参考にしてみてください。
・深夜の障害対応で学んだこと——Linuxエンジニアが「修羅場」から身につける冷静さの作り方
・Linuxのトラブル切り分けは「仮説と検証」が9割｜20年以上の現場経験から学んだ原因特定の思考法
障害対応の「型」を体系的に身につけたいあなたへ
障害対応の第一報を上手く書くには、Linuxサーバーの基本構造とログの読み方を体系的に理解していることが前提です。
「ログのどこを確認すればいいか分からない」「サーバーの全体像が掴めない」という方もいるかもしれません。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として15年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 次のページへ：Linuxのログを読む習慣が身につくと現場の見え方が変わる理由｜20年以上の運用経験から伝えたいこと
- 前のページへ：Linuxの設定変更前に「なぜ今こうなっているか」を調べる習慣｜現役講師が語る根拠なき変更が招く障害の実態
- この記事の属するカテゴリ：Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます