工務店・ハウスメーカーの商談宿題をAIで抽出 担当・期限・確認先の点検

実務上の結論は、AIの役割を宿題の確定ではなく、候補抽出と欠落点の発見に限定することです。商談後に担当者が一から議事録を読み直すのではなく、AIが作った候補一覧を、担当・期限・確認先・完了条件の4点で点検します。この条件なら、営業、設計、積算、工務にまたがる宿題を整理しながら、約束していない内容や誤った期限が管理表へ入るのを防げます。

この記事では、商談記録全体の活用方法ではなく、「宿題を抜き出し、担当・期限・確認先を確定する作業」だけを扱います。追客全体の設計やAI活用の位置づけは、基幹記事の工務店のAI追客フロー｜下書き・確認・送信・記録を分けるを参照してください。

01.最初に「宿題」と「会話上の話題」を分ける

商談記録には、依頼、質問、希望、懸念、雑談、将来構想が混在しています。これらをすべて宿題にすると、タスクが膨らみ、本当に返答すべき約束が埋もれます。反対に、明確な依頼だけを拾うと、営業担当者が持ち帰った確認事項や、社内で判断が必要な保留事項を落とします。

この記事でいう宿題は、「商談後に誰かの行動または確認が必要で、その結果を案件関係者へ戻すもの」です。施主から明示的に頼まれたことだけでなく、担当者が「確認します」と回答したこと、社内判断に持ち帰ったこと、次回までに用意すると約束した資料も含みます。

一方、「吹き抜けもいいですね」「将来は犬を飼いたいです」のように、まだ行動を約束していない発言は要望や検討材料です。宿題候補と要望候補を別の欄に分けることで、AIが将来の希望を直近の作業へ変換する誤りを抑えられます。

この表から読み取るべきなのは、同じ発言でも、行動の約束が加わった時点で宿題へ変わることです。単語ではなく、「商談後に誰が何をすることになったか」という文脈で分類します。

宿題には社内向けと顧客向けがあります。たとえば「設計に壁を抜けるか確認する」は社内確認ですが、その結果を施主へ知らせるところまでが商談上の約束です。社内確認の完了だけでタスクを閉じると、回答漏れが起きます。

したがって、一つの宿題を「確認する作業」と「相手に返す作業」に分けることがあります。確認者と回答者が同じなら一件にまとめても構いませんが、設計が判断し営業が回答する場合は、受け渡しを見えるようにします。

この模式図で重要なのは、発言を拾った直後にタスク確定しない点です。「行動の約束」と「結果を返す相手」を確認してから、担当や期限の点検へ進みます。

02.AIへ渡す前に商談記録を整える

AIの抽出精度は、指示文だけでなく入力記録の書き方に左右されます。録音の文字起こしをそのまま渡すと、話者の取り違え、言い直し、否定表現の欠落が宿題候補へ持ち込まれます。まず、少なくとも商談日、案件識別子、出席者、次回予定、決定事項と保留事項を入力の先頭に置きます。

話者名は「担当」「奥様」のような曖昧な表記ではなく、「営業：S01」「施主：顧客1」のように役割と社内記号を組み合わせます。氏名と記号の対応表は社内の顧客元帳と社員台帳にだけ置き、AIへの入力には含めません。記号でも話者の取り違えは防げるうえ、人が原文へ戻るときは対応表から本人を確認できます。

以下では、架空の工務店と案件を一貫して例示します。実在の企業、施主、成果値を示すものではありません。

• 架空の工務店：若草工務店
• 案件識別子：A-2407
• 施主：顧客1（氏名との対応は顧客元帳で管理）
• 商談日：2026年9月20日
• 次回商談：2026年9月27日14時
• 社内関係者：営業・S01、設計・D01、積算・E01（氏名との対応は社員台帳で管理）
• 商談段階：基本プランと概算見積もりの調整中
• 今回の主題：キッチン配置、吹き抜け、概算予算、住宅ローン事前審査

AIへ渡す記録は、流暢な議事録に作り直す必要はありません。むしろ、原文と編集箇所の境界が分かる方が点検しやすくなります。聞き取れない箇所は想像で埋めず、「［聞き取り不能 18:32］」のように残します。

この表が示すのは、AIに渡す前の必須情報と、欠けたときの停止条件です。情報不足を「それらしい日付」や「通常の担当者」で補わないことが、後工程の手戻りを減らします。

