10月12日、Leela Kumiliが「Spotify More Than Doubled Monthly Code Changes as AI Accelerated Development」と題した記事を公開した。この記事では、SpotifyがAI支援開発の導入により月間コード変更数を1年間で倍増以上させ、それに伴う品質・信頼性管理の課題と対応策について詳しく紹介されている。
月間マージ数が8,100件から17,000件へ
Spotifyは今年8月、月間のマージ済み変更数が前年比で約8,100件から17,000件超へと倍増以上したことを明らかにした。背景にあるのはAI支援開発の本格活用だ。
同社が運用するのは約3,000の本番サービス。月間アクティブユーザー数7億7,700万人、同時接続クライアント数約1億、バックエンドのリクエスト処理は毎秒1,100〜1,200万件という規模である。コード変更の速度が急増した結果、既存の品質検証の仕組みが追いつかなくなる場面が生じた。
Spotifyのエンジニアリングブログで示された変化の内訳を見ると、品質・最適化関連の変更が全体の27%から31%へ増加した一方、メンテナンスや設定変更は31%から25%へ減少している。手戻り（rework）の増加は現時点では確認されていないが、プルリクエストのサイズとコードの複雑さは上昇傾向にあるという。
自動化が引き起こした本番障害
速度向上の恩恵がある一方で、二つの具体的な障害事例が紹介されている。
コンテンツ処理パイプラインの遅延：Spotifyは1日あたり50万件超の楽曲・動画・ポッドキャスト・オーディオブックを処理している。6月24日、定期バッチ処理と新着エピソードの取り込みが競合し、そこに品質改善による処理負荷増加とスケジューラのバグが重なり、スループットが約10%低下。通常は数分で公開されるエピソードが数時間遅延した。Spotify側の対応はエンド・ツー・エンドのモニタリング追加、スケジューラ修正、バッチジョブの優先度引き下げ、処理キャパシティの増強など多岐にわたった。
自動依存関係アップグレードの失敗：Spotifyはフリート管理（Fleet Management）システムで250万件以上の自動メンテナンスPRをマージしてきた。大半は安全性チェック通過後に自動マージされる。しかしあるケースでは、自動依存関係アップグレードが既存チェックを通過しながら本番環境で障害を引き起こした。対策として、ロールバックキャパシティの拡充と、自動変更の実行スケジュールを担当チームの勤務時間帯に限定する措置を追加している。
バックグラウンドコーディングエージェント「Honk」
自動化の中核を担うのが「Honk」と呼ばれるバックグラウンドコーディングエージェントだ。KubernetesのPod上でAnthropicの**ClaudeとAnthropic Agent SDK**を用いて動作する。
役割分担を整理すると、Honkが担うのはコード変更の実際の実行とCI（継続的インテグレーション）環境上でのビルド処理だ。一方、どのサービス・PRを対象とするかの選択、実行タイミングのスケジューリング、進捗の追跡といったオーケストレーション層は、別コンポーネントの「Fleetshift」が担当する。Honkはあくまで個々の変更作業に集中し、Fleetsiftがその全体調整を担う分離設計となっている。3,000規模の本番サービスを横断的に管理する上で、こうした役割の明確な分離が運用上の安定性に寄与していると考えられる。
このHonkを活用したJavaのバックエンド一括マイグレーションはわずか3日で完了したとSpotifyは報告している。従来であれば数週間規模の作業を要するようなリファクタリングを、エージェントが並列的に処理することで大幅に圧縮した形だ。
「書くのは楽になった。難しいのは検証だ」
この事例はエンジニアコミュニティでも反応を呼んでいる。JumpCloudのソフトウェアエンジニアAmit JhaはLinkedInへの投稿でこう述べた。
変更量の増加はテスト・レビュー・オブザーバビリティへのプレッシャーを高める。
Alex Beckも同様の観点からLinkedInで言及している。
コードを書くのは簡単になった。今の難しさは、本番に出す前にその成果が本当に正しいかを確認することだ。
この見方はGoogleの2025年DORAレポートとも符合する。同レポートはAI導入がソフトウェアデリバリーのスループットと製品パフォーマンスを向上させる一方、デリバリーの安定性とは負の相関があることを指摘している。自動テスト・バージョン管理・高速フィードバックループが管理の鍵とされており、Spotifyの取り組みはその実践例といえる。
なお、Spotifyのインシデント調査では、AI生成コードが直接的な原因となった事例は確認されていない。問題の本質は、変更の速度が既存の検証コントロールを上回ったことにある。速度と信頼性をどう両立させるかは、AI支援開発を本格導入する組織が共通して直面する課題であり、Spotifyの事例はその試行錯誤の一端を示すものとして参照価値が高い。
詳細はSpotify More Than Doubled Monthly Code Changes as AI Accelerated Developmentを参照していただきたい。
