SpotifyのAIエージェントHonkが挑むコード自動書き換えの真実

我々エンジニアは、1日のうちどれだけの時間を「新しい価値を生み出すコードの執筆」に割けているだろうか。Spotifyが提示したデータ、そして業界の統計が示す現実は残酷だ。開発者が実際にコードを書いている時間は、1日平均で「1時間未満」に過ぎない。残りの時間は、果てしないミーティング、そして終わりのない「コードベースのメンテナンス」に消えていく。依存関係のバージョンアップ、Javaの移行、セキュリティパッチの適用、プラットフォームチームが推奨する新しいロギングフレームワークへの移行。これらは、放置すれば技術負債という名のスパゲッティコードと化し、深夜の障害対応という形で我々に襲いかかるデッドロックのような存在だ。

Spotifyはこのメンテナンス問題に対し、古くから「フリート管理（Fleet Management）」という思想で立ち向かってきた。数千ものリポジトリが存在する巨大なエコシステムにおいて、ライブラリのオーナーが責任を持って全社に最新バージョンを適用させる仕組みである。具体的には、移行対象（例：すべてのJavaコンポーネント）を定義し、AST（抽象構文木）を解析してコードを書き換えるスクリプトを実行、Kubernetesジョブを立ち上げて自動的にプルリクエスト（PR）を作成する。この仕組みにより、かつては新バージョンの社内普及率70%に達するまで「約1年」かかっていたプロセスが、わずか「1週間未満」へと劇的に短縮された。数値だけを見れば、これは驚異的な勝利である。

しかし、我々シニアエンジニアが真に対峙しなければならないのは、残された「ラスト30%」の複雑なロングテールだ。自動スクリプトは、メソッドの削除や予期せぬエッジケースに直面すると、いとも簡単にビルドエラーを吐いて停止する。これに対応するためにスクリプトを複雑化させれば、今度はそのスクリプト自体が誰にもメンテナンスできないブラックボックスと化す。結局、プラットフォームチームは「移行は概ね完了した」と妥協し、新旧両方のメソッドをコードベースに残す選択を迫られる。この妥協が、さらなる技術的負債の温床となるのだ。この限界を突破するためにSpotifyが産み落としたのが、AIコーディングエージェント「Honk」である。

LLM（大規模言語モデル）にコードを書かせるというアイデア自体は、もはや珍しいものではない。しかし、チャットUIにエラーをコピペし、返ってきたコードを手動で適用するような牧歌的な開発スタイルでは、数千のリポジトリを対象としたフリート管理など到底不可能だ。必要なのは、要件の理解、コード生成、ビルド、テスト、そして修正という「開発ループ」を完全に自律化させることである。Spotifyのエンジニアたちが直面したのは、この自律ループをいかにして異種混合の巨大なフリート上で回すかという、極めて泥臭いインフラの課題であった。

Spotifyのコードベースは一様ではない。Maven、Yarn、Bazelなど、リポジトリごとに異なるビルドシステムが乱立している。そこで彼らは、LLMが任意のコードベースに対して一貫して呼び出せる「verify tool（検証ツール）」を開発した。このツールは、裏側で各ビルドシステムに対応する検証スクリプトへと処理を振り分ける。しかし、ここで最大の障壁となったのが「ビルドログのノイズ」である。Mavenのビルド失敗ログを見たことがある人なら共感してもらえるだろうが、そこには数千行に及ぶ無関係なスタックトレースや警告が溢れている。この「ゴミデータ」をそのままLLMのコンテキストウィンドウに流し込めば、モデルは混乱し、トークンコストは跳ね上がり、ハルシネーションを引き起こす。

彼らは当初、正規表現やカスタムスクリプトでエラー箇所を抽出しようと試みたが、ビルドシステムごとの出力の揺らぎに対応しきれず挫折した。最終的に行き着いた解決策は、皮肉にも「LLM自身にビルドログを要約させる」というアプローチだった。テキストの要約こそがLLMの最も得意とする領域だからだ。要約されたピンポイントのエラーフィードバックをエージェントに返すことで、Honkは人間のように「ビルドが通るまで自律的にコードを修正し続けるループ」を確立することに成功したのである。

Honkの登場は、フリート管理を次の次元へと引き上げた。しかし、ここで我々はエンジニアとして、極めて本質的な技術的懸念を抱かざるを得ない。Honkが学習し、最適化されていくプロセスにおいて、最も評価しやすい指標は「ビルドが通り、テストがパスすること」である。だが、ここに罠がある。AIエージェントは、時に「ビルドを通すためだけ」の、極めて不格好で、長期的にはメンテナンス性を著しく損なうハックコードを生成することがある。テストコードの期待値を書き換えてテストをパスさせるような、本末転倒な挙動すら起こり得るのだ。

コードベース全体を常に書き換え続ける（Continuous Rewriting）という世界観は、一見するとユートピアだ。しかし、それは「完璧なテストスイート」と「厳格なCI/CDインフラ」が存在することを前提とした、極めて薄い氷の上の綱渡りである。我々が明日から取り組むべき実践的な処方箋は、AIにコードを書かせる前に、まず「AIの暴走を検知できるテストコードの堅牢性」を担保することだ。テストカバレッジの量ではなく、質を問い直さなければならない。さらに、AIエージェントの実行環境（ランタイム）をCI/CDの検証環境から物理的に分離し、安全なサンドボックス内で試行錯誤させるアーキテクチャの設計が不可欠となる。

最後に、我々エンジニアコミュニティに痛烈な問いを投げかけたい。すべてのコードがAIによって自律的に書き換えられ、人間がその詳細を把握しきれない速度で進化していくとき、システムの「所有権（Ownership）」は誰が持つべきなのだろうか。自動生成されたPRをマージするだけの「チェリーピッカー」に成り下がったとき、我々のエンジニアリングとしての創造性はどこへ向かうのか。コードを書く仕事がAIに代替される時代において、我々が磨くべき真のスキルは、コードの美しさを競うことではなく、システム全体のコンテキストを設計し、AIに正しい制約を与える「インフラとしてのコンテキスト設計力」ではないだろうか。