TypeScript 7.0の破壊的変更まとめ：削除された機能とアップグレード判断

TypeScript 7.0の破壊的変更まとめ：削除された機能とアップグレード判断

#TypeScript#Web開発#開発手法

2026年7月8日、TypeScript 7.0が正式リリースされました。 コンパイラをGoで書き直し、フルビルドがおよそ10倍高速になった、TypeScript史上最大のメジャーアップデートです。 一方で、tsconfigのデフォルト値の変更とレガシー向けオプションの削除という2系統の破壊的変更を含むため、アップグレード前に影響範囲の確認が必要です。 本記事では、TypeScript 7.0で何が変わったのか、どのプロジェクトが影響を受けるのか、いつアップグレードすべきかを整理します。

Go製ネイティブコンパイラで何が変わったのか

TypeScriptのコンパイラは、これまでTypeScript自身で実装されていました。 7.0では、これをGoで全面的に書き直しています。 2025年にアナウンスされた「ネイティブ移植計画」の完成版で、プレビュー版（@typescript/native-preview）は週850万ダウンロードに達していました。

公式が公開しているフルビルドのベンチマークは次のとおりです。

  • VS Code：125.7秒 → 10.6秒（11.9倍）
  • Sentry：139.8秒 → 15.7秒（8.9倍）
  • Bluesky：24.3秒 → 2.8秒（8.7倍）
  • Playwright：12.8秒 → 1.47秒（8.7倍）
  • tldraw：11.2秒 → 1.46秒（7.7倍）

メモリ使用量は6〜26%削減され、エディタでファイルを開いたときの診断表示は17.5秒から1.3秒未満へ、約13倍に短縮されています。

高速化の理由は、ネイティブコードへの移行と、共有メモリを使ったマルチスレッド化の2点です。 --checkersフラグで型チェックの並列数を調整でき（デフォルト4）、モノレポ向けにはproject referenceを並列ビルドする--buildersも用意されています。

導入企業の公表値も出はじめています。 SlackはCIの型チェックが7.5分から1.25分になりマージキュー全体が40%短縮、MicrosoftのニュースサービスはCIビルド時間を月400時間削減、Canvaはエラー検出が58秒から4.8秒に短縮されました。 この規模になると開発体験の改善にとどまらず、CI費用と待ち時間という直接のコスト削減です。

破壊的変更①：tsconfigのデフォルト値の変更

1つ目の破壊的変更は、tsconfigのデフォルト値の現代化です。

  • strict がデフォルトで true に
  • module のデフォルトが esnext に
  • target のデフォルトが最新の安定版ECMAScriptに
  • noUncheckedSideEffectImports がデフォルトで true に
  • stableTypeOrdering が true 固定に（無効化できない）
  • rootDir のデフォルトが ./ に
  • types のデフォルトが []（空）に

新規プロジェクトで手動設定されることが多かった項目が標準になった形で、方向性としては妥当な変更です。 ただし公式自身が「最も驚かれるのは rootDir と types の変更」と明言しています。

rootDir はこれまで入力ファイルの構成から推論されていましたが、./ 固定になりました。 src 配下にコードを置いているプロジェクトは、明示的な指定が必要になります。

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

types が空デフォルトになった影響も見落としやすいポイントです。 これまで node_modules/@types を自動で読み込んでいたのが読み込まれなくなるため、アップグレード後に process や describe の型が見つからなくなった場合は、これが原因です。

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

移行時につまずくのは、この2つが筆頭になるはずです。

破壊的変更②：レガシー向けオプションの削除

デフォルト値の変更よりも影響が大きいのが、機能ごと削除されたオプション群です。 非推奨化を通り越して、7.0ではエラーになります。

  • target: es5 がサポート終了（ES5へのダウンレベルコンパイル不可）
  • downlevelIteration 削除
  • moduleResolution: node（node10）と classic 削除 → nodenext か bundler へ
  • module: amd / umd / systemjs / none 削除
  • baseUrl 削除
  • esModuleInterop と allowSyntheticDefaultImports は false にできない
  • alwaysStrict は常に true
  • namespace内での module キーワード禁止
  • importの asserts キーワード削除（with に移行）
  • /// <reference no-default-lib /> が無視されるように

象徴的なのは target: es5 の削除です。 「TypeScriptで書いて古いブラウザでも動くコードを出力する」という10年以上続いた使い方が、公式に終了しました。 AMDやSystemJSの削除も同様で、Node.js普及以前・バンドラ乱立期の資産が一括で整理された形です。

JSDocまわりのJavaScriptサポートも整理されています。 @enum の廃止、型の位置に値を書く記法の禁止（typeof が必須に）、後置 ! の非サポートなどが含まれるため、JSDocで型を付けているJavaScriptプロジェクトも確認が必要です。

