2026.11.08 データベース

Tableau Serverとは：Linux・Windowsのインストール手順・TSMコマンド・ノード構成とサイジング【2026年11月】

Tableau Server（タブローサーバー）は、Tableau Desktopで作ったワークブックやデータソースを社内で共有するために、自社のサーバーへ入れて運用する製品です。同じ役割をSalesforceが運用するのがTableau Cloudで、Serverはハードウェアの用意からバージョンアップまでを自社で受け持ちます。この記事では、公式ヘルプをもとに、Linuxでのインストールとinitialize-tsmによる初期化、Windowsでのセットアップ、TSMでのバックアップ、3ノードの高可用性構成までのサイジング、Desktopとの版の互換性をコマンド付きで整理します。

まとめ：Tableau Serverの構築で先に決める要件・初期化の設定・ノード数

まずCloudで足りないかを確かめます。公式のインストール要件のページ自身が、ほとんどの組織にはCloudが信頼性とコストで有利だと書いています。Serverを選ぶのは、Kerberos認証や社内閉域での運用など、Cloudが対応しない要件があるときです。

構築すると決めたら、順番は「要件の確認、初期化、ノード構成」です。単一ノードの本番環境は8コア・RAM 128GBが出発点になります。initialize-tsmは1回しか実行できず、データディレクトリの場所やFIPSモードは後から変えられません。止められない業務で使うなら、最初から3ノードで設計します。2ノードでは高可用性の要件を満たさないからです。

Desktopは、Serverと同じか古い版にそろえて配ります。

Tableau Serverの役割とCloudとの違い：構築前に確かめる要件と対応OS

Serverは、作ったコンテンツを置いて閲覧・更新させる「置き場所」の製品です。Cloudとの運用責任の違いや、Cloudで使えない機能の一覧はTableau Cloudとは：Serverとの違い・SSOとBridgeの設定・Serverからの移行手順で比べています。ここではServerを入れるマシンの条件に絞ります。

単一ノードの最小要件：8コア・RAM 128GB・x86_64限定の根拠

Linux版のインストールの前にでは、本番用の単一ノードの最小推奨を次のように示しています。

項目	単一ノードの最小推奨	補足
プロセッサー	64ビット（x86_64）	SSE4.2とPOPCNTが必要。ARMは非対応
CPU	8コア（16vCPU）、2.0GHz以上	コア数は物理コアで数える
RAM	128GB（2022.3以降）	2021.4〜2022.1は64GB
空きディスク	50GB	/optに15GB以上、残りを/varへ
スワップ	RAMの平方根か8GBの大きい方	128GBなら約11.3GB

AWSやGoogle Cloudでは、vCPUは物理コアでなくハイパースレッドを指すことが多い点に注意します。公式は「2 vCPU＝1物理コア」として数えるよう書いており、単一ノードの推奨は16vCPUです。16vCPUに対してメモリ128GBという比率なので、汎用型よりメモリを多く積むインスタンス型が候補になります。

対応OSの変化：2025.1.0でCentOS 7・Amazon Linux 2が対象外

同じページのOS要件表は、2026年11月時点で2026.2.x の列まで載っています。Linuxで並ぶのは、RHEL・AlmaLinux・Rocky Linux・Oracle Linuxの8〜10系、Amazon Linux 2023、Ubuntu 20.04〜24.04 LTSなどです。版ごとに対応範囲が違うので、入れる版の列で確かめます。

既存環境で引っかかるのは、2025.1.0での打ち切りです。CentOS 7、RHEL 7、Oracle Linux 7、Ubuntu 16.04と18.04、Amazon Linux 2は、2025.1.0以降のServerに対応しません。古いOSのままServerだけを上げる計画は成り立たず、OSの入れ替えを含めて見積もります。

Windows版のインストールの前にで2023.3.1〜2026.2.xの対応OSとして並ぶのは、Windows Server 2016・2019・2022の3つです。Windows Server 2025は表に載っていません。LinuxとWindowsのノードを1つのクラスターに混ぜることもできません。

ポートと固定IP・ホスト名の前提：8850・80・443・8000〜9000番

