@HideakiYamamoto-Chasoso(Hideaki Yamamoto)

【Tableau】ダッシュボード拡張機能でTableau MCPを使った生成AIエージェントを作成してみた

Posted at 2026-06-23

注意
この記事は2026年6月中旬時点の実装内容です。
当時は公式のTableau MCPリモートサーバーが未公開だったため、リモートMCPサーバーではなく、stdio接続でTableau MCPを利用しています。

Tableau MCPやOAuth対応の状況は今後変わる可能性があります。
本番運用では、公開時点の公式ドキュメントを確認し、リモートMCPサーバーやOAuthを含む推奨構成を検討してください。

1.はじめに

この記事は、Tableau MCPそのものの入門というより、Tableau MCPをTableauダッシュボード拡張機能や外部APIと組み合わせて、実際の業務フローに近いPoCへ組み込んでみた記録です。
なお、今回の実装はCodexを活用しながら進めました。自分で全コードを手書きしたというより、要件や修正方針を整理し、Codexに実装を依頼しながら作成しています。
Tableau MCPを試してみたい方、Tableauダッシュボード拡張機能でAI UIを作ってみたい方、MCPとAPIの使い分けに悩んでいる方の参考になれば幸いです。

背景

先日実施された第8回北陸Tableauユーザー会で、Tableau MCPに関するセッションを実施しました。
セッションの中でTableau MCPを使ったデモをするにあたり、ClaudeアプリでのデモやWebアプリではなく、Tableauのダッシュボード拡張機能として実装しました。

Agentforce World Tour Tokyoで感じたこと

Salesforceが開催するAgentforce World Tour Tokyoでは、Salesforceが目指すエージェント時代の分析体験を垣間見ることができました。

Tableauは、従来の可視化・ダッシュボードに加えて、信頼できるデータ基盤やAIエージェントから利用される分析基盤としての役割も強めていくように感じました。その中で、生成AIがTableau上の信頼できるデータにアクセスする手段として、Tableau MCPは、AIアプリケーションからTableauの情報や機能を扱うための重要な接続手段になりそうだと感じました。

それを踏まえて、「私がTableau MCPを扱うとしたら…？」と考えて、Tableau MCP、Tableau Extensions API、外部サービスAPIを組み合わせて、アプリを実装しました。

2.この記事で扱うこと・扱わないこと

この記事は、「Tableau MCPを試してみたいが、Claude Desktopでつなぐだけではなく、実際のアプリや業務フローにどう組み込むのかイメージしたい人」あたりを想定読者としています。

扱うこと

Tableauダッシュボード拡張機能として生成AIエージェントを作成した全体像
Tableau Extensions API、Tableau MCP、外部APIの役割分担
Tableau Extensions APIで取得したダッシュボード文脈の概要
Tableau MCPを利用したTableau情報取得・分析文脈取得の概要
Slack、Bluesky、Google CalendarなどをAPIで実装した理由
自由チャット型ではなく、ワークフロー型にした理由
MCPとAPIを実装上どう使い分けたか
実装時に苦労した点と、そこから得た学び
Codexを活用してPoC実装を進めた方法と、そこで得た学び
PoCとして作成して見えてきた本番運用上の課題

扱わないこと

Tableauダッシュボード拡張機能の作成手順の詳細
Tableau Extensions APIの各メソッドの詳細解説
Tableau MCPのセットアップ手順や仕様の詳細
Slack API / Bluesky API / Google Calendar APIの実装手順
AWS環境の構築・デプロイ手順の詳細
Cognito、OAuth、Tableau Connected Appsを含む認証・認可設計の完全解説
Bedrockのモデル比較、プロンプト設計、生成品質改善の詳細
Codexの基本的な使い方や具体的なプロンプト全文
本番運用に必要な監査ログ、権限管理、セキュリティ設計の完全な実装方法

3.作成したもの

今回のイベントのデモでは主に、自由に質問できるAIチャット拡張機能と、イベント広報用に処理を固定したAI PRエージェントの2つを紹介しました。
前者でTableau上のAI対話を試し、後者でMCPや外部APIを組み合わせたワークフロー型のAIエージェントを試しました。

1. AIチャット拡張機能

Tableauのダッシュボード上にチャットUIを表示する拡張機能です。
現在表示しているダッシュボードについて質問できます。
取得したダッシュボードの文脈をバックエンドに送信して、バックエンド側で生成AIやTableau MCPを使って回答する構成です。

AIチャット拡張機能の動作イメージ

