TypeScript 7 による迅速なイテレーション

2026年6月、VS Codeチーム著、@code

VS CodeとTypeScriptは、いわば一緒に成長してきました。初期の頃からVS CodeをTypeScriptで記述するという賭けに出て以来、私たちはTypeScriptチームと密に連携し、VS Codeに優れた組み込みのTypeScriptおよびJavaScript言語サポートを提供してきました。この記事は、その歩みの次のステップである「TypeScript 7」に関するものです。TypeScript 7の採用に向けた協業が、どのようにビルドを高速化し、開発者とAIエージェントの双方にとって日常的なコーディングのループを改善し、TypeScriptチームがよりテストされたリリースを出荷する助けとなったかについて紹介します。

TypeScript 7は、TypeScriptのコンパイラと言語ツールをGo言語で完全に再実装したバージョンです。つまり非常に高速で、多くの場合において10倍以上高速化されています。VS Codeにとって、この高速化から得られるものは非常に大きいため、私たちは当然ながら、できるだけ早くTypeScript 7を採用したいと考えていました。

しかし、これには時間がかかることも分かっていました。2025年の夏にこのプロセスを開始した時点ですでに、TypeScript 7は完全な書き換えとしては驚くほど進捗していましたが、それでも型の不整合があり、私たちが必要とする多くの機能が不足していました。それでも、私たちはすぐにテストとフィードバックを開始したいと考えました。まだ構築中の段階でTypeScript 7を採用するのは少し正気ではないように聞こえるかもしれませんが、結果的にVS CodeとTypeScriptの両方にとって素晴らしい決断となりました。

段階的な移行

VS Codeチームは、コードベースでの厳格なnullチェックの有効化、リモート開発サポートの追加、あるいは数千のファイルにわたる危険なコードパターンの対処と防止など、大規模なエンジニアリングの取り組みに挑むことを決して恐れませんでした。これらの取り組みに共通するテーマは、段階的なアプローチを取り入れようとすることです。つまり、大きくて複雑な問題を小さなステップに分解するのです。それらのステップはメインのコードベースで行われ（フォークや長命のブランチは使用しません）、それぞれがマージされるごとに小さな改善をもたらします。小さなステップを十分に積み重ねれば、振り返ったときには、かつては到底乗り越えられないと思われた課題を静かに克服していたことに気づくでしょう。

私たちは、TypeScript 7の採用においても同様のアプローチを取りたいと考えました。私たちにとってそれは、影響やリスクの低い領域から始めて、最終的にVS Codeの主要な領域へと移行していくというように、ワークフローやコードベースのさまざまな部分にTypeScript 7を段階的に導入することを意味していました。段階的に取り組むことには多くの利点がありますが、今回の取り組みにおいては、特に次の2点が重要でした。

リスクの軽減。移行の各ステップが比較的小さいため、何か問題が発生した場合でも、原因の特定とロールバックが容易でした。
早期のフィードバック。TypeScript 7の開発初期段階からテストを開始し、TypeScriptチームに質の高いフィードバックを提供したいと考えていました。つまり、VS Codeチームの開発者の生産性に悪影響を与えることなく、可能な限り多くの部分でTypeScript 7を使用することでした。

このテストにより、バグや制限事項を見つけ出すことができ、それらを優先的に修正してもらうことができました。また、コードベースのより多くの部分でTypeScript 7を採用するにつれて、それらの領域が、TypeScript 7の新しいナイトリーリリースごとの非公式なリグレッションテストとしても機能するようになりました。

実際には、この段階的な哲学は約6ヶ月間にわたる一連のフェーズとして展開されました。各フェーズにおいて、TypeScript 7の使用とテストの割合を少しずつ増やしていき、TypeScript 7自体の進捗に歩調を合わせながら、その方向性を形作る手助けをしました。その具体的な経過は以下の通りです。

探索期（2025年夏〜初秋）

TypeScript 7は、2025年3月に一般公開されました。夏頃には初期テストの準備が整いましたが、この時点ではまだ既知のバグや制限事項がありました。

型チェックは、JavaScript出力ファイルを生成するプロセスである「emit」よりも開発が進んでいたため、初期のテストの大部分は、いくつかの小さめの拡張機能で@typescript/native-preview npmパッケージを --noEmit 付きで手動実行することに集中していました。問題を見つけ次第報告し、native-preview パッケージは毎日更新されていたため、新しい変更や修正を迅速にテストすることができました。

