Tableauでデータが重複する原因｜JOINとリレーションシップの確認手順

Tableauで注文データに別の表を追加したら、売上が2倍になった。JOINではなくリレーションシップを設定したのに、集計値が想定と違う。

最初に確認したいのは、[データソース]で表をどう組み合わせたかです。物理結合は一致する行を組み合わせて一つの表を作ります。一方、リレーションシップは表を個別に保持し、ビューで使うフィールドに応じてTableauがクエリを作ります。両者では「データが重複している」ときの調べ方が異なります。

この記事でわかること

物理結合とリレーションシップで数字が変わる仕組み
元データ・結合結果・ビューのどこを確認するか
原因に応じた修正方法と、修正後の検算方法

結論：まず物理結合かリレーションシップかを確認する
具体例：注文に対応履歴をJOINすると売上が増える
まずここから確認：重複が生じた場所を探す
物理結合で重複する主な原因と直し方
リレーションシップで数字が合わないときの確認方法
JOINとリレーションシップ、どちらに直せばよい？
初学者が詰まりやすい3つのポイント
それでも直らないときの検算手順
まとめ
次に読む記事

結論：まず物理結合かリレーションシップかを確認する

Tableauの[データソース]画面で、テーブル間のつながり方を確認してください。通常、最初に表示される論理レイヤーで表同士を関連付けるのがリレーションシップです。論理テーブルを開いた内側で設定するのが物理結合です。

組み合わせ方	データの扱い	数字が増えたときの主な確認点
物理結合	一致する行を組み合わせた表を作る	結合キーの重複、条件不足、結合後の行数
リレーションシップ	表を個別に保持し、ビューに応じて問い合わせる	関係に使うキー、カーディナリティ、参照整合性、ビューの集計単位

物理結合なら「どの元の行が何行になったか」から調べます。 リレーションシップなら「元テーブルそれぞれの値は正しいか」「どのフィールドを同じビューに置いたとき値が変わるか」から調べます。

リレーションシップは、異なる詳細レベルの表を扱うための仕組みです。ただし、元データの誤った重複や、実データと合わない関係設定まで自動的に修正するものではありません。

具体例：注文に対応履歴をJOINすると売上が増える

まず、次の2つの表を考えます。

注文：1行＝1注文

注文ID	売上
101	100
102	200

注文の売上合計は300です。

対応履歴：1行＝1回の対応

注文ID	対応
101	メール
101	電話
102	メール

注文IDで物理結合すると、結果は次のようになります。

注文ID	売上	対応
101	100	メール
101	100	電話
102	200	メール

結合結果に対して売上を足せば、100＋100＋200＝400です。注文101が二重登録されたとは限りません。対応履歴に注文101が2行あり、注文の売上100がそれぞれの行に付いた結果です。

この違いを見落としやすいのは、「注文の売上」と「対応履歴」が異なる粒度のデータだからです。注文ごとの売上が欲しいのか、対応ごとの情報が欲しいのかを先に決める必要があります。

まずここから確認：重複が生じた場所を探す

以下の順に確認すると、原因を絞れます。

順番	確認すること	見つかること
1	各テーブルの「1行が表すもの」	注文単位と明細・履歴単位の違い
2	各テーブルでキーごとの行数	元から複数行あるキー
3	[データソース]での組み合わせ方	物理結合かリレーションシップか
4	結合キーと、物理結合なら結合タイプ	条件不足や未一致行の扱い
5	結合前後、または各表単体と複数表のビューを比較	数字が変わる段階
6	注文IDなど小さな単位で再計算	総額の差を生んだ具体的な行

物理結合を使っているなら、Tableauの[データソース]のデータグリッドで結合結果を確認します。

元データをSQLで確認できる場合は、結合先に同じキーが何行あるか調べると早く切り分けられます。

SELECT order_id, COUNT(*) AS rows_per_order
FROM order_events
GROUP BY order_id
HAVING COUNT(*) > 1;

このSQLで注文101が2行と分かっても、履歴の二重登録とは限りません。「1注文に複数回の対応がある」という正しいデータの可能性があります。

SQLで重複キーと該当明細を確認する方法は、こちらで解説しています。

物理結合で重複する主な原因と直し方

原因1：結合先が1キーにつき複数行ある

問題： 結合後、注文IDごとの行数と売上合計が増える。

