工務店・ハウスメーカーの資料送付文をAIで作る 読む理由と該当箇所を案内する

「丁寧な資料送付メールを書いて」と頼むだけでは、AIが顧客の意図を補ったり、施工事例を個別案件へ適用したり、「必ず」「最適」「安心」といった根拠のない表現を加えたりする可能性があります。文章が自然であることと、資料原本に忠実であることは別です。

本記事では、送る資料を担当者が決めた後を対象に、AIへ渡す入力票、初稿用プロンプト、断定が追加された初稿の修正例、送信前の評価表、修正履歴をテンプレートへ反映する基準を扱います。媒体ごとの送付方法や追客業務全体は既公開記事へ分け、この作業に必要な成果物を深掘りします。

01.完成させるのは送付文と根拠記録の一組

資料送付文は、挨拶と添付案内だけで完成とはいえません。受け手が「なぜ届いたのか」「どこを見ればよいか」「資料から何が分かり、何はまだ分からないか」を判断できる必要があります。

一方、顧客へ送る文章だけを保存しても、後からページ番号や表現の根拠を確認できません。実務上の成果物は、顧客向けの送付文と、担当者が確認した根拠記録の一組です。

AIが担うのは、これらの部品を指定された長さと口調で並べ、重複を減らすことです。資料の選定、掲載内容の確認、個別案件へ適用できるかの判断、送信承認は担当者が行います。

資料送付が追客全体のどの接点に当たるか、どの業務をAIへ任せるかは、基幹記事の工務店のAI追客・連絡業務の進め方で確認できます。本記事では、資料が決まった後の文案作成と検証に範囲を限定します。

02.AIに渡す「判断済みの部品」を先に固定する

AIへ入力する情報は、単なる箇条書きではなく、誰が確定した情報なのか、変更してよいのか、未確認なのかが分かる形にします。同じ「土地」という言葉でも、「住宅密集地の土地を検討している」は顧客の発言であり、「二階リビングが適している」は設計判断です。両者を同じ入力欄へ入れると、AIが一続きの事実として扱いやすくなります。

入力する部品は、次の六区分に分けます。

「未確認」と「該当しない」も分けます。敷地の方位が分からないなら「未確認」です。今回の送付文で費用を扱わないと決めたなら、費用欄は「今回の案内対象外」です。空欄だけでは、AIも確認者も、情報がないのか記入漏れなのか判断できません。

確定情報同士に矛盾があった場合の優先順位も決めておきます。顧客管理画面に登録された古い資料名より、送付直前に原本で確認した正式版を優先します。ただし、AIにどちらが正しいか選ばせるのではなく、矛盾を検知した時点で生成を止め、担当者へ戻します。

この流れでは、AIを開く前に主要な判断が終わっています。AIが新しく加えてよいのは、接続表現、段落分け、指定範囲内の言い換えです。顧客の関心、資料の内容、設計上の結論を新しく作ることではありません。

判断済みの部品には、出典も持たせます。「顧客発言」は問い合わせ本文、「資料位置」は送付する原本、「読む観点」は担当者判断というように、確認先を一つずつ付けます。送信前に疑問が生じたとき、AIとの会話履歴ではなく元資料へ戻れる状態にするためです。

03.架空の工務店例068案件を入力票へ落とし込む

ここからは、架空の工務店例068と架空の問い合わせを使って作業を進めます。実在する会社、顧客、施工実績、効果を示すものではありません。

問い合わせ者はWebフォームで、「住宅が近接する土地を検討しており、リビングの明るさと外からの視線が気になる」と記入しました。土地を購入済みか、具体的な敷地が決まっているかは書かれていません。

工務店例068が送る資料は「施工事例集2026年6月版」です。担当者は、住宅が近接する敷地のリビングを扱う事例と、窓と視線の考え方を扱う解説ページを原本で確認しました。ただし、掲載事例と問い合わせ者の検討地が同じ条件であるとは確認できていません。

担当者は、AIを使う前に次の入力票を完成させます。

この入力票では、資料に書かれていることと、担当者が付けた読み方を分けています。「窓と居場所の位置関係を見る」は送付時の案内方針であり、顧客が述べた事実ではありません。「同じ方法が使える」はどちらにも該当せず、個別条件の確認後に行う判断です。

