工務店・ハウスメーカーの事例案内をAIで補助 要望と確認済み事実を対応させる

以下で扱う「工務店例086」、顧客条件、事例ID、数値は、手順を説明するための架空例です。実在する企業、建物、顧客とは関係ありません。工務店例086は地域内で木造注文住宅を扱い、個別案内に利用できる施工事例を18件管理しているものとします。検討中の顧客は夫婦と子ども1人の3人世帯で、共働きです。要望は「帰宅後に手を洗う」「室内干しを中心にする」「リビングへ入る前に上着やかばんを片付ける」「道路から主要居室が見えにくいようにする」です。予算、建築地の法的条件、設備機種はまだ確定していません。

AIが担うのは、事例の採否を最終決定することではなく、要望と事実の対応候補を並べ、見落としや確認不足を示すことです。敷地条件、価格、性能、補助制度、法令への適合、施工可能地域などは、写真や紹介文から推測させません。根拠をたどれない項目は、「不一致」でも「対応済み」でもなく「未確認」として止めます。

追客業務全体の役割分担、承認、送信、記録は、基幹記事の工務店のAI追客フロー｜下書き・確認・送信・記録を分けるで扱います。商談記録から顧客の発言と営業側の推測を分ける工程は、工務店の商談要約をAIで作る｜顧客の発言と営業の推測を分けるの範囲です。本記事では、その後に行う「整理済みの要望と事例事実の対応」「出力の修正」「送付可否の評価」に絞ります。

01.事例案内の完成条件を「似ている」から「対応を説明できる」へ変える

事例案内で必要なのは、顧客と同じ家を見つけることではありません。建築地、家族構成、延床面積、予算、好み、採用できる商品がすべて一致する事例はほとんどないからです。完成条件は、次の五点を説明できる状態とします。

1. どの顧客要望に対応する事例なのか 2. 対応の根拠となる確認済み事実は何か 3. 顧客の計画と事例では何が異なるのか 4. 資料から判断できない項目は何か 5. 次に誰へ何を確認するのか

たとえば、顧客が「共働きなので、帰宅後の家事が短く済む家にしたい」と話していても、事例紹介に「家事楽の住まい」と書かれているだけでは対応は成立しません。玄関から手洗い場所までの経路、洗濯機と物干し場所の位置、収納の出入口など、要望に関係する具体的な事実が必要です。

反対に、洗濯機と室内干し場所が隣接しているからといって、「家事時間が短くなる」「3人分の洗濯物を十分に干せる」とは限りません。生活上の効果は、洗濯量、設備の使い方、移動の順序などによって変わります。事例案内では、確認できる配置と、まだ評価できない効果を分けます。

顧客側の条件は、次の四種類で記録します。

事例側も、「確認済み・条件付き・未確認・非該当」の四種類で管理します。

• 確認済み：図面、仕様書、見積内訳、撮影記録、担当者の確認記録など、根拠を特定できる
• 条件付き：事実は確認できるが、時期、対象範囲、外構、商品などの条件が付く
• 未確認：紹介文や写真から可能性は考えられるものの、根拠資料をたどれない
• 非該当：その事例には採用されていない、または顧客条件と明確に異なる

顧客条件の「未確認」と、事例事実の「未確認」は別物です。前者は顧客への聞き取りで解消し、後者は社内資料や担当者への確認で解消します。AIの出力には、未確認の種類と確認先を必ず残します。

途中で根拠が切れた場合は、文章を整える前に候補を保留へ移します。候補数を増やすために未確認情報を「おそらく採用されている」と補うと、顧客が自邸でも同じ条件を実現できると受け取るおそれがあります。案内数が少なくても、参考にできる範囲が明確なほうが、次の相談に使える資料になります。

02.施工事例を検索できる事実カードへ直す

過去のWeb記事や施工写真をまとめてAIへ渡しても、安定した候補選定にはなりません。公開記事は読み物として編集されており、顧客要望との照合に必要な項目がそろっていないからです。「開放的」「快適」「こだわり」といった言葉も、案件ごとに意味が異なります。

工務店例086では、18件の事例を一度に整備せず、利用頻度の高い案件から同じ書式の「事実カード」へ直します。カードには紹介文だけでなく、事実、状態、根拠、公開範囲、確認日を記録します。

このカードでは、「玄関から洗面室へ直接入れる」は確認済みでも、「収納後にリビングを通らず洗面室へ行ける」は未確認です。写真に玄関収納が写っていても、帰宅後の経路全体が分からなければ、顧客要望を満たすとは評価できません。

