コーディングはもはや constraint ではない — Niklas Gustavsson (Spotify) が公開する Honk V2 と「99% AI 採用」後の Spotify 組織変容 (Code w/ Claude London 2026)

Code w/ Claude London 2026 — Niklas Gustavsson / Spotify 2026/05/20

ニクラス・グスタフソン / Niklas Gustavsson · 02:55 「by far、我々が今 ship している PR の大多数は AI agent と開発者の共著によるもの。コーディングはもはやボトルネックではない」

Code w/ Claude London 2026 (2026/05/19 開催、 2026/05/20 公開、約 27 分 36 秒)。講師はニクラス・グスタフソン (Niklas Gustavsson、 Spotify Chief Architect 兼 VP of Engineering、在籍 15 年)。 Spotify の約 3,000 名 engineering 組織が、 Opus 4.5 リリース (2025-11) を境に Claude Code 採用が爆発し、 6 ヶ月後の 2026/05 時点でどう変容したかを社内データで公開する 27 分。内部 tool 「FleetShift」「Honk」「Honk V2 (alpha)」「Chirp」と、それを支える Backstage Developer Portal の標準化思想を体系的に提示する。

Niklas Gustavsson の Code w/ Claude London 2026 講演は、「AI coding tool 採用が一巡した大企業エンジニアリング組織で何が起きるか」を 6 ヶ月分のデータで答える最初の公的レポート。同じく Code w/ Claude で Anthropic の Boris Cherny が Claude Code 全体ロードマップを語った文脈の中で、顧客側 (Spotify) が「採用後の実態」を裏付ける役割を担う。

MEMEX 編集視点で重要なのは、講演が示すのは個別ツールの紹介ではなく organizational thesis である点。「FleetShift も Backstage も標準化思想も pre-AI 時代に作った。だから AI が来た時に Honk を上に乗せられた」という時系列の含意は、後発企業に対する暗黙の警告でもある。同じ Intercom の Claude Code 2x や PFF の post-engineer org と並ぶ、「採用 1 年後の AI engineering 組織」シリーズの中核データ点。

採用曲線 ── Opus 4.5 が境界線

Niklas が冒頭で示す事実: 「我々は社内ツールを常にロールアウトしているが、 AI coding tool で見たような採用曲線は今まで一度も見たことがない」。グラフでは Claude Code (オレンジ) が他のツール群と比較して急上昇曲線を描く。 inflection point は 2025 年 11 月の Opus 4.5 リリース。ここから Claude のみならず AI tool 全般の使用が「completely bananas」状態になった。

6 ヶ月後の 2026/05 時点での社内数値:

engineer の 99% 超 (Niklas 提示数値) が AI coding tool を週次で使用
94% の engineer が AI tooling で生産性が向上したと自己評価 (record high)
+76% の PR frequency 増 (講演準備中も伸び続けたため数値を何度も書き換えた、と Niklas)
Niklas の表現で「by far the majority」 (圧倒的大多数) の PR が AI agent + developer の共著 (auto-generated だけでなく開発者との協働も含む)

PR frequency の増加曲線もまた Opus 4.5 リリースで急上昇している、と Niklas は指摘する。

FleetShift ── pre-AI 時代に作られた前提条件

Spotify の AI 移行が円滑に進んだ理由として Niklas が真っ先に挙げるのは、 AI 以前から準備していた基盤。数年前、 Spotify は production codebase が engineer 数の 7 倍速で成長していることに気付いた ── engineer 1 人を雇うごとに、既存コードベースに engineer 7 人分の追加 maintenance 負荷が積み上がる構造。結果として engineer は新機能を作るより既存 codebase の maintenance に時間を吸い取られる状態になっていた。

