工務店・ハウスメーカーのデータ整理をAIで補助 表記ゆれと欠損の扱い

案件一覧の表記ゆれや空欄を、AIでどこまで整理してよいのでしょうか。AIに任せやすいのは、似た表現を集め、分類候補や調べるべき資料を示すところです。実際の担当者、契約金額、工事日などを推測で決める作業とは分けます。

整理後の表に必要なのは、見た目の統一だけではありません。「何を同じ分類にしたか」「何が未確認で、何は調べても分からなかったか」を説明できることです。原本と根拠を残しておけば、件数が変わったときに、事業の変化と整理方法の変更を区別できます。

以下は架空の「工務店例055」の設計例です。従業員12人の会社が、2019年4月から2025年3月までの案件一覧2,400行を整理する想定で、実在企業の実績ではありません。対象は案件番号、市区町村、工事種別、受注経路、担当者、契約日、完工日、契約金額の8項目。目的は年度別の工事種別、受注経路、市区町村別の経営集計で、請求、登記、本人確認には使いません。

01.どの集計に使うかで、そろえる範囲を決める

営業エリアの集計なら市区町村が分かれば足りる場合がありますが、契約書の住所では番地なども必要です。用途を決めずに「住所を正しくする」と依頼すると、不要な情報を扱ったり、集計には不要な細部へ時間を使ったりします。

工事種別も同じです。「新築」と「新築工事」は社内分類が同じならまとめられますが、「水回り」が改修か修繕かは工事内容と分類基準によります。「HP」と「ホームページ」をWebの大分類へまとめても、広告か自然検索かまでは分かりません。

最初は、工事種別の年度別件数のように、一項目、一期間、一目的で始められます。他の項目へ広げるときは、同じ分類規則を流用するのではなく、その項目に必要な根拠を選び直します。

02.原本と整理後の値を、同じ行へ戻れる形で残す

抽出したデータは、行数、列名、抽出日時、対象期間、抽出条件を付けて原本として保存します。作業は複製で行い、並べ替えても変わらない行IDを付けます。画面上の行番号や、重複する案件番号だけでは、変更履歴との対応が切れるためです。

架空例055なら、2,400行と8項目が取り出せたか、案件番号の空欄・重複は何件かを最初に見ます。重複候補はすぐ削除せず、集計対象外にする理由を残します。同じ案件の分割工事など、重複して見えても別行として必要な場合があるからです。

作業表には、原本値、整理後の値、状態、適用した規則と版、根拠、確認者・確認日を持たせます。列が多ければ、変更履歴を別表にし、行IDと対象項目で結べます。

外部AIへ渡すデータは、利用目的とサービスの取扱い条件に照らして先に選びます。氏名を削除したり社員名を番号に変えたりしても、それだけで個人を識別できない情報になるとは限りません。個人情報の取扱いは、利用目的や委託先管理などを実際の契約・処理方法に合わせて判断します。個人情報保護委員会「通則編」

この架空例では、AIへ渡す候補一覧から氏名、番地、電話番号、メールアドレス、自由記述を除きます。受付票や自由記述を調べる必要があるときは、権限のある担当者が許可された環境で読み、必要な分類根拠だけを取り出します。元資料を調べることと、全文を外部AIへ送ることは別の工程です。

原本や履歴のアクセス権、バックアップ、保存期間も決めます。中小企業向けの管理体制を考える参考には、IPAの中小企業の情報セキュリティ対策ガイドラインがあります。本記事の作業表や状態コードは独自の提案です。

03.表記ゆれは、文字の置換と意味の判断を分ける

前後の空白を除く処理と、「建替え」をどの工事種別へ分類するかは違う作業です。意味が変わらないと確認した形式変換、承認済みの別名対応、資料を要する意味判断に分けると、AIへ任せる範囲が明確になります。

架空例055：表記ゆれ辞書の一部

辞書には対象項目だけでなく、期間、適用条件、除外条件、根拠を持たせます。同じ文字列でも、年度や業務上の意味が変われば同じ分類にはできません。

