トラブル報告書の書き方【社内向け】｜発生→経緯→現状→対応→再発防止の型と例文

2026年6月18日

社内向けトラブル報告書は「型」に沿えば迷わず書ける

社内のシステム障害や連携ミスはもちろん、客先で起きたトラブル・取引先との納期問題・顧客からのクレームなど、起きたトラブルを上司や社内へ報告する＝社内向けトラブル報告書を書くとき、何から手をつければいいか手が止まりがちです。結論から言うと、報告書は「発生 → 経緯 → 現状 → 対応 → 再発防止」の順に並べる型に当てはめれば、トラブルの種類が違っても迷わず形になります。

ここでいう「社内向け」とは、提出先が社内（上司・部門）という意味です。トラブル自体は客先・取引先など社外で起きたものでも、それを上司・社内に報告するなら社内向けトラブル報告書にあたります。一方、取引先へ直接出すお詫び＋経緯の「社外向け」報告は、謝罪が目的で書き方も別物です。ここでは社内向け（事実を整理して報告・指示を仰ぐ）の書き方を扱います。

この型がそのまま、上司が知りたい順番です。「何が起きて（発生）、どういう流れで（経緯）、今どうなっていて（現状）、どう手を打ったか（対応）、繰り返さない手立ては何か（再発防止）」。読み手が判断に必要な情報を、判断する順に並べるのがコツです。

発生：いつ・どこで・何が起きたか（結論を先に1〜2行で）
経緯：発生から現在までの出来事を時系列で
現状：報告時点での状況（復旧済み／対応継続中など）
対応：すでに行った対応と、これから行う対応・見通し
再発防止：原因と対になる、繰り返さないための具体策

順番に迷ったら、まず「結論（何が起きたか）」を冒頭に置くことだけ守れば大きく外しません。経緯から書き始めると、上司は最後まで読まないと事の重大さが分からず、初動が遅れます。

解決前でも出す——「第一報」を早く出すのが最優先

社内トラブル報告でいちばん大事なのは、文章のうまさではなく速さです。原因が分からなくても、解決していなくても、トラブルを認知した時点で第一報を出すのが鉄則です。報告が遅れるほど被害は広がり、「なぜすぐ言わなかった」と問われるのは報告内容ではなく報告の遅さです。

「全部分かってからまとめて報告しよう」と完璧を待つと、対応の初動が丸ごと遅れます。第一報は分かっていることだけで構わないので、調査中の項目は「現在調査中」と書いて先に出し、判明し次第あらためて続報を入れる、という二段構えにします。

急ぎのトラブルは、まず口頭や電話・チャットで一報を入れてから書面に起こすのが実務です。報告書はその記録と、関係者への共有・指示を仰ぐための土台になります。第一報の時点では、最低限つぎの3点が埋まっていれば動けます。

何が起きたか（事象の概要・結論）
今どうなっているか（影響範囲・被害の有無）
現時点で誰が何をしているか（暫定対応・調査の状況）

テレワークの普及で、第一報を社内メールやビジネスチャット（Slack・Teams）でテキスト送信するケースも増えています。このあと紹介する本文例の「記」以降の内容は、社内メールやチャットにそのまま貼り付けて送信してもかまいません。まずチャットで一報を流し、正式な記録として同じ内容を報告書に残す、という運用でも問題ありません。

原因・再発防止策は、第一報の段階では空欄でも構いません。無理に原因を断定すると、後で覆ったときにかえって混乱します。確定していないことは「調査中」と書き、続報で埋めていくのが正しい順序です。

事実と推測を分けて書く

進行中のトラブルほど、原因が見えないまま報告することになります。そのとき危ないのが、確認できた事実と、書き手の推測が同じ文に混ざることです。読み手が「これは確定事項か、予想か」を切り分けられないと、誤った前提で対応を指示してしまいます。

NG（事実と推測が混在）	OK（事実と推測を分離）
おそらくサーバーの設定ミスが原因で、システムが止まったと思われます。	○時にシステムが停止した（事実）。原因はサーバー設定の不備の可能性があり、現在調査中（推測・調査状況）。
先方はかなり怒っていて、たぶん契約は危ういです。	先方より「対応が遅い」との指摘を受けた（事実）。今後の取引への影響が懸念される（所感）。

事実と推測を分けた言い回しの例

コツは、確認できた事実は「〜した」「〜である」と言い切り、推測は「〜の可能性がある」「〜と考えられる」で締めること。原因がまだ特定できていないなら、無理に断定せず「現在調査中」と書くのが、進行中の報告では正解です。

社内向けトラブル報告書の本文例（コピーして使える型）