FleetShift : 「component 単位で手動 migration」を捨て、「fleet 全体を一斉に mutate する」発想で構築されたシステム ── 車のフリート 100 台に同じパーツ交換を 1 台ずつ手で施す代わりに、工場ラインの設定を 1 行書き換えれば 100 台が同時に更新される、という構造に近い。 1 つの shift 定義から数千 component に対する PR を生成、 CI で検証、安全と判定したら auto-merge する。累計 250 万件の自動 maintenance PR を merge した実績。

「これは pre-AI の話」と Niklas は強調する。単純な変更 (dependency bump、 configuration 更新) には FleetShift の決定的 script で十分機能した。ただし API 置換のような複雑な変更では、全 corner case を script で網羅する必要があり ── Hyrum's Law によって ── 移行 script が非現実的に巨大化していた。

Honk ── Claude Agent SDK を pod に閉じ込めた harness

LLM 出現後、 Spotify は「決定的 script の代わりに LLM で code modification をやらせられないか」という方向で何度も iteration を重ねた。「最初はモデルが too stupid で、我々の使い方も too stupid だった」が、モデル改善と試行錯誤を経て生まれたのが Honk。

Honk のアーキテクチャは Niklas が公開する範囲で以下:

中核に Claude Agent SDK を採用
Spotify 独自の harness で SDK をラップ
Kubernetes pod として cloud 環境にスケジュール、多数の Honk job を並行実行
trusted tools 一式を agent に提供 (verification tools のみが図示されたが、他にも多数)
verification には Spotify の CI environment で実コードビルドを走らせる (multi-OS、 client は複数 OS で動くため)

Honk と FleetShift の関係: FleetShift が orchestration を担当、 Honk が個別 component の code modification を担当する 2 層構造。 team 単位の UI からは「現在の shift で何件 PR 作成、何件 merge、何件 CI 失敗」を可視化できる。

具体的成果として Niklas が挙げたのは、 Java migration が 3 日で完了したケース。 Spotify backend は JVM 上で動く 4,000 万行モノレポ (= 単一書籍に換算すると約 80 万ページ規模) で、旧来であれば数百 team に migration path を配って「数週間〜数ヶ月」かかっていた作業を、 1 人の engineer が 3 日で完遂した。これは Tejas Kumar の harness 体系化が production scale で実装された事例と言える。

Honk V2 ── Slack 経由から multiplayer agent へ

Niklas は講演前日 (hack week 期間中) に Honk V2 alpha をリリースしたと公表。「v2 と呼んでいるが実際は 8 番目の版なので versioning は適当」と冗談を挟みつつ、大きな機能拡張を提示。

きっかけは organic な user behavior: 「Honk を migration 以外にも使いたい」という engineer が自発的に Slack 経由で Honk を呼び出し始めた事実。 Slack 会話中に @honk でメンションすると、 Honk が裏で作業し PR を返してくる、という運用パターンが社内で広がっていた。

Honk V2 はこの user pattern を一級市民として再設計:

Chirp ── agent orchestration tool。 Claude Agents や AgentDeck に近いが、 Spotify infrastructure に深く統合。多数の agent session を並列で coordinate する
Chirp 経由で Honk job をスケジュール可能
Multiplayer collaboration ── 「Google Docs for Claude」と Niklas が表現する機能。 1 つの agent session に複数の開発者が参加し、 feedback / アイデアをリアルタイムで共有可能
Project 単位の上位構造 ── 新機能や新製品単位で project を作成、その下に複数の Honk session を抱え team で共通目標に向かって協働
any device 対応 ── デスクトップに縛られず、出先からも agent と対話

Niklas が個人的に最も興奮していると述べたのは multiplayer 機能。「agent が複数の開発者・team とどう協働するかを想像し直す段階に入った」。これは Anthropic の long-running agent workshop が前提とした「人が agent を babysit する」単独モデルから、 multi-human + agent の collaborative モデルへの進化を示す。

Backstage と標準化 ── agent を効果的にする土壌

講演後半で Niklas が掘り下げるのは、もう 1 つの pre-AI 投資である Backstage。 Spotify が developer portal として開発し、 OSS 化したものを社内では production で運用している。