TypeScript 7の一環として、TypeScriptチームはVS Codeのエディタ内におけるTypeScriptおよびJavaScriptサポートを駆動する新しい言語サーバーも構築していました。これは、TypeScript native preview VS Code拡張機能を使用して配布され、VS Codeの組み込みのJavaScriptおよびTypeScript IntelliSenseを新しいTypeScript 7言語サーバーに置き換えるものでした。私たちはTypeScriptチームと協力し、2つのTypeScriptのバージョン間を簡単に行き来できるようにしました。TypeScript 7はこの時点ではまだいくつかの基本的な言語機能が欠けていたため、この柔軟性が重要でした。開発者ができる限り少ない手間で、かつ低いリスクで試すことができるようにしたかったのです。

また、VS Codeから直接TypeScript 7の不具合を簡単に報告できるようにしました。報告を容易にすることで、開発者は些細な煩わしさであっても、迷うことなく起票するようになりました。それらのレポートは、TypeScriptチームにとって実際の現場からの貴重なフィードバックの継続的な流れとなりました。

この段階では、ほとんどのテストは、アルファテストに関心があり、いくつかの不都合を回避して作業することにいとわない、意欲的な少数のVS Codeチームメンバーによって行われました。

TS 6という架け橋（2025年秋）

一方、TypeScriptチームは、ユーザーに一度の大きなジャンプを強いるのではなく、TypeScript 7への移行をいかにスムーズにするかを考えていました。2025年ということもあり、この考察にはなぜか不可解な身振りが伴い、その結果として「TypeScript 6.0」というぴったりの名前のバージョンが生み出されました。

TypeScript 6.0は、TypeScript 5.9と7の間の架け橋として機能します。そのため、TypeScript 6.0における変更のほとんどは、TypeScript 7の採用に向けた足並みを揃え、準備を整えるためのものです。

— https://devblogs.microsoft.com/typescript/announcing-typescript-6-0/

このような架け橋が必要だったのは、TypeScript 7によって、チームがTypeScriptツールにおける長年の不満点を修正し、近代化するチャンスが得られたからです。例えば、古いTypeScriptのリリースでは、デフォルトのターゲットがES5になっていました。ES6（別名ECMAScript 2015）がまだ策定されていなかった2014年にはそれは理にかなっていましたが、2025年にはひどく時代錯誤に感じられました。また、target を設定し忘れたために、意図せず大きくて効率の悪いJavaScriptファイルを生成してしまう、新しい開発者にとっての「落とし穴（footgun）」でもありました。同様に、TypeScript 5では厳格なnullチェックがデフォルトで有効になっていなかったため、多くのユーザーが有効にする必要があることを知らなかったという理由だけで、このゲームチェンジャーとも言える機能を逃していました。

VS Codeチームにとって、完全に書き直されたTypeScript 7を採用するという見通しに比べれば、TypeScript 6への切り替えは小さくリスクの低いステップでした。必要なコードの変更もわずかでした。それでも、この小さなステップにより、コードベースが良好な状態にあり、TypeScript 7の準備が整い次第、大きな問題なく切り替えられるという確信が強まりました。

TS 6と7の並行稼働（2025年秋）

次は、本格的にTypeScript 7を使い始める時期でした。私たちは最もリスクの低い領域、つまり組み込み拡張機能の型チェックにTypeScript 7を使用することから始めました。このフェーズでは、完全な型チェックとJavaScriptの生成（emit）のためにTypeScript 6の実行も継続しました。TypeScript 6と7の両方のビルドがパスする必要があるように、CI（継続的インテグレーション）を設定しました。一般的にTypeScript 6と7の間で型チェックの結果は一致していましたが、両方を実行したことで、いくつかの差異を発見して報告することができました。

この時点までに、TypeScriptチームの着実な作業のおかげで、TypeScript 7の言語サーバーもさらに開発が進んでいたため、開発者が簡単に切り替えられるように、VS CodeのリポジトリにTypeScript 7の拡張機能を依存関係として追加しました。私たちの目標は、開発者がより多くの時間をTypeScript 7を使用して過ごせるよう、エディタのサポートを段階的に改善することでした。バグであれ機能の欠落であれ、開発者がTypeScript 6に戻らざるを得なくなるような要因があれば、何であれ最優先で対処しました。

