2026年6月、Salesforce Japan最大級のイベントAWTTに出展してきました。ブースで来場者の方に体験いただいたのは、Tableauで絞り込んだダッシュボードを、ボタンひとつでPassworkに連携し、LINEとメールを発信するデモ。会期3日間で、このフローを約300回、来場者の目の前で実行させていただきました。本記事では、デモの中身と「同じものをカスタム開発で組むと何が必要になるか」、そして打ち上げの中華まで、まとめてレポートします。
AWTT 2026に出展しました
2026年6月8日〜10日の3日間、Salesforce Japan最大級のイベントAWTT 2026に出展しました。昨年は1万5千人超が来場した大型イベントです。
SalesforceとTableauのユーザーがど真ん中で集まる場所なので、ブースに立ち寄ってくださる方の課題感もはっきりしています。いちばん多かったのは、やはりこの声でした。
「ダッシュボードで”この顧客たちにアプローチすべき”とまでは分かる。でも、そこから先は結局CSVに落として、リストを作り直して、別のツールに取り込んで……になっている」
分析の結果は出ている。次にやるべきこともだいたい見えている。それなのに、「見る」と「動く」のあいだに手作業の谷がある ── この谷を埋めるのがPassworkです、というのが今回のブース全体のメッセージでした。
デモ：Tableauで絞り込んで、ボタンひとつでPassworkに連携する
ブースのデモは、徹底的にシンプルにしました。テーマは「見るBI」から「動くBI」へ。Tableau上の操作はいつものダッシュボード操作のまま、最後の一歩だけが変わります。
デモのシナリオ
題材は、ECサイトの顧客を購買行動で分析するRFM分析ダッシュボード（Tableau Cloud上に構築）。優良顧客・新規育成・離反注意・休眠といったセグメントごとに、約8,000人の顧客が散布図とリストで可視化されています。
- ①Tableauで、いつも通りに絞り込む
RFMダッシュボード上で、セグメントや金額のフィルタ、リスト上の選択を使って「アプローチしたい顧客」を絞り込みます。ここまでは普段のTableau操作そのものです。
- ②ダッシュボード上のボタンを押す
ダッシュボードに埋め込まれた「Passworkに連携」ボタンを押すと、いま絞り込まれている顧客リストがそのままPasswork側のフローに渡り、フローが起動します。CSVのエクスポートも、リストの貼り直しもありません。
- ③Salesforceのリードと突合する
Passworkのフローは、受け取った顧客リストのメールアドレスをキーに、Salesforceのリードを照合。BI上の「点」が、CRM上の「誰」に変わります。
- ④分岐して、適切なチャネルで発信する
分岐ノードが顧客の属性に応じて発信チャネルを振り分け、LINE通知とメール（SendGrid）がその場で送信されます。来場者のスマホ側で実際に通知が届くところまでがデモです。
実際に動いていたフローは、たったこれだけの構成です。
- Tableauダッシュボードから起動（トリガー：絞り込み済みの顧客リストを受信）
- Salesforceからリードを取得（受信したメールアドレス一覧で照合）
- 分岐（顧客属性でチャネルを振り分け）
- LINE通知 ／ メール通知（SendGrid）
同じ仕組みをカスタム開発で組むと、何が必要か
「ボタンを押したら、絞り込んだリストでLINEとメールが飛ぶ」── デモとしては数十秒で終わる、一見シンプルな動きです。ブースでも「これ、うちでも作れそう」という反応をいただきました。実際、作れます。ただし、カスタム開発で組むと見た目以上にやることが多いのがこの連携です。
分解すると、最低でもこれだけの部品が必要になります。
| 必要な部品 | カスタム開発でやること |
|---|---|
| ① ダッシュボード内のボタン | Tableauの拡張機能（Extensions API）として開発し、ホスティングし、サイトの許可リストに登録する。ダッシュボード側の設定とセットで管理が必要。 |
| ② 「いま見えている行」の受け渡し | 全件ではなく「絞り込まれた結果だけ」を取得して送る必要がある。フィルタ・選択・表示中シートの状態をAPIで正しく拾うのは、Tableau拡張開発の中でも特に癖の強い部分。 |
| ③ 属性の補完 | ダッシュボードのビューに表示されている列が、連携に必要な列と一致するとは限らない。ビューに出ていない属性は、データソース側へ取りに戻る仕組みが別途必要になる。 |
| ④ 受け口のAPI | リストを受け取るWebhook／APIサーバーを建て、認証を設計し、運用する。 |
| ⑤ Salesforce照合 | OAuth認証、トークン更新、受信したN件のメールアドレスをIN句に展開するクエリ生成、ガバナ制限への配慮。 |
| ⑥ チャネル分岐と発信 | LINE Messaging API・メール基盤（SendGrid等）それぞれの認証と仕様に合わせた実装。文面への差し込み（パーソナライズ）も自前で。 |
| ⑦ 運用の足回り | 実行ログ、エラー時の通知と再実行、誰がいつ何件に発信したかの記録。デモでは見えないが、本番では一番効いてくる部分。 |
ポイントは、これらがTableau・Salesforce・LINE・メール基盤という4つの異なるサービスの「つなぎ目」に散らばっていることです。どれか1つの技術が難しいというより、認証もAPI仕様もエラーの出方も違う4つの世界を、1本の業務の流れとして安定稼働させ続けることに開発・運用コストがかかります。
Passworkでは、この①〜⑦がそれぞれトリガーとノードの設定に置き換わります。ダッシュボードからの起動はTableau連携トリガーが、Salesforce照合は入力ノードの条件設定（受信リストをそのままIN条件に使えます）が、チャネル振り分けは分岐ノードが、発信はLINE・SendGridの出力ノードが担当します。実行ログと再実行は、フローを動かせば標準でついてきます。
私たちは「カスタム開発が悪い」とは考えていません。むしろ350社超の実装支援の中で、こうした連携を何度も自前で組んできました。だからこそ、毎回同じ形で繰り返される”つなぎ目”の苦労は、プロダクト側が引き受けるべきだと考えています。個社ごとに違う業務ロジックにこそ、人の時間を使ってほしいからです。
おまけ：全国にいるメンバーで、中華を食べました
最後は技術の話ではなく、チームの話を少しだけ。
Praztoのメンバーは普段、全国それぞれの場所で仕事をしています。日々の仕事はリモートで完結していて、それで何も困らないのですが、AWTTのような出展は同じ場所に集まる数少ない機会です。
3日間の会期を終えた夜は、そのままみんなで中華へ。普段は画面越しのメンバーと、同じ卓を囲んで同じ料理を取り分ける ── 出展の打ち上げとしては、これ以上ないご褒美でした。
