Snowflake×Tableau連携のお話　仮想接続でやってみた

はじめに

こんにちは！千株式会社でデータアナリストをしているSAWA(@data_and_cat)です。 SEN Advent Calendar 2025 11日目の記事を担当します🎄

前回の記事（Tableau「DATA Saber」が考える初心者向けSnowflake勉強法）で、Redashとスプレッドシートの運用から、SnowflakeでSSOT(Single Source of Truth)を実現するプロジェクトをやってるよと冒頭で書きました。

今回は、その続きとして「SnowflakeのデータマートをTableauに繋ぐ際にやっちまったこと」を共有します。

はじめに
プロジェクトの背景
なぜ仮想接続を選んだのか
やっちまった話:命名ルールを後回しにした結果
使い始めてやっぱり露呈した問題
け、決断:命名ルールの策定と全修正
やっちまった地獄の修正作業:Tableauへの影響
もう一つの反省:仕様書テンプレートの未設定問題
今やっている対策:再発防止
学んだこと:データ基盤×BI連携の教訓
これからSnowflake-Tableau連携を始める人へのメッセージ

プロジェクトの背景

目指したもの

Snowflakeで構築した統合データマートをTableauで可視化
各部署が共通のマートから条件を絞り込んで利用できる環境
SQLを書けない人もデータ活用できるセルフサービスBI

今回目指したデータの流れ

既存システム(大量のテーブルがあるDBが存在)
  ↓
Snowflake(必要なテーブルを取り込みデータマート作成)
  ↓
Tableau(クレンジング・可視化・分析)
  ↓
各部署でのデータ活用

なぜ仮想接続を選んだのか

SnowflakeとTableauを繋ぐ方法として、仮想接続を採用しました。前職では当初 Tableau Desktopでの直接接続していたのですが、データの管理、特に認証管理が煩雑になってしまったため、仮想接続を取りました。なので仮想接続一択で接続設定をしていきました。そのメリットを踏まえ違いをご紹介します。

Tableau Desktopでの直接接続との違い

直接接続の場合

[Snowflake → Tableau Desktop]
        ↓
ワークブックからパブリッシュする際に接続情報が埋め込まれる
        ↓
個人のアカウント認証に紐づく

問題点:

ワークブックごとに接続設定が分散、Snowflake接続であることもわからない
誰がどのデータに接続しているか把握困難
作成者が異動・退職すると修正不可能に ← これが地味につらい

仮想接続の場合

Snowflake → 仮想接続 → Tableau Desktop
                ↑
          ここで一元管理、接続情報は１つ

仮想接続のメリット

1. 接続の一元管理

複数のワークブックで同じ仮想接続を参照が可能
どのワークブックがどのデータソースを使っているか可視化、非表示管理も可能
接続設定の変更が全ワークブックに自動反映 ← ここで日本語に変えておけば各ワークブックでカラム名を日本語に変える必要もないし揺れない！！
仮想接続_テーブルを選択

2. 認証情報の管理効率化

データベースのパスワード変更時、仮想接続を1箇所更新するだけでOK

3. 行レベルセキュリティ(RLS)の適用

仮想接続レベルでデータポリシーを設定
ユーザーごとに見えるデータを制御可能 ※ここはまだ未対応ですが、使う日が来るかも

4. ダッシュボード作成者の負担軽減

Snowflakeの接続情報や資格情報を知らなくてもデータアクセス可能
「公開された仮想接続」を選ぶだけで利用開始

やっちまった話:命名ルールを後回しにした結果

今日の本題はここからです。

前提:日本語カラム名からのスタート

もともとRedashでは日本語カラム名でデータを扱っていました。

-- Redashで使っていたクエリの例
SELECT
  顧客名,
  売上金額,
  プラン,
  注文件数
FROM ...

Snowflakeのマート構築のためのSQLも、日本語カラム名のままSnowflake上で進めていました。

当時の意識:

複数システムのデータが正しく結合できているか(ドキドキ)
必要なカラムが漏れていないか(不安)
数値が重複していないか(絶対確認！)

