はじめに：データエキスパートのボトルネックを超えて
Spotifyは、数千のチームが高速で動く環境において、データインサイトの需要がすでに専門家の処理能力を超えているという問題に直面していました。「データが必要なら関連ダッシュボードを探すか、該当ドメインの専門家にSlackでメッセージを送って待つ」という従来の方法は、もはやスケールしませんでした。
この問題を解決するためにAIデータアシスタントを開発しましたが、7万以上のデータセット（ペタバイト規模）を単純にLLMに投入する方法は通用しませんでした。コンテキストウィンドウの制限も問題でしたが、より根本的な理由は スキーマだけではデータの意味を伝えられないからです。
例えば、
INT64型のカラムがあるとしましょう。その値のうち100未満はレガシーテストデータであるという事実、'アクティブユーザー'の定義がチームごとにどう異なるか、スキーマは決して教えてくれません。
Spotifyが選んだ解決策は 「コンテキストレイヤー (Context Layer)」 でした。データウェアハウス全体ではなく、実際に重要な断片を、そのドメインを最もよく理解している人がキュレーションする中間層を作るというものです。このアーキテクチャは、Spotifyアプリリリースの舞台裏ダッシュボード設計と自動化の教訓で扱った自動化の哲学とも共通しています。
Vedder：Spotifyのデータアシスタント
Spotifyはこのデータアシスタントを Vedder と名付けました。2025年8月から実際に運用されており、現在2,100人以上のSpotify社員が13,000回以上の会話、60,000以上のメッセージをやり取りしながら使用しています。驚くべき点は、ユーザーの4分の1以上がSQLを一度も書いたことがない人たちだということです。
動作の仕組み
- ユーザーが自然言語で質問を入力します。
- エージェントが適切なコンテキスト（クラスター）を選択します。
- SQLクエリを生成し、ウェアハウスで実行します。
- 結果とともにクエリ、出典を返します。
Vedderは ReAct (Reasoning + Acting) ループに従います。一段階ずつ推論し行動し、各ツール呼び出しの結果に応じて調整します。ユーザーは結果だけでなく、その結果がどのように作られたかを透明に見ることができます。
インターフェース
- Slackボット: スレッド内でのクイックな質問
- MCPサーバー: IDEやAIツールとの連携
- 専用Web UI: インタラクティブな探索
もしあるトピックをカバーする知識ベースがなければ、データアシスタントはその事実をユーザーに伝えます。この透明性が、回答の信頼性を高める核心です。
核心アーキテクチャ：クラスターモデル
Spotifyはデータドメインを クラスター (Cluster) と呼びます。各クラスターは特定のイニシアチブ、組織、またはアドホックな関心に結びつけることができ、以下の3つの構成要素から成ります。
1. データセット (Datasets)
関連データウェアハウステーブルの完全なスキーマとプロファイリング情報を含みます。単なるカラム名や型を超え、カーディナリティ（ユニーク値数）、サンプル値、パーティション構造までキャプチャします。例えば country カラムに 'US', 'GB', 'SE' といった値が入っている事実をモデルが知っていれば、WHERE句をより正確に生成できます。
2. ペア (Pairs)
検証済みの質問-SQLペアです。これがデータアシスタントの フューショット (Few-shot) メカニズム です。ドメインエキスパートが各ペアを承認するか直接作成し、同僚が従うべきパターンを教えます。これらのペアは、LLMに対して「このデータをどのようにクエリし、意味を解釈すべきか」を教える教科書の役割を果たします。
3. ドキュメント (Docs)
追加のビジネスコンテキストです。用語の定義、注意点 (Gotchas)、チームごとに異なる定義、使用すべきカラムと避けるべきカラムなどが含まれます。例えば'アクティブユーザー'の定義がAチームとBチームで異なるなら、その違いを文書化します。
キュレーションの重要性：12.5%の法則
Spotifyはある実験を行いました。データウェアハウスに保存された全クエリ履歴から質問-SQLペアを自動生成し、クラスターキュレーターに「この中から良い例を選んでください」と依頼しました。
結果は衝撃的でした。わずか12.5%しか承認されませんでした。
残りの87.5%は：
- 一回きりの探索クエリ
- デバッグセッション
- 間違ったテーブルを使用したクエリ
- 技術的には正しいが、間違ったパターンを教えるクエリ
クエリ履歴はほとんどがノイズ (Noise) です。 シグナル (Signal) は自分でラベルを付けません。だからこそ、すべての例は専門家のレビューを経る必要があります。モデルはコンテキストの上で推論するだけで、データについて「何が真実か」を決定しません。その役割はドメインエキスパートのものです。
この方法は専門家を置き換えるものではありません。彼らの専門性をよりスケーラブルな方法で提供するものです。
クラスターの健全性管理：ヘルススコア
データは変わり、ビジネスロジックは変わり、先月正確だったコンテキストが今日は間違っていることがあります。スキーマが進化し、カラム名が変わり、テーブルが廃止されます。Vedderが継続的に正確な情報を提供するには、常時監視が必要です。
各クラスターは ヘルススコア (Health Score) で管理されます。ヘルススコアは以下のようなシグナルを総合して計算されます：
- 基盤データの健全性: クラスターが参照するデータの品質
- ペアの有効性: 最近のスキーマ変更後もキュレーションされたペアが有効か？
- カバレッジ: コンテキストがユーザーが実際に尋ねる質問をよくカバーしているか？
- 再現性: 生成されたSQLが再現可能か？
ヘルススコアが低下するとダッシュボードにシグナルが表示され、キュレーターに改善アクションが提案されます。
フィードバックループ：閉じた循環
すべてのVedderとの会話はシステムにフィードバックされます。Vedderはすべての会話とクエリをログに記録し、質問、回答、生成されたSQL、ユーザーフィードバックをクラスターオーナーに表示します。これはデータサイエンティストの知識をスケーリングする方法です。彼らが承認したすべての質問-SQLペア、明確にしたすべてのドキュメントは、次のユーザーがより正確なインサイトを得ることに貢献します。
この技術の限界または注意点
- コンテキストキュレーションのボトルネック: 依然として人間の専門家の時間が必要です。自動生成されたペアの87.5%がノイズであるという事実は、完全自動化が難しいことを意味します。
- スキーマ外部の知識: 現在のアーキテクチャは主にスキーマと構造化されたドキュメントに依存しています。組織内のプロセス定義や非構造化ドキュメントにある知識はまだ完全にはカバーできていません。Spotifyもこの部分を次の課題としています。
- 拡張性と正確性のトレードオフ: クラスターが多くなりすぎると管理負担が増大します。適切なクラスター分割戦略が重要です。
次のステップ学習の方向性
- ReActパターンについてさらに学ぶ: arXiv論文 Reasoning and Acting in Language Models はVedderの核心ループを理解するのに必須です。
- フューショットプロンプティングとコンテキストウィンドウ最適化戦略を学習してみてください。LLMがコンテキストを効果的に活用する方法を理解すれば、類似のシステムを自分で構築できます。
- データカタログツール（例：Apache Atlas, Amundsen）とデータ品質モニタリングツールを併せて調べると、クラスターモデルを実際に実装するのに役立ちます。
Spotifyのアプローチが与える教訓は明らかです：AIの信頼性はモデル自体ではなく、そのモデルが見るコンテキストの品質に依存する。 データ専門家を置き換えるのではなく、その専門性をよりスマートに拡張する方法を考える時です。
このアーキテクチャをより深く理解したい方は、FunctionGemma、TPUで10分でファインチューニングする方法（Tunix + Colab実践ガイド）で扱うモデルファインチューニング手法と組み合わせると、より強力なデータアシスタントを構築できるでしょう。