開発者がTypeScript 6に戻る最も一般的な初期の理由の1つは、少し意外なものかもしれません。それはコードのフォーマットです。補完候補が完璧でなかったり、「定義へ移動（Go to Definition）」の動作が一貫していなかったりすることには概ね耐えられますが、TypeScript 6と7の間でのフォーマットの差異は、PRのコミット前チェックやCIのフォーマットチェックを失敗させる原因となりました。そのため、余分なホワイトスペースといったちょっとしたフォーマットの不整合でさえも、過度に高い優先度が与えられました。時間が経つにつれて、そうしたフォーマットの問題は解消され、開発者がTypeScript 6に戻る必要は次第になくなっていきました。

ほとんどの拡張機能でのTypeScript 7の採用（2026年1月〜2月）

2026年初頭までに、TypeScript 7には私たちがフル活用するために必要なすべての要素が揃っていました。TypeScriptチームは、型チェックを信頼できるものにし、emitを完成させ、エディタ内の言語ツールを改善するという、実に素晴らしい仕事をしてくれました。いよいよTypeScript 7へ全面的に移行を開始する時期が来ました。

いつものように、慎重かつ段階的に進めたかったため、組み込み拡張機能を1つずつ移行し始めました。これらの組み込み拡張機能は、基本的に yo code を使って作成できるVS Code拡張機能と非常に似ています。移行前、これらの拡張機能は以下のビルドツールを使用していました。

型チェックと開発ビルド用の tsc（TypeScript 6）。
本番およびウェブバンドル用の webpack。
高速なemit用の esbuild。

TypeScript 7への移行の一環として、バンドルツールを webpack から esbuild に変更することでビルドを簡素化することに決めました。これによりビルドツールがシンプルになり、バンドルの生成にかかる時間が大幅に短縮されました。

私たちの新しいビルド構成は、よりシンプルになりました。

型チェックと開発ビルド用の tsgo（TypeScript 7）。
本番およびウェブバンドル用の esbuild。

リグレッションの影響を最小限に抑えるため、拡張機能を小さなグループに分けて移行しました。これにより、最もシンプルな拡張機能から始めて、より複雑な拡張機能に進む前に知識と自信を積み重ねることができました。このプロセスは概ね順調に進みました。私たちがすでにこのコードをTypeScript 7でビルドしていたことを考えれば、それは大きな驚きではないはずです。

デフォルトとしてのTypeScript 7の採用（2026年2月）

最後のステップは、通常開発におけるTypeScript 7への切り替えでした。その頃には、TypeScriptチームの修正により私たちが回避策を講じていたブロッカーが取り除かれており、段階的なステップによってすでに大部分の作業が終わっていたため、このためのコード変更は実際には非常にわずかなものでした。例えば、こちらが通常のwatchタスクをTypeScript 7を使用するように切り替える変更です。

また、VS Codeリポジトリのエディタ内で使用されるデフォルトのバージョンとしてもTypeScript 7を指定しました。エスケープハッチとして古いTypeScriptに戻す機能も引き続きサポートしていますが、実際のところ必要になることはほとんどありません。ほとんどの開発者は、パフォーマンスが大幅に向上しているため、TypeScript 7を使い続けることに満足しています。

数値で見る成果

では、それだけの価値はあったのでしょうか？答えは、文句なしの「Yes」です。

VS Codeのメインソースコードの型チェックにおける、移行前後の比較は以下の通りです。

# TS 6.0
tsc --noEmit -p src/tsconfig.json
36 seconds

# TS 7
tsgo --noEmit -p src/tsconfig.json
5 seconds

TypeScript 7は7倍以上高速です！これら2つのタスクが同じ作業を行っている（同じファイルに対して同じレベルの徹底度で型チェックを行い、同じエラーを報告する）ことを考慮すると、これは特に印象的です。TypeScript 6からTypeScript 7に切り替えただけで、型チェックが7倍も高速化されたのです。

TypeScript 7を導入したことにより、ほぼすべての組み込み拡張機能の型チェックを1秒未満で完了できるようになりました。唯一の例外は、より大規模なCopilot拡張機能ですが、それでもわずか2.5秒しかかかりません。