Serverを入れるマシンには、静的なIPv4かIPv6のアドレスが必要です。ホスト名にはアンダースコアを使えず、TSMを起動した後はホスト名を変えられません。cloud-initで仮想マシンを立てる構成では、ホスト名が起動のたびに変わらないよう固定しておきます。

既定のポートは、TSMが8850、ゲートウェイが80、SSLが443です。複数ノードでは、PostgreSQLの8060と8061、動的割り当て用の8000〜9000、ライセンスサービスの27000〜27009も開けます。8850番はインターネットに公開しないよう公式が明記しています。

Linuxへのインストール手順：パッケージ導入からinitialize-tsmまで

Linux版は、ディストリビューションのパッケージマネージャーで本体を入れ、同梱のスクリプトでTSMを初期化する流れです。作業はsudoが使えるユーザーで行い、このユーザーにはパスワードでログインできる設定が必要です。

RHEL系とUbuntuでのパッケージ導入とTSM初期化のコマンド例

TSM のインストールと初期化に沿ったコマンドです。パッケージ名の版は「メジャー-マイナー-メンテナンス」の形で、例は公式に載っている2025-3-5を使っています。

# RHEL・Rocky Linux・Amazon Linux 2023 など（yum が依存パッケージも入れる）
sudo yum update
sudo yum install tableau-server-2025-3-5.x86_64.rpm

# Ubuntu の場合
sudo apt-get update
sudo apt-get -y install gdebi-core
sudo gdebi -n tableau-server-2025-3-5_amd64.deb

# TSM の初期化（scripts.<version_code> は導入した版のディレクトリ名に置き換える）
cd /opt/tableau/tableau_server/packages/scripts.<version_code>/
sudo ./initialize-tsm --accepteula -d /data/tableau_data
exit   # グループ所属を反映させるため、一度ログアウトしてから入り直す

既定のインストール先は/opt/tableau/tableau_server、データディレクトリは/var/opt/tableau/tableau_serverです。-dでデータディレクトリを別ディスクにする場合、ディレクトリは自分で作らずスクリプトに作らせます。パスにピリオドや空白があると初期化に失敗します。シンボリックリンクとNFSのボリュームも使えません。

initialize-tsmで変更不可の設定：データの保存先・FIPS・実行ユーザー

initialize-tsmは1回しか実行できません。公式が「初期化の際にのみ」変更できると書いている設定は、次の4つです。

データディレクトリの場所（-d）。以後のアップグレードを含め、展開の寿命まで変えられない
既定以外のシステムユーザーとグループ（--unprivileged-userなど）
FIPSモード（--enable-fips）。2025.3.1で追加され、有効にすると戻せない
ATR（実行承認）サービスによるライセンス認証。2021.4以降は既定で、選ぶと取り消せない

フォワードプロキシ（--http_proxy）も、後から設定するより初期化時に渡すほうが手間は少なく済みます。データディレクトリは最初から大きいディスクに置きます。抽出の更新中は、完成した抽出の最大3倍の一時領域を使うからです。

ライセンス認証・IDストア設定からtsm initializeまでの流れ

初期化の後は、ライセンス認証、登録、IDストアの設定、変更の適用、起動の順に進めます。インストールのジャンプスタートの手順をまとめると次のとおりです。

# ライセンス認証と登録（登録ファイルはテンプレートを出して編集する）
tsm licenses activate -k <プロダクトキー>
tsm register --template > /home/tsmadmin/registration.json
tsm register --file /home/tsmadmin/registration.json

# IDストアをローカル認証にする設定（identity.json）
{
  "configEntities": {
    "identityStore": {
      "_type": "identityStoreType",
      "type": "local"
    }
  }
}

tsm settings import -f /home/tsmadmin/identity.json
tsm pending-changes apply
tsm initialize --start-server --request-timeout 1800
tabcmd initialuser --server 'localhost:80' --username 'admin' --password '<強いパスワード>'

IDストアの種類は、ローカル認証かActive Directory・LDAPかの二択です。アイデンティティストアのヘルプは、一度設定するとサーバーを入れ直さない限り変えられないと書いています。社内のADで認証する予定が少しでもあるなら、最初からADでの構成が必要です。管理ビューを表示するには、PostgreSQLのJDBCドライバーを/opt/tableau/tableau_driver/jdbcに置いてtsm restartする作業も要ります。

