2026年6月18日、Microsoft は TypeScript 7.0 の RC（リリース候補）を公開しました（公式ブログ）。コンパイラを Go 言語で全面再実装したメジャーバージョンであり、正式版は「1か月以内」とアナウンスされています。型システムと構文は TypeScript 6.0 と互換ですが、tsconfig.json のデフォルト変更とレガシー機能の削除を含むため、多くのプロジェクトで設定の明示化が必要です。

以下のいずれかに該当するなら、この記事はあなたのチームのための記事です。

• strict: false のまま運用してきた tsconfig.json がある
• CI のビルド時間が tsc だけで数分かかっている
• module: "commonjs" + moduleResolution: "node" で設定が固定されている
• ESLint カスタムルールや ts-morph など TypeScript API を直接使うツールがある

速報記事は多数出ていますが、「自分のプロジェクトは今すぐ動くべきか」を判断できる実用的な情報はまだ多くありません。本記事では、変更内容を整理したうえで、TECH PLAY の実プロジェクト2つでの検証結果を交えて移行タイミングの判断材料を提供します。

TypeScript 7.0 の全体像 — 言語は同じ、エンジンが別物

まず押さえておくべきポイントは、TypeScript の型システムと構文は変わっていないということです。公式ブログでも "Its type-checking logic is structurally identical to TypeScript 6.0." と明記されています。

変わったのは、コンパイラの実装言語です。

項目	TypeScript 6.x 以前	TypeScript 7.0
コンパイラの実装言語	TypeScript（Node.js で実行）	Go（ネイティブバイナリ）
並行処理	シングルスレッド	マルチスレッド（共有メモリ並列）
エディタ連携	TSServer（独自プロトコル）	LSP（Language Server Protocol）
配布形式	npm パッケージ（JS）	npm パッケージ（ネイティブバイナリ同梱）

Go が選ばれた理由は「ネイティブコードの速度と共有メモリによる並列処理」を両立できるためです。エディタ連携については、Go プロセスと Node.js 間の同期通信を実現する Rust 製モジュール（libsyncrpc）が開発されています（Native Previews ブログ、2025年5月22日）。

コンパイル速度10倍 — 数字の裏側

「10倍速い」という数字の実態を見てみます。Microsoft が 2025年5月の Native Previews ブログ で公開した Sentry のベンチマーク（約9,300ファイル・約111万行の TypeScript コード）では、以下の結果が出ています。

指標	TypeScript 5.8	ネイティブ実装	倍率
総コンパイル時間	72.81秒	6.76秒	10.8x
型チェック時間	63.26秒	5.88秒	10.8x

同じく Microsoft の A 10x Faster TypeScript（2025年3月11日）では、規模別の結果も公開されています。

プロジェクト	規模	速度向上
VS Code	150万行	10.4x
Playwright	35.6万行	10.1x
TypeORM	27万行	13.5x

Bloomberg、Canva、Figma、Google、Linear、Notion、Slack、Vercel 等がプレリリーステストに参加しています。この速度改善を支えているのが、新しい並列化オプションです。

• --checkers（デフォルト: 4）: 型チェックを複数ワーカーで並列実行
• --builders: プロジェクトリファレンス（モノレポ等で複数 tsconfig を連携させる仕組み）の並列ビルド
• --singleThreaded: デバッグや CI 環境向けにシングルスレッド実行を強制

--checkers 4 --builders 4 の組み合わせでは最大16の型チェッカーが同時に動作します。メモリ消費量も比例して増えるため、CI 環境（GitHub Actions standard runner: 7GB RAM）ではチェッカー数を 2 程度に抑えるか、メモリ使用量のモニタリングを推奨します。

既存プロジェクトへの影響チェックリスト

ここからが本記事の核心です。TypeScript 7.0 RC には複数の破壊的変更が含まれています。あなたのプロジェクトが影響を受けるか、以下の5項目で確認してください。