根拠には強さがあります。配置を完成平面図で確認できるなら平面図を主根拠とし、施工写真を完成状態の補助資料にします。公開済みの記事本文しか残っていない場合は、「公開されたから確認済み」と扱わず、元資料を探す対象にします。担当者の記憶を根拠にする場合も、確認者、確認日、確認した内容を記録し、図面で確認した事実と区別します。

費用情報には、金額だけでなく範囲が必要です。「本体価格」「付帯工事を含む請負額」「土地や諸費用まで含む総額」は比較単位が異なります。費用をカードへ記載する場合は、税込・税抜、契約時期、対象工事、除外項目をセットにします。いずれかが欠けるなら、顧客の予算への適合判定には使いません。

性能情報も同様です。数値が残っていても、指標の名称、算定条件、対象建物、根拠資料がそろわなければ、顧客向けの裏付けにはしません。「高断熱」「耐震性に配慮」といった紹介表現を、AIに具体的な等級や数値へ置き換えさせてはいけません。

写真では、「写っていること」「当時採用されたこと」「現在も同じ条件で提供できること」を分けます。造作収納が写っているなら「CASE-07で採用された収納」とは書けますが、現行価格や現在の施工可否までは分かりません。現在案件への適用は、商品・施工担当や積算担当への確認事項です。

カードを更新したときは、元の値を消すだけでなく、更新日、更新者、変更理由、影響する未送信案内を残します。標準仕様や公開条件の変更があったとき、古いカードから作った文章を探せるようにするためです。

03.顧客の言葉を判定可能な条件へ分解する

顧客の発言は、事例カードの項目とそのまま対応するとは限りません。「家事を楽にしたい」「明るい家がいい」「プライバシーもほしい」という表現には、複数の目的や優先順位が含まれます。AIへ渡す前に、顧客が実際に述べた内容と、営業担当が考えた解決方法を分けます。

工務店例086の顧客が「帰ったらすぐ手を洗って、上着やかばんを片付けてからリビングに入りたい」と話した場合、確認できる要望は一つではありません。手洗い場所までの経路、収納の位置、収納後に入る部屋の順序へ分解できます。ただし、「玄関内に手洗い器が必要」とまでは確定していません。洗面室へ短く移動できる間取りでも、目的を満たす可能性があるからです。

追加質問をすべて終えるまで事例検索を止める必要はありません。未回答の条件を未確認のまま残し、答えによって候補の意味が変わる場合に質問します。室内干し量が不明でも、洗濯機置場と物干し場所が隣接する事例を「配置の参考」として見せることはできます。ただし、「3人分に十分」とは表現しません。

一方、「道路から見えにくい」が昼間の視線対策なのか、夜間に照明を点けた状態まで含むのかによって、参考にする資料は変わります。外構、カーテン、窓の高さ、敷地の高低差も影響するため、建物写真だけで適否を決めないようにします。

要望の優先順位は、営業担当やAIが頻出回数から決めてはいけません。「必須」は、顧客が明言したか、確認して合意した条件です。会話で繰り返された表現であっても、自動的に必須へ昇格させません。AIの入力には、分類と一緒に根拠となる発言または確認日を付けます。

解決方法と目的も分けます。「ファミリークローゼットが欲しい」は部屋名称を使った方法の希望です。その目的は、帰宅時の片付け、着替えの集約、洗濯後の収納、季節用品の保管など複数考えられます。同じ名称の部屋がある事例だけを探すと、目的に合う別の配置を見落とします。

この分離により、AIは「ファミリークローゼット」という語の一致ではなく、片付けの順序に関係する事実を探せます。同時に、営業側の提案仮説が顧客の必須条件へ変換されるのを防げます。

04.採用・保留・除外を同じ基準で判定する

候補事例は、点数だけで順位付けせず、「採用・保留・除外」の三状態で管理します。

• 採用：少なくとも一つの必須要望に確認済み事実が対応し、除外条件と衝突せず、案内可能な根拠がある
• 保留：参考になり得るが、根拠不足、公開範囲、条件差などを確認しなければ送付できない
• 除外：顧客の除外条件と衝突する、公開できない、または差異を説明しても参考価値が乏しい

すべての必須要望を一件の事例で満たす必要はありません。CASE-07は帰宅動線、CASE-12は洗濯動線、CASE-15は道路側の視線対策というように、役割を分けて案内できます。その場合は「ご希望に近い三棟」とまとめず、各事例で確認してほしい点を明示します。

