【2026年8月時点】Tableau AIとは？Pulseで変わるKPI監視と導入条件

ダッシュボードは60本あるのに、見に来る人が増えない。この状態に心当たりはないでしょうか。Tableau AIとは、Tableauに組み込まれた生成AI機能の総称です。データを要約して届ける機能と、対話しながら分析を組み立てる機能が含まれます。Agentforceと同じくEinstein Trust Layerの上に構築されており、既定ではオフの状態で提供されます。

本記事では、化粧品を企画・製造する中堅メーカー（従業員380名・営業40名・経営企画部4名）を例に、Tableau AIで何が変わり、使い始めるまでに何を確認するのかを解説します。この企業は説明のための架空の設定であり、実在の企業ではありません。記載内容は2026年8月時点のものです。

この記事を書いた人

本田正憲

合同会社クロスコムの代表｜専門商社にて7年間のBtoB営業を経て、マーケティング業界に参入。現在はSalesforce公式コンサルティングパートナーとして、ソリューション営業の業務プロセスに特化したAgentforce導入・定着支援と、Agentic CRM設計支援を提供している。

Tableau AIが必要になる3つの状況

Tableau AIの検討が始まるきっかけは、新しい機能への興味ではありません。多くの場合、ダッシュボードを整えたのに使われないという、数年越しの課題が背景にあります。例に挙げた化粧品メーカーも、Tableauを4年使い、公開されているダッシュボードは60本ありました。それでも経営企画部への分析依頼は減っていません。依頼が減らないという事実は、ダッシュボードの本数と成果が比例しないことを示しています。ここでは、Tableau AIが必要になる3つの状況を確認していきます。

状況①ダッシュボードを見に行く人が少ない

1つ目は、作ったダッシュボードに人が来ないという状況です。

このメーカーでは、営業40名のうち、ダッシュボードを週1回以上開いている担当者は9名でした。残る31名は、月次の会議で共有される資料を見るだけで、自分から数字を確認する機会がありません。ダッシュボードが使いにくいわけではありません。開くきっかけが業務のなかに組み込まれていないという状態です。

見に行く行為には、思い出すという工程が要ります。担当している顧客の対応に追われていれば、その工程は後回しになります。60本という本数も、かえって障害になっていました。どれを見ればよいのかを選ぶ手間が加わるためです。

ダッシュボードの本数を増やす作業は、見に来る人を増やす作業とは別のものです。 前者を続けても、後者は解決しません。本数を増やしても、開く担当者の人数が連動して増えたことはありませんでした。増えたのは、どれが最新なのか分からないという声のほうです。

状況②数字の変化に気づくのが遅れる

2つ目は、数字が動いたことに気づくまでに時間がかかるという状況です。

このメーカーでは、特定の販路の受注が前月から落ちていたことに気づいたのが、月次の会議の場でした。落ち始めていたのは3週間ほど前です。データはその時点でTableauに入っており、ダッシュボードにも反映されていました。見る人がいなかったために、発見が会議まで遅れた形になります。

気づくのが遅れると、打てる手も限られます。3週間前であれば取引先へ確認する余地がありましたが、月次の会議の時点では次の月の受注にも影響が及んでいました。数字が見える状態にあることと、変化に気づける状態にあることは違います。

この差は、担当者の注意深さでは埋まりません。60本のダッシュボードすべてを毎日確認する運用は、現実的に成立しないためです。仕組みの側で拾わない限り、同じ遅れは繰り返されます。気づけなかった理由を担当者に尋ねても、見る時間がなかったという答えしか返ってきません。

状況③分析の依頼が特定の担当者に集まる

3つ目は、少し込み入った分析の依頼が、特定の担当者に集中するという状況です。

このメーカーでは、経営企画部4名に対して月およそ25件の依頼が届いていました。「この販路の伸びが鈍った理由を知りたい」「昨年の同じ時期と比べたい」といった内容です。依頼する側からすると、自分でTableauを操作するより頼んだほうが速いという判断になります。

依頼を受ける側の負担も問題ですが、より影響が大きいのは、依頼するほど確認できないことです。頼むまでもないと判断された疑問は、確認されないまま残ります。確認されなかった疑問の中に、後から効いてくるものが混じっている可能性は否定できません。

分析の依頼が集中している状態は、データを見る力が組織に広がっていないことの表れでもあります。依頼という形を取らなければ確認できない状態が、そもそもの制約になっています。

Tableau AIの検討が始まる背景にあるのは、ダッシュボードが足りない状態ではなく、作った数字に人が近づけていない状態です。

Tableau AIを構成する3つの機能

前章では、Tableau AIが必要になる3つの状況を挙げました。ここからは、その状況に対して何が用意されているのかを見ていきます。Tableau AIは単一の機能を指す名前ではありません。役割の違う複数の機能をまとめた呼び方です。公式ヘルプでは、Pulseによるインサイトの要約、Tableau Agentによる作成の支援、Tableau Catalogによる説明の自動生成などが列挙されています。それぞれ、届ける・作る・説明するという別の仕事を担います。名前を1つずつ覚えるより、どの仕事を担う機能なのかで整理したほうが、資料を読むときに迷いません。ここでは、主要な3つの機能を解説していきます。

機能①Tableau Pulseによる変化の要約

1つ目は、指定した数字の変化を検知し、自然言語で要約して届けるTableau Pulseです。

公式ヘルプでは「ユーザーはフォローしているメトリクスに関するパーソナライズされたデータのインサイトを受け取ることができます」と説明されています（2026年8月時点）。※参考記事はこちら

ここで重要なのは、フォローという言葉です。利用者が見に行く必要はありません。あらかじめ関心を登録しておいた数字について、変化があったときに届きます。状況①と状況②で挙げた問題に、直接対応する設計だといえます。

化粧品メーカーの60本のダッシュボードは、どれも見に行くことが前提の作りでした。Pulseは、その前提を変えます。届く仕組みに変えるという点が、既存のダッシュボードとの最も大きな違いです。60本のダッシュボードを整理しなくても、この仕組みは並行して動かせます。既存の資産をどうするかという判断を、後回しにできる点も実務では効いてきます。

機能②Tableau Agentによる対話分析

2つ目は、自然言語での指示にもとづいてVizや計算フィールドの作成を支援するTableau Agentです。

公式ヘルプによると、Tableau Agentはデータの探索、Vizの作成、計算フィールドの作成と説明、インサイトの発見を助けるAIアシスタントとして位置づけられています。Tableau Prepでのフロー作成の支援や、ダッシュボード解説（ベータ版）も同じ名前のもとにまとめられています。

この機能が効くのは、状況③で挙げた依頼の集中に対してです。自分で操作するより頼んだほうが速いという判断が生まれるのは、操作の習得に時間がかかるからです。自然言語で指示できれば、その障壁は下がります。

なお、Tableau AIの基盤にはEinstein Trust Layerが使われています。同じ仕組みはEinstein系の機能でも共通して用いられており、Salesforce製品を横断する共通の基盤として位置づけられています。

