TypeScript 7にアップグレードすべきタイミングは今か？

プロジェクトが純粋なTypeScriptで構成され、6.0ですでにエラーなくビルドできているなら、今すぐTypeScript 7にアップグレードしましょう。typescript-eslint、Vue、Svelte、Astro、MDX、またはAngularのテンプレート型チェックに依存している場合は、7.0のtscを6.0と並行して実行し、完全に切り替えるのは7.1を待ってからにしてください。

速度の数値は魅力的です。しかし、lintパイプラインも、.vueファイルも、独自のコード生成スクリプトも、すべてtypescriptをインポートしていることを思い出すと、メジャーバージョンアップには不安が生じます。

TypeScript 7.0は2026年7月8日にリリースされました。本記事では、高速化の実態、ビルドを壊す設定変更、まだ7.0を利用できないツール、そして1つのリポジトリで両方のコンパイラを運用する方法を解説します。最後に、プロジェクトの種類ごとの結論を示します。

TypeScript 7はどれくらい速いのか？

TypeScript 7.0はTypeScriptコンパイラをGoに移植したもので、Microsoftによれば、フルビルドは一般的にTypeScript 6.0の8倍から12倍高速になります。チームはコンパイラを再設計したわけではありません。Go版は元のコードの構成と動作をそのまま踏襲しているため、2つのコンパイラは同じ結果を返します。性能向上は、ネイティブコードとして実行されること、そしてメモリを共有する複数スレッドで型チェックを行うことによってもたらされています。

以下はMicrosoftのTypeScript 7.0リリース告知に掲載されたフルビルドの数値です。

Microsoftはこれらのビルドを、デフォルトの4つの型チェッカーワーカー（--checkers 4）を用いて大規模オープンソースコードベース上で実行しました。告知では使用したハードウェアは明らかにされていません。最も低い結果であるtldrawの7.7倍は、Microsoftが掲げる「8倍から12倍」の範囲をわずかに下回っています。

TypeScript 7で実際に短縮される時間は、コードベースの規模によって異なります。Microsoftの数値から計算すると、vscodeではフルビルド1回あたり約115秒短縮されるのに対し、tldrawでは10秒未満です。もともと2秒で型チェックが終わる小規模なアプリでも同程度の比率で高速化されますが、短縮される時間はごくわずかです。

その他3つの小さな変更点を一行ずつ紹介します。

• --checkersと--buildersは、並列型チェックとプロジェクト参照ビルドを制御します。7.0のリリースノートでは、どちらのフラグも実験的機能とされています。
• --watchは、ParcelのファイルウォッチャーをGoに移植したものの上で動作するようになりました。
• JSおよびJSDocのチェックは、.tsの解析により近い動作をするよう作り直されました。詳細はtypescript-goのCHANGES.mdを参照してください。

TypeScript 5.xまたは6.0からのアップグレードで壊れるもの

stableTypeOrderingを有効にし、ignoreDeprecationsを削除した状態でTypeScript 6.0上でエラーが出ないコードは、TypeScript 7.0でも同じ出力になるはずです。壊れるものはすべて6.0に起因します。7.0は6.0の新しいデフォルトを引き継いでおり、6.0で非推奨とされたものはすべてビルドを停止させるようになりました。5.xから直接移行するチームは、両方の変更に一度に対応することになります。

新しいデフォルト

6.0から引き継がれたTypeScript 7.0の4つのデフォルトが、破壊的変更の大部分を引き起こします。

• strictがtrueになります。型付けが緩いコードでは新たなエラーが発生することを想定してください。TypeScriptのユーティリティ型を使って構築した適切に型付けされたヘルパーがあれば、移行が容易になります。
• moduleのデフォルトがesnextになります。
• rootDirのデフォルトが./になります。tsconfig.jsonがsrcより上の階層にある場合は、rootDirを明示的に設定してください。
• typesのデフォルトが[]になります。nodeやjestなどのグローバル型パッケージを名前で列挙するか、["*"]を設定して以前の動作に戻してください。

さらに4つのデフォルトが変更されています。targetは最新の確定済みECMAScriptエディション（esnextの1つ前）に追従するようになり、noUncheckedSideEffectImportsはtrue、libReplacementはfalse、stableTypeOrderingはtrueとなり無効化できなくなりました。

ハードエラーになった非推奨項目

TypeScript 7.0のリリースノートには、ハードエラーとなった12の非推奨オプションおよび動作が列挙されています。

• target: es5
• downlevelIteration
• moduleResolution: node / node10（nodenextまたはbundlerを使用）
• moduleResolution: classic（bundlerまたはnodenextを使用）
• module: amd、umd、systemjs、none（esnextまたはpreserveを使用）
• baseUrl（pathsはプロジェクトルートからの相対パスで記述）
• esModuleInteropまたはallowSyntheticDefaultImportsをfalseに設定すること
• alwaysStrictをfalseに設定すること
• 名前空間宣言におけるmoduleキーワード
• インポートにおけるasserts（withを使用）
• skipDefaultLibCheck下での/// <reference no-default-lib />
• ディレクトリにtsconfig.jsonがある状態でコマンドラインにファイルパスを渡すこと（--ignoreConfigを付けない場合）

outFileはこのリストに含まれていませんが、これも廃止されています。6.0のリリースノートには、6.0の時点ですでに削除されたこと、そして6.0で非推奨とされたすべてのオプションは7.0で完全に削除されることが記載されています。まだoutFileを使用している場合は、その処理をバンドラーに移行してください。

型レベルの変更もあります。テンプレートリテラル型からの推論で、絵文字のような文字が2つに分割されなくなりました。これに気づくのは、従来のUTF-16による分割に依存した型レベルの文字列ヘルパーを書いていた場合に限られます。

以下は典型的なレガシー設定と、7.0で動作するバージョンです。

// Before: hard errors on 7.0
{
  "compilerOptions": {
    "target": "es5",               // error: es5 unsupported
    "downlevelIteration": true,    // error: removed
    "moduleResolution": "node",    // error: node/node10 unsupported
    "baseUrl": "./src",            // error: baseUrl unsupported
    "paths": { "@/*": ["*"] }
  },
  "include": ["./src"]
}

// After: valid on 7.0
{
  "compilerOptions": {
    "moduleResolution": "bundler",
    "rootDir": "./src",
    "types": ["node", "jest"],
    "paths": { "@/*": ["./src/*"] }
  },
  "include": ["./src"]
}

新しいバージョンでは、デフォルトが適用されるようtargetを削除し、pathsをプロジェクトルート基準に変更し、rootDirとtypesを明示的に設定しています。

Microsoftは、まず6.0に移行することを推奨しています。6.0にアップグレードし、すべての非推奨警告を修正し（各項目についてはTypeScript 6.0のリリース告知で解説されています）、ignoreDeprecationsを削除してから、初めて7.0をインストールしてください。

まだTypeScript 7で動作しないツールは？

TypeScriptコンパイラをライブラリとしてインポートするツールや、Vue、MDX、Astro、Svelte、Angularのテンプレート型チェックを支えるツールは、まだTypeScript 7.0で動作しません。TypeScript 7.0にはプログラマティックAPIが含まれていないためです。Microsoftの7.0リリース告知によれば、typescript-eslintのようにコンパイラをライブラリとしてインポートするツールは、@typescript/typescript6互換パッケージを通じてTypeScript 6.0上で動かし続ける必要があります。typescript-eslintによる型情報を用いたlintの構成がtypescriptへのpeer dependencyに依存している場合は、次のセクションで説明するエイリアス設定が必要です。

組み込み言語も影響を受けます。Microsoftの7.0リリース告知では、Vue、MDX、Astro、Svelteのプロジェクトは当面TypeScript 6.0にとどまるべきとされています。Volarなどのツールは、コンパイラを直接呼び出すことでこれらのファイル形式にTypeScriptサポートを組み込んでいますが、7.0にはそのためのAPIがありません。Angularのテンプレート型チェックにも同じ制約があります。Angularについて告知では、役割を分けることが提案されています。コマンドラインとCIでは7.0のtscを使ってプロジェクト全体のエラーを素早く検出し、エディタは6.0に任せてテンプレートチェックが引き続き機能するようにする、という方法です。

VS Codeでは、Microsoftの専用TypeScript 7拡張機能に「Disable TypeScript 7 Language Server」と「Enable TypeScript 7 Language Server」という2つのコマンドパレットコマンドが用意されており、必要に応じていつでもエディタを6.0と7.0の間で切り替えられます。切り替え後にエディタの挙動がおかしくなった場合でも、通常のVS CodeでのTypeScriptデバッグワークフローがそのまま使えます。

MicrosoftはTypeScript 7.1でAPIを復活させる予定ですが、従来のAPIと同一にはなりません。これらのインテグレーションが移行するのは、現実的にはそのリリースのタイミングになるでしょう。

TypeScript 7と6.0を並行して実行する方法

1つのリポジトリで両方のバージョンを実行するには、npmエイリアスを使います。typescriptパッケージ名を6.0互換パッケージに向け、7.0は別の名前でインストールします。こうすると、typescriptをインポートするツールは6.0を読み込みます。互換パッケージは6.0のAPIに加え、tsc6という6.0のコマンドを提供します。

素のnpmプロジェクトでは、npx tscは7.0を実行します。ただし注意点があります。互換パッケージは独自のtscを宣言するTypeScript 6.0の完全なコピーに依存しているため、2つのパッケージがそのコマンド名を取り合うことになります。YarnやBunではtscが6.0にリンクされる場合があるとユーザーから報告されています。以下のtypecheckスクリプトは7.0のファイルを直接呼び出すため、どちらのパッケージがtscの名前を獲得するかに左右されません。これはMicrosoftが説明している構成に、スクリプトを加えたものです。

{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  },
  "scripts": {
    "typecheck": "node node_modules/@typescript/native/bin/tsc --noEmit",
    "typecheck:6": "tsc6 --noEmit",
    "lint": "eslint ."
  }
}

typecheckは7.0を実行します。typecheck:6は6.0を実行し、移行期間中に両方のコンパイラの結果が一致するかを確認するのに役立ちます。lintはエイリアスを通じてtypescriptを6.0に解決します。代わりにターミナルから6.0のエイリアスを設定するには、npm install -D typescript@npm:@typescript/typescript6を実行します。これだけを行った場合はtsc6しか使えないため、7.0のエイリアスも追加してください。

素のtscがどちらのコンパイラを呼び出すかは、npx tsc --versionを実行して確認できます。Microsoftはこの構成をnpm向けにしか文書化していないため、pnpm、Yarn、Bunを使用している場合は結果を自分で確認してください。

アップグレードすべきか？状況別の結論

TypeScript 7にアップグレードすべきかどうかは、6.0のビルドがどれだけクリーンか、そしてツールチェーン内にコンパイラをインポートするものがあるかどうかの2点で決まります。

新規プロジェクト： 7.0から始めましょう。FlowからTypeScriptに移行する場合は、最初から7.0のデフォルトを目標にすることで、二度目の移行を避けられます。

小規模な純粋TSコードベース： 6.0に移行し、すべての非推奨項目を修正してから切り替えましょう。短縮される時間はわずかですが、メンテナンスされている系統に乗ることができます。

大規模モノレポ： エイリアスを設定し、CIの型チェックを今すぐ7.0のtscに移行し、7.1でAPIが提供されるまでlint、コード生成、エディタは6.0のまま維持しましょう。

まとめ

TypeScript 7.0は、6.0とほぼまったく同じようにコードを型チェックし、それをより高速に行います。壊れるもののほぼすべては、6.0の非推奨項目か、コンパイラAPIを必要とするツールに起因します。まずはignoreDeprecationsなしで6.0上でクリーンなビルドを実現することから始めましょう。その後、完全に切り替えるか、npmエイリアスを追加して、ツール類を7.1まで6.0に残したままCIで7.0のtscを実行するかを選択してください。

よくある質問

tsgoや@typescript/native-previewはTypeScript 7と同じものですか？

現在は異なります。7.0のリリース前、Goコンパイラは@typescript/native-previewパッケージでプレビュー提供されており、そのコマンドはtsgoでした。このパッケージの最終バージョンは7.0.0-dev.20260707.2で、安定版リリースの前日に公開されました。TypeScript 7.0では、ネイティブコンパイラは通常のtypescriptパッケージに含まれ、tscとして実行されます。ナイトリービルドは現在typescript@nextから提供されているため、CIスクリプト内のtsgoはtscに変更してください。

TypeScript 7でVite、esbuild、SWCのビルドは速くなりますか？

いいえ。Vite、esbuild、SWCは型をチェックせずに除去することでTypeScriptをJavaScriptに変換するため、tscを呼び出すことはなく、トランスパイル時間は変わりません。TypeScript 7が高速化するのは、独立した型チェックのステップ（通常はCIやpre-commitフックでのtsc --noEmit）と、エディタの言語サーバーです。型チェックがパイプラインで最も遅いステップでなければ、アップグレードしてもビルド時間が目に見えて短くなることはありません。

ts-nodeはTypeScript 7で動作しますか？

直接は動作しません。ts-nodeはTypeScriptコンパイラAPIを通じてファイルをコンパイルしますが、7.0にはそのAPIが含まれていません。npmエイリアス構成を使えば、ts-nodeによるtypescriptのインポートは6.0互換パッケージに解決されるため、tscが7.0で動作する一方でts-nodeは6.0上で動き続けます。消去可能な構文のみを使用するコードであれば、最近のNode.jsの型ストリッピング機能により、コンパイラなしで.tsファイルを実行できますが、型チェックは一切行われません。

TypeScript 7でも古いブラウザ向けにES5へコンパイルできますか？

いいえ。TypeScript 6.0でサポートされる最小のtargetはES2015に引き上げられ、target es5は非推奨となりました。7.0ではtarget es5はハードエラーになります。ES5の出力がまだ必要な場合は、tscでES2015以降を出力し、その結果をBabelなどのコンパイラで後処理してください。あるいは、TypeScriptのソースをそうした外部ツールで直接コンパイルする方法もあります。