はじめに：データ専門家の悩みをAIで解決

Spotifyでは、データ分析の依頼は決まったパターンをたどっていました。関連ダッシュボードを探しても見つからず、Slackでデータ専門家にメッセージを送り、相手の都合がつくのを待つ。何千ものチームが高速で動く環境では、データインサイトへの需要は個人の専門家が対応できるレベルを超えていました。

この問題を解決するためにAIデータアシスタントの開発に着手しましたが、7万以上のデータセット（ペタバイト規模）を抱える環境で、単純にすべてのスキーマをLLMに入れる方法は通用しませんでした。コンテキストウィンドウは大きくても100万トークン程度で、データウェアハウス全体を収めるには全く足りません。さらに、スキーマだけではすべての情報を伝えられません。例えば、あるカラムがINT64型だからといって「100未満はレガシーテストデータ」という事実や「アクティブユーザー」の定義の違いまではわかりません。

Spotifyが選んだ解決策は 「コンテキストレイヤー」 でした。データウェアハウスの一部から実際に重要な情報だけをキャプチャし、そのデータを所有・理解するドメインエキスパートが管理する中間層を設けるというアプローチです。この方法は単なる技術的問題を超え、組織内のデータガバナンスと専門性の活用に関する深い洞察を提供します。

本記事はSpotify Engineering Blogの「Encoding Your Domain Expert」を基に、日本の開発者・データチーム向けに分析・再構成しました。原文はこちらからご確認いただけます。

Data analyst curating domain context for AI assistant in Spotify data platform IT Technology Image

Vedder：SpotifyのAIデータアシスタントアーキテクチャ

Vedder（Spotifyデータアシスタントのコードネーム）は2025年8月から運用が開始されました。現在2,100人以上のSpotify社員が13,000回以上の会話と60,000以上のメッセージをやり取りしており、広告、ポッドキャスト、音楽、オーディオブック、財務、クリエイターツールなど177のクラスター（ドメイン）をカバーしています。特筆すべきは、ユーザーの4分の1以上がSQLを一度も書いたことがない人々だという点です。

動作の流れ

ユーザーが質問を入力すると、Vedderは以下のプロセスを実行します：

  1. 適切なコンテキスト（クラスター）の選択
  2. SQLクエリの生成
  3. データウェアハウスへのクエリ実行
  4. クエリと出典とともに回答を返却

これはReAct（Reasoning and Acting）ループに従います。モデルが段階的に推論・行動し、各ツール呼び出しの結果に応じて調整します。ユーザーは結果だけでなく、結果がどのように生成されたかも確認できるため、透明性が保証されます。

インターフェース

Vedderはユーザーが既に作業しているサーフェスに組み込まれています：

  • Slackボット：スレッドでの会話中に素早く質問
  • MCPサーバー：IDEやAIツールとの連携
  • 専用Web UI：インタラクティブな探索

クラスターモデル：ドメイン知識のカプセル化

Spotifyはデータドメインを「クラスター」と呼びます。各クラスターは特定のイニシアチブ、組織、またはアドホックな関心事に結びつけることができ、3つの構成要素から成ります：

構成要素説明役割
データセット関連データウェアハウステーブル（全スキーマ＋プロファイリング）モデルがWHERE句生成時にカラムのカーディナリティ、サンプル値、パーティション構造を活用
ペア検証済みの質問-SQLサンプルペア（Few-shotメカニズム）ドメインエキスパートが承認したパターンをLLMに学習
ドキュメント追加のビジネスコンテキスト（用語、注意点、定義）チームごとに異なる定義や使用すべき/避けるべきカラムをガイド

このキュレーションはデータサイエンティストとアナリティクスエンジニアが担当します。彼らは自分のドメインをどうクラスターに分割するか、どのテーブルを含めるか、どのサンプルが重要かを決定します。

コアコード例：クラスターヘルススコアの計算

以下はVedderがクラスターの健全性を監視する方法を簡略化した疑似コードです：

# クラスターヘルススコア計算例（疑似コード）

def calculate_cluster_health(cluster):
    """
    クラスターのヘルススコアを計算します。
    複数のシグナルを組み合わせて総合スコアを算出します。
    """
    signals = []
    
    # 1. 基盤データの健全性
    schema_freshness = check_schema_freshness(cluster.datasets)
    signals.append(schema_freshness * 0.3)
    
    # 2. キュレーションされたペアの有効性
    valid_pairs_ratio = 0
    for pair in cluster.curated_pairs:
        if is_pair_still_valid(pair, current_schema):
            valid_pairs_ratio += 1
    valid_pair_score = valid_pairs_ratio / len(cluster.curated_pairs)
    signals.append(valid_pair_score * 0.4)
    
    # 3. ユーザー質問のカバレッジ
    coverage = measure_question_coverage(cluster, recent_user_queries)
    signals.append(coverage * 0.2)
    
    # 4. 生成されたSQLの再現性
    reproducibility = measure_sql_reproducibility(cluster.generated_sql)
    signals.append(reproducibility * 0.1)
    
    total_score = sum(signals)
    return total_score

