VS CodeはどのようにAIで構築されているのか

2026年3月13日 投稿者: Pierce Boggan

私たちはVS Codeをリリースするために、日々AIを活用しています。AIのおかげで開発速度が劇的に向上し、10年間続いた月次リリースから、ついに週次リリースへと移行しました。この変革の鍵となったのはエージェントの活用です。単なるコード記述だけでなく、チームのあらゆる作業プロセスにおいてその威力を発揮しています。

Agent Sessions Dayの幕開けとして、私はVS CodeチームのエンジニアリングマネージャーであるPeng Lyuと対談し、VS Codeチームが日々の業務で実際にどのようにAIを活用しているかを探りました。機能の実装（これは言うまでもありませんが）だけでなく、トリアージ、コードレビュー、リリースノートの作成、検証、そして会議の多いスケジュールの中での生産性維持など、機能開発を「取り巻く」あらゆる業務について議論しました。

このセッションで取り上げたのは、チームがエージェントを使って日々行っていることのわずか5%程度に過ぎません。しかし、これは数百万人の開発者に利用されている製品がどのように作られているかを象徴するものです。そこで、私たちのワークフローにおける最近の大きな変化と、私たちが次に向かう先について、さらに詳しく共有したいと考えました。

10年間の月次リリースを経て、週次リリースへ

私たちは10年間、VS Codeを月次サイクルでリリースしてきました。毎月、「計画、構築、テスト、エンドゲーム（最終調整）、リリース」という完成されたサイクルを繰り返してきました。チームの各メンバーがさまざまな役割をローテーションするこのリズムは、チーム文化の一部となっていました。

最近、私たちはVS Codeを週次でリリースすることに決めました。同時に、厳格さと品質の基準はこれまで通り高く維持したいと考えました。月次サイクルには、計画を立てる時間、チームがお互いの機能をクロスチェックするエンドゲーム週を設ける時間、そして詳細なリリースノートを書く時間を確保する余裕がありました。これを週次で行うには、これらすべてを高速化するか、自動化しなければなりません。これは非常に大きな変化であり、1年前の私たちには不可能だったでしょう。このシフトが可能になったのは、エージェントが私たちの働き方を一変させたからです。

週次のリリースサイクルは、単に速くリリースするためのものではありません。改善をより早く開発者に届けるためのものです。かつては次の安定版リリースまで3週間待たなければならなかったバグ修正が、今では数日でリリースされます。月曜日にマージされた機能が、その週のうちに開発者のエディターに届くのです。「リリース > 学習 > 反復」というフィードバックループが、劇的に高速化されました。

この変化から学んだこと

私たちのワークフローとプロセスは、学びと適応を経て日々進化しています。その中で、一貫して真実であり続けている重要な教訓がいくつかあります。

1. 自分自身を並列化する。 コンテキストを切り替える前に、複数のエージェントセッションを開始する習慣をつけましょう。ワークツリー、クラウドエージェント、複数のVS Codeセッション…これらをすべて活用してください。
2. 中間成果物をスキップする。 かつての「会議メモ → イシュー → 仕様書 → コード」という流れは、今や「会議 → エージェントセッション → コード → プルリクエスト（PR）」へと変わりつつあります。
3. 速度に比例して増大するオーバーヘッドを自動化する。 私たちは、Copilot CLI、Copilot SDK、GitHub Actionsを使用して、イシューのトリアージ、コミットの要約、リリースノート、コードレビューのためのエージェント駆動型パイプラインを構築しました。これらのワークフローの終端には依然としてエンジニアが存在しますが、エージェントは適切な情報を適切な人物に、より速く届ける手助けをしてくれます。
4. スピードの前にハーネス（ガードレール）に投資する。 テスト、ゴールデンシナリオ、コードレビューのゲートは、エージェントによる開発速度の向上が、エージェントによるリグレッション（退行）につながらないように防いでくれます。
5. オーナーシップの概念が進化している。 PM、他領域のエンジニア、コミュニティの貢献者、そしてエージェントがどのコンポーネントにも貢献できるようになった今、従来のオーナーシップモデルは適応が必要です。成果に対する責任は、依然としてエンジニアが負います。
6. 人間の感性をループに残す。 エージェントは正確性をチェックし、人間は「心地よさ」を評価します。

