工務店・ハウスメーカーの要望分類をAIで下書き 候補票を人が確定する手順

要望整理表の列、三分類の判定基準、家族ごとの合意、変更履歴、設計・見積もりへの引き継ぎは、基幹記事の工務店の要望整理表の作り方｜必須・希望・保留を分けて家族の発言と変更履歴を残すで扱っています。本記事では、その要望整理表を正本とし、同じ作り方を繰り返しません。

ここで扱うのは、AIに渡す記録をF・O・A・Uに分ける方法、分類候補を作る指示文、AI特有の誤りを直す修正票、利用を止める条件、試行結果を評価する指標です。AIの成果物は正式な要望整理表ではなく、人が確認するための「分類候補票」と位置づけます。

記事内の会社、家族、商談日、面積、期限、要望、評価値はすべて説明用の架空例です。法的適否、建築上の成立性、価格、工期、製品性能をAIが保証するものではありません。該当する図面、見積書、製品資料、調査結果を担当者が確認し、顧客の回答と分けて記録してください。

01.AIに任せる成果物を分類候補票までに限定する

AIへ最初に伝えるべきなのは、分類基準よりも権限の境界です。AIに許可するのは、原記録からの要望候補の抽出、根拠箇所の表示、不足情報の指摘、確認質問案の作成、競合候補の検出までです。

必須・希望・保留の正式な確定、設計上の可否、見積金額、工期、法令への適合、家族の合意は、AIの出力だけでは決めません。「顧客が言い切った」「AIが必須と判定した」という理由だけで、図面や見積書へ反映しない運用が必要です。

必須・希望・保留の基本的な意味は、正本側の運用規則に従います。AI用の「候補」は、正式分類とは別の値です。たとえば「必須候補」は、顧客が未達時の影響を述べた可能性があるという抽出結果であり、実現可能性まで確認済みという意味ではありません。

候補票から正本へ移す条件を先に決めておくと、AI出力がそのまま社内資料へ流れることを防げます。

商談内容を要約する前段階で、顧客の発言と営業担当者の推測が混在している場合は、先に工務店の商談要約をAIで作る｜顧客の発言と営業の推測を分けるの方法で原記録を整えます。推測が混ざった記録から分類だけを正確にすることはできません。

02.AIを使える案件か入力前に判定する

AIを使うかどうかは、担当者の好みではなく入力条件で決めます。原記録がない案件や、複数案件のメモが混ざった資料は、長い指示文を加えても安全に分類できません。顧客名を伏せただけで、利用条件の確認が終わったことにもなりません。

入力前判定では、記録の品質と利用環境を分けて確認します。記録が整っていても、利用を許可されたサービス、契約プラン、入力範囲、保存先、承認者が決まっていなければ処理を始めません。

顧客の個人情報を含む商談記録を扱う場合は、利用目的と入力範囲、安全管理措置を先に確かめます。個人情報保護委員会のガイドライン（通則編）は、利用目的の具体的な特定と、取扱状況に応じた安全管理措置を示しています。下の判定表はその法定様式ではなく、AI処理に進めるかを社内で決めるための編集上の書式です。

録音の欠落、話者不明、家族内の発言の食い違いは、AIに推定させず「処理できない情報」として残します。聞き取れない部分を自然な文章へ直すと、その後の担当者が推定箇所を見分けられなくなります。

AIを使う案件でも、全資料を渡す必要はありません。要望分類に不要な氏名、電話番号、メールアドレス、勤務先名、土地の詳細な所在地などは、入力目的と必要性を確認して除外または置換します。ただし、単に氏名を「顧客A」へ変えれば十分だとは限りません。家族事情、土地条件、勤務状況などの組み合わせから識別につながる可能性も検討します。

条件を満たさない場合は、AI処理を見送って人が整理します。停止できる分岐は、AI活用を妨げるものではなく、誤った分類候補を後工程へ流さないための運用機能です。

03.原記録をF・O・A・Uに分けて入力する

AIへ渡す文章には、情報の出所を示す記号を付けます。本記事では、F・O・A・Uの四区分を使います。文字だけを社内へ導入すると意味が変わりやすいため、入力テンプレートと指示文の両方に毎回凡例を入れます。