機能③Tableau Catalogの説明生成

3つ目は、Tableau Catalogによる説明の自動生成です。データソース、ワークブック、テーブルの説明文を自動で作ります。

地味に見える機能ですが、ダッシュボードが60本ある環境では効きます。どのダッシュボードが何を見るためのものかが分からなければ、選ぶ手間が発生するためです。状況①で触れた「どれを見ればよいのかを選ぶ手間」は、説明が付いているだけで軽くなります。

説明の自動生成は、作った本人が退職や異動でいなくなった後にも効いてきます。4年運用していれば、担当者は入れ替わります。作成の意図が引き継がれないまま残ったダッシュボードは、誰にも判断できないものになります。説明が付いているかどうかは、そのまま資産の寿命を左右します。

3つの機能は独立していますが、目的は共通しています。データに近づくまでの距離を短くすることです。

Tableau AIは1つの機能を指す名前ではありません。届ける・作る・説明するという3種類の支援をまとめた総称です。

Tableau Pulseでできる4つのこと

3つの機能のうち、既存の運用を最も大きく変えるのはTableau Pulseです。ダッシュボードを開くという前提を外し、変化があったときに知らせる側へ回るためです。公式ヘルプに記載されている動作を整理すると、できることは4つに分けられます。4つは独立した機能として並んでいません。検知から深掘りまでが1つの流れとしてつながっています。ここでは、Tableau Pulseでできることを順に解説していきます。

できること①フォロー中の変化を受け取る

1つ目は、フォローしている数字の変化を受け取ることです。

利用者は、関心のあるメトリクスをフォローします。以後、その数字に動きがあったときに要約が届きます。全員が同じ内容を受け取る形ではありません。フォローの内容に応じて届く情報が変わる設計です。公式ヘルプでも、パーソナライズされたインサイトという表現が使われています。

化粧品メーカーの営業40名は、担当する販路も、扱う製品カテゴリも分かれていました。全員に同じ月次レポートを配っても、自分に関係のある行を探す作業が発生します。フォローの単位を分ければ、その作業がなくなります。

受け取る側の操作は、フォローの登録だけです。見に行く習慣を新しく作るより、関心を1度登録するほうが定着しやすいという性質があります。登録という行為は1回で終わるものです。毎週決まった時間にダッシュボードを開くという習慣を40名に根付かせる取り組みと比べると、必要な働きかけの量が違います。

できること②変化の要因を自動で検出する

2つ目は、数字が動いた要因を自動で拾うことです。

公式ヘルプでは、Tableau Pulseが「推進要因、傾向、寄与要因、外れ値を自動的に検出」すると記載されています（2026年8月時点）。数字が上がった、下がったという事実だけでなく、どの内訳が動いたのかまでを含めて届く形になります。

要因まで届くことの意味は、次の行動が決まる点にあります。受注が落ちたという情報だけでは、確認する対象が絞れません。特定の販路が落ちているという情報が付けば、確認する先が決まります。状況②で挙げた、気づくのが遅れて打てる手が限られるという問題に対して、時間と手がかりの両方で効いてきます。

ただし、検出された要因が原因とは限りません。相関のある内訳が示されるだけで、因果の判断は人が行います。この線引きを最初に共有しておかないと、届いた要因をそのまま結論として扱う運用が生まれます。示されるのは確認すべき候補であり、答えとして扱うものではありません。

できること③ダッシュボードの外へ配信する

3つ目は、Tableauの画面の外に情報を出すことです。

公式ヘルプによると、インサイトはSlackとメールダイジェストで配信できます。Tableauにログインしなくても、日常的に開いているツールの側に届く形になります。

この配信先の設計が、実は最も効きます。ログインするという行為自体が、見に行く工程の一部だからです。化粧品メーカーの営業31名がダッシュボードを開いていなかったのも、Tableauを開く習慣がなかったことが理由でした。日常的に開いているツールへ届けば、その工程は消えます。

一方で、配信は増やしすぎると読まれなくなります。届く量と読まれる割合の関係は、後の章で扱う指標の設計に直結します。配信先を選ぶときは、その相手が1日に何通の通知を受け取っているかも考慮に入れます。すでに大量の通知が流れているチャンネルへ送れば、埋もれる可能性が高くなります。届ける経路の選択は、内容の質と同じくらい結果を左右します。

できること④自然言語で深掘りの質問をする

4つ目は、届いた要約に対して追加の質問を投げることです。

要約を読んで疑問が生まれたとき、その場で質問できます。別のダッシュボードを探しに行く必要がありません。公式ヘルプでは、Pulseに対するTableau Agentの機能としてこの動作が整理されています。

この動きは、状況③で挙げた依頼の集中を減らす方向に働きます。経営企画部へ届いていた月25件の依頼のうち、一定の割合は「その数字の内訳を見たい」という単純な内容でした。届いた要約からその場で掘れれば、依頼として起票する必要がなくなります。

深掘りの質問が成立するかどうかは、元になるメトリクスの定義に左右されます。定義が曖昧なまま配信を始めると、質問への回答も曖昧になります。定義の設計が、深掘りの質を決める前提になります。

Tableau Pulseの要点は、変化の検知・要因の提示・外部ツールへの配信・その場での深掘りという4つが1つの流れとしてつながっていることです。

Tableau Agentが担う3つの作業

Tableau Pulseが届ける側の機能だとすれば、Tableau Agentは作る側を助ける機能です。データを扱う作業のうち、操作の習得が壁になっていた部分を自然言語で代替します。公式ヘルプに記載されている支援の対象は、Viz作成・計算フィールド・Prepのフロー作成の3つに整理できます。いずれも分析の結論を出す機能ではありません。結論にたどり着くまでの手数を減らす機能です。ここでは、それぞれの作業を解説していきます。

作業①自然言語の指示からVizを作る

1つ目は、言葉で指示してグラフを作る作業です。

公式ヘルプによると、Tableau Agentはデータの探索とVizの作成を支援します。どの項目を軸に置き、どの数値を並べるかを操作で指定する代わりに、見たい内容を言葉で伝える形になります。

化粧品メーカーの営業40名のうち、Tableauで自分でグラフを作れる担当者はごく一部でした。作れない理由は分析の知識にありません。画面の操作を覚えていないという点にあります。この壁が下がると、経営企画部を経由しない確認が増えます。

公式ヘルプでは、パフォーマンスの観点からデータ抽出やファイルベースのデータでの利用が推奨されている旨も記載されています。ライブ接続でも動作しますが、応答の速さは接続の形に左右されます。試す段階では、抽出したデータで動かして応答の速さを確かめておくほうが判断しやすくなります。遅いという印象が最初に付くと、機能の評価とは別の理由で使われなくなります。

作業②計算フィールドの内容を説明する

2つ目は、計算フィールドを作る作業と、既存の計算フィールドの中身を説明する作業です。

