ITシステムのトラブル報告書の書き方｜テンプレートと作成ポイントを徹底解説

障害・トラブル報告書とは

ITシステムの運用では、障害やトラブルを完全に避けることはできません。

特に商用システムで障害が発生した場合、技術的な原因調査だけでなく、顧客やPM、システム利用者などに対して「何が起きたのか」「どのような影響があったのか」「なぜ起きたのか」「どのように対処したのか」「今後どう再発を防ぐのか」を正確に説明する必要があります。

しかし、調査した内容をそのまま時系列に並べたり、技術用語だけで説明したりしても、分かりやすいトラブル報告書にはなりません。

重要なのは、事象・影響・原因・対処を整理し、読み手が知りたい順番で説明することです。

本記事では、システム障害やインフラトラブルの報告で利用できる、実践的なトラブル報告書の構成と書き方を解説します。

トラブル報告書の基本構成

トラブル報告書は、以下の9項目で整理すると分かりやすくなります。

ポイントは、単に技術情報を並べるのではなく、「何が起きた → どんな影響があった → なぜ起きた → どう直した → 今後どう防ぐ」という流れを作ることです。

1. 表題

表題では、できるだけ利用者や業務から見た事象（サービス影響）を記載します。

たとえば、WebサーバでHTTP 404エラーが発生したケースを考えてみます。

NG例：
Webサーバにて404エラーが発生した件についてのご報告

OK例：
Webサービスの一部コンテンツが参照できない事象についてのご報告

404エラーはシステム内部の事象です。一方、利用者にとって重要なのは「コンテンツを参照できなかった」というサービス影響です。

特に顧客向けの報告書では、内部コンポーネントで発生したエラーだけを書くのではなく、利用者から何が見えていたのかを意識すると伝わりやすくなります。

2. 概要

概要では、トラブルの全体像を短く説明します。

ここだけを読んでも、トラブルの概要が把握できる状態を目指します。

最低限、以下の内容を含めるとよいでしょう。

いつ発生したのか
どのサービス・システムで発生したのか
何が発生したのか
どのような影響があったのか
現在はどのような状態なのか

たとえば、以下のように記載します。

2026年9月1日 10:05～10:25の間、Webサービスの一部コンテンツが参照できない事象が発生しました。調査の結果、Webサーバへの設定反映漏れが原因であることを確認しました。10:25に設定を修正し、現在は正常にサービスを提供しています。

顧客や利用者に影響を与えた場合は、必要に応じて謝罪の文言も記載します。

3. 事象

事象では、確認できた客観的な事実を中心に記載します。

代表的な情報は以下です。

発生日時
発生箇所
エラーメッセージ
エラー件数
監視アラート
ログ
正常時との違い

ここで重要なのは、事象と原因を混ぜないことです。

たとえば、

10:05からWebサーバAにおいてHTTP 404が発生した。

は確認された事実です。

一方、

設定反映漏れによってHTTP 404が発生した。

は原因分析を含んでいます。

「何が起きたのか」と「なぜ起きたのか」を分離するだけでも、報告書はかなり読みやすくなります。

また、システム構成が複雑な場合は、システム構成図や処理フロー図を使って、問題が発生した箇所を視覚的に示すと効果的です。

4. 影響

影響では、技術的な障害内容そのものではなく、その障害によって実際に何が起きたのかを整理します。

影響は、サービス影響・システム影響・データ影響の3つに分けて整理すると分かりやすくなります。

サービス影響

サービス影響では、利用者や業務にどのような影響があったのかを記載します。

たとえば、以下のような内容です。

影響時間：10:05～10:25（20分間）
影響ユーザ数：87ユーザ
エラー件数：152件
影響機能：商品詳細ページを参照できない
業務への影響：対象時間帯に一部の操作を実施できない

単に「HTTP 404が発生した」と書くのではなく、利用者から見て何ができなかったのか、業務にどのような支障があったのかまで記載することがポイントです。

システム影響

システム影響では、障害によってシステム内部のコンポーネントや後続処理にどのような影響があったのかを記載します。

たとえば、以下のような内容です。

WebサーバAでのみHTTP 404が発生
ほかのWebサーバは正常に稼働
後続バッチ処理への影響なし
外部システムとの連携への影響なし

利用者への直接的な影響だけでは分からない、システム内部で影響を受けた範囲を明確にするための項目です。

データ影響

データ影響では、障害によってデータの欠損・重複・誤更新・不整合などが発生していないかを記載します。

