工務店・ハウスメーカーのCRM入力をAIで補助 抽出結果を原記録と照合する

この作業で重要なのは、AIの文章が自然かどうかではありません。「どの記録の、どの箇所が、そのCRM項目を支えているか」「既存値を更新してよいのか」「未確定の内容を選択肢へ押し込んでいないか」を確認できることです。根拠を示せない値は、もっともらしくても登録しません。

商談記録そのものの作り方は工務店の商談記録｜事実・仮説・宿題を区別する、顧客発言と営業判断を分けた要約は工務店の商談要約をAIで作る｜顧客の発言と営業の推測を分けるで扱います。追客全体の役割分担は、基幹記事の工務店のAI追客フロー｜下書き・確認・送信・記録を分けるを参照してください。

本記事では全体手順を繰り返さず、CRM入力に固有の項目定義、既存値の更新、四つの判定、選択式項目への変換、評価方法を掘り下げます。入力例、AI出力の修正例、照合判断票までを一つの架空案件で確認します。

01.AI出力とCRMの正式値を明確に分ける

CRM入力をAIで補助するときは、データの状態を先に定義します。AIが値を抽出しただけの段階と、担当者が原記録を確認した段階と、CRMへ正式登録した段階を同じものとして扱ってはいけません。

顧客情報の利用目的と取扱いを定める際は、個人情報保護委員会の個人情報保護法ガイドライン（通則編）を参照します。以下の状態区分と承認欄は同ガイドラインの指定様式ではなく、AIの転記候補が未確認のままCRMの正本になることを防ぐための編集部の実務案です。

たとえば顧客が「土地も含め、全部で四千五百万円を超えないくらいにしたい」と話した場合、AIは「総予算4,500万円以下」と抽出できます。しかし、自社の総予算欄が「土地、建物本体、付帯工事、諸費用、消費税を含む金額」と定義されているなら、「全部」がその範囲と一致するかは分かりません。数値が原文に存在することと、CRM項目へ登録できることは別の判断です。

AIの出力画面に値が表示されても、照合済みになるわけではありません。自動連携を使う場合も、最初の保存先は正式項目ではなく、未承認の下書き領域または確認シートにします。CRMに下書き領域がない場合は、外部の確認表で判定を終えてから担当者が正式項目へ入力します。

正式データになる境界は、「AIが高い確率を示したとき」ではなく、「担当者が根拠箇所を開き、項目定義に適合すると判断し、必要な承認を終えたとき」です。AIの確信度は補助情報にはなっても、原記録の代わりにはなりません。

CRMから原記録へ戻れるように、少なくとも記録ID、記録日時、該当位置を残します。文字起こしなら時刻または発言番号、メールなら送信日時とメッセージID、相談票ならページと欄名、図面なら図面番号と版を使います。AIとの会話履歴だけを根拠にすると、元の文脈や入力時点を追えなくなるため、CRMの証拠欄にはしません。

02.原記録を項目ごとに選び、記録媒体を順位表にしない

原記録とは、CRMへ入れようとしている値を直接確認できる記録です。AIが作った要約や別担当者の伝聞ではなく、顧客が記入した相談票、顧客から届いたメール、録音、図面への記入など、発言または記入内容へ戻れるものを使います。

ただし、「メールは録音より強い」「相談票を常に優先する」といった媒体別の固定順位は適切ではありません。何を確認するかによって、必要な記録が変わるからです。来場日時なら双方が合意した最新メール、設備の希望なら商談時の具体的な発言、図面変更なら対象版への指示が直接の根拠になり得ます。

複数の記録が食い違う場合、AIに多数決をさせません。まず、同じ対象について述べているかを確認します。「総額4,500万円」と「建物3,200万円」は矛盾とは限りません。「2027年夏に入居したい」と「完成は秋でも構わない」は、希望が変わったのか、理想と許容期限を分けているのかを確かめる必要があります。

照合では、次の順序で確認します。