公式ヘルプでは、計算フィールドの作成と説明の両方が支援の対象として挙げられています。後者は、運用が長い環境ほど効きます。4年運用していれば、当時の担当者が作った計算式が残っており、中身を読み解ける人がいなくなっている場合があるためです。

化粧品メーカーでも、売上の集計に使われている計算式のうち、いくつかは作成の経緯が分からない状態でした。触ると数字が変わるため、誰も手を付けられません。説明が得られれば、そこから判断ができます。

新しく作る場面より、過去に作られたものを読み解く場面のほうが、この機能の価値は分かりやすく出ます。読み解けた計算式は、そのまま引き継ぎの資料にもなります。担当者が入れ替わるたびに同じ解読作業を繰り返している組織では、この工程が積み上がった負債として残っていることが少なくありません。説明を得て記録に残すところまでを1つの作業として設計しておくと、次の代へ持ち越されません。

作業③Prepのフロー作成を助ける

3つ目は、Tableau Prepでのデータ準備の作業です。

公式ヘルプでは、Tableau AgentがTableau Prepでのフロー作成を支援する機能が独立して記載されています。データを結合し、不要な行を落とし、形を整えるという工程を、言葉での指示で組み立てられます。

準備の工程は、分析全体のなかで時間を取られやすい部分です。化粧品メーカーの経営企画部が受けていた月25件の依頼も、実際の作業時間の多くはデータを整える工程に費やされていました。分析の作業より、その手前の準備が重いという構図です。

なお、Tableau Prep Builderでこの機能を使う場合は2025.2以降のバージョンが必要と記載されています。利用にあたって確認すべきバージョンの条件は、後の章でまとめて扱います。

Tableau Agentが下げるのは分析の難しさではありません。Vizの作成・計算式の解読・データ準備という操作の習得にかかる負担です。

Tableau AIを使う前に必要な3つの条件

機能を理解した後で確認するのは、自社の環境で使える状態にあるかどうかです。公式ヘルプには「既定では、Tableau の AI 機能はオフになっています」と明記されており、契約していれば自動的に使えるわけではありません。化粧品メーカーが有効化するかどうかの判断に2週間かけたのも、この確認に時間がかかったためです。3つとも、機能の説明を読んでいるだけでは答えが出ません。自社の設定画面と契約内容を実際に見に行く作業になります。ここでは、使い始める前に必要な3つの条件を解説していきます。

条件①サイトでAI機能が有効であること

最初の条件は、サイトの設定でTableau AIが有効になっていることです。

公式ヘルプでは、既定の状態でAI機能がオフになっており、管理者がTableau CloudまたはTableau Serverのサイトで有効にする必要があると記載されています（2026年8月時点）。※参考記事はこちら

この既定がオフであるという設計は、確認の負担を管理者側に置くという意味を持ちます。利用者が個別に判断して使い始める形にはなりません。裏を返せば、社内で使う範囲を組織として決めてから開けられるということです。

化粧品メーカーでは、情報システム部と管理部門の間で、どの範囲に開けるかの調整に時間がかかりました。全社に一斉に開くのか、特定のグループに限るのかで、確認すべき点が変わるためです。先に範囲を決めておくと、この調整は短く済みます。誰に使わせたいかが定まっていない状態で有効化の可否だけを議論すると、結論が出ないまま時間が過ぎます。

条件②該当するロールが割り当てられていること

2つ目の条件は、利用者に適切なロールが割り当てられていることです。

公式ヘルプによると、Tableau Agentを利用するにはCreatorまたはExplorerのロールが必要です。Viewerのロールの場合、ダッシュボードで機能が有効になっていることに加えて、[AIへのアクセス]と[フルデータクエリ]のパーミッションが必要と記載されています（2026年8月時点）。※参考記事はこちら

この条件は、対象者の人数を見積もる作業に直結します。化粧品メーカーの営業40名のうち、ExplorerやCreatorのロールを持っていたのは一部でした。全員に使わせる想定であれば、ロールの見直しが前提になります。

条件を確認する順番としては、使わせたい人を先に決めてから、その人のロールを見に行くほうが早く済みます。ロールの見直しはライセンスの構成にも波及します。人事異動の時期と重なると調整が長引くため、確認は早めに始めておくほうが安全です。

条件③対象のバージョンを満たしていること

3つ目の条件は、利用する環境のバージョンです。

公式ヘルプに記載されている条件は、Tableau Desktopが2025.1以降、Tableau Serverが2025.3以降、Tableau Prep Builderが2025.2以降です。ダッシュボード解説の機能はベータ版として提供されており、2026年7月以降の記載があります。

環境ごとに条件が違う点に注意してください。Tableau Cloudを使っている場合と、自社でTableau Serverを運用している場合とでは、バージョンを上げる作業の重さが変わります。前者は提供側の更新に従いますが、後者は社内で計画を立てる必要があります。

化粧品メーカーはTableau Cloudを利用していたため、この条件は問題になりませんでした。確認が必要かどうかは、Cloudを使っているか自社で運用しているかで最初に分かれます。

Tableau AIは契約していれば自動で使える機能ではありません。サイトでの有効化・ロールの割り当て・バージョンの3つを満たして初めて動きます。

Tableau AIの安全性を確認する3つの観点

条件①で触れたとおり、Tableau AIは管理者が有効にして初めて動きます。その判断で必ず論点になるのが、社内のデータが外部へ出るのかという点です。化粧品メーカーでも、管理部門から最初に出た質問がこれでした。公式ヘルプによると、Tableau AIはEinstein Trust Layerの上に構築されており、データとプライバシーの制御が提供されると記載されています。確認の対象は、機能が安全かどうかという一般論ではありません。自社のどのデータが、どの経路を通るのかという具体の話です。ここでは、確認しておく3つの観点を解説していきます。

観点①外部モデルとのやり取りの経路

1つ目の観点は、データがどの経路を通るかです。

Tableau AIの生成機能は、外部の言語モデルとやり取りをします。その経路に介在するのがEinstein Trust Layerです。公式ヘルプでは、Tableau AIがこの仕組みの上に構築されていると明記されています（2026年8月時点）。

経路が明示されていることは、稟議を通すうえで説明しやすい材料になります。どこを通り、どこで保護がかかるのかを図に落とせるためです。逆に、経路が説明できない状態では、管理部門の確認は通りません。

一任する範囲と人が承認する場面をどう設計するかは、ほか記事「Einstein Trust Layerとは？AIに一任する範囲と人が承認する場面の設計」で詳しく扱っています。本記事では、Tableau AIから見た確認の観点に絞ります。経路の説明は、製品の資料をそのまま引用するだけでは足りません。自社の環境でどの機能を使うのかを添えて初めて、確認する側が判断できる形になります。

観点②プロンプトに含まれるデータの扱い

2つ目の観点は、実際に送られる内容の範囲です。

生成の機能を使うと、指示の文章に加えて、対象となるデータの一部が処理の対象になります。どの範囲が含まれるのかを把握しないまま使い始めると、想定していなかった情報が処理に回る可能性が残ります。