たとえば、以下のような内容です。

データ欠損：なし
二重登録：なし
データ不整合：なし
復旧後のデータ補正：不要

サービスが復旧していても、障害発生中にデータが正しく処理されていたかは別途確認が必要な場合があります。そのため、データ影響の有無はサービス影響とは分けて明示すると分かりやすくなります。

このように、サービス影響・システム影響・データ影響の3つに分けることで、「利用者・業務への影響」「システム内部への影響」「データへの影響」を漏れなく整理できます。

5. 時系列

障害報告では、発生から復旧までの流れを時系列で整理すると、対応状況が非常に分かりやすくなります。

時刻	内容
10:05	Webアクセスエラー発生
10:07	監視システムが異常を検知
10:10	担当者がログ調査を開始
10:18	Webサーバの設定差異を確認
10:22	設定を修正
10:25	正常性を確認し復旧

時系列を整理すると、単なる経過説明だけでなく、検知・調査・判断・復旧にそれぞれどの程度の時間を要したのかも確認できます。

これは、復旧時間の短縮や監視改善など、再発防止策を検討するうえでも重要な情報になります。

6. 原因

原因は、トラブル報告書の中でも特に重要な項目です。

単に「○○が原因でした」と直接的な原因だけを記載するのではなく、「なぜその事象が発生したのか？」を繰り返し、原因を段階的に深掘りすることが重要です。

たとえば、原因を一次原因 → 二次原因 → 三次原因と整理します。

一次原因

まず、トラブルを直接発生させた原因を記載します。

WebサーバAに必要な設定ファイルが反映されていなかった。

二次原因

次に、「なぜ設定ファイルが反映されていなかったのか？」を掘り下げます。

複数のWebサーバへの設定変更を手動で実施しており、WebサーバAへの反映作業が漏れていた。

三次原因

さらに、「なぜ反映漏れを防止できなかったのか？」を掘り下げます。

設定変更後に全Webサーバの設定差異を確認する仕組みがなく、担当者の手作業による確認に依存していた。

このように、

事象 → なぜ？ → 一次原因 → なぜ？ → 二次原因 → なぜ？ → 三次原因

という形で「なぜ？」を繰り返すことで、表面的な原因だけでなく、再発防止につながる根本的な原因まで整理しやすくなります。

ただし、三次原因まで必ず記載しなければならないわけではありません。トラブルの内容に応じて、再発防止策を具体化できるところまで必要な深さで原因を掘り下げることが重要です。

原因は文章だけでなく図解する

原因が複雑な場合、文章だけでは因果関係が分かりにくくなります。

そのため、システム構成図、処理フロー図、原因を段階的に示した図などを使って視覚化することをおすすめします。

特に、

事象 → 一次原因 → 二次原因 → 三次原因

の関係を図で示すと、「なぜこのトラブルが発生したのか」を顧客やPMにも伝えやすくなります。

未検知理由

原因そのものとは別に、なぜレビュー・試験・監視などで問題を事前に発見できなかったのかも整理します。

試験ではWebサーバBへのアクセスのみを確認しており、WebサーバAを含む全サーバの設定差異を確認していなかった。

原因を深掘りするだけでなく未検知理由まで整理することで、「問題を発生させないための対策」と「問題を早い段階で検知するための対策」の両方を検討できるようになります。

また、調査途中の報告では「事実」「推測」「未確認」を明確に区別することも重要です。

推測を事実として記載すると、後から原因が変わった際に報告全体の信頼性を損なう可能性があります。

7. 対処

対処では、トラブルをどのように復旧させたのかを記載します。

暫定対処と恒久対処が異なる場合は、分けて記載すると分かりやすくなります。

暫定対処

WebサーバAへ不足していた設定を反映し、サービスを復旧した。

恒久対処

設定ファイルの配布を自動化し、全Webサーバへの反映結果を自動確認する仕組みを導入する。

また、「対応予定」とだけ記載するのではなく、可能であれば以下も明確にします。

実施内容
対象
担当
実施予定日
完了条件

これによって、対処が単なる方針ではなく、実行可能なアクションになります。

8. 水平展開

水平展開では、同じ問題がほかのシステムやサーバ、設定、処理にも存在しないかを確認します。

たとえば今回の原因が「複数サーバへの設定反映漏れ」であれば、以下のような確認が考えられます。

