業務効率化

顛末書の書き方|社内・社外別テンプレ例文6本と始末書との違い【2026年】

顛末書(てんまつしょ)は、業務上で起きたトラブルについて「何が、いつ、どういう順序で起きたのか」を事実として報告する社内文書です。謝罪や反省を述べる始末書とは目的が違い、書くべき内容も、提出させる側の扱い方も別物になります。

ところが実務では「とりあえず顛末書を出して」と言われた側が、事実と推測と言い訳を混ぜて書いてしまい、後から会社が困るというケースが少なくありません。顛末書は法律で様式が決まっている書類ではないぶん、書式を社内で揃えておかないと品質が人任せになります。

この記事では、経理・総務の担当者と、それを指導する立場の方に向けて、顛末書の骨格・社内向けと社外向けの例文6本・AIで下書きを作る手順までをまとめました。

この記事で分かること

  • 顛末書と始末書・報告書の違いと、どちらを求めるべきかの判断基準
  • 顛末書に入れる8項目と、事実・推測・意見を書き分ける3層ルール
  • 社内向け3本・社外向け3本、そのままコピーして使える例文
  • 顛末書と混同しやすい「法定の報告」(個人データの漏えい・労働災害)の期限と根拠条文
  • 時系列メモから顛末書のドラフトをAIに書かせるプロンプトと、うまくいかないときの直し方

顛末書とは|始末書・報告書との違いを最初に押さえる

顛末書の「顛末」は、物事の始めから終わりまでという意味です。つまり顛末書は、事案の発生から収束までの経過を時系列で報告する文書を指します。ここに謝罪文としての性格を持ち込むと、文書の役割が濁ります。

顛末書・始末書・報告書の違い

文書

主な目的

謝罪・反省

典型的な使う場面

宛先

顛末書

事案の経過と原因を事実として報告する

含めない(社外向けは冒頭のお詫びのみ)

事実関係の把握が先に必要な段階

上長・社内関係部署/取引先

始末書

本人の非を認めさせ、反省を表明させる

含める

就業規則違反が確認でき、処分を記録に残す段階

会社(人事・経営)

報告書

業務の状況・結果を定期的に共有する

含めない

日常業務、トラブル以外も含む

上長

実務での順序は、まず顛末書で事実を固め、処分を検討する段階になって初めて始末書に切り替えるのが安全です。事実関係が確定しないうちに謝罪文を書かせると、本人の記憶頼みの不正確な記述が「会社が認定した事実」として残ってしまいます。提出させる側の法的な線引きについては、始末書の書き方とケース別テンプレートの記事で、懲戒との関係を含めて整理しています。

顛末書は法定書類ではない。それでも様式を統一する理由

顛末書には、記載事項を定めた法律も、届出先も存在しません。労働基準法第89条は就業規則に「表彰及び制裁の定めをする場合においては、その種類及び程度に関する事項」を記載するよう求めていますが(e-Gov法令検索:労働基準法)、これは制裁の話であり、顛末書そのものを義務づけるものではありません。

それでも様式を統一すべき理由は3つあります。第一に、同じ型で書かせると事案どうしの比較ができ、再発防止の議論が具体的になること。第二に、後から監査・調査・訴訟で参照されたときに、記述の抜けが少ないこと。第三に、書く側の負担が減ることです。白紙から書かせると、書ける人と書けない人の差がそのまま文書の品質差になります。

顛末書に入れる8項目|漏えい報告の項目立てを骨格として借りる

骨格を自前で考える必要はありません。個人情報保護法施行規則第8条は、個人データの漏えい等を個人情報保護委員会に報告する際の記載事項を定めており、これが「事故を第三者に説明するときに何を書けば足りるか」の公式な答えになっています。項目は、概要/漏えいした項目/対象となる本人の数/原因/二次被害またはそのおそれ/本人への対応状況/公表の状況/再発防止措置、の8つです(e-Gov法令検索:個人情報の保護に関する法律施行規則)。

この項目立ては、漏えい以外の事案にもそのまま流用できます。実務ではこれを社内文書用に読み替えて使います。

