展示会リードのデータ整備をAIで自動化しようとしたら、毎日手作業する羽目になった話

毎日毎日、私はひとりで会社名を検索していました。1社調べては、また1社調べる。何度も思いました、「自分は何をやっているんだろう」と。

これは、展示会で獲得したリードの会社名表記揺れをなくすAIツールを作ろうとしたが、毎日手作業でAIを鍛える羽目になり、ツールは完成したものの、結局現場では使われなかった話です。

私はDX関連サービスを提供するスタートアップで、個人向けサービスのマーケティングを含めた集客責任者を経験したのち、現在は同社の法人向けサービスのマーケターとして働いています。担当業務は広く、マーケティング部門の立ち上げや、コンテンツ制作、メルマガ、ウェビナー、展示会まで関わっています。

法人向けサービスのマーケターになってびっくりしたことは、データクレンジング（データの修正）が求められる場面の多さです。とくに展示会やカンファレンスで獲得する大量リードのクレンジングは大変です。

これを自動化したいと思い、私は先の「自動化」ツール開発に着手しました。結果として、非エンジニアである私でも、すぐに動くものを作れました。しかしこの試みは、失敗に終わりました。

会社名の表記揺れは、法人向けサービスのマーケターに共通の悩みだと思います。「株式会社」が前につくか後ろにつくか、大文字か小文字か、英語かカタカナか、さらに全く同じ会社名の企業が複数あるケースも。

この揺れが、CRM（顧客管理システム）の中で問題を引き起こします。CRM上で、会社名を同じ会社として判定するキーとして活用すると、表記が違えば当然データは結合できず、本当は1社しかない会社が、別々の会社として積み上がります。その結果、データとしての信頼性や集計数値に影響します。

そこで、都度修正することになります。問合せや資料請求は1日の件数がそこまで多くなければ、対応できます。しかし問題は、数日で大量のリードを獲得する展示会やカンファレンスです。これは、短期間に大量のクレンジングが発生するという問題だけではありません。なるべく早めにブース訪問者の御礼メールを送りたいので、クレンジングに期限があります。

私自身、お客様のブース訪問当日〜翌朝までに御礼メールを送るため、展示会終了後にデータを直し続ける、といったこともありました。

もちろん、事前準備や当日のクレンジング作業の効率化もしています。クレンジングメンバーのアサイン、関数入りExcelの準備、さらに生成AIの検索機能の活用などです。

しかし、展示会の会期前は遅くまで準備し、展示会中は足が棒になるまで立ち、夜はクレンジング祭り。大量リード獲得の嬉しい悲鳴とともに、「絶対もっといい方法があるはず」と思いながらも根本的な自動化に着手できない。そんな課題を抱えていました。

そんな中、追い風が2つ吹きました。

1つ目は、法人番号付きの企業データです。Salesforce導入にあわせて、ターゲットとする企業の法人番号付きの企業情報がSalesforceに入りました。（法人番号は、国税庁がすべての法人に付与する13桁の番号です。）

2つ目の追い風が、会社のAIツール環境です。エンジニア向けのAI開発ツールである「Cursor」が使用できるようになりました。

そこで、私は思いました。会社名ではなく法人番号をキーとして、Salesforceの会社データを統合する。つまり、獲得リードに正しい法人番号を自動付与できるようなツールを開発できないかと。

具体的には会社名をクレンジングして検索し、正しい法人番号を付けてもらうだけ。生成AIの進化を思えば簡単にできるのではと、早速開発に取り掛かりました。

まず作成した仕組みは、以下のようにシンプルでした。

• システムの入力情報は、個人情報を一切含まない、企業名だけを並べたローカルファイル
• 企業名をクレンジングし、法人番号のデータファイル（国税庁が提供する法人の全件データ）の中を検索して法人番号と会社の正式名称（法人番号と共に登録されている法人名）を取得
• 出力の「確からしさ」をAからDの4段階で判定。Aは確認不要、BからDは人間が目視。法人番号が見つからないリードには「なし」などのラベルを付けて仕分け

この時点の私は、正直、うまくいくと思っていました。

最初のバージョンでは、誤マッチが多発しました。作った本人の目から見ても、「全然使えない」。明らかに違う会社なのに、A判定やB判定が頻出。

そこで、以下のように改善しました。

• 前株後株等の法人格の位置を検証するステップを追加
• 会社を特定する材料を増やすために、入力情報にメールアドレスのドメインのみを追加
• 照合はデータファイルだけでなく、APIでの検証も追加

▼制作途中のフロー：制作した運用マニュアルから抜粋

それでも、誤りが多く残りました。株の位置も会社名も同じ会社や、市区町村を含めた官公庁、部分では一致してしまう企業（例：あいうえお株式会社、いうえ株式会社など）。データの前処理や突合方法でカバーしきれないデータが、多くあったのです。

そこで覚悟を決め、AIに与える「正解」である教師データを作ることにしました。

つまり、直近の展示会で獲得した全リードに対して、検索などを駆使して正しい法人番号を手作業で付与する、ということです。

冒頭のシーンは、このときのことです。自分は何をやっているんだろう、とつぶやきながら、正しい法人番号を付けていきました。

一定数の正解データを作っては、正解と出力の差分をシステムに反映させ、正誤表を見ながら誤りを順に潰し、全体に適用できる閾値やルール設計をブラッシュアップ。これをとにかく繰り返しました。