個人名、連絡先、資金情報、家族構成などを外部のAIサービスへ入力する場合は、サービスの契約条件、保存条件、入力データの利用範囲、自社の利用目的と安全管理の手順を具体的に確認する必要があります。個人情報の利用目的や安全管理などの基本的な考え方は、個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」が一次資料です。

この記事では個別サービスへの入力が適法かどうかを一律には判断しません。利用する機能、契約、保存場所、入力内容によって条件が変わるためです。社内運用としては、抽出に不要な住所、電話番号、勤務先、具体的な借入額などを削り、案件識別子へ置き換えてから入力する方法が考えられます。

AI利用者を含む関係者ごとのリスク管理や、人による適切な判断を組み込む考え方については、総務省・経済産業省「AI事業者ガイドライン（第1.2版）」（2026年3月31日付）のうち、本編第5部「AI利用者に関する事項」を参照できます。以下の入力整形、確認欄、承認手順は、その資料に記載された工務店専用様式ではなく、本記事が提案する社内運用です。

03.抽出項目を固定し、AIに推測禁止を指示する

自由な要約を依頼すると、AIは読みやすい文章を作れても、管理に必要な欠落を隠してしまうことがあります。「次回までに確認予定です」という文章だけでは、担当も確認先も分かりません。そこで、出力欄を先に固定します。

最低限必要なのは、宿題ID、宿題の内容、実行担当、期限、確認先、回答先、完了条件、根拠発言、不足項目、確度です。「確認先」は情報や判断を得る相手、「回答先」は結果を返す相手として分けます。

たとえば設計可否であれば、確認先は設計担当または構造担当、回答先は施主です。設備の納期であれば、確認先は仕入先やメーカー窓口、回答先は営業担当を介した施主になる場合があります。この二つを一欄にすると、「社内では確認済みだが施主へ未回答」という状態を表現できません。

AIへの指示は、次のように作れます。

商談記録から、商談後に行動または確認が必要な宿題候補を抽出してください。
宿題ごとに「内容、実行担当、期限、確認先、回答先、完了条件、根拠発言、不足項目」を出してください。
記録にない担当者名、日付、確認先、仕様、金額は推測しないでください。
「来週」「次回まで」などは、記録冒頭の商談日・次回予定から確定できる場合だけ日付候補を併記してください。
約束されていない要望や雑談は「要望候補」として宿題から分離してください。
同じ宿題を言い換えた発言は統合し、統合した根拠を示してください。
判断できない項目には「要確認」と記載してください。

重要なのは、AIに完成形だけを求めず、不足項目も出させることです。空欄を許すと、担当者が見落とします。「要確認」という明示値を使えば、フィルターや件数集計も可能になります。

この表では、AIが埋める欄と、人が責任を持って確定する根拠を対応させています。欄を増やす目的は詳細な議事録を作ることではなく、行動できない宿題を目立たせることです。

確度は、AIの主観的な百分率に頼らない方が運用しやすくなります。「明示」「文脈から候補」「不足あり」の3区分程度にし、それぞれの条件を会社で固定します。数字の精密さより、なぜ人の確認が必要かを説明できる分類を優先します。

04.架空の商談記録から宿題候補を抽出する

若草工務店の架空案件A-2407について、入力記録の一部を次のように固定します。

施主・顧客1：吹き抜けをもう少し広くできますか。
営業・S01：構造との関係があるので、設計のD01に確認して、次回までに回答します。
施主・顧客1：キッチンを対面にした場合の差額も知りたいです。
営業・S01：設備の仕様をそろえてE01に見積もってもらいます。ただ、次回までに間に合うかは確認します。
施主・顧客1：住宅ローンの事前審査は、私たちで銀行に出しておきます。
営業・S01：では、提出できたかどうかを次回聞かせてください。
施主・顧客1：床はオークもいいですね。
営業・S01：サンプルを見てから決めましょう。手配するかは、今日ご家族で相談いただいても大丈夫です。
施主・顧客1：駐車場は2台必要です。
営業・S01：承知しました。配置案に反映します。

この記録では、吹き抜け、キッチン差額、ローン事前審査、駐車場反映が宿題候補です。床サンプルは手配の約束が確定していないため、現時点では要望または次回確認事項に分けます。