最初に除外条件を見るのは、部分的な魅力に引っ張られないためです。顧客が吹き抜けを避けたいと明言しているのに、採光の参考として吹き抜け事例を通常候補の上位に出すと、要望を理解していない印象を与えます。代替案の説明に不可欠なら通常候補と分け、提示目的を顧客へ説明できる場合だけ、担当者と承認者が例外扱いを判断します。

工務店例086では、次の五条件をすべて満たす場合だけ、AIが「案内候補」と表示する設定にします。

1. 必須要望の一つ以上に確認済み事実が対応している 2. 除外条件と衝突していない 3. 対応に使った事実の根拠資料と確認日がある 4. 条件差と未確認事項を案内文へ記載できる 5. 個別送付が認められた情報だけで説明できる

「一つ以上」とするのは、複数事例に役割を分けるためです。対応が一つだけなら、「ご要望に近い事例」ではなく、「帰宅後の手洗い経路を考えるための参考事例」のように範囲を限定します。

条件差は、欠点の一覧ではなく、事例を転用できる範囲を決める情報です。延床面積が顧客の想定より大きくても、玄関と洗面室の隣接関係は参考になる可能性があります。一方、広さによって成立している回遊動線を、別の面積条件でも再現できるかは未確認です。「配置の考え方は参考になるが、同じ通路幅や収納量を確保できるとは限らない」と切り分けます。

AIによる得点は、確認順の整理には使えても、採否の代わりにはなりません。必須要望三つのうち二つに対応していても、除外条件に衝突していれば、単純な加点方式では上位に残る可能性があります。除外条件、非公開情報、重大な根拠不足は減点ではなく停止条件にします。

05.AIへ渡す入力を一案件一形式に固定する

AIの回答を安定させるには、指示文を長くする前に入力の欠落を減らします。顧客条件、事例カード、判定基準、出力形式を毎回同じ順序で渡すと、担当者による差を抑えられます。チャット履歴だけに依存せず、一案件ごとに入力票を保存します。

入力票には顧客の氏名、住所、勤務先、学校名、連絡先を含めず、案件IDを使います。家族構成も、事例の判断に必要な粒度へ限定します。「3人世帯」は収納量や洗濯量を確認する入口になりますが、個人を特定できる詳細属性まで通常の候補選定に入れる必要はありません。

工務店例086の入力例は次のとおりです。

処理目的
顧客要望と施工事例の確認済み事実を対応させ、担当者が確認する案内候補を作成する。

案件ID
LEAD-086-14

顧客条件
必須：玄関から手洗い場所へ移動しやすい。帰宅経路上に上着とかばんの収納がある。洗濯機置場と室内干し場所を近づけたい。道路側から主要居室への視線を抑えたい。
希望：収納後にリビングを通らず移動したい。
除外：吹き抜けのある事例は通常候補にしない。
未確認：室内干しする量、玄関内手洗いの要否、昼夜どちらの視線を重視するか、予算に含める工事範囲。

事例カード
事例ID、公開範囲、確認済み事実、条件付き事実、未確認、非該当、根拠資料、最終確認日を記載する。

禁止事項
資料にない事実を補完しない。性能、価格、効果、法令適合、施工可否を推測しない。顧客の優先順位を変更しない。条件付き事実から条件を削除しない。

判定順序
除外条件との衝突、公開範囲、必須要望との対応、条件差、未確認の順に確認する。

出力項目
事例ID、判定、対応する要望、カードから引用した事実、条件差、未確認、確認先、顧客向け初稿を出力する。

使用禁止表現
「ぴったり」「最適」「必ず」「完全に」「予算内で実現できる」「同じ性能」「問題なく採用できる」。

この形式の前に、「不足項目だけを列挙する」工程を置きます。いきなり案内文まで作らせると、不足を補って文章を完成させる場合があるからです。公開範囲、根拠、確認日、条件分類の不足を先に出させ、補える情報だけを担当者が追記してから採否判定へ進みます。

事例カードをAIへ渡す順番も固定します。推したい事例を先頭に置いたり、「この事例を勧めたい」と書いてから評価させたりすると、根拠より営業上の希望を優先した出力になりかねません。工務店例086では事例ID順に並べ、採否を決めた後に顧客へ見せる順序を人が整えます。

複数の顧客案件を同じ入力へ混ぜる運用は避けます。要望が混ざるだけでなく、別案件の情報が出力へ現れた場合に影響範囲を追いにくくなります。一案件一入力、一出力一保存先とし、案件を越えて再利用するのは、公開範囲を確認した事例カードと承認済みの判定基準に限ります。

