不具合報告書の書き方｜AIに下書きさせる手順

客先から不具合の連絡が入り、3日以内に報告書を出すことになった。原因の見当はついているものの、文書にまとめる時間が取れない。現場のメモと測定値は手元にあるので、あとは形にするだけ——という場面です。

報告書の文章化は、生成AIに任せてよい仕事に入ります。ただしそのまま提出できる下書きは返ってきません。理由は、AIが観測した事実と、こちらの推定を区別せずに書くためです。この記事では、報告書に必要な項目を整理したうえで、どこまで任せてよいのかを具体的に見ていきます。

AIに下書きさせてよい場面

報告書づくりでAIが効くのは、次のような場面です。

• 材料はそろっているが文章になっていないとき：現場のメモ、測定値、時系列の記録が手元にある
• 提出先ごとに書き分けるとき：同じ内容を社内向けと客先向けで整える
• 抜けを確認したいとき：項目立てを作らせて、埋まっていない欄を洗い出す

共通しているのは、中身の判断は自分が済ませているという点です。原因の特定も対策の決定も終わっていて、残っているのが文章化だけなら任せられます。

NG例（△）: 原因がまだ分からない段階で、報告書を書かせる使い方です。AIは材料が足りなくても、それらしい文章で空欄を埋めてきます。「〜が原因と考えられる」という一文が、誰も確認していない推測のまま文書に残ります。

もうひとつのNG例が、時系列をAIに整理させることです。いつ発見し、いつ止め、いつ客先へ連絡したかは記録から拾うものです。順序を推測で埋められると、後から食い違いが出ます。

不具合報告書に必要な6項目

様式は会社ごとに違いますが、中身はおおむね次の6つに収まります。この順序で埋めていきます。

項目	書く内容
①発生状況	いつ・どこで・何が・どれだけ。発見の経緯
②影響範囲	対象ロット・出荷済みの数量・客先での状況
③暫定処置	止血のために今すぐやったこと
④原因	調査で確認できた発生原因と流出原因
⑤恒久対策	再発を止めるための仕組みの変更
⑥水平展開	同じ原因が他にないかの確認結果

この6つのうち、AIが枠として作れるのは項目立てまでです。中身は自社の調査結果でしか埋まりません。品質文書全般で同じ構造になっているので、FMEAやQC工程図での考え方は品質文書をAIに下書きさせる｜FMEAとQC工程図にまとめました。

発生原因と流出原因を分ける

④でつまずきやすいのが、原因を1つしか書かないことです。品質の世界では2つに分けます。

• 発生原因：なぜ不良が作られたのか
• 流出原因：なぜ検査で止められず客先まで出たのか

この2つは別の問題で、対策も別々に立てます。金型の摩耗で寸法が外れたのが発生原因なら、対策は金型管理です。全数検査をしていたのに見逃したのが流出原因なら、対策は検査方法です。片方だけ直しても、もう片方は残ります。

AIに書かせると、この2つが1つの原因欄にまとめられがちです。項目を分けた様式を先に渡しておくと防げます。検査の位置づけは検査の種類｜受入・工程内・出荷の違いと使い分けで整理しています。

事実と推定を分ける

ここがこの記事の中心です。報告書でいちばん重要なのは、どこまでが確認した事実で、どこからが推定かの境目です。そしてAIの下書きは、この境目をほぼ確実に溶かします。

理由は単純で、AIは自然に読める文章を作るからです。「確認した」と「と思われる」が混ざった文章より、すべて断定調のほうが読みやすく仕上がります。読みやすさを優先した結果、確認していないことまで確認したように書かれます。

下書きに起こりやすい形

ここから先は、起こりやすいパターンを説明のために組み立てた例です。実際にAIへ入力して得た出力ではなく、事案も架空のものです。現場のメモにこう書かれていたとします。

8/12 14時ごろ、受入検査で外径のはみ出しを3個発見。同ロットを全数確認して計7個。金型の摩耗ではないかと班長が言っている。前回の金型交換は6月。

このメモを貼り付けて、こう頼んだとします。

このメモをもとに、客先提出用の不具合報告書を書いてください。

頼み方としては自然です。しかしこの一文には、様式も、事実と推定の扱いも指定されていません。指定しなければ、AIは読みやすさを優先します。結果として次のような文になりがちです。

本不具合は金型の摩耗により発生したものです。前回の金型交換から約2か月が経過しており、摩耗が進行していました。

