MENU

TypeScript 7.0正式リリース：Goネイティブ化で約10倍高速、移行条件と注意点

TypeScript

Microsoftは米国時間2026年7月8日、日本時間では7月9日に、TypeScript 7.0の正式提供を発表しました。最大の変更は、コンパイラと言語サービスをJavaScriptベースの実装からGoによるネイティブ実装へ移植したことです。公式ベンチマークでは、フルビルドがTypeScript 6の約7.7～11.9倍高速になっています。(Microsoft for Developers)

ただし、すべてのプロジェクトがすぐに移行すべきとは限りません。通常の.ts・.tsxファイルをtscで型チェックするプロジェクトは有力な導入候補ですが、TypeScriptのプログラムAPIを使うツール、Vue・Svelte・Astro・MDX、古いJSDoc記法、ES5向け設定などを利用している場合は、TypeScript 6との併用や移行延期が必要です。

目次

TypeScript 7.0で何が変わったのか

コンパイラと言語サービスがGoによるネイティブ実装になった

TypeScript 7.0では、コンパイラと開発ツールの中核がGoで実装されています。

単に処理系の言語を置き換えただけではありません。ネイティブコードの実行速度、共有メモリを使ったマルチスレッド処理、ファイル単位の並列解析などを活用できる設計になっています。

主に高速化されるのは、次の処理です。

  • tscによる型チェックとビルド
  • エディター起動時のプロジェクト読み込み
  • 入力中のエラー診断
  • コード補完
  • 参照検索
  • 定義への移動
  • --watchモードでの再チェック

構文解析、型チェック、JavaScriptや宣言ファイルの出力など、従来は直列処理の影響を受けやすかった工程も並列化されています。エディター向けの言語サービスはLanguage Server Protocol、いわゆるLSPを基盤とする設計へ移行しました。(Microsoft for Developers)

「約10倍高速」はフルビルドの実測値

公式発表では、大規模なオープンソースプロジェクトをTypeScript 6とTypeScript 7でビルドした結果が公開されています。

コードベースTypeScript 6TypeScript 7高速化メモリ差
VS Code125.7秒10.6秒11.9倍-18%
Sentry139.8秒15.7秒8.9倍-6%
Bluesky24.3秒2.8秒8.7倍-26%
Playwright12.8秒1.47秒8.7倍-11%
tldraw11.2秒1.46秒7.7倍-15%

VS Codeのコードベースでは、エディターを開いてから最初のエラーが表示されるまでの時間も、約17.5秒から1.3秒未満へ短縮されています。公式の計測条件における改善であり、すべての環境で同じ倍率になるわけではありませんが、大規模プロジェクトほど恩恵を受けやすいことが分かります。(Microsoft for Developers)

アプリケーション自体が10倍速くなるわけではない

TypeScript 7.0の高速化は、開発ツールの処理速度に対するものです。ブラウザやNode.jsで実行されるアプリケーションの動作が10倍速くなるわけではありません。

例えば、バンドラや別のトランスパイラがJavaScriptへの変換を担当し、tscを型チェックにしか使っていないプロジェクトでは、速くなるのは主に型チェック部分です。画像処理、テスト、バンドル、デプロイなどがボトルネックなら、CI全体の所要時間が10分の1になるとは限りません。

導入効果を判断するときは、「ビルド全体」ではなく、次の時間を分けて計測する必要があります。

計測対象確認する内容
型チェックtsc --noEmitにかかる時間
フルビルドキャッシュなしのtsc -bや通常ビルド
差分ビルド1ファイル変更後の再チェック
エディター起動から診断・補完が有効になるまで
CI型チェック工程とパイプライン全体の時間
メモリローカル環境とCIランナーの最大使用量

TypeScript 7.0の提供条件と使い始め方

npmの通常のtypescriptパッケージから利用できる

プレビュー段階では@typescript/native-previewという別パッケージが使われていましたが、正式版は従来と同じtypescriptパッケージからインストールできます。

npm install -D typescript

インストール後は、これまでと同じようにnpx tscを実行します。