追加の聞き取りで「室内干しは全量ではなく、雨の日だけ」と判明した場合は、入力票を上書きして終わらせません。更新日、変更前、変更後、確認方法、影響する候補を記録します。古い条件で作成した未送信文面があれば、送付前に再評価します。

06.AIの出力を顧客向けの案内へ修正する

AIの初稿は、対応候補の整理には使えても、そのまま顧客へ送れるとは限りません。典型的な欠陥は、部分一致を全体一致へ広げる、条件差を削る、未確認を前向きな推測で埋める、設計上の配置と生活上の効果を直結させることです。

修正は、単に文章を柔らかくする作業ではありません。主語、根拠、適用範囲を狭め、「どの要望について、何を参考にできる事例なのか」を明確にします。

修正文では、「確認できる」「判断できない」「追加確認する」を使い分けます。ただし、すべてを曖昧にすればよいわけではありません。図面で確定している配置まで「かもしれません」とぼかすと、事例を示す意味が薄れます。確定している過去事実は明確に述べ、そこから先の効果、転用可能性、現行価格だけを限定します。

顧客向け案内は、会社が見せたい特徴ではなく、顧客の関心から始めます。完成文は、たとえば次の形です。

前回伺った「帰宅後に手洗いと片付けを済ませてからリビングへ入りたい」というご希望について、配置を考える参考としてCASE-07をご案内します。

この事例では、玄関から洗面室へ直接入る扉と、ホール側から利用する玄関収納を完成平面図で確認できます。また、洗面室内に洗濯機置場があり、隣接する室に物干し金物が設置されています。

一方、収納後にリビングを通らず洗面室へ移動できるかは、現在の資料では確認できません。道路側の植栽は竣工写真で確認できますが、敷地との高低差や夜間の見え方は未確認です。

CASE-07の延床面積は112.4㎡で、今回想定する面積や敷地条件で同じ配置が成立するかはまだ検討していません。次回は、手洗い場所が玄関内に必要か、洗面室へ短く移動できればよいかを伺い、取り入れられる配置を設計担当と確認します。

この文では、案内理由、確認済み事実、条件差、未確認、次の質問が分かれています。「同じ家ができる」という約束ではなく、次の相談で判断する材料として位置付けています。

写真を添付する場合は、「玄関から見た洗面室入口」「洗面室に隣接する室内干し場所」など、対応する要望が分かるキャプションを付けます。写真に写っていない経路を図示するなら、平面図との整合を担当者が確認します。撮影範囲外の扉や移動経路を、AIに推測で描写させません。

一度に案内する事例数も、件数ではなく役割で決めます。帰宅動線、洗濯動線、視線対策について同じ情報しか示さない事例を多数送っても、判断材料は増えません。原則として、一つの事例に一つの主な役割を付け、同じ役割の候補を複数送る場合は違いを説明できるものに限ります。

07.対応評価表で採用理由と送れない理由を残す

承認者が確認するのは、文章の読みやすさだけではありません。要望と事実の対応、根拠、条件差、公開範囲、未確認の扱いを一枚で追える評価表が必要です。点数だけを保存すると、なぜ採用したのか、資料更新後にどこを直すべきかが分かりません。

工務店例086では、個別項目を「適合・部分適合・未確認・非該当・衝突」の五種類で評価します。「良い・普通・悪い」のような感覚評価は使いません。

「部分適合」は、何でも候補に残すための評価ではありません。適合する部分と、適合しないまたは確認できない部分を一文ずつ説明できる場合だけ使います。「玄関収納はあるが、収納後の経路は未確認」「物干し設備はあるが、必要量への適否は未確認」という形です。説明できない部分適合は未確認へ戻します。

総合処置は個別評価の多数決で決めません。次のいずれかがあれば、他の項目が適合でも送付を止めます。

• 顧客の除外条件と衝突している
• 案内理由に使った事実の根拠を開けない
• 顧客へ送れない写真や図面が説明に必要である
• 過去価格を現在価格として表示している
• 法令適合、構造、性能、安全性を事例の類似だけで判断している
• 条件付き事実から条件が消えている
• 別案件の顧客情報が混入している

評価表は顧客へそのまま見せる資料ではなく、社内の判断記録です。顧客向けには必要な差異と未確認を読みやすく伝えますが、社内では、確認者、確認日、根拠資料、保存場所、承認者まで残します。事例IDと案件IDを紐付けておけば、事例カードの訂正時に影響する未送信文面や過去の案内を検索できます。

