きれいに作り込んだTableauダッシュボードも、データが古ければ「過去の絵」です。最新に保つ鍵は、ビューではなくその下にあるデータソースの更新。けれど多くの現場は、DWHの構築・Bridgeの常駐・手動の抽出更新に時間を奪われています。Passworkは、複数SaaSのデータをそのままTableau Cloudに直接パブリッシュ。DWHを経由せず、スケジュール実行で「Tableau データソースの自動更新」を、設定だけの仕組みにします。
なぜTableauの「データ更新」はいつも詰まるのか
「ダッシュボードの数字、いつのですか？」── このひと言で、せっかくの会議が止まることがあります。Tableauのビジュアルは一度作れば残りますが、その下のデータが自動で新しくなるわけではないからです。鮮度を保つには、ビューではなくデータソースそのものを更新し続ける必要があります。
ところが、この「データソースを更新し続ける」が、現場ではいくつもの方式に分かれ、それぞれに手間が潜んでいます。
- 抽出の手動更新 ── 誰かが手作業でデータを更新。属人化して、更新が止まる
- Tableau Bridgeの常駐 ── オンプレやSaaSと繋ぐためにPCやサーバーを常時起動。落ちると更新も止まる。
- DWHを挟む構成 ── 一度データウェアハウスに集約してからLive接続。鮮度は出るが、DWHの構築・運用コストがのしかかる
- CSVファイルによる、SaaSごとの直結での連携 ── コネクタ非対応のSaaSは結局CSVを手作業で取り込む
「ダッシュボードは完成しているのに、データを最新にする作業だけが毎週残る」── BIの価値は”見られる状態が続くこと”にあります。一度きりの構築よりも、更新が止まらない仕組みのほうが、ずっと難しい。ここを人手やDWHに頼り続けると、BIは「専門チームのもの」から動けなくなります。
Passworkは、この「データソースを更新し続ける」を、DWHもBridgeも常駐PCもなしに引き受けるために設計されています。
「DWHを経由しない」という選択肢
BIの定石の１つとして「まずDWHにデータを集めてから繋ぐ」があります。DWHは正しいシステム構成です。けれど、すべての更新がDWHを必要とするわけではありません。「特定の部署の、特定のダッシュボードを、毎朝最新にしたい」── この規模に、DWHの構築・運用は重すぎることがあります。
Passworkは、SaaSやDBから取得したデータを、そのままTableau Cloudのデータソースへ発行することが可能です。間にDWHを必要としません。2つの経路を並べると、違いがはっきりします。
もちろん、全社横断の大規模分析にはDWHが向きます。ここで言いたいのは「DWHか、何もないか」の二択ではないということです。DWHを立てるほどではない更新を、Passworkが軽く埋める。用途に応じて経路を選べるのが現実的です。
Passworkが発行するのは、Tableau Cloud上のPublished Data Source（公開データソース）です。つまり既存のワークブックは、データソースを差し替えるだけで、そのまま最新データを参照できます。ダッシュボードを作り直す必要はありません。
仕組み：個人用アクセストークン（PAT）によるAPI実行
「DWHなしで、どうやってTableauに発行するのか？」── 中身はシンプルです。Passworkは、フローを流れるデータをTableau REST APIでアップロードします。
- ①フローのデータを取得する
入力ノードや数式ノードを経て整ったデータを取得します。
- ②RESTで分割アップロード
Tableauのアップロードセッションを開始し、ファイルをチャンクに分けて送信。サイズの大きいデータでも安定して送り切れます。
- ③データソースとしてPublish（commit）
指定したプロジェクトに、指定した名前でPublished Data Sourceを発行。これでTableau Cloud上のデータが入れ替わります。
更新の振る舞いは3つのオペレーションから選べます。
| オペレーション | 振る舞い | 使いどころ |
|---|---|---|
| 作成 (create) | 新しいデータソースを作る | 初回の発行。まだ存在しないデータソースを用意したいとき |
| 上書き (overwrite) | 同名のデータソースを丸ごと差し替える | 定期実行で毎回最新スナップショットに更新したいとき |
| 追加 (append) | 同名のデータソースにデータを追加する | 定期実行で毎回差分データを追加したいとき |
定期的な自動更新の主役は、上書き（overwrite）か追加（append）です。同じデータソースが常に最新の中身に置き換わります。ワークブック側は何も変えなくて構いません。
設定の実際：出力ノードに入れる5項目
仕組みは中で動くだけで、設定する側がやることは多くありません。フローの最後にTableau Cloud 出力ノードを置き、サイドバーで次の項目を埋めるだけです。
- コネクタ（接続情報）を選ぶ : Tableau Cloudへの接続は個人用アクセストークン（PAT）で行います。事前に登録したコネクタを選ぶだけです。
- オペレーションを選ぶ : 作成 (create) 、 上書き (overwrite)、追加(append)を選びます。
- 対象データ（上流ノード）を指定する : どのノードの出力をデータソースにするかを選びます。整形済みのデータをそのまま渡せます。
- 対象プロジェクトを入力する : 発行先のTableauプロジェクト名（例：
営業管理）を指定します。 - データソース名を決める : 発行するデータソースの名前（例：
SalesData_2024Q1）。overwriteのときはこの名前が更新先のキーになります。
あとは項目マッピングで、上流データの列をデータソースの列に対応づければ完成です。出力先の項目対応に迷うときは、AIによる項目マッピング自動提案が橋渡しを補助してくれます。
設定の実際：出力ノードに入れる5項目
ここまでで「1回の発行」はできました。「自動更新」にする最後のピースが、スケジュール実行です。Passworkでは、作ったフローに実行スケジュール（例：毎朝6時、1時間ごと）を設定できます。これで、人が触らなくてもデータソースが更新され続けます。
このとき効いてくるのが、入力側の増分連携です。取得するデータ量を「前回以降に変わったぶん」に絞るといった設計ができます。Passworkには、前回成功したジョブの実行時刻を埋めてくれるシステム変数があります。
# 入力条件：前回成功ジョブの開始日時以降に更新されたものだけを対象に
更新日時 >= {{lastSucceededJobStartedAt()}}全件を毎回取りに行く必要がなくなるので、ソースのSaaSへの負荷も、フローの実行時間も軽くなります。日付境界の計算は変数が引き受けるため、「昨日の23:59以降が漏れる／二重に取れる」といった境界のミスも避けられます。
更新が「ちゃんと回り続けているか」も見える化しておくと安心です。Passworkは実行ログとステータスを残すので、更新が失敗したら気づける状態を作れます。BIで一番怖いのは「古い数字に気づかずに意思決定すること」── 更新の成否を監視まで含めて仕組みにするのが、本当の自動化です。
実例：複数SaaSを束ねて1つのデータソースへ
商談はSalesforce、受注実績は基幹、広告コストは各媒体」といったデータを、1枚のダッシュボードで見たいケースを考えます。
① 複数の入力ノードでデータを集める
Salesforce・kintone・広告各媒体など、必要なソースぶんの入力ノードを並べます。それぞれの抽出条件に {{lastSucceededJobStartedAt()}} を入れ、増分だけを取得します。
② フロー内で結合・整形する
数式ノードやマッピングで、各ソースの形式のズレ（コード値・日付・項目名）を吸収し、1つの分析テーブルの形にまとめます。DWHでやっていた前処理を、フローの中で完結させるイメージです。
③ Tableau Cloud 出力ノードへ繋ぐ
整えたデータを統合実績データ のようなデータソースに発行。プロジェクトとデータソース名を指定するだけです。
④ スケジュールを設定して放置する
毎朝の実行を設定すれば、以降は3つのSaaSを横断した最新データソースが、毎朝自動で更新されます。Tableau側のワークブックは、このデータソースを参照するだけ。Bridgeも常駐PCも要りません。
複数ソースを束ねるとき、1つのソースだけ更新が遅れると、ダッシュボード全体の整合が崩れます。Passworkなら、複数ソースの取得から発行までを1本のフロー・1つのスケジュールで束ねられるので、「どれかだけ古い」が起きにくい。更新のタイミングが1点に揃うのは、地味ですが大きな安心です。
まとめ：ダッシュボードの”鮮度”を仕組みにする
Tableauのデータソース自動更新は、「便利な追加機能」ではありません。本質は、BIを”作って終わり”から”動き続ける状態”へ変えることです。
- DWHを経由しないダイレクト発行で、軽い更新を軽いまま回す
- 既存ワークブックはそのまま最新化
- スケジュールで、毎回きれいな最新スナップショットに更新
- 入力側の増分連携で、取得量とソース負荷を抑える
- 複数SaaSを1本のフローで束ね、更新タイミングを1点に揃える
