Claude公式の対談シリーズ「Office Hours with Boris Cherny」から、今回はSpotifyのチーフアーキテクト兼エンジニアリングVP、Niklas Gustavsson氏の回を紹介します。Spotifyでは今、プルリクエストの73%がAI起筆。アイデアを持つ人なら誰でも1〜2時間で動くプロトタイプを作れる環境が整っています。2,900人のエンジニア組織と2,000万行超のコードベースで何が起きているのか——対談の要点を読み解きます。

Gustavsson氏の経歴はユニークです。もともと分子生物学者で、ゲノムシーケンスの大量データを扱うためにプログラミングへ転向し、気づけば業界歴約30年。Spotifyには2011年から在籍しています。

個人的なブレイクスルーは、2025年11〜12月のOpus 4.5だったといいます。「賢いオートコンプリート」から「実際の問題を丸ごと投げられる存在」への転換で、大したプロンプトエンジニアリングも不要になった、と。

象徴的なエピソードがあります。前年9月、Cherny氏から「年末には誰もIDEを使っていないと思う」と言われ、内心「それはさすがにない。2年ならあり得るが2ヶ月は極端だ」と思ったそうです。そして2ヶ月後、自分がIDEを使わなくなっていた——30年のキャリアで見たことのない働き方の変化だった、と振り返ります。現在は、ターミナルに5〜10個のタブでClaudeセッションを並べ、git worktreeと組み合わせた「セッションと端末のマトリクス」で複数エージェントを並行稼働させるスタイルです。

Spotifyのバックエンドは2,000万行超。巨大モノレポとエージェントの相性を当初は心配していた(過去のツールではインデックス問題があった)ものの、結果は「驚くほどうまく動く」。理由のひとつは、Claudeがリポジトリ内の他のコードを読んで、解こうとしている問題のヒントを得るのが上手いこと。ただし、自社のツーリングを理解させるためのCLAUDE.mdの反復改善は必要だったといいます。

この対談の白眉が、社内ツール「Honk」の物語です。5〜6年前、Spotifyはコードベースがエンジニア数の7倍の速度で成長していることに気づきます。ライブラリ更新やJavaバージョン移行のようなメンテナンスは、数百のチームが数千のコンポーネントに同じ作業を手作業で繰り返す構図で、1つの移行に数ヶ月、年に10件が限界。社内調査でも「最も嫌われる作業」の筆頭でした。

そこで、コードベース全体に一括変更をかける「フリート管理」基盤を構築し、決定論的スクリプトで数百万件のPRをマージしてきました。しかし壁に当たります——コードのAPI表面積は膨大で、たった1つのメソッド差し替えでも呼び出し方が5通りあれば、スクリプトはエッジケース対応で数千行に膨らむ。静的解析(AST変換)アプローチの限界です。

初期のLLM(Claude以前)をこの問題に当てたときは、コードを見せてワンショットで変えさせる素朴なやり方でうまくいかず。しかしモデルの進化と手法の進化——LLM-as-judge(判定役LLM)の導入、問題の分解——を重ねるうちに光が見え、それが統合されてHonkになりました。今は「V2」と呼んでいるが実質はV8くらいだ、という反復の跡も正直です。そして興味深いのは、当初PR成功率を20〜30%から80%に引き上げた立役者のjudgeを、今は撤去したこと。モデルとエージェントハーネスが追いついて、不要になったのです。

現在のHonkは、Claude Agent SDKをKubernetes Pod上で動かすシンプルな構成。以前は許可リスト制だったツールも、今はユーザーが自分で追加でき、社内のあらゆるツールに繋げます。最重要のツールは検証——LinuxとmacOSの両方でCIビルドを実行でき(iOS開発にはmacOSが必須)、シミュレータとの統合ではFigmaのデザインからUI実装まで自動化し、TVアプリへの移植にも活用されています。用途もコード変更のオーケストレーションから広がり、Slackでメンションしてタスクを頼む、ユビキタスな存在になりました。