npx tsc --version
npx tsc -p tsconfig.json --noEmit

CIやチーム開発では、意図しないマイナーアップデートを避けるため、package.jsonとロックファイルで7.0系のバージョンを固定してから検証するのが安全です。発表時点の公式例では7.0.2が使用されています。(Microsoft for Developers)

VS Codeでは専用拡張機能を利用する

発表時点のVS Codeでは、TypeScript 7用の公式拡張機能をインストールすると、新しい言語サーバーが標準のエクスペリエンスとして有効になります。

問題が発生した場合は、コマンドパレットから次のコマンドを実行して、TypeScript 6の言語サービスへ戻せます。

Disable TypeScript 7 Language Server

再度有効にするときは、次のコマンドを使用します。

Enable TypeScript 7 Language Server

公式発表では、今後数週間でVS Code本体にもTypeScript 7対応を組み込む予定とされています。Visual Studioの最新バージョンでは、ワークスペースに応じて自動的に有効化されます。その他のエディターについてはLSPを利用できますが、実際の対応状況は各エディターや拡張機能の実装を確認してください。(Microsoft for Developers)

ナイトリービルドの配布方法も変わる

従来、ネイティブ版のナイトリービルドは@typescript/native-previewから配布されていました。正式版公開後は、標準のtypescriptパッケージにあるnextタグへ戻す方針が示されています。

npm install -D typescript@next

本番プロジェクトでは安定版を使い、ナイトリービルドは不具合の再現確認や次期バージョンの先行検証に限定するのが適切です。

TypeScript 7.0をすぐ導入すべきプロジェクト

TypeScript 7.0の導入可否は、プロジェクトの規模よりも「TypeScriptをどのように利用しているか」で判断する必要があります。

プロジェクトの状況推奨判断理由
.ts・.tsxを通常のtscで型チェックしている検証を開始しやすいネイティブコンパイラの恩恵を直接受けられる
大規模モノレポやProject Referencesを使っている優先的に検証並列ビルドと型チェックの効果が出やすい
CIの型チェックが数分以上かかる導入効果が大きい可能性待ち時間と実行コストを削減しやすい
小規模で型チェックが1秒未満急ぐ必要はない短縮できる絶対時間が小さい
TypeScriptのプログラムAPIを利用しているTypeScript 6と併用7.0には安定したプログラムAPIがない
Vue・Svelte・Astro・MDXを使っている原則としてTypeScript 6を継続埋め込み言語用ツールが7.0のAPIを利用できない
Angularテンプレートの型チェックを重視するCLIのみ段階検証エディターやテンプレート側は6.0が必要になる場合がある
JavaScriptとJSDocを多用している十分な互換性検証が必要JSDocとJavaScript解析の仕様変更が多い
ES5や旧式モジュールを出力している設定移行を先に実施複数の旧設定が削除されている

公式はTypeScript 7.0を本番利用可能な品質と位置付けています。大規模な社内外プロジェクトで検証され、新しい言語サーバーでは、失敗するコマンドがTypeScript 6比で80%以上、クラッシュが60%以上減少したというデータも示されています。とはいえ、処理系全体が新しいコードベースになったため、いきなり全チームへ展開するのではなく、代表的なリポジトリから段階的に導入するのが安全です。(Microsoft for Developers)

Vue・Svelte・Astro・MDXではすぐに全面移行できない

TypeScript 7.0には、TypeScript 6まで提供されていた安定したプログラムAPIがありません。

VueやSvelteなどの開発ツールは、TypeScriptのコンパイラや言語サービスを内部に組み込み、.vueや.svelteなどのファイルを仮想的なTypeScriptコードへ変換しています。この仕組みではTypeScriptのプログラムAPIや言語サービス用プラグインが必要になるため、TypeScript 7.0へそのまま置き換えられません。

公式発表では、次のワークフローは当面TypeScript 7.0の恩恵を受けにくいとされています。

  • Vue
  • Svelte
  • Astro
  • MDX
  • Angularのテンプレート型チェック
  • VolarなどTypeScriptを内部に組み込むツール

