Tableauで合計が膨らむ理由
データ粒度（LOD）と重複行の正体

なぜTableauで合計が膨らむのか — 結論を先に

「Tableauで売上合計を出したら、Excelで集計した値の何倍にもなってしまった」「ディメンションを1つ追加しただけで合計の数字が変わった」 ――Tableauを業務で使い始めた方が最初にぶつかる壁の一つです。

結論から言えば、原因のほとんどは「データ粒度の認識違い」と「結合による重複行の発生」のどちらか、あるいは両方です。 Tableauが計算間違いをしているわけではなく、想定と異なる粒度で集計が行われているために、結果の数値が膨らんで見えるという現象です。

この記事では、合計が膨らむ仕組みを「ビュー粒度」「データ粒度」「結合とリレーションシップの違い」の3つの観点から整理し、 注文データと商品マスタを結合するシナリオで実際の数値を追いながら、対処法までを解説します。 Tableau Certified Data Analyst試験の「データの探索と分析」ドメインでも頻出のテーマです。

ビュー粒度とデータ粒度は別物

「粒度」という言葉はTableauの解説で頻繁に登場しますが、実は2種類の粒度が同じ言葉で語られていることが混乱の原因になっています。 まずこの2つを区別することから始めます。

ビュー粒度はSHELFで決まる

ビュー粒度（Level of Detail）とは、Tableauのビュー上で1マーク（1行）が何を表しているかの単位を指します。 SHELF（行・列・詳細・色・サイズなど）に配置されているディメンションの組み合わせによって決まります。

たとえば「カテゴリ」だけを行シェルフに置いた状態では、1マークが「カテゴリ単位の集計値」を表します。ここに「サブカテゴリ」を追加すると、 1マークが「カテゴリ × サブカテゴリ」の組み合わせ単位に変わります。ビューに置いたディメンションを増やすほど、ビュー粒度は細かくなり、 表示されるマーク数も増えていきます。

ビュー粒度は分析者が画面上で操作して変更できるものであり、SHELF構成を見れば何の単位で集計されているかがその場で分かるという特徴があります。 ビュー粒度の基本的な考え方は入門学習粒度とビューの仕組み — ディメンション追加でなぜ数値が変わるかで確認できます。

データ粒度はデータソース側で決まる

一方、データ粒度（データソースの粒度）は、データソース側で1レコードが何を表しているかの単位です。 これはTableauに接続する前から決まっている性質で、画面上の操作では変えられません。

たとえば「注文明細テーブル」の1レコードは「1つの注文に含まれる1つの商品行」を表します。同じ注文IDが複数回現れることがあり、 これは「1つの注文で複数商品を購入した」状態を意味します。一方「注文ヘッダーテーブル」の1レコードは「1つの注文全体」を表すため、 注文IDは重複しません。

つまり、同じ「売上」というメジャーでも、明細テーブル基準で集計するか、ヘッダーテーブル基準で集計するかでデータ粒度が変わります。 ビュー粒度をどう設計しても、もとのデータ粒度が想定と違えば集計結果は意図したものになりません。

ディメンションを追加すると粒度が細かくなる仕組み

ビューにディメンションを追加すると粒度が細かくなり、それに連動してメジャーの集計値も変わります。この動きを具体的な数字で確認します。

仮に「全国の売上合計」が1億円だとします。何もディメンションを置かない状態では、ビューに表示されるのは「1億円」という1つのマークだけです。

ここに「地域」ディメンションを追加すると、1マークが「地域単位の売上合計」になります。東日本5,000万円・西日本3,000万円・その他2,000万円といった形で、 地域ごとの集計値が分かれて表示されます。これらを足し合わせれば1億円ですが、個々のマークの数値は当然それより小さくなります。

さらに「製品カテゴリ」を追加すると、1マークが「地域 × カテゴリ」の組み合わせ単位になります。東日本×家電、東日本×書籍、西日本×家電……といった粒度に細分化され、 マーク数も大きく増えます。

ここで重要なのは、合計値そのもの（1億円）は変わっていないという点です。ディメンションを追加して見えるのは、同じ1億円を別の切り口で内訳表示しているだけ、 という事実です。「ディメンション追加で数値が変わった」と感じたときは、実は1マークあたりの集計範囲が変わっただけで、全体の総和は同じであることが多いです。

結合（Join）とリレーションシップで粒度の扱いが違う

合計が膨らむもう一つの代表的な原因が「結合による重複行の発生」です。Tableauには「結合（Join）」と「リレーションシップ」という 2つのテーブル接続方式があり、データ粒度の扱い方がまったく異なります。

結合は行を物理的に複製する

結合（Join）は、SQLのJOINと同じ仕組みで、2つのテーブルを結合キーで突き合わせて1つのフラットなテーブルを物理的に作る方式です。 Tableauでは「データソース」タブで結合を設定します。

このとき、結合先のテーブルにキーが複数件存在すると、結合元のレコードが複製されます。たとえば「注文ヘッダー1件」に「注文明細3件」が紐づいている場合、 結合後の物理テーブルでは注文ヘッダーの内容（注文金額・顧客名など）が3行に複製されることになります。

結合後の物理テーブルでそのまま「注文金額」を合計すると、本来1件の注文金額が3回足されてしまうため、想定の3倍に膨らむことになります。 これが「結合で合計が膨らむ」現象の正体です。

リレーションシップは集計時に解決する

リレーションシップは、Tableau 2020.2以降で導入された新しい接続方式で、テーブル同士の関係を「論理的に」定義する仕組みです。 データソース上では物理的に結合されず、ビューで使用したフィールドに応じて適切な集計が自動的に行われます。