さらに、ランク分けの変更（100%間違いないS判定の新設）や、出力に判定の背景や調査方法も掲載。私以外のクレンジング担当者でも「自分で調べ直さなくても安心して使える」仕組みになるように調整しました。

そして約1週間の教師データ作りと改善の末に、実戦に出せるバージョンが完成しました。

▼最終的なフロー：制作した運用マニュアルから抜粋

そのバージョンアップの検証では、約1,500件の企業リストを45分ほどで処理できました。確認不要（S・A判定）は45.9%、件数にして688件。その中で誤っていたのはA判定の2件、率にして0.29%。これなら、展示会1日で大量のリードを獲得できても、運用できそうです。

本番の展示会に私は参加できないため、運用マニュアルと使用方法の動画を残し、担当者がCursorで動かせるかたちで引き渡しました。

そして展示会当日、本システムの動き出しは非常に好調だったそうです。ところが来場ピークの14〜15時に、トークン（AIの利用量の単位）が切れて止まりました。開発中には起きなかったことでした。使用サービスの料金体系が変わったタイミングなどもあり、会社側で使用量に上限が設けられていたようでした。

当然バックアッププランもあったので、問題なく当日の御礼メールには間に合いました。しかし、私の作ったツールはチームに大きく貢献できず、結局当日のクレンジングは元のやり方で運用することになってしまいました。

作ってみて初めて、分かったことがあります。「AIで自動化」と呼ばれているものには、ベクトルの異なる2つの「自動化」が含まれていました。

1つ目は、高い精度がいらない自動化です。例えば記事や資料のたたき台なら、AIの出来は70点でも役に立ちます。多少の誤りがあっても困らないからです。この種の自動化は、たしかに簡単になりました。

2つ目は高い精度が求められる自動化です。今回の法人番号のケースは、70点では使いものになりません。CRMに入って、会社をひとつに結合するキーになるからです。70点とは、3割の誤りが静かにデータに混ざるということです。

ふり返れば、ここまでに書いてきた苦労は、この区別を意識しないまま始めたことから来ていました。しかし、自動で動くことと、間違えないことは、別の話でした。

ルールを足しても例外が湧き続け、最後は「正解」を自分の手で作ることになった。あの遠回りは、間違えられない自動化に挑むなら、避けて通れない手間だったのです。

70点でいい自動化は、たしかに簡単になった。でも「間違えられない自動化」は、想像以上に簡単ではありませんでした。

教師データまで作って、ツールは実戦に出せる精度に届きました。でも、いちばん大きな学びは、この先にありました。

精度が届いても、ツールは現場に残りませんでした。理由は、ツールの中ではなく、ツールの外にありました。

現場での運用において、使う人も、当日の負荷も、AIの料金も、会社の方針も、すべてツールの外側にあって、予告なく変わる変数です。これらの変数が変わっても同じ精度で動くものでないと、現場での運用に耐えられないのです。

しかも、変わり続けるのは本番の条件だけではありません。会社名は、これからも変わり続ける。つまり、保守の問題もあります。「完成」は終わりではなく、手入れを続ける始まりなのだと知りました。

いま思えば、私はゴールを「作って動く」に置いていました。教師データで「間違えない」までは引き上げた。でも、ゴールを置くべき場所は、そのさらに先の「現場で使われ続ける」でした。

動く。間違えない。使われ続ける。この3つは、それぞれ別のものでした。

現在、Cursorでの一括処理はもう行っていません。ABM（ターゲット企業を絞り込んで攻めるマーケティング手法）のツールを導入し、Salesforceと連携できるようになったからです。

いまのクレンジングは、まずClaude Codeで会社名を検索・整理し、ABMツールが持つ企業データベースと突合して、その結果をSalesforceに連動させる流れです。

ただし、これで回っているのは一度に処理する件数が少ない場合です。展示会のように一気に増える大量のリードには、まだ適用しきれていません。ここは、いまも改善中です。

最後に、これからAIで業務の自動化に挑む方に、持ち帰っていただきたいことをまとめます。

最初の一歩は、ツールを作ることではありません。ゴールを「作って動く」ではなく、「現場で使われ続ける」に置き直すことです。そのうえで、着手する前に、3つの設計を確かめます。

その自動化が「70点でも役に立つもの」か「間違えられないもの」かを、まず見極める。間違えられない側なら、「どこまでAIに任せ、どこから人が確認するか」を先に決める。それでも精度が足りなければ、正解データ（教師データ）を自分の手で作る覚悟を決める。

確認すべき問いは、2つ。「本番のいちばん忙しい瞬間にも動き続け、止まったときにも業務は回るか」、「本番運用時に考慮できていない変数はないか」。
動き続けられるかを見積もり、止まったときの備え（代替手段と、自分以外の人でも使える状態）を先に用意しておく。守るべきはツールではなく、業務です。

対象のデータは変わり続ける前提に立ち、保守の手間と精度の限界を、時間軸で見積もる。目先の時短の大きさだけで、導入を判断しない。

「動くもの」を作ること自体は、もう誰にでもできる時代です。問われているのは、現場で使われ続けるまでの設計を、作る前に描けるか。

私と同じ轍を踏まずに済む方が、ひとりでも増えたらうれしいです。