1. 同じ案件、同じ顧客、同じCRM項目に関する記録か 2. 発言者または記入者は誰か 3. いつ作成された記録か 4. 発言は希望、質問、仮定、提案、決定のどれか 5. 金額、時期、対象範囲などの条件が同じか 6. 新しい記録が既存値を明確に変更または撤回しているか 7. 変更ではなく候補追加や条件分岐として残すべきか

「もし土地が狭ければ三階建ても考える」という発言は、希望階数を三階建てに更新する根拠ではありません。「土地が狭い場合の選択肢」として残すか、CRMに専用欄がなければ自由記述の検討条件へ入れます。現在値を三階建てへ置き換えると、仮定条件が消えてしまいます。

原記録に修正がある場合は、修正前後も確認します。相談票の数字に訂正線があり、訂正後の文字が判読できなければ、AIが読み取った値を採用しません。図面や見積書も、最新版であることだけでは足りず、その書き込みが承認済みか、検討案かを見ます。

03.CRM項目辞書で採用条件と更新方法を固定する

同じ原記録を見ても担当者の判断が分かれる場合、AIの精度ではなくCRM項目の定義が曖昧な可能性があります。「予算」「時期」「確度」「家族人数」のような広い項目名だけでは、何を入れる欄か確定できません。

AIへ抽出を依頼する前に、項目ごとの辞書を作ります。最低限、項目名、意味、データ型、単位、採用できる根拠、採用できない表現、未確認時の扱い、更新規則を定めます。

総予算と建物予算を同じ欄に置いているCRMでは、AIに正しく分類させることは困難です。入力候補の精度を上げる前に、項目を分けるか、少なくとも金額の対象範囲を併記できる設計へ変えます。

選択式項目では、選択肢の定義も辞書に含めます。たとえば「入居時期：3か月以内、6か月以内、1年以内、1年超」という選択肢は、起点が商談日か登録日かによって値が変わります。可能であれば「希望入居年月」と「確認日」を保存し、相対区分は表示や集計時に算出します。

自由記述欄へ複数種類の情報を混ぜる場合も、文頭に分類を付けます。

• `顧客発言：桜台駅西側は通勤しやすい`
• `条件：学区は未調査`
• `担当判断：東側を含めて通学条件を説明する必要がある`
• `予定：次回、二つのエリアを比較する`
• `未確認：世帯としての優先順位`

「桜台駅西側を希望しているため、西側で土地を探す」のように一文へまとめると、前半の発言と後半の社内判断が一つの顧客決定に見えます。CRMでは分類ごとに分け、現在値と補足を区別します。

自社の項目を増減するときは、入力後に何へ使うかも確認します。担当者割り当て、次回連絡、設計条件、積算、案件集計のいずれにも使わない項目は、照合負担だけを増やす可能性があります。項目を絞る考え方は工務店の顧客管理項目｜最初に必要な記録を絞るを参照してください。

04.AIには原記録・項目定義・禁止事項を別々に渡す

「商談メモをCRM用にまとめてください」という指示では、抽出、要約、推測、項目への変換が混ざります。照合可能な出力にするには、処理対象、項目定義、禁止事項、出力形式、原記録本文を分けます。

原記録には先に位置情報を付けます。文字起こしなら時刻、メモなら段落番号、メールなら送信日時とメッセージIDを使います。AIに引用を出させても、位置情報がなければ担当者が全文から探し直すことになります。

以下の構成なら、AIの役割を転記候補の作成に限定できます。

処理対象
案件ID：CRM-2026-041
記録ID：MTG-2026-041-02
商談日時：2026年9月20日 14:00〜15:10

抽出対象
候補エリア、総予算、提案試算条件、希望入居時期、次回予定

項目定義
総予算は、土地、建物、付帯工事、諸費用を含むと確認できる金額だけを候補にする。
提案試算条件は、営業担当者が案の作成用に提示した金額を記録し、顧客予算とは分ける。
次回予定は、日時と方法について双方の合意が読める場合だけ候補にする。

禁止事項
原記録にない値を補完しない。
相対表現を勝手に特定日へ変換しない。
営業担当者の提案を顧客の決定として扱わない。
複数候補から一つを選ばない。
CRMの選択肢に近いという理由で意味を変更しない。

