はじめに
みなさん、リリースから1ヶ月半以上たちましたがTypeScript 7.0 はもう試しましたか？
2026年7月8日（現地時間）に正式リリースされ、公式ブログでは「10x faster native port of TypeScript」と紹介されています。
バージョン番号こそ 6 → 7 のひとつ上がりですが、中身はコンパイラそのものが Go に移植されたという、なかなかにインパクトのある変更です。
僕自身、業務で TypeScript を触っているので「これは早めにキャッチアップしておかないとまずいやつだな」と思い、公式ブログを読みながら要点をまとめてみました。
今回は「何が変わったのか」「移行するときに何にハマりそうか」を中心に整理していきます!
3行まとめ
- コンパイラと言語サービスが Go にネイティブ移植され、フルビルドが 6.0 比で おおむね 8〜12倍 高速に
- 並列化を制御する
--checkers/--builders/--singleThreadedフラグが追加 - ただし 7.0 には API が同梱されていないため、Vue / Astro / Svelte などのツールチェーンはまだ 6.0 が必要
そもそも TypeScript 7.0 とは
これまでの TypeScript のコンパイラ（tsc）は、TypeScript 自身で書かれていました。
つまり「TypeScript で書かれたコンパイラを JavaScript にコンパイルして、それで TypeScript をコンパイルする」という構成だったわけですね。
TypeScript 7.0 では、このコードベースが Go に移植されました。
ここで大事なのは、ゼロから書き直したわけではないという点です。
公式ブログでは、既存の実装の構造とロジックを保ったまま忠実に移植した、と説明されています。
型チェックのロジックは 6.0 と構造的に同一なので、「7.0 にしたら急に型エラーの出方が変わった」ということは基本的に起きません。
ここが個人的に一番安心できたポイントでした。
インストールはいつも通りです。
npm install -D typescript
① とにかく速い（8〜12倍）
まずは目玉の高速化から。
ネイティブコードの速度、共有メモリによるマルチスレッド処理、そして各種最適化の組み合わせで、フルビルドは通常 8〜12倍速くなるとされています。
公式ブログに載っている、大規模 OSS でのビルド時間の比較がこちらです。
| コードベース | TypeScript 6 | TypeScript 7 | 高速化 |
|---|---|---|---|
| vscode | 125.7s | 10.6s | 11.9x |
| sentry | 139.8s | 15.7s | 8.9x |
| bluesky | 24.3s | 2.8s | 8.7x |
| playwright | 12.8s | 1.47s | 8.7x |
| tldraw | 11.2s | 1.46s | 7.7x |
vscode が 125秒 → 10.6秒 って、ちょっと桁が違いますね…。
しかも面白いのが、速くなったのにメモリ使用量はむしろ減っていることです。
同じく公式の計測では、vscode で 5.2GB → 4.2GB（-18%）、bluesky で 1.8GB → 1.3GB（-26%）といった具合に、6〜26% ほど削減されています。
エディタ側の体感も変わります。
VS Code のコードベースでエラーのあるファイルを開いたとき、最初のエラーが出るまで従来は約 17.5秒 かかっていたところ、7.0 では 1.3秒 未満になったと書かれていました。
実際の導入事例もいくつか公開されています。
- Slack: CI の型チェックが約7.5分 → 1.25分に短縮、マージキューの待ち時間が40%削減
- Canva: エディタで最初のエラーが見えるまで約58秒 → 約4.8秒
- Microsoft の News Services チーム: CI 待ちが月400時間の削減
CI 時間が数分縮むのは、チーム開発だと普通に効いてきますよね。
② 並列化を制御するフラグが追加された
7.0 ではパース・型チェック・emit といった処理が並列に実行されるようになりました。
パースや emit はファイルごとに独立して処理できるので素直に並列化できますが、型チェックはそう単純ではありません。
ファイル同士が依存し合っていますし、チェックの順序によって結果が変わるケースもあるためです。
そこで 7.0 では、決まった数の「型チェッカーワーカー」を立てて、同じ入力なら必ず同じ分割・同じ結果になるようにしています。
このワーカー数を調整するのが --checkers フラグです。
--checkers
型チェックの並列数を指定します。デフォルトは 4。
公式ブログでは --checkers 8 にした場合の比較も載っていました。
| コードベース | TypeScript 6 | TS7 (--checkers 8) |
高速化 |
|---|---|---|---|
| vscode | 125.7s | 7.51s | 16.7x |
| sentry | 139.8s | 12.08s | 11.6x |
| bluesky | 24.3s | 2.01s | 12.1x |
| playwright | 12.8s | 1.16s | 11x |
| tldraw | 11.2s | 1.06s | 10.6x |
vscode が 16.7倍 まで伸びていますね。
ただしワーカーを増やすとメモリ使用量も増えるので、CPU コアやメモリが限られる CI ランナーではむしろ減らしたほうがいい場合もあります。--checkers 1 まで下げられます。
なお、チェッカー数を変えるとまれに順序依存の結果が出ることがあるとも書かれています。
チームで結果を揃えたいなら、環境をまたいで値を固定しておくのが無難そうです。
--builders
--build（Project References）実行時に、同時にビルドするプロジェクト数を制御します。
モノレポで効いてくるやつですね。
注意点として、--checkers と掛け算になります。
--checkers 4 --builders 4 にすると最大 16 個の型チェッカーが同時に走ることになるので、盛りすぎ注意です。
--singleThreaded
並列化を完全に無効化するフラグです。
デバッグ時、6.0 と 7.0 の性能比較をしたいとき、外部で並列ビルドを制御しているとき、リソースが極端に限られた環境などで使います。
なお --checkers と --builders は**experimental（実験的）**な位置づけです。
③ --watch モードが作り直された
--watch の基盤が刷新され、Parcel のファイルウォッチャーをベースにした実装になりました。
背景がちょっと面白かったので触れておきます。
Go の標準ライブラリにはクロスプラットフォームなファイル監視 API がありません。
チームはポーリングベースの実装も試したものの、node_modules を大量に抱えた大規模プロジェクトでは計算コストが高すぎて実用に耐えなかったそうです。
そこで、VS Code が長年使ってきた実績のある @parcel/watcher に目をつけたのですが、これは C++ 実装。そのまま使うと C++ ツールチェーンが必要になってしまいます。
結果として、最小限のアセンブリシムを使いつつ Go に移植するという道を選んだとのことでした。
「C++ から直訳したものを、テストを通したままイディオマティックな Go に磨き上げた」と書かれていて、地味ながらかなり骨のある仕事だなと思います。
これにより、--watch 時のリソース消費がプラットフォーム横断で改善されています。
④ tsconfig のデフォルトが変わっている（要注意）
ここからは移行時にハマりそうなポイントです。
TypeScript 7.0 は 6.0 の型チェック・CLI の挙動と互換になるよう作られています。
ただし、6.0 で変わった新しいデフォルトをそのまま引き継ぎ、6.0 で非推奨になった構文・フラグはハードエラーになります。
つまり 5.x から一気に上げようとすると、7.0 特有の問題というより「6.0 の変更点」でつまずくことになります。
公式も「7.0 への移行を楽にするために、まず 6.0 に上げること」を推奨しています。
主なデフォルト値の変更はこのあたりです。
-
strictがデフォルトでtrue -
moduleのデフォルトがesnext -
targetのデフォルトがesnextの直前の安定 ECMAScript バージョン -
noUncheckedSideEffectImportsがデフォルトでtrue -
libReplacementがデフォルトでfalse -
stableTypeOrderingがデフォルトでtrue（無効化不可） -
rootDirのデフォルトが./に。内側のソースディレクトリは明示指定が必要 -
typesのデフォルトが[]に。従来の挙動に戻すには["*"]を指定
公式が「一番驚くかもしれない」と挙げているのがrootDirとtypesの2つです。
tsconfig.json が src の外にある構成なら、こうしておけば従来のディレクトリ構造を維持できます。
{
"compilerOptions": {
// ...
+ "rootDir": "./src"
},
"include": ["./src"]
}
types のほうは、必要な @types パッケージを明示的に並べる形になります。
{
"compilerOptions": {
+ "types": ["node", "jest"]
}
}
削除されたオプション
「no-op（無視）」ではなくハードエラーになったものたちです。
-
target: es5は非サポート -
downlevelIterationは非サポート -
moduleResolution: node/node10は非サポート（nodenextかbundlerを推奨） -
module: amd/umd/systemjs/noneは非サポート（esnextかpreserveを推奨） -
moduleResolution: classicは非サポート -
baseUrlは非サポート（pathsをプロジェクトルート相対に書き換える） -
esModuleInterop/allowSyntheticDefaultImportsをfalseにできない -
alwaysStrictは常にtrue - namespace 宣言で
moduleキーワードが使えない - import での
assertsキーワードが使えない（withを使う） - カレントディレクトリに
tsconfig.jsonがあるとき、CLI でファイルパスを渡せない（--ignoreConfigが必要）
baseUrlあたりは使っているプロジェクトも多そうなので、事前に grep しておくと良さそうです。
⑤ テンプレートリテラル型が Unicode コードポイントを保持するように
地味だけど個人的に「おっ」となった変更です。
type HeadTail<S> = S extends `${infer Head}${infer Tail}` ? [Head, Tail] : never;
type Result = HeadTail<"😀abc">;
// 7.0: ["😀", "abc"]
// 6.0まで: ["\ud83d", "\ude00abc"]
従来は JavaScript の UTF-16 のインデックス挙動に従っていたため、絵文字がサロゲートペアの片割れに分割されていました。
"😀abc"[0] と一致するという意味では技術的に一貫していたのですが、意図した挙動ではないことがほとんどですよね。
7.0 では for...of やスプレッド構文（[...str]）でイテレートしたときと同じ直感に揃えられました。
なお、UTF-16 コードユニットを意図的にモデリングしていた型レベルの文字列操作（Length 系のユーティリティなど）にとっては破壊的変更になります。
⑥ JavaScript サポートの仕様が見直された
.js ファイルの JSDoc 解析まわりも整理されました。
これまでは Closure や JSDoc ツールが理解しそうなパターンを個別対応してきた結果、.ts の解析と挙動が乖離していたそうです。
7.0 では .ts の解析と一貫させる方向に寄せられています。
主な違いはこのあたり。
- 型が期待される場所で値を使えない →
typeof someValueと書く -
@enumが特別扱いされない →@typedefで(typeof YourEnumDeclaration)[keyof typeof YourEnumDeclaration]を書く - 単独の
?を型として使えない →anyを使う -
@classを付けても関数がコンストラクタにならない →class宣言を使う - 後置の
!は非サポート →Tをそのまま使う - 型名は
@typedefタグ内で定義する必要がある - Closure スタイルの関数構文（
function(string): void）は非サポート →(s: string) => void
thisのエイリアスやprototypeの丸ごと再代入といったパターンも特別扱いされなくなりました。
詳細な差分は typescript-go リポジトリの CHANGES.md にまとまっています。
⑦ エディタ体験（LSP ベースに）
新しい言語サーバーは LSP（Language Server Protocol）ベースになり、マルチスレッドで同時リクエストを捌けるようになりました。
安定性も上がっていて、公式のデータでは 6.0 と比較して
- 失敗する言語サーバーコマンドが 80%以上減少
- サーバークラッシュが 60%以上減少
とのことです。
VS Code には専用の拡張機能が用意されていて、インストールするとデフォルトの体験として有効になります。
コマンドパレットの「Disable / Enable TypeScript 7 Language Server」でいつでも切り替え可能です。
数週間のうちに VS Code 本体にも取り込まれる予定と書かれていました。
Visual Studio ではワークスペースに応じて自動で 7.0 が有効になります。
⑧【重要】7.0 には API がない
ここが今回一番の「待ち」ポイントかもしれません。
TypeScript 7.0 には API が同梱されていません。
新しい API は 7.1 で提供予定とされています。
これが何を意味するかというと、コンパイラにプログラム経由でアクセスするツール群がまだ 7.0 に乗れない、ということです。
具体的には、
-
typescript-eslint など
typescriptパッケージを直接 import するツール - Vue / MDX / Astro / Svelte など、Volar 経由で TypeScript を埋め込んでいるツール
-
Angular のテンプレート内の型チェック
このあたりは当面 6.0 が必要です。
6.0 と併用する方法
そのために @typescript/typescript6 という互換パッケージが公開されました。
これは tsc6 という名前の実行ファイルを提供するので、7.0 の tsc と名前が衝突しません。
typescript-eslint のように peer dependencies 経由で typescript を直接 import するツールがあるため、公式は npm alias での導入を推奨しています。
npm install -D typescript@npm:@typescript/typescript6
ただしこれだけだと tsc6 しか使えません。
7.0 の tsc も併用したい場合は、もう一段 alias を張ります。
{
"devDependencies": {
"@typescript/native": "npm:typescript@^7.0.2",
"typescript": "npm:@typescript/typescript6@^6.0.2"
}
}
これで npx tsc は 7.0 として動きます。
今後のロードマップ
7.0 のリリースをもって、チームは新機能開発・エルゴノミクス改善・さらなる性能改善、そしてエコシステム向けの新 API 実装に戻るとのことです。
リリース間隔も従来通り 3〜4ヶ月ごとに戻る想定と書かれていました。
直近では 7.1 で新 API が来るので、ツールチェーンの移行が本格化するのはそこからになりそうです。
おわりに
今回は TypeScript 7.0 の変更点をまとめてみました。
個人的な所感としては、
- 速度面のメリットは疑いようがない（特に CI と大規模モノレポ）
- ただし API がないので、いきなり全部を 7.0 に寄せるのは難しい
- dependabot 対応等 でこの辺りの関係で見送ることも
- まずは 6.0 に上げて
tsconfig.jsonを整えるのが最初の一歩
というところかなと思っています。
「7.0 にするぞ!」と気合を入れるより、先に 6.0 移行を済ませておくほうが結果的に近道になりそうです。
baseUrl や types あたりは、今からでも棚卸ししておいて損はないはずです。
みなさんもぜひ、まずは手元のプロジェクトで npx tsc の時間を測ってみてください!