VS Code全体のコンパイルおよび型チェック（つまり、メインのソースコードと約50の組み込み拡張機能の tsconfig プロジェクトの両方）を見ると、この結果はさらに印象的になります。これは npm run watch コマンドが行う処理であり、VS Codeの開発者が通常実行するコマンドでもあります。

TypeScript 6では、npm run watch が完了するまでに約80秒かかっていました。TypeScript 7に移行したことで、この時間を20秒強にまで短縮できました。およそ4倍の高速化です。これにより、ビルドを再起動する必要があるたびに（初期watch完了後の再チェックは最大でも約1秒です）、通常開発およびAIエージェントによるイテレーションにおいて丸1分の時間が節約されます。

これらの改善は、エディタ内での言語ツールのパフォーマンス向上にも直結しています。エディタ内のTypeScript言語機能では、適切なエラーや自動インポートのような複雑な機能を提供できるようになる前に、 tsconfig プロジェクト全体をロードする必要があります。メインのVS Codeプロジェクトの場合、以前は1分近くかかっていました。現在では約10秒です。これにより約50秒が節約されます。VS Codeの開発者は1日に何度もエディタウィンドウを再読み込みすることが多いため、この節約された時間は積もり積もって大きなものになります。エディタツールのロードを待つ間にコーヒーを淹れに行く必要ももうなくなりました。

こうした数値を目の当たりにすると、改善の規模がどれほどのものだったのかがよく分かります。私たちの段階的なアプローチでは、多くの改善が1つの大きなPRとしてではなく、徐々にもたらされたため、全体的な影響を見失いがちでした。初期のステップではわずか1秒や数百ミリ秒の短縮しかなかったかもしれません。しかし最終的には、そうした小さな成功が積み重なって大きな成果となりました。また、TypeScriptチームが当初の約束をしっかりと果たしてくれたことも驚きです。完全に本物のTypeScriptでありながら、圧倒的に高速なのです。

協業によるさらなる向上

TypeScript 7の採用はVS Codeの開発者にとって大きな勝利でしたが、この取り組みには、目に見えにくいものの、おそらくそれ以上にインパクトのあるもう一つの成果があります。VS Codeの大規模で複雑なコードベースは、TypeScript 7の実際のバグを発見し、そのエディタツールを洗練させるための絶好の手段であることが判明したのです。

また、VS Codeチームの開発者たちは、不足している機能や違和感を覚える点についてフィードバックすることを恐れませんでした。開発者が粗削りな部分に直面してTypeScript 6に戻るたびに、それはTypeScriptチームにとって次に何を修正すべきかを判断するためのシグナルとなりました。その結果生まれたのは、VS Codeのコードベースの枠を超えて十分に機能することが分かっている、よりテストされ洗練されたバージョンのTypeScript 7です。

この記事ではVS Code側の話に焦点を当ててきましたが、称賛のほとんどは本当にTypeScriptチームに捧げられるべきものです。なんといっても、うるさいVS Code開発者たちからのすべてのフィードバックに対応しながら、TypeScript 7を作り上げたのは彼らなのですから。私、そしてVS Codeチームを代表して、感謝を申し上げます！

TypeScript 7は、プログラミング言語としてのTypeScriptにとってエキサイティングな前進です。VS Codeでコードを編集しているときも、コマンドラインでコンパイルを実行しているときも、エージェントにプロジェクトのイテレーションを依頼しているときも、パフォーマンスの向上は顕著であり、はっきりと体感できます。TypeScriptチームの尽力と、ここで紹介したテスト・フィードバックのプロセスのおかげで、TypeScript 7への切り替えは比較的スムーズに行え、多くのコードベースにとって容易な勝利となるはずです。

しかし何よりも、この記事が、段階的に作業すること、早期かつ頻繁にテストすること、そして緊密なコラボレーションのために強固なフィードバックループを構築することの価値を示していることを願っています。これらはVS Codeが常に大切にしてきた価値観であり、今回の取り組みにおいても私たちを大いに助けてくれました。この記事が、ご自身のプロジェクトにおける大規模なエンジニアリングの取り組み方について新しい視点を得るきっかけとなり、最終的に優れたコードを出荷するモチベーションとなることを願っています。

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