Fは「確認済み事実」のFではありません。ここでは、発言という出所を識別するための記号です。たとえば「F：2028年3月までに入居したい」は、顧客がその希望を述べた記録であり、工程上実現できることを確認した記録ではありません。

Oには、担当者が観察した現在の暮らしや、提示を受けた資料の内容を記載できます。ただし、「室内干しをしていた」という観察から「ランドリールームを希望している」とは確定できません。観察は質問を作る材料であり、顧客要望の代用ではありません。

Aは削除せず、推測だと分かる状態で残します。営業担当者の仮説には、次回の質問や提案に役立つものがあるからです。一方で、Aだけを根拠に必須候補や希望候補を作らないよう、指示文で明示します。

架空の工務店例012案件をF・O・A・Uへ変換する

以下では、架空の工務店例012が受けた新築相談を固定例として使います。家族は夫婦と小学生の子ども一人、計画規模は延床面積約30坪、初回ヒアリング日は2026年9月12日、入居希望は2028年3月までとします。土地は所有済みですが、総予算の上限は確定していません。

AI用入力は、会話を読みやすく要約するより、発言者と出所を失わないことを優先します。

S-02の「絶対」という表現は重要ですが、それだけで独立室を正式な必須にはしません。守りたいものが部屋形式なのか、洗う・干す・しまう動線なのかがS-14で未確認だからです。

S-04も、生活上の目的があるというだけでは希望候補に確定できません。どの場所を見たいのか、別の配置や見守り方を比較できるのか、満たせない案を採用しないのかが未確認です。したがって、初稿では保留候補に置き、回答後に分類を動かします。

04.指示文には分類規則より先に禁止事項を書く

「必須・希望・保留に分類してください」だけでは、AIが空欄を補って完成度の高い表に見せる可能性があります。指示文には、役割、入力記号、出力形式、候補の判定条件、禁止事項、不明時の処理を含めます。

次の指示文は、架空の工務店例012案件を試すための例です。自社の正式な要望整理表へ直接登録する指示ではありません。

あなたは、注文住宅の商談記録から要望の分類候補を作る補助者です。出力は人が確認するための候補票であり、正式な要望整理表ではありません。

入力記号は次のとおりです。
F＝顧客が実際に述べた発言。発言内容が客観的事実であるという意味ではありません。
O＝担当者が観察した状況または確認済み資料。
A＝担当者の推測または仮説。
U＝未確認、矛盾、欠落、話者不明。

Fから要望候補を抽出してください。Oは確認質問の材料として扱い、顧客要望へ変換しないでください。Aは推測欄へ分離し、Fとして引用しないでください。Uは不足情報として残してください。

分類は「必須候補・希望候補・保留候補」のいずれかです。
必須候補は、満たされない案を採用しない、計画を見送る、または生活・業務上の目的が成立しないと顧客が発言している事項です。強い言葉だけでは必須候補にしないでください。
希望候補は、顧客が採用を望み、費用、面積、配置、代替手段などと比較できることが発言から確認できる事項です。目的が明確という理由だけでは希望候補にしないでください。
保留候補は、未達時の影響、代替可能性、比較材料、決定者、回答期限のいずれかが不足している事項です。保留を低優先という意味で扱わないでください。

目的と手段が同じ発言に含まれる可能性がある場合は、候補を別行にしてください。ただし、記録にない目的を創作しないでください。

記録にない寸法、金額、日付、性能、商品名、法令上の可否、設計上の可否、家族の合意を補わないでください。確認期限は確定値を作らず、「期限設定が必要」と記載してください。

各行に、候補ID、要望対象、分類候補、根拠となる入力ID、顧客の原文、不足情報、分類を確かめる質問、専門確認先を出してください。根拠となる入力IDがない行は作らないでください。

最後に、要望同士の競合候補と、AIでは判断できない事項を分けて出してください。競合が見つからない場合も「確認した範囲では見つからない」と記載し、存在しないと断定しないでください。

「期限案を作って」と指示すると、AIが商談日から機械的に一か月後の日付を置くことがあります。期限は、図面、見積もり、発注、申請、工事などへの影響を担当者が確認して設定します。AIには期限の不足を見つけさせても、根拠のない日付は作らせません。

