IMPLEMENT — 実装ノウハウ ／ 初級〜中級

散らかったデータをAIで整える方法｜表記ゆれ・名寄せ・分類を自動化する実務手順

なぜ「散らかったデータ」は手作業とExcel関数で直りきらないのか

「同じ会社なのに『(株)山田商事』『株式会社山田商事』『ヤマダ商事』が別々の行として存在する」——多くの中小企業の顧客リストで実際に起きている状態です。データが散らかる典型パターンは次の3つに整理できます。

• 表記ゆれ: 全角/半角、法人格の略記、カタカナ/英字、旧字体、スペース有無など、同じ対象の書き方が揃っていない
• 名寄せ漏れ: 同一の顧客・企業・商品が複数行に重複登録され、集計や案内が二重になる
• 分類の欠落・不統一: 業種・商品カテゴリなどの分類列が空欄だったり、担当者ごとに基準がバラバラ

従来の対処は、Excelの置換・SUBSTITUTE関数・VLOOKUPによる突合でした。これらは「パターンを人間が列挙できる範囲」では有効ですが、『ヤマダ商事＝株式会社山田商事』のような文字面が一致しない同一判定や、「商品説明文からカテゴリを推測する」ような判断はルール化しきれません。結果として、置換ルールが数百行に膨らんだ末に、最後は目視チェックに戻る——というのがよくある行き詰まりです。

ここにLLM（ChatGPTやClaudeなどの大規模言語モデル）を組み込むと、「文字が違っても意味が同じ」を判定できるようになり、ルールベースでは届かなかった最後の2〜3割を自動化できます。ただし後述の通り、LLMは万能ではなく、使いどころを間違えるとコストと誤りが増えます。

ルールベースとAI（LLM）の使い分け——先にルール、残りをAI

実装の大原則は「決定的に処理できるものは先にルールで潰し、判断が必要な残りだけをLLMに渡す」です。理由は3つあります。ルール処理は（1）無料で高速、（2）結果が毎回同じ（再現性がある）、（3）間違いの原因を特定しやすい。LLMはその逆で、柔軟な代わりにコストがかかり、出力が揺れる可能性があります。

この順序にすると、LLMに渡す件数そのものが減るため、API費用と検証の手間が大きく下がります。体感としては、ルール処理だけで7〜8割の行は片付き、LLMが必要なのは残りの「人間なら分かるが機械には難しい」部分です。

なお住所については、LLMに丸ごと正規化させるより、まず公的な住所データ（デジタル庁アドレス・ベース・レジストリや郵便番号データ）と突合し、マッチしなかった行だけLLMで補正する構成が精度・コストとも有利です。

そのまま使えるプロンプト例——正規化・名寄せ・分類の3パターン

LLMをデータ整備に使うときのプロンプトには共通の型があります。（1）出力形式を固定する（JSONや表）、（2）判断基準を明示する、（3）迷ったら『不明』と答えさせる逃げ道を用意する——の3点です。逃げ道がないと、LLMは無理にでも答えを作ってしまいます（ハルシネーション）。

例1: 会社名の正規化

• 「以下の会社名リストを正規化してください。ルール: 法人格は『株式会社』等の正式表記に統一し前株/後株は原文のまま維持、全角英数は半角に、余分なスペースは削除。元の値と正規化後の値をJSONで出力。判断できない場合は normalized を null にしてください。」

例2: 名寄せ（同一判定）

• 「以下の2件の顧客レコード（社名・住所・電話番号）が同一企業か判定してください。出力は {"match": "yes/no/unsure", "reason": "判定理由"} のJSON。確信が持てない場合は必ず unsure としてください。」

名寄せは総当たりだと件数の2乗で組み合わせが爆発するため、実務では「電話番号や住所の市区町村が一致するペアだけをルールで絞り込み、その候補ペアのみLLMに判定させる」ブロッキングという手法を使います。1万件のリストでも、LLMに渡すのは数百〜数千ペアに抑えられます。

例3: カテゴリ分類

• 「以下の商品名と説明文を、次のカテゴリのいずれか1つに分類してください: [カテゴリ一覧を列挙]。一覧にないカテゴリを新設しないこと。どれにも当てはまらない場合は『その他』とし、confidence を high/medium/low で付けてください。」

