【報告書の書き方】事実・原因・対策を分けて伝える基本

「報告書を書いてください」と言われて、何から書けばいいのか迷いませんか。

何が起きたのか。原因はどこまで書くのか。自分の考えを入れていいのか。どこまで詳しく書けばいいのか。

報告書というと、きれいな文章を書かなければならないように感じます。でも、仕事の報告書で本当に大切なのは文章力ではありません。

読んだ人が状況を理解し、次の判断や行動に進めることです。

この記事で分かること

• 報告書に何を書けばいいか
• 事実・影響・原因・対応・対策の分け方
• 5W1Hを報告書でどう使うか
• 事実と推測を混ぜない書き方
• 「気をつけます」で終わらせない再発防止策
• 事故・トラブル時に第一報を優先する考え方
• AIに報告書を作らせるときの注意点

報告書は「うまい文章」を書くものではない

報告書の目的は、文章を読ませることではありません。

必要な情報を整理して、相手が判断できる状態を作ること。

例えば、設備が停止したときに、

「機械が壊れました。修理をお願いします」

だけでは、受け取った側は次の判断ができません。

• どの設備なのか
• いつ止まったのか
• どんな症状なのか
• 現在使えるのか
• 業務への影響はあるのか
• 原因は分かっているのか
• 修理以外の対応はあるのか

結局、報告を受けた側が一つずつ聞き直すことになります。

「自分が言いたいことを書く」のではなく、「相手が次に何を判断するのか」を考える。

これが報告書の基本です。

迷ったら「事実→影響→原因→対応→対策」で整理する

報告書の内容は、まず次の5つに分けると整理しやすくなります。

項目	書くこと
事実	何が起きたのか
影響	顧客・納期・品質・金額・業務に何が起きるか
原因	なぜ起きたのか。未確定なら調査中とする
対応	発生後に何をしたか
対策	今後、何を変えるのか

全部の報告書に5項目が必須という意味ではありません。

通常の業務報告なら「実施内容→結果→課題→次の対応」で十分なこともあります。

ただ、トラブルや事故の報告では、事実・原因・対応・再発防止を混ぜないだけでもかなり読みやすくなります。

5W1Hは「抜け」を見つけるために使う

何を書けばいいか分からないときは、5W1Hで事実を確認します。

項目	確認すること
When	いつ
Where	どこで
Who	誰が・誰に
What	何が起きた
Why	なぜ起きた
How	どのように起きた

ただし、5W1Hを全部一文に詰め込む必要はありません。

項目に分けても、箇条書きでも構いません。

5W1Hは作文の型ではなく、必要な情報が抜けていないか確認するための道具として使う方が実務的です。

そもそも報告で何を伝えるべきか迷うなら、こちらの記事も参考にしてください。

最初に「結局どうなったのか」を書く

長い報告書ほど、最初に概要を書きます。

9月22日15時ごろ、第一工場のA設備が停止しました。
現在は使用を中止し、代替設備へ切り替えています。
現時点で納期への影響はありません。原因は調査中です。

これだけ読めば、まず現在地が分かります。

そのあとに経緯、原因、対応などの詳細を書けばいい。

読み手が最初に知りたいのは、たいてい「何が起きて、今どうなっているのか」です。

事実と推測を混ぜない

報告書で特に気をつけたいのが、確認できた事実と、自分の推測を分けることです。

例えば、

作業員の確認不足が原因で設備が停止した。

と書いたとして、本当に原因まで確認できているでしょうか。

確認できているのが「操作中に設備が停止した」までなら、「確認不足が原因」はまだ推測かもしれません。

設備側の不具合、手順の問題、表示の分かりにくさ、作業環境など別の原因がある可能性もあります。

まだ分からないことは、無理に埋めなくて構いません。

原因：現在調査中

これで十分な場面もあります。

AIで議事録を作る場合にも、似た問題があります。自然な文章でも、AIが不明な情報を勝手に補えば事実ではありません。【議事録の取り方】AI時代でも知っておきたい基本と3つの作り方でも、「推測しない」「不明なら要確認」とする考え方を扱っています。

原因が分からないなら無理に決めない

