AI・自動化

AIで顧客リストの表記ゆれを直す:関数と候補提案の使い分け

顧客リストの表記ゆれは関数とAIでどう分けるか。TRIM・CLEAN・UNIQUE、候補表、過剰修正、顧客IDによる反映、確認費用を説明します。
この記事の内容
  1. 文字の整形と同じ顧客への統合を分ける
  2. 関数で直せる範囲を先に試す
  3. AIへ渡すのは修正ではなく候補の依頼にする
  4. 合成100行では直さない行も入れる
  5. 反映は元データを残して小分けに行う
  6. 一度きりの整備と毎月の運用で費用を変える
  7. 関連記事

顧客リストの整備では、余分な空白を消す作業と、似た名前が同じ会社かを判断する作業を分けましょう。前者は表計算の関数で処理できる場合があります。後者はAIの候補が参考になっても、顧客IDや取引記録との照合が必要です。

最初から元の名簿を上書きせず、元の値、修正候補、変更理由、確認結果を残す形にします。個人事業や数人の会社でも、この分け方なら処理を取り消したり、取引先へ正式表記を確認したりしやすくなります。

文字の整形と同じ顧客への統合を分ける

「会社名の前後に空白がある」と「同名の会社が二つある」は異なる問題です。見た目が似ていても、別法人や別支店かもしれません。同じ取引先でも、請求先と配送先を別の行で管理する理由がある場合もあります。

作業最初に使う方法人が確認すること
前後の半角空白を整理表計算の関数空白を消してよい列か
決まった略称を置換承認済みの対応表正式表記との一致
似た社名を集める検索やAIの候補提案同一法人か別法人か
住所を補う確認済みの原本照合支店・部屋番号の違い
顧客行を統合する業務上の承認請求や連絡履歴への影響

社名の「株式会社」の位置をそろえることも、単なる見た目の修正とは限りません。正式名称を変えてしまうため、前後を勝手に入れ替えず、取引先が示した情報に合わせてください。

関数で直せる範囲を先に試す

GoogleスプレッドシートのTRIMは、先頭・末尾や繰り返すスペースを整理する関数です。例えば元の値をA2に置き、隣の列で「=TRIM(A2)」を使う形なら、元の値と比較できます。全角空白や特殊な空白まで、すべて同じ扱いになるとは思い込まず、対象の文字で確認します。GoogleのTRIMヘルプ

CLEANは印刷できないASCII文字を除く関数で、すべての不可視Unicode文字を消すものではありません。見た目が変わらない問題もあるため、万能な名簿修正として使わないようにします。GoogleのCLEANヘルプ

重複行を抽出するUNIQUEも、似た社名が同じ顧客かを判断する機能とは区別します。比較する列に住所や担当者が含まれるかで、同じ行と扱う範囲が変わります。GoogleのUNIQUEヘルプ

AIへ渡すのは修正ではなく候補の依頼にする

AIを使う場合は、「似ている値を候補として列挙し、理由を示す」処理から始めます。「誤りを全部直す」と依頼すると、正しいが珍しい社名や住所まで一般的な表記へ変える可能性があります。

架空の名簿で「青葉デザイン」「青葉デザイン合同会社」が並んでいても、同一と断定できません。AIには同一候補として出させ、確認方法は請求書、契約書、顧客IDなどの社内記録に戻します。外部検索で見つけた似た会社を、自社の取引先へ自動的に当てはめないようにします。

出力列は、行ID、元の値、候補、変更理由、確認状態とします。メールアドレスや口座の数字を「自然な形」に修正する用途には使いません。個人情報を含む名簿をサービスへ渡す前に、利用目的、契約、入力してよい範囲を確認します。

合成100行では直さない行も入れる

比較用のデータは、正しい値を先に作り、一部へ意図的な表記の違いを加える方法で用意できます。100行なら、直すべき行、同じに見えるが別の顧客の行、そのままで正しい行を混ぜます。ここでの100行は試験設計の例であり、特定の精度を保証する数ではありません。

架空の採点例として、変更すべき20行のうち18行を正しく修正し、変更不要の80行のうち3行を誤って変えた場合を考えます。修正できた割合は18÷20で90%ですが、3行の過剰修正も残っています。「90%正しい」とだけ見ると、元は正しかった情報を壊した問題が見えません。

修正漏れと過剰修正を別々に記録し、住所、社名、連絡先などの列ごとにも分けます。正確さが必要な連絡先では、候補の数を減らしてでも人へ戻す条件を厳しくするなど、用途に合わせて判断します。

反映は元データを残して小分けに行う

本番ではまずコピーへ処理し、変更があった行だけを確認します。元のリストは読取専用の版として保管し、いつのデータにどのルールを使ったか残してください。大量に上書きしてから元へ戻す方法を考える順序は避けます。

確認済みの候補だけを、顧客IDなどの変わらない識別子で元の管理先へ反映します。行の並び順だけで対応を取ると、途中の並べ替えや行追加で別の顧客へ反映してしまいます。取込後に件数と代表的な行を照合し、請求や通知など後続処理も確認します。

修正した一覧を社内で共有する際も、利用者全員に変更権限が必要とは限りません。名簿の編集担当を決め、確認待ちの候補が正式情報として使われないよう、保存先と表示を分けます。

一度きりの整備と毎月の運用で費用を変える

一度きりの名簿整理なら、定額サービスを長く契約するより、関数と目視確認で十分な場合があります。毎月複数の受付経路からデータが増えるなら、入力フォームの選択肢や対応表を整え、表記ゆれが発生する場所を減らすことも検討します。

架空の計算例で、準備に2時間、確認に100行当たり30分かかる設計なら、1,000行で合計7時間です。AIの候補が増えすぎると、確認時間が長くなる場合もあります。実際の自社データで必要な確認を含めて測り、生成にかかった時間だけで判断しないようにします。

フォーム回答の保存と通知で入力側を整理し、不要な情報は顧客データの保存・削除ルールで見直せます。まず関数で機械的に直せる部分を分離し、同一顧客かの判断だけを候補表へ集めると、AIを使う価値のある工程を絞れます。

関連記事

情報の確認について

料金・機能は記事内に記載した確認時点の情報です。申し込み前に公式サイトで最新の条件をご確認ください。

主な情報の確認日:2026.10.08

編集方針・情報の確認方法 →