これらが私たちのチームでどのように実践されているか、詳しく見ていきましょう。

並列での作業

Paul Grahamの有名なエッセイに、Maker（作る人）のスケジュールとManager（管理する人）のスケジュールは根本的に相容れないという話があります。最近まではそれがほとんど真実でしたが、エージェントがそれを変えつつあります。

典型的な一日は、このような感じです。

• 会議に出席する前に、バグ修正、機能のプロトタイピング、あるいはイシューのトリアージのために3〜4つのエージェントセッションを開始します。
• 会議中、エージェントは複数のVS Codeセッション、ワークツリー、あるいはクラウド上で並行して動作します。
• 会議の後、エージェントの出力をレビューし、ローカルで検証し、マージするか、再プロンプトを行い、再度実行させます。

マネージャーは依然として会議に出席し、その他の管理タスクをこなしますが、同時にエージェントを活用することで、会議の多いスケジュールでは不可能だった「作る人」としての作業も引き受けることができます。

具体的な例を挙げましょう。Pengは毎朝、VS Code Insidersを更新することから始めます。私たちは、開発中のものについて早期フィードバックを得るために、通常1日2回Insidersビルドをリリースしています。その後、彼はWork IQを通じて自身の会議情報を取得し、現在のタスク状況をスナップショットとして生成するカスタムエージェントを実行します。

そこからPengは、自分で集中すべきこと、エージェントに委任すること、チームのために優先すべきことを判断します。エージェントがコンテキストを収集する煩雑な作業を肩代わりするため、彼は興味深い課題に直接取り組むことができます。彼が最初の会議に出る頃には、タスクはすでに並行して動いています。

「以前は、常に逐次的に作業していました。メモを書き、それをイシューに変え、あとで自分や誰かがそれを拾い上げるという流れです。今では、物事を並列でこなせるようになり、その力を手にしました。これは構築すべき習慣です。だから、もう会議のメモは書きません。直接エージェントを動かしているのです」 — Peng Lyu

これは本当に新しい筋肉のようなものです。会議中に誰かが「やるべきこと」を言えば、その場ですぐにエージェントを走らせます。また、Teams会議のほとんどで文字起こしを有効にしているため、後からコンテキストを把握するのも簡単です。かつて「会議メモ→イシュー→作業」となっていた流れは、今や「その場で開始されるプロンプト」になりました。

オーバーヘッドの自動化

速度の向上は素晴らしいことですが、同時に新たなオーバーヘッドを生みます。トリアージすべきイシュー、追跡すべきコミット、書くべきリリースノートが増えるのです。私たちは、速度に比例して増大するこれらの部分を次のように自動化しました。

コミットの要約。 複数のリポジトリにまたがる過去24時間のすべてのコミットを取得し、高速なモデルで要約するカスタムのスラッシュコマンドを構築しました。かつては`git fetch`をすると20〜30のコミットがある程度でしたが、今では100以上が待機していることもあります。機能全体が1日で実装されることもあります。このパイプラインは、Insidersの変更ログに流し込まれ、毎日の更新を投稿する私たちの自動化されたXアカウントを動かしています。これらすべてが、GitHub ActionsとしてトリガーされるCopilot CLIとCopilot SDK上に構築されています。

イシューのトリアージ。 VS CodeはGitHubで最大のオープンソースプロジェクトの1つです。コミュニティを愛していますが、受け取るイシューの数は、製品がいかに多くの人にケアされているかの証であり、毎日何百ものイシューが届きます。以前は1週間交代で「インボックストラッカー」という役割を設け、1人がすべてをトリアージしていましたが、これはもうスケールしません。

