工務店・ハウスメーカーのAI業務自動化 人の確認を残す場所を決める

AIで業務を自動化するとき、どこに人の確認を残せばよいのでしょうか。判断の出発点は、処理を間違えたときに誰へ影響し、どこまで戻せるかです。顧客への約束、提出金額、正式な工程、発注、支払いなどが確定する直前には、その内容を判断できる人を置きます。

一方、原本を変えず、社内の候補として保存し、誤りを見つけて容易に直せる処理は、個別の事前確認を減らせる場合があります。候補作成と送信・確定を切り分けると、確認が必要な場所へ担当者の時間を使えます。

本記事では、処理方法をL0「自動実行」、L1「事後確認」、L2「実行前確認」、L3「決裁」に分けて説明します。これは工務店の業務を考えるための独自分類で、公式ガイドラインの等級やAIの性能評価ではありません。

01.一つの業務を、候補作成と実行に分ける

「問い合わせ対応を自動化する」という単位では、確認点が決まりません。本文の分類、返信案の作成、担当者による修正、メール送信では、起こる影響が違うからです。

たとえば、AIの分類結果だけを人が見ても、その後に未確認の返信が自動送信されるなら、顧客への約束を止められません。逆に、分類候補を社内の仮欄へ保存するだけなら、送信と同じ確認方法を採る必要はない場合があります。

次は、従業員18人で新築とリフォームを扱う架空の「工務店例014」の設計例です。実在企業の運用実績ではありません。

入力から先の動作は、「入力取得→入力可否の判定→AI処理→候補保存→確認・決裁→実行」と書き出します。別システムの自動通知や書込みも含めると、見落としていた確認点が見つかります。

「仮登録」という名前だけでは影響を判断できません。登録と同時に担当者へ期限が通知され、正式工程へ反映されるなら、すでに業務上の影響があります。名称は仮のままでも、事前確認が必要になり得ます。

02.L0からL3は、影響と戻しやすさで選ぶ

水準を決めるときは、影響先、確定する内容、可逆性、情報の性質、根拠の確かさを見ます。点数を平均して重大な条件を薄めず、その処理で最も重い影響に対応できる方法を選びます。

L0も無管理ではありません。検索用索引のように原文へ戻れて再構築できるものでも、権限のない文書が検索に出たり、別案件の情報が混ざったりするなら、影響は軽くありません。内容と利用先を限定したうえで判断します。

L1とL0の違いは、人が継続的に見る必要がどこにあるかです。問い合わせの分類ミスは初動の遅れにつながるため、修正可能でもL1として滞留と誤分類を追う理由があります。

外部への送信も一律ではありません。会社が事前承認した固定の受付通知を、決めた条件で送る処理と、AIが個別に対応可否を書き換える返信は分けます。前者の自動送信を検討する場合も、宛先、適用条件、個別の約束を含まないことを設計段階で判断します。本記事でL2とする顧客返信は、AIが内容を作成・変更するものです。

L3の権限者は必ずしも社長とは限りません。既存の社内権限に従い、誰がその金額や条件を承認できるかを決めます。小規模な会社で同じ人が利用・確認・決裁を担う場合も、確認した根拠と決裁した条件は区別します。

03.外部AIへ渡す前にも判断が必要になる

出力を確かめても、入力してはいけない情報をすでに送っていれば、その送信は止められません。入力する項目、送信先のサービス、契約・設定、保存期間、学習等への利用、アクセス権を、自動化の開始前に決めます。

個人情報保護委員会の注意喚起は、個人情報取扱事業者に対し、個人情報の入力が特定された利用目的の達成に必要な範囲内かを十分に確かめるよう求めています。また、本人の同意をあらかじめ得ずに個人データを入力し、そのデータが応答結果の出力以外の目的で扱われる場合は、個人情報保護法に違反する可能性があるとしています。そのため、本人同意なく個人データを入力する場合は、提供事業者が当該個人データを機械学習に利用しないこと等を十分に確認します。学習に使われない設定だけで、あらゆる入力が適法になるという意味ではありません。生成AIサービスの利用に関する注意喚起等

架空例014の問い合わせ分類なら、希望工事と対象市区町村など、用途に必要な項目へ絞る方法があります。ただし「問い合わせ本文」という列を許可しても、自由記述内に家族事情、資金資料の内容、認証情報などが入る可能性は残ります。

自由記述を使うなら、許可された環境内で不要情報を除く工程を先に置きます。入力可否を判定するために、そのまま同じ外部AIへ全文を送る設計では、入力制限になりません。機械的な除去で扱いきれないものは担当者へ回し、対象を限定して始めます。

添付ファイル、複数案件が混ざる文書、対象外の保存場所、版不明の単価表なども、通常処理とは分けます。情報の取扱いを社内で判断できない場合は、情報管理責任者や必要な専門家へ、対象データと処理経路を示して判断を求めます。

04.確認者には、文章の自然さより判断の根拠を見せる

実行前の画面には、出力だけでなく、実行先、元資料、参照した版、変更箇所、実行後に起きることを近くに置きます。確認者が資料を探し回る構成では、読みやすい文章であることだけを理由に通してしまいやすくなります。

架空例：返信では、未確認の約束を見つける

「隣接市ですが、来週中に現地調査できますか」という問い合わせに、AIが「対応可能です。来週中に伺います」と答えたとします。問題は敬語ではなく、対応地域と日程を未確認のまま約束していることです。