なぜ起きるか： 左表の1行に右表の複数行が一致するためです。対応履歴や注文明細などでは、複数行が正常なこともあります。

確認箇所： 両方の表で結合キーごとの行数を調べ、[データソース]のデータグリッドで具体的な注文IDの結合結果を見ます。

修正方法： 注文ごとの対応件数が必要なら、対応履歴を注文単位に集計してから結合します。対応の存在だけが必要なら、元データ側で存在判定を作る方法もあります。どちらも、欲しい指標の単位に合わせて選びます。

結合キーの重複、1対多・多対多の見分け方は、SQLの例を使った記事でも確認できます。

原因2：結合条件が足りない

問題： 特定の店舗や月だけ、売上・件数が大きく増える。

なぜ起きるか： 本来は「店舗IDと対象月」で結ぶべき表を、「店舗ID」だけで結ぶと、同じ店舗の複数月が一致します。

確認箇所： [データソース]で物理結合の条件を開き、業務上の一意な組み合わせと比べます。店舗ID・対象月ごとの行数も元データで確認します。

修正方法： 対応する列を結合条件に追加します。ただし、両表で「月」が同じ意味と形式かを確認してください。片方が計上月、もう片方が出荷月なら、列を追加するだけでは正しい対応になりません。

原因3：集計対象の列を、増えた行の上でSUMしている

問題： 対応件数は正しいのに、注文売上だけ大きい。

なぜ起きるか： 結合で増えた各行に注文売上が繰り返され、その売上列をSUMしているためです。

確認箇所： Tableauのビューに注文IDと売上を置き、結合前の注文売上と注文ID別に比較します。表示の集計方法がSUMかも確認します。

修正方法： 元の表で注文売上を集計する、結合先を注文単位にまとめる、または分析内容に適したリレーションシップを検討します。MINやAVGで表示上の値を合わせる方法もありますが、業務上の指標に合う場合だけ使ってください。

DISTINCTやCOUNTDで総額・件数だけを合わせて終了しないことも大切です。結合条件やデータの粒度が間違ったままなら、別の集計軸で再び数字がずれる可能性があります。

リレーションシップで数字が合わないときの確認方法

物理結合とは異なり、リレーションシップは表を事前に一つの平坦な表へ統合しません。Tableauはビューで使うフィールドをもとにクエリを作り、表の詳細レベルを考慮して集計します。そのため、リレーションシップを使っているだけで、物理結合と同じ行の増加が常に起きるわけではありません。

それでも値がおかしい場合は、次の順で確認します。

1. 表ごとの値は正しいか

注文表の売上だけを置いた検証用シートと、対応履歴表の件数だけを置いた検証用シートを作ります。まず各表単体の値を元データと比べ、その後、両表のフィールドを同じビューに置いて比較します。

各表単体ですでに違うなら、元データ、フィルター、集計方法を調べます。組み合わせたときだけ違うなら、関係に使うフィールドや設定を調べます。

2. 関係に使うキーは正しいか

[データソース]でテーブル間の線を確認し、注文IDだけで対応するのか、店舗や期間なども必要かを元データの定義と比べます。同じ名前のフィールドでも、両表で意味が違う可能性があります。

3. カーディナリティを実データに合わせているか

キーが一意でないのに、リレーションシップのパフォーマンスオプションで[One (1)]等を選ぶと、重複した集計値が表示される場合があります。一意か分からないキーは、確認せずに[One (1)]と決めないでください。

同じ設定画面では、表同士のレコードがすべて一致するかという参照整合性も扱います。「すべて一致する」と設定する前に、実際に未一致のキーがないか確認してください。

カーディナリティとは、2つの表を結ぶキーについて、片方の1件に対して、もう片方が何件対応するかを表す関係（1対1、1対多、多対多）です。

JOINとリレーションシップ、どちらに直せばよい？

数字が合わないからといって、すべての物理結合をリレーションシップに変更する必要はありません。目的に合わせて判断します。

やりたいこと	検討する方法	確認すべきこと
注文と対応履歴を、それぞれの単位で集計したい	リレーションシップ	関係キーと各表の粒度
注文ごとの対応件数を1列として付けたい	対応履歴を注文単位に集計してから結合	集計後に注文IDが一意か
対応1件ごとの一覧に注文情報を付けたい	物理結合	注文売上を対応行ごとに合計しないか
一致しない行を意図的に除外したい	要件に合う結合タイプを選ぶ	除外したIDと件数