データベース

Tableau Cloudとは：Serverとの違い・SSOとBridgeの設定・Serverからの移行手順【2026年10月】

Adureを利用したインフラ構築

Tableau Cloud（タブロークラウド）は、Tableauのワークブックやデータソースを置いて組織で共有する、Salesforceが運用するクラウドの共有基盤です。旧称はTableau Onlineで、自社でサーバーを立てるTableau Serverとは運用の責任範囲が違います。この記事では、公式の移行ガイドをもとに両者の機能差を整理し、MFA必須の認証設定、クラウドDBの許可リストに入れるIP範囲の取り方、社内のデータベースへつなぐTableau Bridgeの構築、Migration SDKでServerから移す手順を、実装者向けにコマンドとコード付きで示します。

まとめ：Tableau Cloudの導入で先に決める認証・データ接続・移行の要点

新しくTableauを入れるなら、Cloudを前提に考えて構いません。サーバーの構築とバージョンアップをSalesforce側が受け持ち、Tableauは常に最新版で動きます。Serverを選ぶ理由が残るのは、Kerberosでのデータベース認証、キューブへの接続、独自URLなど、Cloudが対応しない要件があるときです。

導入で詰まる箇所は3つに絞れます。1つ目はMFAです。2022年2月からすべての利用者に必須で、SSOのIdP側で満たすか、Tableau自身のMFAで満たすかを決めます。2つ目はデータの置き場所で、クラウドDBなら許可リストにTableau CloudのIP範囲を登録し、社内ネットワークのDBならTableau Bridgeを社内に置きます。

3つ目はServerからの移行です。公式はContent Migration Toolでなく、Tableau Migration SDKを使うよう案内しています。移行の前に、Cloudで使えない接続方式とAPIの認証方式を棚卸しする作業が先です。

Tableau CloudとTableau Serverの違い：運用・接続・認証の比較表

CloudとServerは、作ったワークブックを置く先という役割は同じです。違いは、誰がサーバーを運用するかと、そこから派生する接続・認証の制約に出ます。

公式の移行ガイドで比べるCloudとServerのホスティングと接続の差

公式のTableau Server から Tableau Cloud に移行する際の技術的な考慮事項にある比較から、選定に効く行を抜き出しました。

項目 Tableau Cloud Tableau Server
ホスティングと更新 Tableauが管理 自社で管理
サイトの数 単一サイトが既定 自社で決める
DBやSaaSへの接続 対応（DBごとに制限あり） 対応
カスタム接続 一部のみ対応 対応
キューブ 非対応 対応
AD・Kerberos・LDAP 非対応 対応
ライセンス ロールベース ロールベースとコアベース

Cloudは常に最新版で動き、メジャーアップグレードもダウンタイムなしで行われます。Amazon Web Services上で動いており、日次のバックアップもTableau側が取ります。ただし、このバックアップはシステム全体を戻すためのものです。利用者が誤って消したワークブックを1本だけ戻す手段にはならないため、重要なファイルの控えは自社で持ちます。

Cloudで使えない機能：キューブ・Kerberos・LDAP・独自URLの扱い

同じ移行ガイドには、Cloudで使えない項目が具体的に並んでいます。

  • Kerberosによるデータベース認証（CloudでもBridgeでも不可）
  • キューブのデータソース（参照元のデータベースへ直接つなぐ構成に変える）
  • Connector SDK（.taco）で作った独自コネクタ
  • Active Directory・LDAPとの直接連携（Azure ADならSAMLで連携する）
  • カスタムURL、カスタムフォント、カスタムのウェルカムバナー
  • ゲストユーザー（代わりに接続済みアプリで見せる）

運用監視の方法にも違いがあるため、確認が必要です。Serverで使えたリポジトリへの直接接続はCloudにはなく、代わりに「管理者インサイト」という監視用のプロジェクトを使います。既定のデータ保持期間は90日間で、Advanced Managementを足すと365日まで延びます。