この結果から、AIは候補を並べられても、実行可能なタスクにするには人の判断が残ると分かります。とくにA-2407-02は、差額算出自体は引き受けていますが、期限について「間に合うか確認する」としか述べていません。AIが次回商談日をそのまま期限にすると、実際には約束していない納期を作ることになります。

A-2407-03では、行動主体は施主です。顧客側の宿題を社員の業務タスクと同じ扱いにすると、催促の頻度や責任範囲を誤解しやすくなります。管理表では「顧客行動」と区分し、工務店側には「次回商談で提出状況を確認する」という別の次回行動を置きます。

A-2407-R1は、宿題として確定させません。「手配するかを家族で相談する」という状態なので、営業側が勝手にサンプルを発注する根拠がないからです。次回の確認項目として残し、施主が希望した段階で「サンプルを手配する」という宿題へ切り替えます。

AIの抽出結果には、候補だけでなく除外候補も出させると便利です。除外理由があれば、「AIが床の話を見落とした」のではなく、「合意前なので宿題から外した」と人が判断できます。採用・保留・除外の履歴は、後から指示文を改善する材料にもなります。

05.担当は「発言者」ではなく実行責任で確定する

商談で返答した人が、必ずしも宿題の実行担当とは限りません。営業が「確認します」と言っても、技術判断は設計、金額算出は積算、発注可否は工務が担うことがあります。AIが発言者を担当者として固定すると、営業担当者の一覧にすべてが集中します。

そこで、実行担当と案件責任者を分けます。実行担当は成果物を作る人、案件責任者は期限までに顧客へ結果が返ることを管理する人です。若草工務店の例では、吹き抜け可否の検討はD01、顧客回答の管理はS01になります。

さらに、受け渡しがある宿題では「依頼元」「実行担当」「承認者」「回答者」を必要な範囲で置きます。すべての宿題に4人を設定する必要はありません。一人で完結するなら実行担当だけで十分です。しかし、部門をまたぐ項目を一人の名前で表すと、どこで止まっているのか分からなくなります。

この表からは、「担当者を一人決める」だけでは足りず、どの成果を誰が持つかを明示する必要が読み取れます。とくに技術確認と顧客回答を別タスクにすると、社内で結論が出たまま連絡されない状態を把握できます。

担当が決まらない場合、AIに組織図から推測させるのではなく、割当責任者を決めます。たとえば「未割当の宿題は当日中に営業責任者が割り当てる」と社内ルールを置きます。当日中という時間設定は本記事の提案例であり、各社の商談件数や勤務体制に合わせて決めるものです。

兼務の多い工務店では、役割名だけでも曖昧になります。「設計担当」と書いた結果、設計もできる営業と外部設計事務所のどちらが動くのか分からない場合があります。管理表には、実際に通知を受け取る個人または委託先名を確定欄として持たせます。

休暇、定休日、外注先の回答待ちも考慮します。担当者を決めた時点で終わらず、期限内に不在なら代替担当を置くのか、期限を顧客と再合意するのかを選びます。AIは勤務予定や契約上の連絡経路を知らないことがあるため、ここは人の点検対象です。

06.期限は約束日・社内期限・再確認日を分ける

期限の誤りは、抽出漏れと同じくらい実務への影響があります。「次回までに」という発言を次回商談の開始時刻に設定すると、資料を準備して説明する余裕がありません。顧客との約束日と、社内で成果を受け取る期限を分ける必要があります。

若草工務店の次回商談は2026年9月27日14時です。吹き抜け可否をその場で説明するなら、D01の確認結果をS01が事前に読み、図面や説明を整える時間が必要です。仮に社内ルールを「顧客回答の1営業日前まで」と決めるなら、休日や勤務予定を踏まえて社内期限を計算します。

ここで重要なのは、「1営業日前」が法令や共通基準ではなく、自社が決める運用値だということです。案件の難易度、承認者、定休日によって変えて構いません。固定値を置く場合は、誰がどのカレンダーで計算するかまで決めます。

期限には少なくとも次の三つがあります。

1. 顧客約束期限：施主に回答・提出すると合意した日時 2. 社内完了期限：確認、作成、承認を終えて回答者へ渡す日時 3. 再確認日：外部回答待ちなどで完了日を確定できないとき、進捗を見直す日時

