障害対応が長引き、原因がまだ分からないまま次の報告時刻が近づいてきて、何を書くか一瞬考えている一人運用の保守担当者
障害対応・運用監視約18分

障害が長引くときの中間報告｜復旧見込みが立たないときの伝え方

第一報は出せた。原因の調査も始めた。 ——それから1時間。まだ、何も分かっていません。

そして、自分で書いた「◯時ごろ、次のご連絡をします」の時刻が近づいてきます。

進展がないのに、何を書けばいいんでしょうか。

「調査中です」だけ送るのは、さぼっているように見えないだろうか。かといって、まだ分かっていない原因を、それらしく書くわけにもいかない。ログを追う手を止めて、この文面のことをずっと考えている——一人で保守運用をしていると、この時間がいちばん消耗します。

先に言っておきたいことがあります。進展がない時間があるのは、あなたの調査が遅いからではありません。 障害調査は、切り分けた分だけ「違ったもの」が積み上がっていく仕事です。外から見て進んでいないように見える時間にも、確実に候補は減っています。

この記事では、復旧見込みが立たないときの中間報告を「何を書くか・どの間隔で出すか」に絞って整理します。

結論：中間報告に復旧時刻は要りません。入れるのは「①いま分かっていること ②除外できたこと ③今やっていること ④迂回策（あれば） ⑤次の連絡時刻」の5つ。

いちばんのコツは②の「除外できたこと」を書くことです。「サーバーの負荷とネットワークは原因ではないと確認できました」——これは立派な進展で、相手にもそう伝わります。

そして、約束するのは復旧の時刻ではなく、次の報告の時刻だけにします。守れる約束だけをして、それを必ず守る。これが長期化した障害でいちばん効きます。

報告の相手・頻度・様式は、社内ルールや契約（SLA・報告義務）で決まっていることがあります。ここに書く型は出発点として、自分の現場の決まりに合わせて足し引きしてください。

何が起きているか：相手が不安なのは「沈黙」のほう

報告をためらう気持ちの正体は、たいてい「中身がないものを送りたくない」です。真面目な人ほどそう考えます。

でも、報告を待っている側の景色は、ずいぶん違います。

相手の手元にあるのは、あなたが出した第一報だけです。そこから連絡が途絶えると、相手には次のどれなのかがまったく区別できません。

この区別がつかない状態が続くと、相手は最悪のケースを想像します。そして、想像に耐えられなくなったところで「どうなってますか」の連絡が飛んできます。いちばん集中したい時間に、いちばん答えにくい形で。

中間報告は、この想像を止めるためのものです。 「難航しているが、人は動いている」——これが伝わっていれば、相手は待てます。中身が薄くても構いません。沈黙よりずっといい、というだけの話です。

もうひとつ、実務的な効果もあります。約束の時刻に報告が届いていると、社内の窓口や営業の方が、お客様に「◯時時点でこういう状況です」と一次対応できます。あなたの一報が、そのまま何人分かの対応になっているわけです。

中間報告に入れる5つの要素

第一報が「気づいています・動いています」を伝えるものだったのに対して、中間報告が伝えるのは「どこまで来たか」です。

必要なのは、次の5つだけです。

  1. いま分かっていること：確認できた事実。「特定のページだけで発生」「◯時◯分から継続」など。
  2. 除外できたこと：調べて「原因ではなかった」と分かったもの。ここがいちばん大事です（次の節で詳しく書きます）。
  3. 今やっていること：現在の作業。「アプリケーションログの解析」「ベンダーへの問い合わせ」など。
  4. 迂回策（ワークアラウンド）：あれば。無ければ「現時点ではありません」と書く。
  5. 次の連絡時刻：必ず入れる。ここだけは毎回、具体的な時刻で。

逆に、入れなくていいものもはっきりさせておきます。

謝罪は第一報と同じく一言までです。回を重ねるごとに謝罪が長くなっていくと、事実が読みにくくなります。淡々と、事実と次の予定を。

「除外できたこと」を書くと、進展ゼロが進展になる

ここが、この記事でいちばんお伝えしたいところです。

障害調査で「進展がない」と感じている時間、実際に起きているのは候補を消す作業です。