気づいた瞬間:「おや、、英語名が揺れてる?」

Snowflakeでマートを作る際はすべて英語のカラム名に変換が必要なことをすっかり失念していた私。その穴を埋めるため、マート作成を依頼したエンジニアが英語化をしてくれてました。

しかし、元々のDBの英語名自体がノールールで自由かつレガシー感あふれる状態。ビジネス側用語に合わせて日本語に訳していたため、それらのコンテキストをちゃんと伝えてなかったことから起きる揺れ。

-- 売上集計用マートA
SELECT
  customer_name,        -- 顧客名
  total,             -- 売上金額
  plan,              -- 契約プラン
  order_count        -- 注文件数
FROM A;

-- 売上集計用マートB
SELECT
  customername,         -- 顧客名(元のカラム名がアンダーバーがない状態)
  sales_amount,      -- 同じ「売上金額」なのに別の英語名
  contract_plan_name,-- 同じ「契約プラン」なのに別の英語名
  total_orders       -- 同じ「注文件数」なのに別の英語名
FROM B;

同じカラムを指すはずのものが、複数の英語名で存在していました。

見て見ぬふりをした判断

「揺れてる？」と気づきながらも...

「Tableauで日本語の別名つければいいよね」
「とにかく実装優先」
「気になるけど命名ルール整備してたらスケジュールが遅れるなぁ」

この判断が、後に大きなツケとなって返ってきます。

使い始めてやっぱり露呈した問題

問題1:どのカラムを使えばいいか分からない

Tableauで日本語に置き換える際、すでに混乱しつつあり:

├── revenue (数値)
├── sales_amount (数値)
├── total_amount (数値)
└── photo_order_amount (数値)

「写真の売上」を表示したいけど、どれだっけ…

問題2:ドキュメントも統一されていない

仕様書は書いていたが、テンプレがあったわけではなく自由に作成状態:

マートAは詳細な仕様書あり
マートBはクエリの説明を詳しく書いている
マートCはクエリのみ、あとは注釈程度

元のテーブル名やSnowflakeカラム名とTableauでの日本語カラムの対応表も存在しませんでした。

問題3:問い合わせ対応が発生

Snowflakeを触ろうとした人から次々と確認が来ます:

「このカラムって何のデータですか？」
「revenueとsales_amountの違いは何ですか？」
「planとcontract_plan_nameは同じものですか？」

同じような質問に答える羽目に...これではデータへの信頼が...

SSOTを目指したはずが、「どの数字が正しいの?」状態に逆戻り。これじゃだめだ！！！

け、決断！！！ぐぬぬ:命名ルールの策定と全修正だ

やったこと

1. 業務用語と英語名の対応表を作成

ビジネス側用語	統一後の英語カラム名	データ型	説明
顧客ID	CUSTOMER_ID	VARCHAR	顧客の識別子
売上金額	TOTAL_AMOUNT	NUMBER	合計金額
契約プラン	CONTRACT_PLAN_NAME	VARCHAR	契約プラン名称
注文件数	ORDER_COUNT	NUMBER	注文件数

2. 命名規則の策定

プロジェクトで実際に作成した命名ルールから抜粋:

【基本ルール】
1. すべて大文字を使用(Snowflakeの標準)
2. アンダースコア(_)で単語を区切る
3. 日本語のローマ字は使わない

【命名パターン】
主キー・外部キー:
  - {テーブル名}_ID (例: CUSTOMER_ID, ORDER_ID)

日付・時刻系:
  - {対象}_DATE (例: ORDER_DATE, CREATED_DATE)
  
数値系:
  - {対象}_COUNT (例: ORDER_COUNT, CHILD_COUNT)
  - {対象}_AMOUNT (例: TOTAL_AMOUNT, TAX_AMOUNT)
  
フラグ系:
  - IS_{状態} (例: IS_ACTIVE, IS_ENROLLED)
  
名称系:
  - {対象}_NAME (例: CUSTOMER_NAME, FACILITY_NAME)

3. 全マートのカラム名を修正

-- 修正前のバラバラな命名
-- マートA
revenue              -- 売上
plan                 -- プラン
order_num            -- 注文数

-- マートB  
sales_amount         -- 売上(別の英語名)
contract_plan_name   -- プラン(別の英語名)
total_orders         -- 注文数(別の英語名)

-- 統一後
-- すべてのマートで同じ命名規則に
TOTAL_AMOUNT         -- 合計金額
CONTRACT_PLAN_NAME   -- 契約プラン名
ORDER_COUNT          -- 注文件数

やっちまった地獄の修正作業:Tableauへの影響

カラム名変更により、Snowflake接続画面、Tableauの既存ワークブックがエラーに。

影響を受けた箇所

1. データソース接続(仮想接続画面)

カラム名変更後のエラー画面(赤い感嘆符が表示される)

各テーブルのデータソース設定を開いて過去のものを除外、修正したものを日本語変換する作業が必要に。

2. 各ワークブックでの修正

英語名も日本語名も変わったものを1つずつ修正

計算フィールドの中身の変更

全ての計算フィールドを手作業で置き換え修正。

// 修正前
IF [plan] = "フル" THEN [revenue] * 0.05
ELSEIF [plan] = "ハーフ" THEN [revenue] * 0.08
ELSE [revenue] * 0.1
END

// 修正後
IF [CONTRACT_PLAN_NAME] = "フル" THEN [TOTAL_AMOUNT] * 0.05
ELSEIF [CONTRACT_PLAN_NAME] = "ハーフ" THEN [TOTAL_AMOUNT] * 0.08
ELSE [TOTAL_AMOUNT] * 0.1
END

フィルター

カラム名が変わったフィルターは全て再設定が必要。

修正前: [plan] のフィルター → エラー
修正後: [CONTRACT_PLAN_NAME] で再作成

ツールヒント

// 修正前のツールヒント設定
売上: <revenue>
プラン: <plan>
注文数: <order_num>

// 修正後
売上: <TOTAL_AMOUNT>
プラン: <CONTRACT_PLAN_NAME>
注文数: <ORDER_COUNT>

もう一つの反省:仕様書テンプレートの未設定問題

命名ルールと同時期に、仕様書のバラつきもやっぱりなんとかせねばと思うように。

統一した仕様書テンプレートを作成

実際にプロジェクトで作成したテンプレートの主要部分:

# マートテーブル仕様書

## 1. 基本情報
| 項目 | 内容 |
|------|------|
| テーブル名 | PHOTO_ORDER_SUMMARY |
| スキーマ名 | MART_PHOTO |
| 作成日 | 2024-11-26 |
| 作成者 | データ分析チーム |

## 2. テーブル概要
### 2.1 目的
月次の写真注文状況を顧客別に集計し、注文率や売上推移の分析に利用する

### 2.2 更新頻度
- 更新タイミング: 日次 03:00
- データ取得範囲: 前日までの累積データ

## 3. データソース
### 3.1 参照元テーブル
| スキーマ名 | テーブル名 | 使用目的 |
|-----------|-----------|---------|
| RAW_PHOTO | PHOTO_ORDERS | 写真注文データ |
| RAW_PHOTO | PHOTO_ORDER_DETAILS | 注文明細データ |
| MASTER |CUSTOMER_MASTER | 顧客マスタ |

## 4. テーブル定義
### 4.1 カラム一覧
| カラム名 | データ型 | NULL可否 | 説明 | 元スキーマ | 元テーブル | 元カラム名 |
|---------|---------|---------|------|-----------|-----------|-----------|
| CUSTOMER_ID | VARCHAR | NOT NULL | 顧客D | MASTER | CUSTOMER_MASTER | customer_id |
| CUSTOMER_NAME | VARCHAR | NULL | 顧客名 | MASTER | CUSTOMER_MASTER | customer_name |
| ORDER_YEAR_MONTH | VARCHAR | NOT NULL | 注文年月 | RAW_PHOTO | PHOTO_ORDERS | order_date |
| ORDER_COUNT | NUMBER | NULL | 注文件数 | RAW_PHOTO | PHOTO_ORDERS | order_id |
| TOTAL_AMOUNT | NUMBER | NULL | 合計金額 | RAW_PHOTO | PHOTO_ORDERS | total_amount |