受付後に担当者が確認して回答する運用なら、返信案は次のように戻せます。

お問い合わせありがとうございます。対象地域と現地調査の日程を担当者が確認し、結果をご連絡します。工事予定地の市区町村と、ご希望の時間帯をお知らせください。

すでに受け取っている情報は重ねて尋ねません。「2営業日以内に回答」などの期限は、実際に守れる体制がある場合だけ加えます。修正文に新しい約束を入れていないかも確認対象です。

架空例：見積では、不足候補から金額を確定しない

AIが「仕様一覧の食器洗い乾燥機が見積明細に見当たらない」と指摘しても、不足とは限りません。設備一式に含まれる、施主支給、別途工事、選択未確定などの可能性があります。L1で候補を集め、積算担当者が根拠を見て採否を決める形なら、確認作業を絞れます。

顧客提出額を変更する段階では、数量、単位、単価、税区分、値引き、端数処理、参照した単価表の版をそろえ、所定の決裁へ回します。合計が合うことと、見積内容が正しいことは別です。

架空例：議事録では、検討事項を仕事の約束へ変えない

顧客が「造作棚も気になりますが、予算を見てから考えます」と話した場合、確認できるのは「造作棚に関心があり、採用は未決定」ということです。この発言だけから、追加工事や期限を確定することはできません。

「概算を準備する」「次回打ち合わせ前まで」と正式タスクにするには、別途その作業と期限への合意が必要です。発言の抽出と、次の行動の提案を欄で分ければ、AIの提案を会議の決定事項と取り違えにくくなります。

05.承認を、実際に処理を止められる仕組みにする

指示文に「承認後に送信」と書くだけでは、送信の制御にはなりません。候補を作る処理には必要のない送信・発注・支払い権限を持たせず、実行する側が承認状態を確かめる構成にします。

承認する対象は、内容だけでなく宛先、添付、金額、接続先を含む最終版です。承認後にAIが文章を作り直したり、別の宛先へ差し替えたりした場合は、その承認のまま実行せず、変更に応じて再確認します。

確認画面には、承認のほかに、修正、差し戻し、保留、権限者への回付を用意します。資料不足を承認ボタンで解消させないためです。承認期限を過ぎた場合も、自動承認へ切り替えず、代理者へ回すか保留します。

記録は、一件の処理を追える範囲に絞れます。処理ID・案件ID、入力元、参照資料と版、修正前後、確認・決裁者と日時、実行先・成否がつながれば、誤りの原因と再実行の可否を調べられます。保存期間とアクセス権は既存の文書・顧客情報管理に合わせます。

06.緊急連絡と異常は、通常の確認待ちから外す

漏水や事故の連絡を、翌日の抜き取り確認まで待たせる運用にはできません。問い合わせの受付担当は、AIの仮分類とは独立して、受信時点で緊急性を拾う経路を持ちます。キーワードの検出だけに依存せず、分類されなかった連絡や未処理の受信も追えるようにします。

苦情、契約上の異議、個人情報に関する要請も、通常の営業返信へ混ぜず、それぞれの対応担当へ回します。AIの分類が受付自体を消したり、返答不要と確定したりしない設計が必要です。

処理上の異常は、影響の範囲で止め方を変えます。一件の入力不備ならその案件を保留できますが、別顧客の情報混入や誤った単価表の利用があれば、同じ処理や資料を使った案件全体を調べます。

誤送信、許可外の情報入力、承認前実行が疑われるときは、追加処理の停止と責任者への報告を直ちに行い、ログ・原本を保全します。影響範囲が分かるまで報告を待つのではなく、調査を並行させます。個人データの漏えい等については、事案に応じた内部報告・拡大防止、委員会への報告や本人通知の要否を確認します。個人情報保護委員会「通則編」

送信や支払いの成否が不明な場合は、同じ操作をそのままやり直しません。処理IDと外部側の履歴を照合して二重実行を防ぎます。復旧後の滞留案件にも、手作業で処理済み、期限切れ、担当変更が混ざるため、一括実行の前に対象を選び直します。

07.最初の試験では、誤りを止められるかを見る

導入試験は、許可された過去データや試験用データで、実際の送信・支払いへ影響しない環境から始めます。正しい候補が出ることに加え、入力不足、根拠なし、担当不在、処理失敗を試します。

L1の確認率を記録するなら、分母と期間を残します。架空例で、1週間に自動分類した80件のうち20件を確認した場合は `20件÷80件×100＝25％` です。25％だから十分とはいえません。通常案件の無作為抽出と例外案件の全件確認では、対象の選び方が違います。率に加え、誤りの内容、見逃した場合の影響、検出方法を記録します。

導入・運用リスクを考える参考として、IPAサイト掲載の「テキスト生成AIの導入・運用ガイドライン」があります。卒業プロジェクトの成果物であり、IPA等の見解を代表するものではありません。本記事のL0〜L3や試験表も独自の実務案です。

一つの自動化について、入力する情報、候補の保存先、確定する動作、確認者・決裁者、例外・停止条件、実行記録、再開判断を一枚にまとめます。その内容が実際の権限と連携設定に合うかを試せば、承認者の名前だけがある状態から進められます。

確認負担が増えた場合は、まず原文を探す手間や不要な生成を減らします。担当者名、案件番号、定型署名などを確定データから挿入できれば、AIの誤りを確認する対象も減ります。利用範囲、参照資料、モデル、接続先が変わったときは、影響する処理を再試験してから確認水準を見直します。