名寄せは「つなぐ」から始まる——複数サービスを1つの作業台に載せる仕組み

2026.08.26データ整備の考え方AI名寄せ

名寄せの最初の工程は、重複の判定ではなく「接続」です。Salesforce・kintone・会計ソフト・スプレッドシートに散らばった顧客データを、まず1つの作業台に載せる——ここを整えずに突合を始めると、比較の土俵がそろわず、精度も安全も確保できません。この記事は、ナヨセルの機能を体験順に紹介するテック連載の第1回として、いちばん地味でいちばん大事な「つなぐ」の仕組みと、その裏側の設計判断を解説します。

名寄せは「つなぐ」から始まる

重複は、サービスの「中」ではなくサービスの「間」に住んでいます。同じ取引先が、Salesforceでは「株式会社山田製作所」、kintoneでは「山田製作所」、請求システムでは「（株）山田製作所」として、それぞれ別のIDで登録されている——これが名寄せが必要になる典型的な状況です。各サービスに備わっている重複チェック機能は、そのサービスの中しか見ていません。横串の重複は、データを横に並べない限り永遠に見えないのです。

横串の重複が見えないまま放置されると、実害は静かに積み上がります。

• 営業が同じ会社に二重にアプローチし、先方に「おたくは社内で連携していないのか」と言われる
• MAツールが同じ担当者に同じメールを2通配信する
• 「顧客数」「商談数」のレポートが水増しされ、経営判断の土台が狂う
• どのシステムの値が最新か誰も断言できず、確認のやり取りだけで時間が溶ける

では横に並べればよい、と各サービスからCSVをエクスポートしてExcelで突き合わせると、今度は別の壁に当たります。文字コードも日付の形式もカラム名もサービスごとにバラバラで、並べる前の「そろえる」作業に大半の時間を取られます。しかもエクスポートした瞬間からデータは古くなり始め、突き合わせている間にも元のサービスでは新しいレコードが増えていきます。そして最大の問題は、苦労して作った突合結果を元のサービスに戻す手段がないことです。

この経験から得られる教訓はシンプルです。接続は名寄せの準備作業ではなく、名寄せの品質を決める最初の設計対象だということ。どこから・何を・どんな形で持ってくるかを最初に設計してしまえば、後工程の正規化・突合・書き戻しはすべてその土台の上で機械的に回せます。逆にここが場当たりだと、毎回の名寄せが一点物の手作業になります。

作業台という設計——元サービスを直接さわらない

ナヨセルは、接続した各サービスのデータをコピーして、ナヨセルが管理するデータベース（ナヨセルDB）に取り込みます。名寄せの検討・シミュレーション・突合はすべてこの作業台の上で行い、人が承認して確定した結果だけを元のサービスに書き戻します。元サービスのデータを直接書き換えながら名寄せを進めることは、設計としてできないようになっています。

この方式の利点は3つあります。第一に、失敗が元データに及ばないこと。マージ条件を間違えても、壊れるのは作業台の上のコピーだけです。第二に、何度でも試せること。条件を変えて再シミュレーションするコストがほぼゼロになります。作業台がナヨセルの管理するデータベースだからこそ計算を最適化でき、実測では約600万件の突合シミュレーションが90秒で返ります。「試す→眺める→条件を直す」のループを、お茶を淹れる間もなく回せる速度です。第三に、複数サービスのデータを同じ型にそろえられること。作業台の上では、SalesforceのレコードもkintoneのレコードもCSVの行も、同じテーブル形式・同じ文字コード・同じ型で扱えます。

「コピーが増えるのはむしろ危険では」という懸念には、権限と経路で答えます。作業台への閲覧・変更は役割ごとに制御され、確定と書き戻しは承認と監査ログを通る正規の経路しかありません。詳しくはセキュリティのページにまとめています。

作業台方式にはもうひとつ、見落とされがちな効用があります。名寄せの検討過程そのものが作業台の上に残ることです。「どの条件で試したら何件になったか」「どの候補を人が承認したか」が元サービスの外で積み上がるので、名寄せの品質を後から説明できます。元サービスの中で直接編集する方式では、この検討の痕跡がどこにも残りません。

作業台の中身——主・副・関連の3種類のテーブル

作業台に載せるデータは、役割の違う3種類のテーブルに分けて受け取ります。この区別が、後工程のマージと書き戻しの正確さを支えています。

