はじめに：「AIがコードを書くと品質が落ちるのでは？」
月間アクティブユーザー7億7,700万人、秒間バックエンドリクエスト1,100〜1,200万件、プロダクションサービス約3,000個。Spotifyの規模において、品質は常に未解決の課題でした。しかし、AI導入後に本当に興味深いことが起きました。
原因はAI slop（低品質なAI生成コード）ではありませんでした。 むしろ問題は**「変化の速度」そのもの**でした。コードを生み出す能力が、検証する能力を追い越してしまったのです。
本記事では、Spotifyが1年間の自社データを分析して導き出した4つのリスク領域と、実際に何を変えたのかを実務視点で解説します。
💡 なぜこの記事が重要なのか Google Cloudの2025 DORAレポートは「AI導入 → スループット↑、安定性↓」という相関を示しました。しかしSpotifyは自社データではそのトレードオフは見えないと述べています。その差がどこから来るのかが核心です。
根拠資料: Spotify Engineering Blog
Spotifyが直面した4つのリスク領域
1. コンテンツ処理パイプライン：サイレント障害
Spotifyは1日50万件以上の新規楽曲・動画・ポッドキャスト・オーディオブックを処理しています。ここで2つの既存の弱点が露呈しました。
- 障害の隠蔽： 処理できなかったメディアファイルが静かに失敗し、数時間誰も気づかない（ページ通知が飛ばない）
- 容量不足： トランスコード容量が枯渇すると、正常な動画エピソードがキューで待機するが、それを知らせるアラートがない
6月24日のインシデントはこれらの要因が重なりました。予約バッチジョブが新規エピソードと競合 + 最近の品質改善でエピソードあたりの計算量が増加 + スケジューラのバグでスループットが約10%減少。結果、通常数分で公開されるエピソードが数時間遅延しました。
対応：
- E2Eモニタリング追加（クリエイターより先に障害を検知）
- スケジューラのバグ修正
- バッチジョブを低優先度に移動
- 容量増強 + サービスタイアリング/ワークロード優先度の再設計
# 概念的なワークロード優先度の例
priority_classes:
- name: critical_services
weight: 100
- name: new_uploads
weight: 80
- name: bad_actor_episodes
weight: 5 # 抑制および優先度を大幅に引き下げ
- name: batch_jobs
weight: 20 # 低優先度に移動
2. フリートアップデート：自動化が生む新たな障害モード
SpotifyのFleet Managementフレームワークは毎日大規模な変更を自動マージします。最近ではJavaマイグレーションを3日でバックエンドサービス全体に完了したとのこと。しかし自動化が増えれば、新たな障害モードも生まれます。
事例： 自動依存関係アップグレードが検証は通過したが、プロダクションで失敗 → エンドユーザーに影響
対応：
- セーフガード強化
- ロールバック容量の拡大
- 自動変更を所有チームの勤務時間内にスケジューリング ← これは実務で本当に重要です
3. コンピュート不足：AIが生んだ間接的な品質低下
業界全体でAI需要が急増 → CPU/GPU供給不足 → 予備容量の減少。Spotifyは元々「必要なときにコンピュートがある」という前提で運用していましたが、その前提が崩れました。
リージョン障害時に他リージョンへトラフィックを逃がすfailoverを行いますが、以前は些細だった問題が容量不足の状況ではユーザーが体感するようになりました。
対応：
- ネットワークエッジ/タイアリングの再検討
- Failover時に下位ティアのサービスは容量がない可能性を許容
- 5月のインシデント後に予約エッジ容量を2倍確保
- サービスメッシュトラフィックの手動移動 → エッジまで拡張を進行中
4. モバイルアプリ：リリースは健全だが、回帰は蓄積する
10年以上繰り返されたサイクル：新機能を素早く出荷 → 品質指標悪化 → ガードレール強化 → 回復 → 新たな問題登場 → 繰り返し。
AIがこのサイクルの周期を短くしました。問題はAIコードが悪いのではなく、品質測定システムがビルド/デプロイ速度に追いつけていないことです。
「個別のリリースは健全に見えるが、小さな回帰が特定の端末で蓄積したり、我々が見ていないシグナルに隠れている。」
対応： 品質シグナルの拡大 + 長期トレンド指標の追加
データが語ること：本当に品質-速度トレードオフなのか？
Spotifyは毎月主要インシデントの振り返りを行い、2つの質問を追加しました。
- AIが書いたコードがこのインシデントに直接寄与したか？
- 変更量の増加がレビュー/テスト/ロールアウト/可観測性に圧迫を与えたか？
結果
| 項目 | 発見 |
|---|---|
| AI作成コードの直接的な障害寄与 | ❌ 有意な証拠なし |
| 変更量増加による検証圧迫 | ✅ 観察された |
| マージされたPR数（8月YoY） | 8,100 → 17,000（2倍以上） |
| 品質/最適化作業の割合 | 27% → 31%（絶対量は2倍以上） |
| メンテナンス/設定の割合 | 31% → 25% |
| コードchurn | 上昇（FAROS 2026レポートと一致） |
| Rework rate | 上昇なし ← 核心シグナル |
Churn vs Rework Rate、何が違うのか
- Code churn： 追加されたコードに対する削除されたコードの比率
- Rework rate： 変更されるコードの**年齢（age）**を重みとして反映 → 最近の作業がどれだけ持続しているかをより正確に測定
解釈： 業界全体でchurnは急増しましたが、Spotifyはrework rateが上がらなかった → AIによる品質負債が蓄積されていないというシグナル。
⚠️ 注意：2つの警告シグナル
- コード複雑度の上昇
- PRサイズの増加
AI以前はこの両方とも明確な品質懸念でした。しかし今は人間とエージェントが協働して、より大きな作業単位を安全にデプロイした結果である可能性もあります。Spotifyはどちらの仮説にも確信が持てないため、閾値を自己安慰のために調整せず観察を続けると述べています。これは非常に成熟した姿勢です。
この技術の限界と注意事項
- Spotify規模のデータは再現不可能： 3,000サービス、秒間1,100万リクエスト規模で観察された結果が、スタートアップや中規模チームにそのまま適用されるわけではありません。
- 「直接寄与なし」は「無関係」ではない： AIコードが障害の直接原因ではなかったものの、変更量そのものを増やして間接的に検証システムに負荷をかけたことは確認されています。
- DORAレポートと相反： DORAは安定性低下を、Spotifyはトレードオフなしを主張 → コンテキスト（チーム成熟度、検証自動化レベル）によって結果が変わるというのが正確な解釈です。
- 複雑度/PRサイズの閾値再検討は未決着： 現状の基準をそのまま使うのも、変えるのも危険な状況です。
日本の開発エコシステムへの示唆
国内のSI/スタートアップ環境では、この部分に特に注意が必要です。
Spotifyのように3,000サービスの規模でなくても、**「変更量 > 検証能力」**になる瞬間は誰にでも訪れます。特に：
- レビュー渋滞： AIでPR生成速度だけを上げると、レビュアーがボトルネックになります。SpotifyがPRサイズ増加を警告シグナルと見なす理由がここにあります。
- 可観測性の不足： 日本の多くのチームが依然としてログベースのデバッグに依存しています。SpotifyがE2Eモニタリングを最優先に挙げたことは示唆に富みます。
- ロールバック自動化： 「ロールバック容量の拡大」という表現自体が馴染みのないチームも多いでしょう。デプロイだけ自動化してロールバックは手動のチームは、AI導入前にここを整備すべきです。
次のステップ学習の方向性
- DORA 2025レポート原文を読む — AI導入と安定性の相関データ
- FAROS 2026レポートのchurn分析 — 業界全体のトレンド把握
- Rework rateを自社で測定してみる — 自社リポジトリでコード年齢ベースの指標を抽出
- ワークロード優先度/タイアリング設計 — バッチジョブとクリティカルサービスの分離
まとめ：結局「検証システム」がボトルネックである
Spotifyの結論は明確です。
「AIは変化を生み出す能力を高めた。次の制約はそれを検証する能力だった。」
AIが書いたコードの品質論争は副次的です。本当の戦いはレビュー、テスト、ロールアウト、可観測性、ロールバック、failover、品質測定を開発速度と同じペースで動かすことです。