Argano の鈴木です。この記事ではTypeScriptのバージョン6及び7へのバージョンアップに向けて、どのような変更があるのかを紹介していきたいと思います。
TypeScriptバージョン6の変更点とv7：モダンな開発環境への適応
2026年3月23日にリリースされた TypeScript 6.0 は、単なる機能追加のバージョンではありません。次世代の TypeScript v7（Project Corsa） において、コンパイラをGo言語でゼロからネイティブ化へ再構築するための「重要な準備期間」として位置づけられています。
TypeScript v7では、実行速度を劇的に向上させるためにGo言語への移植が行われます。この大規模な刷新を成功させるためには、長年蓄積された複雑なレガシー仕様を整理し、コンパイラのロジックをシンプルにする必要がありました。v6はそのための仕様の最適化期間であり、開発者がスムーズに次世代環境へ移行するためのステップです。
v6の最大の役割は、TypeScriptを最新のJavaScript規格（ES Modulesなど）に最適化することです。そのため、古いブラウザや過去のモジュール形式に関連する設定を非推奨とし、v7ではそれらを完全に削除することで、コンパイラの「軽量化」と「高速化」を実現しようとしています。
仕様の整理だけでなく、実用的なアップデートも含まれています。
- Import Attributesの安定化: 最新のJavaScript標準仕様に基づき、
import ... with { type: "json" }構文が正式にサポートされました。これまで使われていたassert構文は非推奨となり、セキュリティと標準準拠の両面でより堅牢になっています。 - デフォルト設定のモダン化:
strictモードがデフォルトで有効になり、targetのデフォルトがes2025、moduleがesnextへと変更されました。 - エディタ連携（Language Service）の高速化: 型解析アルゴリズムの最適化により、VS Code上でのコード補完や定義ジャンプのレスポンスが向上しています。日常的なエディタ操作の快適さが底上げされました。
TypeScript 6.0から非推奨・削除される設定とその理由
なぜこれほど多くの設定を削除する必要があるのか。最大の理由は、Go言語で実装されるネイティブコンパイラのパフォーマンスを極限まで引き出すためです。
20年近い歴史の中で積み重なったレガシーな仕様（AMD, UMD, Node10解釈など）をすべてGo言語で再実装すると、コンパイラが複雑になり、速度の足かせとなります。これらを切り捨てることで、モダンなフロントエンド開発に特化した爆速のエンジンが実現可能になります。
また、現在のフロントエンド開発（特にviteなどのエコシステム）では、処理速度を高めるためにツールの役割分担が主流になっています。
- TypeScript（tsc）の役割: 複雑な「型チェック」と「モダンなJS（ESNext）への出力」に専念する（あるいは
noEmit: trueで型チェックのみを行う）。 - SWC / esbuild / Babelの役割: TSのコードから型を瞬時に剥がし、必要に応じて古いブラウザ（ES5など）でも動くJSに高速で変換（トランスパイル）する。
v6でのレガシーターゲットの非推奨化（およびv7での削除）は、この役割分担を前提としています。つまり、「古い環境への変換は、それを得意とする高速な専用ツールに任せる」という現代の思想への完全なシフトです。
古いブラウザ対応が必要なケースでも、viteの @vitejs/plugin-legacy などを活用すれば、TypeScript本体の高速化の恩恵を受けつつ、安全にレガシー対応が可能です。基本的には、v6環境で出力される非推奨の警告を一つずつ解消していくことが、v7への最短ルートになります。
主な非推奨・削除項目と対応方法
上記の背景を踏まえ、各設定項目の対応方法をまとめました。
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 7.0で何が変わるのか
Go言語によるコンパイラの再構築
TypeScript v7の最大の変化は、コンパイラがこれまでのNode.js製から、Go言語によるネイティブバイナリへと作り直されることです。コードネーム「Project Corsa」として進められたこの刷新により、既存のJSエンジンの限界やオーバーヘッドが取り払われました。
2026年5月現在では、npmパッケージ @typescript/native-preview として先行提供されており、コマンドも tsgo として試すことができます。
参考: typescript-go
ネイティブ動作と並列処理による圧倒的な高速化
TypeScript v6まではtscコンパイラはnode環境上で動作します。このプログラムがOS上で直接実行されるようになることで、起動速度と実行効率が劇的に向上します。小規模なプロジェクトでは瞬時に、大規模なプロジェクトでも従来比で約10倍の高速化が期待できます。
さらに、これまでのTSコンパイラは基本的にシングルスレッドで動作していましたが、v7からはGo言語の強みである Goroutine を活かし、マルチコアをフル活用した並列処理で型チェックを行います。これにより、viteのHMRの速度に対して、型チェックがボトルネックにならなくなります。
移行にあたっての注意点と対策
厳格化された型推論へのコード修正対応
v6以降、デフォルトで strict: true が採用されているほか、コンパイラエンジンの刷新に伴い、型推論のロジックがより厳格になりました。これまで曖昧に許容されていたコードや、緩い型定義がエラーとして弾かれる可能性があります。特に複雑なジェネリクスやユニオン型を使用している箇所は、移行時に見直しが必要になるケースが多いため、移行には注意が必要です。
おわりに
TypeScript v7でますます速くTypeScriptで開発ができるようになるのでリリースが楽しみです。TypeScript v7のリリースに備えてまずはバージョン6の導入から始めましょう。