分類ではカテゴリ一覧をプロンプト内に必ず列挙し、「新しいカテゴリを作らせない」制約を入れるのがポイントです。これを忘れると、モデルが気を利かせて独自カテゴリを生み、かえって分類が散らかります。

精度検証とバッチ処理——全件投入の前にやるべきこと

LLMの出力をノーチェックで基幹データに反映するのは危険です。全件処理の前に、次の手順で精度を測ってください。

1. サンプル100件を抽出し、人手で「正解」を作る（ここだけは手を抜かない）
2. 同じ100件をLLMで処理し、正解との一致率を計測する
3. 不一致だった行を見て、プロンプトの判断基準を修正 → 再計測
4. 一致率が業務上許容できる水準（用途によるが目安95%前後）に達したら全件へ

全件処理後も、confidenceが low / unsure の行だけ人間がレビューする運用（human-in-the-loop）にすると、目視対象を全体の数%に圧縮できます。「AIが9割を片付け、人間は迷った分だけ見る」——これが現実的な着地点です。

件数が数千〜数十万件ある場合のバッチ処理は、次の点を押さえます。

• 1リクエストに数十行ずつまとめて渡す（1行ずつは遅くて割高、詰め込みすぎは精度低下）
• 行ごとにIDを付けて出力させ、入力と出力の対応ズレを機械的に検知する
• 途中失敗してもその箇所から再開できる設計にする（処理済みを記録）
• 急ぎでなければ各社APIのバッチ処理割引（OpenAI・Anthropicとも通常の約半額。最新の料金体系は要確認）を使う

個人情報を扱うときの注意——顧客リストを無防備にAIへ渡さない

顧客リストの整備は、ほぼ確実に個人情報の取り扱いを伴います。技術的にできることと、やってよいことは別です。最低限、次を確認してください。

• 無料のチャット画面に顧客リストを貼り付けない。サービスによっては入力内容がモデルの学習に利用される設定があり、業務データの投入は不適切です
• 業務利用はAPI経由、または学習利用しないことが明記された法人向けプランで行い、各ベンダーのデータ取り扱いポリシーを事前に確認する
• LLMに渡す項目は処理に必要な最小限に絞る。例えば名寄せ判定に生年月日やメールアドレスが不要なら渡さない。氏名を伏せてIDと住所だけで済む処理も多い
• 外部APIへの送信は、個人情報保護法上の委託や外国にある第三者への提供に該当し得るため、自社のプライバシーポリシー・社内規程との整合を確認する（法解釈やガイドラインは更新されるため、最新は個人情報保護委員会の情報で要確認）

実務上のおすすめは、「個人を特定する列を分離してから処理する」設計です。元データに行IDを振り、氏名・連絡先は社内に残したまま、判定に必要な列だけをAIに渡し、結果をIDで書き戻す。これだけで漏えい時の影響範囲が大きく変わります。

小さく始める導入ステップ——最初の1週間でやること

データ整備は「全社データを一気に」ではなく、1つのリスト・1つの目的から始めるのが定石です。当社（TrysLinx）でも98件以上のAI導入を支援してきましたが、データクレンジングは効果が数字（重複件数・空欄率の減少）で見えやすく、社内にAI活用を根付かせる最初の題材として相性が良い領域です。

1. 対象を1つ決める: 「顧客リストの名寄せ」「商品マスタのカテゴリ埋め」など、困っている度合いが最も高いもの
2. 現状を数える: 総件数、明らかな重複数、空欄率。改善効果を測る基準になる
3. ルール処理を先に実施: 全半角統一・法人格統一・スペース除去だけでも見違える
4. サンプル100件でLLM検証: 前述のプロンプト例をベースに一致率を測る
5. 全件処理＋低確信度のみ人間レビュー: 結果を反映し、ビフォーアフターの数字を残す

一度きれいにしても、入力ルールがなければデータはまた散らかります。仕上げとして「入力時の選択式化（自由記述を減らす）」「月次でクレンジングバッチを回す」まで組み込めると、整った状態を維持できます。ここまで来れば、RAG（社内データ検索AI）や営業分析など、次のAI活用の土台としてもそのまま使えます。

よくある質問