1. tsconfig.json のデフォルト値変更

最も多くのプロジェクトに影響する変更です。

設定	旧デフォルト	7.0 デフォルト
strict	false	true
module	commonjs	esnext
rootDir	自動推定	./
types	["*"]（全自動検出）	[]
noUncheckedSideEffectImports	false	true

tsconfig.json の Before / After 例（React + Vite プロジェクト）:

// Before: 暗黙のデフォルトに依存（TypeScript 6.x）
{
  "compilerOptions": {
    "target": "ES2020",
    "jsx": "react-jsx",
    "moduleResolution": "bundler",
    "paths": { "@/*": ["./src/*"] }
  },
  "include": ["src"]
}

// After: 7.0 で明示化が必要な設定を追加（TypeScript 7.0 RC）
{
  "compilerOptions": {
    "target": "ES2020",
    "module": "esnext",
    "jsx": "react-jsx",
    "moduleResolution": "bundler",
    "rootDir": "./src",
    "types": ["vite/client"],
    "paths": { "@/*": ["./src/*"] }
  },
  "include": ["src"]
}

noUncheckedSideEffectImports が true になるため、CSS 等の副作用 import（import "./style.css"）にはアンビエントモジュール宣言（declare module "*.css" {}）が必要です。Vite プロジェクトでは vite-env.d.ts で自動カバーされます。宣言ファイルの配置には罠があるため、後述の「ハマったポイント」も参照してください。

今すぐできること: 現在の tsconfig.json に上記の設定を明示的に書き出しておくと、7.0 移行時の差分が明確になります。

2. 削除された機能

以下の機能は TypeScript 7.0 で完全に削除されました。該当する場合は移行前に対応が必須です。

• target: "es5" — ES5 への変換は廃止。最低でも ES2015 以上に変更
• module: "amd" | "umd" | "systemjs" — レガシーモジュールシステムは廃止。"preserve" + "bundler" へ
• moduleResolution: "node" | "node10" | "classic" — "nodenext" または "bundler" へ
• baseUrl — paths のパス指定をプロジェクトルートからの相対パスに書き換え
• downlevelIteration — ES5 ターゲットの廃止に伴い不要に
• esModuleInterop: false / allowSyntheticDefaultImports: false — 常に true として扱われ、無効化できない
• import ... assert — with キーワードに変更（import data from "./data.json" with { type: "json" }）
• namespace 宣言での module キーワード — namespace キーワードのみ使用可

3. JavaScript / JSDoc サポートの変更

.js ファイルで checkJs を使っているプロジェクトのみ影響があります。@enum や @class の廃止、値を型として使う場合の typeof 必須化など、複数の破壊的変更があります。純粋な .ts プロジェクトは影響なし。変更の全リストは CHANGES.md（typescript-go） を参照してください。

4. プログラマティック API と周辺ツール

TypeScript 7.0 は Go で再実装されたため、従来の Node.js 向けプログラマティック API（ts.createProgram() 等）が存在しません。公式ブログでも "we won't have a stable programmatic API available until at least several months from now with TypeScript 7.1" と明言されています。typescript パッケージを import しているツールは、実行時に ERR_PACKAGE_PATH_NOT_EXPORTED でクラッシュします。

主要ツールの対応状況（2026年6月28日時点）:

ツール	TS 7.0 対応	備考
typescript-eslint	未対応	TS API に依存。対応には 7.1 の IPC API が必要（#10940）
ts-morph	未対応	作者が「ts-morph may not continue to exist」と言及（#1621）
ts-jest	未対応	ts.transpileModule() を直接使用。対応の動きなし
vitest	影響なし	esbuild で変換するため TS API 不使用。vitest typecheck は tsc を外部起動
prettier	動作確認済み	内部で typescript-estree を使うが実動作に問題なし。babel-ts パーサーで完全回避も可能

コミュニティの互換性テスト（参考記事）では、esbuild、Biome v2、Prisma Client 等の独自パーサーを持つツールは問題なく動作しています。