化粧品メーカーの場合、取引先ごとの卸価格が論点になりました。販路別の受注状況を扱うメトリクスであれば問題になりませんが、価格の内訳まで含む分析では扱いが変わります。確認すべきなのは機能の安全性の一般論より、自社のどのデータを対象にするかという範囲の話です。

範囲を決めておけば、後から対象を広げるときの判断も速くなります。最初に線を引く作業は、後で効いてきます。線を引く単位は、部門でも項目でもかまいません。重要なのは、対象に含めるかどうかを誰が決めるのかを明確にしておくことです。判断する人が決まっていなければ、範囲の議論は毎回振り出しに戻ります。実際にこのメーカーでも、最初に決めたのは判断する担当を1名置くことでした。

観点③管理者が制御できる設定の範囲

3つ目の観点は、有効化する対象を管理者がどこまで絞り込めるかです。

公式ヘルプでは、Tableau Cloudの場合に単一のユーザーグループに限定して有効化することも、サイト全体で有効化することもできると記載されています。ダッシュボードに関する機能はパーミッションで制御されます。

制御の粒度が分かっていれば、段階的に広げる計画が立てられます。まず特定のグループで試し、問題がなければ範囲を広げるという進め方が取れるためです。全社か全面停止かの二択しかない仕組みでは、この進め方は選べません。

化粧品メーカーが2週間で判断できたのは、この粒度を確認できたからでした。最初から全社に開ける必要がないと分かった時点で、論点が「試す対象をどこにするか」へ移っています。段階を踏める設計であることが、最初の一歩を軽くします。

安全性の確認は機能の一般論で終わらせず、通る経路・送られる範囲・管理者が制御できる粒度の3点を自社の対象データに当てて見ます。

Tableau AIの導入でつまずく3つの落とし穴

条件と安全性の確認を終えても、進め方を誤ると使われないまま止まります。既存のダッシュボードが多い環境ほど、この傾向は強く出ます。60本の資産があるということは、それだけ過去の運用が積み上がっているということでもあるためです。3つは連鎖します。定義を決めずに配信すれば指摘が出て、既存の資産を整理し始めれば着手が遅れ、読まれているかを測らなければ改善の手がかりが残りません。ここでは、繰り返し起きる3つの落とし穴を解説していきます。

落とし穴①メトリクスを定義しないまま配信する

1つ目は、届ける対象を決めないまま配信を始めてしまうことです。

Tableau Pulseは、メトリクスの定義にもとづいて動きます。公式ヘルプでも、メトリクス定義でコアメタデータを指定すると記載されています。この定義が曖昧なままだと、届く要約の内容も曖昧になります。

化粧品メーカーでは、売上という言葉が部門によって違う意味で使われていました。営業は出荷ベースで話し、経営企画部は計上ベースで見ています。どちらの定義でメトリクスを作るかを決めないまま配信すると、届いた数字について「その数字は違う」という指摘が出ます。

配信の設定より、定義を決める会話のほうが時間がかかります。この順番を飛ばすと、後から全部作り直すことになります。作り直しの手間より、指摘が出た記憶のほうが後を引きます。最初に届いた数字が違っていた機能は、直した後も信用されにくくなるためです。定義の合意には時間をかける価値があります。決める場を1度設けるだけで済む作業でもあります。

落とし穴②既存のダッシュボードを置き換える

2つ目は、Pulseを入れるにあたって既存のダッシュボードを整理しようとすることです。

一見すると筋が通っています。60本もあるのだから、この機会に減らそうという発想です。ところが、整理の作業には利用状況の調査と各所への確認が伴い、着手までの期間が読めなくなります。Pulseを試すことと、資産を整理することは別の作業です。

化粧品メーカーも、当初は整理から入る計画を立てていました。方針を変えたのは、60本のうち誰が何を使っているかの調査だけで数週間かかると分かった時点です。既存のダッシュボードはそのまま残し、Pulseは新しく3本のメトリクスから始めました。

置き換えを前提にすると着手が遅れます。並走させて、後から判断するほうが早いでしょう。並走させると、どちらが使われるかが自然に見えてきます。使われなくなったダッシュボードから順に整理すれば、調査の作業も軽くなります。整理の判断材料を、運用のなかで集める形です。

落とし穴③通知が読まれているかを測らない

3つ目は、配信した通知が読まれているかを確かめないまま続けることです。

届く仕組みに変えた時点で、目的の半分は達成されたように見えます。しかし、届いていることと読まれていることは違います。読まれていない通知は、受信箱の中で無視される項目が1つ増えただけの状態です。

化粧品メーカーでは、開始から1週目に通知を開いた割合がおよそ4割でした。この数字を把握していたため、頻度と内容を調整する判断ができています。測っていなければ、なんとなく定着していないという印象だけが残ります。

読まれない原因は、内容と頻度のどちらにもありえます。切り分けるには、両方の数字が必要です。測る仕組みは、配信を始める前に用意しておきます。後から遡って集めようとしても、初期の状態は残っていません。

Tableau Pulseでつまずく順番は決まっています。定義を決めずに配信し、既存の資産を先に整理しようとし、読まれているかを測らないという3つです。

Tableau Pulseのメトリクス設計4ステップ

落とし穴①で触れたとおり、Pulseの成否は定義の設計で決まります。設定の操作は短時間で終わりますが、何を監視して誰に届けるかを決める工程には時間がかかります。化粧品メーカーが最初の6週間で踏んだのは、次の4つのステップでした。順番を入れ替えると、どこかで手戻りが発生するでしょう。とくにステップ①と②を逆にすると、定義の議論が対象の選定にまで戻ってしまいます。ここでは、その4ステップを順に解説していきます。

ステップ①監視する数字を1つ選ぶ

最初にするのは、監視する数字を絞ることです。

このメーカーが最初に選んだのは、販路別の受注金額でした。状況②で気づくのが遅れた数字であり、動きに気づけば手が打てるという条件を満たしています。候補には在庫回転や新規取引先の件数もありましたが、最初の1つには選んでいません。

絞る理由は、うまくいかなかったときに原因を切り分けられるようにするためです。3本のメトリクスを同時に立ち上げても、読まれない理由がどれに起因するのかが分からなくなります。実際にはこのメーカーも3本まで広げていますが、最初の2週間は1本で運用しています。

小さく始める（スモールスタート）進め方には、調整の対象が絞られるという利点があります。最初の1本で運用の型ができれば、2本目以降の立ち上げは短くなります。定義の決め方、対象者の選び方、頻度の考え方が一度決まっているためです。1本目に時間をかけることは、全体の期間を縮める判断でもあります。

ステップ②メトリクスの定義を指定する

2つ目は、選んだ数字の定義を確定させる工程です。

公式ヘルプでは、メトリクス定義でコアメタデータを指定すると記載されています。どのデータソースの、どの項目を、どの単位で見るのかを決める作業です。ここで落とし穴①に挙げた部門ごとの言葉の違いが表面化します。