Windows Serverへのインストール：セットアップ画面とTSM Web UIの操作

Windows版は、セットアップ画面とブラウザのTSM管理画面で進めます。

Windowsセットアップでの既定のインストール先とATRの選択画面

Windows版のジャンプスタートでは、インストーラーを実行し、既定のC:\Program Files\Tableau\Tableau Serverか別のドライブを選びます。データの既定の保存先はC:\ProgramData\Tableau\Tableau Serverです。別のドライブを選ぶと、データディレクトリも同じパスに作られます。

［サーバーインストールのタイプ］は、1台目なら「新しいインストールを作成」のままです。［プロダクトアクティベーションのタイプ］のATRは、Linuxと同じく選ぶと取り消せません。

TSM Web UIでのプロダクトキー有効化と不足ライセンスの警告

開いた管理画面の［ライセンス認証］でプロダクトキーを入れ、［登録］で組織情報を入力し、IDストアを選んで初期化します。コア数が足りないキーやViewerロールだけのキーでは「不十分なライセンスが適用されました」と出るため、［別のプロダクトキーのアクティブ化］でキーの追加が必要です。CreatorやViewerのロールごとの価格はTableauの価格｜Creator・Explorer・Viewerの料金と人数別の年額、CloudとServerの差で整理しています。

TSMコマンドで行う日常運用：設定の反映・バックアップ・ログの整理

Serverの設定変更、プロセス構成、バックアップは、すべてTSMで行います。

pending-changesで反映する仕組みと再起動が要る変更

tsm settings importやtsm topology set-processで行った変更は、tsm pending-changes listで一覧でき、tsm pending-changes applyで反映されます。再起動が要る変更なら、適用時に出るのは確認のメッセージです。ノードの役割やプロセス数の変更は多くの場合で再起動を伴うため、業務時間外に適用する運用にします。

2026.2で追加されたtsm maintenance log-levels resetは、上げたままのログレベルを一括で既定に戻します。

backupとsettings exportを組み合わせた復旧用バックアップ

バックアップと復元によると、完全な復旧には2種類のファイルが要ります。リポジトリとファイルストアを1つにまとめた.tsbakと、構成・トポロジを書き出したJSONです。tsm maintenanceのオプションを使った例を示します。

# 構成とトポロジ（シークレットを含むので暗号化して保管する）
tsm settings export -f /backup/ts_settings.json

# リポジトリとファイルストア。-d で日付が付き ts_backup-yyyy-mm-dd.tsbak になる
tsm maintenance backup -f ts_backup -d

# 毎週土曜12時に取るスケジュールを登録する例
tsm maintenance backup -f ts_saturday_backup -sr weekly -st 12:00 -sd 6 -sn weekly-saturday-backup

# 2日より古いログを消す
tsm maintenance cleanup -l --log-files-retention 2

書き出し先の既定は/var/opt/tableau/tableau_server/data/tabsvc/files/backups/です。バックアップは、作成した版と同じか新しい版のServerにしか戻せません。IDストアの種類も一致している必要があり、ADで動いていたServerのバックアップは、ローカル認証で初期化したServerには戻せません。

復旧時に備えたバックアップ対象外の証明書・キータブ・グループの控え方

同じヘルプは、TSMのバックアップに含まれないものを挙げています。復旧の手順書には、次の項目を別に記録します。

tableau・tsmadminグループに入っているユーザー（grep tsmadmin /etc/groupで確認）
どのノードで調整サービスが動いているか（tsm topology list-nodes -v）
Kerberosのキータブ、LDAPの構成ファイル、相互SSLの証明書とキー
リポジトリへの直接接続を許可したアカウントのパスワード
サインイン画面のロゴなどのカスタマイズ用画像

外部SSLの証明書とtsm security custom-cert addで入れた証明書は、例外としてバックアップに入ります。

ノード構成とサイジング：単一ノード・2ノード・3ノードHAの選び方

推奨されるベースライン構成は、初めての構築の出発点として3つの型を示しています。