日本のポッドprod-apnortheast-aとデータを置く地域の確認方法

Cloudのサイトは「ポッド」と呼ばれる環境のどれかに置かれます。Tableau Cloud にパブリッシュされたデータへのアクセスの承認によると、日本のポッドはprod-apnortheast-aで、地域はAWSの東京リージョンと同じap-northeast-1です。自分のサイトがどのポッドにあるかは、サインイン後にブラウザに出るURLで確かめられます。

前出の移行ガイドは、データがホストされている地域から外部に送られることはないと説明しています。「データは国内に置く」という規程がある組織は、契約時にポッドが日本かを確かめることが必要です。2024年8月から2025年3月のHyperforce移行でIPアドレスも変わったため、古い許可リストは後述の手順で入れ替えます。

Tableau Cloudの認証設定：MFA必須の要件とSAML・SCIMの構成手順

Cloudに入る方法は、サイト管理者が［設定］の［認証］で決めます。認証のヘルプで選べるのは、MFAを使用したTableau、Google、OIDC、Salesforce、SAMLの5種類です。

2022年2月から必須のMFA：IdP側で満たすかTableauのMFAで満たすか

多要素認証 と Tableau Cloudによると、MFAは2022年2月1日からCloudの必須要件です。満たし方は2通りあります。

  1. 推奨：SAMLやOIDCでSSOを構成し、IdP（Entra ID、Oktaなど）の側でMFAをかける
  2. 代替：TableauIDのまま、Tableau自身の「多要素認証を備えたTableau」を有効にする

Tableau自身のMFAを選ぶ場合は、検証方法の制約に注意します。Tableau Desktop、Tableau Prep Builder、Tableau Bridge、Content Migration ToolからCloudへ入るときは、セキュリティキーやTouch ID・Windows Helloのような組み込みの認証は使えません。作成者には、オーセンティケーターアプリによるワンタイムパスコードも登録させておく運用が無難です。管理者のアカウントには検証方法を2つ以上登録し、10個の使い捨てリカバリコードを控えておくよう公式も勧めています。

SAML・OIDCのシングルサインオンと非常用TableauID管理者の確保

社内でEntra IDやOktaを使っているなら、SAMLかOIDCでSSOを組むのが基本の形です。2025年1月（Tableau 2024.3）からは1つのサイトに複数の認証構成を持てるようになり、2025年1月より後に作ったサイトでは最大20個まで構成できます。

見落としやすいのは、IdPが止まったときの入口です。認証のヘルプは、MFAを使用したTableauで入る専用のサイト管理者アカウントを1つ残しておくよう勧めています。SAMLの証明書の期限切れやIdP側の設定ミスでSSOが通らなくなっても、このアカウントで管理画面に入って直せます。

SCIMでユーザーとグループを同期する設定とトークンの持ち主の注意

人事異動のたびに手でユーザーを足し引きしないために、SCIMでIdPからユーザーとグループを自動で同期させます。前提はSAMLかOIDC（あるいはGoogle）のSSOが構成済みであることで、OIDCとGoogleを選べるようになったのは2026年2月（Tableau 2026.1）からです。IdP別の手順はEntra ID、Okta、OneLogin、PingFederateが用意されています。

設定は［設定］→［認証］のSCIMの欄で新しい設定を作り、ベースURLと生成したシークレットをIdP側に貼る流れです。ここに落とし穴があります。シークレットは作成したサイト管理者に紐づいており、その人のサイトロールが変わるかサイトから外れると無効になる仕組みです。担当者の異動で同期が突然止まる事態を避けるには、個人でなく運用用の管理者アカウントで作成します。SCIMを有効にした後は、ユーザーの属性をTableau側で直接書き換えず、IdP側で管理します。

社内DBやクラウドDBへの接続設定：IP許可リストとBridgeの構築手順