顛末書8項目の一覧

項目

書く内容

よくある失敗

1. 件名・提出日・所属氏名

「◯◯に関する顛末書」と事案が特定できる件名

「お詫びについて」など事案が分からない件名

2. 概要

3〜4文で全体像。読み手が最初の30秒で把握できる要約

いきなり詳細な経緯から始める

3. 発生日時・発覚日時・発覚経路

発生と発覚を必ず分けて書く

両者を混同し、対応の遅れが見えなくなる

4. 経過(時系列)

日時+主体+行為の形で箇条書き

段落文で書き、順序と担当が読み取れない

5. 影響範囲

件数・金額・相手先数など数えられる形で

「軽微です」など主観的な評価だけ

6. 原因

直接原因と背景要因を分けて記載

「確認不足」で止まり、仕組みの話に届かない

7. 実施済みの対応

誰が、いつまでに、何を完了したか

「対応中」のまま期日がない

8. 再発防止策

担当者・期限・確認方法をセットで

「今後は注意します」で終わる

事実・推測・意見を分ける3層ルール

顛末書の品質を決めるのは、文章のうまさではなく記述の層を混ぜないことです。書く前に、手元の材料を次の3層に仕分けます。

  • 事実:ログ・メール・伝票・システムの記録で裏が取れるもの。「10時15分に送信済みフォルダに◯◯宛のメールが記録されている」
  • 推測:裏が取れないが合理的に考えられるもの。「宛先候補の表示順が変わったため誤選択したと考えられる」
  • 意見・評価:書き手の判断。「チェック体制が形骸化していた」

本文では、事実を先に置き、推測には「〜と考えられる」「〜の可能性がある」と明示し、意見は原因・再発防止策のセクションにまとめます。この分離ができていない顛末書は、後から第三者が読んだときに、どこまでが確認済みなのか判別できません。逆に言えば、この3層が分かれているだけで文書の信頼度は目に見えて上がります。

時系列は表で固めてから文章にする

いきなり文章を書き始めると、順序が前後したり、対応の空白時間が隠れたりします。先に「日時/主体/行為/根拠資料」の4列の表を埋め、埋まらないセルが出たらそこが調査の残タスクです。空白のまま提出せず、「◯月◯日◯時時点で未確認」と書く方が、後から見て誠実な記録になります。

【社内向け】顛末書のテンプレートと例文3本

社内向けは、お詫びの前置きを最小限にし、事実と再発防止に紙面を割きます。A4用紙1枚に収めるのが目安です。

例文1:メールの誤送信

【件名】顧客宛メール誤送信に関する顛末書
【提出日】2026年◯月◯日 【所属・氏名】◯◯部 ◯◯

1. 概要
 2026年◯月◯日、当部が【顧客A】宛に送付予定であった見積書を、
 誤って【顧客B】宛に送信しました。添付ファイルには【顧客A】の
 社名・担当者名・取引金額が含まれます。送信から28分後に発覚し、
 同日中に【顧客B】へ削除を依頼、削除完了の連絡を受領しました。

2. 発生・発覚
 発生:◯月◯日 10:15(送信時刻/送信済みメールの記録による)
 発覚:◯月◯日 10:43(【顧客B】担当者からの返信により)

3. 経過
 10:15 ◯◯が【顧客B】宛に見積書を添付し送信
 10:43 【顧客B】担当者より「宛先違いでは」との返信を受領
 10:50 上長◯◯へ報告、送信済みメールを確認し誤送信を確定
 11:20 【顧客B】へ電話。削除を依頼し、口頭で了承を得る
 13:05 【顧客B】より削除完了の連絡をメールで受領
 15:00 【顧客A】へ経緯を報告

4. 影響範囲
 誤送信先:1社1名。含まれた個人データ:担当者氏名・部署・
 メールアドレス(各1件)。二次利用・外部流出は確認されていない。

5. 原因
 直接原因:メールソフトの宛先補完で表示された候補のうち、
      1行下の【顧客B】を選択した。
 背景要因:外部宛の添付メールについて、送信前の第三者確認を
      運用ルールとして定めていなかった。