読みやすい文章です。しかし元のメモにあったのは「班長がそう言っている」という段階の話で、金型を測って摩耗を確認したとは書かれていません。「〜ではないか」が「〜により発生した」に変わり、「6月に交換」が「摩耗が進行していました」という観測結果に変わっています。

この文章を客先に出すと、次の会議で「金型の摩耗量はいくつでしたか」と聞かれます。測っていなければ、そこで報告書全体の信頼が落ちます。

直すとこうなる

8月12日14時ごろ、受入検査にて外径寸法の規格外品を3個発見。同一ロットを全数確認し、計7個の規格外品を確認しました（確認済みの事実）。
発生原因は金型の摩耗と推定しています。金型の実測は8月14日に予定しており、結果は追って報告します（推定・確認中）。

長くなりますが、読んだ人が「どこを信じてよいか」を判断できます。品質の文書は読みやすさより、根拠の所在がはっきりしていることが優先です。

現場で確認した事実だけを事実として書く、という姿勢そのものは三現主義とは｜現場・現物・現実で原因をつかむの考え方と同じです。

依頼文で境目を守る

後から直すより、最初の依頼文で指定しておくほうが手戻りが減ります。指定するのは次の3つです。

指定すること	書く内容
①様式	使う項目名を並べる（発生状況・影響範囲・暫定処置…）
②事実と推定の扱い	メモにない情報を補わない。推定は推定と分かる書き方にする
③足りない欄の扱い	埋められない欄は空欄のまま残し、何が足りないかを挙げる

3つを入れると、たとえばこうなります。

次のメモをもとに、不具合報告書の下書きを作ってください。項目は「発生状況／影響範囲／暫定処置／発生原因／流出原因／恒久対策／水平展開」です。
メモに書かれていない情報は補わないでください。推定にあたる内容は断定せず、推定と分かる書き方にしてください。
情報が足りず埋められない項目は空欄のままにし、何が足りないかを最後に挙げてください。

効くのは③です。空欄を許可しないと、AIは何かしらの文で埋めようとします。「埋められないものは埋めなくてよい」と伝えておくと、足りない情報のほうが返ってくるので、次に何を調べればよいかが分かります。

覚えておくのはこの3つの並びだけで、文言は毎回その場の言葉で構いません。そのまま使い回す呪文にすると、様式が変わったときに合わなくなります。プロンプトを型で持つ考え方は品質データをAIに渡す前に｜プロンプトの型と注意点で詳しく扱いました。

暫定処置と恒久対策を書き分ける

③と⑤も混ざりやすい組み合わせです。目的が違います。

	暫定処置	恒久対策
目的	今の被害を止める	再発を止める
時間軸	即日〜数日	数週間〜
例	該当ロットの出荷停止・全数選別	金型の交換基準を管理項目に追加

AIに「対策」とだけ伝えると、この2つが1つの欄にまとめられます。すると全数選別が恒久対策として書かれるという形になりがちです。選別は人手で止めているだけなので、やめた瞬間に元へ戻ります。

恒久対策は、仕組みを変えたかどうかで判断します。作業者の注意喚起や教育の徹底は、多くの場合まだ仕組みになっていません。人が気をつけなくても止まる形にする考え方はポカヨケとは｜人のミスを止める仕組みと現場の事例で扱っています。決めた対策を維持する仕組みは標準化と小集団活動とは｜目的と進め方の範囲です。

水平展開はAIには出せない

⑥の水平展開は、同じ原因が他の工程・他の製品にも潜んでいないかを確認した結果を書く欄です。

ここはAIが原理的に埋められません。自社にどんな工程があり、どの製品が同じ金型構造を使っているかを知らないためです。AIに書かせると「同種工程についても確認を行いました」という中身のない一文が入ります。確認していないなら空欄のまま出すほうが誠実です。

この構造は、FMEAで検出度をAIが埋められないのと同じです。自社のデータを見ないと出せない欄は、AIの担当ではありません。

対策を打って終わりにしない

報告書を出した時点では、恒久対策はまだ「実施予定」か「実施直後」のはずです。効果が出たかどうかは、一定期間動かしてみないと分かりません。多くの会社で、効果を確認してから案件をクローズする手順になっています。

確認の材料は、対策後の不良率や測定値です。ばらつきが落ち着いたかを見るなら管理図が向いています。判定の考え方は管理図の異常判定ルール｜Western Electric Rulesの読み方で扱っています。この効果確認の欄も、AIには埋められません。対策後のデータを持っているのは自社だけです。

AIに渡すもの・渡さないもの

報告書には客先名や型番が入ります。そのまま貼り付けてよいかは会社の規程によるため、先に確認が要ります。

