はじめに こんにちは、データ基盤ブロックの平本（ @cisetn ）です。 本記事では、ZOZOTOWNのリアルタイムデータ連携基盤の中核である ETL層 を作り直した事例を紹介します。対象はオンプレミスのSQL ServerからBigQueryへリアルタイムにデータを連携する基盤です。そのETL層を Goで実装したプラグイン （実行基盤はFluent Bit）で再設計しました。 ZOZOのリアルタイム連携基盤は2020年に 一度紹介記事を公開しています が、それ以降、段階的にアーキテクチャを見直してきました。本記事はその中でもETL層の再設計にフォーカスします。 想定読者は、リアルタイム連携基盤やストリーミング処理基盤の設計・運用に関わる方です。 本記事で扱うこと、扱わないことは次のとおりです。 扱う ：ZOZOのリアルタイム連携の全体像、今回リプレイスした基盤の背景・設計・実装 扱わない ：BigQuery側のテーブル設計、SQL Server側のChange Tracking設定、利用側（BI・分析クエリ等） 目次 はじめに 目次 ZOZOのリアルタイムデータ連携の全体像 これまでの変遷 リプレイスに至った背景 顕在化してきた課題 新基盤アーキテクチャ 設計の軸 技術選定：Fluent Bit + Goプラグイン 全体構成 大量のデータをリアルタイムで捌くために考えたこと 新基盤の構成 INPUT内部：取得とエンコードを分けた OUTPUT内部：送信とACK確認を分けた 結果 今後の展望：Change Data Captureへの移行 まとめ ZOZOのリアルタイムデータ連携の全体像 本題の前に、ZOZOにおけるリアルタイム連携の全体像を軽く俯瞰しておきます。本記事のテーマがあくまで「その中のひとつ」であることを共有するためです。 ZOZOではデータソースが多岐にわたります。オンプレミスのものもあれば、クラウド上のものもあり、MySQL、SQL Server、DynamoDBなどさまざまです。当然、差分を検知する手段もソースに応じて変わりますし、連携の実現方式も1つではありません。 マネージド / SaaSで済むケース ：例えばMySQL → BigQueryであれば Datastream を利用する 専用のパイプラインを組む必要があるケース ：例えばDynamoDB → BigQueryのように、対応するマネージドサービスがない場合は、別途データ連携のパイプラインを構築する必要がある 結果として、ZOZOのリアルタイム連携基盤は 複数系統に分かれて共存 しています。本記事で扱うのは、そのうち オンプレ SQL Server → BigQuery の系統です。本番環境（prd）で 約400のテーブル を連携対象としており、新規の連携依頼も日々発生するため、データ基盤の運用において比重の大きな系統となっています。SQL ServerのChange Tracking機能で変更を検知し、プラグインで取得したレコードをPub/Sub経由でBigQueryに流しています。 これまでの変遷 実は、本記事で扱う系統は今回が初めてのリプレイスではありません。以下の変遷を経ています。 時期 アーキテクチャ 主目的 2020 Qlik Replicate → fluentd + Dataflow → BigQuery 安定性向上 + コスト削減 2024 fluentd + BigQuery Subscription （Dataflow を廃止） コスト削減 2025 プラグインによる ETL 層の再設計 + BigQuery Subscription 効率改善（メモリ・スループット・コスト） 2024年には、ストリーム処理層のDataflowを廃止し、Pub/SubのBigQuery Subscriptionに置き換えるリプレイスが行われました。このフェーズの主目的はコスト削減です。 そして今回、ETL層をプラグインで再設計したのが本記事のテーマです。詳細な背景と目標は次章で述べますが、結果として、コスト削減・メモリ効率の改善・スループット向上・運用課題の解消といった効果につながりました（数値は末尾）。 リプレイスに至った背景 誤解のないよう先に述べておくと、旧基盤の設計が「悪かった」わけではありません。2020年当時、ZOZOのデータ基盤はまさに拡大していくフェーズにあり、リアルタイム連携の需要も増え始めたばかりでした。そうした状況では、プラグインが豊富なfluentdとDataflowのように既存のツールを組み合わせて素早く構築できる構成は合理的な選択だったかと思います。実際、信頼性（データ欠損が起きないこと）は チェックポイント機構 などによって担保できており、長く運用されてきました。チェックポイント機構は、処理済みのChange TrackingバージョンをBigQueryに保持する仕組みです。Pod再起動時はそこから再開できます。 顕在化してきた課題 一方で、運用を続け、データ量や利用要件が増えていく中で、 効率の側面 でいくつかの課題が徐々に顕在化してきました。 メモリ効率 ：結果セットを一括でメモリに載せる実装のため、メモリ使用量がデータ量に比例して増加する構造でした。大量更新時のOOMを避けるためには「ピーク時のデータ量」を見越した大きなメモリを常時確保しておく必要があり、データ量が増えるにつれてリソース見積もりの難しさが目立つようになってきました。 コスト ：上記のメモリ確保がそのままコストに直結します。メモリがトランザクション単位のデータ量に比例する構造であるかぎり、「ピーク時のデータ量」の見積もりを下回るとOOM直行となります。そのため運用上の工夫（時間帯別のスケーリング等）では本質的な改善が難しく、リソースの常時確保によるコスト増を抱え続けるしかありませんでした。 性能 ：逐次処理ベースの実装のため、1トランザクションあたりの規模が大きいテーブルでは、リアルタイム性を保ちにくい場面もありました。 運用 ：依存していたコンテナイメージがEOLを迎えており、継続利用にリスクがありました。加えて、内部状態の可視性が低く、障害発生時の原因特定にも時間がかかる状況でした。 一言でまとめると、各所でガタが出始めており、信頼性を維持したまま効率（メモリ・スループット・コスト）の側面を改善するため、リプレイスを検討するタイミングに来ていた、ということです。 新基盤アーキテクチャ 設計の軸 新基盤の設計指針はシンプルで、 キャパシティプランニングの軸を「ピーク時のデータ量」から「単位時間あたりの処理量」に変える ことに尽きます。信頼性（データ欠損が起きないこと）は旧基盤からチェックポイント機構によって担保されており、新基盤でもそのまま引き継いでいます。そのため本記事のテーマは 信頼性を維持したまま、効率（メモリ・スループット・コスト）をどう改善したか です。 技術選定：Fluent Bit + Goプラグイン 今回のリプレイスは、前フェーズ（2024年のDataflow撤廃 + BigQuery Subscriptionへの切り替え）の延長線上にあります。前フェーズで Dataflow関連の費用がまるごと不要になり大きなコスト削減は既に達成済み で、下流（Pub/Sub HubとBigQuery Subscription）も整理されている状態でした。一方でETL層はfluentdベースのまま残っており、メモリ効率とスループットの面で課題が顕在化していたため、今回はその続きとして ETL 層の中身を作り直す ことにしました。下流はそのまま踏襲し、ソース側（Change Tracking設定）にも手を加えません。 このスコープと、既存のPub/Sub Hub構成・BigQueryテーブル設計を維持する制約のもとで、マネージドCDCサービスやOSSのCDCミドルウェアの活用も検討しました。ただし我々のケースでは、既存テーブル設計とPub/Sub Hubへの直接出力をそのまま組み合わせ続けられる選択肢を見つけられず、プラグインとして実装する形に決めました。 採用したのは Fluent Bit + Goプラグイン です。決め手は次のとおりでした。 既存基盤がfluentdベースで運用されていたため、Fluent Bitへの移行が素直 ：プラグインモデル・設定構造・デプロイ手順といった運用ノウハウがそのまま活きる INPUT（Change Tracking取得）とOUTPUT（Pub/Sub送信）の挙動を 自分たちで細かく調整できる 。後述の非同期ACK並列確認のような最適化も、プラグインとして自前で書いているからこそ仕込める Fluent BitのBuffer・バックプレッシャー機構をそのまま活用できる Goプラグイン公式サポートにより、後述する並列処理をgoroutineとchannelで素直に書ける 全体構成 以下の図は主要コンポーネントのみを示した簡略図です。 ETL層（Fluent Bit + Goプラグイン）はGKE上で動作します。プラグインは データ取得（INPUT） と Pub/Subへの送信（OUTPUT） の2つで構成されており、それぞれの実装の詳細は次章で扱います。 大量のデータをリアルタイムで捌くために考えたこと 新基盤の設計で常に意識していたのは、「 大量のデータをいかにリアルタイムで捌くか 」という問いでした。データ量が増えてもパイプラインが詰まらず、メモリ消費がデータ量に比例しない構造をどう実装するかを検討しました。前章で述べた「単位時間あたりの処理量を軸にする」方針を、Fluent Bitのパイプライン上に乗せて具体化していった話を、本章で紹介します。 なお、Fluent Bitのパイプライン構造の全体像については、 公式ドキュメント もあわせてご覧ください。 新基盤の構成 Fluent Bitのパイプライン構造はINPUT → Filter → Buffer → Router → OUTPUTという形です。新基盤ではこのうち INPUTとOUTPUTをGoプラグインで実装 しました。チャンク単位の処理やバックプレッシャーといったBuffer周りの機構はFluent Bit Engineが標準で備えています。そのためプラグイン側は INPUTとOUTPUTの"箱の中"の設計に集中できました 。 設計の出発点として、データ取得から送信までの各処理を「どこがボトルネックになるか」で整理し、並列化方針を決めました。 処理 特性 並列化方針 CT取得（クエリ → カーソル） I/O bound（DB側） 単一スレッド（DBがボトルネック） エンコード CPU bound Worker数で並列化 Pub/Sub Publish I/O bound（NW） 非同期APIで並列化 ACK確認 I/O bound（NW待ち） 別Workerプールで並列化 CPU boundとI/O boundを別レーンに分け、それぞれを独立した並列度で動かす設計です。以下、INPUT内部・OUTPUT内部の順で紹介します。 INPUT内部：取得とエンコードを分けた INPUT内部の設計では、メモリとCPUを独立した軸として扱えるようにしました。 メモリの設計 ：結果セット全体を展開せず、 カーソルで小分けに読み進める方式 を採用。1回のクエリで読むレコード数 RecordsPerChunk をプラグインの設定で指定でき、本番では 10,000件/チャンク CPUの設計 ：取得処理とエンコード処理を 別レーンに分け 、エンコードは複数のWorkerで並列実行 取得とエンコードの間に 中間キュー（jobs queue） を挟むことで、取得側はエンコードの完了を待たずに次のチャンクを先行投入できます。キュー容量がゼロだと直列に戻ってしまうため、本実装では jobs queue の容量をWorker数の5倍 に設定しています。 この構造のもとで、同時にレコード形式でメモリに乗るチャンク数は NumWorkers × 6 個で頭打ちになります。内訳は「jobs queue上の最大 NumWorkers × 5 個 + 各Workerが処理中の1個」です。 同時メモリ上のレコード数 = RecordsPerChunk × (jobs queue + 処理中 Worker) = RecordsPerChunk × (NumWorkers × 5 + NumWorkers) = RecordsPerChunk × NumWorkers × 6 = 10,000 × NumWorkers × 6 例えばNumWorkers = 2なら、データ量に関わらず常に約12万レコード分のメモリしか確保しなくて済みます。100万件規模のトランザクションが流れてきても、結果セット全体を一括ロードしてしまう旧基盤と違ってOOMにはなりません。 なお、Fluent Bit上でカーソル方式を実装するときには工夫が必要でした。Fluent BitはINPUTに対して定期的に「データをちょうだい」と呼び出してくる構造になっており、素朴に書くと毎回新規にクエリを発行してしまいます。それでは結果セットが毎回頭から読み直されてしまうため、 カーソル状態をプラグイン側に持ち越し、呼び出しごとに「続きから」読み進める ようにしました。 OUTPUT内部：送信とACK確認を分けた OUTPUT内部では、 送信処理とACK確認処理を別レーンに分離 しました。Pub/SubのPublishは同期的に書くと「送信 → ACK待ち → 次へ」と直列化してしまい、ACK待ちのネットワークI/Oが支配的になります。これだとスループットがACKレイテンシに律速されてしまうため、両者を分離して並列化する方針を取りました。 送信側 ：非同期APIを呼んで即座にFuture相当の結果を受け取り、次へ進む。送信そのものは止まらない 確認側 ：受け取ったFutureのACK確認専用のWorkerプールを設け、複数並列で確認する 各メッセージが独立したACKタイムアウトを持つようになり、1件の遅延が後続全体を巻き込む連鎖タイムアウトを構造的に防げるようになりました。 このパターンはPub/Subに限らず、Future / Promiseを返す非同期メッセージングSDKで同様に当てはまる考え方です。 送信そのものではなく、ACK確認の方をスケールさせる という発想を、我々のケースでは設計時に組み込みました。 なお、下流の詰まりに対する保護（バックプレッシャー）はFluent Bit標準の機構が動いており、OUTPUT側で詰まったときにINPUTを自動で止める仕組みが標準で得られています。これがあるおかげで、プラグイン側は「並列にどんどん投げて確認する」シンプルな構造に保てました。 結果 前章で述べたカーソル方式により、メモリ消費はデータ量に依存しなくなりました。prd環境では、ETL Podを載せているGKEクラスタのTotal Memoryが 約240GiBから約40GiBへ、約1/6にまで縮小 し、ETLのGKEコストは約 -66％ 下がりました。 環境 リプレイス前 リプレイス後 削減率 prd $2,800 $940 -66% stg $3,200 $1,100 -67% 合計 $6,000 $2,000 -67% （2025年11月実績、ETLのGKEコストのみ・定価ベース） 注：stgはprdよりテーブル数が多く（stgは約500、prdは約400）、絶対額も大きくなっています。 性能面では、逐次処理からWorkerプールによる並列処理へ切り替えました。Worker数を変えるだけでスループットの線形拡張が可能な構造になりました。旧基盤では一部の大規模テーブルで遅延が長くなりやすく、監視の閾値を最大40分まで緩めて運用していました。新基盤では、全テーブル一律10分以内の閾値で安定処理しています。 運用面では、Fluent Bit標準のメトリクスにより内部状態が可視化されました。 fluentbit_input_records_total や fluentbit_output_retries_total などの指標を、GKEのMetrics Explorerから確認できます。実際、リプレイス後に予期せぬ問題が起きた際も、 fluentbit_output_retries_total の急増から原因を切り分けてデバッグできました。また、プラグインを自前で実装しているため、コアな部分まで踏み込んだ調査・修正も可能です。依存していたコンテナイメージのEOLリスクから解放された点も、得られた効果です。 今後の展望：Change Data Captureへの移行 現在はSQL Serverの Change Tracking (CT) を使っていますが、CTは「その行が変わった」ことは検知できても、変更前後の値や中間の変更履歴までは取得できません。 一方、SQL Serverには Change Data Capture (CDC) という、変更の全履歴を捕捉する機能もあります。今後はこのCTからCDCへの移行を視野に入れています。履歴を全て取得できれば、変更前後の差分分析や任意時点の状態再現など、分析側のユースケースを広げられます。 まとめ 本記事では、ZOZOTOWNのリアルタイムデータ連携基盤のETL層を、Fluent Bit + Goプラグインで作り直した事例を紹介しました。リアルタイムデータ連携基盤の設計や運用に取り組む方の参考になれば幸いです。 ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com