化粧品メーカーでは、受注金額を計上ベースで定義しました。営業が普段使っている出荷ベースとは違うため、その旨を対象者へ明示しています。定義を変えることは目的ではありません。届いた数字が何を指すのかを揃えることが目的です。

この工程は、業務設計から入る作業に近い性質を持ちます。ツールの設定画面を開く前に、何を正とするかを社内で決める必要があるためです。決めた定義は、配信の文面にも添えておきます。届いた側が「この数字は何を指すのか」を確認できる状態にしておけば、指摘のやり取りが減ります。定義を決めることと、決めた定義を見える場所に置くことは別の作業です。

ステップ③フォローする対象者を絞る

3つ目は、誰に届けるかを決める工程です。

このメーカーが対象にしたのは、営業の課長5名でした。40名全員ではありません。課長を選んだ理由は、数字の変化に対して打ち手を判断する立場にあるためです。届いても行動につながらない相手に配信しても、読まれない通知が増えるだけになります。

対象を絞ると、意見も追えます。5名であれば、読まなかった理由を個別に確認できます。40名に一斉に配信した場合、寄せられる意見は40通りに分かれ、どれから直すかの判断ができません。

期間は6週間と区切りました。終わりを決めておかないと、試している状態のまま評価の場が来ません。6週間という長さは、週1回の配信を6回はさめる最短の期間として選んでいます。1回や2回では、たまたま読まれなかっただけなのか、継続的に読まれていないのかを区別できません。区切りを設けたうえで、期間の終わりに広げるかどうかを判断する場を先に決めておきました。

ステップ④配信の頻度を決める

最後は、どのくらいの間隔で届けるかを決める工程です。

公式ヘルプによると、インサイトはSlackとメールダイジェストで配信できます。化粧品メーカーは、週1回のダイジェストから始めました。毎日届く設定も選べましたが、読まれない状態が続くリスクを避けています。

頻度は、後から動かせます。読まれている割合が高く、もっと早く知りたいという声が出たときに上げれば足ります。逆に、最初から高い頻度で始めて読まれなくなった場合、下げても印象は戻りません。頻度を決めるときは、対象にした数字が動く速さも見ます。日次で大きく動く数字であれば週1回では遅く、月単位でしか動かない数字であれば毎日届いても内容が変わりません。動きの速さと配信の間隔を合わせる作業です。

以上が、Tableau Pulseのメトリクスを設計する4ステップでした。

Pulseの設計は、監視する数字を1つ選び、定義を確定させ、届ける相手を絞り、頻度を決めるという順番で進めます。

Tableau AIの効果が出やすい3つの業務

設計の手順を示しましたが、どの業務に当てるかで結果は変わります。効果が出やすいのは、同じ数字を繰り返し確認している業務です。確認の回数が多いほど、届く仕組みに変えた効果が積み上がるためです。化粧品メーカーで実際に変化があったのも、日常的に繰り返されていた3つの業務でした。3つに共通するのは、同じ数字を同じ人が繰り返し見ているという構造です。繰り返しの回数が、そのまま効果の大きさに変わります。ここでは、その3つを解説していきます。

業務①週次で同じKPIを確認している会議

1つ目は、決まった曜日に同じ数字を確認している会議です。

このメーカーには週1回の営業会議があり、前週の受注状況を共有する時間が設けられていました。資料は経営企画部が作成し、会議の場で初めて全員が数字を見ます。気づきが生まれるのも、打ち手が決まるのもその場です。

Pulseで同じ数字が事前に届くようになると、会議の出発点が変わります。全員が数字を見た状態で集まるため、共有の時間を短くして、打ち手の議論に時間を回せます。数字を読み上げる時間が要らなくなるという単純な効果です。

会議の資料作成が丸ごとなくなるわけではありません。それでも、参加者が事前に把握している状態で始まるかどうかは、議論の質に影響します。実際にこのメーカーでは、会議の前半で行っていた数字の読み上げを省く運用へ変えています。空いた時間は、落ちている販路への対応を決める議論に充てられました。会議の長さが変わらなくても、中身は入れ替わります。

業務②担当者ごとに数字を集計する報告作業

2つ目は、月次の報告のために各担当者が数字をまとめる作業です。

このメーカーでは、営業がそれぞれ担当分の数字をExcelに転記していました。1人あたり月およそ6時間かかっています。Tableauに同じ数字が入っているにもかかわらず、報告のフォーマットに合わせるための転記が発生していました。

この作業は、Pulseだけでは消えません。報告のフォーマットを変える判断が別に要ります。それでも、数字の確認と抽出の工程は短くなります。転記の前段にあった「どのダッシュボードから取るか」を探す時間が消えるためです。

効果が出る業務を選ぶときは、作業の全体が消えるかより、どの工程が短くなるかを見るほうが判断しやすくなります。月およそ6時間という数字も、全部が消えると考えるより、どの工程に何時間かかっているかを分けて見るほうが現実的です。分けて見れば、次に手を付ける対象も決まります。転記の作業を残したままでも、探す時間が減れば効果は測れるはずです。測るときは、転記にかかる時間と、その前段で数字を探していた時間を分けて記録します。

業務③問い合わせで発生する分析の依頼

3つ目は、経営企画部に届いていた月およそ25件の分析依頼です。

依頼の内容を分類すると、内訳を見たいという単純なものと、仮説を立てて検証したいという込み入ったものに分かれていました。前者は、Pulseで届いた要約から深掘りの質問を投げれば、依頼として起票する必要がなくなります。

依頼が減ると、経営企画部は後者に時間を使えます。件数を減らすこと自体は目的ではありません。扱う内容を移すことが目的です。単純な内訳の確認に4名の時間が使われている状態は、組織として損をしています。

業務単位で何をAIに任せるかを決める考え方は、ほか記事「Agentforce活用事例7選｜成果が出た営業組織に共通する3つの特徴」でも整理しています。対象は違っても、選び方の考え方は共通です。扱う内容が移れば、依頼する側の期待も変わります。

Tableau AIの効果は、同じ数字を繰り返し確認している業務ほど大きく出ます。週次会議・月次報告・分析依頼の3つが典型です。

Tableau AIの費用を見積もる3つの確認項目

ここまで、対象の業務まで絞り込む流れを解説してきました。稟議を書く段階で次に必要になるのが費用の見積もりです。ただし、Tableau AIの利用料は単独の価格として公開されていません。契約しているプランと利用者の人数に依存します。金額を出す前に、確認しておく項目が3つあります。金額を先に聞こうとすると、返ってくるのは前提つきの概算になります。前提のほうを先に固めておけば、見積もりの精度も上がります。確認の順番は、契約・人数・環境の3つです。ここでは、その3つを順に解説していきます。

項目①上位プランの契約が要るかどうか

1つ目の確認項目は、現在の契約でTableau AIの対象になるかどうかです。