6. 実施済みの対応
 ・【顧客B】への削除依頼と完了確認(◯月◯日完了)
 ・【顧客A】への報告と謝罪(◯月◯日完了)

7. 再発防止策
 ・外部宛の添付メールは送信前に同部署員の確認を必須とする
  (◯月◯日運用開始/責任者:◯◯課長)
 ・宛先の自動補完機能を無効化する(◯月◯日までに情報システム部が設定)

ここが差になる点:発生と発覚を分けて書き、発覚から一次対応までの経過時間が読み取れるようにしています。この2つを一緒にすると、対応が速かったのか遅かったのかが評価できません。

例文2:入金・請求処理のミス

【件名】【取引先C】宛請求書の金額誤りに関する顛末書

1. 概要
 ◯月分の【取引先C】宛請求書について、単価を旧単価で計上したため、
 本来【金額A】円のところ【金額B】円で請求しました。差額【金額C】円。
 先方の照会により発覚し、赤伝処理のうえ再発行済みです。

2. 発生・発覚
 発生:◯月◯日(請求書発行日)
 発覚:◯月◯日(【取引先C】経理部からの照会メール)

3. 経過
 ◯月◯日 請求書を発行・送付(担当:◯◯)
 ◯月◯日 【取引先C】より金額相違の照会を受領
 ◯月◯日 契約書および単価改定通知を確認し、旧単価適用を確定
 ◯月◯日 赤伝を起票、正しい単価で再発行し送付

4. 影響範囲
 対象:1社1件、1か月分。過月分への波及の有無:◯月〜◯月分を
    全件突合し、他に相違がないことを確認済み。
 入金への影響:支払期日を◯月◯日へ変更いただくことで合意。

5. 原因
 直接原因:単価改定の反映漏れ。改定通知の受領後、販売管理システムの
      マスタを更新しないまま請求処理を行った。
 背景要因:単価改定の通知が営業部止まりとなり、経理部への
      共有手順が定まっていなかった。

6. 実施済みの対応
 ・赤伝処理および再発行(◯月◯日完了)
 ・過去3か月分の全件突合(◯月◯日完了、相違なし)

7. 再発防止策
 ・単価改定時は営業部が経理部へ改定通知を回付し、経理部が
  マスタ更新の完了を返信する(◯月◯日運用開始)
 ・月次請求前に、当月改定分の一覧とマスタを照合する
  (担当:◯◯/毎月◯日)

ここが差になる点:影響範囲に「過去分を何か月遡って全件突合したか」を書いています。1件の誤りを報告するだけでなく、同種の誤りが他にないことまで確認して初めて、読み手は安心できます。

例文3:作業の遅延・納期遅れ

【件名】◯◯業務の納期遅延に関する顛末書

1. 概要
 ◯月◯日納期の【業務名】について、◯日遅延して◯月◯日に完了しました。
 遅延は【担当者】1名への作業集中と、前工程からのデータ受領遅れが
 重なったことによります。

3. 経過(抜粋)
 ◯月◯日 前工程部門からのデータ受領予定日(実際は未受領)
 ◯月◯日 催促のうえデータを受領(予定より◯営業日遅れ)
 ◯月◯日 担当者が上長へ納期遅延の見込みを報告
 ◯月◯日 関係部署へ遅延を連絡、新納期を◯月◯日に設定
 ◯月◯日 作業完了

5. 原因
 直接原因:前工程からのデータ受領が◯営業日遅れた。
 背景要因:受領遅れが発生した時点でエスカレーションする基準が
      なく、担当者の判断で待機していた。

7. 再発防止策
 ・前工程の受領期限を1営業日超過した時点で上長へ報告する基準を
  業務手順書に明記(◯月◯日改定)
 ・進捗表に「受領予定日/実受領日」列を追加し、週次で確認

ここが差になる点:原因を「担当者の判断が遅かった」で終わらせず、判断基準が存在しなかったという仕組みの話に落としています。個人の資質に原因を求めた顛末書は、再発防止策が「注意する」しか書けなくなります。

【社外向け】取引先に出す顛末書のテンプレートと例文3本