AIが埋めるのは評価表の候補までです。根拠資料を実際に開いた確認、公開範囲の判断、送付可否の承認は人が行います。入力カードにない資料名をAIが「根拠」として出した場合は、その行を採用せず、生成結果全体を再点検します。

評価表を蓄積すると、事例データ側の不足も分かります。「視線対策」が毎回未確認になるなら、担当者の選び方だけでなく、配置図、外構条件、撮影方向、高低差の記録方法を見直します。次の竣工案件から何を保存するかを決める改善材料になります。

08.例外案件では自動選定を止め、確認と連絡の順序を固定する

法規、敷地制約、構造、性能、補助制度、現行商品の適用、正確な価格、保証条件、安全や災害時の効果は、過去事例の事実だけで現在案件への適用を判断できません。類似事例があっても、「同じようにできる」と案内せず、通常の自動選定を止めます。

工務店例086では、次の場合を停止条件とします。

• 建築地の法的条件や敷地調査結果がなければ成立性を判断できない
• 構造計画や性能値を、外観や間取りの類似だけで案内しようとしている
• 過去の費用を現在の予算適合へ読み替えようとしている
• 補助制度、税制、優遇措置の利用可否を事例だけから判断しようとしている
• 現在取り扱っているか不明な設備、建材、工法を同条件で提供できると書こうとしている
• 写真、図面、費用、家族情報の公開・個別送付範囲を確認できない
• 顧客の除外条件と衝突する事例を営業上の都合で推奨しようとしている
• 健康、安全、防犯、耐災害性の効果を、写真や居住者の感想だけで断定しようとしている

確認先は「詳しい人」ではなく、論点ごとに決めます。間取りへの転用可能性は設計担当、現行価格は積算担当、商品や施工可否は商品・施工担当、公開範囲は情報管理責任者へ確認します。法令や制度について社内で判断できない場合は、案件の具体条件を示したうえで、必要な資格者や専門家へ確認します。

安全、健康、災害対応に関わる誤案内を見つけた場合は、通常の文章修正より先に、送信停止と影響範囲の特定を行います。すでに送った相手がいる場合は、誤った記載、正しい確認状況、相手の行動や判断へ与える可能性を整理し、担当責任者が連絡の優先順位を決めます。生命や身体に関係し得る内容は、次回連絡へ紛れ込ませず、利用中止や専門窓口への連絡など必要な行動を先に伝えます。緊急性が判断できないときも、AIだけで「問題なし」と結論付けず、人による確認へ切り替えます。

再開時には、「対応可能」という回答だけを記録しません。対象地域、敷地条件、商品区分、確認日、回答者、案件限定か事例カードへ転用できる一般情報かを残します。条件を外したまま別案件へ再利用しないためです。

顧客から「この家とまったく同じにできますか」と聞かれた場合も、同じ・違うの二択で急いで答えません。「同じ考え方を検討できる部分」「敷地や面積に合わせて再設計する部分」「現時点では確認できない仕様」に分けます。事例は完成品の複製メニューではなく、条件を具体化するための材料です。

候補が一件も残らない場合に、AIへ必須条件を勝手に緩めさせてはいけません。必須条件の意味を顧客へ確認するか、該当事例がないことを伝えたうえで、設計担当が考え方を説明します。「該当事例なし」は、過去事例を現在の約束へ誤変換しなかったという有効な結果です。

すでに誤った案内を送っていた場合は、事例カードの修正だけで閉じません。送付先、送付日時、誤った記載、正しい確認状況、顧客判断への影響を確定し、訂正の要否と方法を決めます。具体的な訂正と再発防止は、工務店のAI追客で誤案内したとき｜訂正と再発防止の手順で扱います。

09.個人情報と利用範囲を事例の魅力より先に確認する

施工事例には、建物だけでなく、施主や家族に関する情報が含まれる場合があります。氏名を削除しても、外観、地域、間取り、家族構成、入居時期、周辺風景などの組み合わせによって個人を識別できる可能性があります。Webに掲載済みの素材であっても、別の相手への送付、別目的での利用、外部AIサービスへの入力まで無条件に認められているとは限りません。

個人情報の利用目的、安全管理、委託、第三者提供などについて検討するときは、個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」のうち、自社の処理に関係する箇所を確認します。ただし、このガイドラインへのリンクだけで個別案件の適法性が確定するわけではありません。入力情報、AIサービスの契約、保存・学習利用の設定、情報の移転先、委託関係、本人への説明、社内規程などによって判断が変わるため、具体条件を示して自社の個人情報保護責任者や必要な専門家へ確認します。

