VS Codeが月次リリースから週次リリースへ移行するためにエージェントをどう活用しているのか。エージェントを使って開発する全ての人に参考になる内容だ。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
Visual Studio Code(以下、VS Code)はバージョン1.111から、それまでの月次リリースから週次リリースの体制へと移行した。これを可能にするために、VS Codeの開発チームでは何が変わったのか。「How VS Code Builds with AI」では、VS Codeの品質はそのままに、週次のリリースを可能にしたキーポイントを紹介している。以下では、その中から、AIエージェントを使って開発するチームや個人が参考にできるポイントを紹介する。
VS Codeをリリースするまでにはもちろん計画→実装→テスト→エンドゲーム(リリースに向けた最終調整)→リリースといった段階を経ることになる。月次リリースから週次リリースへと移行する際には、計画、チーム全体で互いの機能を横断的に確認するまとまったエンドゲーム期間、リリースノート作成といった工程を、より速く進めるか自動化する必要があった。
週次リリースに移行するということは、バグフィックスや新機能が開発者にいち早く届けられ、「リリース→フィードバック→改善」のループも加速するということだが、その一方で、トリアージすべきissueが増え、追うべきコミットが増え、書くべきリリースノートも増える。つまり、速度を上げると、それに比例してオーバーヘッドも増える。
週次のリリースへと体制を変化させていく中で、VS Codeチームがキーポイントとして挙げているのは以下の6つだ。
どうも。HPかわさきです。
「VS Codeが週次のリリースになるなんて、何をどうすれば、そんなことが実現可能なんだろう」と思った方は多いと思います。ここで紹介しているブログ記事は、そのために何がなされてきたかを紹介するものです。読者の皆さんの日常でも役立つノウハウや知見がそこにはあるかもしれません。気になった方はぜひ「How VS Code Builds with AI」にも目を通してみることをオススメします。
以下では、これらのキーポイントの中から幾つかの話をかいつまんで紹介していこう。
「自分自身を並列化する」とは今手掛けている作業とは別の作業に取り掛からなければならなくなったときに、それまでの作業や新たな作業をエージェントに任せることで、並列に作業を進めるようにするということだ。例えば、ミーティングに入る前に幾つかのエージェントセッションを起動し、バグ修正や新機能のプロトタイプ作成、issueのトリアージを並列で回しておけば、ミーティングが終わった後にエージェントの結果をレビューしたり検証したりして、問題なければマージすればよいし、問題があれば再度プロンプトを入力して作業をもう一度エージェントに任せられるだろう。
ミーティングのときにやることも変わった。以前は、ミーティング中にメモを取り、その後でメモを基にissueを立て、誰かに割り当てるといった作業を順番に行っていた。今では文字起こし機能を使えば後から文脈を取り出すのも難しくないため、必要な作業が見つかった時点でその場でエージェントを起動すればよい。
「自分自身を並列化する」とも関連するが、従来は「ミーティングメモ→issue→仕様書→コード」という流れになりがちだったが、エージェントを活用することで「ミーティング→エージェントの起動→コード→PR(プルリクエスト)」へと短縮されることが多くなってきた。例えば、ミーティングの後、プロダクトマネジャーがメモから中間成果物である仕様書を書くのではなく、エージェントを使って動くプロトタイプ=実際のPRを作成できるようになった。
仕様書は仮説の文書であり、実際に作ってみるまで正しいかどうかは分からない。PRならその場で動かして確認でき、担当エンジニアとのやりとりも仕様を間に挟むよりはるかに速く前進する。最初のPRが完璧である必要はなく、アーキテクチャが適切でなければ作り直せばいい。なお、これはコードベースがどれくらいエージェントに対応したものになっているかを試すリトマス試験紙でもある。エージェントが適切なコンポーネントを見つけて妥当なPRを返せるなら、コードベースの構造とドキュメント、テストカバレッジが整っている証しといえる。
月次から週次のリリースになるということは、リリースに伴うオーバーヘッドも増えるということだ。トリアージしなければならないissueは増え、追跡しなければならないコミットも増え、書かなければならないリリースノートも増える。
そこで、VS Codeチームは過去24時間分のコミットを複数リポジトリから取得して要約するカスタムスラッシュコマンドを構築したとのことだ。issueのトリアージについても、以前は週替わりで1人の担当者が全てのissueをトリアージしたのをやめて、GitHub Actionsのエージェントループで自動化するようになったそうだ(登録のたびに重複の検出やオーナーの特定、ラベルの提案が行われる)。
この結果、前年同期比でコミット数は約2倍に増加し、クローズされたissue数も約3倍になったという。
エージェントは便利だが、生成されたコードの品質を保証するものがなければ、最初は快適でも、すぐに進捗(しんちょく)は滞ることになる。そこでVS Codeチームでは幾つかのハーネス(あるいはガードレール)を作成したとのことだ。
例えば、Playwright MCPサーバを使って検証を行うカスタムエージェントを作り、ユーザー体験の検証をエージェントループの中で行えるようにしている(VS Codeを起動し、対象機能へナビゲートし、スクリーンショットを撮り、期待する動作に合っているかどうかを評価し、壊れていれば修正まで行う)。また、テストにおいては、ユーザーが操作を行う中で期待される動作を記述した「ゴールデンシナリオ」を、エージェントがマージ後に自動実行する仕組みも整えた。コードレビューは全PRにCopilotのレビューが自動付与され、人間にレビューを依頼する前に担当エンジニアはそのコメントを解決することが標準になっている。
「オーナーシップの進化」とは、コードを書く人と、その結果に責任を持つ人との関係が変わってきたということだ。
VS Codeチームでは、エンジニアだけがコードに手を入れるわけではない。先ほども述べたようにプロダクトマネジャーがミーティング中にエージェントを起動して、動くプロトタイプを作ることもあれば、他チームのエンジニアや外部コントリビューターが関与することもある。もちろん、エージェントも多くのコードを書いている。こうした状況では、コードの書き手という意味でのオーナーシップはこれまでよりも広く分散している。
その一方で、変更をプロダクトとして受け入れて、その品質や設計についての最終的な責任を持つのは、依然として担当エンジニアである。つまり、書き手という意味でのオーナーシップは広がる一方で、最終責任を持つという意味でのオーナーシップはむしろ明確になっている。これが、ここでいうオーナーシップの進化だろう。
これは人間によるレビューの質が変わってきたことを意味する。つまり、エージェントが生成するコードやPRが増えてきたときに、人間がチェックするのは「この変更はこのプロダクトで意味があるものか?」「長期的に見て、それはアーキテクチャに合った変更なのか?」「使用感がよいか?」といった判断をするのが人間の側の役割になりつつある。エージェントはバグを見つけることはできても、ある機能を気持ちよく使えるかどうかまでは分からない。
エンドゲーム期間では、プロダクトマネジャーの側では「センスに基づいた評価」を行っているそうだ。これはある機能について期待される定性的なユーザー体験をまとめたものと、実装が合っているかどうか、エージェントを使って評価するというもの。エージェントの観察のうち、80%は役に立つが20%は無視することになるが、それでもこれは十分に役に立っているようで、ドキュメントについても同様なアプローチを適用することが検討されている。
いかがでしょうか。個人的には自分自身を並列化する、速度の前にハーネスに投資する、センスは人間の側で担うといった要素はエージェントと人間が協働して、効率的に開発を進めていく上ではとても重要なことに感じました。
特に自分自身を並列化するのは、今日にでも実践できる内容ですよね。ハーネスに投資するというのは仕様駆動開発や各種のmdファイルでどれだけエージェントの振る舞いを定められるかにも通じることでしょう。そして、最後はやはり人間が責任を取ることになります。VS Codeはコードを記述するためのエディタとして登場しましたが、生成AIの隆盛とともにその役割を変えつつあります。同じようなことが、そのユーザーである開発者にもいえるのかもしれませんね。
さて、ぼくもこの後のミーティングをエージェントに任せて、自分はお昼ご飯でも食べにいこうかな(違う、そうじゃない)。
Copyright© Digital Advantage Corp. All Rights Reserved.
編集部からのお知らせ