社外向けは、社内向けの8項目に加えて、冒頭のお詫び・相手方への影響・今後の連絡方法を明記します。ただし過度な謝罪表現で事実を薄めないことが重要です。相手が知りたいのは、被害の範囲と、いつ何が終わるのかです。

例文4:誤請求のお詫びと顛末

【宛先】【取引先名】 【部署名】 【担当者名】様
【件名】◯月分ご請求金額の誤りに関するご報告とお詫び

 平素より格別のご高配を賜り厚く御礼申し上げます。
 このたび、◯月分のご請求書につきまして、弊社の処理誤りにより
 誤った金額をご請求いたしました。多大なご迷惑をおかけしましたことを
 深くお詫び申し上げます。経緯および対応につき、下記のとおり
 ご報告申し上げます。

1. 誤りの内容
 ご請求額 誤:【金額B】円 / 正:【金額A】円 (差額【金額C】円)
 対象   ◯月分ご請求書(請求書番号:◯◯)

2. 発生の経緯
 ◯月◯日 単価改定の社内反映が漏れたまま請求処理を実施
 ◯月◯日 貴社より金額相違のご指摘を頂戴
 ◯月◯日 弊社にて事実を確認、誤請求を確定

3. 貴社への影響とご対応のお願い
 ・訂正後の請求書を◯月◯日付で再発行し、本状に同封いたします
 ・当初のご請求書(番号:◯◯)は破棄をお願いいたします
 ・お支払期日は◯月◯日へ変更させていただきます

4. 過去分の確認結果
 ◯月分から◯月分までの全ご請求について照合し、
 本件以外に相違がないことを確認いたしました。

5. 再発防止策
 単価改定の社内回付手順を定め、請求処理前にマスタとの照合を
 行う運用を◯月◯日より開始いたしました。

 このたびはご迷惑をおかけし、誠に申し訳ございませんでした。
 今後このようなことのないよう、再発防止に努めてまいります。

例文5:個人情報の漏えいに関する報告

【件名】個人情報の漏えいに関するご報告とお詫び

1. 発生した事象
 ◯月◯日、弊社担当者が貴社ご担当者様の情報を含むファイルを
 誤って第三者宛に送信いたしました。

2. 漏えいした情報の項目と件数
 項目:氏名、会社名、部署名、メールアドレス
 件数:◯件(うち貴社関係分◯件)
 要配慮個人情報:含まれておりません

3. 発覚の経緯と時刻
 ◯月◯日◯時◯分 送信
 ◯月◯日◯時◯分 送信先からのご連絡により発覚

4. 二次被害の有無
 現時点で、当該情報の外部公開・不正利用は確認されておりません。
 送信先より削除完了のご連絡を◯月◯日に受領しております。

5. 監督官庁への対応
 個人情報保護法に基づく報告の要否を確認し、
 【要否と対応状況】

6. 再発防止策
 【具体策・開始日・責任者】

7. 本件に関するお問い合わせ先
 【部署名・担当者名・電話番号・メールアドレス・受付時間】

ここが差になる点:漏えい事案の社外報告は、書く項目を自分で考えず、施行規則第8条の項目立てに合わせておくと抜けが出ません。監督官庁への報告が必要になった場合も、同じ材料をそのまま使えます。

例文6:納品物の不具合

【件名】納品物の不具合に関するご報告とお詫び

1. 不具合の内容と発生範囲
 【製品・サービス名】【ロット・対象範囲】【症状】【影響を受ける件数】

2. 発生原因(現時点で判明している範囲)
 直接原因:【 】
 ※調査継続中の事項:【 】(◯月◯日までに追加ご報告いたします)

3. 実施済みの対応
 ◯月◯日 出荷停止/サービス停止
 ◯月◯日 対象範囲の特定完了
 ◯月◯日 代替品の手配

4. 今後の対応スケジュール
 【対応内容】【完了予定日】【ご連絡方法】

5. 再発防止策
 【工程・検査の見直し内容】【開始日】【責任者】

