事故の経緯報告書を時系列の事実でまとめる

経緯書を書く際、人が最も犯しやすいミスは「弁解」と「事実」を同じ文に混ぜてしまうことです。「急いで処理しようとして過去のファイルを開いてしまいました」と書くと、読み手は事実関係の確認を後回しにして態度や言い訳に目を向け始めます。このプロンプトの役割は、その2つを構造的に切り離すことです。

手順を分割して指示しているのはそのためです。一度に「経緯書を書いて」と頼むと、モデルは整理・判断・文章作成を一括で処理しようとし、記憶にない時刻をそれらしくでっち上げてしまいます。整理 → 事実と推測の分離 → 作文 → 原因の整理と区切ることで、中間結果が可視化され、（推測）とマークされた箇所だけを重点的に確認できます。

制約の段落では、感情表現や責任転嫁を防ぎます。事故報告書において他部署を原因として名指しした一文は、事実の真偽に関わらず文書全体の目的を歪めてしまいます。法的な判断や処分の言及を禁じているのも同様の理由です。それらを判断するのは報告書を受け取る側の役目です。

最後に「事前に質問させる」ステップを入れたのは時刻の整合性のためです。メモの時刻は抜けていることが多いですが、モデルは空白を見つけると前後の文脈から勝手に時刻を創作しがちです。ひとつの捏造された時刻が文書全体の信用を損なうため、勝手に埋めさせず質問させる設計が安全です。

出力結果はお詫び文のような内容になってしまいます。「深く反省しており、二度とこのようなことがないよう努めます」といった文面が大半を占め、肝心の「何時何分に何をしたか」が本文中に散らばり、監査担当者が時系列に直す手間が発生します。抜けていた時刻もそれらしい数字で勝手に埋められるため、後から送信ログと照合した際に食い違いが生じ、文書を一から書き直すことになります。

ステップごとに結果を出力するよう指示しても、最終文書だけを一気に出力してしまうモデルがあります。その場合は「まずはステップ2までを出力して」と区切って指示してください。事前質問をスキップして作成に進む場合もあるため、生成結果に [要確認] のプレースホルダーが一切ない時は、時刻などが勝手に補完されていないか確認してください。