名刺情報を顧客管理システムに自動連携、生成AIで約2日の内製構築

名刺は各メンバーが個人向けの無料サービスでデータ化しており、営業活動で使うにはCSVで出力して手作業で突き合わせる必要がありました。加えて、業務委託契約が終わるときに、個人のアカウントに入ったままの名刺情報が社外へ持ち出される心配も残っていました。

編集部の見立てでは、この困りごとの中心にあったのは手作業の多さそのものではなく、顧客との接点情報が「会社ではなく個人に紐づいていた」ことです。少数精鋭でフルリモート、しかも業務委託パートナーと組んで営業を進める体制では、人の出入りがそのまま情報の欠落や流出につながります。統合作業の煩雑さは、その構造が表に出た症状にすぎなかったのではないでしょうか。

ツール選定の必須要件を「HubSpotと連携できるか」の一点に絞り込んだことが、この取り組みの起点になっています。名刺管理そのものの機能を横並びで比べるのではなく、すでに営業の中心にある顧客管理プラットフォームへ情報が流れ込むかどうかで候補をふるいにかけた形です。連携用APIを外部に公開しているSKYPCEが要件に合致し、いきなり全面展開せず検証で連携の可否を確かめてから本導入へ進む順序も踏まれています。

連携の作り込みを自社側に閉じたことも、実現可能性を大きく左右した判断だと考えられます。名刺の蓄積やAPIの提供は既製サービス側が担い、自社の顧客管理の事情に依存する「つなぎ込み」の部分だけを自前でコードにする、という役割分担です。情報システム部門の専任者がいない会社にとって、この切り分けはハードルの高い開発を「AIに書かせられる範囲の作業」まで小さくする効果を持ちます。生成AI（文章やコードを作るAI）の使いどころを、業務そのものではなく業務システムをつなぐ工程に置いた点が、この事例の特徴的なところ。

情報の突き合わせをどう成立させるかという地味な設計も見落とせません。同じ人物かどうかを判定するキーにメールアドレスを選び、名刺情報に更新があれば1時間以内に上書きされる形で運用しています。突合を行うサーバーを大手クラウドサービス上に置いたのは、顧客情報という機微なデータの置き場所を、自前の環境で守り切ろうとしなかった選択と読めます。連携を「一度作って終わり」ではなく、鮮度を保ち続ける仕組みとして設計したことが、営業現場で使える状態を支えているのでしょう。

連携用のコードは生成AIを使って約2日で構築が完了し、名刺の登録や更新がHubSpot上の見込み顧客情報へ反映されるようになりました。昇進や異動を正しく把握できるため、キーパーソンに近づきやすくなり、特に公開されることが少ない中小企業の人事情報をつかめる点が営業の確度に効いています。ターゲットリストの作成も、営業担当者の勘と経験から、東京商工リサーチの業種情報という客観的な指標に置き換わりました。副次的な効果として、電話帳にない番号からの着信でも相手の所属先と名前がスマートフォンに表示され、応対がスムーズになっています。