報告書を早く終わらせようとして、原因を、

• 確認不足
• 注意不足
• 認識不足
• 操作ミス

で終わらせることがあります。
もちろん、本当にそれが原因のこともあります。

でも、なぜ確認不足になったのかまで見なければ、同じ条件でまた起こるかもしれません。

• 確認項目そのものが決まっていなかった
• 手順書が古かった
• 担当者ごとに方法が違った
• 誰が最終確認するか決まっていなかった
• 情報が複数の場所に分かれていた

厚生労働省も、労働災害が発生した場合には、災害原因を分析し、再発防止対策を策定・実施することが重要だとしています。

参考：厚生労働省「労働災害が発生したとき」

悪い報告書は「一見ちゃんとしている」から厄介

分かりやすく極端な悪い例より、実務では次のような報告の方が問題になりやすいです。

9月22日午後、A設備が停止しました。
担当者に確認したところ、操作時の確認不足が原因と思われます。
現在は復旧しており、生産への影響はありません。
今後は作業前の確認を徹底し、同様のトラブルが起きないよう注意します。

文章だけを見ると、かなりまともです。

でも、読む側には疑問が残ります。

• 「確認不足」が本当に原因なのか
• 何をして復旧したのか
• 「影響なし」は何を確認して判断したのか
• 作業前に何を確認するのか
• 誰が確認するのか
• いつから方法を変えるのか

報告書は、文章が整っているだけでは足りません。

読んだ人が追加で何度も質問しなくても、状況と次の対応を判断できることが大切です。

「気をつけます」「頑張ります」では対策にならない

再発防止策で、本当によく出てくるのが次の言葉です。

「今後は気をつけます」
「確認を徹底します」
「周知します」
「同じことがないよう頑張ります」

気をつけること自体が悪いわけではありません。

でも、管理する側からすると返したくなる言葉があります。

「だから、何を？」

「気をつける」では、仕事のやり方が何も変わっていないからです。

対策にするなら、行動や仕組みに落とします。

曖昧な対策	行動にした対策
確認を徹底する	出荷前に品番と数量を照合し、チェック欄へ記録する
注意する	作業開始前に設定値を2項目確認する
ミスをなくす	入力後に別担当者が金額を照合する
早めに報告する	顧客・納期に影響する問題は判明時点で上司へ報告する

可能なら、さらに誰が・何を・いつから・どの方法でまで決めます。

「意識を変える」より、「行動を変える」。その方が、実施したかどうかも確認できます。

トラブル報告は時系列も残す

事故やトラブルでは、いつ何をしたかが重要になることがあります。

時刻	内容
10:05	A設備が停止
10:10	担当者から上司へ報告
10:20	保全担当が現場確認
10:40	部品破損を確認
11:00	代替設備へ切り替え
13:30	修理完了

長い文章にするより、この方が経緯を追いやすい場合があります。

先ほどの厚生労働省の指針でも、事故後の記録は初期対応後に速やかに行い、できる限り経時的に記載する考え方が示されています。

報告書には「今どうなっているか」も書く

過去の経緯だけでなく、現在の状態も重要です。

• 現在停止している
• 応急処置で使用できる
• 代替設備へ切り替えた
• 顧客への影響はない
• 納期に1日影響する可能性がある
• 原因調査中
• 復旧見込みは17時

読み手が知りたいのは、「で、今どうなっている？」だからです。

報告書の基本構成

迷ったら、次の形を基本にすると使いやすいです。

1. 件名：何についての報告か
2. 概要：何が起き、現在どうなっているか
3. 発生日時・場所・関係者
4. 発生した事実
5. 影響・結果
6. これまでの対応
7. 原因：未確定なら「調査中」
8. 今後の対応・再発防止
9. 添付資料：写真、ログ、データなど

そのまま使える報告書テンプレート

件名：

報告日：

報告者：

1．概要
何が起きたか、現在どうなっているかを簡潔に記載。

2．発生日時・場所
日時：
場所：

3．発生した事実
確認できている事実のみ記載。

4．影響
業務・顧客・品質・納期・金額などへの影響。

5．これまでの対応
何を、いつ、誰が行ったか。