出力形式
項目名、抽出値、情報分類、根拠引用、根拠位置、不確定条件、既存値との関係を出す。
根拠がない項目は「該当記録なし」とする。

原記録開始
ここに記録本文を置く。
原記録終了

「適切に判断する」「必要に応じて補完する」といった表現は避けます。担当者が許可していない推測までAIの裁量に含まれるためです。長い社内規程を毎回貼る必要はありませんが、処理対象に関係する項目定義と禁止事項は省略しません。

原記録の開始と終了を示すことには、記録内の文をAIへの指示と混同させない目的もあります。顧客メールに「前の条件は無視してください」と書かれていても、それはAIへの命令ではなく案件記録です。

複数回の商談記録を処理するときは、一つの文章へ結合せず、記録IDと日時を保持したまま並べます。指示も「最新値へ統合する」ではなく、「記録ごとの候補と矛盾を列挙する」とします。どの値を現在値にするかは、更新規則に基づいて担当者が決めます。

画像化された相談票では、文字認識の誤りを前提にします。電話番号、メールアドレス、地番、金額など、一文字の違いが連絡や見積もりへ影響する項目は、AIの読取値だけで確定しません。原画像で桁、記号、欄の対応、訂正線を確認します。

05.架空例「工務店例056」で抽出値と根拠位置を照合する

以下の「工務店例056」は、この記事だけで使用する架空の工務店です。案件、顧客、発言、日時、金額は、CRM照合の手順を説明するための架空例であり、実在する工務店や案件の成果を示すものではありません。

工務店例056の案件IDを「CRM-2026-041」、二回目の商談記録IDを「MTG-2026-041-02」とします。商談日時は2026年9月20日で、顧客本人、同席家族、営業担当者が参加しました。

原記録の該当部分は次のとおりです。

00:12:18 顧客本人「通勤だけなら桜台駅の西側がいいです。ただ、子どもの学区はまだ調べていません」
00:18:42 同席家族「総額は土地もいろいろ込みで四千五百万円を超えないくらいにしたいです」
00:19:10 営業担当「建物は三千万円台前半を目安にして案を作ってみましょうか」
00:19:17 顧客本人「まずはそれで案を見たいです」
00:44:03 顧客本人「入居は来年の夏休みまでだと助かりますが、土地が決まらないと難しいですよね」
01:02:11 営業担当「次は27日の午前か29日の午後はいかがですか」
01:02:22 顧客本人「家族に確認してメールします」

この記録に対して、AIが次のような転記候補を出したとします。

この出力には、引用が存在する行でもCRMへそのまま入れられないものがあります。

希望エリアでは、AIが「確定」を追加しています。原記録が支えるのは、通勤だけを考えた場合の候補です。学区を調べた後に変わる可能性があり、世帯全体の優先エリアとして決定した記録でもありません。

総予算には金額の発言がありますが、「土地もいろいろ込み」が工務店例056の総予算定義を満たすとは確認できません。土地、建物、付帯工事、諸費用の全部を含むと推測してはいけません。

建物の三千万円台前半は、営業担当者が案を作るために提示した試算条件です。顧客本人は、その条件で案を見ることに同意しただけで、建物予算の上限として確定したとは読めません。また、AIが出した「3,000万〜3,499万円」は、「前半」を機械的な範囲へ変換しています。工務店例056の定義にその換算規則がなければ、原文のまま残します。

希望入居日は、原記録に8月31日という日付がありません。「夏休み」の期間は地域、学校、発言者の認識によって異なります。商談年から2027年と読み取る場合も、変換値だけでなく、原文と商談日を残します。

次回予定は、二つの日程を営業担当者が提案し、顧客本人は家族に確認して返信すると答えています。9月27日午前を選んだ根拠はなく、双方の合意もありません。

学区名は原記録に存在しません。地理情報から近隣校を推測できても、顧客が希望する学区として登録することはできません。

なお、建物予算行の根拠位置にある「営業提案01:19:10」はAIの転記誤りです。原記録は「00:19:10」であり、時刻も修正対象になります。一方、次回予定の営業提案は原記録どおり「01:02:11」です。位置情報そのものも照合対象に含めることで、別の発言を根拠として開く事故を防げます。