担当者や協力会社などの名寄せでは、社内識別子が重要な手掛かりになります。ただし、識別子が同じでも番号の再利用があり得ますし、異なっていても重複登録や番号変更の可能性があります。識別子の不一致は自動統合を止める理由にし、同一か別対象かは台帳と履歴で判断します。

AIに渡すときは、全行より先に、未登録の値と出現件数を一覧にする方法があります。工事種別が80種類なら、その80種類から見るという架空の例です。工事内容などの文脈が必要な値は、同じ表記だからと全行へ一括適用しません。

架空例：AIには候補と確認理由を返させる

工事種別の原本値と、承認済みの分類規則を渡します。原本値、分類候補、判定、理由、規則IDを返してください。判定はMATCHまたはREVIEWです。候補は新築・改修・修繕に限り、一つに絞れない場合は候補なしとしてください。承認済み規則の条件を満たす場合だけMATCHとし、文脈や適用期間が不足する場合はREVIEWにしてください。原本値を変えず、工事内容を推測で補わないでください。

MATCHはAIの回答欄であり、人の承認や確定値ではありません。既存辞書の完全一致は通常の処理で検査し、新しい意味判断は担当者が資料を見て採否を決めます。承認した規則を辞書へ版付きで追加すれば、同じ条件の行へ再利用できます。

04.空欄は、調べる順番と調べた結果を分ける

空欄には、入力漏れ、元資料にもない情報、別表との結合失敗、移行時の欠落、適用外、権限上の非表示が混ざっています。一括で「その他」にすると、直せる不備と分からない情報の区別が失われます。

この例では、調査の手掛かりにE1〜E6を使います。原因が未判定の段階で、AIに一つの理由へ確定させる必要はありません。

先にE5・E6を調べ、次にE3・E4を見ます。結合や移行の問題を直せば、複数行がまとめて回復する可能性があるからです。その後、必要なE1を資料や担当者へ戻し、定めた資料を調べても分からないものを不明として閉じます。原因がE3・E4と分かっているなら、回復できなかったという理由で原因コードをE2へ置き換える必要はありません。

案件番号000123が数値として123になっていれば、推測でゼロを足す前に、元システムから文字列として取り直せるかを見ます。番号が年度や拠点ごとに再利用されるなら、それらを組み合わせたキーで一意に対応するかを調べます。

完工日が空欄でも、工事中なら実際の完工日はまだ存在しません。完工済み案件だけの集計では適用外ですが、工事管理では「未到来」として別に持つ方が分かりやすい場合があります。本番システムに既存の状態定義があれば、それを優先します。空欄自体を根拠に「未完工」と判断せず、案件状態や工事記録を使います。

契約金額を周辺案件の平均で埋めることは、事実の回復ではありません。分析上の推計が必要なら、推計額、方法、時点を別項目に置き、実績額と混ぜずに表示します。

05.値の状態と、見せてよいかを別々に持つ

調査結果は、次の状態で管理できます。コードはこの例の設計案で、公式な規格ではありません。

この状態とは別に、出力先へ値を表示できるかを持たせます。MASKEDはその表示区分です。たとえば、契約金額が根拠資料で確定していても、ある出力先には見せない場合があります。値の状態はVALUE、表示区分はMASKEDという二つの性質が両立します。

値や状態の詳細を扱うのは、権限のある管理側です。権限のない出力から中身を推測したり、非表示をUNKNOWNやゼロへ置き換えたりはしません。表示先に渡す状態情報そのものも、許可された範囲に絞ります。

PENDINGは、期限が来ただけではUNKNOWNになりません。未調査なら担当・期限を見直し、調査済みで特定できなかったときに、資料、確認日、理由とともにUNKNOWNにします。追加資料が見つかれば、再調査としてPENDINGへ戻せます。

割合は、権限内で評価できる対象を分母にする

この例で完工日の状態を比較するなら、対象期間と抽出時点をそろえ、適用対象である完工済み案件を選びます。そのうち表示・評価を許可されていないMASKEDの行は、欠損を評価する母集団から除き、除外件数を別に示します。