原因は分かっていません。でも、4つの可能性が消えています。これは間違いなく前進です。

それなのに報告では「調査中です」の5文字に圧縮してしまう。もったいないうえに、相手には「1時間、何もしていない」ように映ります。

だから、そのまま書きます。

【中間報告 15:00時点】
分かっていること：
・症状は問い合わせフォームの送信時のみ。他の画面は正常です
・14:20ごろから継続しています

確認して、原因ではないと分かったもの：
・サーバーの負荷（CPU・メモリ）は平常の範囲でした
・ネットワークの疎通に問題はありませんでした
・本日のリリース内容は、該当機能に触れていませんでした

現在：メール送信まわりのログを時系列で確認しています
迂回策：現時点ではありません。お電話での受付をお願いしています
次のご連絡：16:00ごろ

同じ1時間の報告でも、受け取る印象がまるで違います。しかも、書いてあることは全部事実で、盛っていません。

これは、書く側にも効きます。除外できたものを毎回書き出していくと、自分の調査の地図が更新されていきます。「あと残っているのはこの範囲だ」が見えると、焦りが少し減ります。

除外した項目をどこに書き留めておくかは、問い合わせ対応を調査ログとして残して資産にする方法や障害対応の履歴を残して属人化を防ぐと同じ話です。中間報告のためのメモが、そのまま記録になります。

復旧見込みは、状況を3段階に分けて言い分ける

障害対応の進み具合を、まだ範囲が絞れていない段階・原因の場所が絞れた段階・直している段階の3つに分けて表した図
復旧の見込みを言えるのは右の段階だけ。左と中央では「次の連絡時刻」だけを約束する

「で、いつ直るの？」——これがいちばん答えにくい質問です。

答えられないのに、その場の空気で「あと1時間くらいでしょうか」と言ってしまう。そして1時間後、直っていない。このとき失われるのは復旧時間ではなく、次からの言葉の信用です。以降、何を言っても「またそう言ってる」と受け取られてしまいます。

だから、状況を3つに分けて、言えるときだけ言うと決めておきます。

① 調査中（原因の範囲がまだ絞れていない）

復旧見込みは言いません。

代わりに伝えるのは、除外できたものと、次の連絡時刻です。

「現時点では原因を特定できておりません。サーバー・ネットワーク側は問題ないことを確認済みで、現在はアプリケーション側のログを確認しています。復旧の見込み時刻は、恐れ入りますがまだ申し上げられません。次回16:00ごろに、状況をあらためてご連絡します。」

「まだ申し上げられません」は、逃げではありません。分からないことを分からないと言えるのは、信頼できる報告の条件です。

② 原因を特定（場所は分かった。直し方はこれから）

ここでも、まだ復旧時刻は約束しません。

原因が分かっても、直すのに何が必要かはまだ見えていないからです。データの修正が要るのか、ベンダーの対応待ちなのか、設定を戻せば済むのか。ここで楽観的な時刻を言うのが、いちばんよくある失敗です。

「原因は、◯◯の処理でエラーが発生していることまで特定できました。現在、対処方法を検討しています。復旧の手順が固まり次第、あらためて見込みをお伝えします。次回16:30ごろにご連絡します。」

言えるのは「特定できた」という進展と、「次に何が分かるか」です。それで十分に大きな前進が伝わります。

③ 復旧作業（直し方が決まり、作業に入った）

ここで初めて、時刻の話ができます。ただし、幅を持たせます。

「対処方法が決まり、17:00から修正作業に入ります。作業時間は30分程度を見込んでおり、17:30ごろの復旧を目指しています。作業後の確認を含め、18:00をめどに結果をご連絡します。」

「17:30に直ります」と言い切らないのがポイントです。作業の見込みと、結果を報告する時刻を分けて伝えます。作業が延びても、報告の約束は守れます。

そして、本番に手を入れる作業そのものは、急いでいるときほど段取りを飛ばしがちです。ここは本番反映前のチェックリストと作業前バックアップの取り方や切り戻し（ロールバック）の手順を一度見てから入るほうが、結果的に早く終わります。

報告の間隔は、影響の大きさで決めておく

