はじめに：データセットマイグレーションの苦しみ
データチームであれば誰もが共感するでしょう。古いデータセットを新しいバージョンにマイグレーションする作業は、「やらなければならないが、やりたくない仕事」の代名詞です。特に規模が大きくなればなるほど、その傾向は強まります。Spotifyも例外ではありませんでした。
昨年末、Spotifyのデータプラットフォームチームは、新機能を提供するために最も使用されている2つのユーザーデータセットを非推奨（deprecated）とし、新しいバージョンをリリースする必要がありました。問題は、これら2つのデータセットが約1,800の直接的なダウンストリームデータパイプラインを持ち、会社全体に間接的に影響するパイプラインまで含めると数千に及んだことです。さらに、マイグレーションの期限はわずか6ヶ月でした。
より大きな問題は、これらのパイプラインがSpotify内で使用される3つのまったく異なるパイプラインフレームワークで記述されていたことです：
- SQLベースのBigQuery Runner
- dbt（データビルドツール）
- ScalaベースのScio
手動でマイグレーションを行う場合、約10エンジニアリング週間（engineering weeks）の労力が必要と見積もられました。そこでSpotifyは、自社開発のバックグラウンドコーディングエージェントHonk、内部開発者ポータルBackstage、そして大規模コード変更をオーケストレーションするFleet Managementツールを活用して、この問題を解決することにしました。
本記事は、Spotifyエンジニアリングブログに掲載された「Background Coding Agents: Supercharging Downstream Consumer Dataset Migrations (Honk, Part 4)」の核心内容を、日本の開発者コミュニティの文脈で再構成したものです。（原文：Spotifyエンジニアリングブログ）
Backstageでマイグレーション対象を把握する
コード変更を始める前に、最初に行うべきことは非推奨データセットの系譜（lineage）を把握することです。どのリポジトリがこのデータセットを使用しているのかを特定しなければ、変更対象が見えてきません。
ここでBackstageのエンドポイント系譜プラグインとコード検索（Code Search）プラグインが大きな役割を果たしました。各エンドポイントのBackstageページはダウンストリームコンシューマのリストを明確に表示し、Code Searchを通じてGitHub Enterprise全体から対象リポジトリを特定し、マイグレーション範囲を確定できました。
このプロセスはFleetshiftプラグインによってオーケストレーションされました。Fleetshiftは大規模コード変更を体系的に管理するためのツールで、マイグレーションの進捗状況を一覧できるダッシュボードUIを提供します。おかげで数百ものPRを一つ一つ検索することなく、進捗をモニタリングし、問題が発生したPRをすぐに確認できました。
Honkの成否を分けたコンテキストエンジニアリング
以前の記事「AIが生成したカスタマージャーニーをどう評価するか？CDPメトリクス完全ガイド」でも議論したように、AIエージェントのパフォーマンスは、どれだけ良いコンテキストを提供するかに大きく依存します。Honkプロジェクトでも、コンテキストエンジニアリングが最も時間と反復を要した部分でした。
Scioパイプラインの教訓：標準化されていない環境はエージェントフレンドリーではない
Honkが直面した最大の課題は、3つの異なるパイプラインフレームワークを処理しなければならなかった点です。BigQuery Runnerとdbtは会社全体で比較的一貫したスタイルと構造を持っていましたが、Scioはチームごとに使い方が千差万別でした。
このような非標準化環境では、Honkがすべてのケースを処理できるオールインワンプロンプトを作成することが事実上不可能でした。当時、HonkはClaude Skillsやカスタム設定機能をサポートしていなかったため（これはマイグレーション結果の予測可能性を高めるための設計判断でした）、プロンプトにすべてを盛り込む必要がありました。しかし、Scioパイプラインの柔軟性ゆえにプロンプトが非常に巨大になり、管理が難しくなりました。
結局、SpotifyチームはScioマイグレーションを断念し、標準化されたBigQuery Runnerとdbtに集中することを決定しました。この判断は非常に実用的でした。すべてを自動化しようとして何も自動化できないより、うまくいくものから自動化する方が賢明です。
dbtとBigQuery Runner：標準化の力
標準化された2つのフレームワークでは、コンテキストファイルを精緻に作成することに集中しました。初期は人間が読むマイグレーションガイドをそのままプロンプトに含める方法を試みましたが、結果は芳しくありませんでした。Honkがデータセットフィールド間のマッピングを推測し、誤った仮定をするケースが多発したためです。
解決策は、マッピングテーブルを明示的にコンテキストファイルに含めることでした。Honkが外部ドキュメントを読んだりデータセットスキーマを直接参照したりできなかったため、コンテキストファイル内にすべてのフィールドマッピングを表形式で明確に記述しました。また、特定のフィールドについてはケースバイケースで人間の判断が必要なため、Honkには変更せず、代わりに該当フィールドの上に人間用ガイドへのリンクをコメントとして追加するよう指示しました。
# 例：Honkに提供されたコンテキストファイルの一部（擬似コード）
# マイグレーションルール: user_idフィールドは 'user_id_v1' -> 'user_id_v2' に直接マッピング
# 注意: 'custom_tracking'フィールドはチームごとに異なるロジックが必要なため変更しないこと
# 代わりに以下のコメントを追加すること: "// TODO: このフィールドは手動マイグレーションが必要です。ガイド参照: [リンク]"
テスト不在という現実
もう一つの現実的な問題は、BigQuery Runnerとdbtのリポジトリのほとんどがユニットテストを持っていなかったことです。Honkの核心機能の一つは、自身が行った変更を検証し、結果に応じて調整するフィードバックループですが、テストがなければこの機能を使用できません。
結局、自動生成されたPRをマージする前に、ダウンストリームチームが手動でテストを実施する必要がありました。これは自動化の効用をやや減少させるものでしたが、それでもPR自体を自動生成し、レビュープロセスまで作り出せただけでも大きな時間節約になりました。
結果：240の自動化されたPR、約10週間分の労力削減
最終的にSpotifyチームはFleetshiftを通じて240の自動化マイグレーションPRを成功裏にデプロイしました。BackstageとFleetshiftが提供する概要UIのおかげで、マイグレーションの進捗状況をリアルタイムでモニタリングし、問題のあるPRを即座に特定して担当チームとコミュニケーションを取ることができました。
手作業であれば10週間かかった作業を自動化で解決したことになります。しかし、この成功の背後には、「うまくいくものだけを自動化する」という戦略的判断と、コンテキストエンジニアリングに対する深い理解がありました。
今後の課題と教訓
このプロジェクトを通じてSpotifyが得た最大の教訓は以下の通りです：
-
データ環境の標準化が先行すべきである。 Honkのようなバックグラウンドコーディングエージェントが真の効用を発揮するには、データパイプラインとリポジトリが一貫したパターンに従っている必要があります。標準化されていない環境では、プロンプトの作成自体が非常に困難になり、エージェントのパフォーマンスも低下します。
-
テストと検証を強制すべきである。 エージェントが自身の作業を検証し修正できるようにするには、リポジトリにテストが必須です。これは単にHonkのための要件ではなく、ソフトウェアエンジニアリングのベストプラクティスでもあります。
-
コンテキストは明示的かつ構造化されるべきである。 エージェントに「推測」させるのではなく、マッピングテーブルのような明確な構造でコンテキストを提供すべきです。特にエージェントが外部情報を自ら収集できない環境では、なおさら重要です。
-
すべてを自動化しようとしないこと。 Scioパイプラインの事例が示すように、自動化が難しい部分は潔く諦め、うまくいく部分に集中する戦略が、かえって良い結果をもたらします。
日本の開発環境での適用文脈
日本の開発環境でも、同様の課題に直面されている方は多いでしょう。特に大企業のSIや金融機関のように、レガシーシステムが多く、パイプラインが様々なツールや言語で分散している環境ではなおさらです。
- Backstageは日本での導入事例はまだ多くありませんが、大規模なマイクロサービス環境を運用する企業であれば、内部開発者ポータル（IDP）の構築を検討する価値があります。Spotifyの事例は、Backstageが単なるサービスカタログを超えて、大規模コード変更をオーケストレーションするプラットフォームに拡張できることを示しています。
- データパイプラインの標準化は、言葉で言うほど簡単ではありません。しかし、この事例は標準化が単に「きれいなコード」のためではなく、AIベースの自動化の前提条件であることを示しています。日本の環境では、dbtのようなモダンなデータ変換ツールの導入を検討してみるのも良い出発点になるでしょう。
- テスト文化は、多くの日本企業で依然として課題です。Honkの事例は、テストが単にバグを減らすツールを超えて、自動化されたコード変更の信頼性を保証する核心要素であることを教えてくれます。
この技術の限界または注意点
- Honkのようなバックグラウンドコーディングエージェントは、標準化された環境で最もよく動作します。レガシーシステムや非標準的なコードベースが多い環境では、導入コストの方が大きくなる可能性があります。
- 現時点では、複雑なビジネスロジックやドメイン固有の判断が必要な変更は自動化が困難です。人間の判断が必要な部分は明確に区別し、エージェントが触れてはいけない領域を事前に定義する必要があります。
- エージェントが生成したPRは、必ず人間がレビューしなければなりません。完全な無人自動化はまだリスクが伴います。
次のステップとしての学習方向
- Backstageに興味がある方は：Backstage公式ドキュメントを出発点に、プラグイン開発とカスタマイズを学習してみてください。
- バックグラウンドコーディングエージェントを自ら構築してみたい方は：Claude APIやOpenAIのFunction Callingを活用した簡単なコードリファクタリングエージェントから始めてみることをお勧めします。
- データパイプライン標準化に興味がある方は：dbt、Airflow、そしてデータメッシュアーキテクチャについて学んでみてください。
まとめ
SpotifyのHonk事例は、AIエージェントが実際のプロダクション環境で大規模マイグレーションをどのように成功させることができるかを示す優れた参考資料です。重要なのは、「AIがすべてを解決してくれる」という幻想ではなく、標準化された環境、明確なコンテキスト、そして賢明な自動化範囲の設定が揃って初めて真の効用が生まれるという点です。
今後、Honkチームはエージェントがコード変更を実行する前に、JIRAチケットやドキュメントを読んで自らコンテキストを収集できる機能を開発中とのことです。これにより、事前のコンテキストファイル作成の負担が軽減され、より複雑なタスクにもエージェントを適用できるようになると期待されます。
皆さんの組織では、どのようなマイグレーション作業が自動化できるでしょうか？標準化とテストから始めてみてはいかがでしょうか。
合わせて読みたい記事