ほかのWebサーバにも設定差異がないか
同じ方法で管理している設定ファイルがないか
ほかの環境でも同じ運用を行っていないか
類似システムにも同様の問題がないか

最低限、今回の一次原因と同様の問題が横並びで存在しないかは確認しておくとよいでしょう。

ただし、水平展開の範囲を無制限に広げると、確認コストが非常に大きくなります。

原因との関連性、影響度、確認コストを考慮して対象範囲を決めることが重要です。

9. 再発防止策

再発防止策は、原因分析と未検知理由に対応する形で設定することが重要です。

特に避けたいのが、以下のような対策です。

NG例

確認を徹底する
担当者へ注意喚起する
今後十分注意する

これらは担当者の注意力に依存しているため、時間が経つと同じ問題が再発する可能性があります。

可能な限り、仕組み・プロセス・自動化によって再発しにくい状態を作ります。

また、一次原因・二次原因・三次原因・未検知理由と再発防止策を対応付けると、対策の妥当性を説明しやすくなります。ただし、すべてを網羅する必要はないので、効果的な再発防止を選択して記載する形で問題ないです。

分析結果	再発防止策
一次原因：設定反映漏れ	設定配布を自動化
二次原因：手作業による設定変更	デプロイ手順を自動化
三次原因：設定差異を確認する仕組みがない	全サーバの設定差異を自動チェック
未検知理由：試験対象が一部サーバのみ	全サーバを対象とした確認を追加

このように、原因を掘り下げた結果と再発防止策を対応付けることで、「なぜこの対策を実施するのか」が明確になります。

トラブル報告書を書くときに重要な3つのポイント

事実と推測を分ける

障害調査中は、原因が確定していないことも珍しくありません。

その場合は、「確認済み」「調査中」「推測」といったステータスを明確にし、推測を事実として扱わないようにします。

結論から書く

技術者は調査した順番で説明してしまいがちですが、読み手が知りたい順番とは限りません。

特に顧客やPMへの報告では、まず結論を示し、その後に根拠や詳細を説明する方が理解しやすくなります。

技術用語だけで説明しない

「HTTP 404」「Connection Timeout」「OOM」などの技術用語だけでは、利用者への影響が分かりません。

技術的な事象だけでなく、それによって発生したサービス影響までセットで説明すると伝わりやすくなります。また、必要に応じてシステム影響やデータ影響も明示します。

トラブル報告書テンプレート

最後に、実際の障害報告で利用できるテンプレートをまとめます。

1. 表題
○○が利用できない事象についてのご報告

2. 概要
・発生日時：
・対象システム：
・事象概要：
・影響：
・現在の状態：

3. 事象
・発生日時：
・発生箇所：
・確認されたエラー：
・確認されたログ：
・正常時との差異：

4. 影響
・サービス影響：
　- 影響時間：
　- 影響ユーザ：
　- 影響件数：
　- 影響機能／業務：
・システム影響：
・データ影響：

5. 時系列
HH:MM　事象発生
HH:MM　障害検知
HH:MM　調査開始
HH:MM　原因特定
HH:MM　対処実施
HH:MM　復旧確認

6. 原因
・一次原因：
・二次原因：
・三次原因：
・未検知理由：
・原因を示す構成図／処理フロー図：

7. 対処
・暫定対処：
・恒久対処：
・実施予定日：

8. 水平展開
・確認対象：
・確認方法：
・確認結果：

9. 再発防止策
・原因に対する対策：
・未検知理由への対策：
・実施期限：

まとめ

トラブル報告書で重要なのは、単に技術的な調査結果をまとめることではありません。

「何が起きたのか」「どのような影響があったのか」「なぜ起きたのか」「どう復旧したのか」「どう再発を防ぐのか」を、読み手が理解できる形で整理することが重要です。

基本構成としては、以下の9項目で整理すると分かりやすくなります。

表題
概要
事象
影響
時系列
原因
対処
水平展開
再発防止策

特に原因分析では、直接的な原因だけで終わらせず、「なぜ？」を繰り返して一次原因、二次原因、三次原因と段階的に深掘りし、未検知理由も整理することが重要です。

さらに、それぞれの原因や未検知理由に対応した再発防止策を設定することで、単なる報告ではなく、同じ問題を繰り返さないための実践的なトラブル報告書になります。

障害発生時にゼロから報告書の構成を考えるのは大変なので、自分のプロジェクトや組織に合わせたテンプレートをあらかじめ用意しておくことをおすすめします。