06.一行ずつ採用・修正・保留・却下を決める

照合結果は、正解と不正解の二択ではありません。原記録と項目定義に適合するものは採用し、値または分類を直せば使えるものは修正します。追加確認が必要なものは保留し、根拠がない候補は却下します。

「却下」は、別の表現へ書き換えてCRMに残す判定ではありません。CRMの正式項目、補足欄、未確認欄のいずれにも候補値を残さない処理です。値を別項目へ移せるなら、その行は却下ではなく修正です。確認後に使える可能性があるなら保留です。

工務店例056のAI出力をこの定義で判定すると、次のようになります。

建物予算の行は、値を捨てるのではなく、CRM項目と情報分類を「顧客予算」から「営業の提案試算条件」へ変更します。修正後の値も、独自に数値範囲へ変換せず、「3,000万円台前半を目安」という原記録の強さを保ちます。

次回予定の行は、日時を正式項目へ入れず保留にします。その代わり、顧客の返信を確認するタスクを作ります。タスクには「9月27日午前または29日午後のどちらかを確認」「顧客からのメールを原記録として確認」「確認後に次回予定を更新」と記載します。単に「日程確認」とすると、何を確定すべきか分かりません。

学区の行は却下です。「学区未確認」と書き換えて残す処理ではありません。原記録に学区を調べていないという発言はありますが、「桜台小学校」というAI候補自体には根拠がないため、その候補はCRMに何も残しません。学区を確認する必要があるなら、根拠のある「学区は未調査」という別の発言から、別行として確認事項を作ります。

四判定を残す目的は、AIの点数付けだけではありません。どの項目で修正が繰り返されるかを見れば、AIへの指示の問題なのか、CRM項目辞書の問題なのか、原記録の不足なのかを分けられます。

07.既存値の更新では置換・追加・併存・撤回を分ける

CRM入力は、新規登録より更新時の判断が難しくなります。新しい発言があるという理由だけで既存値を上書きすると、顧客が残した条件、比較中の候補、変更の経緯が消えるためです。

更新前に、既存値、新候補、根拠記録、更新関係を並べます。更新関係は少なくとも「置換」「候補追加」「条件付き併存」「明示撤回」「確認待ち」に分けます。

工務店例056で既存値がある場合の更新例を確認します。

新しい記録に既存値が引用されているだけの場合は更新しません。営業担当者が「前回は4,500万円と伺いました」と述べ、顧客が回答していないなら、最新の顧客確認になっていません。メールの引用部も同様で、最新本文と元の送信日時を区別します。

履歴には、変更日、変更前、変更後、更新関係、根拠記録ID、判断者を残します。CRMに履歴機能がない場合は、次のような一定形式で管理します。

`2026-09-29｜次回予定｜9月27日午前候補→9月29日14時来場予定｜置換｜MAIL-2026-041-05｜判定者：営業担当`

自由記述へ過去の文章を無制限に追記すると、現在値が分からなくなります。現在値は専用項目に置き、履歴は履歴欄または変更表に分離します。

顧客が後から条件を変えた場合と、AIが最初から誤っていた場合も分けます。前者は正常な案件更新、後者は抽出または照合品質の問題です。この区別がないと、顧客の希望変更までAIの誤りとして集計したり、根拠なし補完を「後から変わった」と処理したりします。

08.桁・単位欄・選択肢への変換だけを重点確認する

数字、日付、否定、話者など、文字起こし全体の照合方法は工務店の商談要約をAIで作る｜顧客の発言と営業の推測を分けるで扱います。CRM入力では同じ説明を繰り返さず、入力欄へ変換する際に起きる固有の誤りに絞ります。

CRM固有の確認点は、桁、単位欄、値と単位の対応、選択肢への押し込みです。

金額は、数値だけでなく次の要素を一組として扱います。

• 値または範囲
• 円、万円などの単位
• 総額、建物本体、付帯工事、諸費用などの対象
• 税込・税別
• 上限、目安、試算条件、希望返済額などの性質
• 発言者
• 確認日