入力票へ顧客名、住所、電話番号を入れなくても、文面の骨格は作れます。AIへ入力する前に固有名詞を「問い合わせ者」「検討地」のような表現へ置き換え、生成に不要な家族事情や土地情報を削ります。完成後、利用を承認された業務環境で宛名を戻します。

個人情報の利用目的や安全管理措置などを検討する一次資料には、個人情報保護委員会「個人情報保護法ガイドライン（通則編）」があります。同ガイドラインは個人情報の取扱いに関する一般的な枠組みを確認する資料であり、特定の生成AIサービスへ特定の情報を入力してよいと一律に認めるものではありません。

実際の入力可否は、利用するサービスの契約条件、保存期間、学習への利用設定、アクセス権、提供関係、社内規程などを確認して決めます。「氏名を消せば必ず安全」とも断定できません。土地の位置や相談内容の組み合わせから個人を識別できる場合もあるため、名前以外の情報も必要性を点検します。

04.初稿用と検査用のプロンプトを分ける

一つのプロンプトへ「書く」「事実確認する」「評価する」をまとめると、AIが自分で加えた表現を自分で正当化することがあります。初稿を作る指示と、入力との差分を検査する指示は分けます。

初稿用プロンプトでは、確定情報、未確認事項、禁止する結論、出力形式を明示します。入力同士に矛盾がある場合は、文章を作らず、不一致を報告させます。

あなたは、工務店の資料送付メールを整える文章作成補助者です。
以下の確定情報だけを使って、メール本文の初稿を作成してください。

【顧客が述べた関心】
住宅が近接する土地を検討しており、リビングの明るさと外からの視線が気になる。

【送付資料】
施工事例集2026年6月版

【最初に案内する箇所】
紙面16〜19ページ、PDF表示18〜21ページ
見出し「住宅が近接する敷地のリビング」

【補助的に案内する箇所】
紙面32ページ、PDF表示34ページ
見出し「窓と視線の考え方」

【見てほしい観点】
窓の大きさだけでなく、窓の位置と人が過ごす場所との関係。

【未確認事項】
検討地が決まっているか、方位、寸法、周辺建物、高低差。

【禁止する結論】
・同じ明るさになる
・外からの視線を防げる
・二階リビングが適している
・同じ設計を再現できる
・費用、性能、工期に関する新しい説明

【次に確認する一問】
検討中の土地が決まっているか。

【出力条件】
・350〜500字を目安にする
・送付理由、第一の該当箇所、見る観点、補助箇所、判断の限界、質問の順に書く
・資料全体の閲覧を求めない
・「必ず」「最適」「安心」「おすすめ」を新しく加えない
・質問は一つにする
・入力にない情報を補わない
・入力に矛盾または不足があり、安全に書けない場合は本文を作らず「要確認」と不足項目を出す

メール本文だけを出力してください。

禁止表現だけを列挙するのではなく、禁止する結論と、その理由になる未確認事項を組み合わせることが重要です。「おすすめ」を使わないように指示しても、「有効な方法です」と言い換えられれば、設計判断の先取りは残ります。防ぎたいのは特定の単語ではなく、入力にない結論です。

初稿が出た後は、別の検査指示で入力との差分を確認します。

次の初稿を、入力票と一文ずつ照合してください。

1. 入力票に根拠がない事実、評価、約束を抜き出す
2. 顧客の発言と担当者の判断が混同された箇所を抜き出す
3. 資料の事例が個別案件へ適用できるように読める箇所を抜き出す
4. 資料名、版、位置、見出しの一致を確認する
5. 未確認事項が事実として補われていないか確認する
6. 問題ごとに「該当文」「問題の種類」「入力票上の根拠」「修正案」を表で示す
7. 問題がなくても、原本確認が必要な項目は「人の確認が必要」と示す

AI自身の判断で資料内容や顧客情報を追加しないでください。

この検査結果は、送信承認の代わりにはなりません。AIは添付予定の原本、顧客管理画面、実際の閲覧権限を自動的に確認できるとは限らないためです。担当者は、検査結果を手掛かりに原本へ戻ります。