# カラム名変更時のペア自動無効化例
def is_pair_still_valid(pair, current_schema):
    """
    ペアが現在のスキーマで有効かどうかを確認します。
    参照するすべてのカラムが存在し、型が一致する必要があります。
    """
    for table_ref in pair.sql_parse.get_table_references():
        if table_ref not in current_schema:
            return False
        for column_ref in pair.sql_parse.get_column_references(table_ref):
            if column_ref not in current_schema[table_ref]['columns']:
                return False
    return True

Developer interacting with AI data assistant via Slack for instant SQL query generation Algorithm Concept Visual

人間の判断が必要な理由：87.5%のノイズ

Vedder開発過程で最も重要な発見の一つは、自動生成された学習データの信頼性問題でした。Spotifyのデータウェアハウスには全データ専門家のクエリ履歴が保存されています。ここから質問-SQLペアを生成するのは簡単に見えます：クエリを取得し、LLMにそのクエリが書かれた質問を推測させ、そのペアをモデル学習に使うのです。

しかし、実際のキュレーションフェーズでドメインエキスパートに提案されたペアのうち、承認されたのは**わずか12.5%**でした。残りの87.5%は：

  • アドホックな探索クエリ
  • デバッグセッション
  • 誰も二度と聞かないような一回限りの回答
  • 誤ったテーブルを使用したクエリ
  • 技術的には正しいが誤ったパターンを教えるクエリ

クエリ履歴は豊富ですが、そのほとんどはノイズです。そしてシグナルは自分でラベルを付けてくれません。

日本企業における適用の注意点

日本企業の環境でこのアプローチを適用する際の考慮点をまとめます：

  • レガシーシステム: 多くの日本企業は長年蓄積されたデータウェアハウスを持っていますが、体系的なデータカタログやドメインエキスパートの明確な所有権がないケースが少なくありません。この場合、クラスターモデル導入前にデータガバナンス体制を整備することが先決です。
  • 組織文化: 「自分のデータ」に対する所有権意識が弱い組織では、キュレーションへの参加を促すインセンティブ設計が重要です。Spotifyのようにデータサイエンティストが自らのドメインをケアする文化がない場合は、最低限、専任のデータスチュワード役を指定することから始めるのが良いでしょう。
  • スタートアップ: データ規模が小さいスタートアップは、むしろこのモデルを導入しやすいです。初期からデータセットを体系的に管理し、ドメイン別キュレーションプロセスを構築すれば、スケーラブルなAIデータアシスタントを構築できます。

この技術の限界と注意点

Vedderのアーキテクチャは強力ですが、いくつかの限界があります：

  1. キュレーションコスト: ドメインエキスパートの時間投資が必要です。Spotifyの規模では許容できますが、小さなチームでは負担になる可能性があります。
  2. クラスター境界の曖昧さ: ドメインが重複したり境界が曖昧な場合、どのクラスターが質問を処理するかのルーティングが複雑になります。
  3. リアルタイムデータ: クラスターヘルススコアは定期的に更新されますが、スキーマ変更がリアルタイムで反映されないと、一時的に不正確な回答が生成される可能性があります。
  4. 拡張性 vs. 柔軟性: 事前定義されたクラスターは効率的ですが、全く新しいタイプの質問には対応しにくいです。この部分は現在Spotifyが追加で探求中の領域です。

合わせて読みたい記事

Server rack representing scalable data infrastructure behind Spotify's cluster model Programming Illustration

まとめ：データ専門家の役割を再定義する

Spotifyのアプローチが与える最大の教訓は、AIがデータ専門家を置き換えるのではなく、彼らの専門性をよりスケーラブルな方法で展開するということです。キュレーションを通じて、データサイエンティストは一回限りの質問に答える時間を減らし、何千もの質問に答えられる知識レイヤーを構築することに集中できるようになりました。

VedderのアーキテクチャはSpotify特有のものではありません。核となるアイデアは普遍的です：データドメインを最もよく理解している人が、モデルが見るコンテキストをキュレーションするのが最も効果的であるということです。

次のステップへの学習ロードマップ

この記事に刺激を受けたなら、以下のトピックを探求してみてください：

  1. ReActパターン: LLMがツールを使って推論・行動するパターンの深い理解（原文参照：arXiv:2210.03629）
  2. RAG vs. コンテキストキュレーション: 両アプローチの違いとそれぞれの長所・短所の比較
  3. データガバナンスツール: Apache Atlas、DataHub、Amundsenなどのデータカタログツールの学習
  4. MCP（Model Context Protocol）: AIツールとデータソースを接続する標準プロトコルの理解

データが増えれば増えるほど、そのデータを理解する「人間のコンテキスト」の重要性が増します。Spotifyの事例は、テクノロジーと人間の専門性の調和が、いかに強力なAIシステムを生み出すかを如実に示しています。

本コンテンツは、信頼性の高い情報源をもとにAIツールを活用して作成され、編集者によるレビューを経て公開されています。専門家によるアドバイスの代替となるものではありません。