公式推奨の回避策: npm alias による並行インストール

移行期間中は、ツールチェーン用に TS 6.x を残しつつ、型チェック用に TS 7.0 を使う並行運用が公式に推奨されています（RC ブログ）。package.json の devDependencies で npm alias を使い、typescript（TS 6）と typescript-7（TS 7）を共存させる方式です。具体的な設定方法と CI での動作実績は、後述の「TECH PLAYでの移行検証」で詳しく解説します。

5. 並行実行による再現性の考慮

--checkers による並列型チェックでは、まれに実行順序に依存する結果の差異が生じます。CI と開発環境で --checkers の値を統一してください（package.json の scripts で tsc --noEmit --checkers 2 のように指定）。

移行タイミング判断マトリクス

上記のチェックリストを踏まえ、プロジェクトがいつ動くべきかを3段階で整理します。

今すぐ RC を試す

• tsconfig.json が既に strict: true かつ moduleResolution: "nodenext" または "bundler"
• ビルド速度がボトルネックになっている大規模プロジェクト
• 新規プロジェクトの立ち上げ

npm install -D typescript@rc
npx tsc --noEmit  # 既存コードの互換性チェック

後述の TECH PLAY 実測では、strict: true のプロジェクトなら tsconfig.json の調整だけで移行でき、アプリコードの変更は0行でした。

正式版リリース後に移行

• 現在 strict: false で運用しているプロジェクト（型エラー修正の工数が必要）
• レガシーモジュール設定（module: "commonjs" + moduleResolution: "node"）を使用中
• ES5 ターゲットを指定しているプロジェクト

7.1 以降まで様子見

• typescript-eslint のカスタムルールや ts-morph 等、TypeScript API に依存するツールを CI で利用中（ts-morph は存続自体が不透明 — #1621）
• npm alias パターンで TypeScript 6.x との並行運用が可能（後述の検証セクション参照）

移行のトレードオフ

• ツールチェーンの断絶: プログラマティック API が 7.1 まで未提供のため、typescript-eslint 等の対応を待つ期間が生じる
• メモリ消費の増加: 並列チェッカーの分だけメモリを消費。CI の standard runner で OOM になる可能性
• RC 段階のリスク: Go 再実装のため、未発見の差異が残る可能性がある

TECH PLAY での移行検証 — 規模の異なる2プロジェクトで実測

記事の検証として、TECH PLAY の管理画面（392ファイル）とイベント参加者向け Web アプリ（11,736ファイル）の2プロジェクトで TS 7.0.1-rc への移行を実施し、いずれも GitHub Actions の CI パイプライン全体で動作を確認しました。以下のハマりポイントは Next.js 固有ではなく、TypeScript を使うプロジェクト全般に当てはまります。

検証環境

項目	Admin（管理画面）	Webアプリ
フレームワーク	Next.js 16	Laravel 12 + Inertia.js + React 18
コードベース	392ファイル・約3.7万行	11,736ファイル・約18万行
移行前	TypeScript 6.0.3	TypeScript 5.9.2

tsconfig.json の変更差分

移行で必要だった変更は tsconfig.json の5箇所と型宣言ファイル1つ（assets.d.ts・2行）のみです。アプリケーションコードの変更は0行。

 {
   "compilerOptions": {
-    "baseUrl": ".",
-    "target": "es5",
+    "target": "esnext",
     ...
-    "moduleResolution": "node",
+    "moduleResolution": "bundler",
     ...
     "paths": {
       "~/*": [
-        "src/*"
+        "./src/*"
+      ],
+      "src/*": [
+        "./src/*"
       ]
     }
   }
 }

各変更のポイント:

#	変更内容	理由
1	baseUrl: "." を削除	TS 7 で廃止。paths を相対パスに書き直す
2	target: "es5" → "esnext"	ES5 ターゲット廃止。バンドラ（Next.js）が変換を担当
3	moduleResolution: "node" → "bundler"	"node" は TS 7 で廃止
4	paths の値を ./src/* に修正	baseUrl 廃止に伴い相対パスが必要に
5	"src/*" パスエイリアス追加	baseUrl: "." で暗黙解決されていた non-relative import の代替

strict: true プロジェクトなら、これらの設定変更だけで移行できます。strict: false のプロジェクトでは strict: true がデフォルトになるため、既存の型エラー修正が追加で必要です。

ベンチマーク結果

TECH PLAY では規模の異なる2つのプロジェクトで計測しました。

フルビルド（tsc --noEmit）

プロジェクト	規模	TS 5〜6（Node.js）	TS 7.0.1-rc（Go）	倍率
Admin（管理画面）	392ファイル・3.7万行	2.07秒	0.31秒	6.7x
Webアプリ	11,736ファイル・18万行	19.3秒	2.4秒	8.0x

ファイル数が30倍になると、TS 7 の並列チェッカー（--checkers、デフォルト4）が効果を発揮し、倍率が6.7x → 8.0xに向上しています。Web アプリの計測では CPU 使用率が350%を超えており、複数チェッカーが同時に型検査を実行していることが確認できました。Microsoft の公表値（Sentry 9,300ファイル: 10.8x）と整合する結果です。

watch モード初期コンパイル（ホストマシン・macOS・Admin）

指標	TS 6.0.3	TS 7.0.1-rc	倍率
tsc --watch 初期コンパイル	11.6秒	3.5秒	3.3x

watch モードはファイル監視のセットアップを含むため、フルビルドほどの倍率は出ません。ただし watch の再起動を1日に何度も繰り返す開発サイクルでは、1回あたり約8秒の短縮は体感に直結します。

Docker 環境での注意: TS 7 の Go 製バイナリは Linux の fanotify API でファイル変更を検知します。Docker コンテナのデフォルト設定では fanotify_mark: operation not supported で tsc --watch が起動しません。フルビルド（tsc --noEmit）は問題なく動作するため、CI には影響しませんが、Docker ベースの開発環境で watch モードを使う場合はコンテナの権限設定に注意してください。

npm alias パターンで CI を通す

移行で最初にぶつかった壁は、npm install typescript@rc が peer dependency 衝突で失敗することでした。@typescript-eslint が typescript: <6.1.0 を要求しており、TS 7 と共存できません。

解決策は、RC ブログで推奨されている npm alias パターン — ツールチェーン用の TS 6 と型チェック用の TS 7 を同じ node_modules に共存させる方式です。

// package.json
{
  "devDependencies": {
    "typescript": "~6.0.1",
    "typescript-7": "npm:typescript@^7.0.1-rc"
  },
  "scripts": {
    "lint:types": "node_modules/typescript-7/bin/tsc --pretty --noEmit",
    "lint:eslint": "eslint src"
  }
}

# 型チェック（TS 7 の Go ネイティブバイナリで実行）
npm run lint:types

# eslint（typescript パッケージ = TS 6.0.3 の JS API を参照）
npm run lint:eslint

公式ブログでは "typescript": "npm:@typescript/typescript6@^6.0.0" という alias が紹介されていますが、@typescript/typescript6 パッケージの内部で module.exports = require("typescript") が実行され、alias 名と循環参照を起こして動作しません。"typescript": "~6.0.1" で TypeScript 6.x を直接インストールするのが確実です。

この構成で GitHub Actions の CI が全ステップ通過しました。tsc --noEmit（TS 7）・eslint（TS 6 API 経由）・prettier・stylelint のすべてが1つの CI ジョブ内で正常に動作しています。

ハマったポイント4選

1. baseUrl 廃止で309件のエラー爆発
baseUrl: "." を削除した瞬間、src/components/... 等の non-relative import が全滅しました。paths に "src/*": ["./src/*"] を1行追加するだけで全件解決します。エラー数に圧倒されますが、修正自体は tsconfig.json の1行で済むので落ち着いて対処してください。

2. CSS の declare module がモジュールファイル内で効かない
noUncheckedSideEffectImports: true（TS 7 デフォルト）により、CSS の副作用 import（import "./style.css"）にはアンビエントモジュール宣言（declare module "*.css" {}）が必要になります。既存の global.d.ts に追記するのが自然な発想ですが、同ファイルに export {} があるとモジュールファイル扱いになり、アンビエント宣言として機能しません。export を含まない専用ファイル（例: assets.d.ts）に分離する必要があります。公式ドキュメントに記載がなく、最もハマったポイントでした。

3. ネイティブバイナリのプラットフォーム依存
TS 7 の npm パッケージには Go 製のネイティブバイナリ（darwin-arm64、linux-x64 等）が同梱されています。macOS で npm install した node_modules を Docker（Linux）にマウントすると、バイナリのプラットフォームが不一致で動作しません。CI やコンテナ環境ではコンテナ内で npm ci を実行してネイティブバイナリを再取得してください。

4. @typescript/typescript6 ラッパーの循環参照
公式ブログの npm alias 例（"typescript": "npm:@typescript/typescript6@^6.0.0"）をそのまま使うと、ラッパーパッケージ内部の require("typescript") が自分自身を参照する循環参照が発生します。eslint --print-config 等が無限ループでハングするため、"typescript": "~6.0.1" で TypeScript 6.x を直接インストールする方が安全です。

所感 — 導入する価値はあるか

2つのプロジェクトで検証した結果、CI の全パイプラインが通過しました。

• Admin（typescript-eslint 使用）: npm alias パターンで TS 6/7 を並行インストールし、tsc・eslint・prettier・stylelint が全ステップ通過
• Web アプリ（Biome 使用）: typescript を直接 7.0.1-rc にアップグレードするだけで、tsc・Biome lint・vitest（1,047テスト）・Storybook ビルド・インタラクションテストが全ステップ通過。npm alias は不要

typescript-eslint を使っていないプロジェクトなら、package.json の typescript バージョンを上げるだけで移行できます。typescript-eslint を使っている場合は、7.1 で提供予定の IPC ベース API を待つ必要があります（typescript-eslint #10940、typescript-go Discussion #455）。RC ブログでは "we won't have a stable programmatic API available until at least several months from now with TypeScript 7.1" と記載されており、2026年後半以降になる見込みです。それまでは npm alias パターンで十分に運用できます。

結論として、strict: true のプロジェクトであれば TS 7 は導入する価値があります。設定ファイルの調整だけで6〜8倍の型チェック高速化が得られ、アプリケーションコードの変更は不要です。特に大規模プロジェクト（Web アプリ: 11,736ファイルで8.0x）では並列チェッカーの恩恵が大きく、CI の実行時間短縮はチーム全体の開発サイクルに直結します。TECH PLAY でも、正式版のリリースと typescript-eslint の対応状況を見て本番導入を進める予定です。

まとめ

TypeScript 7.0 は、型システムの互換性を維持しながらコンパイラの実装を根本から刷新したリリースです。多くのプロジェクトにとって最もリスクの少ない準備は、今のうちに tsconfig.json の設定を明示化し、npm install -D typescript@rc && npx tsc --noEmit で互換性を確認することです。

ツールチェーン（typescript-eslint 等）の安定対応は 7.1 を待つ必要があるため、急いで全面移行する必要はありません。

---

参考文献

• Announcing TypeScript 7.0 RC - TypeScript Blog（2026年6月18日）
• Announcing TypeScript Native Previews - TypeScript Blog（2025年5月22日）
• A 10x Faster TypeScript - TypeScript Blog（2025年3月11日）
• TypeScriptコンパイラがGo言語に移植され10倍速に - Publickey（2026年6月24日）
• CHANGES.md - typescript-go（GitHub）