「メーカーへ問い合わせたので待つ」という状態に期限がないと、タスクが無期限に滞留します。回答予定日が得られなければ、完了期限を捏造せず、再確認日を設定します。再確認日に回答がなければ、再問い合わせ、代替案検討、顧客への中間連絡のいずれかを選びます。

この順序で読むと、社内都合の締切から顧客約束を作らないことが分かります。まず合意内容を確認し、その約束を守るための社内期限を逆算します。

この表が示すように、曖昧な期限を無理に日付へ変換してはいけません。ただし放置もせず、「期限をいつまでに回答するか」という宿題へ変えます。

期限変更には履歴を残します。元の顧客約束期限、新しい期限、変更理由、顧客への連絡日時、合意者を記録します。単に日付を上書きすると、遅延したのか、顧客都合で変更したのか、前提条件が変わったのか判別できません。

次回商談が未確定の場合、「次回まで」を日付に変換できません。このときは、次回日程の確定タスクと宿題本体を関連付けます。日程が決まったら期限候補を再計算し、担当者が承認します。AIによる自動更新を使う場合でも、顧客との約束を書き換える処理には人の確認を残します。

07.確認先と回答先を点検して行き止まりをなくす

宿題には、情報を得るための確認先と、その結果を届ける回答先があります。確認先がない宿題は、担当者が「誰に聞けばよいか」を探すところから始まります。回答先がない宿題は、社内で処理済みになっても顧客への返答が漏れます。

確認先は必ずしも人とは限りません。承認済み図面、見積条件表、メーカーの正式資料、自治体の案内窓口など、判断の根拠となる資料や窓口を指定する場合もあります。ただし、AIがウェブ上の一般情報から個別案件の結論を作る運用とは分けます。

確認先は次の三層で考えると整理しやすくなります。

• 社内確認先：設計、積算、工務、経理、責任者など
• 外部確認先：仕入先、メーカー窓口、外部設計者、金融機関など
• 顧客確認先：施主本人、共有名義人、家族内の意思決定者など

顧客確認先では、誰に聞けば合意になるかを勝手に決めないことが大切です。夫婦や家族の一方が商談へ参加していても、すべての決定権限を持つとは限りません。商談で確認した連絡方法と意思決定の進め方に従います。

架空案件A-2407の吹き抜け確認では、「設計のD01に確認する」と記録されています。しかし、D01が構造判断まで行うのか、別の構造担当へ照会するのかは不明です。タスクの確認先をD01としたうえで、「追加判断先の要否」をD01が判定する欄を置きます。

キッチン差額では、積算のE01へ依頼する前に、比較する設備仕様をそろえる必要があります。元の仕様と対面案の仕様が異なれば、差額が配置変更によるものか、設備グレードによるものか分からなくなります。したがって、積算依頼の前提条件として「比較条件の承認」を置きます。

この修正例で注目したいのは、「聞く」「伝える」を完了条件にしない点です。判断結果、図面反映、差額資料、顧客への説明記録など、次の工程が使える状態まで書き換えます。

確認先から回答が来ない場合も先に分岐を決めます。顧客期限に影響しないなら再確認日を更新します。影響するなら、回答者である営業が顧客へ中間連絡し、未確定事項、現在の確認先、次に連絡する日時を伝えます。未確定の結論をAIで補って回答することは避けます。

確認先が複数あるときは、並列か直列かを区別します。設計可否と概算費用を同時に調べられるなら並列です。設計可否が出なければ積算できないなら直列です。この関係が曖昧だと、後工程の担当者へ早すぎる依頼が届きます。

この流れは、社内確認が終点ではないことを示します。顧客へ回答し、その反応や追加条件を記録して初めて、商談上の宿題を閉じられます。

08.完了条件と証跡を決め、終わったつもりを防ぐ

「確認済み」「対応済み」という状態名だけでは、何が終わったか分かりません。完了条件は、第三者が記録を見て、次の行動に進める状態を判定できるように書きます。

吹き抜けの例なら、「D01へ依頼を送った」は着手です。「可能ですと口頭で聞いた」は社内確認の途中です。「可否、条件、図面への影響を記録し、S01が顧客1へ説明した」が顧客約束としての完了候補になります。

ただし、宿題の範囲によっては図面更新まで含めない場合があります。今回の約束が可否回答だけなら、詳細図面の完成を待つ必要はありません。反対に「次回は修正プランを見せる」と約束していれば、口頭回答だけでは未完了です。完了条件は元の約束に合わせます。

