Tableau MCPを組織展開する際の懸念について（主にVizQL Data Serviceに対して）
- 21 時間前
- 読了時間: 12分
公開日: 2026/06/21
最終更新: 2026/06/21この記事では、Tableau MCPやAI Agentにある程度向き合ってきたからこそ感じた、Tableau MCPを組織展開する際の懸念について書きます。
主には複数部署が同居するようなTableau Server環境を念頭に書きますが、懸念自体はTableau ServerとTableau Cloudの両方に、環境の規模感に関係なく当てはまるものだと思っています。
本記事の意図は、あくまでも「仕様を理解しない状態でTableau MCPを使うことにより、普及が止まることを防ぎたい」ことです。
推進したい立場の人間が懸念を書くのはTableau MCPに水を差すようで気が引けるのですが、いずれ皆が気づくであろう論点を、前倒しで一度言葉にしておきたいと思いました。
やや技術的な話も入りますが、ぜひ最後までお付き合いいただけますと幸いです。
前提など
この記事では、以下の機能について主に扱います。 記事中でも適宜補足をしますが、まずは以下の単語と概要をご認識ください。
VizQL Data Service (VDS):
ワークブックを介さず Published Data Source に直接クエリする機能。
ワークブック作成と異なり、Viewerも利用可能。
Tableau Serverではサーバー単位で有効化を一括設定する。
Tableau Cloudでは有効化されており、オフにする方法は無い。
Tableau MCP:
AIがVDSなどTableauの各種APIを叩く経路。
Viewerでも自然言語でTableauデータを使えるようになった。
今までのTableauの各種APIは、Python等での利用を念頭に、開発者ユーザーを想定していたと理解している。一方でTableau MCPはTableauの各種APIの民主化を達成した。
また、この記事では自分がTableau Serverユーザーのため、主にTableau Serverを念頭に執筆します。
ただし本記事で言及する懸念はTableau Cloudにも当てはまります。むしろTableau CloudではVDSの無効化が不可のため、お使いのTableau Cloudの運用方針によっては、懸念点が顕在化している可能性があります。
そして本記事では、Tableauのガバナンスモデルにおける「委任」と「セルフガバナンス」を採用している環境を想定します。
「一元化」モデルを採用している環境は、おそらく本記事の懸念点を払拭し、Tableau MCPを展開しやすいように思います。対策が必要な対象を絞りやすく、また対応をサーバー管理者主導で進めやすいと予想しています。
VizQL Data ServiceとTableau MCPは、Tableauの人間中心の世界観を変えた
Tableauは長い間「人間中心」のデータ利活用ツールでした。
CreatorやExplorerがワークブックでダッシュボードや可視化を組み、集計済み・フィルター済みのデータを人（多くはViewer）に届ける世界観でした。
どの列を見せるか、どうフィルターするかは、基本的にワークブック側で制御されていました。ここでのフィルターには、ディメンションやメジャーによる絞り込みだけでなく、閲覧者の属性に応じて変わるユーザー関数を用いた制御も含みます。
（例：人事情報ダッシュボード - 集計には使用するが表示しない列がある、表示データは閲覧者の所属部署にフィルターされる、など）
一方で、2025.1にてVizQL Data Service（VDS）という機能がリリースされました。端的に言えば「ダッシュボードを介さずに、その裏のデータソースへ直接問い合わせる」ための機能です。
これまでTableauは、ワークブックを通して、整えられたデータを人に届けてきました。VDSはその窓を経由せず、ワークブックの裏側にあるPublished Data Sourceに対して、プログラムやTableau MCPを使うAIから直接クエリを投げ、欲しい列・集計・フィルターを指定してデータを取り出します。
ここで少し立ち止まって、「Viewerは見るだけだから安全」というこれまでの安心の正体を確認しておきたいです。
そもそもViewerは、特定のデータソースに対してダウンロード権限を明示的に付与されても、そのデータソースをダウンロードできません。サイトロールが、ユーザーの持てる機能の上限を構造的に決めているからです。
サイト ロールによって、ユーザーがそのサイトで持つ最大の機能が決まります(たとえば、Viewer のサイト ロールを持つユーザーは、特定のデータ ソースをダウンロードする機能が明示的に付与されている場合でも、データ ソースをダウンロードすることはできません)。
出典: パーミッション、サイト ロール、ライセンス「Viewerにはワークブックという窓だけ」という運用は、この保証の上に成り立っていました。ところが、その明示的に付与しても使えない機能のリストに、VDSは入っていません。VDSはViewerユーザーも利用可能です。
このことは、設定値のページの記述とも整合します。
例えばTableau Server設定値のページには、以下の記述があります。
データ ソースのパーミッション ルール「API アクセス」の権限チェックを有効にします。...(中略)...すべてのサイト ロール (ライセンスなしのロールを除く) が VizQL データ サービス API にアクセスできるようになります。厳密に言えば、データソースにVDSを使用してクエリをするためには、実用上は「APIアクセス」パーミッションを、そのデータソースに対して設定する必要があります。
ただし構造上は、今までの「ワークブックでデータの表示制御をすれば良い」という世界観は、VDSが有効化されている環境では、2025.1以降では崩れています。
ワークブック側のフィルターや表示項目に関わらず、Viewerユーザーも集計前のデータが確認できる経路があります。
（Viewerユーザーが実際にVDSを利用できるパーミッション設定例）
これはVDSが紹介され始めた頃の公式製品ブログからの推測ですが、Tableauの各種APIがそうであったように、VDSはあくまでも技術者向けの機能として開発されていたと思います。ViewerがPATを発行し、個人的な目的のために直接VDS APIを使用してデータを取得しに行くようなユースケースは、この機能の開発時点では想定していたのでしょうか...?
また2025.1がリリースされた2025年2月時点では、AI Agentの話題は現在ほど本格化していないと記憶しています。MCPの議論が本格化し始めたのは2025年の初頭ごろのようです。ちなみにTableau MCPのリリースは2025年6月ですね。
VDSを開発者ユーザーがパーミッション設定などを十分意識した上で利用する分には、まったく問題なかったと思います。
2024年～2025年はHeadless BIの議論も熱かったように記憶しており、開発者やエンジニアを念頭に、Tableauデータソースを様々な方法でそのまま使える機能が開発されていたことは、むしろ素晴らしいことだったと思います。
一方で、現在はどうでしょうか？
Tableau MCPはVDSを民主化しました。ViewerユーザーはAIとTableau MCPを使って、VDSを好きなように利用できます。
そのTableau環境はTableau MCPを使う準備ができているか
「ワークブックでデータの表示制御をすれば良い」という前提はもはや正しくないので、Tableau MCPを展開するにあたっては、VDSを使っても問題ないTableau環境にしておく必要があります。
それではTableau MCPを展開して問題なさそうな状態とは、どのような状態でしょうか？VDSに絞ると以下が主要な観点かなと思います。
Tableau MCPなどを介してAIに使わせても良いデータソースに対してのみ、「APIアクセス」パーミッションを設定する。
AIやViewerに見せたくない列が上記データソースに含まれる場合には、APIアクセスを付与するデータソースと、そうでないデータソースに分離して、個別にパーミッションを設定する。
ワークブック側で実装しているフィルターをデータソース側に移行する。
特にユーザー情報を元に動作する行レベルフィルターなど。
パーミッションを付与するユーザーグループの棚卸を行う。
特にプロジェクトリーダーが付与されているユーザーグループに注意。
プロジェクトリーダーは全パーミッションを持つため、Viewerのプロジェクトリーダーは、意図せず「APIアクセス」パーミッションを持つ可能性があります。
端的に言えば、データソースのより厳格な管理と実装、パーミッション管理、場合によっては頻繁なユーザーグループ管理が求められると理解しています。
冒頭で言及した人事情報ダッシュボードで言えば、基本的にはダッシュボードでのデータ閲覧と展開を前提としつつ、その裏側のデータに対してVDSを使用されても安全なように：
表示させてはいけない列は事前に除外し、また行レベルセキュリティなどもデータソース側に移行する。
パーミッションルールを厳格にし、全ユーザーに対して「APIアクセス」パーミッションが付与されていないことを監視するようにする。
などの対応をすることが考えられます。
そうです。技術的には「APIアクセス」パーミッションの適切な設定や、データソースの正しい運用や実装によって、安心安全なVDS利用・Tableau MCP利用を実現できます。
移行工数や管理工数を積み、自信をもって運用できるのであれば、データソースへのフィルター移行や、データソースに含める列の棚卸、パーミッションの設定など、もちろん対応できる部分はあると思います。
その対応の中で、「APIアクセス」パーミッションの誤付与、パーミッションを付与するユーザーグループ中のメンバーの誤設定など、人的エラーを即座に検知し防ぐ仕組みが必要になるかもしれません。
一方で別のTableauユーザー組織では、厳格な運用は必要ないかもしれません。少数のチームでの利用に閉じていて、ガバナンスが必要ではないデータや運用で十分かもしれません。
ガバナンスとは別の観点で、この変化を全員が求めるかという問いがあります。
自分が挙げたTableau MCPの展開に対する懸念には、Tableauの権限モデルと機能の、それなりに深い理解が要ります。ただしTableauは、ローコードやノーコードで、主には可視化というワークブックの層を使い、多くの人を巻き込みながら広がってきました。
Tableau MCPを使い広める層に、これまでとは全く別の、パーミッションやデータソースに対する理解を求めている。
しかもTableau Serverの場合はVDSの有効化はサーバー単位での設定なので、そのTableau Serverの全ユーザーに波及する。一方で、Tableau MCPやVDSを使う準備ができているかどうかも、そもそも利用ニーズがあるかも、その環境の中でTableauを使っているユーザー組織間で、グラデーションがあるはずです。
このような前提において、Tableau MCPを一方的に展開することは、現実的で妥当でしょうか？
これが自分の一番の問いです。
Tableau MCPは素晴らしいですが、とりわけ中～大規模なTableau Serverユーザーにおいて、仕様上の問題でTableau MCPやAgentic Analyticsを押し付け、また既存の「ワークブックでデータの表示制御をすれば良かった」世界観からの移行を促すのは、現実的でしょうか？
もし実現できるとしても、時間がかかるのではないでしょうか？
ひとつのアイデアとして、サイト単位での有効化があると嬉しいのではないか
Tableau MCPを受け入れる準備にはグラデーションがあるはず。一方で、Tableau MCPのコア機能であるVDSの有効化の制御は、両極しかありません。
サーバー全体でオンにするか、資産ごとにパーミッションで絞るか。組織やドメインの単位、つまりサイト単位でのVDS制御という、中間が無いことを懸念しています。
一方でTableauの機能群は、サイト単位で設定できるものが数多く存在します。
Tableau Prep Conductor、Tableau Catalog、Tableau AIなど...機能を必要としないサイト／組織では、その機能を使わない／使わせないグラデーションが、他の機能では実現されています。
このアイデアがベストではなく、またVDSに限らず他のAPIについての同様の議論があって良いと思いますが...グラデーションを付ける方法の一つとして、VDSがサイト単位で有効化できれば、まだTableau MCPの展開も行いやすいように思いました。
Tableau MCPの準備ができているサイト／組織だけ、Tableau MCP含めたAI活用を実践できる状態が実現するためです。希望しないサイトはVDSを使えない状態にできます。
Tableau Serverにおいてサーバー全体に影響する設定をするためには、ある程度のユーザー合意が必要である場合が多いと思います。TableauがAgentic Analytics Platformへと変わっていくのであれば、Agentic Analyticsを実践したいユーザーが実際に実践できるようにするために、このようなグラデーションを認める機能もぜひ期待したいところです。
余談：Tableau MCPの「サイト設定」環境変数ができたが、これは本質的に問題を解決しない
ちなみに2026.2から、Tableau MCPに「サイト設定」環境変数が増えました。
この環境変数が設定されたTableau MCPの利用において、例えばあるサイトにつないでTableau MCPを使う際に、データソースにクエリするMCP Toolを使用できないように設定できます（EXCLUDE_TOOLSにquery-datasourceを指定しておく、など）。
ただし、これは自分の懸念を解決しません。理由は２つあります。
まず、ここで制御できるのはMCPの挙動であって、VDSの利用そのものではないことです。出すツールや結果の上限は絞れても、PATとパーミッションさえ持っていれば、MCPを介さずVDS APIを直接叩く経路はそのまま残ります。
次に、その設定を守るかどうかが、MCPプロセス側の環境変数（ENABLE_MCP_SITE_SETTINGS）次第ですよね。
これをオフにすると、ドキュメントにある通り「MCPサーバーはサイト設定の上書きを取得も適用もしない」です。そしてローカルにstdioでMCPを立てる構成では、その環境変数を握るのはMCP利用者本人です。
例えば「ローカル環境からのAPI接続をブロックする」等をしない限り（そもそもTableauの仕様として可能だったか？）、管理者のサイト設定は無視される場合が残ります。
ということで、この懸念を解決しそうな機能はTableau MCPには出ましたが、実際にはTableau MCPの話だけで解決できない経路が残り続けると理解しています。
最後に：Tableauユーザーの声を聞きたい、Tableauにそれぞれの声を届けてほしい
この記事の主旨は「VDSは危ない」「Tableau MCPは危ない」ということではありません。
むしろ逆で、VDSとTableau MCPが開くAgentic Analyticsの世界を本気で広げたいからこそ、性急な展開で事故が起きて普及が遅れてしまうのを避けたい意図でした。
サーバー単位での有効化／無効化の二者択一しか無いと、準備の整わないドメインを1つでも抱える組織は、安全側つまり「まるごと無効」に倒れやすくなると思います。そしてその分だけ、Tableau MCPの採用やAgentic Analyticsの実現が遅れることを懸念しています。
だからこそ、例えばサイト単位のVDS有効化は、このグラデーションを段階的な展開に変えるための、ひとつのアプローチだと思っています。
もしこの懸念に共感してもらえたら、担当のTableauの中の人に、ぜひ一度この話を挙げてみてください。「自分も気になっている」など、引用ポストなどで声や意見を聞いてみたいです。
これは多くのTableauユーザーが、Tableau MCPを実際に組織的に利用展開する際に当たりそうな壁だと思っていますが、この懸念が杞憂なのか、別の解決アプローチがありそうかなど、ぜひ意見をお聞きしたいです。
質問などありましたら、XかLinkedInまでお願いします。
最後までお付き合いをありがとうございました。