面積も、坪と平方メートルを単位欄で分けます。CRMが平方メートルだけを受け付ける場合、換算規則と丸め規則を社内で定義し、原値も残します。AIが独自の換算や四捨五入をした値だけを保存すると、後から差を検証できません。

選択式項目に一致する値がない場合、近い選択肢へ押し込みません。「2027年夏休み頃」という希望に対して、起点が曖昧な「6か月以内」を選ぶと、時間の経過で意味が変わります。「未分類」「その他」「要確認」を使う条件を決め、同じ例外が続くなら項目設計を見直します。

「その他」に入れたまま放置すると集計不能になるため、月に一度などの頻度で内容を確認します。ただし、一案件だけの特殊条件のために選択肢を増やし続けると、担当者間の入力差が大きくなります。項目追加は、発生件数、利用目的、既存データへの影響を確認して決めます。

電話番号、メールアドレス、地番など、一文字の誤りが連絡先や物件を変える値は、AIによる画像認識や文字起こしから自動登録しません。相談票や顧客メールなど、直接確認できる表示と一文字ずつ照合します。読み取れない文字がある場合は、似た文字で埋めず保留にします。

09.評価表では誤りの種類と停止条件を分ける

AI補助の評価を「何分短縮したか」だけで判断すると、誤登録が後工程へ与える影響を見落とします。項目単位で採用、修正、保留、却下を記録し、どの条件で正式登録を止めるかを先に決めます。

以下は、工務店例056が四週間、20案件で試行すると仮定した架空の評価条件です。実在の成果値や推奨基準ではありません。評価する場合は、対象案件数、評価項目数、原記録の種類、担当者、AIや文字起こしの設定を固定し、途中で条件を変えた分は別集計にします。

「修正率10％」だけでは評価できません。100項目中10項目なのか、10項目中1項目なのかに加え、修正が表記統一なのか、総予算の対象範囲の誤りなのかで影響が違います。少なくとも次の情報を添えます。

• 試行期間
• 対象案件数
• 評価した候補項目数
• 項目別の件数
• 原記録の種類
• 採用、修正、保留、却下の件数
• 重大項目で発生した誤り
• AI、文字起こし、CRM項目辞書の版
• 判定担当者

停止条件は、自社の正式データへ反映するための運用基準であり、法令上の一律基準ではありません。たとえば「根拠のない学校名が一件でも正式登録された場合、同じ抽出条件の自動反映を停止する」「連絡先の桁誤りが起きた場合、画像からの連絡先抽出を対象外にする」のように、対象処理と再点検範囲を具体化します。

停止条件に該当したら、次の順序で対応します。

1. 同じ設定による正式登録または更新を止める 2. 対象期間、対象案件、対象項目を特定する 3. すでにCRMへ反映された値を原記録と再照合する 4. タスク、見積条件、営業資料など転記先を確認する 5. 誤った値を訂正し、訂正日と根拠を残す 6. 原因をAI指示、項目定義、原記録、操作手順に分ける 7. 修正後に限定範囲で再評価する

AIへの指示文を変えるだけで処理を再開すると、過去の誤登録が残る可能性があります。先に影響範囲を確認し、その後に原因に合った修正を行います。

10.個人情報を含む入力範囲と訂正経路を決める

商談記録には、氏名、住所、連絡先、家族構成、勤務先、土地情報、資金に関する発言などが含まれる場合があります。AIサービスへ入力する前に、利用目的、入力対象、保存設定、アクセスできる人、外部サービスとの関係、出力の保存先を、自社が実際に利用する契約と設定に即して確認します。

個人情報保護委員会の個人情報の保護に関する法律についてのガイドライン（通則編）では、利用目的をできる限り具体的に特定することや、個人データの性質、取扱状況などに応じて必要かつ適切な安全管理措置を講じる考え方が示されています。本記事の確認表や四判定は法令上の指定様式ではなく、誤登録を防ぐための独自の実務案です。