公式ヘルプでは、Tableau Cloudの環境でTableau Agentを利用する条件として「Tableau Cloud+ または Tableau+」が挙げられています（2026年8月時点）。Tableau Desktopで利用する場合も同様の記載があります。つまり、標準のプランのままでは対象にならない可能性があります。

この確認が最初に来る理由は、結果によって検討の前提が変わるためです。上位プランへの変更が必要であれば、金額の規模も承認の経路も変わります。機能の比較を進める前に、この点を販売元へ確認しておくほうが手戻りが減ります。

なお、公式ヘルプにはトライアル期間中は無料で利用できるものの、1時間あたりに実行できるリクエストの数に制限が適用される場合があるという記載もあります。この記載は変わる可能性があるため、契約の前に最新の条件を確認してください。

項目②対象になる利用者の人数

2つ目の確認項目は、実際に使う人が何人になるかです。

条件②で触れたとおり、Tableau Agentの利用にはCreatorまたはExplorerのロールが必要です。Viewerの場合は追加のパーミッションが要ります。ロールの構成を変えれば、ライセンスの費用も変わります。

化粧品メーカーの場合、営業40名のうち最初の対象は課長5名でした。全員分のロールを見直す前提で見積もると金額は大きくなりますが、5名で始める前提であれば規模は変わります。見積もりの金額を左右するのは機能の選択ではありません。どこまで広げる前提で数えるかという設計の側です。

段階的に広げる計画であれば、その段階ごとに費用を分けて示すほうが承認は通りやすくなります。5名で始めて15名へ広げ、その後に全員へ広げるという3段階で示せば、承認する側は最初の段階だけを判断すれば済みます。全員分の金額を最初に出すと、金額の大きさだけで判断が止まります。段階を分けるのは金額を小さく見せる工夫ではありません。判断の単位を合わせる工夫です。

項目③バージョンを上げる作業の有無

3つ目の確認項目は、環境を対象バージョンに上げる作業が必要かどうかです。

条件③で挙げたとおり、Tableau ServerやTableau Prep Builderには対象バージョンの条件があります。自社でTableau Serverを運用している場合、更新の計画と検証の工数が別途かかります。この工数はライセンス費用の外にあるため、見落とされやすい項目です。

Tableau Cloudを利用している環境では、この項目は問題になりません。化粧品メーカーが早く判断できた理由の1つもここにあります。逆に、自社で運用している企業では、更新の時期と合わせて着手を計画するほうが効率的です。

3つの確認項目を押さえてから販売元へ問い合わせると、返ってくる回答の精度が上がります。更新の計画と着手の時期は、あわせて考えます。自社で運用している場合、次の更新が半年以内にあるかどうかが判断の分かれ目になります。

Tableau AIの費用は機能ごとの価格で決まりません。上位プランの要否・対象になる人数・バージョン更新の工数という3つの掛け算で決まります。

Tableau AIの効果を測る3つの指標

費用を見積もったら、その支出に見合う効果が出ているかを測る仕組みも同時に決めます。落とし穴③で触れたとおり、測っていなければ改善も撤収も判断できません。見るべき指標は立ち上げ期と定着期で変わります。最初から効果の大きさを測ろうとすると、まだ使われていない段階で数字が出ずに判断を誤るでしょう。立ち上げ期は使われているか、定着期は読まれているか、拡大期は業務が変わったかという順で見ます。ここでは、フェーズを追って3つの指標を解説していきます。

指標①メトリクスをフォローした人数

立ち上げ期に見るのは、フォローの登録をした人数です。

Pulseは、フォローされていないメトリクスについては何も届けません。つまり、登録が行われていない時点で、配信の効果を測る以前の状態にあります。化粧品メーカーでは、対象にした課長5名のうち何名が登録を終えたかを週単位で数えていました。

登録が進まない場合、原因は関心の低さとは限りません。登録の方法が伝わっていないだけの場合もあります。実際にこのメーカーでも、対象者のうち1名は登録の画面にたどり着けていませんでした。案内を出し直した時点で解決しています。

内容の改善に手を付ける前に、伝わっているかを確かめる順番が効きます。登録の状況は、対象者が少ないうちなら個別に確認できます。5名であれば、登録していない人に直接尋ねてください。人数が増えてからでは同じ確認はできないため、立ち上げ期のうちに詰まりやすい箇所を把握しておくと、後の展開で同じ問題を避けられます。

指標②配信された通知が開かれた割合

定着期に見るのは、届いた通知が開かれた割合です。

化粧品メーカーでは、開始から1週目の開封がおよそ4割でした。この数字を起点に、頻度と内容の調整を行っています。届いているのに開かれないという状態は、内容が業務の役に立っていないか、届くタイミングが合っていないかのどちらかを示します。

切り分けるには、頻度を変えたときの変化を見ます。頻度を下げて割合が上がるなら、量の問題です。頻度を変えても割合が動かないなら、中身の問題になります。1度に2つの条件を変えると、どちらが効いたのかが分からなくなります。開かれた割合は、絶対値より推移で見ます。最初の週に4割だった数字が翌週に上がったのか下がったのかで、打つ手は変わります。1度の測定だけでは判断できません。

効果測定の設計をより深く扱う考え方は、ほか記事「【2026年8月時点】Agentforce Observabilityとは？定着と精度を測る指標設計」で解説しています。

指標③分析依頼の件数の変化

拡大期に見るのは、経営企画部に届く分析依頼の件数です。

導入前の件数を記録していなければ比較できません。化粧品メーカーが月およそ25件という数字を先に押さえていたのは、この比較のためでした。着手の前に現状を数えておく作業が、後の判断材料になります。

件数が減っていない場合でも、内訳が変わっている可能性があります。単純な内訳の確認が減り、込み入った依頼が増えていれば、狙いどおりに進んでいる状態です。件数だけを見て効果がなかったと判断すると、実際の変化を見落とします。依頼の内容を分類して記録しておけば、この判別は可能です。分類は3種類ほどで足ります。件数だけを数えていると、質の変化は見えないままになります。

数字が動かないこと自体は失敗ではありません。どこを直すかを決める材料になります。

Tableau AIの効果は、フォローの登録人数・通知が開かれた割合・分析依頼の件数という3つを、フェーズを追って見ると判断できます。

Tableau AIが向いている企業の3つの特徴

ここまで進め方と測り方を解説してきましたが、どの企業でも同じ効果が出るわけではありません。前提の整い方によっては、着手の順番を変えたほうがよい場合もあります。判断の材料になるのは、繰り返しがあるか、数字の意味が揃っているか、設定を担う人がいるかの3点です。3つとも、製品を選ぶ前に自社の側だけで確認できる項目です。見積もりを取る前の段階でも、ある程度の見当がつきます。ここでは、効果が出やすい企業の特徴を整理していきます。

特徴①同じKPIを定期的に見る会議がある

1つ目の特徴は、決まった間隔で同じ数字を確認する場があることです。