今では、イシューが作成されるたびにGitHub Actionsでエージェントループがトリガーされ、重複を検出（信頼スコア付き）し、適切なオーナーを判断し、ラベルを提案します。エージェントは私たちのオーナーシップ文書を読み込み、過去の割り当てパターンを参照します。オーナーシップは時間の経過とともに変化するためです。

リポジトリの公開データからも見て取れます。前年同期と比較して、コミット数は2倍以上に増え、チームは3倍近いイシューをクローズしています。より良いトリアージは、エンジニアが適切な問題をより速く見つけて解決する助けとなり、実際のソフトウェア開発により多くの時間を割けるようにしてくれます。

「Copilotがコードを書くようになった今、そのオーナーは誰であるべきか？やはり成果に対して責任を負うのはエンジニアだと言いたい。しかし、他の人が自分のコンポーネントに貢献しやすくするための適切な『ハーネス』が必要なのです」 — Peng Lyu

チームは、GitHubイシュー上で重複、オーナー、ラベルなどのトリアージ提案を直接表示するChrome拡張機能も構築しました。これには、チーム全体のイシュー状況を示すダッシュボードも含まれています。VS Code内では、カスタムスラッシュコマンドを使用して、エディタから離れることなくイシューを整理し、重複を見つけることができます。

私たちはすでにチームの開発速度が飛躍的に向上するのを目の当たりにしています。そして、これらのワークフローが成熟するにつれ、自動化・効率化し、学べることはまだまだたくさんあります。

全員がコードをリリースする

これが私が最も興奮している部分です。これこそが、何よりも私の働き方を変えたからです。

従来のPMのサイクルは「仕様書やPRD（製品要求仕様書）を書く → イシューを作る → エンジニアに引き渡す」というものでした。誰もそのような仕様書を読むのを好みませんでしたし、根本的な問題はそれらが仮説に基づいていることでした。体験がどうあるべきかを書いているだけで、実際に作ってみるまで本当のところはわかりません。そのため、機能検証までのターンアラウンドタイムが長くなりがちでした。

変わったのは、仕様書を作る代わりに、プロトタイプ、つまり「実際のプルリクエスト」を作るようになったことです！

VS Codeのエージェントを使えば、XやRedditでフィードバックを受けてから、動作するプロトタイプを作成し、Insidersで自分でホストして体験し、反復を続けることができます。先月、私はCopilot Chatの会話分岐機能を実装するPRをマージしました。エンジニアのJustinと一緒にそのPRをレビューし、オフィスでいくつかのCSS変更を共同作業してマージしました。それが今、VS Codeに入っています。

これは、すべてのプロトタイプが製品に入るとは限りません。コードの品質とアーキテクチャについては、エンジニアが依然として責任を負っています。もしPengが私のPRを見て「これではアーキテクチャが適切ではない」と言えば、それは正当な意見であり、私のPRが捨てられて作り直されても構いません。しかし、そのPRはどんな文書よりも速く会話を前進させます。最初のPRは完璧である必要はありません。それは議論のきっかけとなり、その機能領域を担当するエンジニアとの対話を生むのです。

このワークフローは、コードベースが「エージェント対応」であるかどうかを測る試金石でもあります。エージェントは適切なコンポーネントを見つけられるか？リグレッションを見つけられるか？正しい修正を見つけられるか？PMが問題をエージェントに投げて妥当なPRを得られるなら、それはコードベースの構造、ドキュメント、テストカバレッジが優れていることを示しています。もしエージェントが苦戦するなら、それもまた一つのシグナルなのです。

速度を上げながら品質を高く保つ

速度が上がれば、リグレッションのリスクも高まります。

「適切なハーネスがなければ、最初の1〜2週間は生産性が非常に高いですが、すぐに限界に達し、リグレッションを繰り返すようになります」 — Peng Lyu

新しいコンポーネントに優れたガードレールがなければ、エージェント駆動開発は最初はうまくいくものの、すぐに品質が低下します。基本は依然として重要であり、AIを活用することで、実際にそれらを改善することができます。