重要なのは、これらが7.0で突然導入されたわけではない点です。 すべてTypeScript 6系で非推奨警告として予告済みで、6.0で警告、7.0でエラーという二段構えになっています。 つまり移行作業の本体は7.0ではなく6.0側にあります。

破壊的変更③：プログラマティックAPIは7.1まで提供されない

TypeScript 7.0には、コンパイラをJavaScriptから操作するAPIがありません。 新しいAPIは7.1で提供予定です。

影響を受けるのは、コンパイラAPIに依存しているツール群です。 Vue、MDX、Astro、Svelte、Angularテンプレートといった「TypeScriptを埋め込む」タイプの言語ツーリングは、当面TypeScript 6.0に留まる必要があります。

つなぎとして @typescript/typescript6 という互換パッケージが用意されており、tsc6 バイナリと6.0のAPIをそのまま利用できます。 7.0と並走させる構成です。

npm install -D typescript@npm:@typescript/typescript6

Angularでは「CLIの型チェックは7.0、エディタ支援は6.0」というハイブリッド構成が案内されています。 採用しているフレームワークによって、7.0の恩恵をすぐに受けられるかどうかが分かれます。 エコシステムが一時的に分断される点は、このリリースの弱点です。

そのほかの変更点

破壊的変更以外で押さえておきたい変更は次のとおりです。

  • エディタ統合がLSPベースに刷新：TypeScript 6.0比で言語サーバーコマンドの失敗が80%減、クラッシュが60%減。auto-import、インレイヒント、コードレンズ、JSXのlinked editingなども移植済み
  • watchモードの再実装：ParcelのファイルウォッチャーをGoに移植して搭載し、リソース消費が大幅に改善
  • テンプレートリテラル型のUnicode処理の修正：サロゲートペアで分割されていた絵文字などが、コードポイント単位で扱われるように
  • リリースサイクルは従来どおり：7.1以降も3〜4ヶ月ごとに機能リリースを継続予定

型システムの挙動自体はほぼ据え置きです。 「6.0で stableTypeOrdering を有効にしてクリーンにコンパイルできるコードは、7.0でも同一の結果になる」と公式が明言しています。 10倍高速になっても型チェックの結果は変わらない、というのが今回の設計思想です。

いつアップグレードすべきか

一般的なWebプロジェクト（React / Next.js / Nodeなどの構成）であれば、アップグレードを先送りする理由はほとんどありません。 移行作業の本体が6.0側に寄せられているため、手順は実質3ステップです。

  1. TypeScript 6系に上げて、非推奨警告をすべて解消する
  2. rootDir と types を明示する
  3. typescript@7 に上げる

6.0が警告なしで通っていれば、7.0では同じ結果が10倍速く得られるだけです。 CIの型チェックが分単位から秒単位になることは、開発体験の改善であると同時に、CI費用と待ち時間の削減として費用対効果を見積もれます。

一方、待つのが妥当なのはVue / Svelte / Astro / MDXを使っているプロジェクトです。 ツーリングが6.0のAPIに依存しているため、7.1の新APIとエコシステムの追従を待つのが現実的です。

判断が分かれるのは、target: es5 やAMDに依存した長寿プロジェクトです。 6系に留まる選択も可能ですが、それは事実上「このコードベースを延命フェーズに置く」という宣言と同義になります。 閉じた業務システムであればその判断も成立します。 ただし、これは技術リードだけで決める話ではなく、システムの残存期間や更改計画とあわせて事業側と検討すべきテーマです。

まとめ

  • TypeScript 7.0はGo製ネイティブコンパイラ。フルビルドで8〜12倍高速化、メモリ使用量も6〜26%削減
  • 破壊的変更は「デフォルト値の現代化」と「レガシーオプションの削除」の2系統。特に rootDir と types のデフォルト変更に注意
  • target: es5、AMD、baseUrl などは完全削除。ES5時代のプロジェクトはここが分岐点
  • プログラマティックAPIは7.1まで提供されない。Vue / Svelte / Astro / MDX利用プロジェクトは6.0で待機
  • 移行作業の本体は6.0で非推奨警告を解消する工程。それが済めば7.0への更新コストはほぼゼロで、ビルドは約10倍になる

機能追加のないメジャーバージョンで性能改善に徹し、互換性を保ったまま10倍の高速化を実現した、完成度の高いリリースです。 CIの待ち時間はチームの規模に比例して積み上がるコストであり、アップグレードの費用対効果は多くのプロジェクトで明確にプラスになります。

この記事をシェア