Vue・Svelte・Astro・MDXを利用するプロジェクトは、基本的にTypeScript 6を継続するのが安全です。Angularでは、CLIによるプロジェクト全体のエラー検出だけTypeScript 7を使い、エディター側はTypeScript 6を使う構成も案内されています。(Microsoft for Developers)

TypeScriptのプログラムAPIを使うツールにも注意が必要

TypeScript 7.0は、tscコマンドとLSPベースの言語サービスを提供しますが、7.0時点では安定したプログラムAPIを提供していません。新しく設計されたAPIはTypeScript 7.1での提供が予定されています。(Microsoft for Developers)

次のようなコードやツールがある場合は、API依存を疑ってください。

import * as ts from "typescript";

const program = ts.createProgram(["src/index.ts"], {});
const ts = require("typescript");

影響を受けやすいのは、次の用途です。

  • カスタムコンパイラツール
  • AST解析ツール
  • カスタムトランスフォーマー
  • 型情報を使うリンター
  • TypeScriptを組み込むバンドラやローダー
  • 言語サービスプラグイン
  • コード生成ツール

依存関係を確認するには、パッケージマネージャーの依存ツリーも確認します。

npm ls typescript

自社コードにtypescriptのインポートがなくても、ESLint関連ツールやビルドツールが間接的にコンパイラAPIを利用している可能性があります。

TypeScript 6とTypeScript 7を併用する方法

APIを必要とするツールがある場合、公式は互換パッケージ@typescript/typescript6を使った併用方法を案内しています。

現在の公式例は次の構成です。

{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  }
}

この構成では、役割を分けられます。

利用先使用するバージョン
npx tscTypeScript 7
npx tsc6TypeScript 6
import "typescript"を行うツールTypeScript 6のAPI

インストール後は、実際に参照されるバージョンを確認してください。

npx tsc --version
npx tsc6 --version
node -p "require('typescript').version"

発表直後の公式例では、TypeScript 7側に任意のエイリアス名を使う方法が掲載されていました。しかし、複数パッケージがtscという同じ実行ファイル名を提供することで、TypeScript 6側が呼び出される問題が報告されています。現在の公式ブログは、TypeScript 7側を@typescript/nativeという名前にする構成へ更新されています。古い記事にあるtypescript-7などの例をそのままコピーせず、現在の公式例を使うのが安全です。(Microsoft for Developers)

TypeScript 5.xから直接移行しないほうがよい

TypeScript 6.0は、JavaScript実装の最終メジャーバージョンであると同時に、TypeScript 7.0へ移行するための橋渡しとして設計されています。

TypeScript 7.0は、次の条件を満たすTypeScript 6.0プロジェクトについて、可能な限り同じ型チェック結果を返すように作られています。

  • stableTypeOrderingを有効にしてエラーがない
  • ignoreDeprecationsを使って非推奨設定を隠していない
  • TypeScript 6.0で正常にコンパイルできる

現在TypeScript 5.x以前を使っている場合は、先にTypeScript 6へ移行してください。5.xから7.0へ直接上げると、TypeScript 6で導入された設定変更と、ネイティブ実装への移行差分が同時に発生し、原因の切り分けが難しくなります。(Microsoft for Developers)

TypeScript 6へ移行後、次のように型順序の違いを検証できます。

npx tsc -p tsconfig.json --noEmit --stableTypeOrdering

stableTypeOrderingはTypeScript 7と同じ決定的な型順序を再現するための移行用オプションです。プロジェクトによっては型チェックが最大25%程度遅くなる可能性があるため、TypeScript 6で常用するのではなく、移行テストに利用します。(Microsoft for Developers)

tsconfig.jsonで変わる主なデフォルト値

TypeScript 7.0はTypeScript 6.0で導入された新しいデフォルト設定を引き継ぎます。設定値を省略していたプロジェクトほど影響を受けます。

