こんにちは!株式会社データ・ワンでエンジニアをやっている曽根高です。
社内で利用しているダッシュボード基盤のTableauからDatabricks Apps(AppKit)への移行を進めています。
きっかけは「Tableau の手作業を AI で減らせないか」という試みです。
弊社では、開発の大部分でClaude CodeやCodexといったAIを活用した効率化が進んでいますが、Tableauは手作業が残っており、開発のボトルネックになっていました。
結果的に、AIによるTableau作業の効率化は2回失敗して挫折しましたが、Tableauで抱えていたいくつもの課題をDatabricks Appsに乗り換えることで解決できることがわかりました。
ここからは、AIによるTableau作業の自動化を目指して試したことや、Databricks Appsへ移行することで得られたメリット・移行方法について具体的にお話ししていきます。
目次
- Tableau 運用がつらかった
- 試行1: Tableau のファイルを AIに直接編集させる
- 試行2: AIにTableauを読ませ、人間が操作するための手順を出させる
- 転機: Databricks Apps + AppKit
- Databricks Apps移行のメリット
- なぜAppKitなのか
- TableauからDatabricks Apps移行の手順
- まとめ
- 採用情報
Tableau 運用がつらかった
弊社はリテールメディア事業を行っており、商品の売り上げや購買者の属性情報といったリテールデータや、広告配信の効果レポートをTableau上で社内に公開しています。Tableauのワークブックの数は頻繁に参照されているものだけでも数十個、ワークブックのダッシュボードまで数えると数百個あります。これを開発チームで中央集権的に管理しており、Tableauの経験が豊富なメンバーが1人でほぼ全て対応するという状態が続いていました。
会社の成長に伴って、Tableauの改修依頼の数も増えていきます。一人で全て対応するのは難しくなっていましたが、私を含め他のメンバーはTableau初心者ばかりです。データを加工するフローもワークブックの作りも複雑で、作業依頼が来ても、まずどこを触ればいいのか読み解くだけで時間がかかる。読み解けたとしても、どう操作すれば作りたいものが作れるのかが分からない。変更のたびに調べて、試して、やり直す、という状態でした。
また、ワークブックが参照するデータ量が多いことや計算フィールド等を多用していることなどが原因で、Tableauが編集中に固まって何もできなくなってしまうようなことが頻繁に発生しており、手作業でのTableau運用に限界を感じていました。
当時、Claude Codeで開発の大半を回すようになっていた私はAIに任せられないかと考えました。
試行1: Tableau のファイルを AIに直接編集させる
Tableau Cloudで公開しているワークブックはダウンロードするとtwbxファイルというものになります。.twbx はZIP形式のパッケージで、展開するとワークブック定義を持つ .twb ファイルなどが含まれています。.twb はXMLで記述されているため、これならAIで解析・編集できるのではないかと考えました。そこで、Claude Code に twbx を渡してグラフなどの編集を指示しました。
しかし、結果は散々でした。
一部の作業では成功したものがあったものの、ほとんどの作業はうまくいきませんでした。AIは色を変えたと報告しているがTableau Desktopで開くと変わっていない。グラフの編集を依頼すると、Tableau Desktop が内部エラーを出してファイルが開けなくなるなど、正直使い物になりませんでした。