起源は素朴: Backstage 以前の Spotify には開発者が触る tool が 100 ほど散在しており、「どれが deployment、どれが CI、どれが A/B test」と把握困難な状態だった。「all of those tools were kind of shit as well」 (どれも大して良くなかった) ため、統合する portal が必要になった。

Backstage の最初の機能は単純に「全 software component の owner を引ける catalog」だった。 incident 発生時に owner team に page を送れるよう、 component → owner の対応表を作ることが起点。そこから数年かけて catalog 上に多数の tool を統合、「人間 developer がアクションを取る時の中央集約点」に育った。

AI 時代の Backstage の二次効果: 全てのアクションが MCP / CLI 経由で agent にも公開された。 Claude が owner を検索し、必要に応じて Slack で team に質問を投げることまで可能になった。「Backstage は human developer 向けだったが、そのまま agent 向け portal として機能する」。

少ない技術で動く ── 標準化が agent 性能に効く

Niklas が 15 年信奉してきた信条: 「使う技術が少ないほど速く動ける」。これを実装するため Spotify は:

Technology Radar ── 利用可能な技術リストと推奨ステータス (recommended / not recommended)
Golden State ── component 種別ごとに「この種類の backend service ならこの技術スタック」という推奨セット
Soundcheck UI ── 自 team の component が golden state にどれだけ準拠しているかを self-assess する UI (例: valid owner が定義されているか)
Static analysis + linting ── 上記ルールを実装した lint check が codebase に組み込まれ、違反は即時 feedback として返る

AI 時代の予期せぬ効果: 「Claude が周囲のコードを見て真似する時、コードが一貫していれば Claude もより良い仕事をする」。逆に fragment 化した codebase では Claude の出力品質が落ちることが社内データで観測されている。「Claude が最適でない gRPC 呼び出し方を生成しても、 lint が即座に correct を返す」 ── 標準化と lint が agent への training wheel として機能する構造。

ボトルネックの転位 ── coding から product decision へ

講演末尾で Niklas が提示する構造的予測: 「coding がボトルネックだった時代は終わりつつある」。 Spotify では既に prototype 作成に関して劇的な変化が起きている。

従来の prototype: 「数日〜数週間。 engineer を説得して時間を割いてもらう必要があった」 → Claude + skills 整備後: 「literally minutes。 production codebase 内で誰でも Claude に prompt を出して prototype を生成、 install 可能な app として配布、社内検証へ」。「Spotify の CEO の 1 人もこれで prototype を作っている」と Niklas は明かす。

この変化が示す構造: coding という制約が緩むと、ボトルネックは human decision-making に移る ── 何を ship するか、どのアイデアを探索するか、という product 判断。これらは coding capacity に制約されていた時代にはそんなに頻繁に下す必要がなかった判断であり、「6 ヶ月後の我々の製品開発は今と大きく違って見えるはず」と Niklas は予測する。

副作用: PR frequency 76% 増は同時に PR review 負荷 76% 増でもある。「現時点で最も頻繁な不満は too many freaking PRs to review」。 Spotify は既に「safe enough と判断した PR は人間 review なしで auto-merge」する運用を一部で開始しており、「人間の判断をどこに集中させるか」の再設計が継続中。

編集所見 ── MEMEX の業界軸として

Niklas の講演を MEMEX で取り上げる視点は 3 つ。

(1) 「AI 採用 1 年後」の最初の公的データ点として価値が高い。多くの企業が「Claude Code を導入した」段階で止まっている中、 Spotify は 99% 採用 + 76% PR 増 + Java migration 3 日完了という具体数値を公表した。これは Intercom の Claude Code 2x と並ぶ「定量的成果報告」の数少ない事例。

