Tableauで“別々のデータ”をつないで分析する方法──リレーションシップ／結合／ブレンド／ユニオンの使い分け

1. データモデルの基礎

Tableau 2020.2以降では、データソースに「論理レイヤー」と「物理レイヤー」という二層構造が導入されました。

• 論理レイヤー（リレーションシップ）
  表同士の“関係”を定義する層です。結合で一枚に潰さず、それぞれの表の粒度を保ったまま扱えるのが特徴です。可視化の文脈に応じて最適な結合が自動的に解決されるため、近年はこの方法が推奨されています。

• 物理レイヤー（結合・ユニオン）
  従来どおりのアプローチで、表をジョインやユニオンで一枚にまとめる層です。分かりやすい一方、粒度のズレや重複に注意が必要です。

ベストプラクティスは「まずはリレーションシップで組み、どうしても必要な場合のみ物理的な結合を検討する」ことです。

2. 4つの統合アプローチの違い

(1) リレーションシップ（Relationships）

論理レイヤーで表同士を“対応付け”るだけで、必要に応じてクエリが解釈されます。

• 強み：粒度の異なる表をそのまま扱える／軽量で設計変更に強い

• 使いどころ：売上明細と顧客マスタ、日付ディメンションなど粒度の異なるデータを自然に横断

(2) 結合（Joins）

物理レイヤーでインナー結合や左結合などを指定し、1枚のテーブルにまとめる方法です。

• 強み：条件付き結合や厳密なクエリ固定に有効

• 注意：公開済みデータソースは結合できない／クロスDB結合には制限あり

(3) ブレンド（Blending）

シート単位で「主」と「従」のデータソースを組み合わせる方法です。

• 強み：公開済みデータソース同士を組み合わせたいときに便利

• 注意：従側は“集計後”に組み合わされるため、COUNTDやMEDIANなど一部計算に制約あり

(4) ユニオン（Union）

同じ列構造の表を縦に積む方法です。

• 使いどころ：月次CSVを年次にまとめる、支店別ファイルを一本化するケース

• 注意：同じ接続内でのみ利用可能

3. 選び方の判断フロー

• 粒度が異なる → リレーションシップ

• 1枚の固定テーブルが必要／条件付き結合 → 結合

• 公開済みデータソース同士やシート単位でリンクを変えたい → ブレンド

• 同じ列構造のファイルを縦積み → ユニオン

4. 実践シナリオ

• シナリオA：CRM明細＋顧客マスタ＋カレンダー
  → リレーションシップで粒度の違う表を自然に横断

• シナリオB：売上（DB）×目標（Excel）
  → 結合で1枚化し、KPI達成率を算出

• シナリオC：公開済みDS A（売上）とB（広告）
  → ブレンドでシート上に重ね合わせ、相関を分析

• シナリオD：支店ごとの月次CSV
  → ユニオンで縦積みし、年次ダッシュボードを作成

5. ありがちなつまずきと対処法

• 粒度のズレで数値が倍増／欠落 → リレーションシップを優先

• 公開済みDS同士を組み合わせたい → ブレンドを利用

• ブレンドでアスタリスクやCOUNTD制約 → 粒度調整、必要なら結合へ変更

• クロスDB結合が遅い → 抽出やDB側での前処理を検討

6. 設計のベストプラクティス

• 関係を第一候補に

• 結合は目的が明確なときだけ

• ブレンドは制約を理解して活用

• ユニオンでファイルを整理

• パフォーマンスを意識した設計（フィルタ→集計、抽出の活用、前処理の検討）

7. 基本手順の型

• 関係：キャンバスに表を配置 → キーを指定 → ビューで活用

• 結合：物理レイヤーに入って結合条件を指定 → 値を検算

• ブレンド：主データソースを置き、従を追加 → 共通ディメンションをリンク

• ユニオン：対象の表を追加 → 列名・データ型を調整

8. よくある質問（FAQ）

• 公開済みDS同士を関係でつなげる？ → 不可、ブレンドを使用

• 異なる接続をユニオンできる？ → 不可、ETLや結合で代替

• ブレンドでCOUNTDが使えない理由？ → 従側は集計後に扱われるため制約

• クロスDB結合が遅いときの改善策は？ → 抽出活用、前処理、関係モデルへの切替

9. まとめ

迷ったときの優先順位は、

1. 関係（リレーションシップ）

2. 結合またはブレンド

3. ユニオン

この順で検討するのが、Tableauのデータ統合における近年のベストプラクティスです。