Cloudからデータへの経路は、データの置き場所で2つに分かれます。クラウド上のDBには直接つなぎ、社内ネットワークの中にあるDBにはBridgeを経由させます。

クラウドDBの許可リストにCloudのIP範囲を登録するPythonの例

Amazon RDSやSnowflakeのように接続元IPを絞っているDBには、Tableau CloudのIP範囲を許可リストに足す必要があります。前出のアクセスの承認のヘルプでは、日本のポッドの範囲は141.163.208.0/23です。Salesforceは範囲の更新を自動で取り込めるよう、ip-ranges.jsonを公開しています。新しいIPは有効になる30日以上前にこのファイルへ追加されます。

# ip-ranges.json から東京（ap-northeast-1）のIP範囲を取り出す
import json
import urllib.request

URL = "https://ip-ranges.salesforce.com/ip-ranges.json"
REGION = "ap-northeast-1"  # 日本のポッド prod-apnortheast-a の地域

with urllib.request.urlopen(URL, timeout=30) as r:
    data = json.load(r)

print("createDate:", data["createDate"])  # ファイルの版。前回の値と比べて差分を検知する
cidrs = sorted({c for p in data["prefixes"] if p["region"] == REGION for c in p["ip_prefix"]})
for cidr in cidrs:
    print(cidr)

2026年10月25日に実行した結果は、createDateが2026-10-16-04-32-59、範囲は141.163.208.0/23の1件でした。取り出した範囲をRDSのセキュリティグループへ足すには、authorize-security-group-ingressを使います。PostgreSQLの5432番を開ける例です。

aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --ip-permissions 'IpProtocol=tcp,FromPort=5432,ToPort=5432,IpRanges=[{CidrIp=141.163.208.0/23,Description="Tableau Cloud prod-apnortheast-a"}]'

このJSONは地域ごとのSalesforce全体の範囲なので、範囲の中にはTableau以外のSalesforceのサービスも含まれます。DBのユーザーを読み取り専用にし、パスワード認証とSSLを併用することが、接続時の前提です。なお、同じ東京リージョンのS3にあるデータへつなぐ場合は、IPでなくVPCエンドポイント（VPCE）で制御するよう同じヘルプに書かれています。

社内ネットワークのDBにはBridgeを置く：ポート443とPATの準備

社内のSQL ServerやOracleのように、インターネットから直接届かないDBにはTableau Bridgeを使います。Bridge のインストールによると、Bridgeは社内のマシンからCloudへ外向きの接続を張る仕組みです。使うのはポート443で、証明書の検証にポート80を使います。社内からの外向き通信だけで済むため、ファイアウォールに受信の穴を開ける作業は要りません。

Bridgeにプロダクトキーは不要で、動かすユーザーはCloudの認証済みユーザーである必要があります。動かす先はWindowsへのインストールか、LinuxのDockerコンテナです。抽出1回あたりの時間とメモリの上限はTableau（タブロー）とは：製品の種類・データ接続・権限設計と自社開発との使い分けで整理しています。

Bridge for LinuxのDockerfileとコンテナ起動コマンド例

Bridge for Linux をコンテナ用にインストールするに沿った例です。基本イメージはAmazon Linux 2023、Red Hat Enterprise Linux 8・9が対象で、CentOSは対象外です。ダウンロードしたBridgeのRPMとPostgreSQLのJDBCドライバーを作業ディレクトリに置いてから実行します。

# Dockerfile
FROM registry.access.redhat.com/ubi8/ubi:latest
RUN --mount=type=bind,source=tableau-bridge.rpm,target=/tmp/bridge.rpm \
 set -eux; \
 yum -y update; \
 ACCEPT_EULA=y yum install -y /tmp/bridge.rpm glibc-langpack-en; \
 yum -y clean all; \
 rm -rf /var/cache/yum
ENV LANG=en_US.UTF-8 LANGUAGE=en_US:en LC_ALL=en_US.UTF-8
# PostgreSQL の JDBC ドライバー（ファイル名は取得した版に置き換える）
COPY postgresql-42.3.3.jar /opt/tableau/tableau_driver/jdbc/