ここまでの型を埋めた本文例です。1つ目は対応継続中の「第一報」、2つ目は収束後にまとめる報告の形にしています。例はシステム障害・納期遅延ですが、客先・取引先など社外で起きたトラブルを社内へ報告する場合も、この型のまま「発生場所・影響範囲」に相手先を書けば対応できます。社名・日時・項目を自社の状況に置き換えてお使いください。

トラブル報告書（第一報・対応継続中の例）

トラブル報告書 ○○部 ○○部長 20XX年X月X日 ○○部 ○○○○ 標記の件につきまして、現在判明している状況を下記のとおりご報告いたします。詳細は調査中のため、続報にて改めてご報告いたします。記 1. 発生日時：20XX年X月X日（曜）XX時XX分頃 2. 発生場所・影響範囲：社内基幹システム（営業部全体に影響） 3. 概要（結論）：基幹システムにログインできない障害が発生し、受注入力が停止している。 4. 経緯：（XX時XX分）担当者がログイン不可を確認（XX時XX分）情報システム部へ連絡、復旧対応を依頼（XX時XX分）原因の切り分けを実施中 5. 現状：原因は調査中。受注業務は手書き伝票で暫定運用している。 6. 暫定対応・今後の見通し：情報システム部にて復旧作業中。復旧見込みは追ってご連絡する。 7. 再発防止策：原因特定後に検討し、続報にて報告する。以上

トラブル報告書（収束後・原因と再発防止まで記載した例）

トラブル報告書 ○○部 ○○部長 20XX年X月X日 ○○部 ○○○○ 標記の件につきまして、発生から収束までの経緯を下記のとおりご報告いたします。記 1. 発生日時：20XX年X月X日（曜）XX時XX分頃 2. 発生場所・影響範囲：○○社向け出荷分（全X件） 3. 概要（結論）：○○社向けの商品納品が、当初納期より2日遅延した。 4. 経緯：（X月X日）在庫システムの数量不整合を確認（X月X日）システム部門へ修正を依頼（X月X日）システム復旧、出荷を再開（X月X日）遅延分の出荷を完了 5. 原因：在庫管理システムの引当処理に不具合があり、出荷可能数が正しく表示されなかった。 6. 現状：システムは復旧済み。遅延分の出荷はすべて完了している。 7. 対応：○○社へは個別に連絡し、お詫びと納品日の再調整を行った。 8. 再発防止策：出荷前に在庫数量を担当者2名でダブルチェックする運用を、X月X日より開始する。以上

2つの例で変えているのは原因・再発防止策が「調査中」か「確定」かの部分です。型（項目の並び）は同じまま、第一報では未確定欄を「調査中／続報にて報告」と書いておき、続報・収束報告で埋めていけば、同じ書式を使い回せます。

上司が報告書を突き返す最大の理由は、再発防止策が「気をつけます」「徹底します」といった精神論で終わっていることです。次の1例だけ意識すれば、印象が変わります。

NG（精神論）	OK（仕組み化）
今後は確認を徹底し、ミスが起きないよう注意します。	出荷前に在庫数量を担当者2名でダブルチェックする運用をルール化します。

再発防止策は「人の心がけ」ではなく「仕組み」で書く

原因と対になる仕組みの作り方や、誤発送・連絡漏れ・クレームなど類型別の再発防止策の例文は、次の記事にまとめています。

報告書

再発防止策の書き方・例文｜「注意します」で終わらせない報告書の書き方

報告書の再発防止欄に何を書けばいいか迷う人向けに、良い再発防止策の4条件（具体的・実行可能・主語と期限・仕組み化）、直接原因と根本原因の分け方、なぜなぜ分析のやり方、「注意する」「徹底する」だけのNG例→OK例を解説。誤発送・入力ミス・連絡漏れ・クレーム・事故など、そのままコピーして使える再発防止策の例文を類型別・業種別に多数掲載します。

記事を読む

経緯報告書・顛末書との違い（どれを書くべきか）

社内向けにトラブルを報告する文書には、よく似た名前のものがあります。迷ったら、「まだ進行中か／解決したか」「事実報告か／謝罪か」で選ぶと整理できます（いずれも提出先は社内）。

文書	書くタイミング	中身の重心
経緯報告書	問題が進行中・解決前	発生から現在までの経緯＋現状・今後の見通し
顛末書	問題が解決した後	発生から解決までの一部始終を総括
始末書	重大な過失・規律違反の後	過失を認めて謝罪・反省する（懲戒に関わることも）

進行中か解決後か・事実報告か謝罪かで使い分ける

進行中のトラブルを「現状」「今後の見通し」まで含めて報告するなら、実態は経緯報告書です。一方、解決した後に「結局どうなったか」を一部始終まとめるなら顛末書が適切で、こちらは現状や見通しを持ちません。ここまで紹介してきた第一報・続報は、解決前に出す経緯報告書にあたります。なお、いずれも提出先が社内（上司・部門）の「社内向け」です。取引先へ直接出すお詫び＋経緯の社外向け報告は謝罪が目的の別文書なので、混同しないようにします。