Cherny氏が「クローズドループ開発で唯一最重要なのに、各社が投資不足なのが検証だ」と指摘すると、Gustavsson氏はSpotifyの実体験で応じます。Spotifyには強いソフトウェアオーナーシップ文化があり、数千のコンポーネントそれぞれに責任チームがいる。かつては全変更にオーナーチームが目を通せたので、テスト自動化が甘くても許された。しかし自動マージ(チームがPRを見ないまま統合)を始めるにあたり、どんな自動変更にも耐えるテスト自動化への投資が不可欠になった——そしてその投資が、今エージェントを安心してコードベースに放てる土台になっている、と。

結果として、品質指標を中立に保ったまま速度を大幅に向上。Spotifyは1日約4,500回の本番デプロイを回し、アイデアから本番までの時間は、数年前の「数週間〜数ヶ月」から約1時間にまで縮んでいます。

計測の現在地も明快です。AIツーリングに直接起因するPR頻度の75%超改善、PRの73%がAI起筆。ただし次の課題は、それをユーザー価値と収益に接続すること——PRやデプロイを「ワークアイテム(計画された仕事)」に紐づけ、さらにA/Bテストとロールアウトに接続して、「このPRがこのユーザー価値に貢献した」と遡れる仕組みを構築中です。改善が誰の目にも明らかだった初期と違い、成熟するにつれてROI推定の精度への期待も上がっている、という指摘は多くの企業に刺さるはずです。

もうひとつの大きな投資がプロトタイピング基盤です。自然言語でアイデアを表現すれば、実際のモバイルアプリとバックエンドでエンドツーエンドのプロトタイプが作れる仕組みを整備し、社内アプリストアで共有・試用できるようにしました。以前なら「エンジニアチームを説得して作ってもらう」必要があったアイデアが、1〜2時間で、実ユーザー・実データ付きの動くプロトタイプになる。検証にかかる時間は数週間〜数ヶ月から1日へ。作っているのはエンジニアだけではなく、共同CEOたちのプロトタイプまでアプリストアに並んでいるそうです。

リーダーへの助言は一貫しています。テスト自動化と検証、そして標準化——一貫したコードベース、ツールとフレームワークの統一——への基盤投資を怠るな。もともと人間の生産性のための投資が、そのままエージェントに効く。コードが10通りの書き方をしていればClaudeも混乱する。「コードベースに新しいアクターが入っただけで、エンジニアリングの基本は等しく通用する」という言葉が、この対談の結論です。

エンジニアへの助言は、個人的な告白として語られます。趣味で競技プログラミングをするほど問題解決が好きな自分は、「解く楽しみ」を失うのではと不安だった。しかし間違っていた——自分が好きなのは問題を解くことであり、どう解くかは本質ではなかった。今は5つのエージェントを背後に走らせながら、以前なら数日〜数週間かかったコードベースにも飛び込んで貢献できる。人によって移行の形は違うだろうが、まず試して自分に合う使い方を見つけてほしい、と。

DoorDash回が「プロセスの再発明」の話だったとすれば、Spotify回の主題は「基盤investの複利」です。7倍速で膨らむコードベースという課題に始まり、決定論的スクリプト→LLM+judge→judge不要のエージェント、という段階的な進化。そしてどの段階でも効いたのは、テスト自動化・検証・標準化という地味な基本でした。「judgeを撤去できた」という話は、AIシステムの設計が固定ではなく、モデル進化に合わせて引き算していくものだという示唆でもあります。エンジニアリング組織の長期投資を考える人に、最も参考になる回だと思います。

INNOOV株式会社について

この記事は、AtlassianやIntercomなどのSaaS導入支援と、AIを活用した業務プロセス改善を行うINNOOV株式会社がお届けしました。「自社でもこんな仕組みを作ってみたい」「ツール導入を相談したい」という方は、お気軽にお問い合わせください。

▶ INNOOV株式会社 公式サイト

参考文献　Spotify | Office Hours with Boris Cherny | Claude by Anthropic