ユーザーがTableauダッシュボードを開く
ダッシュボード内の拡張機能にチャットUIが表示される
ユーザーが「このダッシュボードで使われているデータソースを説明して」などと質問する
Extensions APIで現在のダッシュボード文脈を取得する
質問と文脈をバックエンドに送信する
バックエンド側でBedrockとTableau MCPを使って回答を生成する
回答をチャットUIに表示する

2. AI PRエージェント

イベント広報向けの生成AIエージェントです。
会場写真、イベント情報、Tableau上のアンケート結果、過去投稿実績などを組み合わせて、SNS投稿文の候補を生成します。
最終的な投稿は人間が確認し、SlackやBlueskyへの投稿につなげる構成です。
自由に質問するチャット型というより、入力・分析・生成・確認・投稿の流れをある程度固定したワークフロー型に近いアプリです。

AI PRエージェントの動作イメージ

ユーザーがTableauダッシュボード上のPRエージェントを開く
投稿種別を選択する
会場写真をアップロードする
Google Calendarから開催中のイベント情報を取得する
必要に応じてイベントページの情報を取得する
Tableau MCPでアンケート結果や過去投稿実績を取得する
画像・イベント情報・Tableau分析結果を組み合わせて投稿文候補を生成する
ユーザーが投稿文を確認する
SlackやBlueskyに投稿する

種類	内容	取得元
投稿種別	実況、お礼、次回案内など	ユーザー入力
会場写真	イベント会場の写真	ユーザーアップロード
イベント情報	タイトル、日時、概要など	Google Calendar / イベントページ
アンケート結果	参加者の反応や関心	Tableau MCP
過去投稿実績	過去のSNS投稿の傾向	Tableau MCP
投稿文候補	SNS投稿文案	Bedrock
投稿先	Slack / Bluesky	Webhook / API

3. 2つのアプリの位置づけ

AIチャット拡張機能
- Tableau上でAIと対話する基本形
- Tableau Extensions APIとTableau MCPを組み合わせる最初のPoC
AI PRエージェント
- チャット型PoCを発展させた応用例
- 業務フローに近づけるため、入力・分析・生成・確認・投稿の流れを固定
- MCPだけでなく、Google Calendar、Slack、BlueskyなどのAPIも併用

4. 今回の生成AIエージェントの考え方

今回作成したアプリは、完全自律型のエージェントではありません。
基本的には人間が操作し、必要な場面で生成AIが補助していく形です。具体的には、情報収集や文脈整理、レスポンス文作成などに生成AIを活用しています。
完全自律型エージェントではなく、ワークフロー型の生成AIエージェント、あるいはCopilotに近いものとして作成しました。
完全に自動で外部サービスに投稿させることもできましたが、あくまで人間の承認フェーズを重視して、確認画面を毎回出すようにしています。

5. なぜTableauダッシュボード拡張機能にしたのか

Salesforceは今、Tableauをエージェント型分析プラットフォームと再定義しています。
生成AIやAIエージェントが、分析・意思決定・アクションに関わる流れが強くなっています。
これは、Tableauは分析のためのデータ基盤として存在しているという側面を強く感じさせます。

DataFam Tokyoの基調講演「データ × AIが描く分析の新境地〜エージェント型データ分析が切り拓く意思決定の未来〜」（Salesforce+）より

ただ、エージェント型分析が進んでも、ダッシュボードの役割自体は残ると思います。
"繰り返し見られる" かつ "説明的に共有する" ものは、ダッシュボードに向いています。

Tableau Conference「Dashboards, Metrics or Agents: Choosing the Right Experience」（Salesforce+）より

Tableau Agentの会話型分析機能（2026年7月ベータ版リリース予定）のように、ダッシュボードと会話型分析を組み合わせる方向も出てきています。
つまり、「ダッシュボード vs エージェント」ではなく、「ダッシュボード + エージェント」という見方になります。

DataFam Tokyo「AIエージェントで信頼できる分析を ― エージェント型分析を成功に導く方法」（Salesforce+）より

業務用AIエージェントを作る場合、独自Webアプリとして作ることもできます。
しかし、ユーザーが別URLに移動して…となると、今見ているTableauの文脈が切れることになります。
つまり、SaaSごとの画面を増やすより、既存業務ツールの中にAI体験を入れることの方が自然となることもあります。Tableauユーザーにとっては、Tableauの画面内でAI支援を受けられる方が導線を短くできます。
これは、AIエージェント用の専用UIを作るより、既存の業務画面にエージェント体験を埋め込む発想です。

