世界最大級の音楽ストリーミングサービスであるSpotifyが、Anthropic社のAI「Claude」を使って自社の巨大なコードベースを驚くべきスピードで進化させています。エンジニアの生産性を根本から変えたこの事例は、日本企業が「AIをどう業務に組み込むか」を考える上で、非常に具体的なヒントを与えてくれます。本記事では、公開されている一次情報をもとに、Spotifyの取り組みを詳しく整理し、そこから得られる実践的な学びをまとめます。
Spotifyという「巨大すぎる現場」
Spotifyは180以上の市場で7億1300万人以上のユーザーに、1億曲を超える楽曲を届けています。そのサービスを支えるバックエンドのモノレポ（単一の巨大なコードリポジトリ）は、なんと2,000万行超。エンジニアの数はおよそ2,900人にのぼり、1日あたり約4,500件の本番デプロイが行われています。
これほどの規模になると、ちょっとしたライブラリのアップグレードやAPIの仕様変更ひとつでも、数百・数千のリポジトリに影響が及びます。従来であれば、こうした「全社横断の移行作業（フリート・マイグレーション）」は、専門チームが数か月から数年をかけて手作業に近い形で進めるのが当たり前でした。
導入前の課題：自動化には限界があった
Spotifyには2022年から「Fleet Management」というコード移行の仕組みが存在していました。ただし、その中身は抽象構文木（AST）操作や正規表現パターンに頼った、いわば「決まりきったルールに従う自動化」です。単純な書き換えなら対応できても、コードの「意味」を理解しないと判断できないような複雑な移行は、結局エンジニアが手作業で行うしかありませんでした。
この「意味を理解した上での大規模書き換え」こそが、長年のボトルネックだったのです。
Claudeが変えたこと：成果は数字が物語る
2025年7月、SpotifyはClaude Agent SDKをFleet Management基盤に統合しました。その後の半年で、Claudeは大規模コード変換における「第一選択のモデル」になったといいます。結果として公表されている数字は次の通りです。
- 複雑なコード移行作業の時間を最大90%削減
- 月650件以上のプルリクエストをバックグラウンドのコーディングエージェントが生成し、本番にマージ
- 全プルリクエストの73%がAIによる支援を受けている
- プルリクエストの生成頻度が75%以上向上
Spotifyのシニアスタッフエンジニアであるマックス・カラス氏は次のように語っています。
「私たちのエンジニアは、これまで不可能だったペースで、全社規模の移行作業を実行できるようになりました」
また、チーフアーキテクト兼VP of EngineeringのニクラスGustavsson氏はこう述べています。
「Claudeは、大規模なコード変換作業において、一貫して最も高いパフォーマンスを発揮してきました」
具体的な活用シーン
Spotifyの活用は、単純な「コード生成」にとどまりません。実際の適用範囲は多岐にわたります。
- フリート横断の自動変換：JavaのAutoValueクラスをRecordsへ変換、破壊的変更を伴うフレームワークのアップグレード、コードベース全体の文脈を踏まえた設定ファイルの更新など
- gRPCコンテキスト伝播の標準化：Javaサービス群にまたがる横断的な仕様統一
- プロトタイピング：モバイルアプリやバックエンドでのエンドツーエンドのプロトタイプ作成。社内アプリストアで共有し、アイデア検証のサイクルを高速化
- ライブラリ移行・API刷新：これまで数か月を要していた作業の大幅な短縮
特筆すべきは、エンジニアが社内Slackボット経由でエージェントに自然言語で指示を出し、エージェントが自律的にプルリクエストの作成・マージまで完了させる運用フローです。大規模移行用のプロンプトはGitでバージョン管理され、再利用・改善が積み重ねられています。
「検証の仕組み」こそが成功の鍵だった
ここがSpotify事例の最も重要なポイントです。AIエージェントを自律的に働かせるほど、「AIが出した結果を人間がどう検証するか」が成否を分けます。
Spotifyは社内システム「Honk」を通じて、Kubernetes Pod上でClaude Agent SDKを稼働させ、社内ツールと連携させています。当初、AIが生成したプルリクエストの成功率はおよそ25%にとどまっていましたが、「LLMジャッジ（AIによる自動レビュー機構）」を導入したことで成功率は80%まで向上しました。フォーマット、リンティング、ビルド、テストといった検証をプルリクエスト提出前に組み込むことで、人間のレビュー負荷を減らしながら品質を担保しています。
ニクラス氏自身は、tmuxとGit worktreeを使い、5〜10個のClaudeセッションを並行して走らせているそうです。大規模なモノレポだからこそ、Claudeは「近くにある既存コードを参照し、パターンを模倣する」ことができ、一貫性のあるコードベースが逆にAIの精度を押し上げる、という好循環が生まれています。
日本の現場が学べる「活用術」のポイント
Spotifyの事例から、日本企業がすぐに応用できる示唆は多くあります。
1. 「単発の作業依頼」から「継続的な仕組み」へ
ChatGPTやClaudeにその場限りの質問を投げるだけでなく、繰り返し発生する定型的な移行・変換作業を「プロンプトの資産」として管理し、チーム全体で再利用する発想が重要です。
2. 検証プロセスへの投資を惜しまない
AIの出力精度を疑うのではなく、「人間がどう検証するか」の仕組みを先に整えることが成果を左右します。Spotifyの成功率が25%から80%へ向上した背景には、この検証基盤への投資がありました。
3. コードベースの整理整頓がAIの精度を上げる
一貫したコーディング規約や整理されたリポジトリ構造は、人間だけでなくAIエージェントにとっても「読みやすいお手本」になります。AI活用の前提として、社内のドキュメントやコードの整理は依然として価値があります。
4. 非エンジニアの巻き込み
Spotifyではプロトタイピング用途も広がっており、エンジニア以外のメンバーがアイデアを素早く形にする動きも出ています。日本企業でも、企画職やデザイナーが自然言語でAIに指示を出し、試作品を作るような使い方は今後さらに広がるでしょう。
そもそも「Claude Agent SDK」とは何か
Spotifyが使っているのは、チャット画面から質問に答えてもらう一般的なClaudeの使い方ではありません。「Claude Agent SDK」と呼ばれる仕組みで、これはAIエージェントが自律的にタスクを実行できるように設計された開発者向けの基盤です。人間がゴールと制約条件を自然言語で与えると、エージェントは自らコードを読み、変更方針を立て、実際にコードを書き換え、テストを実行し、問題があれば修正を繰り返してからプルリクエストとして提出します。
つまり「質問して回答をもらう」のではなく、「タスクを渡して完了物を受け取る」という関係に近く、これはCowork（Anthropicが提供する非エンジニア向けの業務自動化ツール）にも共通する思想です。Spotifyのケースはこの思想を、最も複雑な領域のひとつである大規模コード移行に適用した、いわば極端な成功例といえます。
他社にも広がる同様の動き
大規模なコード変換にAIエージェントを活用する動きは、Spotifyだけの特殊事例ではありません。Anthropic自身も、決済インフラ企業Bunの共同創業者ジャレッド・サムナー氏が、約100万行にのぼるZigからRustへの移行を2週間足らずで完了させた事例を公開しています。移行後は既存テストスイートの100%がCI上でパスし、マージ後の不具合もわずか19件にとどまりました。
また、製薬会社のNovo Nordiskは、Claude Codeで構築した社内ツール「NovoScribe」により、規制当局向け文書の作成時間を「10週間以上」から「10分」へと劇的に短縮したと報告しています。米Microsoft社内の研究では、数万人規模のエンジニアを4か月間追跡した結果、Claude Codeを導入したエンジニアはそうでない場合に比べてプルリクエストのマージ数が平均24%増加したことも明らかになっています。
これらの事例に共通するのは、「AIに単発の作業を頼む」段階から、「AIエージェントが継続的にプロセスの一部を担う」段階へと利用が進化している点です。
導入を検討する際に押さえておきたい注意点
華々しい成果の裏側には、当然ながら見落とせない論点もあります。
コスト管理は必須
前述のMicrosoft社内研究では、利用が組織全体に広がるにつれてトークン消費量が急増し、一部のヘビーユーザーでは月間のコストが100万ドルを超える例も報告されています。効果測定と並行して、ユーザーごとの利用上限や、チーム単位でのコスト可視化といったガバナンス設計が欠かせません。
「エージェントに任せられる仕事」の見極め
Spotifyの事例が成功した背景には、検証可能なテストスイートや明確なコーディング規約という「土台」がありました。逆に言えば、そうした土台が整っていない現場にいきなり自律型エージェントを投入しても、期待した成果は出にくいということです。
人間のレビュー体制の再設計
AIが生成する変更の量が増えるほど、従来型の「人間が一件ずつ丁寧にレビューする」体制はボトルネックになります。SpotifyがLLMジャッジを導入したように、レビューという工程自体をどう再設計するかが問われます。
まとめ
Spotifyの事例が示しているのは、「AIに丸投げする」のではなく、「AIを組み込んだ開発プロセスそのものを設計し直す」という姿勢です。コード移行時間を最大90%削減し、月650件以上のプルリクエストを自律的に処理する体制は、一朝一夕にできたものではなく、検証の仕組みづくりや運用フローの改善を積み重ねた結果です。
日本企業がClaudeをはじめとする生成AIを本格的に業務へ組み込む際も、単なる「便利ツール」としてではなく、Spotifyのように「検証プロセスとセットで設計する」という視点が、成果を大きく左右するはずです。
本記事は、Anthropic社および関連メディアが公開している一次情報をもとに構成しています。
コメント