設定新しいデフォルト・動作主な影響
stricttrue暗黙のanyやnull関連のエラーが増える可能性
moduleesnext出力モジュール形式が変わる可能性
targetesnext直前の安定版ECMAScript古い実行環境向けの変換が減る
noUncheckedSideEffectImportstrue存在しない副作用インポートを検出
libReplacementfalseライブラリ置換を使う構成では明示設定が必要
stableTypeOrderingtrue、無効化不可宣言ファイルや型表示の順序が安定
rootDir./出力先のディレクトリ構造が変わる可能性
types[]@typesのグローバル型が自動では入らない

特に問題になりやすいのはrootDirとtypesです。(Microsoft for Developers)

出力先にdist/srcが増えた場合はrootDirを確認する

従来、rootDirを省略すると、TypeScriptがソースファイルの共通ディレクトリを推測していました。TypeScript 6以降は、基本的にtsconfig.jsonがあるディレクトリが基準になります。

例えば、次の構成を考えます。

project/
├── tsconfig.json
└── src/
    └── index.ts

意図した出力先がdist/index.jsなのに、dist/src/index.jsへ出力される場合は、rootDirを明示します。

{
  "compilerOptions": {
    "rootDir": "./src",
    "outDir": "./dist"
  },
  "include": ["./src"]
}

processやdescribeが見つからない場合はtypesを確認する

typesのデフォルト値が空配列になったことで、node_modules/@typesにある型定義がすべて自動でグローバル空間へ読み込まれる動作はなくなりました。

Node.jsとJestを使うプロジェクトなら、必要な型だけを明示します。

{
  "compilerOptions": {
    "types": ["node", "jest"]
  }
}

process、Buffer、describe、itなどが突然見つからなくなった場合は、まずtypesを確認してください。

以前に近い動作は次の設定で復元できます。

{
  "compilerOptions": {
    "types": ["*"]
  }
}

ただし、不要な型定義まで読み込むため、ビルド速度と予測可能性の面では、必要な型だけを列挙するほうが適切です。

TypeScript 7.0で削除された主な設定

TypeScript 6では警告や非推奨扱いだった設定の一部が、TypeScript 7.0ではエラーになります。

削除・変更された設定推奨される対応
target: "es5"対象環境を引き上げるか、別の変換工程でレガシー環境へ対応する
downlevelIterationより新しいtargetへ移行する
moduleResolution: "node"、"node10"バンドラ利用ならbundler、Node.js実行ならnodenextを検討する
moduleResolution: "classic"bundlerまたはnodenextへ移行する
module: "amd"、"umd"、"systemjs"、"none"esnextまたはpreserveとバンドラを使う
baseUrlpathsをプロジェクトルート基準の相対パスへ変更する
esModuleInterop: falsefalse指定を削除する
allowSyntheticDefaultImports: falsefalse指定を削除する
alwaysStrict: falsefalse指定を削除する
module Foo {}namespace Foo {}へ変更する
Import AssertionsのassertImport Attributesのwithへ変更する