会議の存在は、その数字が組織にとって重要だと合意されている証拠になります。合意のある数字であれば、メトリクスとして定義する際の議論も短く済みます。逆に、誰も定期的に見ていない数字を選ぶと、定義の段階で意見が割れます。

化粧品メーカーの週1回の営業会議は、この条件を満たしていました。会議で扱っている数字をそのままメトリクスにしたため、何を監視するかの合意は既に取れている状態から始められています。

会議の間隔が短いほど、届く仕組みに変えた効果は大きくなります。日次で確認している数字であれば、なおさらです。逆に、四半期に一度しか見ない数字を最初のメトリクスに選ぶと、効果を確かめるまでに時間がかかります。6週間の期間中に変化が2回しか届かなければ、読まれているかどうかの判断もできません。会議の間隔は、そのまま検証にかかる期間を左右します。

特徴②データの定義が社内で揃っている

2つ目の特徴は、同じ言葉が同じ意味で使われていることです。

落とし穴①で挙げたとおり、売上という言葉が部門ごとに違う意味を持っていると、配信された数字への指摘が発生します。定義が揃っていれば、この工程を飛ばせます。

完全に揃っている必要はありません。最初に扱う1つの数字について合意が取れていれば着手できます。化粧品メーカーも、全社の定義が統一されていたわけではありません。受注金額の1点についてだけ計上ベースで揃える判断をしました。

すべてを揃えてから始める必要はありません。最初のメトリクス1本について合意が取れれば、着手はできます。揃っているかどうかを確かめる方法としては、同じ数字を複数の部門に尋ねてみることです。返ってきた金額が一致しなければ、その数字は定義が割れています。一致しない箇所を見つける作業は、Tableau AIを入れるかどうかに関係なく価値があります。部門をまたいだ会議で数字の話が噛み合わない原因が、そこにあるためです。

特徴③管理者の設定を担う人がいる

3つ目の特徴は、有効化と設定を担う人を置けることです。

条件①で触れたとおり、Tableau AIの有効化は管理者が行います。動き出してからも、メトリクスの追加や配信の調整が続くでしょう。この作業を担う人がいなければ、最初の設定のまま固定されます。

化粧品メーカーでは、情報システム部の担当者が週に1時間ほどを確認に充てる想定を置きました。初期の設定にかかる時間だけでなく、その後の調整の時間まで含めて見積もっている点が重要です。

社内に置けない場合の分け方の1つが、設計レビュー・アドバイザリーだけを外部に頼み、実装と運用は社内で持つ形です。すべてを外部に任せる形と、すべてを社内で持つ形の中間に、いくつかの組み合わせがあります。外部に頼む範囲は、後から狭めることもできます。最初だけ設計を見てもらい、運用が安定してきた段階で社内へ移すという進め方です。切り替える目安は、メトリクスを1本追加する作業を社内だけで完了できたときです。

Tableau AIの効果を左右するのは製品の性能より、定期的に見る会議・揃った定義・設定を担う人という3つが揃っているかどうかです。

Tableau AIを急がなくてよい3つのケース

向いている特徴を挙げましたが、当てはまらない場合に無理に進める必要はありません。先に整えるべきことがある状態で着手すると、効果が出ないまま評価だけが下がります。一度「使えなかった」という評価が付くと、条件が整った後で再び提案するときの障害になります。急がない判断は、諦める判断とは違います。着手の時期をずらし、その間に前提を整えるという選び方です。ここでは、着手を急がなくてよい3つのケースを解説していきます。

ケース①ダッシュボードの整理が終わっていない

1つ目は、既存の資産が把握できていないケースです。

落とし穴②では、整理を先にすると着手が遅れると書きました。一方で、何が動いていて何が使われていないのかを誰も把握していない状態は、別の問題を生みます。Pulseで新しく作ったメトリクスと、既存のダッシュボードの数字が食い違ったときに、どちらが正しいのかを判断できないためです。

判断の基準は、対象にする1つの数字について出所が説明できるかどうかです。60本すべてを整理する必要はありませんが、扱う数字に関わるものだけは経緯を追えるようにしておきます。

化粧品メーカーが受注金額を選んだのは、この数字の出所が明確だったからでもありました。出所が追えるかどうかは、データソースの作成者と更新の経路をたどれば判断できます。作成者が分からず、更新が手作業で行われている数字は、後から食い違いが出たときに原因を特定できません。最初のメトリクスには、この確認を通ったものを選びます。

ケース②数字の定義が部門ごとに違う

2つ目は、同じ言葉が部門ごとに違う意味で使われているケースです。

特徴②の裏返しにあたる状態です。定義が割れている状態で配信を始めると、届いた数字への指摘が繰り返し発生します。指摘への対応に追われるうちに、機能への評価が下がっていきます。

まず定義を揃える作業が先になります。この作業自体は、Tableau AIを入れるかどうかに関係なく必要なものです。部門をまたいだ会議で数字の話が噛み合わないという状態は、別の場面でも損失を生んでいます。

揃える範囲は、最初に扱う1つの数字だけで構いません。全社の定義を統一する取り組みにすると、着手までの期間が読めなくなります。1つの数字について揃えた経験は、次の数字にも使えるはずです。どの部門に確認を取り、どこで合意を記録し、誰が最終的に決めるのかという手順が一度できていれば、2つ目からは短く済みます。全社の統一を目指すより、1つずつ揃えて積み上げるほうが結果的に速く進みます。

ケース③対応バージョンに上げる予定がない

3つ目は、環境のバージョンが条件を満たしておらず、更新の予定もないケースです。

条件③で挙げたとおり、Tableau ServerやTableau Prep Builderには対象バージョンの条件があります。自社で運用している環境で、直近に更新の計画がない場合、Tableau AIを使うには更新の計画を先に立てる必要があります。

この場合、待っている期間を前提の整理に充てられます。ケース①とケース②で挙げた作業を先に進めておけば、更新が完了した時点ですぐ着手できます。定着まで伴走する体制をどう組むかも、この期間に検討できる論点です。

定着の設計をどう組むかは、ほか記事「【失敗パターンから学ぶ】Agentforce定着ガイドと3ヶ月のロードマップ」の考え方が参考になります。待つ判断も、進める判断と同じくらい具体的な理由にもとづいて選びます。

資産が把握できていない・定義が割れている・バージョンを上げる予定がないという3つのケースでは、着手を急がず前提を整えるほうが結果的に早く進みます。

Tableau AIとAgentforceの3つの違い

ここまでTableau AIだけを扱ってきましたが、検討の場では別の名前も同時に出てきます。Salesforceの製品にはAIを冠した機能が複数あり、どれをどう使い分けるのかが分かりにくくなっています。とくに混同されやすいのがTableau AIとAgentforceです。総称としてのSalesforce AIがどの層をまとめた呼び名なのかを先に押さえておくと、位置関係も見えてきます。どちらも自然言語で操作でき、どちらもEinstein Trust Layerの上に構築されているためです。それでも、担う役割は明確に分かれます。ここでは、3つの違いを解説していきます。