公開範囲は「公開可・不可」の二択にしません。Web掲載、SNS掲載、営業資料、個別顧客への送付、社内閲覧、外部AIへの入力、加工の可否を分けます。

「外部AI入力不可」と管理されている素材は、担当者の判断だけで投入しません。氏名を削除しただけで十分と決めつけず、ほかの情報との照合可能性も検討します。必要であれば、利用を認められた社内担当者が資料を確認し、事例選定に必要な非識別の事実だけをカードへ転記します。その事実カード自体についても、利用先と公開範囲を設定します。

AIサービスを選ぶ際は、入力データの保存、学習利用、アクセス権、ログ、削除、管理者設定、契約条件、問題発生時の連絡経路を確認します。AI利用者を含む関係者のガバナンスを検討する際は、経済産業省のAI事業者ガイドラインに関する公式掲載ページを参照し、実際に利用する時点でページに表示される版番号、更新日、改訂履歴を確認します。本記事では未確認の版番号や公表日を固定せず、工務店例086に必要な運用として「入力できる人、承認する人、保存先、問題時の報告先」を定めます。

社内手順には、少なくとも次の項目を含めます。

• 利用を認めるAIサービスと契約区分
• 入力禁止情報と、匿名化・一般化の基準
• 事例カードとAI出力の保存先
• 閲覧、編集、承認の権限
• 出力と操作ログの保存期間
• 顧客へ送る前の承認者
• 誤入力、漏えい、誤案内を発見したときの連絡先
• サービスや契約条件が変わったときの再確認日

AIを使ったことの説明方法も、利用場面と社内方針に沿って決めます。少なくとも、AIが適合性を保証したような見せ方は避けます。顧客から選定理由を問われたときは、「AIが選んだから」ではなく、どの要望に、どの確認済み事実を対応させたかを担当者が説明できる状態にします。

10.小さく導入し、事例カードと判断基準を更新する

導入時から18件すべての事例を整備する必要はありません。工務店例086では、問い合わせで多い「帰宅動線」「洗濯動線」「道路側の視線対策」の三テーマから始め、それぞれ二、三件の事例カードを作ります。紹介したい事例だけでなく、根拠資料と公開範囲がそろっている事例を選びます。

過去案件での試行は、AIの正解率をよく見せるためではありません。人が実際に送った事例とAI候補が違う場合に、顧客要望の記録不足、事例カードの欠落、担当者の経験則、営業上の優先がどこに入ったかを調べるために行います。過去の人の判断を自動的な正解とせず、現在の基準で再評価します。

運用評価では、文章の好みよりも、事実の逸脱と停止条件の見落としを測ります。

率を下げるために具体的な記載を減らし、曖昧な文章へ逃げてはいけません。件数だけでなく、どの項目で起きたかを確認します。たとえば、視線対策だけ未確認の断定が多いなら、プロンプトの問題に限らず、配置図や撮影条件を保存していないことが原因かもしれません。

更新には、案件別更新と横断更新があります。案件別更新は、根拠の誤りや顧客条件の変更を直すものです。横断更新は、標準仕様、価格体系、施工地域、公開条件、AIサービスの契約や設定が変わったときに、影響するすべてのカードと未送信文面を見直すものです。事例ID、資料の版、確認日で検索できる状態にします。

事例カードの責任者も決めます。営業担当だけに任せると、顧客へ伝えやすい表現は増えても、図面、仕様、施工条件との照合が弱くなる可能性があります。設計、施工、積算、広報、情報管理のうち、項目ごとの確認者を割り当て、カード全体の更新責任者を一人定めます。

運用が安定してから、対象テーマと事例数を増やします。新しい事例を登録する基準は、写真の見栄えではありません。「どの要望の判断材料になるか」「どの根拠を残せるか」「どこまで案内できるか」を説明できることです。参考範囲を定義できない事例は、広報素材として利用できても、AIによる事例対応の候補には入れません。

最終的に目指すのは、AIが顧客に最適な家を言い当てる仕組みではありません。顧客の発言を勝手に広げず、過去事例を現在の実現保証へ変えず、確認できる事実から次の相談材料を作る仕組みです。顧客条件の「必須・希望・除外・未確認」と、事例情報の「確認済み・条件付き・未確認・非該当」を混ぜずに運用できれば、施工事例の案内は単なる作品紹介ではなく、顧客と担当者が条件を具体化するための判断資料になります。