証跡は、作業を増やすためではなく、回答内容と根拠を再確認するために残します。管理表のコメント、承認済みファイルへのリンク、送信メール、商談記録の追記など、会社が継続して保管できる方法を選びます。

この表から読み取れるのは、宿題ごとに完了地点が異なることです。社内で成果物ができれば終わる作業と、顧客への説明まで必要な約束を同じ「完了」で扱わないようにします。

証跡には版を識別できる情報を添えます。「修正図面.pdf」だけでは、どの版を説明したか分かりません。「A-2407_配置案_20260925_v03」のように案件、内容、日付、版を組み合わせる方法があります。命名規則は自社の文書管理に合わせ、個人情報を不要にファイル名へ含めないようにします。

顧客へ口頭で回答した場合も、説明日時、説明者、要点、顧客の反応、残った保留事項を商談記録へ追記します。顧客がその場で決めなかったなら、元の確認宿題を完了にし、新たに「顧客判断待ち」または「次回確認」を作ります。一件を永久に開いたままにしない方が経緯を追いやすくなります。

完了後に前提が変わった場合は、過去のタスクを未完了へ戻すより、新しい宿題として関連付けます。たとえば吹き抜け可否を回答した後で寸法条件が変わったなら、「変更後寸法で再確認」を新規作成します。過去に何を前提として回答したかを残せるからです。

09.人が直すべきAI出力を評価表で判定する

AI出力は、文章の自然さではなく、業務へ登録できるかで評価します。読みやすくても、担当や期限が推測なら不合格です。多少ぎこちない文章でも、根拠発言と不足項目が正しく示されていれば、人が短時間で修正できます。

評価単位は、商談記録全体ではなく宿題一件ごとにします。一件の重大な誤りが、ほかの正しい抽出に埋もれないようにするためです。さらに、抽出されなかった宿題も確認する必要があります。

次の評価表は本記事独自の運用提案です。点数をAIの性能保証に使うものではなく、人が登録可否をそろえるための社内基準として使います。

この表の読み方は、合計点だけで自動承認しないことです。たとえば期限の捏造や担当者の誤指定は、総点が高くても登録を止めるべき重大項目です。各社で「0点なら必ず差し戻す項目」を決めます。

架空案件A-2407-02のAI出力が「E01が9月27日までに対面キッチンの差額を提出」となっていた場合、内容と担当は候補として妥当でも、期限には問題があります。原文は「次回までに間に合うか確認します」であり、提出を約束していません。

修正後は、宿題を二段階にします。

• S01がE01へ必要期間を確認し、顧客1へ差額提示日を回答する
• 比較仕様の確定後、E01が差額を算出する

最初の宿題にも期限がなければ、顧客へいつ回答するかをS01が決め、必要なら顧客1と合意します。AIが勝手に9月27日を置くより、一度「期限回答」という小さな宿題に分ける方が約束を正確に管理できます。

A-2407-01が「S01が吹き抜けを広げた図面を次回提出」と抽出された場合も修正が必要です。原文で約束したのは可否確認と回答であり、修正図面の提出までは明示されていません。親切のつもりで範囲を広げると、設計の予定や顧客期待を変えてしまいます。

評価結果は、AIの出力、担当者の修正、最終確定内容を並べて残すと改善に使えます。ただし、すべての商談を永久に保存するという意味ではありません。保存期間やアクセス権は、自社の情報管理方針と利用サービスの条件に合わせて決めます。

誤りの傾向が続く場合は、毎回手修正するだけでなく指示文を変えます。「次回までに間に合うか確認」を納品約束と誤認するなら、「可否を確認すると述べた場合、成果物の提出期限へ変換しない」と例外規則を追加します。

10.登録前レビューから遅延対応までを一つの運用にする

AI抽出を導入しても、誰がいつレビューするかが決まっていなければ管理表へ入りません。商談担当者、割当責任者、各実行担当の役割を分け、短い受け渡しにします。

商談担当者は、AI出力を原文と照合し、宿題ではない要望を除外します。割当責任者は、未割当項目と部門間の優先順位を決めます。実行担当は、自分が受け取った内容、期限、前提条件を確認し、実行不能なら理由を返します。

ここでいう承認は、すべてを上長が決裁する重い工程ではありません。顧客との約束を管理表へ正式登録してよいかを確認する作業です。金額、構造、安全、契約条件など、別の承認が必要な内容は自社の既存手順へ接続します。