また、Tableau MCPは、外部のAIエージェントからTableauの分析文脈へアクセスする用途で紹介されることが多いです。確かに、Tableau MCPを使う上でHeadlessに分析する方向性は自然です。
一方で、今回はTableauユーザーが見ているダッシュボードの中でAIを使う体験を試したかったです。
そのため、今回のAIエージェントのUIはTableauのダッシュボード拡張機能として配置しました。
裏側では、バックエンド経由でTableau MCPやAPIを呼ぶ構成にしています。これにより、Tableauの画面内にAIの操作面を置けます。

6. 全体構成

作成したどちらのアプリも、連携している外部サービスは異なりますが、構成はほぼ共通です。
Tableau Cloudについては、開発者用のサンドボックス環境を使用しています。
ダッシュボード拡張機能については、基本的にはAWSを使って構築しています。

Tableau MCPについては、バックエンド側でstdio起動し、Tableau Connected App + Direct Trust JWTを使ってTableauにアクセスしています。PoCでは、Cognitoで認証されたユーザーのEmailをTableau側のsubjectとして扱う簡易構成にしました。

Notion接続についてはリモートMCPサーバーを使っていますが、それ以外のSlackやGoogleカレンダーとの連携ではAPIを利用しています。こちらの判断理由は後述します。

たとえば、AI PRエージェントで投稿文を生成する場合は、ざっくり次のように動きます。

フロントエンドで投稿種別や画像を受け取る
Extensions APIで現在のTableau文脈を取得する
バックエンドにリクエストを送る
バックエンドがGoogle CalendarやTableau MCPから追加情報を取得する
Bedrockで投稿文候補を生成する
結果をフロントエンドに返す
ユーザーが確認してSlack / Blueskyに投稿する

コストを抑えたPoC構成

今回はイベントデモ用のPoCだったため、できるだけ最小構成で作ることを意識しました。

生成AIモデルについても、まずはコストを抑えて試せる構成にしたかったため、Amazon BedrockではNova 2 Liteを利用しました。
もちろん、より高性能なモデルを使えば、ツール選択や文章生成の品質が改善する可能性はあります。
ただ、今回は本番品質のAIエージェントを作るというより、Tableauダッシュボード拡張機能、Tableau MCP、外部APIを組み合わせたデモを成立させることを優先しました。

そのため、構成としても最初から理想形を目指すのではなく、デモに必要な機能に絞って実装しています。

7. Tableau Extensions APIで取得した文脈

Tableau Extensions APIでは、現在開いているダッシュボードの情報などをWebアプリから取得するために使用しています。
生成AIそのものを動かすため、という訳ではなく、「ユーザーが今何を見ているか」という情報をフロントエンド側で取得するために使っています。
これによって、単なる汎用チャットではなく、現在のTableau画面に基づくAI体験ができるようになっています。

Extensions APIでもワークシートやフィルター、選択状態などの情報は取得できますが、今回の用途では、より広いTableau Cloud上の情報や、LLMが必要に応じて探索する情報取得まではExtensions APIだけで完結させませんでした。
これらについては、取得したダッシュボード情報等をバックエンド側に渡し、必要に応じてTableau MCPを使ってTableau側の情報や分析文脈を取得しています。

8. Tableau MCPを使った部分

Tableau MCPについては、LLMがTableauに関する情報取得をツールとして扱うために使用しています。
本番運用を考えると、リモートMCPサーバーやOAuthを含む公式推奨構成を検討したいところですが、当時は公式リモートMCPサーバーが未公開だったため、今回はstdio接続で利用しました。

認証についてはTableau Connected App + Direct Trust用JWTでの連携としています。
MCPサーバー自体へOAuthログインをするのではなく、LambdaがTableau用のJWTを作って、MCP連携に渡す形です。

今回のPoCでは、Cognitoで認証されたユーザーのEmailをTableau側のsubjectとして扱う簡易構成にしました。そのため、Cognito側のEmailとTableau Cloud側のユーザーEmailが対応していることを前提にしています。
この構成では、Tableau MCPはフロントエンドから直接MCPに接続するのではなく、バックエンドを経由してTableauに接続する構成を取っています。

9. チャット型からワークフロー型へ

最初に作成したAIチャット拡張機能は、Tableauダッシュボード上で自由に質問できるAIチャットとしました。
これはこれで、Tableau上で生成AIとやりとりする体験を確認するには適切だったと思います。

MCPの価値は、単に外部サービスへ接続すること自体ではなく、LLMが状況に応じてツールを選び、必要な情報を取得できる点にあると感じました。複数サービスを跨ぐワークフローにすると、その価値や課題がより見えやすくなります。
そのため、1つのサービスのみとやりとりするようなチャット形式ではなく、複数サービスと連携しながら分析するワークフローに近いアプリも作成することにしました。特に、デモではある程度やることを固定した方がやりやすい、ということもありました。