AI利用の体制、記録、責任分担を検討する際は、経済産業省「AI事業者ガイドライン」を一次資料として参照できます。本記事の入力票、二段階プロンプト、評価表は同資料が工務店向けに定めた必須様式ではなく、資料送付文を管理するための編集上の提案です。

05.AI初稿で起きやすい「断定の追加」を分類する

AIによる断定は、「必ず」のような分かりやすい語だけではありません。入力した事例名や顧客の関心を滑らかにつなぐ過程で、可能性、因果関係、顧客意図、会社の対応能力が追加されることがあります。

断定の追加は、形容詞を削るだけでは直りません。「最適」を「適した」に変えても、適合判断をしていない問題は残ります。修正時には、文体ではなく、その一文が担っている判断を確認します。

特に注意したいのは、顧客への共感を示す表現です。「さぞご不安かと存じます」と書けば丁寧に見えますが、顧客が不安を述べていない場合は心理状態の推測になります。「明るさと視線が気になるとのことでしたので」と、確認できる発言へ戻せば足ります。

また、資料に掲載された住宅が明るく見えるからといって、「窓の工夫で明るさを確保した事例」と書けるとは限りません。撮影条件、設計意図、周辺状況を確認していなければ、写真から原因を推測しているためです。AIへ画像やPDFを読み込ませた場合も、見た目から設計上の因果関係を補わせないようにします。

禁止語の一覧は補助にはなりますが、一覧にない言い換えを防げません。実務では「どの種類の判断を追加してはいけないか」を入力票と評価表で管理します。

一文ごとに根拠と追加判断を分ける

初稿を点検するときは、文全体を「自然かどうか」で採点せず、一文を「原資料にある事実」「顧客の発言」「会社が承認した案内」「AIが補った判断」に分解します。担当者は入力票の資料IDと該当箇所を横に記し、対応する根拠を示せない語句へ印を付けます。根拠が見つからない文を言い換えて残すのではなく、その文の役割を「資料のどこを確認してほしいか」という案内へ戻します。

ここでは前の施工事例集とは別の架空例として、資料IDを付けた「資料D-014」を扱います。別案件の入力票に「資料D-014には二階リビングの写真がある。窓の方位、敷地での採光効果、顧客宅での適用は未確認」とあるのに、AI初稿が「南側の大きな窓で明るさを確保できます」と書いた場合を考えます。「南側」「大きな」「明るさを確保」「できます」は、写真を案内する目的を超えた追加判断です。担当者は資料を見ても方位や効果を確認できなければ、文章を「二階リビングの窓配置を写真でご覧いただけます。ご自宅での明るさは敷地条件を確認したうえで検討します」へ直します。写真の内容がそれすら支えない場合は、該当文を送付文から外します。

修正票には、元の文、根拠ID、見つからなかった判断、修正後の文、承認者を一組で残します。同じ追加判断が別の資料でも再発したら、「方位・性能・個別案件への適用を推測しない」という禁止事項を初稿用プロンプトへ戻し、次の試行で再発したか確認します。資料の改訂によって根拠が増えた場合も、古い入力票を使い回さず資料IDと版を更新してから判定します。

06.不適切な初稿を完成文へ直す

架空案件の入力から、AIが次の初稿を出したとします。これは問題点を説明するための作例であり、特定のAIサービスが実際に出力した結果ではありません。

お問い合わせいただき、ありがとうございます。工務店例068では、住宅が近接する敷地でも、明るさとプライバシーを両立した快適な住まいをご提案できます。今回お送りする施工事例集には、同じお悩みを解決した二階リビングの事例を掲載しています。大きな窓を効果的に配置することで、外からの視線を防ぎながら十分な採光を確保していますので、ぜひ全体をご覧ください。詳しいご提案をご希望でしたら、お早めにご来場ください。

文章としては自然ですが、入力票にない判断が複数追加されています。

修正では、断定を曖昧な免責へ置き換えません。「条件によって異なりますのでお問い合わせください」だけでは、何を確認すべきか分からないからです。入力票にある未確認事項から、今回の判断に直接関係する条件を示します。

完成文は次のように整えられます。

お問い合わせいただき、ありがとうございます。