実務で現実的なのは、固有名詞を記号に置き換えて渡し、返ってきた文章に自分で戻すやり方です。「客先A」「製品B」「工程1」で渡しても、文章の構成を組み立てるうえで支障はありません。

渡してよい形に加工する手順と、社内規程の確認項目は品質データをAIに渡す前に｜プロンプトの型と注意点にまとめました。公表前の不具合情報はとくに扱いが厳しいので、確認を飛ばさないでください。

提出前に確認する3つの問い

返ってきた下書きは、次の3つを順に当てます。

• この文の根拠はどの記録にあるか：答えられない文は、推定と明記するか削る
• 断定になっている箇所は本当に確認済みか：「〜した」「〜である」で終わる文をすべて見る
• 対策は仕組みが変わっているか：人の注意に頼る対策が恒久対策の欄に入っていないか

1つ目がいちばん効きます。先ほどの例なら、「金型の摩耗により発生した」の根拠を問うた時点で、まだ測っていないと分かります。この1問を飛ばすと、推定が事実として客先に届きます。

原因を掘り下げる作業そのものは、報告書を書く前に終えておきます。手順はなぜなぜ分析のやり方｜5回のなぜで真因にたどり着く手順、原因の広げ方は特性要因図の作り方｜4Mで原因を整理する手順にまとめています。改善活動全体の流れはQCストーリーとは｜問題解決型の8ステップが土台です。

よくある質問（FAQ）

Q. 報告書の文章をAIに書かせたことは、客先に伝える必要がありますか？

作成手段より、書かれている内容の根拠を説明できるかが問われます。事実と推定を分け、根拠を自分で確認した文書なら、それは自社が作った報告書です。逆に根拠を説明できない文が残っていれば、手書きであっても同じ問題が残ります。

Q. 原因がまだ特定できていない段階で報告書を出すことになりました

その状態を正直に書くのが正解です。「調査中」と書いてある報告書は信用を落としません。落とすのは、後から違うと分かる断定です。発生状況・影響範囲・暫定処置までを確定情報として出し、原因と恒久対策は期限を添えて次回報告にする形が実務では通ります。

Q. AIに任せると文章が硬くなりすぎます

提出先を伝えると変わります。客先向けか社内向けかで適切な文体は違うためです。ただし読みやすさを優先しすぎると事実と推定の境目が溶けるので、文体の調整は最後に行い、境目の確認はその後にもう一度してください。

Q. 過去の報告書を読み込ませて、同じ形式で書かせてもよいですか？

様式がそろうため下書きの精度は上がります。ただし過去の報告書には客先名や不具合の詳細が含まれるので、入力してよいかを規程で確認してください。形式だけを真似させたいなら、中身を伏せた空の様式を渡すほうが安全です。

まとめ

• 報告書は6項目。発生状況・影響範囲・暫定処置・原因・恒久対策・水平展開の順に埋める
• 原因は発生原因と流出原因に分ける。対策が別になるため
• AIが最も壊すのは事実と推定の境目。読みやすい断定調に整えられ、確認していないことが確認済みに見える
• 依頼文では「様式」「メモにない情報を補わない」「埋められない欄は空欄で残す」の3つを指定する
• 暫定処置と恒久対策を分ける。全数選別は暫定処置で、恒久対策は仕組みが変わったかで判断する
• 水平展開はAIには出せない。自社の工程構成を知らないため、確認していないなら空欄で出す
• 提出して終わりではなく、対策の効果を確認してからクローズする

材料がそろってからAIに文章化を任せ、事実と推定の境目は自分で引き直す、という分担です。原因を掘り下げる段階から確認したい方はなぜなぜ分析のやり方｜5回のなぜで真因にたどり着く手順、AIに任せてよい仕事の全体像は品質管理でAIを使う｜任せてよい仕事と危険な使い方へ進むと流れがつながります。品質管理を体系的に学び直すなら、レベル別のおすすめ書籍を統計学・実験計画法のおすすめ本まとめで紹介しています。

※ 本記事は特定のAIサービスの推奨・比較を目的とするものではありません。掲載した報告書の記載例およびAIの下書き例は、起こりやすいパターンを解説のために組み立てたものです。実際にAIへ入力して得た出力ではなく、事案も架空のものです。様式・記載事項は会社および客先との取り決めによって異なります。利用にあたっては各サービスの最新の利用規約と、勤務先の情報管理規程を必ずご確認ください。記述は2026年8月時点の一般的な整理です。