報告のたびに「次はいつにしよう」と考えるのは、地味に疲れます。平時に目安を決めておくと、その場で悩まなくて済みます。

一人運用での、現実的な目安です。

影響の大きさ報告の間隔の目安
サービス全体が停止している30分ごと
一部の機能・一部の利用者に影響1時間ごと
動作は継続、軽微な不具合2〜3時間ごと、または状況が変わったとき
夜間で、翌営業日まで影響が出ない翌朝の始業前に1本

ただし、この間隔は上限ではなく下限として使います。状況が変わったら、約束の時刻を待たずに出して構いません。「原因が特定できました」の一報は、早いほど価値があります。

そして、いちばん大事なルールを1つだけ。

約束した時刻には、中身が無くても必ず何か出す。

【中間報告 16:00時点】
16:00時点で、状況に大きな変化はありません。
引き続き、メール送信まわりのログを確認しています。
次のご連絡：17:00ごろ

これで十分です。3行でいい。「約束した時刻に届く」こと自体が情報で、それが続いているうちは、相手はあなたの報告を信じてくれます。

報告が負担になってきたら、間隔を延ばす交渉をしていい

30分ごとの報告を4時間続けると、報告を書く時間だけで調査が細切れになります。これは本末転倒です。

そういうときは、正直に相談します。

「調査に集中したいため、次回以降は1時間ごとのご連絡に変更してもよろしいでしょうか。状況が変わり次第、時刻を待たずにご連絡します。」

たいていは通ります。相手も、報告のために復旧が遅れることは望んでいません。黙って報告を飛ばすのではなく、間隔を変える相談をする——これが長期戦のやり方です。

長期化してきたら、報告に「体制」を足す

障害が数時間を超えてくると、報告の中身に1つ足すものがあります。誰が、いつまで対応できるかです。

一人運用だと、ここを言い出しにくいですよね。「自分がやるしかない」と思ってしまう。でも、深夜3時の判断力で本番のデータを触るのは、障害そのものより危険なことがあります。

だから、限界が来る前に、報告の中で先に伝えておきます。

「本日は22:00を目安に、いったん復旧作業を中断させていただきたく考えております。恒久対応は明日9:00から再開します。それまでの間、◯◯の機能は停止したままとなりますが、△△での代替をお願いできればと思います。」

これは弱音ではなく、リスク管理の申告です。判断者にとっても、「担当者が朝まで持つ前提」で計画を立てているほうがよほど危ない。早めに言うほど、応援を頼む・ベンダーに投げる・翌朝に回すといった選択肢が残ります。

このあたりの線引きは、一人運用でも回すオンコールとエスカレーションの決めごとで先に決めておくと、当日の自分が判断せずに済みます。疲れているときに判断しないのが、いちばんの安全策です。

あわせて、復旧を急ぐか、いったん止めて安全側に倒すかの考え方は暫定対応と恒久対応を分けるにまとめています。長期化したときは、完全復旧より先に「暫定でも使える状態」に持っていくほうが、現場は助かることが多いです。利用者向けに状況を出すならメンテナンス告知画面の出し方も一緒にどうぞ。

コピーして使える中間報告テンプレート

そのまま埋めれば使える形にしておきます。

社内チャット向け（速報・箇条書き）

【障害 中間報告】◯◯システム／◯時◯分時点
状況：継続中（復旧しておりません）

分かっていること：
・
・

原因ではないと確認できたもの：
・
・

現在の作業：

迂回策：（無ければ「現時点ではありません」）

復旧見込み：（言えない場合は「未定」と書く）
次の連絡：◯時ごろ
対応：（自分の名前）

社外・関係者向けメール（原因が分かっていない段階）

件名：【障害のご連絡・第2報】◯◯システムについて

お世話になっております。◯◯です。
◯時◯分時点の状況をご連絡いたします。

・現在の状況：復旧しておりません（◯時◯分より継続）
・影響範囲：◯◯
・確認済みの内容：
　サーバーおよびネットワークについては問題がないことを確認しております。
　現在、アプリケーション側の動作を確認しております。
・復旧の見込み：現時点では申し上げられる段階にございません
・次回のご連絡：◯時ごろ