違い①扱うデータの範囲の差

1つ目の違いは、AIが読みに行くデータの粒度と範囲です。

Tableau AIが扱うのは、分析基盤に集約された数値データが中心です。売上、受注、在庫といった集計された指標を対象に、変化を検知して要約します。化粧品メーカーの販路別受注金額も、この範囲に入ります。

一方のAgentforceは、CRMに記録された個別の顧客や商談を対象にします。誰との商談が止まっているのか、どの問い合わせが未対応なのかといった、件単位の情報を扱います。集計された数字より、1件ごとの状態に近い領域です。

範囲が違えば、答えられる問いも別のものになるでしょう。どちらを使うかは、確認したいのが全体の傾向か、個別の状態かで分かれます。両方を使う場面もあります。全体の数字が落ちていることをTableau AIで把握し、どの商談で何が起きているかをCRM側で確認するという流れです。この場合、2つは順番に並ぶ関係です。どちらか一方を選ぶ問題として扱うと、この使い方が見えなくなります。なお、CRMの外にあるデータまでAgentforceが参照するには、Data 360という基盤が前提になります。

違い②動き出すきっかけの差

2つ目の違いは、動作が始まる条件です。

Tableau Pulseは、フォローされたメトリクスに変化があったときに動きます。加えて、利用者が質問を投げたときにも応じます。どちらの場合も、対象は登録済みの数字です。

Agentforceは、設定された条件を満たしたときに自ら動きます。商談が一定期間更新されていない、問い合わせが特定の分類に該当するといった条件です。届く先も、通知だけでなく処理の実行まで及びます。この差は、設定に必要な情報の量にも表れるでしょう。変化の検知だけであれば、監視する数字と閾値を決めれば足ります。条件を満たしたときに処理まで行う仕組みでは、実行の内容と例外の扱いまで決める必要があります。

Agentforceの機能の範囲は、ほか記事「【2026年最新】Agentforceの機能一覧｜360・Coworker・Voiceまで」で整理しています。本記事では、Tableau AI側から見た差分に絞ります。

違い③人が確認する地点の差

3つ目の違いは、人が判断に入る場所です。

Tableau AIの場合、届いた要約を読んで次の行動を決めるのは人です。要約が行動を代わりに実行することはありません。判断の材料が早く届くという性質にとどまります。

Agentforceの場合、実行までが対象に含まれます。そのため、どこまでを自動で完結させ、どこで人が承認するかを設計する作業が発生します。承認の地点を置く設計は、Tableau AIには存在しない論点です。

この差は、導入時の検討項目の量にも表れます。Tableau AIの検討は、対象の数字と届ける相手を決めれば足ります。実行を伴う仕組みでは、任せる範囲の設計が別途必要になります。検討にかかる期間の差も、この論点の量から生まれます。前者が2週間で判断できたのは、決める項目が少なかったためです。

Tableau AIとAgentforceは、扱うデータの範囲・動き出すきっかけ・人が確認する地点の3点で役割が分かれており、置き換えの関係にはありません。

【一問一答】Tableau AIに関するよくある質問

ここまで、Tableau AIでできることから設計の手順、測り方までを解説してきました。実際に検討を始めると、費用や言語対応、データの扱いなど、判断の手前で確認しておきたい点が出てきます。管理部門や情報システム部から必ず問われる項目です。以下の回答は、いずれも2026年8月時点のTableau公式ヘルプの記載にもとづいています。条件は変わる可能性があるため、契約の前に最新の記載を確認してください。最後に、Tableau AIについてよく寄せられる質問に答えていきます。

質問①Tableau AIは追加の費用がかかるのか

契約しているプランによって変わります。公式ヘルプでは、Tableau CloudでTableau Agentを利用する条件としてTableau Cloud+またはTableau+が挙げられています（2026年8月時点）。標準のプランのままでは対象にならない可能性があるため、まず現在の契約が対象かどうかを販売元へ確認してください。

質問②Tableau AIは日本語に対応しているのか

公式ヘルプでは、Tableau AIの機能は英語（en_US）とその他の言語の一部をサポートすると記載されています（2026年8月時点）。サポート対象外の言語設定では、Tableau Agentの応答が英語で返るという記載もあります。日本語で利用する予定であれば、対象のバージョンと機能について公式の記載を確認してから判断してください。

質問③Tableau AIとTableau Pulseは何が違うのか

Tableau AIはTableauに組み込まれた生成AI機能の総称で、Tableau PulseはそのうちメトリクスのインサイトをSlackやメールダイジェストで届ける機能です。並列の選択肢ではありません。包含の関係にあります。社内の資料では、Tableau AIという総称のままでは何を指すかが定まらないため、機能の名前まで下ろして書くほうが伝わります。

質問④Tableau AIを使うのに管理者の設定は必要か

管理者による有効化の操作が必要です。公式ヘルプには「既定では、Tableau の AI 機能はオフになっています」と明記されており、管理者がサイトで有効にする工程が入ります。Tableau Cloudの場合は、単一のユーザーグループに限定して有効化することも、サイト全体で有効化することもできると記載されています。段階的に広げる計画を立てられる粒度です。

質問⑤Tableau AIに社内データを渡して問題ないのか

Tableau AIはEinstein Trust Layerの上に構築されており、データとプライバシーの制御が提供されると公式ヘルプに記載されています。ただし、仕組みがあることと、自社のどのデータを対象にするかを決めることは別の作業です。取引条件や価格の内訳など、扱いを分けたいデータがある場合は、対象にするメトリクスの範囲を先に決めておく必要があります。

Tableau AIは数字を見に行く運用を変化が届く運用へ移す機能

Tableau AIとは、Tableauに組み込まれた生成AI機能の総称です。本記事では、必要になる状況から、3つの機能の役割、Tableau Pulseでできること、使い始める条件、安全性の観点、つまずく落とし穴、メトリクスの設計4ステップ、費用の確認項目、効果を測る指標までを、一連の流れとして解説してきました。

本記事で例として挙げた化粧品メーカーの場合も、変わったのは製品の選び方でした。従業員380名・営業40名・経営企画部4名で4年間Tableauを使い、公開されているダッシュボードは60本あります。それでも週1回以上開いている営業は9名にとどまり、分析の依頼は月およそ25件のまま減っていませんでした。有効化の判断に2週間、最初のメトリクス3本を営業の課長5名に6週間配信し、次は営業40名のうち15名へ広げる計画に進んでいます。

ダッシュボードの本数を増やすことから始めても、見に来る人は増えません。自社のどの数字が、どのくらいの間隔で確認されているのかを数えるところから始めてみてはいかがでしょうか。

なお、どの数字から任せるかを業務設計から一緒に整理し、定着まで伴走してほしい場合は、Agentforce導入・定着支援サービスにお気軽にご相談ください。1ユースケース×3ヶ月のスモールスタートから対応しています。