Tableauのダッシュボードが合わない原因は顧客の重複——顧客数・商談・売上はこうブレる

2026.08.14BI・Tableauデータ整備の考え方

「ダッシュボードの顧客数が、営業部の実感より明らかに多い」「商談パイプラインの合計が、経理の数字と合わない」「先月作った別のワークブックと売上が食い違う」。Tableauを運用していると必ずぶつかるこの「数字が合わない」問題——ワークブックの計算式を疑う前に確認してほしいのが、元データの顧客レコードの重複です。この記事では、重複顧客がTableauの数字をどう歪めるかを集計の仕組みから解説し、Tableau側での応急処置と、データソース側での根本解決を整理します。

「数字が合わない」の正体

SFA・MA・会計システムをTableauにつないでいる場合、それぞれのシステムに同じ会社が別レコードで登録されていることはごく普通に起きています。「株式会社山田製作所」「(株)山田制作所」「ヤマダ製作所」——人間が見れば同じ会社でも、Tableauの集計にとっては3つの別の顧客です。

重複が生まれる経路は日常のいたるところにあります。展示会の名刺リストを一括インポートした。Webフォームから微妙に違う表記で問い合わせが入った。営業担当が既存レコードを検索せずに新規作成した。M&Aで別システムの顧客リストを取り込んだ。どれも悪意のない普通の業務ですが、確実に重複を積み上げます。

厄介なのは、重複が目立たないことです。ダッシュボード上では「なんとなく多い顧客数」「なんとなく分散した売上」として静かに紛れ込みます。エラーも警告も出ません。だからこそ、経営会議で「この数字、本当か？」と聞かれたときに答えられない、という形で突然表面化します。そして一度「あのダッシュボードは数字が怪しい」という空気ができると、BI活用の推進力そのものが失われていきます。数字への信頼は、BIの生命線です。

重複顧客で数字はこうブレる

顧客数が水増しされる

もっとも単純なブレです。COUNTD（個別カウント）で数えても、レコードが分かれていれば別顧客として数えられます。新規顧客数・アクティブ顧客数・解約数——顧客を分母にするすべてのKPIが実態より大きく（ときに小さく）出ます。「今期の新規顧客は120社」と報告したうち何割かが既存顧客の別表記だった、という事態は、営業成績の評価にも直結します。

商談がバラけて、パイプラインが分散する

重複は顧客テーブルだけの問題ではありません。商談・活動履歴・請求は顧客レコードにぶら下がっています。同じ会社の商談が2つの取引先レコードに分散すると——

• 「この顧客との商談総額」がどのレコードを見ても過小に出る
• 営業別・顧客別のパイプラインが分散し、フィルタのかけ方で数字が変わる
• 同じ会社への提案が2ルートで並走していても、ダッシュボード上では見えない

とくに3つ目は静かに損害を生みます。同じ顧客に別々の担当者が別々の見積もりを出していた——顧客からの一本の電話で発覚し、値引き幅の食い違いまで露呈する。ダッシュボードが「見える化」しているつもりで、一番見たい衝突が見えていないのです。

売上・LTVが歪んで、優良顧客を見落とす

いちばん実害が大きいのがここです。売上が複数レコードに分散すると、顧客単価・LTVは実態より小さく計算されます。本当は取引総額トップ10に入る優良顧客が、ダッシュボード上では「中堅顧客」に見える。リピート購入が「新規顧客の初回購入」として数えられ、リピート率も解約率も狂う。

数字が「多少ズレる」のではなく、顧客の優先順位づけという意思決定そのものが逆を向くのが、重複の怖さです。重点顧客向けの特別対応から漏れ、担当の手厚さも、キャンペーンの対象選定も、すべて誤った顧客区分の上で決まっていきます。

ビフォー／アフターで見る集計のズレ

単純化した例で見てみます。山田製作所が3レコードに分かれている状態と、名寄せ後の状態です。

注目してほしいのは、集計そのものはどちらも「正しく」動いていることです。SUMもCOUNTDも計算式のとおりに働いています。違うのは元データだけ——これが、ワークブック側をいくら直しても解決しない理由です。そしてこのズレは山田製作所1社の話ではありません。顧客リストの数％が重複しているだけで、ランキング・区分・前年比のすべてに同じ歪みが入ります。

Tableau Prep・計算フィールドでの応急処置と限界

Tableau側でも応急処置は可能です。実務でよく使われるのは次の3つでしょう。

• Prepのあいまい一致グルーピング——発音や共通文字による自動グループ化で表記揺れをまとめる
• 計算フィールドでの正規化——「株式会社」「㈱」を除去し、全角半角を揃えた列を作ってグループ化する
• 手作りの対応表——「この表記はこの正式名称」というマッピング表を作って結合する

どれも有効な場面はありますし、明日の報告を乗り切るにはこれで十分なこともあります。ただし、構造的な限界が4つあります。

• ダッシュボードごとに毎回やる——Prepフローや計算式は、そのワークブックの中だけの解決。新しい分析を作るたびに同じ突合をやり直すことになる。作る人が変われば突合のやり方も変わり、ダッシュボード同士の数字がまた合わなくなる
• 関連レコードまでは直せない——名前をグルーピングできても、商談・請求の紐付け替えはBIツールの仕事の範囲外。「見た目は1社、明細は3社のまま」という中途半端な状態になる
• 元データは汚れたまま——SFA・MA・会計の中の重複は残っているので、Tableau以外の帳票・メール配信・AIエージェントでは何も直っていない
• 判定基準が属人化する——Prepフローの中のあいまい一致設定は、作った人にしか説明できない。「なぜこの2社を同じとみなしたのか」に答えられない

根本解決——名寄せ済みデータソースをTableauに渡す

根本解決は、Tableauに渡す前のデータを名寄せしておくことです。当社のAI名寄せ・顧客データ統合クラウド「ナヨセル」は、この構成を標準機能で提供します。

• 元サービスごと直す——SFA・MA・会計から取り込んで重複を統合し、結果を元のサービス（Salesforce・RDBMS）に書き戻す。商談・対応履歴などの関連レコードも勝ちレコードへ矛盾なく付け替えるので、どのシステムから集計しても数字が合う
• マージ済みデータをTableau Cloudへ直接公開——統合後のきれいな顧客データを、データソースとしてTableau Cloudにそのまま公開できる。ワークブック側の突合作業が不要になり、誰が作っても同じ土台の上で分析できる
• 統合IDを結合キーに——「Salesforce ID ↔ kintone ID ↔ 統合ID」の対応表（クロスウォーク）を自動生成・保持。複数システムをまたぐ分析の結合キーとして使える
• きれいな状態を保つ——日次・週次のスケジュール実行で重複の再発を統合し続けるので、ダッシュボードは作り直しなしで正確であり続ける

統合の判定はAIが叩き台を出し、確定は人の承認で行います。実行前のスナップショットからのロールバックや監査ログも標準搭載なので、「BIのためにデータを触って、業務システムを壊す」心配を抑えて導入できます。

対応サービスの詳細は対応サービスのページを、AI名寄せの仕組みは「AI名寄せとは？」をご覧ください。AIエージェントの文脈でのデータ整備は「AIエージェント導入の前提は「きれいな顧客マスタ」」で解説しています。

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

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

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