# ビルドして対話モードで起動する（メールアドレスは環境変数で渡す）
docker buildx build --platform=linux/amd64 -t bridge_final .
docker container run -it -e BRIDGE_USER_EMAIL bridge_final /bin/bash

# 以下はコンテナ内。PAT は {"トークン名": "シークレット"} の JSON で保存する
chmod 600 /root/bridge_pat.json
/opt/tableau/tableau_bridge/bin/run-bridge.sh -e \
  --patTokenId="bridge-agent-01" \
  --userEmail="$BRIDGE_USER_EMAIL" \
  --client="bridge-agent-01" \
  --site="mycloudsite" \
  --patTokenFile="/root/bridge_pat.json" \
  --poolId="プールID"

--siteにはURLに出るサイト名だけを入れ、パスは含めません。プールIDはCloudの［設定］→［Bridge］でプール名をクリックすると確認できます。省略すると、新規のクライアントは既定のプールに入ります。

PATは1クライアントに1本ずつ割り当てるよう公式が勧めており、1ユーザーあたり104個まで作れます。--patTokenIdとJSON内のトークン名、トークン作成時の名前は、すべて同じ名前にそろえる必要がある項目です。Bridgeが1台だけだと、そのマシンの再起動中は更新を受け持つクライアントがいなくなります。同じプールに2台以上を入れて、片方が止まっても更新が続く構成にします。

Tableau ServerからTableau Cloudへの移行手順：移行SDKの使い方

Serverで運用してきたコンテンツをCloudへ移す作業は、事前の棚卸し、移行ツールの準備、移行の実行の順で進めます。

移行前に洗い出す項目：Kerberos接続・独自コネクタ・APIの認証

移行ガイドの比較を、手元のServerの使い方と突き合わせます。先に洗い出しておかないと、移した後で動かないワークブックが見つかります。

  • Kerberosで認証しているデータソース（ユーザー名とパスワードなど別の方式に変える）
  • キューブにつないでいるワークブック（参照元のDBへつなぎ直す）
  • .tacoの独自コネクタとTableau Exchangeのコネクタ（Cloudでは使えない）
  • ユーザー名とパスワードでREST APIに入る自動化スクリプト（PAT認証へ書き換える）
  • Prepフロー内のRやPythonのスクリプト手順（Cloudでは非対応）

移行ガイドは、Cloudで使えるAPIがPAT（個人用アクセストークン）による認証を前提に作られていると書いています。tabcmdやTableau Server Clientで組んだ定期処理は、移行の工程にPAT化の改修を含めて見積もることが必要です。また、Serverのリポジトリに接続すれば、抽出の容量や更新回数をCloudのサイト容量と比べて事前に評価できます。

Content Migration Toolでなく移行SDKを使う理由と6.1系の導入

Serverのサイト間でコンテンツを移すContent Migration Toolを思い浮かべる人も多いはずです。ただ、Tableau Content Migration Tool については、ServerからCloudへの移行には推奨しないと明記し、Tableau移行SDKを使うよう案内しています。

Tableau Migration SDKは、ServerからCloudへの移行用に作られたクライアントライブラリで、Apache-2.0ライセンスで公開されています。本体はC#の.NETで書かれ、Pythonから呼ぶためのAPIも付いています。2026年10月時点の最新は2026年6月1日公開のrelease/6.1.0です。公式の導入手順では、先に.NETのランタイムを入れ、Pythonならpip install tableau_migrationで導入します。

移行SDKのPythonサンプルでServerからCloudへ移す設定の書き方

公式の導入手順にあるサンプルを、移行計画の組み立てに絞って抜き出した例です。トークンはファイルに書かず、環境変数で渡します。