8コア機の単一ノードでVizQL Server 2・バックグラウンダー2の既定値

単一ノードでは、すべてのプロセスを1台に載せます。8コアのマシンなら、VizQL Serverは2インスタンス（物理コア数を4で割り、上限は4）、バックグラウンダー・キャッシュサーバー・データサーバーも2インスタンスが目安です。その他のプロセスは1つずつにします。

本番用ディスクは500GB〜1TBが推奨で、最小要件の50GBは動かすための下限にすぎません。公式は、最初の構築を単一ノードにして基幹業務以外の用途から始めるよう勧めています。

抽出の更新が多い組織の2ノード構成とバックグラウンダー数の計算式

データソースの大半が抽出で、営業時間中にも何度か更新するなら、2台目をバックグラウンダー専用にした2ノード構成から始めます。専用ノードのバックグラウンダー数は、物理コア数を4で割った数を下限、2で割った数を上限とします。8コア機なら2〜4です。

Prepのフローをサーバーで定期実行する場合は、2台目をフロー専用にします。役割の設定コマンドはtsm topology set-node-role -n node2 -r flowsです。Prep Conductorの専用ノードは4コア・RAM 16GB以上が条件で、フローの作り方はTableau Prepとは：Prep Builderの使い方・フロー作成とConductor・コマンドラインでの定期実行で扱っています。ただし、どちらの2ノード構成も高可用性の要件は満たしません。

3ノードHAに必要な調整サービス・ファイルストア・リポジトリの冗長化

3 ノード HA クラスタの例が挙げる条件は、3台以上のノード、3台での調整サービス、クライアントファイルサービス（CFS）、2つ目のファイルストアとリポジトリ（pgsql）です。追加ノードは、1台目で作ったbootstrapファイルを使って参加させます。

# 1台目：bootstrap ファイルを作る（埋め込みの認証情報は既定で120分有効）
tsm topology nodes get-bootstrap-file --file /tmp/bootstrap.json

# 2台目・3台目：1台目と同じ版のパッケージを入れてから参加させる
sudo ./initialize-tsm -b /tmp/bootstrap.json --accepteula

# 1台目：ノードIDを確認し、調整サービスを3台に展開する
tsm topology list-nodes -v
tsm stop
tsm topology deploy-coordination-service -n node1,node2,node3
tsm start

# 2台目にCFS・ファイルストア・2つ目のリポジトリなどを載せる
tsm topology set-process -n node2 -pr clientfileservice -c 1
tsm topology set-process -n node2 -pr filestore -c 1
tsm topology set-process -n node2 -pr pgsql -c 1
tsm topology set-process -n node2 -pr backgrounder -c 2
tsm pending-changes apply

tsm topologyのリファレンスでは、bootstrapファイルに構成シークレットを暗号化するマスターキーストアの写しが入っていると説明しています。使い終えたら消します。set-processは1回に1ノード・1プロセスしか指定できません。仕上げに3台のゲートウェイの前へロードバランサーを置きます。

DesktopとServerのバージョン互換性：パブリッシュできる版の組み合わせ

互換性の問題は、2025.3と2026.2のようなアップグレードリリースの間で起き、同じ系列のメンテナンスリリース間では通常起きません。

Serverが同じか新しい版のときだけパブリッシュできる規則

互換性の問題の検出と解決の規則は次のとおりです。

操作	可否の条件
DesktopからServerへパブリッシュ	ServerがDesktopと同版以上の場合のみ
新しいDesktopから古いServerへ	公開時にワークブックの版を下げれば可
古いDesktopで新しい版のワークブックを開く	不可（エクスポートで版を下げて渡す）
新Serverデータソースを旧Desktopで使う	可（古い版にない機能のフィールドは使えない）

見落としやすいのは、新しいDesktopで編集して再パブリッシュすると、ワークブックが新しい版に上がる挙動です。古いDesktopの利用者は、そのワークブックを開けなくなります。Desktopの導入手順はTableau Desktopとは：Free Editionとの違い・インストール手順・データ接続の初期設定にまとめています。

サポート24か月とREST APIの版から立てるアップグレード計画