リビングの明るさと外からの視線が気になるとのことでしたので、検討時の見方を整理する参考として「施工事例集2026年6月版」をお送りします。

最初に、紙面16〜19ページ（PDF表示18〜21ページ）の「住宅が近接する敷地のリビング」をご覧ください。写真の印象だけでなく、窓の位置と、ソファやダイニングなど人が過ごす場所との関係を見ると、事例の考え方を確認しやすくなります。

紙面32ページ（PDF表示34ページ）の「窓と視線の考え方」も、補足としてご覧いただけます。掲載事例と同じ方法が検討地に適するかは、方位や周辺建物などの確認が必要です。

差し支えなければ、検討中の土地は「決まっている」「探しているところ」のどちらでしょうか。一言だけでもご返信いただけます。

この完成文では、AI初稿にあった「快適」「解決」「効果的」「十分な採光」といった評価を、位置情報、見る観点、未確認条件へ置き換えています。文章の勢いを弱めることが目的ではありません。受け手が実際に資料を開き、掲載内容と自分の条件を混同せずに読める情報へ変えることが目的です。

完成文に「方位や周辺建物など」と書いたのは、入力票で未確認とされた条件だからです。AIが一般知識から思い付いた条件を後付けしたものではありません。別の案件では、同じ一文を固定せず、その案件で担当者が確認した条件に入れ替えます。

根拠がない一文を見つけたとき、常に削除するとは限りません。「詳しくは資料をご覧ください」という一般的な文は、確認済みのページと観点へ置き換えられます。一方、「どの敷地にも対応できます」のように、置換に使える確定情報がない文は削除します。

07.送信前評価は点数と停止条件を分ける

資料送付文の評価では、文章の自然さだけを見ません。入力票との一致、原本の照合、未確認事項の扱い、次の質問の負担まで確認します。

以下の評価表は、本記事で提案する運用例です。法令や公的ガイドラインが定める採点基準ではありません。

満点は16点ですが、合計点だけで送信可否を決めません。次のいずれかに該当する場合は、点数にかかわらず送信を止めます。

• 本文に書いた資料名または版が添付予定ファイルと一致しない
• 位置情報や見出しを送付原本で確認していない
• 顧客が述べていない事情を事実として書いている
• 設計可否、性能、費用、工期、法令適合を確認なく断定している
• 宛先、添付ファイル、リンク先、閲覧権限のいずれかが一致しない
• 社内規程で認められていない情報をAIへ入力している
• AIが作った本文を担当者が通読していない
• 入力票内の矛盾が未解消のまま残っている

架空案件の完成文を評価すると、文面から確認できる項目と、文面だけでは確認できない項目があります。

情報管理を文面だけで2点にしてはいけません。匿名化した入力票を使ったか、承認されたサービスか、アクセス権が適切かは、完成文から判定できないためです。

点数はAIの性能を競うためではなく、差し戻す場所を特定するために使います。該当箇所が0点なら、AIへページを考えさせず、担当者が原本を確認します。読む観点が0点なら、AIへ「具体的にして」と頼む前に、担当者が何を見てほしいか決めます。

08.修正をテンプレートへ反映する基準を決める

一件の文面を修正するたびにプロンプトへ条件を追加すると、テンプレートが長くなり、別の案件に固有条件が残ります。反対に、繰り返す問題を個別修正だけで済ませると、同じ誤りが続きます。

修正履歴は、まず原因によって分類します。

テンプレートへ反映するかは、発生回数だけで決めません。次の三点を確認します。

第一は、他の案件でも同じ原因が起こるかという「共通性」です。特定顧客だけに必要な説明なら、その案件の入力票へ残します。どの資料でも未確認事項が抜けるなら、共通入力欄を追加します。

第二は、同じ入力条件で同じ問題を再現できるかという「再現性」です。一度だけ不自然な言い回しが出た場合、すぐ禁止語を増やすのではなく、入力と出力を記録します。複数回、個別適用の断定が出るなら、禁止する結論と検査項目を見直します。

第三は、誤った場合の「影響」です。ページ案内の軽微な表記揺れと、性能保証や個人情報の不適切な入力を同列に扱いません。件数が一度でも、顧客への誤案内や情報管理上の問題につながるなら、共通ルールや送信停止条件へ反映します。