# config.ini（値は引用符で囲まない）
[SOURCE]
URL = https://tableau.example.internal
SITE_CONTENT_URL =
ACCESS_TOKEN_NAME = migration-source
[DESTINATION]
URL = https://ポッド名.online.tableau.com
SITE_CONTENT_URL = mycloudsite
ACCESS_TOKEN_NAME = migration-destination
[USERS]
EMAIL_DOMAIN = example.co.jp

# migrate.py
import configparser
import os
import tableau_migration

config = configparser.ConfigParser()
config.read("config.ini")

plan_builder = (
    tableau_migration.MigrationPlanBuilder()
    .from_source_tableau_server(
        server_url=config["SOURCE"]["URL"],
        site_content_url=config["SOURCE"]["SITE_CONTENT_URL"],
        access_token_name=config["SOURCE"]["ACCESS_TOKEN_NAME"],
        access_token=os.environ["TABLEAU_MIGRATION_SOURCE_TOKEN"],
        create_api_simulator=False)
    .to_destination_tableau_cloud(
        pod_url=config["DESTINATION"]["URL"],
        site_content_url=config["DESTINATION"]["SITE_CONTENT_URL"],
        access_token_name=config["DESTINATION"]["ACCESS_TOKEN_NAME"],
        access_token=os.environ["TABLEAU_MIGRATION_DESTINATION_TOKEN"],
        create_api_simulator=False)
    .for_server_to_cloud()
    .with_tableau_id_authentication_type()
    .with_tableau_cloud_usernames(config["USERS"]["EMAIL_DOMAIN"])
)

validation_result = plan_builder.validate()  # 計画の検証。エラーがあれば実行しない
plan = plan_builder.build()
results = tableau_migration.Migrator().execute(plan, None)
tableau_migration.MigrationManifestSerializer().save(results.manifest, "manifest.json")
print(results.status)

with_tableau_cloud_usernamesは、Serverのユーザー名にメールのドメインを付けてCloudのユーザー名を作る指定です。Serverのユーザー名が社員番号のような形式なら、Cloud側のメールアドレスと一致するかを事前に確かめます。

実行結果はmanifest.jsonに残ります。サンプルでは、次回の実行時にこのファイルを読み込み、前回の結果を引き継いで続きから流す作りです。まず1部署のプロジェクトで試すと、権限の付け漏れを早く見つけられます。

Tableau Cloudを採用する条件と見送ってServerを残す場面の判断基準

ここまでの機能差を踏まえ、どちらを選ぶかを言い切ります。判断の軸は「サーバーを運用する人手」と「Cloudが対応しない要件の有無」です。

Cloudを選ぶ組織：サーバー運用の人手がなくデータがクラウドにある場合

Tableau専任のサーバー管理者を置けない組織は、Cloudを選びます。データがBigQuery、Snowflake、Amazon Redshiftのようなクラウドにすでにあるなら、Bridgeも要らず、IP許可リストの登録だけで接続が完成します。

費用面では、Serverに必要なサーバー代と運用の人件費がかからない代わりに、抽出の更新枠などサイトの容量に上限があります。ライセンスの年額はTableauの価格｜Creator・Explorer・Viewerの料金と人数別の年額、CloudとServerの差で比べています。

Serverを残す場面：Kerberos必須・キューブ分析・独自URLが要件のとき

次の条件に1つでも当てはまるなら、Cloudへの全面移行は見送り、Serverを残します。

  • 社内DBの認証がKerberosに統一され、別方式の接続ユーザーを作れない
  • キューブ（多次元DB）の分析が業務の中心で、参照元DBへの付け替えができない
  • 社外向けポータルに自社ドメインの独自URLで見せることが契約上の条件になっている
  • Connector SDKで作った独自コネクタが、主要なワークブックの接続先になっている