この流れでは、AI出力から担当者への自動通知までを一気に進めません。商談担当による原文照合と、未割当処理を通してから実行へ移します。

案件数が少ない会社なら、専用システムを用意せず、表計算や既存の顧客管理ツールでも運用できます。重要なのはツール名ではなく、要確認項目を抽出できること、変更履歴を追えること、案件との対応が分かることです。

管理表には次の状態を用意すると、止まっている理由を判別しやすくなります。

この状態表で見るべきなのは、「外部回答待ち」と「顧客判断待ち」を対応中から分けている点です。担当者が作業を怠っているのか、相手の回答を待っているのかを区別できます。

AIの候補抽出から登録までの時間も、各社で目安を決めます。ただし、商談件数や勤務形態が異なるため、全国共通の適正時間は置けません。まず数週間分を観察し、顧客約束に間に合わなかった原因が「抽出の遅れ」「割当の遅れ」「実行の遅れ」のどこにあるかを分けます。

遅延が見込まれたら、期限当日まで待たずに分岐します。前提不足なら顧客へ確認し、社内工数不足なら代替担当または期限再合意を検討し、外部回答待ちなら中間連絡を行います。AIに謝罪文を作らせる前に、現在分かっている事実と次の連絡日時を人が確定します。

宿題の件数が多い案件では、優先度を「顧客約束への影響」「後工程を止めるか」「金額や設計条件への影響」で決めます。AIが重要度を提案しても、案件の契約状況や社内負荷を知らなければ誤るため、最終順位は案件責任者が決めます。

商談から次回行動を漏らさない管理方法を広げたい場合は、工務店の次回行動管理｜期限と担当を漏らさない仕組みで、案件横断の管理へ接続できます。本記事は、その前段となる一回の商談記録からの宿題確定に範囲を絞っています。

11.例外処理を先に決めてAIの誤確定を止める

平常時の手順だけでは、実際の商談に対応しきれません。宿題が衝突する、施主の発言が途中で変わる、同じ内容を複数人が引き受ける、次回日程が変更される、といった例外が起きます。

一つ目は、同じ宿題に異なる期限が現れる場合です。商談前半で「来週」、後半で「次回打ち合わせ」と述べ、両者の日付が違うことがあります。AIには新しい発言を自動採用させず、「期限衝突」と表示させます。どちらが最終合意かを発言の流れと当事者の確認で決めます。

二つ目は、否定や撤回です。「サンプルをお願いします」の後に「やはり今は不要です」と変わった場合、最終状態は取消です。ただし、発注済みなら単純な削除では済みません。取消可否、費用、返却方法などを担当者が確認し、新たな対応として管理します。

三つ目は、条件付きの依頼です。「予算内なら造作洗面も見積もってほしい」は、予算内かどうかの判定条件が曖昧です。AIが即座に見積依頼へ変えず、「予算上限の確認」「比較対象の確定」を前提タスクとして出すようにします。

四つ目は、顧客と工務店の認識が食い違う場合です。社内記録では「検討」となっていても、顧客が「次回に見積もりが出ると思っていた」と認識していることがあります。記録だけを根拠に顧客の認識を否定せず、何をいつ回答できるかを改めて合意し、その経緯を残します。

五つ目は、AIが一件を細かく分けすぎる場合です。「設計へ聞く」「返答を受ける」「営業へ送る」「顧客へ電話する」をすべて独立タスクにすると、管理負荷が増えます。担当が同じで連続して実行できる工程は一件にまとめ、担当交代、承認、外部待ちがある場所で分けます。

反対に、一件へまとめすぎる場合もあります。「プランと見積もりを修正して次回説明する」という宿題には、設計変更、積算、社内照合、顧客説明が含まれます。担当や完了時期が異なるなら親宿題と子宿題に分け、親宿題は全工程の完了を表します。

この表から分かるのは、例外を「AIの失敗」として削除するだけでは足りないことです。衝突、撤回、前提不足などの印を残し、人が取るべき行動へ変換します。

次回商談日が変更されたとき、すべての「次回まで」の期限を自動で移動するのも危険です。すでに旧日程を基準に外注先へ依頼しているかもしれず、期限を早める約束として別途合意している可能性もあります。影響対象を一覧化し、一件ずつ変更要否を承認します。