リレーションシップを使った場合、注文ヘッダーから「注文金額の合計」を取り出せば、明細テーブルの行数に関係なく注文ヘッダー基準の集計結果が返ります。 Tableauが内部で各テーブルの粒度を保持したまま集計してくれるため、結合のような重複行による合計の膨張は基本的に起きません。

ただし、リレーションシップはすべての場面で結合より優れているわけではありません。同じテーブル内で集計を完結させたい場合や、 抽出ファイルのパフォーマンスを最大化したい場合は結合が適しています。試験では「結合とリレーションシップのどちらを選ぶべきか」という シナリオ問題が出題されるため、両者の挙動の違いを押さえておくことが重要です。結合とリレーションシップの基本的な使い分けは入門学習データモデルと関係 — 結合・リレーションシップの違いを整理するおよび結合とユニオン — テーブルをつなぐ2つの方法で確認できます。

注文 × 商品 結合で売上合計が膨らむ事例

具体的な数値で「結合で合計が膨らむ」現象を追ってみます。次のような2つのテーブルを想定します。

注文ヘッダーテーブル（3件）

合計：35,000円

注文明細テーブル（6件）

注文ヘッダーと明細を「注文ID」で内部結合すると、結合後の物理テーブルは6行になります。注文金額が次のように複製されます。

このテーブルでSUM([注文金額])を取ると、10,000 + 10,000 + 20,000 + 20,000 + 20,000 + 5,000 = 85,000円になります。 本来35,000円であるはずの合計が、85,000円という想定の2.4倍の値に膨らんでしまいました。これが結合による重複行が原因の合計膨張です。

実務では「注文と商品マスタを結合してダッシュボードを作ったら、なぜか売上が他の集計と合わない」という形でこの現象に直面します。 原因を結合構造まで遡って特定できるかどうかが、Tableau実務者の力量の分かれ目になります。

COUNT(DISTINCT) で回避できるケース・できないケース

合計の膨張に対する対処法はいくつかありますが、まず押さえておきたいのがCOUNT(DISTINCT)とLOD式の使い分けです。

COUNT(DISTINCT)はその名のとおり「ユニーク件数」を数える関数です。先ほどの結合例で「注文件数」を出したい場合、結合後のテーブルで単純な SUM(1)やCOUNT(*)を取ると6件と出てしまいますが、COUNTD([注文ID])を使えば3件と正しい値が返ります。 「件数」を求めるケースでは、COUNT(DISTINCT)は重複行への対処として有効です。

一方、COUNT(DISTINCT)が向かないのが「合計金額」のような連続値メジャーの集計です。注文金額の合計を出したい場合、 COUNTD([注文金額])は単に「異なる金額の種類数」を返すだけで、本来求めたい合計値にはなりません。このケースではLOD式（FIXED）を使うのが基本です。

たとえば{FIXED [注文ID] : MIN([注文金額])}という計算フィールドを作り、これをSUMで集計すれば、 注文IDごとに1つの注文金額を固定して合計できるため、結合による重複の影響を避けられます。あるいは、データ構造そのものを見直して、 結合ではなくリレーションシップに切り替えるという根本的な対処もあります。動的な閾値と組み合わせたい場合は、パラメーターと組み合わせる設計も有効です。 詳しくはTableauのパラメーター・セット・コンテキスト 違いと使い分けで解説しています。

「件数の重複ならCOUNT(DISTINCT)・連続値の重複ならFIXED LODまたはリレーションシップ」という対応関係を覚えておくと、 トラブルシュートで迷いにくくなります。LOD式そのものの使い分けはLOD式（FIXED/INCLUDE/EXCLUDE）完全解説で詳しく扱っています。

試験で問われる典型パターン

Tableau Certified Data Analyst試験では、データ粒度に関する問題が「データの探索と分析」ドメインで複数出題されます。 代表的なパターンを3つ紹介します。

パターン1：粒度変化の理由を問う問題
「ビューにディメンションを追加したら表示マーク数が大幅に増えた。原因として最も適切なものはどれか」という形式で、 「ビュー粒度が細かくなったため」を選ばせる問題です。集計方法の変更・キャッシュ・フィルター解除などの紛らわしい選択肢に惑わされないことが鍵です。

パターン2：結合とリレーションシップの選択
「2つのテーブルを使ってダッシュボードを作る際、それぞれの粒度を保ったまま集計したい場合に最も適切な接続方式はどれか」という問いで、 リレーションシップを選ばせる問題が出題されます。結合（Join）は行を物理的に複製するため重複が発生しやすく、 リレーションシップは集計時に粒度を保持するという違いを押さえておきましょう。

パターン3：合計膨張の対処法
「結合後のテーブルで売上合計が想定より大きくなった。最も適切な対処はどれか」という応用問題では、FIXED LOD・COUNT(DISTINCT)・ データ構造の見直しといった選択肢から、ケースに応じた最適解を選ぶ判断力が問われます。「件数か金額か」「単発の対処か根本対処か」を整理して考えることが大切です。 計算フィールド・LOD式・テーブル計算の使い分け全体像は計算フィールド vs LOD vs テーブル計算 フローチャートで整理しています。

※ 本記事はTableau Certified Data Analyst試験の学習を支援する目的で作成しています。 結合・リレーションシップの仕様や試験の最新情報はSalesforce（Tableau）の公式ドキュメントをご確認ください。 Tableau・Salesforceは各社の商標または登録商標です。