指示文を長くしても、入力にない事実は得られません。出力が不安定なときは、形容詞を追加して調整する前に、F・O・A・Uの誤区分、話者の欠落、参照位置の不足を点検します。

05.固定案件でAIの分類候補を検証する

架空の工務店例012案件を指示文へ入力したとき、AIには次のような候補票を期待します。これは正解表ではなく、人が修正する前の作業用出力です。

R-01は、仕事への支障が語られているため必須候補にできます。ただし、この段階ではAIによる候補であり、正本へ渡す正式な必須分類ではありません。「個室書斎」「2階」「2室」「高性能な防音設備」といった手段は原記録にないため、AIがそれらを追加した場合は要望の抽出ではなく創作です。

R-02は、「絶対」という言葉があっても初稿では保留候補とします。S-14で、独立室と洗濯動線のどちらが成立条件か未確認だからです。次回面談で妻が、守りたい動線と比較できる部屋形式を回答した場合に、目的と手段を二行へ分けます。

R-04は「子どもの様子を見たい」という目的が読み取れても、目的が明確であること自体は希望の判定理由になりません。代替可能性と未達時の影響が分からない段階では保留候補です。顧客が「直接見通せない案も、近くへ行きやすければ比較できる」と回答した後で、希望へ変更できます。

R-06の「できれば」は希望候補の手がかりになりますが、言葉の弱さだけで処理を終えません。玄関の床面積、土間収納、外用品の置き場所など、何を比較する要望なのかを次回確認します。

AIの誤りを原文・分類・行動の三方向から直す

AI出力の点検は、文章を読みやすく整える校正ではありません。各行について、原文に戻れるか、分類理由が規則に合うか、次の行動で不足を解消できるかを確認します。

点検順序を固定すると、もっともらしい文章に引きずられにくくなります。

1. 根拠となる入力IDが実在するか確認する。 2. 引用文が原記録と一致するか確認する。 3. OやAをFとして扱っていないか確認する。 4. 記録にない数字、日付、仕様、合意がないか確認する。 5. 一行に複数の判断が混ざっていないか確認する。 6. 分類理由が、未達時の影響、比較可能性、不足情報のいずれかになっているか確認する。 7. 確認質問へ回答すれば分類を更新できるか確認する。 8. 専門判断が必要な事項に確認先が付いているか確認する。

AI誤り修正票の記入例

修正票には、正しい文章だけでなく誤りの型を残します。同じ誤りが続く場合、担当者が毎回手で直すのではなく、入力区分、指示文、出力欄、承認手順のどこを変えるべきか判断できます。

一行に複数の判断が混ざった出力を分ける

AIが「防音性の高い2階の個室書斎を夫婦それぞれに設ける」と出力した場合、少なくとも次の判断が混ざっています。

• 会議中に生活音が入りにくいこと
• 会議中の背景への映り込みを避けること
• 夫婦が同時にオンライン会議を行えること
• 固定された個室とすること
• 2階へ配置すること
• 2室設けること
• 特定の防音仕様を採用すること

原記録が支えているのは、生活音への懸念とオンライン会議があることまでです。背景、同時利用、個室形式、配置階、室数、防音仕様は、質問または専門検討が必要です。

分割後も、すべてを要望行にするとは限りません。顧客が述べていない事項は、確認質問または設計案の検討条件として残します。AIが作った細分化項目を、そのまま顧客の希望一覧へ変換しないことが重要です。

修正後の顧客回答を再入力する

次回面談で得た回答は、以前の入力文へ上書きせず、新しい入力IDを付けます。以下は、工務店例012の固定案件について作成した架空の追加回答です。

S-15は、独立室以外の手段を比較できるという回答です。S-21では、洗う・干す・しまう場所が離れる案を選ばないという未達時の判断も確認しています。この二つを根拠として、R-02を「洗濯動線を近づける必須候補」と「独立ランドリールームの希望候補」に分けられます。

S-16は、専用個室以外の場所を比較できるという回答であり、場所の形式を必須にする根拠ではありません。一方、S-20では、会議に家族の声が入る状態を避けられない案を採用しないと回答しています。そのため、R-01の必須分類はS-20を根拠に確定できます。

