はじめに：データマイグレーション、なぜこんなに苦しいのか？
データチームであれば誰もが共感するでしょう。古いデータセットを非推奨(deprecated)にし、新しいバージョンに移行する作業は、まさに「泥沼で泳ぐ」ようなものです。データオーナーはもちろん、そのデータを日々利用するダウンストリームチームにとっても大きなストレスです。
Spotifyも例外ではありませんでした。昨年末、新機能を解放するために、最も利用されている2つのユーザーデータセットを非推奨にする必要がありました。ところが、これらのデータセットには 約1,800の直接的なダウンストリームデータパイプライン が接続されており、間接的には社内全体の数千に影響を及ぼしました。さらに、Spotify内で使われている3つの全く異なるパイプラインフレームワーク（SQLベースのBigQuery Runner、dbt、ScalaベースのScio）すべてをサポートしなければなりませんでした。
手動で処理した場合、約 10エンジニアリングウィーク(engineering weeks) が必要と見積もられました。この難局をどう突破したのでしょうか？ 答えは、バックグラウンドコーディングエージェント Honk と Backstage、Fleet Management プラットフォームの組み合わせでした。
この記事は、Spotifyエンジニアリングブログ「Background Coding Agents: Supercharging Downstream Consumer Dataset Migrations (Honk, Part 4)」をベースに、日本の開発者の皆様が実際の業務に応用できるインサイトを中心に再構成しました。
本論1：Backstageでデータ系統(Lineage)を把握し、ターゲットリポジトリを発掘する
コード変更を始める前に、最初にすべきことは どこを修正すべきか把握する ことでした。SpotifyはBackstageの エンドポイント系統(Lineage)プラグイン と Codesearch を活用しました。
- Backstageエンドポイントページ: 各エンドポイントのページでダウンストリームコンシューマのリストを一目で確認。マイグレーション規模を即座に把握できました。
- Codesearchクエリ: Spotify GitHub Enterprise全体からターゲットリポジトリを検索するクエリを作成。
- Fleetshiftプラグイン: 発見したリポジトリをマイグレーション範囲としてマーキングし、全体のオーケストレーションを担当。
このプロセスにより 240の自動化PR(Pull Request) を生成できました。BackstageとFleetshiftのダッシュボードUIは、マイグレーション進捗をスナップショットのように表示し、各PRを簡単にクリックして確認できるようにし、トラブルシューティングや進捗モニタリング、オーナーチームとのコミュニケーションに大いに役立ちました。
本論2：Honkに「コンテキスト」を教える技術
先日ご紹介した CSS Gridでジグザグ（滝）レイアウトを作る translateY(%)の隠れた魔法 でも強調したように、ツールを正しく活用するには、そのツールが理解できる言語で語らなければなりません。Honkにとっては、まさに「コンテキストエンジニアリング」がその核心でした。
2.1 3つのフレームワーク、3つのアプローチ
| フレームワーク | 標準化度合い | Honk適用結果 | 重要な教訓 |
|---|---|---|---|
| dbt | 高い（一貫したスタイル） | ✅ 成功 | 標準化された環境ではプロンプトがシンプルでも良好に動作 |
| BigQuery Runner | 高い（一貫したスタイル） | ✅ 成功 | マイグレーションガイドをそのままプロンプトにせず、明確なマッピングテーブルを提供 |
| Scio (Scala) | 低い（チームごとの自由度が高い） | ❌ 中断 | 多様なパターンをすべてカバーするプロンプトは非現実的。追加コンテキスト収集機能が必要 |
2.2 プロンプト作成の落とし穴と解決策
最初は、人間が読むマイグレーションガイドをそのままClaudeにプロンプトとして与えました。しかし結果は散々でした。Honkがフィールドマッピングを推測し、誤った方向に進むケースが多発したのです。
解決策: すべてのフィールドマッピングを テーブル形式 で明示的に提供しました。Honkは私たちが与えたコンテキストしか見ることができないため、曖昧さを完全に排除する必要がありました。
# 例: Honkが理解できるマッピングテーブル（擬似コード）
mapping_table = {
"old_dataset.user_id": "new_dataset.user_identifier",
"old_dataset.play_count": "new_dataset.total_plays",
"old_dataset.last_active": None # マイグレーション対象外、コメント追加を依頼
}
また、マイグレーションを 行ってはいけないフィールド も明示しました。例えば、特定のユースケースに応じて人間の判断が必要な場合、Honkにはフィールドをそのままにし、代わりに該当フィールドの上に人間エンジニア向けガイドへのリンクをコメントとして残すよう指示しました。
2.3 テスト不在という壁
Scioパイプラインにはユニットテストが存在することが多かったのですが、BigQuery Runnerとdbtのリポジトリには ビルドタイムのユニットテストがほとんどありませんでした。これはHonkの核心機能の一つである「自己検証後に結果に応じて調整する」ことを使えないことを意味しました。結局、ダウンストリームのオーナーチームがPRをマージする前に手動テストを行う必要がありました。
本論3：日本企業の開発現場での適用コンテキスト
Spotifyの事例は単なる海外ビッグテックの話ではありません。日本の開発現場でも十分に応用可能なインサイトがあります。
3.1 レガシーシステムのマイグレーション
日本のSI案件や金融機関では、数百、数千ものバッチJobやデータパイプラインが運用されています。今回の事例から学べる点は：
- 標準化が先行して初めてAI自動化が可能になる: SpotifyもScioは標準化不足で自動化を断念しました。日本の現場では、まず パイプラインテンプレートの標準化 から進めるのが優先です。
- Backstageのような内部開発者ポータル(Internal Developer Portal)導入の検討: データ系統を一目で把握できるツールがなければ、AIエージェントもどこを直せばよいかわかりません。
3.2 この技術の限界または注意点
- コンテキストエンジニアリングのコスト: Honkに完全なコンテキストを提供するのに相当な時間がかかります。小さなプロジェクトでは、むしろ手動作業の方が早い場合があります。
- テストインフラは必須: AIが生成したコードを検証する自動化テストがなければ、結局人間が再レビューする必要があります。「半自動」状態に留まる可能性が高いです。
- フレームワークの多様性: 標準化されていない環境では適用が困難です。すべてをAIが解決してくれるわけではありません。
まとめ：AIコーディングエージェントの未来と次のステップ
SpotifyのHonk事例は、AIコーディングエージェントが単なるコード生成ツールを超え、大規模システムマイグレーションを現実的に自動化できる ことを示しています。しかし、成功の鍵はAI自体の性能よりも、組織のデータ標準化、テスト文化、そしてコンテキストエンジニアリング にあります。
今後Honkチームは、JIRAチケットやドキュメントを読んで自らコンテキストを収集する機能を開発中とのことです。これにより、人間が毎回コンテキストファイルを作成する負担が減り、より複雑なタスクにもAIを適用できるようになるでしょう。
合わせて読みたい記事
次のステップとしての学習方向性
- 内部開発者ポータル(Backstage、Port、Cortexなど)導入の検討 - データ系統とサービスカタログがAI自動化の基盤です。
- パイプライン標準化テンプレートの作成 - dbtやBigQuery Runnerのように一貫したパターンを強制しましょう。
- 小さな単位から始める - 最も標準化されたパイプライン10本だけをまず自動化し、徐々に拡大してください。
- AIエージェント用のテストパイプライン構築 - AIが生成したコードを自動検証するCI/CDパイプラインを同時に作りましょう。
# Honkコンテキストファイルの例（擬似コード）
# 目的: old_user_stats_v1 → new_user_stats_v2 マイグレーション
MIGRATION_RULES = {
"field_mappings": [
{"from": "user_id", "to": "user_identifier", "transform": None},
{"from": "total_listens", "to": "total_plays", "transform": "lambda x: int(x)"},
{"from": "last_login", "to": "last_active_timestamp", "transform": "parse_date"},
{"from": "premium_status", "to": None, "action": "keep_unchanged",
"comment": "ユーザーごとに判断が必要。人間のエンジニア向けガイド: docs/internal/premium-migration.md"}
],
"excluded_fields": ["internal_session_id"],
"testing_required": True,
"pr_template": {
"title": "[AUTO] Migrate {repo_name} from old_user_stats_v1 to new_user_stats_v2",
"labels": ["honk-auto", "dataset-migration"]
}
}
表で見るHonkマイグレーションの成果
| 項目 | 数値 | 備考 |
|---|---|---|
| 対象ダウンストリームパイプライン | ~1,800 | 直接的影響 |
| 自動生成PR | 240 | Fleetshift経由でデプロイ |
| 削減されたエンジニアリング時間 | 約10週間 | 手動と比較 |
| サポートフレームワーク | 3つ (dbt, BigQuery Runner, Scio) | Scioは途中で断念 |
| 主な成功要因 | Backstage系統 + 標準化フレームワーク + 明示的マッピングテーブル | |
| 主な失敗要因 | 標準化不足(Scio) + ユニットテスト不在 |
日本企業の開発現場での注意点
日本の開発現場では、以下の点に特に注意してください：
- レガシーシステムのドキュメント化不足: Backstageのようなツールなしでデータ系統を把握するだけでも大きな工数です。AI導入前に データカタログ の構築を先に検討しましょう。
- 多様なフレームワークの混在: 一つのプロジェクト内でも、Informatica、Talend、Spark、Pythonスクリプトが混在しているケースが少なくありません。Spotifyのように標準化されたフレームワークから始める戦略が必要です。
- テスト文化: 多くの日本企業のプロジェクトでは、データパイプラインに対するユニットテストが整備されていません。AI自動化の効果を最大化するには、パイプラインテストの自動化 が先行すべきです。
おわりに：AIエージェント時代のデータエンジニアリング
SpotifyのHonk事例は確かに心強いものです。しかし「AIがすべてを代替する」という過大な期待には注意が必要です。実際には 標準化、テストインフラ、コンテキストエンジニアリング という膨大な準備作業が必要でした。
それでも、一度インフラが整えば、AIエージェントは人間がやりたがらない反復的で膨大なマイグレーション作業を驚くべき速度で処理できます。特に Holotron-12B のような最新AIモデルが登場し、推論効率が2倍向上していることを考慮すると、今後このような自動化事例はますます増えるでしょう。
次のステップとしておすすめのアクションアイテム:
- 今すぐチームで使っているデータパイプラインの標準化状況を棚卸ししましょう。
- 最も標準化されたパイプラインを1つ選び、AIエージェントでマイグレーションするPoCを進めてみてください。
- 失敗しても構いません。SpotifyもScioで失敗しました。その経験から学ぶことの方が重要です。
「AIはエンジニアを代替するのではなく、エンジニアがより価値のあることに集中できるようにするツールである」 - Spotify Honkチームの教訓