ガイドラインを参照しただけで、個別のAI利用が適法または安全と決まるわけではありません。入力する情報、利用目的、契約関係、保存期間、学習利用の有無、削除機能、委託や提供に関する整理などは、自社の条件に即して担当部門や、必要に応じて専門家へ確認します。

「氏名を消したから個人情報ではない」と一律に判断することも避けます。住所、勤務先、土地の所在地、家族構成、商談日時などの組み合わせによって、本人を識別できる可能性があります。何を除けばよいかを感覚で決めず、CRM入力の目的に必要な情報を項目ごとに選びます。

入力範囲を減らす方法には、次のようなものがあります。

• CRM入力に不要な雑談や家庭事情を処理対象から外す
• AI処理中は氏名ではなく案件IDを使う
• 氏名、電話番号、メールアドレスは別の確実な転記方法を使う
• 録音全体ではなく、対象項目を含む必要な部分だけを処理する
• 話者名を「顧客本人」「同席家族」「営業担当」に置き換える
• 出力後に不要となる中間ファイルの保存要否と削除方法を決める
• AIサービスの保存期間、入力データの利用条件、管理機能を契約書や設定画面で確認する

削りすぎて話者や時系列が分からなくなると、原記録照合ができません。必要最小限とは、単純に文字数を減らすことではなく、目的に必要な識別情報を残し、それ以外を含めないことです。

AI利用の役割、リスク管理、運用の見直しを検討するときは、経済産業省のAI事業者ガイドラインが示すAIガバナンスの考え方を参照できます。ただし、本記事の四判定、照合票、停止条件は同資料が定める公式様式ではありません。工務店がAI出力と人の承認を分けるための運用例です。

権限については、AI利用者、原記録閲覧者、CRM更新者、承認者が常に同じである必要はありません。資金情報や録音を閲覧できる人を業務上必要な範囲に限定し、担当変更や退職時の権限停止、共有リンク、端末への保存、出力の二次利用も確認します。

誤った個人情報を登録した場合に備え、訂正経路を決めます。まずCRMの現在値を止め、原記録で正しい値を確認し、訂正者と訂正日を残します。その後、誤った値がタスク管理、見積書、営業資料、メール下書きなどへ転記されていないかを確認します。AI画面の出力だけを削除しても、他の保存先は訂正されません。

11.小さな試行から照合判断票を標準化する

導入時から全項目を自動入力する必要はありません。原記録に明記されやすく、項目定義と照合方法を固定できる少数項目から始めます。ただし、希望エリアのように抽出しやすい項目でも、「確定」「候補」「条件付き」を区別できることが前提です。

試行範囲は案件数だけでなく、原記録の種類も固定します。顧客メールで問題が少なかった手順を、複数話者の録音へそのまま広げてはいけません。メール、相談票、文字起こし、図面では、誤りの型と確認箇所が異なります。

運用上の役割は、少なくとも次のように定めます。

小規模な工務店では一人が複数の役割を兼ねても構いません。ただし、「商談を担当した立場」と「CRM値を照合した立場」は記録上分けます。担当者の記憶だけで補わず、表示された根拠箇所を確認します。

例外も先に定義します。録音が途中で切れた、話者を判別できない、相談票の文字を読めない、家族間で希望が異なる、既存値の作成根拠がない、CRMの選択肢に該当値がない場合などです。例外時の基本動作は、近い値で埋めることではなく、正式値を維持または空欄にして確認経路へ送ることです。

最後に、案件ごとに次の照合判断票を完成させます。

工務店例056の案件を完了とする条件は、全欄が埋まることではありません。原記録と項目定義に合う値だけが登録され、提案試算条件が顧客予算と分離され、未合意の日程が正式予定にならず、保留項目に具体的な確認タスクが付き、根拠のない学区名がCRMに残っていないことです。

AIは空欄を埋めるために使うのではありません。担当者が原記録のどこを見ればよいかを絞り、既存値を更新できる条件と、更新してはいけない条件を明確にするために使います。採用、修正、保留、却下の境界を項目辞書と判断票で固定すれば、入力速度を上げながら、推測が正式データへ入り込む経路を減らせます。