R-04も、S-17によって代替案を比較できることが確認されたため、保留候補から希望候補へ変更できます。分類変更の根拠は「生活上の目的が明確だから」ではなく、「直接の見通し以外の方法を比較できると顧客が回答したから」です。

R-06は、初回のS-06だけでは「広い玄関」という手段と、その目的の関係が未確認でした。S-22によって、目的が外用品の保管であり、玄関の広さと別の収納方法を比較できると確認できたため、要望対象を「玄関付近に外用品を置けること」へ直します。

06.重大な誤りでは公開・共有・反映を止める

すべての誤りを同じ重さで扱うと、表現修正に時間をかける一方で、他案件情報の混入や必須条件の脱落を見逃すおそれがあります。誤りを軽微、要修正、重大の三段階に分け、重大な誤りには件数や平均点とは別の停止条件を設けます。

重大な誤りを見つけたときは、次の順序で対応します。

1. AI出力の正本登録、顧客共有、設計・見積もりへの反映を止める。 2. 該当する出力、入力、派生資料、共有先を特定する。 3. 社内で定めた管理責任者へ連絡する。 4. 他案件情報や入力範囲外の情報が含まれる場合は、利用サービス上の共有状態や保存状態も確認する。 5. 原記録から人が候補票を作り直し、すでに反映された資料との差分を確認する。 6. 必要な訂正、連絡、記録を自社の規程と具体的な状況に従って行う。 7. 原因と再開条件を承認者が確認するまで、同じ処理を再開しない。

法令上どのような対応が必要になるかは、含まれた情報、利用形態、共有先、契約関係などによって異なります。記事だけで事故該当性や報告義務を判断せず、社内責任者や必要な専門家が具体的な状況を確認してください。

07.面談では分類名ではなく判断条件を確認する

AIが作った分類候補票を顧客へ見せ、「必須ですか、希望ですか」と選ばせるだけでは、目的と手段を分けられません。顧客へ確認するのは、満たされない場合の影響、別の方法を比較できるか、判断に必要な情報、家族内の決定者です。

「この条件が実現しなければ契約しませんか」という聞き方を毎回すると、顧客へ過度な二択を迫る場合があります。まず困る場面と代替可能性を聞き、必要な場合に未達時の判断を確認します。

AIが生成した質問には、答えを誘導する表現が混ざることがあります。「家事効率のためにランドリールームが必要ですよね」のような質問では、担当者の解釈が前提になります。「どの作業を近づけたいですか」「別の配置でも比較できますか」のように、目的と手段を確認できる形へ直します。

顧客確認後も、正式分類と実現可能性は別です。顧客が「会議中に生活音が入りにくいことは成立条件」と回答しても、どの設計なら条件を満たすかは担当者が確認します。AIや営業担当者が、特定の壁仕様や設備で必ず実現できると断定しないようにします。

面談後の宿題について、担当者、期限、確認先を実行単位で管理する方法は、工務店の商談宿題をAIで抽出｜担当・期限・確認先の点検で扱います。分類候補票では要望判断に必要な不足を示し、宿題管理では実行の完了を追います。

08.AI出力を正本へ登録する承認ゲートを設ける

基幹記事の要望整理表には、顧客の原文、分類理由、確認状態、担当者、期限、反映先、変更履歴などを持たせます。本記事では同じ列設計を再掲せず、AI出力を正本へ移すために追加する監査項目へ絞ります。

原文照合者と正本登録者を同じ担当者にするかは、自社の人数とリスクに応じて決めます。ただし、重大な誤りが繰り返されている試行期間中は、別の担当者が確認するほうが誤りの傾向を見つけやすくなります。

承認は、表の末尾へ印を付けるだけでは機能しません。「根拠IDのない行は登録不可」「保留候補に不足情報がなければ差し戻し」「重大な誤りが一件でもあれば案件全体を停止」のように、差し戻し条件を設定します。

架空案件の確認後に正本へ渡す内容

工務店例012案件でS-15からS-22までの架空の追加回答を得て、担当者が原文照合した後の登録候補は次のようになります。反映先の版や期限は説明用に作らず、各担当者が実際の工程を確認してから正本へ記入します。

R-01について、S-16は専用個室以外の場所を比較できることを示していますが、必須分類の根拠ではありません。必須分類の根拠は、条件を満たさない案を採用しないと明示したS-20です。手段は比較可能でも、「会議に家族の声が入りにくいこと」という条件は必須になり得ます。