今やっている対策:再発防止

1. 命名ルールのMDファイル化

命名規則を詳細にドキュメント化し、プロジェクト内で管理。

実際のファイル構成:

/rules
  ├── snowflake_column_naming_rules.md (命名規則)
  ├── mart_table_spec_template.md (仕様書テンプレート)
  └── business_terms_dictionary.md (業務用語辞書)

命名ルールには以下の内容を含む:

基本ルール(大文字、アンダースコア区切りなど)
命名パターン(ID、DATE、COUNT、AMOUNTなど)
IDとNUMBERの使い分け
具体的な命名例
避けるべき命名
よくある変換例

2. Claude Codeでの自動チェック

新規カラム作成時の流れ:

1. Claude Codeに命名規則MDを読み込む
2. 「このデータは『注文の合計金額』です。適切なカラム名を提案してください」
3. Claude: 「TOTAL_AMOUNTが適切です。理由は...」
4. 命名規則との整合性を確認
5. 最終的にテンプレに記入依頼

3. エンジニアとビジネス側の間に入った翻訳を意識した確認フロー

カラム命名時のフロー:

業務要件の確認
    ↓
ビジネス側用語の定義(日本語)
    ↓
英語名の提案(Claude Code活用)
    ↓
データエンジニアがレビュー
    ↓
命名規則への適合確認
    ↓
承認・採用

学んだこと:データ基盤×BI連携の教訓

1. 技術選定だけでは不十分

仮想接続という正しい技術選定をしても、運用ルールが伴わなければ意味がない。

2. 「気づいたらすぐ対処」が鉄則

「あれ？」と思った瞬間が、対処すべきタイミング。「あとで」「まあいいか」は禁物。絶対ダメ。

3. 後戻りコストを見積もる

実装を急ぐ気持ちは分かるが、後から修正するコストと比較すべき。

タイミング	修正コスト	実際の工数
気づいた時点(マート構築中)	小	数時間
ワークブック作成開始後	中	2-3日
本番運用開始後	大	数週間〜

今回のケースでは、約2日間分の修正作業 + スケジュール的に1週間遅延という代償を払いました。

4. AIツールを味方につける

Claude Codeに命名ルールMDを読み込ませることで:

命名の一貫性が保たれる
人的ミスが減る
レビュー工数が削減される

命名規則のチェックなど、機械的な作業はAIに任せる。人間は「ビジネスコンテキストが正しいか」の判断に集中。

これからSnowflake×Tableau連携を始める人へのメッセージ

技術的には正しかった

仮想接続の採用はよかった
Snowflakeでのデータマート構築もできた
SSOTを目指す方向性も間違っていないはず

でも運用面で失敗した

命名ルールの後回し
ドキュメントルールの未整備
「気づいてたのに見て見ぬふり」←これが一番ダメ！絶対ダメ！！（大反省）

得られた教訓

データ基盤構築は技術(SQL)だけじゃない
運用ルール、ドキュメント、コミュニケーションが重要
「あとで」のツケは必ず回ってくる
でも、気づいた時点で改善する勇気も大切 ←一番大事！！

今できていること

詳細な命名規則ドキュメント
実用的な仕様書テンプレート
Claude Codeによる自動チェック体制

この記事が、誰かの「やっちまった」を防ぐきっかけになりますように。 ※実際のプロジェクトをベースにしていますが、記事用に名称は変更しています。

さて明日のSEN Advent Calendar 2025 はYuba41のお話ですよ！お楽しみに～

参考リンク

Tableau仮想接続について(公式ドキュメント)

💼 お問い合わせ

私たちと一緒に、幼保業界や写真業界のDXを進めていく仲間を募集中です！

📋 採用情報