「同じ問題が二回起きたら自動的に追加」のような件数ルールだけにすると、偶然の言い回しまでテンプレートへ蓄積されます。二回目を見直しの契機にすることはできますが、反映時には共通性、再現性、影響を確認します。

たとえば「二階リビングがおすすめ」と二件で出た場合、禁止語へ「おすすめ」を追加するだけでは不十分です。「掲載事例を個別案件への推奨へ変えない」という判断単位を制約へ加え、検査プロンプトにも「事例紹介が適合判断へ変わっていないか」を追加します。

一方、ページ番号の誤りが続く場合は、プロンプトの強化より資料台帳を確認します。入力自体が誤っていれば、AIは正しく文章化しても誤案内します。正式版、外部送付可能な版、位置情報を確認した日、改訂時の更新担当者を資料側で管理します。

テンプレートを変更したら、変更日、変更理由、対象資料、承認者を残します。古いテンプレートを使った案件まで自動的に正しい状態へ変わるわけではありません。共有フォルダー、顧客管理システム、個人保存の定型文など、実際の利用場所を確認して更新します。

媒体別の見せ方は既公開記事へ分ける

• メールでは件名・本文・添付を一組で確認します。メールに添える案内の設計は工務店の資料請求後メール｜資料に添える案内の設計を参照してください。
• LINEでは通知画面とスマートフォンでの到達性を確認します。画面上の案内や送付方法は工務店のLINE資料送付｜読む目的と確認点を添えるで扱っています。
• 媒体が変わっても、AIへ渡す確定情報、禁止する結論、原本照合の要否は変えません。

資料側の例外は文面生成を止めて処理する

• 正式版、見出し、位置情報が一致しない場合は生成と送信を止め、資料管理者が使用版を確定してから入力票を作り直します。
• ファイルを開けない、権限がない、リンク期限が切れている場合は、説明文の修正より先に閲覧手段を復旧し、送付方法の確認は工務店のLINE資料送付｜読む目的と確認点を添えるへ分けます。
• 誤送信や不適切な共有が疑われる場合は、追加送信を止め、可能なら共有を停止し、社内の責任者へ報告して、影響確認と相手への対応を自社手順に沿って進めます。

09.小さく試し、完成文ではなく修正原因を蓄積する

運用開始時は、送付頻度が高く、正式版が一つに定まり、担当者が原本を確認できる資料を一種類選びます。複数資料、複数媒体、複数の生成AIを同時に変えると、どの変更が誤りに影響したか分かりにくくなります。

最小運用は、次の九工程です。

1. 顧客が実際に述べた関心を原文から抜き出す 2. 生成に不要な個人情報や案件情報を除く 3. 送付する資料と正式版を確定する 4. 該当箇所と見出しを原本で照合する 5. 読む観点、未確認事項、禁止する結論を担当者が決める 6. 初稿用プロンプトで文案を作る 7. 検査用プロンプトと評価表で差分を見つける 8. 添付、宛先、権限を人が確認して承認する 9. 修正原因と反映先を記録する

修正履歴には、AIの出力全文を漫然と保存するのではなく、どの入力から何が追加され、誰がどこへ戻したかを残します。会話履歴に個人情報が含まれる可能性があるため、保存範囲や保管期間も社内ルールに合わせます。

運用指標も、返信数だけに偏らせません。強い件名や来場の催促で返信が増えても、資料案内が正確になったとは限らないからです。

数値目標は、送付件数、資料の種類、承認体制に応じて自社で決めます。本記事から一律の合格率は示しません。母数が少ない月の割合だけで結論を出さず、修正内容と原因も併せて確認します。

AIを使った資料送付文で最も重要なのは、流麗な文章を一度で出すことではありません。担当者が判断済みの部品を渡し、AIが追加した判断を見つけ、原本へ戻して修正できる状態を作ることです。

読む理由、該当箇所、見る観点、判断の限界、次の一問が入力票と対応していれば、担当者が変わっても修正理由を説明できます。AIには資料の価値や顧客の気持ちを推測させず、確認済みの材料を受け手が迷いにくい文面へ整える役割を担わせます。