どれもCloud側の設定では回避できません。逆に、どれにも当てはまらないのにServerを使い続けているなら、移行を検討する時期です。Bridgeの冗長構成、SCIM連携、移行SDKのスクリプト作成まで含めると、情シスの片手間では収まりにくい作業量になります。依頼できる範囲と費用の決まり方はTableauの導入支援｜依頼できる範囲と外注先の選び方、費用の決まり方にまとめました。移行の可否判断から任せたい場合は、BIツール導入支援で現行のServerの構成を棚卸しするところから相談できます。

よくある質問

Tableau Cloudの導入と移行でよく出る質問に答えます。

Tableau CloudとTableau Onlineは同じものですか？

同じ製品です。公式のTableau Cloud のリリース ノートの冒頭に「Tableau Online は Tableau Cloud に変わりました」と書かれています。ヘルプのURLには、旧称の表記である「online」がいまも残っている状態です。Tableau Onlineの名前で書かれた古い解説は画面や手順が現行と違う場合があるため、操作は現行のTableau Cloudヘルプで確かめます。

Tableau DesktopからCloudにサインインするとき、どのMFAが使えますか？

Tableau自身のMFAを使っている場合、Tableau Desktop、Prep Builder、BridgeからのサインインではセキュリティキーとTouch ID・Windows Helloのような組み込みの認証が使えません。Salesforce Authenticatorか、Google AuthenticatorやMicrosoft AuthenticatorのようなTOTPのアプリを登録します。SSOでIdP側のMFAを使っている場合は、IdPの認証画面に従います。DesktopのFree EditionはCloudへのパブリッシュができないため、Creatorのライセンスが必要です。詳しくはTableau Desktopとは：Free Editionとの違い・インストール手順・データ接続の初期設定で扱っています。

Tableau Cloudから社内のExcelやCSVにつなげますか？

つなげます。共有フォルダなど社内ネットワークにあるファイルは、Tableau Bridgeを経由して抽出として取り込みます。Bridgeはファイルへの抽出には対応していますが、ファイルへのライブ接続には対応していません。Google ドライブ、OneDrive、Box、Dropboxなどに置いたファイルなら、Bridgeを使わずにCloudのコネクタで直接つなげます。

Tableau CloudでもPythonやRの連携は使えますか？

分析拡張機能としてのRとPythonの連携は、Cloudでも使えます。ただし、Bridgeは分析拡張機能に対応していないため、Bridge経由のデータソースとは組み合わせられません。Cloud上で作成またはパブリッシュしたPrepフローの中のRやPythonのスクリプト手順も非対応です。Serverでこれらを使っている場合は、外部のETLで加工を済ませてからCloudに渡す構成に組み替えます。Prepフローを定期実行する方法の選び方はTableau Prepとは：Prep Builderの使い方・フロー作成とConductor・コマンドラインでの定期実行で解説しています。

ServerとCloudを並行して使うことはできますか？

できます。どちらもロールベースのサブスクリプションで契約できるため、部署単位で順にCloudへ移し、移行が終わるまでServerを残すという段階的な進め方が可能です。並行期間中は、同じワークブックが両方で更新されないよう、移したプロジェクトをServer側で読み取り専用にしておくと混乱を防げます。

関連記事

お気に入りに入れた記事の一覧

この記事は以下の記事からリンクされています

この記事に関連するサービス

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.10.23　テックブログ Renta!不正アクセスでサービス停止：再開未定の現状と運営側の停止判断・証拠保全・段階的再開
  2. 2026.10.21　テックブログ ふるさとチョイス不正アクセスで445万件流出：対象確認・パスワード変更と再開時期
  3. 2026.10.24　テックブログ カプコン不正アクセス：CAPCOM ID 1,177万件漏えいと196件の乗っ取りへの対処
  4. 2026.10.24　テックブログ ブラストメール不正アクセス：配信先288件の漏えいと利用企業の報告・通知の手順
  5. 2026.10.14　テックブログ ローソンID不正アクセス：215万件漏えいの対象確認と本物メールの見分け方

RELATED POSTS 関連記事

一覧へ戻る

目次