• 主テーブル（基準の取り込みデータ）——名寄せの基準になる1つのテーブル。統合後のデータ（統合台帳）の列構成は、この主テーブルの定義から作られます。たとえばSalesforceの取引先をここに置きます
• 副テーブル（追加の取り込みデータ）——主テーブルに突き合わせたい、他サービス由来のデータ。kintoneの顧客アプリや展示会リストのCSVなど、必要な数だけ追加できます
• 関連テーブル（関連データ）——商談・対応履歴・請求など、顧客に「ぶら下がる」データ。マージの対象にはせず、親の統合結果に合わせて出力や付け替えに使います

具体例で見てみます。Salesforceの取引先を主テーブルに、kintoneの顧客アプリを副テーブルに置いたとします。主に「株式会社山田製作所」、副に「山田製作所」があれば、この2行がマージ候補の土俵に載ります。一方、Salesforceの商談は関連テーブルに置きます。商談そのものは重複ではないので統合しませんが、親の取引先が統合されたら、商談のひも付け先は新しい親に付け替えたい——この「親はマージ・子は付け替え」という扱いの違いを、テーブルの役割としてあらかじめ宣言しておくのが3種類の区別の意味です。

もうひとつ、目立たないが重要な仕掛けがあります。作業台のテーブルには、行の通し番号・マージ済みかどうか・どの行に統合されたか、を記録する管理用の列が自動で付与されます。つまり「どの行がどの行に吸収されたか」をテーブル自身が覚えているのです。この仕組みがあるから、後工程で関連レコードの付け替え先を機械的に特定でき、間違えたときに元へ戻すこともできます。取り込んだ瞬間から、すべての行に足跡が付く設計です。

なお、副テーブルと関連テーブルは後から何度でも追加・削除できます。最初から完璧な構成を目指す必要はなく、「まず主テーブルだけで小さく始めて、突き合わせたいデータが増えたら副を足す」という育て方ができます。テーブルを消すときは物理テーブルごと破棄され、中途半端な残骸が作業台に残らないようになっています。

3種類をどう定義するか——列の設計と日本語化——は次回のスキーマ取込とカラム名の日本語化で詳しく扱います。

サービスごとの階層差を吸収する仕組み

接続の実装で最初にぶつかるのは、サービスごとにデータの「住所の書き方」が違うことです。この違いを画面ごとに作り込むと、対応サービスが増えるたびに画面も増え、操作感もバラバラになります。ナヨセルはデータ源を3つの型に整理して、この問題を解いています。

階層をたどる型——深さだけが違う

Salesforceなら「オブジェクト」を1つ選べばフィールド一覧に届きます。PostgreSQLなら「スキーマ→テーブル」の2段、BigQueryなら「プロジェクト→データセット→テーブル」の3段をたどる必要があります。ここでの設計判断は、すべてのサービスを「一覧を見る」「列を取り出す」の2つの操作に正規化することでした。サービスごとに違うのは階層の深さだけなので、深さは「オブジェクト」「スキーマ→テーブル」のようなデータとして持ち、画面側は同じ2操作を深さのぶんだけ繰り返します。新しいサービスへの対応は「深さと呼び先を定義する」ことに近づき、ユーザーから見れば、どのサービスをつないでも同じ操作感で列一覧まで届きます。

ファイルから読む型——ヘッダ行が列定義になる

CSVやスプレッドシートには、たどるべき階層がありません。代わりにファイルの1行目（ヘッダ行）を読んで列一覧を作ります。FTP・SFTP・Box・Google Drive・Amazon S3などの置き場所ごとの違いは接続側で吸収するので、ユーザーの操作は「置き場所を指定して、列を取得する」だけです。展示会リストのような単発のCSVも、基幹システムから毎晩吐き出されるCSVも、同じ作法で作業台に載ります。

同梱の公共データ——コネクタと同じ棚に並ぶ

ナヨセルにはgBizINFO由来の法人マスタ（500万法人超・月次更新）が同梱されており、これもコネクタと同じ一覧から選べます。自社のデータと公的な参照データを同じ入り口・同じ作法で扱えるので、「まず自社データを載せて、次に法人マスタと突き合わせる」という流れが1つの画面で完結します。