ご不便をおかけしております。
状況に変化があり次第、時刻を待たずにご連絡いたします。

（署名）

進展がないときの短い版

【障害 中間報告】◯時◯分時点
状況に大きな変化はありません。引き続き◯◯を確認しています。
次の連絡：◯時ごろ

翌日に持ち越すときの版

【障害 中間報告】◯時◯分時点／本日の対応終了のご連絡

本日の調査では復旧に至りませんでした。
・現在判明していること：◯◯
・本日確認し、除外できたもの：◯◯／◯◯
・暫定の対応：◯◯（例：該当機能を一時停止し、電話受付に切り替え）
・明日の予定：◯時より調査を再開します
・次のご連絡：明日◯時ごろ

夜間に状況が変わった場合は、あらためてご連絡いたします。

具体例：原因が分からないまま5時間が過ぎた日

型だけだと分かりにくいので、1日の流れとして並べてみます。

状況：社内の受発注システムで、特定の取引先向けの帳票だけが出力できない。第一報を14:30に発信。

ここで注目したいのは、16:30の第3報です。

進展ゼロ。書くことがない。いちばん飛ばしたくなる回です。でも、これを飛ばしていたら、15:30から17:30まで2時間の沈黙になっていました。その間に「どうなってる」の電話が来て、17:30の発見はもっと遅れていたはずです。

3行の報告が、2時間分の集中を守っています。中身の薄い報告ほど、実は仕事をしています。

もうひとつ。17:30に「原因を特定」と書けたのは、15:30と16:30で除外したものを積み上げていたからです。除外の記録は、そのまま調査の進み方になります。

影響：中間報告の型があると、何が変わるか

最後の点は、思っている以上に効きます。障害対応の翌日、記憶だけで報告書を書くのはかなりつらい作業です。中間報告を毎回出していれば、その日のうちに時系列の記録ができあがっています。

一方で、正直に書いておくと、中間報告は復旧を早くはしません。書く時間の分だけ、調査は止まります。それでも出す価値があるのは、沈黙が生む催促と不安のほうが、結果的に大きく時間を奪うからです。

明日やること：テンプレを1つ、runbookに貼る

障害が起きていない今日のうちに、5分でできることです。

  1. 上の「進展がないときの短い版」をコピーして、すぐ開ける場所に貼る（1分）
  2. 自分の現場の報告間隔の目安を1行で決める（例：「全停止＝30分、一部＝1時間」）（2分）
  3. 障害対応runbookを作っているなら、第一報テンプレの隣に中間報告の枠を足す（2分）
  4. 「復旧見込みは、作業に入るまで言わない」の一行を、目立つところに書いておく

これだけです。実際に使うのは何か月か先かもしれませんが、そのときの自分は、たぶん頭が真っ白になっています。未来の自分に向けた申し送りだと思って置いておきましょう。

中間報告 チェックリスト

自分の中間報告が「長期戦に耐えるか」を確かめる項目です。

まず、これだけあれば回ります。最低ラインの3つです。

ここから先は、あると報告の質が上がる項目です。

中身について

間隔について

長期化に備えて

全部そろっていなくて大丈夫です。最低ラインの3つ、とくに「約束した時刻には必ず何か出す」さえ守れていれば、報告としては十分に機能します。

最後に

進展のない報告を出すのをためらってしまうのは、あなたが「中身のあることを届けたい」と思っているからです。相手の時間を無駄にしたくない、という誠実さから来ています。

でも、待っている人が受け取りたいのは、答えではありません。 「まだ動いている人がいる」という事実です。

3行の報告に、それは十分に入っています。だから、書くことがない日の報告こそ、いちばん届いています。

原因が見つからない時間は、長く感じます。でも、その間にあなたは確実に候補を減らしています。まだ分からない、は「何もしていない」ではありません。

次の報告は、除外できたものを1つ書き足すところから始めてみてください。それだけで、あなたの1時間はちゃんと言葉になります。

長引いた障害の対応を終え、時系列に書き残したメモを前に、朝の光の中で肩の力が抜けている保守運用の担当者

よければ、こちらも

障害の連絡まわりは、前後の記事とつなげて読むと、当日の迷いが減ります。

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

関連用語