Spotify のバックエンドプログラミング AI エージェント実装実践 (1,500 件を超える AI 生成 PR を正常にマージ) 中核的な問題と解決策 Spotifyのフリート管理システムは単純なタスクの自動化には優れていますが、複雑なコード変更は常に困難を極めています。従来の方法では抽象構文木や正規表現の操作が必要となり、高度な専門知識が求められます。例えば、Mavenの依存関係更新スクリプトは20,000行を超えるコードになっています。 チームの中心的なアイデアは、Fleet Management のすべてのインフラストラクチャ (ターゲット リポジトリの選択、PR の開始、レビュー、マージ プロセスなど) を維持しながら、決定論的な移行スクリプトを自然言語で定義されたインテリジェント エージェントに置き換えることです。 技術進化パスのフェーズ1：オープンソースツールの探索。チームはGooseやAiderなどのオープンソースツールを試しましたが、大規模な移行シナリオにおいてマージ可能なPRを確実に生成することは困難でした。 フェーズ2：自社開発ループ。LLM APIをベースにした「エージェントループ」を構築しました。これは、ユーザーが提供するプロンプト、エージェントによるファイルの編集とビルドフィードバックの統合、そしてテストパスまたは制限値到達後の完了という3つのステップで構成されています。これは小さな変更には適していますが、複雑な複数ファイルの変更を扱う際には、ループが不足したり、コンテキストが失われたりすることが多々あります。 フェーズ3：クロード・コード Claude Codeは、約50件の移行とほとんどの本番環境PRで使用されており、最高のパフォーマンスを発揮するエージェントとして注目を集めています。より自然なタスク指向のプロンプトをサポートし、ToDoリストを管理し、子エージェントを効率的に導出します。 プロジェクトの主要な原則 1. エージェントの特性に基づく調整 - 独自に開発されたエージェントは厳密なステップバイステップの指示に適していますが、Claude Code は最終状態を記述し、自律性を可能にするのに適しています。 2. 前提条件を定義する – エージェントは性急に行動することが多いため、いつ行動を起こさないかを明確に定義する必要があります。 3. 具体的な例を使用する - いくつかの具体的なコード例は、結果に大きな影響を与える可能性があります。 4. 検証可能な目標を定義します。理想的には、あいまいな指示を避け、テストとして提示します。 5. 一度に 1 つの変更 – 複数の変更を組み合わせると、コンテキストが使い果たされたり、部分的な結果が生成されたりする可能性が高くなります。 6. エージェントからのフィードバックを求める - 会話が終了した後、エージェントは提案の欠点を指摘できます。 ツールとコンテキスト管理 Spotifyは予測可能性を維持するために保守的なツール戦略を採用しています。エージェントは以下のものにのみアクセスできます。 • 検証ツール：フォーマット、静的解析、テストを実行します。 • 制限付き Git ツール：Git 操作を標準化し、リモートリポジトリへのプッシュや変更を禁止します。 • ホワイトリストに登録された Bash コマンド：ripgrep など。 コード検索ツールやドキュメントツールを公開するのではなく、ユーザーに提案に関連コンテキストを事前に含めるよう求めます。設計理念は、「ツールが増えれば増えるほど、予測不可能な側面が増える」というものです。 このシステムは、実際のアプリケーションで実証されているように、次のような複雑な移行タスクを処理します。 • 言語の近代化（例：Javaの値型をレコード型に移行する） • 破壊的な変更を伴うアップグレード • UIコンポーネントの移行 • プロファイルの更新 これらの移行により、60～90%の時間節約が実現しました。さらに重要なのは、2024年半ば以降、SpotifyのPRの約半分がこのシステムによって自動的に生成されるようになったことです。 移行後のアプリケーションチームは、MCPプロトコルを介してSlackとGitHub Enterpriseにエージェントを統合します。ワークフローは次のとおりです。インタラクティブエージェントはまずタスク情報を収集し、プロンプトを生成し、その後、コーディングエージェントに渡して実行とPR作成を行います。これにより、エンジニアはSlackスレッドからアーキテクチャに関する決定ログを取得したり、プロダクトマネージャーがローカルでビルドすることなく簡単な変更を提案したりできるようになります。 解決すべき課題 Spotify チームは、現在の制限について率直に指摘しました。 • パフォーマンスと予測可能性の問題 • 構造化されたヒント/モデル評価方法の欠如 • PRが本当に元の問題を解決しているかどうかの検証の難しさ • ヒントを進化させるには、依然として主に直感と試行錯誤に依存している パート1: https://t.co/M5pJCeL5Ds パート2:
