2026/05/21

Argano の鈴木です。TypeScript v7のリリースが迫ってきました。この記事ではどのような変更があるのか、また、Argano メンバーに聞いた疑問点などを紹介していきたいと思います。

TypeScript v7での変更点

もうすぐTypeScriptバージョン7がリリースされます(2026年5月現在v7開発中)。
v7では、これまでTypeScriptで書かれていたTypeScript本体やコンパイラをGo言語で実装し直すという大きな変更があります。 Go言語で実装し直すことでビルドや型チェックの速度の大幅改善が見込まれています。

なぜGo言語で書くと速くなるのか

TypeScriptで書かれたコンパイラの場合、コンパイラはnode環境で実行されますが、v7以降のGo言語で実装されたコンパイラはネイティブバイナリとして、node環境を介さずにOSが直接バイナリを実行することになるため、高速に処理を進めることができるようになります。
また、TypeScriptとGo言語では並列処理の方法が異なっており、Go言語での並列処理の方がビルド速度を高速にするのに向いています。
Node.js (TypeScript) では、基本的にシングルスレッドで処理を行っています。async/awaitなどの非同期処理時には待ち時間の間に別の処理をするだけで、CPU自体を複数同時に使うことは苦手です。Node.jsでマルチコアを活用することは worker_threads や子プロセスを使うことで実現できますが、新しいスレッドを立ち上げる処理のコストが大きいこと、また、スレッド間でのメモリ共有が苦手であるなど、コンパイラ開発における弱点は点在している状況です。
一方Go言語での並列処理ですが、複数スレッドを使うことを前提に設計された Goroutine という仕組みによってスレッドを素早く立ち上げて使うことができます。メモリの共有においても、Node.jsのようなデータの変換・転送コストをかけずに実行することが可能となっています。

レガシー機能の削除

v7 および、v7の準備段階として位置付けられたv6から、いままで使えていたレガシーな機能が使えなくなります。
前述したようにv7では実行速度向上のためにGo言語への移植が行われます。この大規模な刷新を成功させるためには、長年蓄積された複雑なレガシー仕様を整理し、コンパイラのロジックをシンプルにする必要がありました。
v6はそのための仕様の最適化期間であり、開発者がスムーズに次世代環境へ移行するためのステップです。
v6の最大の役割は、TypeScriptを最新のJavaScript規格（ES Modulesなど）に最適化することです。そのため、古いブラウザや過去のモジュール形式に関連する設定を削除または非推奨とし、v7ではそれらを削除することで、コンパイラの「軽量化」と「高速化」を実現しようとしています。
これまでの歴史の中で積み上げてきた機能のなかには、レガシーな仕様（AMD, UMD, Node10解釈など）が含まれていますが、viteなどを使ったモダンな開発でツールの役割分担が主流となっています。
viteの例ですと、TypeScript(tsc)では型チェックのみを行い、viteの役割としてJSへの変換や、必要に応じて古いブラウザでも動くようトランスパイルしています。

Arganoメンバーに聞いたv7への疑問

TypeScript v7への期待や疑問などを Argano メンバーにインタビューしてみました。

実際にどれくらい速くなるのか計測してみてほしいです。

弊社のプロジェクトの中でも比較的ファイル数が多いリポジトリでTypeScript v6, TypeScript v7のそれぞれのコンパイラを使って型チェック(tsc --noEmit)にかかる実行時間を計測してみました。
リポジトリ内のts,tsxファイルは合計で約2,500ファイルあり、累計の行数は約140,000行となっています。

v6(TypeScript製)v7(Go言語製)
7.90s1.104s

今回計測したリポジトリでは約1/7に処理時間が短縮されました。
コードが大きくなりビルドにかかる時間の肥大化が問題となりつつありましたが、TypeScript v7へアップデートすれば大きく改善できそうです。

v7に備えて開発者はどのような準備をする必要がありますか？

v7がリリースされる前に、準備段階としての立ち位置のTypeScript v6がリリースされています。このバージョンではv7で廃止される予定のtsconfigの設定が廃止・非推奨となります。
一度v6に上げ、tsconfig.jsonの修正を行うことでスムーズにv7を使うことができるようになります。

どのような破壊的変更がありますか？

tsconfig.jsonの設定が変更されることで破壊的変更が発生します。主な非推奨・削除項目と対応方法をまとめました。

module: amd, umd, system

  • 設定の概要: コンパイル後のJavaScriptのモジュールシステムを指定するものです。これらはES Modules（ESM）が標準化される前の時代に使われていた形式です。
  • 対応方法: tsconfig.json の module を ESNext または NodeNext に変更します。UMD形式などが必要な場合は、viteやWebpackなどのバンドラ側の設定で出力するように変更する必要があります。
  • 削除の背景: すでに標準仕様であるESMへの移行が完了しており、過去のモジュール形式の出力ロジックは不要と判断されたため削除となります。

moduleResolution: node

  • 設定の概要: モジュールの解決アルゴリズムを指定します。node（実質的な node10）は、exports フィールドなどを解釈しない古いNode.jsの挙動です。
  • 対応方法: viteなどのバンドラを使用している場合は bundler に変更します。Node.js環境の場合は NodeNext を指定します。
  • 削除の背景: npm等のモダンなパッケージエコシステムの実態と合わなくなっているため削除となります。

target: es5, es3

  • 設定の概要: 出力するJavaScriptの構文バージョンを指定します。es5 はIE11などで動作するように古い記法へ変換します。
  • 対応方法: target を ES2020 以降、または ESNext に変更します。古いブラウザのサポートが必要な場合は、コード変換をSWCやBabelといった専用のトランスパイラに任せるアーキテクチャへ移行する必要があります。
  • 削除の背景: 古い構文への変換処理はコンパイラにとって非常に重く、この役割を専用ツールに譲り渡す方針になっているため削除となります。

baseUrl

  • 設定の概要: プロジェクト内のインポートパスの基準ディレクトリを指定する設定です。paths 設定と組み合わせてエイリアスを実現するためによく使われてきました。
  • 対応方法: tsconfig.json から baseUrl を削除します。エイリアスを使用したい場合は、paths の指定をプロジェクトルートからの相対パスに書き換えることで引き続きエイリアスを使用することができます。
  • 削除の背景: 元々AMD時代に作られた機能であり、現代の標準的なモジュール解決とは異なる挙動をしているため削除となります。

outFile

  • 設定の概要: 複数のTypeScriptファイルを1つのJavaScriptファイルに結合して出力する機能です。
  • 対応方法: この設定は削除し、ファイルの結合はviteやesbuildといった専用のバンドラに任せるようにします。
  • 削除の背景: ファイルの結合や最適化は、現在では完全にバンドラの仕事として定着しているため削除となります。

noImplicitUseStrict

  • 設定の概要: コンパイルしたファイルの先頭に "use strict"; を付与するのを防ぐ設定です。
  • 対応方法: tsconfig.json から単純に削除してください。
  • 削除の背景: モダンなJavaScriptは仕様上常に厳格モードで動作するため、無効化するユースケースがなくなったため削除となります。

参考: TypeScript 6.0 Release Notes

TypeScript自体は何が変わりますか？

言語としての文法・型システムなど開発者側からみての大きな変更はありませんが、コンパイラとVSCodeなどのエディタで動くプログラムがGo言語に置き換わりました。
GitHub リポジトリの Languages をみると、v6では99.9%がTypeScriptで書かれていますが、v7では84.8%がGo言語、12.0%がTypeScript, 残りの3.2%がJavaScriptで実装されています。

コンパイラの実態はなんですか？

コンパイラの実態はGo言語で書かれており、typescript-goリポジトリのcmd/tsgoにあります。
npm install などでインストールされる際には各OS・CPUアーキテクチャごとにコンパイルされているバイナリ形式の実行ファイルがインストールされます。そのためGo言語を動かす環境を整える必要なく実行することができます。

最後に

TypeScript v7を実際に触ってみて、こんなにも速くなるのかと驚きました。VSCodeで使われているTypeScriptの性能も上がるとのことで、今後さらにサクサクと開発が進められるようになるという期待でいっぱいです。
また、いきなり大きく変更するのではなく、間にv6を置いて準備期間を設け、v7がリリースされてからすぐに使えるという設計もよくできているなと思いました。ただ、大きなプロジェクトであればv6へアップデートするのに一筋縄では行かないとも思っています。
今のうちからv6への移行を済ませておき、v7への準備を万端にしておいてv7のリリースを楽しみに待ちたいと思います。