AIが原文にない金額、製品仕様、制度利用可否を補った場合は、その箇所を削除するだけでなく、入力と指示を点検します。別案件の情報が混ざっていないか、検索機能や外部情報参照が有効になっていないか、過去のテンプレートを事実として扱っていないかを確認します。

制度、法令、性能、製品仕様に関する質問は、宿題として抽出できても、AI回答だけで顧客へ確定説明しません。該当する一次資料、正式な窓口、担当専門家など、案件に応じた確認先を設定します。この記事で確認済みの一次資料も、個別案件の結論を代行するものではありません。

12.自社で使える「担当・期限・確認先の点検票」を完成させる

ここまでの成果物は、長い議事録や高度なAI設定ではありません。商談ごとに宿題候補を並べ、担当・期限・確認先・回答先・完了条件を人が確定する点検票です。

点検票は、AI出力の貼り付け欄と最終確定欄を分けます。AIが出した内容を直接上書きすると、どこを人が修正したか分からなくなるからです。少なくとも試行期間中は、修正前後を比較できる形にします。

この点検票から読み取るべきなのは、宿題の文章だけでなく、根拠から完了までを一続きにしている点です。AIの役目は左側の候補作成を速めることであり、右側の合格判定まで代替するものではありません。

架空案件A-2407-01を最終確定すると、次のようになります。

• 宿題ID：A-2407-01a
• 宿題内容：吹き抜け拡大の可否と、可能な場合の条件を確認する
• 実行担当：設計・D01
• 社内期限：若草工務店の営業日カレンダーで別途確定
• 確認先：設計・D01。追加の構造確認が必要な場合はD01が照会先を指定
• 回答先：営業・S01
• 完了条件：可否、前提寸法、付帯条件、追加検討の有無が記録され、S01へ共有される
• 根拠：2026年9月20日の商談で、S01が「設計のD01に確認して次回までに回答」と発言
• 不足項目：社内期限、追加の構造確認先

続く顧客回答は別にします。

• 宿題ID：A-2407-01b
• 宿題内容：吹き抜け拡大の確認結果を顧客1へ説明する
• 実行担当：営業・S01
• 顧客約束期限：2026年9月27日14時の次回商談
• 確認先：A-2407-01aの確認結果
• 回答先：顧客1
• 完了条件：可否と条件を説明し、顧客1の意向と残った保留事項を商談記録へ追記する
• 前提：A-2407-01aが完了していること

この二件へ分けることで、D01の技術確認が終わっているのにS01が未回答なのか、D01の確認自体が終わっていないのかを判別できます。小規模な組織でD01とS01が同一人物なら、一件へまとめても構いません。

導入初期は、AIが何件抽出したかより、人がどの種類の修正をしたかを見ます。「担当の推測」「期限の捏造」「要望の宿題化」「回答先の欠落」などに分類すると、自社の記録方法や指示文の弱点が見えてきます。

修正件数を比率で見る場合は、分母を明記します。たとえば「修正が必要だった宿題数 ÷ AIが抽出した宿題候補数」とし、対象期間と商談件数も添えます。ただし、抽出されなかった宿題は分母に入らないため、この比率だけで品質を判断できません。原文から人が追加した宿題件数も別に記録します。

運用開始時には、すべての担当者へ一度に展開するより、商談の種類を限定して点検票を試す方法があります。新築初回相談、プラン調整、見積説明では宿題の性質が異なるため、同じ指示文で十分とは限りません。どの商談種別で試したかを記録します。

追客の頻度や連絡内容まで決めたい場合は、工務店の追客戦略｜検討段階に合わせた関係づくりが隣接領域です。本記事の点検票は、追客シナリオそのものではなく、一回の商談で生じた具体的な約束を確定するために使います。

最後に、登録前の判断を一文にまとめます。「原文へ戻れるか、実行担当が受領できるか、顧客約束と社内期限を区別したか、判断を得る確認先があるか、結果を返す相手がいるか、完了を証跡で判定できるか」です。一つでも答えられなければ、自動登録せず要確認へ戻します。

AIを使う価値は、宿題を勝手に確定することではありません。人が見落としやすい発言を候補として並べ、不足している担当・期限・確認先を同じ様式で点検できることにあります。最終判断を人に残しながら、商談後の読み返しを「全文から探す作業」から「候補の根拠を確かめる作業」へ変えるのが現実的な使い方です。