例えば、従来の設定が次のようになっている場合です。

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/*": ["src/*"]
    }
  }
}

TypeScript 7.0ではbaseUrlを削除し、pathsをプロジェクトルートからの相対パスとして指定します。

{
  "compilerOptions": {
    "paths": {
      "@/*": ["./src/*"]
    }
  }
}

また、カレントディレクトリにtsconfig.jsonがある状態で、tsc src/index.tsのようにファイルを直接指定する実行方法も変更されています。設定ファイルを無視してファイル指定を行う場合は、明示的な--ignoreConfigが必要です。(Microsoft for Developers)

JavaScriptとJSDocを使うプロジェクトは変更点が多い

TypeScript 7.0では、.jsファイルの解析を.tsファイルの解析へ近づけるため、JavaScriptとJSDocの扱いが整理されています。

主な変更は次のとおりです。

従来の書き方・機能TypeScript 7.0での対応
値の名前を型として使用typeof 値を使う
JSDocの@enum@typedefなどで型を明示する
単独の?型anyを使う
関数に@classを付ける通常のclass宣言を使う
Closure形式のfunction(string): void(s: string) => void形式へ変更する
thisの別名を使った特殊な推論通常のthis参照へ書き換える
関数のprototypeを丸ごと再代入class構文へ移行する

さらに、JavaScriptファイルから生成する.d.tsについては、TypeScript 6と完全に同じ出力にすることが目標ではないとされています。

allowJs、checkJs、declarationを組み合わせてJavaScriptから型定義を生成しているライブラリは、生成された.d.tsの差分を必ず確認してください。(Microsoft for Developers)

テンプレートリテラル型では絵文字の扱いが変わる

TypeScript 7.0では、テンプレートリテラル型の推論でUnicodeコードポイントを自然に扱うようになりました。

type HeadTail<S> =
  S extends `${infer Head}${infer Tail}`
    ? [Head, Tail]
    : never;

type Result = HeadTail<"😀abc">;
// TypeScript 7.0: ["😀", "abc"]

従来は絵文字のようなサロゲートペアがUTF-16の2単位へ分割される場合がありました。TypeScript 7.0では、for...ofやスプレッド構文で文字列を扱う感覚に近い結果になります。

一般的なアプリケーションコードへの影響は限定的ですが、文字列長や文字分割を型レベルで計算するユーティリティでは破壊的変更になる可能性があります。(Microsoft for Developers)

並列数を調整して性能を最適化できる

TypeScript 7.0はデフォルトで4つの型チェッカーワーカーを使用します。新しいオプションを使うと、CPUコア数やメモリ量に合わせて並列処理を調整できます。

checkersで型チェックの並列数を指定する

npx tsc --checkers 8

--checkersの値を増やすと、大規模プロジェクトではさらに速くなる可能性があります。公式の同一環境における--checkers 8の計測では、TypeScript 6比で10.6～16.7倍の高速化が確認されています。

一方、ワーカーごとに一部の計算やメモリが重複するため、並列数を増やせば必ず速くなるわけではありません。

CPUとメモリが限られるCIランナーでは、次のように減らしたほうが安定する場合があります。

npx tsc --checkers 1

buildersでProject Referencesの並列数を指定する

--buildを使用するモノレポでは、--buildersで同時にビルドするプロジェクト数を指定できます。

npx tsc -b --builders 2

--checkersと--buildersは掛け合わせで動作します。

npx tsc -b --checkers 4 --builders 4

この例では、最大16個の型チェッカーが同時に動く可能性があります。ローカル環境では速くても、メモリの少ないCIでは処理速度の低下やメモリ不足につながるため、値を個別に検証してください。

singleThreadedで並列処理を無効化する

npx tsc --singleThreaded

シングルスレッドモードは、次の場面で利用できます。

  • 性能差の原因を調査するとき
  • 外部のビルドツールがすでに並列化しているとき
  • CPUやメモリが限られる環境
  • TypeScript 6とTypeScript 7を比較するとき
  • 並列数によって診断結果が変わる問題を切り分けるとき

TypeScript 7.0の--watchモードも全面的に再構築されています。ファイル監視にはParcelのファイルウォッチャーをGoへ移植した実装が使われ、クロスプラットフォームでの安定性とリソース効率が改善されています。(Microsoft for Developers)

TypeScript 7.0を安全に導入する手順

現在のTypeScript利用方法を確認する

最初に、TypeScriptがどこで利用されているかを整理します。

npm ls typescript

package.jsonのscriptsも確認し、次の工程を区別してください。

  • tscによる型チェック
  • tscによるJavaScript出力
  • バンドラによる変換
  • ESLintなどの型情報を使う解析
  • 宣言ファイルの生成
  • エディターの言語サービス

npm run buildが速くなるかどうかは、実際にそのスクリプトがtscをどの程度使っているかで決まります。

先にTypeScript 6でエラーを解消する

TypeScript 5.x以前を使用している場合は、先に6.0へ上げます。

次の項目を確認してください。

  • ignoreDeprecationsを削除する
  • stableTypeOrderingを有効にして型チェックする
  • rootDirを明示する
  • typesを明示する
  • baseUrlを削除する
  • 古いmoduleとmoduleResolutionを移行する
  • ES5依存の有無を確認する

検証用ブランチでTypeScript 7を導入する

発表時点の7.0系を検証する例です。

npm install -D typescript@~7.0.2
npx tsc --version
npx tsc -p tsconfig.json --noEmit

ロックファイルも更新し、開発者PCとCIが同じバージョンを使う状態にします。

エラー件数だけでなく出力差分も比較する

アプリケーションでは、最低限次の項目を確認します。

  • 型エラーの件数と内容
  • JavaScriptの出力先
  • モジュール形式
  • バンドル結果
  • 単体テスト
  • 統合テスト
  • 本番ビルド
  • エディターの補完と診断

ライブラリでは、さらに次の項目が重要です。

  • .d.tsの差分
  • 公開APIの型
  • 型の並び順
  • JavaScriptから生成した宣言
  • 利用側プロジェクトでの型チェック

性能は複数回計測する

1回だけの実行時間で判断すると、OSキャッシュや依存関係のキャッシュに影響されます。

次の条件を分け、各条件を複数回実行して中央値を比較してください。

time npx tsc -p tsconfig.json --noEmit
time npx tsc -p tsconfig.json --noEmit --checkers 1
time npx tsc -p tsconfig.json --noEmit --checkers 8

Project Referencesを使う場合は、フルビルドと差分ビルドも分けて測ります。

time npx tsc -b --force
time npx tsc -b --force --builders 2

一部のリポジトリから段階展開する

複数のサービスを持つ組織では、最初に次の条件を満たすリポジトリを選ぶと進めやすくなります。

  • 大規模で型チェック時間が長い
  • VueやSvelteなどの埋め込み言語を使っていない
  • コンパイラAPIを使う独自ツールがない
  • TypeScript 6への移行が完了している
  • ロールバックしやすい

効果と問題点を確認した後、同じ構成のプロジェクトへ展開します。

導入時によくある問題と対処方法

症状主な原因対処方法
processやBufferが見つからないtypesのデフォルトが[]"types": ["node"]を設定する
describeやitが見つからないテスト用グローバル型が未指定"types": ["jest"]などを追加する
出力がdist/src配下になったrootDirの変更"rootDir": "./src"を設定する
パスエイリアスが解決できないbaseUrlが削除されたpathsをプロジェクトルート基準へ変更する
tscは動くがリンターが失敗するツールがTypeScript APIを利用TypeScript 6互換パッケージと併用する
VueやSvelteの補完が動かない埋め込み言語ツールが7.0未対応エディターをTypeScript 6へ戻す
ローカルでは速いがCIで遅い並列数に対してCPUやメモリが不足--checkersと--buildersを減らす
npx tscがTypeScript 6を実行するnpmエイリアスのbin競合公式の@typescript/native構成を使う
型は通るが.d.tsの差分が大きい型順序、JSDoc、Unicode処理の変更TypeScript 6でstableTypeOrderingを使い比較する
エディターだけ従来と同じ速度TypeScript 7の言語サーバーが未使用VS Code拡張機能と有効状態を確認する

TypeScript 7.0への対応要否を判断する基準

TypeScript 7.0は、単なる小規模な高速化ではなく、TypeScriptの開発基盤そのものをネイティブ実装へ切り替える大きな転換点です。大規模な型チェック、モノレポ、CI、エディターの起動時間に悩んでいるチームでは、検証する価値が高いリリースです。

一方、導入判断では次の3点を優先してください。

  • TypeScript 6で非推奨設定を解消できているか
  • TypeScriptのプログラムAPIや埋め込み言語へ依存していないか
  • 自社のローカル環境とCIで実際に時間を短縮できるか

3点を満たすプロジェクトは、検証用ブランチでTypeScript 7.0を導入し、型チェック、出力差分、エディター、CIを比較してください。

API依存やフレームワーク側の制約がある場合は、TypeScript 6を維持するか、互換パッケージを使ってTypeScript 7のtscだけを段階的に導入します。見出し上の「約10倍」という数字だけで一括更新せず、依存関係と実行環境を確認したうえで進めることが、最短で安全な移行方法です。

TypeScript
TypeScript Go TypeScript 7.0 ネイティブコンパイラ

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次