調査が終わっていない段階で報告を求められることは珍しくありません。そのときは「調査継続中」と明記し、次の報告期限を書くのが正解です。分からないことを推測で埋めた顛末書は、後から訂正が必要になり、かえって信頼を損ないます。取引先へ送る連絡文そのものの型は、顧問先へのチャットワーク返信例文集も参考になります。

顛末書と「法定の報告」を取り違えない

ここが実務で最も事故が起きるところです。社内の顛末書を書いて満足してしまい、期限のある法定報告を落とすケースがあります。顛末書は社内文書、法定報告は別建てと切り分けてください。

個人データの漏えい等|速報と確報の期限

個人情報保護法第26条は、個人データの漏えい等のうち個人の権利利益を害するおそれが大きい事態について、個人情報保護委員会への報告と本人への通知を義務づけています。報告対象となる事態は施行規則第7条で4類型が定められており、要配慮個人情報を含む場合、財産的被害が生じるおそれがある場合、不正の目的による行為である場合、そして本人の数が1,000人を超える場合です。「そのおそれ」がある段階で対象になる点に注意してください。

報告は2段階です。事態を知った後速やかに行う速報と、事態を知った日から30日以内(不正の目的による行為の場合は60日以内)の確報で、いずれも施行規則第8条に定めがあります。実際の報告窓口と要件の解説は、個人情報保護委員会「漏えい等の対応とお役立ち資料」に集約されています。

社内でメール誤送信の顛末書を書くときは、同時にこの4類型に当たるかを判定する運用にしておくと落としません。日常の防止策としては、生成AI利用時の情報漏洩対策の手順も合わせて整えておくと、事案そのものを減らせます。

労働災害|労働者死傷病報告

労働者が労働災害等により死亡または休業した場合、事業者は労働安全衛生規則第97条に基づき、所轄労働基準監督署長へ労働者死傷病報告を提出しなければなりません(e-Gov法令検索:労働安全衛生規則)。休業4日以上は遅滞なく、休業4日未満は四半期ごとにその期間の最後の月の翌月末日までとされています。

あわせて実務上の変更点として、労働者死傷病報告を含む一部の報告は2025年(令和7年)1月1日から電子申請が義務化されています(厚生労働省「主要様式ダウンロードコーナー」)。紙の様式を前提にした社内手順書が残っている場合は、この機会に見直しておくのが安全です。

社内文書と提出書類を混ぜない

顛末書に法定報告の内容を書き足すのではなく、顛末書を「事実の一次資料」として置き、そこから各提出書類を派生させる形にします。1つの事実台帳から複数の宛先向け文書を作る構造にしておけば、記述の食い違いが起きません。

AIで顛末書の下書きを作る手順とプロンプト

顛末書で時間を食うのは、書く作業そのものより「散らばったメモを時系列に並べ直す」工程です。ここは生成AIが得意な領域なので、下書きまでを任せて、判断が必要な部分に人手を残す配分が現実的です。

手順1:時系列メモを顛末書のドラフトにする

あなたは企業の総務担当者です。以下のメモをもとに、社内提出用の
顛末書のドラフトを作成してください。

【制約】
- 見出しは「概要/発生・発覚/経過/影響範囲/原因/実施済みの対応/
  再発防止策」の7つとする
- 経過は「日時+主体+行為」の形式で1行ずつ箇条書きにする
- メモに書かれていない事実は絶対に補わない。不明な箇所は
  「(要確認)」と明記する
- 謝罪・反省の表現は入れない。事実の記述のみとする
- 推測を書く場合は必ず「〜と考えられる」の形にし、事実と区別する

【メモ】
【ここに時系列のメモを貼る】

手順2:事実と推測が混ざっていないか点検させる

以下の顛末書の草案について、各文を「事実」「推測」「意見・評価」の
3つに分類し、表形式で出力してください。

そのうえで、次の2点を指摘してください。
1. 事実として書かれているが、裏付け資料が示されていない記述
2. 推測であるにもかかわらず断定形で書かれている記述

【草案】
【ここに草案を貼る】

手順3:再発防止策を仕組みの言葉に置き換えさせる