独立ランドリールームは、初回の「絶対」という発言だけでは保留候補でした。S-15とS-21を確認した後は、洗濯動線が必須、独立室が希望です。完成後の分類と、途中の候補分類を混同しないようにします。

R-04も、初稿では保留候補、追加回答後は希望です。分類理由は一貫しており、生活目的の明確さではなく、代替案を比較できるというS-17の回答によって希望へ移っています。

R-06は、S-06の「玄関を広くしたい」だけでは目的が未確認でした。S-22によって外用品の保管という目的と、別の収納方法を比較できることが確認されたため、入力IDを明示して希望へ登録します。

09.正解率だけでなく追跡性と重大誤りを評価する

AIの試行結果を、作業時間や文章の読みやすさだけで評価すると、後工程の手戻りを見落とします。評価単位は商談数ではなく要望行数を基本とし、抽出、追跡、分類、質問、禁止事項を分けて測ります。

たとえば、人が原記録から確定した要望が20行あり、AIがそのうち18行を正しく抽出した場合、要望抽出率は90％です。AI出力が22行あり、20行で根拠IDと参照位置を確認できた場合、追跡可能率は約90.9％です。これらは計算例であり、実在企業の成果値や一般的な推奨基準ではありません。

分類一致率だけを高くしようとすると、AIが迷った行をすべて保留候補へ置く運用になりかねません。反対に、必須候補を多く出させると重要条件を拾ったように見えて、誤分類が増えます。抽出率、追跡可能率、無根拠補完率、重大誤り件数を併せて評価します。

試行時の合否票を案件ごとに残す

自社の合格条件は、対象業務、確認体制、入力情報に応じて決めます。次は、工務店例012が試行時に使うという設定の説明例であり、すべての工務店へ共通する基準ではありません。

評価用の正解票は、AI出力を見た担当者だけで作ると判断が引きずられます。可能なら、原記録から先に人の照合票を作る担当者と、AI出力を修正する担当者を分けます。少人数の会社では、先に人の判定を保存してからAI出力を見るだけでも比較しやすくなります。

指示文を変更したら版番号を変え、同じ試行データで再評価します。案件ごとに入力内容を変えながら指示文も変えると、改善した理由を判別できません。

10.個人情報とAIサービスの利用条件を具体的に確認する

住宅相談の記録には、氏名や連絡先だけでなく、家族構成、資金に関する事情、生活時間、勤務状況、土地や建物に関する情報が含まれ得ます。どの情報が個人情報に該当するか、どの利用目的で扱うか、どの安全管理措置が必要かは、実際の情報と運用形態に即して確認します。

利用目的、安全管理措置、従業者や委託先の監督などを検討するときは、一次資料である個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」を参照します。外部AIサービスへの入力が個別案件でどのように扱われるかは、サービスとの契約関係、データの送信先、利用目的、設定、共有範囲などによって異なります。「外部サービスなら常に第三者提供になる」「氏名を伏せれば規律の対象外になる」と一律に断定しないでください。

AI利用の役割分担やリスク管理を検討するときは、総務省・経済産業省のAI事業者ガイドライン（第1.2版）を参照します。2026年3月31日にとりまとめられた版を確認し、本記事の入力票と人による確認手順は、個別の工務店で使うための編集上の書式として位置付けます。社内規程を見直す際は、参照版と改訂の有無を再確認します。

AI用入力と原記録の対応表は、AIの画面だけに置かず、自社が定めた保存場所で管理します。入力画面から会話を削除したとしても、サービス側の取扱いや社内に保存した複製まで同じ状態になるとは限りません。削除、保存期間、ログの扱いは利用サービスと自社環境の条件をそれぞれ確認します。

個人名を案件IDへ変換する場合も、変換表の閲覧権限を限定します。AI分類に不要な勤務先名は除外しつつ、「週3日在宅勤務」「オンライン会議がある」といった判断に必要な条件だけを残すなど、目的に応じて入力を最小化します。

11.少数案件で試し、再開条件まで標準化する

全案件へ一斉に導入すると、指示文の欠陥と担当者ごとの確認差を区別しにくくなります。最初は、原記録が整っており、営業と設計が一緒に確認できる少数案件へ限定します。