(2) Pre-AI infrastructure 投資が AI 時代に二次効果を生む構造論。念のため最初に書いておくと、これは Honk という個別ツールの紹介ではなく、 Honk を乗せられる土壌があるかどうかの話。 FleetShift (fleet management)、 Backstage (catalog)、技術標準化、全社 lint ── これらは AI 普及前に作られた pre-AI 投資である。 Niklas の暗黙の主張は「Honk だけ真似ても Spotify の成果は再現できない。土壌が要る」。この主張は Tejas Kumar の harness 6 要素や Pedro Rodrigues の skill 設計が示す「個別技法」の上位に位置する「組織能力」のレイヤーを描く。

(3) ボトルネックの転位という構造予測。考えてみると、「coding がボトルネックだった時代」の終わりは、 engineering 組織の根本前提を揺るがす。「coding constraint → product decision constraint」は単なる Spotify の話ではなく、業界全体に対する仮説。もし正しいなら、 PdM / Designer / 経営判断の重要度が相対的に上昇し、 engineer の役割は「書く」から「決める / 検証する」へシフトする。 MEMEX が観測する 10 Downing Street の Insurgency Model や PFF の post-engineer org と同じ「engineer の役割再定義」系の業界軸に Spotify のデータが乗る形。

MEMEX が Niklas の講演を取り上げる理由は、 (1)(2)(3) のいずれにも繋がるより大きな問いがあるため ── 「AI が constraint を消した後、 engineering の専門性は何処に残るのか」。 Niklas は「verification と engineering practice は廃れない」と答えたが、これは仮説であり、 6 ヶ月後・1 年後の別企業のデータと突き合わせるべき問いとして MEMEX archive に残す。

動画の構成

(00:00) 導入、 Spotify の規模感 (engineer 約 3,000 = 大学院 1 学部相当の規模、 1 日 4,500 deployment、 backend 40M LOC monorepo + 数千 polyrepo)
(01:11) AI 採用曲線 ── Opus 4.5 で爆発、 99%+ が週次で AI tool 使用
(02:08) 94% が生産性向上を自己評価、 record high
(02:30) PR frequency +76%、大多数が AI agent + developer 共著
(03:23) Pre-AI: codebase が engineer の 7 倍速で成長していた問題
(05:13) FleetShift の仕組み、累計 250 万 PR を auto-merge
(06:00) 単純変更には十分、複雑変更で Hyrum's Law に阻まれる
(07:10) LLM での code modification を初期から試行 (pre-Claude)
(07:44) Honk の誕生、名前と icon は silly でも実用性は高い
(08:17) Honk アーキテクチャ ── Claude Agent SDK + 独自 harness + Kubernetes pod + verification tools
(10:15) Java migration が 3 日で完了した実例
(10:30) Backstage Developer Portal Premium 経由で商用提供開始
(11:00) Slack 経由 Honk 呼び出しが organic に発生
(11:30) Honk V2 alpha リリース ── Chirp、 multiplayer、 project、 any device
(13:30) Spotify 標準化思想「使う技術が少ないほど速い」を 15 年継続
(15:13) 標準化が agent 性能にも効くとの観測
(16:11) Backstage の起源 ── 社内 100 tool を統合する catalog から始まった
(17:55) Agent も Backstage を MCP / CLI 経由で利用、 owner 検索や Slack 通知
(18:11) Technology Radar、 Golden State、 Soundcheck UI による標準化
(19:39) Lint / static analysis が agent への即時 feedback として機能
(20:31) まとめ ── engineering practice は廃れない、 verification の重要性
(22:06) Human judgment の配置を再設計 ── PR review 負荷 76% 増の副作用
(23:19) ボトルネックの転位 ── coding から product decision へ
(24:50) Prototype が数日〜数週 → minutes に短縮、 CEO まで prototype 作成
(26:00) 「6 ヶ月後の製品開発は今と大きく違うはず」予測
(27:00) 締め、 FleetShift / Honk の commercial offering 案内

関連リソース

出典