Tableauのダッシュボードを開くまで時間がかかる。フィルターを選ぶたびに待たされる。あるいは、編集時だけ動作が重い。こうした症状は、原因によって直す場所が違います。
まず「どの操作が遅いか」を一つ決め、その操作のパフォーマンスを記録してください。 接続に時間がかかるなら接続先、クエリが遅いならデータや計算、レイアウトが遅いならダッシュボードの表示内容を調べます。
この記事でわかること
- Tableauが重いときの最初の確認順
- よくある原因10個と、それぞれの改善方法
- 速度を上げる際に、数字やデータの鮮度を変えてしまわないための注意点
結論：遅い操作と場所を先に特定する
同じ「重い」でも、問題ごとに調査先が異なります。
| 問題 | まず確認する場所 | 次の一手 |
|---|---|---|
| 開くまでが遅い | 接続先、初期表示のシート数、クエリ | 遅いシートと処理を特定する |
| フィルター変更後が遅い | フィルターの数、適用先、クエリ | 対象シートとフィルターを絞って比べる |
| 特定のシートだけ遅い | マーク数、計算式、参照データ | そのシートを単独で開く |
| Desktopでは速いが公開先では遅い | 公開先の接続、ネットワーク、利用状況 | 同じ操作を同条件で比べる |
| 抽出の作成・更新が遅い | 取り込む行・列、元データの取得処理 | 取り込み対象と更新処理を確認する |
| 編集中だけ遅い | 編集ごとの再計算 | 編集中の自動更新を一時的に止める |
「以前より遅くなった」場合は、いつから、どのワークブックで、誰の操作で起きるかも控えてください。データ量の増加、接続先の変更、シートやフィルターの追加を調べる手がかりになります。
パフォーマンス記録でボトルネックを確認する
Tableau Desktopでは、対象のワークブックを開き、次の順に操作します。
- [ヘルプ] > [設定とパフォーマンス] > [パフォーマンスの記録の開始]を選ぶ。
- 遅い操作を一度だけ再現する。例：ダッシュボードを開く、地域フィルターを変更する。
- [ヘルプ] > [設定とパフォーマンス] > [パフォーマンスの記録の停止]を選ぶ。
- 開いた記録ワークブックの[Performance Summary (パフォーマンス サマリー)]で、時間の長いイベントと対象シートを見る。
記録に出る処理の意味は、おおむね次のとおりです。
| 時間が長いイベント | 疑う場所 |
|---|---|
| データ ソースへの接続 | ネットワーク、接続先、DBの応答 |
| クエリの実行 | データ量、DB側の処理、フィルター、結合 |
| クエリのコンパイル | シートの複雑さ、計算式、フィルター |
| レイアウトの計算 | 表示するシートや要素、レイアウト |
| 抽出の生成 | 取得する行・列、元データの取得速度 |
これは調査の入口です。例えば「クエリの実行」が長くても、DBだけが原因とは限りません。Tableau側のシートが必要以上に細かいデータを要求している可能性もあります。
Tableauが重い・遅い原因10選
原因1：ライブ接続先のクエリや接続が遅い
問題： シートを開くたび、またはフィルターを変えるたびに待たされる。
なぜ起きるか： ライブ接続では参照元に問い合わせます。元のDBの処理やネットワーク接続に時間がかかれば、Tableauの操作にも影響します。
確認方法： パフォーマンス記録で「データ ソースへの接続」「クエリの実行」を確認します。接続先のDBやビューに対しても、同じ条件の取得処理が遅くないか、管理担当者と確認します。
改善方法： 元のSQL・ビュー・テーブル設計、必要な行や列、DB側のインデックスなどを検討します。鮮度の要件が許すなら抽出も試します。ただし、抽出への変更には更新計画が必要です。
ライブ接続と抽出の判断を詳しく確認したい場合は、次の記事が役立ちます。
原因2：使わない行・列まで読み込んでいる
問題： 抽出の作成・更新や、明細を使うシートの表示が遅い。
なぜ起きるか： 分析に使わない期間や項目まで取り込むと、処理対象が増えます。
確認方法： 必要な対象期間、行の粒度、シートで使用する列を洗い出します。「将来使うかもしれない」という理由だけで含めた列がないかも見ます。
改善方法： 業務上必要な範囲を決め、抽出フィルターなどで対象行を絞ります。抽出を作成する前に不要なフィールドを非表示にする方法もあります。除外したデータが後で必要になる場合は、抽出を作り直す運用まで決めてください。
原因3：1画面にシートや情報を載せすぎている
問題： ダッシュボード全体の初期表示が遅いが、個々のシートは比較的速い。
なぜ起きるか： 複数のシートや大量の情報を一度に表示すると、それぞれの問い合わせと描画が必要になります。
確認方法： 各シートを単独で開き、ダッシュボード全体の表示時間と比べます。初期画面で本当に必要なグラフを確認します。
改善方法： 初期画面のシート数を減らし、詳細は別画面や操作後に表示します。
ダッシュボードの作り方から見直す場合は、基本手順も参照できます。
原因4：ビューのマーク数が多い
問題： 特定の散布図、地図、明細表などを開くと遅い。
なぜ起きるか： 細かい単位のデータを一度に表示すると、Tableauが処理・描画するマークが増えます。
確認方法： 対象シートに、注文IDのような細かいディメンションや、全期間の明細が置かれていないか確認します。
改善方法： 最初は月・地域などの集計結果を表示し、必要な場合に明細へ進める構成を検討します。詳細を省く前に、利用者がその画面で何を判断するかを確認してください。
原因5：フィルターが多い、または対象範囲が広い
問題： フィルターの候補表示や、選択後の再表示が遅い。
なぜ起きるか： フィルターごとの候補取得や、適用先シートの再計算が負担になる場合があります。
確認方法： 遅いフィルターを一つ特定し、そのフィルターの適用先と候補数を確認します。フィルター操作を記録し、どのシートで時間がかかるか見ます。
改善方法： 必要なフィルターに絞り、利用者の操作順に合わせて対象範囲を狭めます。速度改善だけを目的に、すべてをコンテキストフィルターに変更しないでください。
フィルターが「遅い」のではなく「想定したシートに効かない」場合は、適用先や操作順をこちらで確認してください。
原因6：計算フィールドやクエリが複雑
問題： ある計算を加えたシートだけ遅い。記録では「クエリのコンパイル」や「クエリの実行」が長い。
なぜ起きるか： 長い計算、入れ子になった計算、LOD計算などが、生成するクエリを複雑にする場合があります。
確認方法： シートを複製し、計算フィールドを一つずつ外して同じ操作を比べます。外したことで必要な数字まで変わるため、比較用の複製で行います。
改善方法： 同じ計算の繰り返しを整理し、データ側で事前に計算・集計できるか検討します。移す前後で、フィルター時の結果と集計値が同じか確認してください。
原因7：結合やデータ構造が分析に合っていない
問題： 複数テーブルを使うシートだけ遅い。加えて件数や合計も想定と違う。
なぜ起きるか： 必要以上のテーブルを結合したり、細かい粒度のデータを扱ったりすると、処理するデータやクエリが複雑になります。
確認方法： 対象シートが使うテーブル、結合キー、テーブルごとの粒度を確認します。元データ、結合後、集計後の件数をそれぞれ比べます。
改善方法： 必要なテーブルと列に絞り、分析に合う粒度を決めます。事前集計を使う場合は、明細を使う別の分析に影響しないか確認します。重複が起きている場合の具体的な調べ方は次の記事にまとめています。
原因8：カスタムSQLなどでデータ取得が重い
問題： 単純な表示でもクエリの実行に時間がかかり、取得元の処理が複雑。
なぜ起きるか： 複雑なカスタムSQLや取得元のビューが、毎回多くの処理をしている可能性があります。
確認方法： Tableauに渡しているSQLやビューの内容、取得する列と行、DB側での実行状況を確認します。
改善方法： DB担当者とともに、不要な取得処理の削減やデータモデルの見直しを検討します。カスタムSQLを使う必要がある場合もあるため、削除すること自体を目標にせず、遅い処理を測ってから変更します。
原因9：抽出の作成・更新で大量のデータを処理している
問題： 普段の閲覧はできるが、抽出の作成や更新が長い。
なぜ起きるか： 抽出に取り込む対象が広い、または元データの取得処理そのものが遅い可能性があります。
確認方法： 遅いのが「ダッシュボード表示」か「抽出更新」かを分けます。抽出に含める期間・列と、更新時の取得処理を確認します。
改善方法： 必要なデータ範囲を見直し、抽出に含める行・列を減らせるか検討します。更新方式を変える場合は、既存行の修正が反映されるかまで確認してください。
抽出を更新しても値が新しくならない場合は、速度とは別に更新経路を調べます。
原因10：公開環境やネットワークで時間がかかっている
問題： Tableau Desktopでは速いのに、Tableau ServerやTableau Cloudで閲覧すると遅い。あるいは、利用する時間帯で差がある。
なぜ起きるか： 公開先からデータソースへの接続、ネットワーク、サーバー上の処理や利用状況が関係する場合があります。
確認方法： 同じワークブック・同じ接続・同じフィルター条件で、Desktopと公開先を比べます。特定の時間帯や利用者だけで発生するかも記録します。
改善方法： ワークブック側の重い処理を先に特定し、公開環境だけに現れる差は管理者と調べます。「公開先で遅い」という事実だけで、サーバーの能力不足と判断しないことが大切です。
具体例：フィルターを変えると遅い場合の調べ方
例えば、売上ダッシュボードで「地域」を選ぶと表示に時間がかかるとします。
まずフィルター変更の操作だけをパフォーマンス記録に残し、時間が長いイベントとシートを見ます。
- 複数のシートでクエリ実行が長い： 地域フィルターの適用先と、各シートが取得するデータを確認する。
- 一つのシートだけ遅い： そのシートのマーク数、計算フィールド、使うテーブルを確認する。
- レイアウト計算が長い： 画面上のシートや表示要素を減らして比べる。
- 接続に時間がかかる： データソースへの接続と元DBの状況を確認する。
変更は一度に一つずつ行い、同じフィルター条件で所要時間と売上合計を比較します。これなら、何が改善に効いたのかと、数字が変わっていないかを判断できます。
初学者が詰まりやすい3つのポイント
1．「抽出にすれば解決する」と考える
原因： ライブ接続時のクエリ実行だけを見ている。
なぜ起きるか： 抽出で閲覧が速くなる場合はありますが、抽出の作成・更新や、複雑なシートの表示は別の処理です。
対策： 遅い操作を記録し、抽出を試すなら更新に要する時間と必要なデータの鮮度も確認します。
2．フィルターを追加すれば軽くなると思う
原因： 表示する行を減らせば、すべての処理が減ると考える。
なぜ起きるか： フィルターの候補取得や、複数シートへの適用自体が負担になることがあります。
対策： 遅いフィルターと適用先を確認し、追加前後を同じ条件で測ります。
3．見た目がシンプルなら軽いと思う
原因： 画面に見えるグラフの数だけで判断する。
なぜ起きるか： 一つのシートでも、細かいマーク、複雑な計算、重いデータ取得を含む場合があります。
対策： シート単位で記録を見て、クエリと描画のどちらに時間がかかるかを調べます。
改善時に数字を変えないための注意点
速度が改善しても、必要なデータが消えていたり、集計の意味が変わっていたりすれば、業務では使えません。
注意点1：抽出フィルターで対象期間を狭めると、過去比較ができなくなる場合があります。 利用者が必要とする比較期間を確認してから対象を決めてください。
注意点2：事前集計すると、明細単位でしかできない分析が使えなくなる場合があります。 たとえば月別売上を事前集計したデータだけでは、個々の注文を調べる用途に応えられません。
また、結合方法やフィルターの適用先を変更した後は、代表的な月・地域について元データとの件数と合計を照合します。速度の調査中に数字まで合わなくなった場合は、こちらの切り分け手順も参照してください。
それでも改善しない場合に見ること
一つずつ変更しても原因が見えない場合は、次の情報をそろえて管理者やデータ担当者と確認します。
- 遅いワークブックとシート
- 遅くなる操作とフィルター条件
- 発生し始めた時期
- Desktopと公開先のどちらで起きるか
- パフォーマンス記録で時間が長いイベント
- データソースや公開設定の直近の変更
複数のワークブックで同時に遅くなったなら、個別のシート設計に加え、共通のデータソースや公開環境も調査対象になります。反対に一つのシートだけなら、そのシートのデータ取得と表示内容から調べると範囲を絞れます。
まとめ
Tableauが重いときは、遅い操作を一つ再現し、パフォーマンス記録で時間のかかる処理を確認するところから始めます。接続、クエリ、抽出、レイアウトのどこで待っているか分かれば、調べる相手と修正箇所を決めやすくなります。
改善後は同じ条件で時間を測り、集計値とデータの鮮度も確認してください。速度と正しさを両方満たす形で運用することが大切です。
次に読む記事
ライブ接続と抽出の違いを確認する
フィルターが想定どおりに動かない場合を調べる
JOIN・リレーションシップと重複を確認する
データ更新が反映されない原因を調べる
改善後に数字が合わなくなった場合を調べる