進行中の一報は本記事の型でカバーできますが、トラブルが収束したあとに上司・人事へ総括を出す段になったら、顛末書の書き方を参考にしてください。

始末書・顛末書

顛末書の書き方【社内向け】｜上司・人事への報告に使える構成と例文

業務上のトラブルで顛末書を社内（上司・人事・経営層）に提出する人向けに、事実を客観的に整理する5W1H構成、提出先別の文面差、軽微なミス・システム障害・顧客クレーム・情報漏洩の社内顛末書の例文をまとめました。始末書との違いや反省文との使い分けも整理します。

記事を読む

なお、自分の作業ミス（誤発送・入力ミス・連絡漏れなど）に絞った報告は、トラブル報告とは書き出しや原因の書き方の力点が少し変わります。言い訳を足さず「事実 → 原因 → 再発防止」で書くコツや類型別の例文は、次の記事にまとめています。

報告書

作業ミス・業務ミスの報告書例文｜言い訳より「事実・原因・再発防止」で書く

誤発送・入力ミス・連絡漏れなど、自分の作業ミスを上司に報告する報告書の書き方と例文をまとめます。報告書は謝罪文ではなく中立の事実報告。言い訳を足さず「事実→原因→再発防止策」で書くのが基本です。ミスの類型別にそのまま使えるコピペ例文と、始末書・作業事故報告との使い分けも解説します。

記事を読む

報告書の基本構成や、5W1H・事実と意見の分け方をまとめて確認したいときは、報告書全体のガイドもあわせてご覧ください。

報告書

報告書の書き方｜基本構成・5W1H・例文テンプレと種類別の使い分け

報告書の書き方を、表題・宛先・5W1Hの基本構成、結論から書く・事実と意見を分けるといったビジネス報告の鉄則、そのまま使える構成テンプレ付きで解説。業務・調査・事故・トラブル・クレーム・改善など種類別の使い分けと、「報告書・始末書・顛末書・経緯報告書の違い」も整理します。

記事を読む

顧客からのクレーム・苦情がきっかけのトラブルも、社内への一報なら同じ「発生 → 経緯 → 現状 → 対応」の型で書けます。ポイントは、「先方より◯◯との指摘を受けた（事実）」「一次対応として△△を実施（対応）」と、受けた内容と打った手を分けて書くこと。ただし、顧客名・受付方法・一次対応・水平展開まで含めて正式な苦情の記録として残すなら、クレーム報告書のほうが項目がそろっています。受けた苦情を客観的に記録する書き方と例文は、専用の記事にまとめています。

報告書

クレーム報告書の書き方と例文｜受付方法・一次対応・再発防止の項目と社内向けテンプレ

クレーム報告書の書き方を、受付方法・顧客情報・クレーム内容・一次対応・原因・再発防止策・水平展開という項目に沿って解説。クレームを受けた側が事実を客観的に記録する社内文書という性格、一次対応と報告書の時系列、商品不良・接客・納期トラブルでそのまま使える本文例つき。顧客へ送る対応メールとの違いも整理します。

記事を読む

経緯報告書テンプレートで第一報をすぐ形にする

進行中のトラブルは、レイアウトを整えている時間が惜しいものです。TEMPLEXの経緯報告書テンプレートなら、発生日時・経緯・原因・現状・今後の対応・再発防止策の欄を埋めるだけでA4のPDFが即発行できます。本記事の本文例をそのまま貼り付ければ、第一報も収束後の報告もすぐ整います。詳しくは経緯報告書テンプレートをご利用ください。

前文には「社内向け（対応継続中）」のプリセットも用意しているので、解決前の段階でも、現状と今後の見通しを添えた一報をそのまま出せます。

発生日時・発生場所・件名をフォームに入力
経緯（時系列）・原因・現状・今後の対応を記書きに記載
プレビューで体裁を確認しながらリアルタイム編集
PDFとして即ダウンロード（Microsoft Office 不要）
差出人情報は次回以降自動入力

報告書をすぐに作成しませんか？

TEMPLEXなら、フォームに入力するだけで報告書のPDFを作成・ダウンロードできます。

報告書のテンプレートを見る

コラム著者・編集者

TEMPLEX編集チーム

TEMPLEX編集チームは、ビジネス文書の作成・管理に精通した実務経験者と技術ライターで構成されています。送付状・請求書・見積書をはじめとする各種ビジネス書類のフォーマットや書き方のノウハウを、わかりやすく丁寧にお届けします。「Office不要で誰でもすぐ使える」をコンセプトに、忙しいビジネスパーソンの書類作成をサポートします。