AIが書いた提案書を、強く売る文章から「安全を伝える報告」へ直した

設備点検で見つかった不備を、建物の管理者へ説明する担当者の仕事を支援しました。一覧から報告と改善案をまとめる際には、状況を分かりやすく伝えながら、過度に不安をあおらない文章にする必要がありました。

AIには、不備一覧や受け取った写真をもとに、説明資料の下書きを作らせます。そのために、元資料にない状態を推測しないこと、改善案には確認済みの文面を使うことを条件として整理しました。

現場のレビューで直したのは、危険性をどれだけ強く訴えるか、という部分です。実際に確認した不備を伝えることと、相手の不安を大きくして修繕を促すことは、同じではありません。

AiWiLLは、不備一覧からレポートを生成する流れを実演し、担当者と文章を見直して、写真の扱い・改善文の選び方・渡し方を整理しました。ここで残ったのは、生成したレポートと説明の基準です。送付後の反応や営業成果は、今回の記録では確認できていません。

最初に直したのは、章立てよりも伝え方だった

打ち合わせでは、不備一覧のPDFを取り込み、レポートにする流れを実演しました。本文の構成だけでなく、法令の条文や損害の想定をどう書くか、という話になりました。

当時の記録では、厳密な条文の記載や、強い損害シミュレーションをそのまま使わず、危険性を穏やかに伝える方向へ調整しています。工事の時期も、こちらで細かく決めたように書かない方針にしました。

安全上の注意を弱めるためではありません。点検で確認したことと、そこから説明できる範囲を揃えるためです。専門的に見える文章ほど、根拠の確認が必要になります。

続くレビューでは、不備の写真を組み込む話が出ました。どこの何が不良なのかが見えれば、管理者が状況をつかみやすくなります。

後に整えた要件では、写真がないときは写真の欄そのものを省く形にしました。写真を受け取っていないのに、写真がある前提の説明を残さないためです。

未点検の箇所も、未点検という事実までにとどめています。見ていない場所の状態を想像して、不備を増やしてしまっては困ります。

こうした制約は、最後に注意書きを付ければ済むものではありません。入力資料にない内容を本文へ出さない、という生成時の条件にします。

改善提案の文章については、担当者側で検討した文面を使い、条件に合う場合に出す構成を決めました。

残った要件では、設備名と不良内容がマスタの記載に一致したものだけを採用します。該当するものがなければ、改善提案の節は省く。AIが「似た内容だから」と補う余地を、ここでは小さくしています。

この仕組みには、不一致なら必要な提案が出ない可能性もあります。自由な補完を減らす代わりに、人が未一致を確認してマスタを整える仕事が残ります。すべての説明をAIへ任せる設計ではありませんでした。

打ち合わせで選んだのは、営業担当者の個別提案だけに使う形ではなく、メンテナンス側から点検報告と一緒に届ける形で試すことでした。

誰が、どんな文脈で渡す資料なのかが決まると、文章の役割も変わります。読んだ相手が、何が起きていて、どこから相談すればよいかを理解できること。そのための報告書として整えます。

ただし、今回読み返した記録では、実際の送付後の反応や修繕受注、継続利用までは確認できません。残っているのは、レビューで決めた方針と、生成したレポートです。

過去の出力には、一般化の強い法的な説明や、期待効果を言い切る文章も残っています。要件を整えたことを、過去の全出力が基準を満たした証拠にはしていません。

以下は、今回のやり取りから整理した、提出前の確認項目です。

AIの提案書づくりで残したいのは、毎回よく売れそうな言葉を選ぶ技術だけではありません。何を根拠に、どこまで言うかという、自社の説明の基準です。

その基準を渡したうえで、生成した一件を担当者が読む。違う表現が出たら直し、次に参照する条件へ戻す。今回のレポートづくりは、その往復を具体化する仕事になりました。

報告書の作成、見積りの下書き、問い合わせ返信、社内資料の整理。いま困っている仕事を一つ選び、必要な資料と、人が確認する範囲から整理します。

先に現在地を見たい人は、AIに任せる準備度の診断もあります。