この自由チャット型とワークフロー型の両方を作ってみたことで、MCPとAPIの使い分けも見えやすくなってきました。

10. APIで実装した部分

当初はすべての外部サービス接続をMCPサーバー経由で実施しようと思いましたが、設計や時間の問題ですべてをMCPで実装したわけではありません。

具体的には、

Googleカレンダーからのイベント取得
Bluesky投稿
Slack投稿（正確にはIncoming Webhook経由）

はMCPを経由せずアクセスしています。
Incoming Webhookは、SlackのWebhook URLにHTTP POSTするAPI的な外部連携として扱っています。

これらの外部サービス連携は、

処理内容が明確に決まっている
実行順序をアプリ側で制御したい
副作用のある操作をLLMに自由に任せたくない
既存APIで十分シンプルに実装できる

という側面がありました。
そのため、すべてMCP化するよりも、API制御にすることで十分確実な処理を実装することができました。

11. MCPとAPIの使い分け

ここは個人的な感触です。
いくつかサービス連携を試した中で感じたことです。

MCPが向いていると感じた場面

LLMにツール選択を任せたい
ユーザーの質問に応じて必要な情報が変わる
探索的に情報を取得したい
どの情報を見るべきかをLLMに判断させたい
チャット型・探索型の体験にしたい

APIやアプリ側制御が向いていると感じた場面

やることが決まっている
実行順序を固定したい
投稿・保存・更新など副作用がある
人間の確認や承認を挟みたい
既存APIで十分に実装できる

MCPはAPIの完全な代替ではないのだと思います。
LLMに自由に判断させたい部分ではMCP実装が効果を発揮しやすいと感じましたし、やることを固定したい場合は、API実装の方が楽です。
（まだMCPサーバーは発展途上のため、整備が追い付いていない面も…）

実際のAIエージェント開発でも、こういったMCPとAPIを合わせた制御は必要になるのかなあ、と思っています。

12. Codexを使って実装したこと

今回の実装は、Codexをかなり活用しました。
自分で全てのコードを手書きしたというより、要件整理、設計判断、動作確認、ログ確認、修正方針の作成を自分で行い、実装作業をCodexに依頼する形です。

特に役立ったのは、React UI、バックエンドAPI、Tableau Extensions APIまわり、MCP連携、ログ追加、テスト追加などです。特に、ログやスクリーンショットを渡しながら原因調査や修正方針を考えさせる使い方は有効でした。

一方で、UIや認証のように正解が一つではない部分は、人間側がかなり具体的に期待値を決める必要がありました。
曖昧な指示では意図しない実装になりやすく、UIやワークフロー、表示する情報量はかなり細かく指示しました。
AIエージェントを作る開発でも、最終的な体験設計や要件の判断は人間側に残るんだろうなあと感じました。

13. 苦労したこと

AIチャット拡張機能は3週間、AI PRエージェントは1週間くらいで、デモを通せるレベルになりました。今回は、最初から本番構成を目指すのではなく、デモに必要な最小構成で成立させることを優先しています。（つまり、継続的に人に使ってもらう完成度というより、デモを通すためのPoCです。）
その中で色々と考えながら作った部分です。

MCPをつなぐだけではエージェントにならない

Tableau MCPについて体験するのであれば、ClaudeやCodexを使って直接MCPを経由してアクセスするのが近道です。ただ、「常に既成の生成AIアプリからアクセスするのだろうか」という疑問もあり、自分で生成AIアプリを作成することにしました。
そこで立ちはだかったのは、思った結果が得られない、もっと自律的に分析してほしいのに途中で分析を終えてしまう、といったことでした。
自分でLLMを使ってアプリを作成する場合、AIエージェントをAIエージェントたらしめる自律的な実行部分をある程度作りこむ必要がありました。
この試行錯誤をしていると、やっぱりClaudeやCodexはとてもLLMのオーケストレーション能力に優れている、と実感しました。
（ただ、この辺は工夫次第で劇的に改善させることができるような気もしています）

ダッシュボード拡張機能の認証

ダッシュボード拡張機能側にも、認証設計が必要です。
ただ、Tableauのダッシュボード拡張機能はTableau内に埋め込まれるWebアプリで、通常のWebアプリ認証とは違い、iframe内で動くことを意識する必要があります。
そのため、ポップアップで認証を行い、その結果を元画面で受け取る、という方式をとる必要がありました。
当初、そのあたりの知識が無かったのでCodexと相談しながら実装したのですが、ここだけで1-2日使いました。