`対象D＝同じ抽出範囲の完工済み案件のうち、完工日を評価する権限があり、非表示ではない案件数`

`未確定率＝DのうちPENDINGの件数÷D×100`

`調査済み不明率＝DのうちUNKNOWNの件数÷D×100`

PENDINGには値が入っていても未承認のものがあり得るため、ここでは単なる空欄率と呼びません。Dがゼロなら率は算出しません。適用外・非表示の除外件数も併記し、権限や対象範囲が異なる集計の率をそのまま比較しないようにします。

受注経路の大分類はWebと分かり、小分類の広告・自然検索は分からない場合もあります。項目を分ければ、大分類VALUE、小分類UNKNOWNとして、分かった範囲を使えます。

06.本番へ反映する前に、誤統合と集計差を見る

AI候補の評価では、別の対象をまとめる誤統合と、同じ対象の別表記を残す見逃しを分けます。顧客や協力会社の誤統合は履歴を混ぜるため、全体の一致率が高くても見過ごせません。

評価データは、辞書や指示文の調整に使ったものと分けます。架空例で2,400行から120行を選ぶなら、先頭から取るのではなく、年度、工事種別、入力経路、欠損理由、珍しい表記を含めます。120行は説明用の数で、十分性を保証する標本数ではありません。誤りの影響とデータの多様性に応じて追加します。

割合を出す場合は対象期間と評価対象をそろえ、分母ゼロは算出対象外にします。AIの「高信頼」という表示は、原本や識別子の照合に代わるものではありません。

反映前後は、行数、行IDの重複・欠損、変更対象外の値、規則別の変更件数、分類別件数を比べます。PENDINGが確定値として使われていないか、非表示情報が出力へ混ざっていないかも対象です。

空白除去と意味分類は別の処理IDにすると、問題のある処理だけを戻しやすくなります。まず一項目で、保存、反映、集計、切り戻しを試します。表計算では正しくても、取込先の日付形式や先頭ゼロの扱いで変わる場合があるためです。

07.辞書を直した理由まで、経営資料へつなげる

変更履歴は、行ID、対象項目、変更前後、規則IDと版、根拠、確認者・日付、処理IDを結びます。経営資料には、対象期間、抽出時点、辞書の版、利用した状態、残る未確定・不明、集計対象外の件数を添えます。これにより、Web案件が増えた理由が営業活動の変化か、HP表記を統一した結果かを追えます。

辞書変更は、誤りの訂正、新しい別名の追加、分類基準の改定を分けます。たとえば紹介をOB施主紹介・協力会社紹介へ細分化しても、過去資料に紹介者区分がなければAIで配分しません。大分類を紹介、小分類をUNKNOWNとしたまま、過年度比較の限界を説明します。

繰り返し発生する入力漏れは、整理の後工程だけでなく入力元を見直します。契約前から契約日を必須にすると仮の日付を入れられるおそれがあるため、「契約済みに変えるときに必須」といった業務段階に合う条件を設けます。

入力元システムの誤字を正す場合は、権限のある担当者が変更履歴を残して訂正します。保存済みの抽出原本は書き換えず、新しい抽出データと旧原本を区別します。辞書で補正する場合も、どの時点の原本へ適用したかを残します。

初回整理後は、新規・変更行、新しい表記、期限を迎えたPENDING、改定規則の影響行を中心に見ます。モデルや指示文、入力の種類を変えたときは影響する評価データで再試験しますが、承認済みの辞書による確定値を理由なく再生成する必要はありません。

誤送信や権限外の共有が判明した場合は、追加の入力・同期・共有を止め、責任者へ直ちに報告して記録を保全します。影響調査と、共有停止や削除の可否を調べる作業を進め、法令上の報告・本人通知の要否は事案に応じて判断します。個人情報保護委員会「通則編」

整理の完了は空欄ゼロではありません。原本へ戻れ、変更の根拠があり、未確認と調査済みの不明を分け、集計できる範囲を説明できることです。その状態を一項目で作ってから広げれば、AIの候補抽出を日常の集計へ取り入れやすくなります。