はじめに NTT西日本の酒井です。本記事ではTableauという分析ツールの生成AI機能を触りながらデータ分析と生成AIの未来について考察します。内容は記事執筆時点(2025年12月16日)時点の情報に基づきます。 対象読者 この記事は以下のような人を対象に書いています。 Tableauと生成AIの連携に興味がある人 生成AIでデータ分析がどう変わるか考えたい人 背景 私はこの会社でデータ分析に関わる仕事に10年ほど携わってきました。ネットワークトラフィックの分析や社内でのデータ活用の推進、社内外のコミュニティ活性化、お客様向けのデータ活用・Tableau活用の支援などデータにまつわるさまざまな業務を行ってきました。しかし昨今では「生成AIの登場によってデータ分析やデータ可視化のスキルが生成AIに置き換わってしまうのではないか?」という言説にほんのりと不安になることがあります。そんな状況だからこそ生成AIは自分で触って使い道を考えていく必要があると考えていろいろ試してみましたので、その試行の記録と、その結果から考える生成AIとデータ分析の未来について考察したいと思います。 本記事の内容と目的 本記事ではTableauというデータ分析ツールの生成AI機能を試していきます。私のデータ分析のキャリアのほとんどにおいてTableauがメインツールだったので、最も使い慣れたこのツールの生成AI機能を試すことで生成AIがデータ分析、データ活用にどう役立つのかを考えていきたいと思います。 目次 Tableauとは?からはじまり、Tableau×生成AIのお試しをするための設定方法、実際に使ってみたレポート、考察という流れで進めます。 はじめに 対象読者 背景 本記事の内容と目的 目次 Tableauとは? Tableau MCPとは? Tableau MCPで利用可能な機能 今回の動作環境 Tableau MCPの導入方法 Tableau MCPを試してみよう! ダッシュボードの検索 ダッシュボードの使い方を教えてもらう データからビジネスの状況を教えてもらう Tableau MCPの使い所はどこか? データ分析と生成AIの未来 さいごに 商標 Tableauとは? まずTableauとはなんなのか簡単に説明します。Tableauは、使いやすい直感的なUI(ユーザーインタフェース)と豊富なビジュアル表現が特徴的なデータ分析のためのツールです。BI(Business Intelligence)ツールと呼ばれる分野のツールで、Tableau以外にもMicrosoftのPower BIや、Qlik社のQlik Sense、ウイングアーク1st社のMotionboardなどがあります。BI各社も生成AIの機能をリリースしていますが、今回はTableauの生成AI機能に絞って検証と考察をしていきたいと思います。 www.tableau.com Tableauでは本記事のテーマである生成AI機能の開発がとても活発です。2024年2月に登場した特定のKPIの動向を生成AIが要約してくれるTableau Pulseにはじまり、同じ年の夏にはデータ可視化をサポートしてくれるTableau Agentが、2025年には分析からアクションまでトータルにサポートしてくれるAIエージェントであるTableau Nextと、矢継ぎ早にさまざまな機能がリリースされています(これらの機能の詳細な説明は今回は割愛します)。 そして上記のTableauにビルトインされている機能以外にも、Tableau Langchain、Tableau MCPというオープンソースのプロジェクトも存在します。今回はこのうちのTableau MCPで何ができるのか?を試していきたいと思います。 Tableau MCPとは? 今年(2025年)の夏頃に公開されたオープンソースのプロジェクトです。生成AIに対してTableau ServerおよびTableau Cloudに格納されている情報にアクセスするためのスキルを提供します。ちなみにMCPとはModel Context Protocolの略で、Anthropic社が開発した生成AIのための標準規格のことです。生成AIが外部ツールやデータソースにアクセスするための共通プロトコルです。Tableau MCPはTableauの機能に生成AIがアクセスするための機能を提供しています。ちなみにAnthropic社はClaudeという生成AIを提供しています。 Tableau MCPについては以下のGithubリポジトリに詳しい情報があります。 github.com 前述の通りTableau Langchainという別のオープンソースプロジェクトもあるのですが、執筆時点(2025年12月16日)において最後の更新が5ヶ月前でありこちらの開発は最近は停滞している状況です。 Tableau LangchainのCommits over timeの画像 反面、Tableau MCPは執筆日(2025年12月6日)の4日前にも更新されており直近でも多くのCommitがなされています。 Tableau MCPのCommits over time おそらくTableauは注力領域をTableau LangchainからTableau MCPにシフトしているのだと思います。Tableau LangchainはLangchainというAIアプリ開発フレームワークでしか利用できませんがTableau MCPはオープン標準規格なのでClaudeやDifyなど多くのツールで利用できます。Tableau MCPに注力するのは自然な流れだと思います。 ということで本記事でもTableau MCPを使ってみて、使い道について考察をしていきたいと思います。 ちなみにTableau LangchainとTableau MCPについては、Tableauユーザー会のLT(ライトニングトーク)で私が発表した資料もありますのでよければご覧ください。 Tableau Langchain speakerdeck.com Tableau MCP(本記事はこの内容を肉付けしたものです) speakerdeck.com Tableau MCPで利用可能な機能 Tableau MCPでは以下の機能が提供されています。多いですがこの記事を読む上では覚える必要はありません。 Data Q&A:データソースの一覧やメタデータの取得やクエリを投げることができる List Datasources Get Datasource Metadata Query Datasource Workbooks:ワークブック(Excelブックのようなもの)の情報を取得できる List Workbooks Get Workbook Views:ビュー(Excelのシートのようなもの)の情報を取得できる List Views Get View Image Get View Data Pulse:Tableau Pulse関連の機能。今回は取り扱いません。 List All Metric Definitions List Metric Definitions List Metrics for Definition List Metrics List Metric Subscriptions Generate Insight Bundle Generate Pulse Insight Brief Content Exploration:Tableau ServerおよびTableau Cloud上のコンテンツ(ワークブックやデータソース)を検索できます Search Content 今の所、Tableau ServerおよびTableau Cloud上のワークブックやデータソースの情報を取得する機能が提供されていますが、ダッシュボードを作ったりグラフを作る機能は提供されていません。 Tableau MCPの機能は基本的にTableau ServerおよびTableau Cloudで提供されているAPIに依存してます。APIが提供されているものについてはTableau MCP側に機能追加される可能性がありますが、APIがないものはなかなか機能追加されないと思います。ダッシュボードやグラフの作成については現時点でAPI自体が提供されていないため実現には時間がかかりそうです(要望は多いと思うのですが)。 今回の動作環境 今回は以下の構成で検証を進めます。Tableau Cloud以外はローカル環境で実行します。 各ツールのバージョンは以下のとおりです。 macOS: Sequoia 15.5 Claude Desktop: 1.0.1768 Claudeのモデル: Opus 4.5 Tableau MCP: 1.10.3 Tableau Cloud: 2025.3.0 今回の実行環境の概要 Tableau MCPの導入方法 導入方法はとても簡単です。 1. Tableau ServerもしくはTableau Cloudを用意する 個人で準備するのは難しいと思われると思いますが、Tableau Cloudであれば検証用にDeveloperサイトを無料で開設できます。以下の記事を参考にぜひ試してみてください。簡単ですよ。 note.com 2. パーソナルアクセストークン(PAT)を作成する 以下の手順でPATを作成することができます。シークレットは1度しか表示されないのでメモ帳などにコピペしておいてください。 PATの作成方法 3. Claude DesktopにTableau MCPをインストールし各種設定をする 以下のとおりClaude Desktopの拡張機能として簡単にTableau MCPをインストールできます。 Claude Desktopの設定から拡張機能を参照する Tableauと検索するとTableau MCPが出てくる Tableau MCPをインストールする Tableau ServerもしくはTableau Cloudに接続するための設定をする PAT nameに先ほど作成したPATの名前を、PAT Valueにシークレットを入力してください。 これで準備OKです!早速試していきましょう。 Tableau MCPを試してみよう! 以下のユースケースを想定して実際に動作を確認していきたいと思います ダッシュボードの検索 ダッシュボードの使い方を教えてもらう データからビジネスの状況を教えてもらう ダッシュボードの検索 Tableau Cloudには多くのダッシュボードが掲載されていると、自分に関係のあるダッシュボードを探すのも一苦労です。そこで生成AIの力を借りましょう まずはTableau Cloudに掲載されているダッシュボードには何があるかを聞いてみましょう。 Tableau MCPを使ってダッシュボードを聞いてみた図 List Workbooksの機能を使って3つのワークブックがあることを教えてくれました。これらはTableau Cloudにデフォルトで格納されているサンプルワークブックです。それぞれどういう内容なのか知りたいのでURLも聞いてみましょう。 URLも聞いてみた図 新たにTableau MCPの機能を使うことなくURLを提示してくれました。すでにURLの情報は取得していたようです。実際にリンクをクリックすると当該ワークブックにアクセスすることができました。 では自分の興味のあるダッシュボードを探してもらいましょう。売上に関するダッシュボードがないか聞いてみます。 売上に関するダッシュボードを探してもらう するとSearch ContentとGet Workbookを使って関連するダッシュボードを探してくれました。Superstoreというワークブックに入っている具体的なビュー(ダッシュボードに当たるもの)の説明もつけてくれています。 Overviewというビューをみれば売上の全体概要が掴めそうなので、OverviewのURLを聞いてみましょう。 OverviewのURLを教えてもらう 無事教えてくれました。アクセスしてみましょう。 Overviewのダッシュボードの画面 Superstoreという架空の小売店の売り上げをまとめたダッシュボードが表示されました。自分の興味に合致するダッシュボードを探すことができました。なかなか使いやすいですね。 ダッシュボードの使い方を教えてもらう ダッシュボードの使い方も慣れるまでは難しいものです。なのでダッシュボードの使い方も生成AIに聞いてみましょう。 使い方を聞いた結果 Get View Imageという機能を使ってダッシュボードの画像を取得し内容を解析しているようです。ダッシュボードの構成を説明した上でフィルターを切り替えてみたいデータを見る方法も提示してくれています。ここまで説明してくれれば初めて見る人でも使い方をイメージしやすそうですね。 データからビジネスの状況を教えてもらう とはいえダッシュボードを触りながらデータを深ぼっていくのも慣れない人からするとハードルがあつかもしれません。なのでこのダッシュボードで使われているデータを使ってデータ分析をしてもらいましょう。架空の設定として私はCentral Regionの責任者であり、Central Regionについて他のRegionと比較した良いところ悪いところを生成AIに提示してもらおうと思います。 分析依頼の結果(1) List DatasourceとGet Datasource Metadataを使ってデータソースの基礎情報を取得しています。その後Query Datasourceにてクエリをいくつか投げて分析を行っています。どんな結果が返ってきたのでしょうか。以下がこの続きです。 分析依頼の結果(2) 売上、利益だけでなく利益率や顧客数、割引率までに着目してサマリーをまとめてくれています。また具体的にCentral Regionの良いところをいくつか示してくれています。では課題についではどうでしょうか? 分析依頼の結果(3) 割引率が高いせいで利益率が低いこと、どのサブカテゴリーの商品の利益率が特に低いのか、具体的な州についても触れてくれています。また2024年に利益が急落したという大きな変化も示してくれています。なかなか良い分析をしてくれていそうです。どう改善すれば良いのでしょうか?それも提案してくれていました。 分析依頼の結果(4) かなり具体的かつ定量的な目標も含めて提示してくれています。最近の生成AIの優秀ぶりには本当に驚かされます。 せっかくなので最終的なアクションにも繋げていきましょう。州や製品の担当者に指示を出しましょう。 メール文案作成依頼の結果 各担当者向けのメール文案を細かく作成してくれました。これは想像以上の結果でした。シンプルにClaude Opus 4.5の性能に驚きました。 メール文案作成結果の一部 かなり具体的な指示を丁寧に書いてくれています。内容のクオリティについては精査が必要とは思いますが、ダッシュボードの検索からメール文案作成までの一連の作業はこの記事を書きながら約30分で実施できました。すごいスピード感だと思います。データ分析者の仕事はなくなってしまうのか不安になってしまいますね。 Tableau MCPの使い所はどこか? これまでみた通りTableau MCPではデータ分析に詳しくない人でも、自然言語を使ってデータから気づきを得ることができそうなことが見えてきました。ではダッシュボードは不要になるのでしょうか?おそらくそうではないと思います。ダッシュボードはビジネスを実施する上での健康診断のようなもので、定期的に同じ数値を確認し自分たちのビジネスや施策が予定通りうまく進んでいるのか、課題がないのかを見つめ直すために使います。こういった数値は生成AIに都度聞くのではなくダッシュボードとしてまとめておいた方がチーム全体での統一的な見解を持つことができると思います。Aさんが聴いた結果とBさんが聴いた結果がもし異なっていたら議論が食い違ってしまいますよね。ではTableau MCPのような生成AI機能は何に使えばよいのでしょうか? 大きく二つの用途が考えられると思います。 - データに触れるきっかけを作る - ダッシュボードではわからない質問をする 前者はさきほどの「試してみよう」の章でみてきたようなゼロからデータに触れるためのきっかけを作る用途です。ダッシュボードを見たり、データ分析者に質問をするのは多少のハードルがあるものです。ダッシュボードはどこにあるんだろう、下手に触って壊したら怖い、データ分析者にこんなこと聞いて恥をかかないだろうか、そんなハードルは生成AIであれば皆無です。気軽に生成AIに気になる情報を聞いてもらってデータで何がわかるのかを掴んでもらうのにはとても良いと思います。 後者はデータ活用がより成熟してきてダッシュボードによるデータ活用ができている状態において、スピード感が求められる調査に活用できます。会議にてダッシュボードをみながら利益率の低下といった課題が見えてきました。ではその要因はなんなのか分析したいがダッシュボードで用意された切り口以外の分析はできません。Tableauに慣れた人であれば、データ可視化機能を使って別の切り口での分析を行うことも可能、普段ダッシュボードを見るだけの人にはなかなか難しいです。そんなときでも生成AIを使えばすぐに質問をして、課題のあたりをつけていくことができます。それらしい仮説がうまれたら分析ができる人により詳細な分析を依頼することもできるでしょう。 いずれにしてもデータ分析のスキルが高くない人がデータを活用する入り口になると思います。 データ分析と生成AIの未来 Tableau MCPを試してみた感じたのは「生成AIはこれまで以上に簡単にデータに触れられる新しいユーザーインタフェース」だと感じました。これはBI登場の歴史にも似ていると思います。昔は基幹システムにバンドルされている分析機能やデータ出力機能を使っていて、求められる技術力も高く一部の人しかデータ分析はできませんでした。BIの登場により簡単にデータを分析できる環境が生まれ、より多くの人がデータ分析をできるようになりました。これにより現場で業務を回している人がみずからデータを見た判断がしやすくなりました。しかし簡単になったとはいえそれでも一定の基礎リテラシーやトレーニングが必要ではありました。しかし生成AIであれば同僚や部下に質問をするように自然言語で質問することで欲しいデータを得ることができます。これであればデータ活用のハードルをかなり下げることができます。この簡単さこそが生成AIによるデータ分析が生み出す価値だと思います。 ただしこの価値を享受するには大きな壁もあります。それはデータの整備です。BIを広めていく上でもデータ整備は大きな壁でしたが、生成AIではさらに大きな障壁となります。BIを使う際は人がデータを見て誤りを検知したり、修正するフローを組んだりすることができました。しかし生成AIにそれができるでしょうか?現時点では分析者ほどの精度では実現できないと思います。そのためAIが使いやすいデータを整備することの重要性が高まります。実際にそういった議論がさまざまなところで行われています。生成AIのためにデータ整備が進めばBIを使ったデータ分析もしやすくなるので、この生成AIのブームに乗って日本中のデータ整備がすすむことを願います。 さいごに 本記事ではTableau MCPを使って生成AIとデータ活用の未来を考えました。最初の疑問であった「生成AIの登場によってデータ分析やデータ可視化のスキルが生成AIに置き換わってしまうのではないか?」についてはどうでしょうか?現時点ではすぐに置き換わることはなさそうです。ポイントはデータ整備とドメイン知識です。やはりデータの整備やメタデータ(データの各列の意味などをまとめたデータ)の整備がなされていないと生成AIも正しくデータを見ることができません。また職場それぞれにある特有の商習慣やドメイン知識をとらえるのもまだ難しいでしょう。しかし今後データの整備が進み、生成AIに職場独自の知識を与え、生成AIの精度も高まっていけば生成AIが置き換えられる領域は増えていきそうです。とはいえ今回Tableau MCPを触ってみて思ったのは不安よりもワクワクでした。やはり新しい技術が新しい価値を生み出す瞬間はワクワクします。データ分析人材として生成AIを脅威としてとらえることも重要ですが、それ以上に新たな武器として使いこなしていきたいなと思いました。生成AI時代のデータ分析者としての自分らしい強みを見つけていきたいと思います。最後までお読みいただきありがとうございました。 商標 「Tableau」「Tableau Cloud」「Tableau Server」「Tableau Pulse」「Tableau Agent」「Tableau Next」は、Salesforce, Inc.の商標または登録商標です。 「Microsoft」「Power BI」は、米国Microsoft Corporationの商標または登録商標です。 「Qlik」「Qlik Sense」は、QlikTech International ABの商標または登録商標です。 「MotionBoard」は、ウイングアーク1st株式会社の商標または登録商標です。 「Claude」は、Anthropic, PBCの商標または登録商標です。 「Mac」「macOS」は、米国Apple Inc.の商標または登録商標です。 「Dify」は、LangGenius, Inc.の商標または登録商標です。 「LangChain」は、LangChain, Inc.の商標または登録商標です。 「GitHub」は、GitHub, Inc.の商標または登録商標です。

こんにちは、Data Groupのデータアナリストをしている加藤です。 2024年10月1日よりLuupで働き始め、早くも3か月以上が経過しました。（諸事情により公開が遅れました） 今回はLuupを転職先に選んだ理由と、データアナリストとしての日々の業務についてお話しします。 前職について 新卒で金融機関に入社し、2年半にわたり自治体向けのキャッシュレス決済プロジェクトのデータ分析やデータ関連の事務を担当しました。 1～2年目では、事業の理解を深めながら、BIツール（Tableau・Qlik Sense）を使って、決済状況や予算の進捗状況のダッシュボードや顧客向けレポートの作成をしま