今回は、以下のようなフローでアプリの認証をしています。

UIが思い通りにならない

当初、UI自体はCodexに任せるのではなく、自分でイメージを作ってから作成を依頼しようとしていました。

ただ、上記のような画像をいくつか作成してUI修正を依頼しても、意図通りにならないことが多かったです。

特に、

画面に不要な情報を画面表示する
色やスタイルがうまく適用できない

あたりで苦労しています。
結局、一つひとつ指示を出して修正していきました。

Tableau接続の認証・認可設計

リモートMCPサーバーを経由したOAuth接続ができれば、ユーザーごとの認可をより自然に扱える可能性がありますが、今回はstdio接続ということもあり、Connected App + Direct Trustで実装しました。
今回は、CognitoのEmailをTableau側のsubjectとして扱い、Tableau Cloud側のユーザーEmailと対応していることを前提にした簡易構成で実装しました。

本番運用のことを考えると、課題があります。
本来は、Tableau側のOAuthフローを通して、ユーザー本人の認可を取得する構成にしたかったです。

MCPや生成AI以前に、認証認可設計がかなり重要となりそうです。

14. うまくいったこと

Tableauのダッシュボード上で、生成AIを動かす、というのは、体験として分かりやすかったと思います。
また、Extensions APIを使って現在のダッシュボード文脈を取得できる、という点も、普通のアプリでチャットとして実装するより、Tableauアプリらしくなった気がします。

また、完全自律型のエージェントにこだわらず、PRエージェントをワークフロー型に寄せたことで、デモストーリーを組み立てやすかった、というのもあります。
さらに、すべての外部サービスをMCP経由とせず一部API接続にしたことで、短期間でPoCを成立させられました。

以前、Codexでハッカソンのアプリケーションを作成したことがあったのですが、その時よりも短期間ででも可能な状態までもっていくことができました。

前回とは異なり、今回はMCPについて理解する、という目的もありました。
MCPでサービス連携を実装したことで、MCPとAPIの使い分けを具体的に理解できたと思います。

15. 本番運用に向けた課題

ただ、あくまで今回はデモとしては成り立ったというだけであって、本番運用するとなると検討すべき課題は多いです。

Tableau MCPとのリモート接続
Tableau側のOAuthとの連携
- 今後、Tableau MCPの公式リモートサーバーがリリースされたら、いろいろ試してみようと思います
アプリの認証とTableau認可の安全な対応付け
- Tableau Cloud側のユーザー権限を、AI経由の操作にも正しく反映できるかは、今後さらに検証が必要です
監査ログをどう取得・集計するか
LLMツール選択の安定化
- 今回は使用できるツールを限定することで、デモストーリーを一定にしようとしました
- 実運用では、ある程度自由に分析できる状態と安全な制御のバランスが必要になりそうです
モデル選定とコスト設計
- 今回はPoCとしてコストを抑えるため、BedrockではNova 2 Liteを利用しました
- 本番運用では、コスト、応答品質、ツール選択の安定性、レイテンシーのバランスを見ながらモデルを選ぶ必要があります
生成AIのレスポンスの品質評価
- 今回は十分な検証評価まではできていません
- 生成AIエージェントの評価・テスト方法も今後検討が必要です

16. まとめ

Tableauダッシュボード拡張機能やTableau×生成AIアプリケーションを初めて作ってみたのですが、今後来るであろうヘッドレス分析の導入部分を少しだけ学べたのかなあと感じています。
今回作ってみて、Tableauの文脈をAIに扱わせる部分ではMCPが有効で、やることが決まっている処理や副作用のある処理ではAPIやアプリ側制御が向いていると感じました。すべてをMCPにするのではなく、MCP・API・Extensions API・UI制御を組み合わせることが、現実的なAIエージェント開発では重要になりそうです。
もともとは”MCPとはそもそもどのように有効なのか”というのを知るために色々試していたのですが、なんだかんだ生成AIアプリでAPIを利用するシーンもまだ残るのだろうと思っています。
ただ、認証・認可・エージェンティックループ・エージェントの評価については、今後の課題かなと思います。

また、Extensions APIについても初めて触ってみましたが、現在表示させているダッシュボードの文脈を取得できる、というのはいろいろと応用できそうだな、と思っています。これからも、コーディングエージェントと二人三脚で色々試してみたいです。

【Tableau】ダッシュボード拡張機能でTableau MCPを使った生成AIエージェントを作成してみた

1.はじめに