同じヘルプによると、Tableauは各版のリリースから24か月だけ技術サポートとダウンロードを提供します。2年以上上げずにいる環境は、サポート対象外の版で運用している状態です。古い抽出形式の.tdeは2024.3以降使えないため、放置した環境ほど作業が膨らみます。

自動化スクリプトを持っている場合は、REST APIの版も確かめます。REST API and Resource Versionsでは、2026.2に対応する版は3.29、2025.3に対応する版は3.27です。Serverを上げる前に、スクリプトが指定しているAPIの版と認証方式を棚卸しします。

Tableau Serverを自社で構築する条件とCloudへ切り替える判断基準

判断の軸は「Cloudが対応しない要件があるか」と「サーバーを運用し続ける人手があるか」の2つです。

Serverを構築すべき組織：Kerberos・社内閉域・大規模利用が要件の場合

次のどれかに当てはまるなら、Serverを構築します。

社内データベースへの接続がKerberos認証に統一されている
データを社外のクラウドに置けない規程があり、閉じたネットワークで運用する
キューブ（多次元データベース）への接続が業務の中心にある
ピーク時のVizQLセッションが1時間あたり1,000を超える大規模利用（公式はこの規模ならLinux版を推奨）

その場合も、OSの入れ替えと復旧訓練を年間の運用計画に入れます。製品全体の選び方はTableau（タブロー）とは：製品の種類・データ接続・権限設計と自社開発との使い分けで整理しています。

Serverを見送る場面：専任の管理者がいない・PoC段階・2ノード止まり

専任の管理者を置けない組織は、Serverを選びません。OSの入れ替えを伴うアップグレードや障害時の復旧は、情シスの片手間では回りません。概念実証の段階も同じで、公式のベースライン構成のページはPoCにはCloudを使うよう勧めています。

可用性を求めながら予算が2ノード分しかない計画も、見送るべき場面です。2ノードでは単一障害点が残り、止まったときの復旧はバックアップからの手作業になります。Cloudなら、基盤の冗長化を担うのはSalesforce側であり、同社の責任範囲です。構築か移行かの判断から外部に任せたい場合、依頼できる範囲はTableauの導入支援｜依頼できる範囲と外注先の選び方、費用の決まり方で説明しています。現行の構成を棚卸しするところからなら、BIツール導入支援で相談できます。

よくある質問

Tableau Serverの構築と運用でよく出る質問に答えます。

Tableau ServerはDockerなどのコンテナで動かせますか？

専用の「Tableau Server in a Container」の形なら動かせます。2021.2から、Linux版の特定の構成をコンテナで実行できるようになりました。普通のLinuxイメージにServerを入れてDocker上で動かす構成はテストされておらず、公式のサポート対象外です。

TSMの管理画面にはどのURLで入りますか？

既定では「https://ホスト名:8850」です。8850番がインストール時に使用中だと別の番号に割り当てられ、それを確認する画面がありません。インストール前に8850番を空け、社内か踏み台からだけ届くようにファイアウォールを設定します。

Tableau ServerはARMのサーバーやMacに入れられますか？

入れられません。対応するプロセッサーは64ビットのx86_64で、SSE4.2とPOPCNTの命令セットが必要です。ARMベースのプロセッサーは非対応と明記されており、AWSのGravitonのようなARMインスタンスも使えません。OSはLinuxとWindows Serverだけで、macOSには入りません。

2台構成にすれば高可用性になりますか？

なりません。公式のベースライン構成は、2ノード構成は高可用性の最小要件を満たさないと明記しています。リポジトリのアクティブとパッシブ、ファイルストアの冗長化、調整サービスの多数決を成り立たせるには、最低3台のノードが必要です。2台目の追加は、抽出の更新やフローの実行を分ける性能対策として考えます。

Windows版のTableau ServerからLinux版へ移行できますか？

移行できますが、通常のバックアップと復元だけでは済みません。Windows版で書き出した構成とトポロジのデータは、Linux版に復元できないと公式に書かれています。公式のWindowsからLinuxへの移行手順に沿い、構成は移行先での再設定が必要です。OSの混在したクラスターは組めないため、新しいLinux環境を別に立てて切り替えます。