6．原因
判明している原因。未確定なら「調査中」。

7．今後の対応・再発防止策
誰が、何を、いつまでに行うか。

8．添付資料
写真、ログ、データ、関連資料など。

報告書完成より第一報を優先する場面もある

報告書をきれいに仕上げてから報告しようとすると、初動が遅れることがあります。

特に、

• 事故
• 情報漏えい
• 顧客クレーム
• 納期遅延
• 大きな設備トラブル

などは、詳細な報告書より第一報が先になることがあります。

現在分かっている範囲で第一報します。
詳細は確認後、改めて報告します。

これでいい場面もあります。

情報セキュリティ分野では、IPA（独立行政法人 情報処理推進機構）が、インシデント発生時に従業員が速やかに適切な初動を取れるよう、対応を事前に定めておく重要性を示しています。

IPAは、経済産業省所管の独立行政法人で、情報セキュリティ対策やデジタル人材育成などを行う公的機関です。

参考：IPA「プラクティス7-2 従業員の初動対応の規定」／IPA「独立行政法人等の組織に関する情報」

必要な情報を、必要なタイミングで出す。

完璧な報告書を遅れて出すより、重要な問題を早く共有する方が大切なことがあります。

通常の業務報告ならもっと簡単でいい

すべての報告書を事故報告の形にする必要はありません。

進捗報告なら、

やったこと → 結果 → 課題 → 次にやること

くらいで十分です。

実施内容
A社へ見積書を提出。

結果
仕様変更の依頼があり、再見積となった。

課題
納期条件について仕入先への確認が必要。

次の対応
9月23日に仕入先へ確認し、24日までに再見積を提出予定。

報告書は長いほど良いわけではありません。

上司が知りたいのは「次に判断すべきこと」

報告書を書き終えたら、一度だけ考えます。

「この報告を読んだ人は、次に何を判断する？」

例えば、

• 修理するか
• 顧客へ連絡するか
• 納期を変更するか
• 費用を承認するか
• 人員を追加するか
• 再発防止策を実施するか

判断が必要なら、その材料まで入れます。

例えば修理承認なら、修理費、復旧までの時間、代替手段、放置した場合の影響などがあると判断しやすくなります。

報告書は記録であると同時に、意思決定のための資料でもあります。

AIに報告書を書かせるなら材料を先に整理する

生成AIを使えば、報告書の文章を整える作業はかなり早くできます。

ただし、AIに渡す情報が曖昧なら、完成する報告書も曖昧です。

最低限、次の情報を整理してから渡します。

• 何が起きたか
• いつ起きたか
• どこで起きたか
• 現在の状態
• 影響
• 実施した対応
• 分かっている原因
• まだ分からないこと
• 今後の対応

AIへの指示には、

「入力した情報にない内容は推測せず、不明な項目は『要確認』としてください」

と入れておくと安全です。

そして、作成後は日時、数字、原因、対応内容を人間が確認します。

AIは文章を整えることはできても、何が事実かを現場の代わりに確認することはできません。

提出前に確認する10項目

• 最初に概要・結論があるか
• いつ・どこで・誰が・何をしたか分かるか
• 事実と推測が混ざっていないか
• 原因を根拠なく断定していないか
• 現在どうなっているか分かるか
• 顧客・納期・品質などへの影響が分かるか
• これまでの対応が分かるか
• 今後何をするか分かるか
• 「気をつける」だけの対策になっていないか
• 読み手が次の判断をできる情報があるか

まとめ｜報告書は次の人が判断できる形にする

報告書の書き方で迷ったら、まず文章を考える必要はありません。

先に整理するのは、

事実 → 影響 → 原因 → 対応 → 対策

です。

そして、

• 何が分かっているのか
• 何がまだ分からないのか
• 今どうなっているのか
• 次に何をするのか

を分けて書きます。

原因が分からなければ「調査中」でいい。

対策を書くなら「気をつけます」で終わらせず、行動にする。

緊急性が高ければ、完成した報告書を待たずに第一報を出す。

報告書は、きれいな文章を書くためのものではありません。

読んだ人が状況を理解し、次の行動や判断に進めるようにするためのものです。