以下の再発防止策について、「担当者の注意・意識」に依存している
記述を特定し、それぞれを次の3要素を含む形に書き換えてください。
 (1) 誰が (2) いつ・どの頻度で (3) 何を確認するか

書き換え案は各項目2案ずつ出し、運用コストが低い順に並べてください。

【再発防止策】
【ここに貼る】

うまくいかない例と直し方

うまくいかない例

何が起きているか

直し方

「顛末書を書いて」とだけ指示する

もっともらしい創作が混ざり、実際には確認していない事実が入る

「メモにない事実は補わない」「不明は(要確認)と書く」を制約に入れる

謝罪文のような文章が返る

顛末書と始末書が学習データ上で混在している

「謝罪・反省の表現は入れない」を明示する

経過が段落文にまとめられる

読みやすさを優先して情報が要約されている

「日時+主体+行為の形式で1行ずつ」と出力形式を指定する

再発防止策が「注意を徹底する」になる

入力メモに仕組みの情報がない

手順3のプロンプトで、担当者・頻度・確認方法の3要素を要求する

AIに任せてはいけない部分

3つあります。事実認定(ログや伝票との突合は必ず人が行う)、法定報告の要否判断(前章の類型に当たるかは条文と公式ガイドで確認する)、懲戒処分に踏み込む記述(顛末書に処分の見込みを書かせない)です。とくに期限や要件の数値は、モデルが古い情報を保持していることがあるため、必ず一次資料で裏を取ってください。

汎用の生成AIでもここまでは十分に実用的です。ただし顧問先や従業員の情報を扱う以上、入力データの取り扱いが業務要件に合っているかは別途確認が必要です。士業AIは、経理・総務のバックオフィス業務を想定した業務効率化AIを用意しており、事務スタッフ向けの業務効率化AIでは、顛末書のような社内文書の下書き・体裁の統一・チェックリスト化をまとめて扱えます。

よくある質問

顛末書は手書きでないといけませんか

法律上の決まりはなく、PC作成で問題ありません。会社が手書きを指定している場合はそれに従います。指定がないなら、検索性と再利用性を考えてPC作成が実務的です。

顛末書と始末書、どちらを求めるべきですか

事実関係が固まっていない段階、または本人の落ち度が明確でない段階では顛末書です。就業規則の懲戒事由に該当することが確認でき、処分として記録に残す段階になってから始末書に切り替えます。

顛末書はどのくらいの長さが適切ですか

社内向けはA4用紙1枚が目安です。社外向けで調査項目が多い場合も、本文は1枚に収め、詳細な調査結果は別紙に分けると読み手の負担が下がります。

顛末書はいつまで保管すべきですか

顛末書自体に法定の保存期間はありません。ただし、労務関係の記録として扱うのか、品質記録として扱うのか、社内の文書管理規程で分類を決めておくべきです。分類が決まっていないと、必要なときに出てこない一方で、不要なものが個人情報を含んだまま残り続けます。

提出を拒否された場合はどうすればよいですか

事実の報告を求めるだけの顛末書は、業務命令として求める余地が比較的広いと考えられます。一方、反省や謝罪といった内心の表明を求める始末書は、強制に限界があります。事実確認が目的なら顛末書に切り替え、聞き取り内容は会社側で別途記録に残すのが現実的です。

まとめ

顛末書は、謝らせるための文書ではなく、事実を固めるための文書です。8項目の骨格を社内で統一し、事実・推測・意見を分けて書く。その一次資料をもとに、社外向けの報告書や法定の報告を派生させる。この順序が守れていれば、事案そのものは避けられなくても、対応の質は安定します。

そして、期限のある法定報告だけは記憶で処理しないことです。個人データの漏えいは施行規則第7条の4類型と30日/60日の確報期限、労働災害は労働安全衛生規則第97条と電子申請の義務化。この2つは顛末書とは別建てで、チェックリストに載せておいてください。

参考文献

FREE TRIAL

士業AIで業務を効率化しませんか?

税務・会計・法務の専門業務を AI がアシスト。 まずは無料でお試しいただけます。

無料で試す

クレジットカード不要・数分で開始