過去案件を試行データに使う場合も、過去の情報だから自由に入力できるとは限りません。利用目的、保存状態、利用環境、入力範囲を確認したうえで扱います。試行用に架空データを作る場合は、実案件の一部を組み合わせて特定の顧客を推測できる形になっていないかも確認します。

試行では、平均処理時間だけでなく、どこで人の確認が必要だったかを記録します。AIが初稿作成を短縮しても、無根拠補完を探す時間が増えれば、対象業務に適していない可能性があります。逆に、分類一致率が十分でなくても、不足情報と確認質問を安定して抽出できるなら、正式分類ではなく質問準備に用途を限定できます。

AIを使わない分岐を標準手順へ残す

次の状態では、担当者の裁量で無理に処理を続けず、人が原記録から整理します。

• 顧客発言と担当者の推測を区別できない
• 原記録がなく、担当者の記憶だけが残っている
• 話者不明の発言が分類の根拠になっている
• 複数案件の記録が混在している
• 利用を許可していない情報を除けない
• 利用サービス、契約プラン、設定を確認できない
• 他案件らしい情報が出力された
• 必須候補の根拠を原文へ追跡できない
• 正式登録の承認担当者が不在である
• AI出力から図面や見積書へ直接反映される状態を止められない

再開条件は「注意して使う」ではなく、実行を確認できる形で書きます。「案件資料を分離した」「入力禁止項目を除いた」「管理者が設定を確認した」「原文照合者と登録者を割り当てた」のように、停止理由に対応させます。

担当者による分類差は理由で調整する

同じ発言を見て、ある担当者は必須候補、別の担当者は保留候補と判断することがあります。多数決で分類を決めるのではなく、どの原文を根拠にし、未達時の影響と代替可能性をどう読んだかを比較します。

設備名だけで社内ルールを固定しないことも重要です。「ランドリールームは原則希望」「太陽光発電は原則保留」と決めると、顧客ごとの成立条件を確認しなくなります。社内の判定例には、設備名ではなく、発言、未確認情報、確認質問、回答後の変更理由をセットで残します。

12.分類候補票・修正票・評価票を一組で運用する

AIを使った要望整理の完成物は、分類結果だけではありません。少なくとも、AIが作る分類候補票、人が直す誤り修正票、運用品質を測る評価票の三点を一組にします。

提出前には、次の項目を点検します。

1. AI出力が「候補」であり、正式分類と区別されているか。 2. 全要望行からFの入力IDと原記録の位置へ戻れるか。 3. Oを顧客の希望として扱っていないか。 4. Aを顧客の発言や合意へ変えていないか。 5. UをAIが推測で埋めていないか。 6. 必須候補は、強い言葉ではなく未達時の影響を根拠にしているか。 7. 希望候補は、目的の明確さだけでなく比較可能性を確認できているか。 8. 保留候補には、判断を止めている不足情報が書かれているか。 9. 一行に目的、手段、寸法、配置、設備名が混在していないか。

10. 記録にない金額、寸法、日付、性能、商品名、家族の合意が追加されていないか。 11. 確認質問へ回答すれば、分類または不足情報を更新できるか。 12. 設計、施工、積算、製品資料などの専門確認先が分かるか。 13. 顧客確認済みと、実現可能性の確認済みを混同していないか。 14. AI初稿から直した理由を誤り修正票へ残したか。 15. 重大な誤りが見つかった場合に、共有と反映を停止したか。 16. 正本への登録者と登録先の要望IDを記録したか。 17. 必須・希望の分類理由に、その判断を支える入力IDが記載されているか。 18. 追加回答を以前の入力へ上書きせず、新しい入力IDと参照位置で追跡できるか。

AIの価値は、顧客の要望を自動的に決めることではありません。原記録から候補を拾い、人が確認すべき不足をそろえ、同じ誤りを測定可能にすることにあります。

正式な三分類、家族内合意、変更履歴、反映先は正本の要望整理表で管理します。AI側ではF・O・A・Uを崩さず、候補、根拠、不足、質問、誤りを残します。この境界を守れば、「必須・希望・保留」をAIに決めさせるのではなく、顧客と担当者が確定するための準備にAIを使えます。