試行2: AIにTableauを読ませ、人間が操作するための手順を出させる
AIに丸投げする方式ではうまくいかなかったため、方針を変えました。AIにファイルを編集させるのはやめて、読ませるだけにする。やりたいことを伝えると、AI が XML から対象要素を特定し、Tableau Desktop での操作手順を返す。それを参考に人間が手作業でTableauを編集する。作業後は編集前のバックアップファイルと編集後のファイルをAIに比較させ、意図した変更だけが入ったか確認する。これをAgent Skillsとして仕組み化しました。
これは一定の効果がありました。AIに作業手順も教えてもらえるので初心者でも作業できる。変更の取りこぼしや意図しない変更も差分(diff)で見つかる。
ただ、限界もすぐ見えました。ひとつは、AIにも分からないケースがあること。AIに提示された手順通りにやっても、思ったような結果にならない。何度もAIとやりとりし、結局解決しないということが起こりました。Opus4.7 max effortが匙を投げ、「申し訳ありません。これが私の限界です」とまで言わしめることもありました。
もうひとつは、結局PCを操作するのは人間なので、作業があまり速くならないことです。AI が正しい手順を出しても、人間の作業スピードがボトルネックになります。さらに、冒頭にも書いたように編集のたびに数十秒待たされることもあるため、かなり非効率な作業になっていました。
結局、難易度の高い改修はTableauが得意な人に頼むことになり、開発のボトルネックが残ったままになりました。
ちなみに、AIが匙を投げた改修要望は、Tableauが得意な人がやるとすぐに対応完了しました。
AIによるTableau運用自動化の試みは失敗に終わりましたが、その過程で生み出されたTableau編集前後のdiffを確認するスキルは、レビューにおいて今も活用されています。
TableauはGUIで操作するため、改修後のチェックは人の目で実施していましたが、抜け漏れや意図しない変更の見落としなどが発生することがありました。今回作成したスキルを利用すると、変更したポイントを機械的に洗い出すことができ、レビューの精度向上に役立っています。
転機: Databricks Apps + AppKit
弊社ではデータ基盤としてDatabricksを利用していますが、Databricks Apps上でWebアプリケーションを構築するためのTypeScript SDKであるDatabricks AppKitが2025年末に公開されていたので、これを試してみることにしました。
Databricks Apps は、Databricks のワークスペース上で Web アプリをホストする機能です。Databricks AppsはDatabricks上のサーバーレス環境でホストされ、OAuthやUnity Catalog、Databricks SQLなどと統合されています。別途Webアプリのホスティング基盤や認証基盤を構築する必要がありません。データアクセスにはアプリ専用Service Principalを使う方式と、ユーザー権限で実行するOn-Behalf-Of方式があり、SQL WarehouseやUnity Catalogへの必要な権限を設定して利用します。AppKit は、その上で動くアプリを作るための Node.js + React の TypeScript SDK で、SQL ファイルを置けばクエリと型が登録され、React コンポーネントから呼ぶだけでグラフや表が作れます。「Built for humans and AI」と公式のリポジトリにも書かれているように、 コーディングエージェントを利用した開発のガイドがあったり、Agent Skillsが用意されていたりと、AIコーディングを前提としたSDKになっています。
TableauのワークブックのDatabricks Appsへの移行を試してみました。
結果は上々で、Tableau初心者の私がTableauで実装するなら数週間かけても終わらないであろう複雑なワークブックを1日もかからず移行してしまいました。
Tableau のtwbxファイルとtflファイル(Tableauでのデータ変換を定義したファイル)、そして、Tableauの画面キャプチャを渡して「これを再現して」と指示し、できあがった画面を見ながら「バーの間隔をもう少し狭くして」など微調整の依頼をするだけで、十分な完成度のダッシュボードが出来上がりました。自分の手では一切コードを書いていません。
ここまでで、私はDatabricks AppKitを利用したDatabricks Appsへの移行は実行すべきだと確信していましたが、Tableauはこれまで使い込んできてそれなりに大きな基盤になっていて移行のコストがかかることもあり、移行の合意を社内で取り付けるには、具体的なメリットの提示が必要でした。
Databricks Apps移行のメリット
開発スピード
一番効果を実感しているポイントです。
Tableau初心者の私基準ですが、実装完了までの時間は格段に早くなりました。
また、Tableauの場合は最初から最後まで全て手作業なのに対して、Databricks AppsではAIに指示を出して、完成したものをレビューするだけなので、人間が拘束される時間で考えるとさらに短くなります。
システムのコスト
弊社が利用しているTableau Cloudの契約では、ユーザーに割り当てるライセンスをベースに費用が発生します。そのため、利用頻度が低いユーザーにも一定のコストがかかっていました。
一方でDatabricks Appsでは、Databricks Appsのコンピュートと、データ取得のためのSQLを実行するSQL Warehouseが主なコストになります。さらに、アイドル時にゼロまでスケールダウンする「Serverless Micro Apps」も発表されており、今後はより利用量に応じたコスト構造になることが期待できます。
まだ移行の途中段階のため、移行完了後の具体的なコストは出ていませんが、大幅にコスト削減できると試算しています。
パフォーマンス
弊社のTableauでは、大規模なデータをデータソースとして用意し、ワークブック内の計算フィールド等で集計を行うような実装になっていました。これにより、ユーザーがワークブックにアクセスしてからダッシュボードが表示されるまでや、タブを切り替えた時、フィルター条件を変更した時などに毎回長時間待たされるという状態になっていました。
これに対して、Databricks Appsでは複雑な計算や集計処理はすべてSQLに寄せてしまい、アプリ側は集計値だけを受け取り表示に専念するような役割分担をしています。
これにより、ページの表示や切り替えがサクサク動くようになり、ユーザーのストレスを軽減することができます。
これはDatabricks Appsそのものの性能差というより、移行を機に処理をSQL側へ寄せる設計に変更した効果が大きいです。
表現の柔軟性
Tableauで用意しているダッシュボードは社内のみの利用ではなく、クライアントへの広告配信結果のレポーティングにも利用されています。その際、広告の効果をわかりやすく表現するために、グラフ等の見せ方を細かく修正する依頼をもらったりしていました。しかし、Tableauでは表現不可能な依頼も中にはあり、その場合は、Tableauから出力した画像をパワポ上で図形などと組み合わせて実現するといった作業で対応していました。
対して、AppKitはReactで実装するため、通常のWebアプリケーションと同様に高い自由度でUIを作り込めます。これにより、ビジネスサイドからの細かい要望にも応えられるようになります。
Git管理できる
Tableau Cloud にもリビジョン履歴はありますが、残るのは直近10世代までです。
Databricks Appsはコードで実装するので、Git管理できます。この記事を読んでくださっている方はほとんどエンジニアだと思うので、いうまでもないことですが、Git管理できることは素晴らしいことです。変更は PR でレビューでき、履歴がすべて残り、いつでも過去の状態に戻せます。CIで型チェックやテストも回せます。
なぜAppKitなのか
Databricks でデータを可視化する選択肢は AppKit だけではありません。
AI/BI ダッシュボードもあるし、Databricks Apps 上では Streamlit や Dash といった Python フレームワークも動きます。
AI/BI ダッシュボードは、基本的には既定のビジュアルの組み合わせしかできませんが、Vega-Lite を利用すればカスタム可視化も可能です。しかし、Vega-Liteによるカスタム可視化は個々のビジュアルを作り込むための仕組みで、画面全体を自由に作り込む用途には向いておらず、クライアントに提出するレポートの作り込みには表現力が足りませんでした。
StreamlitやDashであれば、作れないことはありません。ただ、今回のようにTableauで作り込まれたレポートを細部まで再現しようとすると、既製コンポーネントの範囲を超えたカスタム実装が必要になり、シンプルに作れるというこれらのフレームワークの本来のメリットが活きなくなります。
そして何より、AIに作らせる前提なら AppKit が一番適していました。ReactベースでUIを自由に作り込めるうえ、AppKit自体もAI-assisted developmentを前提に整備されています。
AIに実装を任せて開発スピードを上げつつ、ビジネスサイドからの要望にきめ細やかに対応できるのはAppKitであると判断しました。
TableauからDatabricks Apps移行の手順
移行の手順そのものも、Agent SkillsにしてAIに任せています。
活用しているスキルは以下のような構成になっています。
AppKitへ移行したいTableauのワークブック名を指定してスキルを呼び出すと、以下の処理をAIが順番に実行します。
- AIがブラウザを操作し、Tableau Cloudからtwbxとtflファイルをダウンロードしてファイルの内容を解析する
- 引き続きAIがブラウザを操作し、Tableau Cloud上でワークブックを開いてタブごとにスクリーンショットを撮る
- tflのフローの定義やtwbxの計算フィールドをもとにSQLを生成する
- SQLを実行した結果が、スクリーンショットで撮った数値と一致しているか確認する。一致していなければ原因を調査しSQLを修正する
- twbxファイルの定義と、スクリーンショットをもとにグラフや表などのUIを実装する
- 実装が終わったらローカルサーバーを起動し、人間にレビュー依頼する
人間が手を動かすのは、事前にTableau Cloudにログイン、スキルを呼び出す、実装のレビューの3つだけで、移行作業の大部分をAIに任せることができています。

まとめ
AIにTableauを直接編集させたり、操作手順を生成させたりと試行錯誤しましたが、最終的にはTableauの運用そのものをAIで効率化するのではなく、AIが扱いやすいコードベースのDatabricks Apps + AppKitへ移行するという結論になりました。
移行によって、開発スピードだけでなく、パフォーマンス、表現力、Gitによる変更管理など、Tableau運用で感じていた複数の課題をまとめて改善できています。
GUIの操作を無理にAIへ任せるよりも、AIが力を発揮しやすい仕組みに変えてしまう。今回の取り組みで一番大きかったのは、この発想の転換でした。
採用情報
データ・ワンではエンジニア・プロダクトマネージャーを募集しております。
データ・ワンのエンジニアチームはまだまだ小さく、各メンバーが裁量を持って働けます。この記事に書いたDatabricks Appsへの移行のような、新しいことへのチャレンジができる環境があります。
興味を持たれた方は以下のリンクをご確認ください。