• 自動検証。 5〜10個のエージェントを同時に動かしている場合、コードがコンパイルできるだけでなく、それぞれが適切な体験を提供できているかを人間が手動で検証するのはコストがかかります。私たちのチームは、Playwright MCPサーバーを使用してVS Codeを起動し、テスト対象の機能に移動してスクリーンショットを撮り、期待される動作と一致するかを評価するカスタムエージェントを構築しました。エージェントループ内で動作するため、スクリーンショットが異常を示せば、エージェントは自分で修正に行きます。スクリーンショットは人間がレビューするために保存されます。

• テスト。 包括的なテストスイート、ユニットテスト、統合テスト、そしてそれらを実行するためのインフラは必須条件です。さらに、私たちはゴールデンシナリオをドキュメント化しています。これは主要なユーザーフローにおける期待される動作の仕様です。以前は月次のエンドゲーム週にこれらを手動でテストしていましたが、現在はこれらのシナリオをエージェントに与え、マージ後の自動検証として実行させています。また、このパイプラインを使ってデモ録画を自動生成することも検討中です。PRがマージされるとデモ動画が生成され、それが変更ログやツイートのコンテンツになるのです。

• コードレビュー。 すべてのPRは自動的にCopilotコードレビューを受け、エンジニアは人間がレビューを依頼する前にCopilotのコメントを解決します。半年ほど前は、フィードバックが多すぎたため強制していませんでした。ここ数ヶ月でモデルの品質が大幅に向上し、初回パスでセキュリティやパフォーマンス、品質の問題を捕捉できるようになりました。人間がレビューする前にそれらのコメントを解決することが、私たちのワークフローの自然な一部となりました。私たちはSlackチャンネルで連携しており、ボットがCIとCopilotコードレビューのステータスインジケーターを投稿し、チェックが完了するたびに更新されます。私たちの文化は「一つレビューしたら、一つレビューを受ける」というものです。

• 感性の評価。 人間のレビューがなくなることはなく、むしろ重要性が増しています。エージェントがより多くのコードを書き、PRが速くマージされるようになると、人間は「この変更が本当に製品にとって意味があるか」を確認します。長期的なアーキテクチャに合っているか？使っていて心地よいか？エージェントはバグは見つけられますが、その機能が開発者を喜ばせるかどうかまでは教えてくれません。

従来はエンジニア、PM、デザイナーがお互いの機能をテストするエンドゲーム週を設けていました。これをなくすのではなく、短縮しようとしています。PM側では、私は「感性に基づくグレーディング」と呼ぶものを模索しています。機能に求められる定性的な体験を書き出し、その実装がそれに合致しているかをエージェントに評価させるのです。エージェントの観察の80%が有用で、20%は無視するとしても、その80%だけでも大きな価値があります。例えば「モデルピッカーはモデル名と倍率を表示するだけか、ユーザーが本当に求めている情報があるか」といった点です。

このアプローチは、公開されているドキュメントが実際の体験と一致しているかを確認するのにも役立つと考えています。VS Codeのドキュメントのほとんどは1人で書かれていますが、このペースを考えると驚異的です。しかし、製品がこれほど速く変わるとドキュメントはすぐに古くなります。エージェントがその乖離を自動的に見つける方法を模索しています。

次に向けた展望

より広義には、これらすべては「エージェント対応のコードベース評価」という考え方につながります。あなたのコードベースは、エージェントが効果的に貢献できる構造、ドキュメント、テストカバレッジを備えていますか？

私たちは、皆さんのチームのバージョンがどのようなものか興味があります。私たちがまだ見落としているワークフローはありますか？私たちが思いついていない自動化のアイデアはありますか？VS Codeリポジトリでイシューを作成するか、Xでご連絡ください。私たちは皆さんと一緒にこれを構築しており、皆さんのフィードバックが次なる一歩を形作ります。

Agent Sessions Dayでは他にも多くの素晴らしいセッションを行いましたので、まだの方はぜひチェックしてみてください。

ハッピーコーディング！💙