階層をたどる型に収まらないデータ源にも、それぞれの入り口があります。CSV・スプレッドシート系は、ファイルのヘッダ行（1行目）を読んで列一覧を作ります。さらに、gBizINFO由来の法人マスタ（500万法人超・月次更新）のような同梱の公共データも、コネクタと同じ一覧に並びます。「どこから持ってくるか」の入り口を1か所に集約してあるので、社内のデータと公的データを同じ作法で作業台に載せられます。

ナヨセルの場合——350社以上で磨かれたコネクタ基盤

ナヨセルの接続部分は、当社のAgentic ETL「Passwork」が350社以上のデータ連携で磨いてきたコネクタ基盤をそのまま使っています。SFA・MA・会計・データベース・広告・ファイルストレージまで、名寄せのためにゼロから接続を開発したのではなく、実運用で叩かれてきた土台の上に名寄せ専用の作業台を組んだ、という成り立ちです。対応サービスの一覧は連携ページをご覧ください。

取り込みの実行はフローとして定義するので、初回の大掃除だけでなく、毎晩の定期取り込みにもそのまま使えます。「一度きりの名寄せ」で終わらせず運用に乗せる話は、連載後半のスケジュール実行の回で詳しく扱います。そして、接続はすべての後工程の入り口です。この連載でこれから紹介していく機能は、全部この作業台の上で動きます。

• 取り込んだテーブルの列名を人が読める形にする——スキーマ取込とカラム名の日本語化
• マージ実行前に重複率を実測する——AI名寄せ診断
• 作業台のデータを直接歩いて検分する——データブラウザ
• そして重複条件の設計・シミュレーション・承認・書き戻しへ（連載第2部以降）

料金面もこの設計と対応しています。ナヨセルの課金変数はマージ対象のレコード数だけで、接続するサービスの数は何個つないでも料金に影響しません。「つなぐことにコストがかかるから接続を絞る」という本末転倒を避けるための価格設計です。詳しくは料金プランをご覧ください。

よくある質問

対応コネクタがないサービスのデータも名寄せできますか？

できます。CSVでエクスポートできるデータであれば、ファイル経由で作業台に取り込めます。CSV・スプレッドシート系の取り込みはヘッダ行から列を自動で読み取るので、手作業の整形はほとんど必要ありません。

取り込むと元のサービスのデータは変わりますか？

変わりません。取り込みはコピーであり、元サービスへの書き込みは一切発生しません。元データに変更が加わるのは、名寄せの結果を人が承認し、書き戻しを実行したときだけです。

接続サービスが増えると料金は上がりますか？

上がりません。料金はマージ対象のレコード数だけで決まり、接続サービス数・実行回数・ユーザー数は課金対象外です（Starter 5万円〜・月額税抜）。

既存のETLやDWHがある場合、作業台は二重投資になりませんか？

役割が違います。DWHは分析のための置き場、ナヨセルの作業台は「統合を確定させて元サービスに書き戻す」ための場所です。マージの試行・承認・付け替え・書き戻しに必要な管理列と安全装置を備えた専用の台なので、DWHやETLとは併存します。DWH側を接続元にして取り込むこともできます。

どのデータを主テーブルにすべきですか？

「統合後のデータの持ち主にしたいサービス」を主テーブルにするのが基本です。書き戻し先がSalesforceならSalesforceの取引先を主に、というように、名寄せ結果を最終的に住まわせたい場所から逆算してください。導入支援（全プラン標準付帯・2ヶ月・50万円〜）でもこの設計から一緒に行います。詳しくは導入の流れをご覧ください。

まず何から接続すればよいですか？

書き戻し先にしたいサービス（多くの場合はSFA）を主テーブルとして最初に接続し、次に重複の混入源になっているデータ——展示会リストのCSVやMAツール——を副テーブルとして足すのが定石です。関連テーブルは、マージ後に付け替えが必要な商談・履歴が出てきた時点で追加すれば間に合います。

作業台のデータは誰でも見られてしまいますか？

いいえ。作業台への閲覧・変更はプロファイル（役割）で制御され、データの閲覧経路は読み取り専用に固定されています。誰が・いつ・何をしたかは監査の記録に残ります。詳細はセキュリティのページにまとめています。

料金プランと導入支援の内容がわかる
資料をご用意しています

サービス概要から料金プラン、2ヶ月の導入支援の進め方まで
まとめた資料を無料でダウンロードいただけます。

資料ダウンロード無料 料金プランを見る