TypeScript 7とは？いつ出た？6.0からの移行手順と変わった点【2026年10月】

TypeScript 7 は、TypeScript のコンパイラ（tsc コマンド）を Go という言語に移した新しい版です。コンパイラとは、.ts のファイルの型の誤りを調べ、.js のファイルに変換する道具のことです。正式版は2026年7月8日（日本時間では7月9日）に出ていて、公式は「10 倍速い」「本番で使える」と紹介しています（2026年10月時点）。

この記事は、TypeScript を使っていて、いまのプロジェクトを 7 に上げてよいか知りたい人に向けて、公式の資料に書かれていることを整理します。コマンドを実行して確かめた結果は、日付と環境を添えて、公式の記述とは分けて書きます。公式は、7 に上げる前にまず 6.0 に上げることを勧めています。一方で、typescript-eslint のように、2026年10月3日時点で 7 に対応していない道具もあります。

TypeScript 7 とは？Go に移したコンパイラ

TypeScript は、JavaScript に型の書き方を足した言語です。型チェックで誤りを見つけ、エディタの手助けを充実させます。TypeScript そのものの説明は、React と TypeScript の違いの記事にもあります。.js・.jsx・.ts・.tsx のファイルの違いと使い分けは、こちらの記事で説明しています。

これまでの TypeScript のコンパイラは、TypeScript で書かれ、JavaScript にコンパイルされて動いていました。TypeScript 7 は、そのコードを Go に移したものです。公式は、Go で作った「ネイティブ」の移植版で、いまのハードウェアを活かすことが目的だと書いています。7.0.2 の tsc は、OS と CPU ごとに分かれた実行ファイルを起動する作りです（あとの「入れるときの注意」で説明します）。

大事なのは、「書き直し」ではなく「移植」だという点です。公式は、新しい Go のコードは元の実装から移植したもので、一から書き直したものではなく、型チェックのロジックは 6.0 と構造が同じだと書いています。元のコードの構造とロジックを保つことで、6 と 7 の結果がそろうようにしています。

そのため、自分が書いた TypeScript のコードが Go に変わるわけではありません。変わったのは、TypeScript 自身を作っている言語です（詳しくは「よくある質問」で説明します）。

公式の資料では、6 を「TypeScript 6 (JS)」、7 を「TypeScript 7 (native)」と呼び分けています。開発中の呼び名は、元のコンパイラが「Strada」、今回の移植が「Corsa」でした。

入れ方は、これまでと同じ npm です。次のコマンドで新しい tsc がプロジェクトに入り、npx tsc で動かせます。npm・yarn・pnpm の違いは、こちらの記事で説明しています。

npm install -D typescript

2026年10月3日時点で入るのは 7.0.2 で、package.json には "typescript": "^7.0.2" と書かれます。版は次のコマンドで確かめられます（TypeScript 7.0.2 の出力）。

$ npx tsc --version
Version 7.0.2

ただし、「7 でも書き方は何も変わらない」という意味ではありません。公式は、既定値が変わったものと、エラーになる設定や書き方があると書いています。詳しくは「6.0 から何が変わった？」の節で説明します。

TypeScript 7 はいつ出た？正式版は 7.0.2、7.1 の予定は？

正式版は、公式ブログの日付で2026年7月8日（日本時間では7月9日）に出ました。npm に 7.0.2 が出たのも、同じ2026年7月8日です。

正式版の版番号は 7.0.2 です。 7.0.0 や 7.0.1 という正式版は、npm の typescript にありません（RC の版は 7.0.1-rc でした）。6.0 も同じで、ベータは 6.0.0-beta、RC は 6.0.1-rc、正式版は 6.0.2 でした（2026年10月3日時点）。RC は、正式版の候補のことです。

公式ブログの記事の日付で並べると、次のとおりです。日付は UTC（世界の標準時）で、日本時間は UTC に 9 時間を足した時刻です。

公式ブログの日付（UTC）	日本時間	できごと
2025年3月11日	3月11日 23:31	Go への移植を発表
2025年5月22日	5月23日 0:04	ネイティブのプレビューを npm と VS Code で公開
2025年12月2日	12月3日 2:31	進み具合の報告（Progress on TypeScript 7 – December 2025）
2026年2月11日	2月12日 3:50	6.0 ベータ
2026年3月6日	3月7日 4:13	6.0 RC
2026年3月23日	3月24日 1:34	6.0 正式版
2026年4月21日	4月22日 3:24	7.0 ベータ
2026年6月18日	6月18日 23:31	7.0 RC
2026年7月8日	7月9日 0:58	7.0 正式版

7.0 のあとの修正版は、2026年10月3日時点で出ていません。npm の 7.0 系の正式版は 7.0.2 だけで、latest（何も指定せずに入れたときに入る版）も 7.0.2 です。

移植の作業場所だった microsoft/typescript-go は、作業が終わって閉じられ、2026年10月3日時点で読むだけの状態（archived）です。開発は、元の microsoft/TypeScript に戻りました。

7.1 の予定（2026年10月3日時点の計画）

次の版の 7.1 については、公式の Issue「TypeScript 7.1 Iteration Plan」に、次の予定が書かれています。

予定日	内容
2026年10月6日	7.1 ベータ
2026年11月10日	7.1 RC
2026年11月24日	7.1 正式版

これは計画で、2026年10月3日時点で 7.1 は出ていません。計画の中身には、API を安定させること、lib と target に es2026 を足すことなどが並んでいます。7.0 の記事には、7.1 は新しい（これまでと違う）API を載せる見込みだと書かれています。7.0 には API が無い点は、あとの「7 にまだ対応していないものは？」の節で説明します。

7.0 のあとは、新しい機能・使いやすさの改善・速さ・新しい API の仕事に戻ると、公式は書いています。機能を足した版は、これまでと同じく 3〜4 か月ごとに出す見込みです。

6.0 はどうなる？

6.0 は、JavaScript で書かれた最後の版です。公式は、6.1 は出さない予定だと書いています。ただし、まれに 6.0.1 や 6.0.2 のような修正版を出すことはある、としています。修正版を出すのは、セキュリティの問題、深刻な退行（5.9 には無かった新しい深刻な不具合）、6.0 と 7.0 の互換に関わる深刻な修正のときです。6.0 のサポートがいつ終わるかは、確かめた公式の資料には見当たりません（2026年10月3日時点）。

どれくらい速くなった？公式の数字と測った条件

公式は、速くなる理由を「ネイティブコードの速さ」「メモリを共有するマルチスレッド」「新しい最適化」の 3 つだとして、フルビルド（全体を通して行うビルド）で、たいてい 8〜12 倍速くなると書いています。速さは Go を使うことだけでなく、メモリを共有する並列処理・並行処理からも来ている、とも書かれています。

公式は、かなり大きなオープンソースの 5 つのコードで、TypeScript 6 と 7 のビルド時間を比べた表を載せています。自分でも比べられる、と書かれています。7 は既定の --checkers 4 で測っていて、同じマシンで --checkers 8 にした結果も載っています。次の表は、その 2 つの表を 1 つにまとめたものです。数字は 7.0 の正式版の記事のものです（2026年7月8日）。

コード	TypeScript 6	TypeScript 7（既定の --checkers 4）	TypeScript 7（--checkers 8）
vscode	125.7 秒	10.6 秒（11.9 倍）	7.51 秒（16.7 倍）
sentry	139.8 秒	15.7 秒（8.9 倍）	12.08 秒（11.6 倍）
bluesky	24.3 秒	2.8 秒（8.7 倍）	2.01 秒（12.1 倍）
playwright	12.8 秒	1.47 秒（8.7 倍）	1.16 秒（11 倍）
tldraw	11.2 秒	1.46 秒（7.7 倍）	1.06 秒（10.6 倍）

表を読むときの注意です。

• 公式の言い方は「たいてい 8〜12 倍」です。表には 7.7 倍の行（tldraw）もあるので、どのプロジェクトでも 8 倍以上になる、という意味ではありません
• 公式は「結果はプロジェクトとマシンで変わる」と書いています。測ったマシンの性能は、公式の記事には書かれていません（2026年10月時点）
• ほかの時期の公式の記事にも速さの表がありますが、測った時期と条件が違います。この記事では、7.0 の正式版の記事の表だけを使います

メモリについて、公式は「ビルド全体で必要なメモリの合計も、たいてい少なく済む」と書いています。表の増減（％）は公式の表のままです。GB は丸めた値なので、GB から計算し直すと合わない行があります。

コード	TypeScript 6	TypeScript 7	増減（公式の表のまま）
vscode	5.2GB	4.2GB	-18%
sentry	4.9GB	4.6GB	-6%
bluesky	1.8GB	1.3GB	-26%
playwright	1.0GB	0.9GB	-11%
tldraw	0.6GB	0.5GB	-15%

エディタでも速くなったと、公式は書いています。同じコンピュータで、VS Code のコードのエラーのあるファイルを開くと、最初のエラーが出るまでに約 17.5 秒かかっていました。7 では 1.3 秒未満（13 倍以上）です。

公式ブログは、使っている会社の声も紹介しています。各社の測り方は書かれていません。

• Slack: CI（変更のたびに自動で行う検査）での型チェックが約 7.5 分から 1.25 分になり、マージ待ちの時間の 40% がなくなった
• Canva: エディタで最初のエラーが出るまでが、約 58 秒から約 4.8 秒になった
• Vanta: いちばん大きなプロジェクトの 1 つで、最大 9 倍速くなった
• Microsoft の News Services チーム: CI のビルドを待つ時間が、月 400 時間減った

公式は「本番で使える（Ready for Production）」という見出しの節に、この 1 年、社内外の多くの大きなチームと一緒に、現実のコードで TypeScript 7 を試した、と書いています。名前が挙がっているのは、Microsoft の Loop・Office・PowerBI・Teams・Xbox と、社外の Bloomberg・Canva・Figma・Google・Slack・Vercel などです。

並列の設定: --checkers・--builders・--singleThreaded

7.0 は、構文の読み取り・型チェック・出力など、多くの手順を並列（同時進行）で行います。並列の度合いを決めるフラグが 3 つあり、--checkers と --builders は公式が「実験的」としています。

フラグ	何をするか
--checkers	型チェックの作業者（worker）の数。既定は 4。増やすと、CPU コアの多いマシンで大きなコードが速くなることがありますが、メモリはたいてい増えます。CPU コアやメモリが少ないマシン（例: CI のランナー）では、減らしたほうがよいことがあり、最小は --checkers 1 です
--builders	--build のときに、プロジェクト参照（project references）を同時にいくつビルドするか。モノレポ（複数のプロジェクトを 1 つのリポジトリで管理する構成）で役に立ちます。--checkers と掛け算になり、--checkers 4 --builders 4 なら最大 16 の型チェックが同時に動きます。公式は「多すぎるかもしれない」と書いています
--singleThreaded	並列をやめる。型チェックの作業者を 1 にして、読み取りと出力も 1 本のスレッドで行います。デバッグや、資源の限られた環境で役に立つことがあります

まれに、--checkers の数を変えると、順番に左右される結果が出ることがあります。ビルドする環境ごとに数を固定しておくと全員が同じ結果になりますが、固定するかどうかはチームが決めることだと、公式は書いています。--watch（ファイルの変更を見張って自動でやり直す機能）も作り直されていて、OS をまたいで安定して動くと書かれています。

6.0 から何が変わった？既定値とエラーになる設定

先に大事なことを書きます。主な既定値の変更も、使えなくなった設定も、6.0 で入った変更です。 公式は、7.0 は 6.0 の新しい既定値をそのまま使い、6.0 で非推奨にした設定や書き方はエラーにする、と書いています。6.0 はまだ新しいので、多くのプロジェクトは 6.0 の変更に合わせる必要がある、とも書かれています。

6.0 では、非推奨の設定は「7.0 で動かなくなる」というエラーで知らされ、"ignoreDeprecations": "6.0" を書くと黙らせられます。7.0 では、取り除かれた設定のエラーは、"ignoreDeprecations": "6.0" を書いても消えません。5.9 以前から上げる人は、6.0 に上げた時点で同じものに当たります。このあとの strict・types・rootDir の例は、6.0.3 と 7.0.2 が同じエラーを出します。

既定値が変わったもの

7.0 の記事の一覧にある、既定値が変わった設定です（全部で 8 つ。残りの 2 つは、表のあとに書きます）。

設定	7.0 の既定値	ひとこと
strict	true	厳しい型チェックの設定をまとめて有効にする設定です。より厳しい型付けを望む声が増え、新しいプロジェクトの多くが strict を使うため、と公式は書いています
module	esnext	出力するコードのモジュールの形式を決める設定です。ESM がいちばん使われる形式になったため、と公式は書いています
target	esnext の 1 つ前の安定版（いまは es2025）	出力する JavaScript の版を決める設定です。ほとんどの開発者は、古い JavaScript に変換しなくてよい環境に出しているため、と公式は書いています
noUncheckedSideEffectImports	true	副作用だけの import（import "./x" のような形）の打ち間違いを見つけるための設定です
rootDir	./	下の「rootDir が tsconfig.json のあるフォルダになった」で説明します
types	[]	下の「types が [] になった」で説明します

ほかに、libReplacement が false に、stableTypeOrdering が true に変わりました。stableTypeOrdering は、6.0 では付けると型の並び順が 7.0 と同じになるフラグでしたが、7.0 では常に有効で、切れません（あとの「手順 4」に出てきます）。ESM（ES モジュール）と CommonJS の違いは、こちらの記事で説明しています。

strict・module・target・noUncheckedSideEffectImports で動かなくなったら、前の値を tsconfig.json に書けば戻せます。たとえば、strict が false だった前の既定に頼っていたなら、"strict": false と書きます。

strict の例です。型を書いていない引数がある次の a.ts は、strict が true だとエラーになります。

function greet(name) {
  return "Hello, " + name;
}
export const msg: string = greet("TS");

$ npx tsc --noEmit a.ts
a.ts(1,16): error TS7006: Parameter 'name' implicitly has an 'any' type.

上は TypeScript 7.0.2 の出力で、6.0.3 も同じエラーを出します。5.9.3 では、エラーになりません。

新しい設定ファイルを作る tsc --init は、6.0.3 と 7.0.2 で、空行を除いて同じ tsconfig.json を作ります。"module": "nodenext"・"target": "esnext"・"types": []・"strict": true・"jsx": "react-jsx"・"verbatimModuleSyntax": true・"skipLibCheck": true などが書かれています。

つまずきやすい types と rootDir

公式は、rootDir と types の変更がいちばん「意外」だろうと書いています。簡単に直せる、とも書かれています。

types が [] になった

types は、tsconfig.json の compilerOptions に書く、コンパイルのときにグローバルに取り込む型パッケージの名前の一覧です。これまでは、node_modules/@types の中のパッケージを全部取り込んでいたので、@types/node の process や fs、@types/jest の describe や it を、import なしで使えました。

6.0 から、既定は []（何も取り込まない）になりました。何百もの型パッケージを取り込むと遅いためで、公式が見たプロジェクトの多くで、types を正しく書くだけでビルド時間が 20〜50% 改善した、と書かれています。

直し方は、使う型パッケージの名前を書くことです。たいていは "types": ["node"] です。"types": ["*"] と書くと 5.9 までの動きに戻りますが、公式は、ビルドの速さと予測のしやすさのために、名前を書くほうを勧めています。

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

たとえば、@types/node を入れたフォルダで、console.log(process.version); の 1 行だけの env.ts を、types を書いていない tsconfig.json で型チェックすると、TypeScript 7.0.2 は次のエラーを出します。@types/node は入っていますが、types に書いていないので、このエラーになります。

$ npx tsc -p .
env.ts(1,13): error TS2591: Cannot find name 'process'. Do you need to install type definitions for node? Try `npm i --save-dev @types/node` and then add 'node' to the types field in your tsconfig.

"types": ["node"] を足すと、エラーは出なくなります。同じ条件で、6.0.3 は同じエラーを出し、5.9.3 は何も出しません。

rootDir が tsconfig.json のあるフォルダになった

rootDir は、ソースのルートフォルダ（出力のフォルダ構成の基準）を決める設定です。これまでは、入力ファイルから共通のフォルダを推測していました。6.0 から、既定は tsconfig.json のあるフォルダになり、推測するのは、tsconfig.json なしでコマンドを打つときだけです。

tsconfig.json が src フォルダの外にあるなら、"rootDir": "./src" を書きます。直す前の目印は、出力が ./dist/index.js ではなく、./dist/src/index.js に書かれることです。

たとえば、次の tsconfig.json で、src/index.ts を 1 つ出力すると、TypeScript 7.0.2 は次のエラーを出し、出力は dist/src/index.js に書かれます。6.0.3 も同じエラーと同じ出力先で、5.9.3 はエラーなしで dist/index.js に書きます。

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

$ npx tsc -p .
tsconfig.json(2,24): error TS5011: The common source directory of 'tsconfig.json' is './src'. The 'rootDir' setting must be explicitly set to this or another path to adjust your output's file layout.
  Visit https://aka.ms/ts6 for migration information.

"rootDir": "./src" を足すと、エラーは出なくなり、出力は dist/index.js に書かれます。

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

エラーの最後にある https://aka.ms/ts6 は、GitHub の「6.0 Migration Guide」（Issue #62508）につながります。Issue の本文は「Placeholder」で、項目ごとの説明は、メンテナーのコメントにあります。

使えなくなった設定

7.0 の記事の一覧には、6.0 で非推奨になり、7.0 でエラーになるものが 12 項目あります。

使えなくなったもの	7.0 では
target: es5	エラーになります。いちばん古い target は ES2015 です。ES5 の出力が要るなら、TypeScript のソースを直接コンパイルするか、TypeScript の出力を後から処理する別のコンパイラを使う、と公式は書いています
downlevelIteration	エラーになります
moduleResolution: node（node10）	エラーになります。Node.js で直接動かすなら nodenext、バンドラーや Bun を使うなら bundler にします
module: amd, umd, systemjs, none	エラーになります
baseUrl	エラーになります。消して、paths の各行に前置きを足します（例は、あとの「6.0 を経由して 7 に上げる手順」にあります）
moduleResolution: classic	エラーになります
esModuleInterop と allowSyntheticDefaultImports を false にすること	エラーになります。import * as express from "express" のような書き方は、import express from "express" に直すことがあります
alwaysStrict を false にすること	常に有効です。await・static・private・public などの予約語を変数名に使っている古いコードは、名前を変えます
名前空間の宣言での module キーワード	module Foo {} ではなく namespace Foo {} と書きます。declare module "some-module" {} はそのまま使えます
import の asserts	with と書きます。import blob from "./blahb.json" with { type: "json" } のようにします
skipDefaultLibCheck のもとでの /// <reference no-default-lib />	効かなくなります（無視されます）
tsconfig.json があるフォルダで、ファイル名を渡すこと（tsc foo.ts）	エラーになります。tsconfig.json を使わずにそのファイルだけ扱うなら、--ignoreConfig を付けます（tsc --ignoreConfig foo.ts）

tsconfig.json があるフォルダで、tsc b.ts のようにファイル名を渡したときのエラーは、TypeScript 7.0.2 では次のとおりです。

$ npx tsc b.ts
error TS5112: tsconfig.json is present but will not be loaded if files are specified on commandline. Use '--ignoreConfig' to skip this error.

outFile（複数の入力を 1 つの出力にまとめる設定）について、6.0 の記事の本文は「6.0 で取り除いた」と書いていますが、同じ記事の見出しは「Deprecated（非推奨）」で、6.0.3 で使うと「非推奨で、7.0 で動かなくなる」というエラー（TS5101）になります。7.0 の記事の一覧には載っていませんが、7.0.2 ではエラーになります。いまはバンドラーの仕事です。

6.0 と 7.0.2 では、エラーの文面が違います。たとえば、6.0 で非推奨になった設定を使った、次の tsconfig.json で比べます。

{
  "compilerOptions": {
    "target": "es5",
    "module": "commonjs",
    "moduleResolution": "node",
    "baseUrl": "./",
    "noEmit": true
  }
}

TypeScript 6.0.3 は、1 件目のエラーを次のように出します。「7.0 で動かなくなる」ことと、"ignoreDeprecations": "6.0" で黙らせられることを教えてくれます。

tsconfig.json(3,15): error TS5107: Option 'target=ES5' is deprecated and will stop functioning in TypeScript 7.0. Specify compilerOption '"ignoreDeprecations": "6.0"' to silence this error.

TypeScript 7.0.2 は、次の 3 件のエラーを出します。「取り除かれたので、設定から消して」という文面です。

tsconfig.json(3,15): error TS5108: Option 'target=ES5' has been removed. Please remove it from your configuration.
tsconfig.json(5,25): error TS5108: Option 'moduleResolution=node10' has been removed. Please remove it from your configuration.
tsconfig.json(6,5): error TS5102: Option 'baseUrl' has been removed. Please remove it from your configuration.
  Use '"paths": {"*": ["./*"]}' instead.

この tsconfig.json に "ignoreDeprecations": "6.0" を足すと、6.0.3 はエラーなしで通りますが、7.0.2 は上と同じ 3 件のエラーを出します。"ignoreDeprecations": "6.0" は、6.0 の中だけで使える一時しのぎです。

そのほかの変更

公式の 7.0 の記事には、次の変更も書かれています。

• テンプレートリテラル型の推論で、絵文字などが 2 つに割れなくなりました（"😀" が 1 文字として扱われます）。UTF-16 の単位を前提にした型の工夫（文字列の長さを測る Length のような型）は、壊れることがあります
• JavaScript ファイル（JSDoc で型を書く使い方）の扱いを、TypeScript ファイルに近づけました。@enum を特別に扱わない、@class を付けても関数がコンストラクターにならない、などです。違いの一覧は、CHANGES.md にあります

6.0 を経由して 7 に上げる手順

公式は、7.0 に移りやすくするために、先に 6.0 に上げることを勧めています。6.0 は 5.9 と 7.0 の「橋渡し」で、6.0 の変更の多くは、7.0 に備えるためのものです。6.0 は安定版で、いまから導入できるはずだと、6.0 の記事に書かれています。

7.0 は、6.0 の型チェックとコマンドの動きに合わせて作られています。公式は、6.0 でエラーなく通るほとんどのコードは（stableTypeOrdering を付け、ignoreDeprecations を付けない状態で）、7.0 でも同じ結果になるはずだと書いています。

このあとのコマンドは、公式の記事に書かれているものと、macOS（Node v21.7.1・npm 10.5.0）で実行して確かめたものです。Windows と Linux では実行して確かめていません。Windows・Linux での手順の違いは、確かめた公式の資料には見当たりません（2026年10月3日時点）。

手順 1: 6.0 を入れる

いま npm install -D typescript を実行すると 7 が入るので、6 を入れるときは版を指定します。

npm install -D typescript@6

2026年10月3日時点では 6.0.3 が入り、package.json には "typescript": "^6.0.3" と書かれます。これは npm の版の指定の書き方で、公式ブログに書かれた文ではありません。

手順 2: types と rootDir を書く

6.0 に上げたとき、多くのプロジェクトが最初に直すことです。公式は、非推奨や動きの変更の中には、エラーの文面が原因を直接指さないものがあるので先に書いておく、としたうえで、多くのプロジェクトは次の少なくとも 1 つが要ると書いています。

• tsconfig.json の types を書く。たいていは "types": ["node"] です
• rootDir がこれまで推測に頼っていたなら、"rootDir": "./src" を書く

どちらも、前の節の例のとおりです。

手順 3: 非推奨のエラーを直す

6.0 に上げて、非推奨の警告が出たら、7.0 にする前に直すことを、公式は強く勧めています。"ignoreDeprecations": "6.0" を書くと、6.0 では黙らせられますが、これは 6.0 の中だけの一時しのぎです。7.0 では効きません。

baseUrl については、公式は、ほとんどの開発者に、baseUrl を消して、paths の各行に適切な前置きを足すことを勧めています。公式の例です。

- "baseUrl": "./src",
- "@app/*": ["app/*"],
+ "@app/*": ["./src/app/*"],

baseUrl と rootDir は、実験的な道具 ts5to6 で、コードベース全体を自動で直すこともできます（任意）。ファイルを書き換える道具なので、実行する前に、いまの状態を Git などで保存しておくと安心です。

npx @andrewbranch/ts5to6 --fixBaseUrl .
npx @andrewbranch/ts5to6 --fixRootDir .

ts5to6 の説明は、andrewbranch/ts5to6 にあります。ts5to6 1.1.1 で、baseUrl の例の paths は "@app/*": ["./src/app/*"] の形に直り、rootDir の例には "rootDir": "./src" が足されて、どちらも TypeScript 7.0.2 でエラーなく通りました（2026年10月3日・macOS）。

手順 4: （任意）6.0 のまま、7.0 との違いを調べる

6.0 の --stableTypeOrdering を付けると、型の並び順が 7.0 と同じになるので、6.0 と 7.0 の違いを見つけやすくなります。ただし、型チェックが最大 25% 遅くなることがあるので、常に付けておくことは勧められていません。公式は、6.0 と 7.0 の違いを調べるためのもので、長く使う機能ではないと書いています。7.0 では、常に有効で切れません。

手順 5: 7.0 を入れる

6.0 でエラーなく通ることを確かめたら、7.0 を入れます。

npm install -D typescript

2026年10月3日時点では 7.0.2 が入り、package.json には "typescript": "^7.0.2" と書かれます。

手順 6: typescript を使う道具があるときは、6.0 と 7.0 を並べる

typescript-eslint のような道具は、プロジェクトに入っている typescript を直接 import して使います。そのため、公式は、npm のエイリアス（別名をつけて入れる書き方）で、6.0 と 7.0 を並べることを勧めています。次の package.json で、7.0 の tsc と、6.0 の tsc6（と 6.0 の API）が同時に使えます。API は、プログラムからコンパイラを使う仕組みのことです。

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

@typescript/typescript6 は、tsc6 というコマンドを持つ互換パッケージで、6.0 の API をそのまま出します。7.0 の tsc と名前がぶつからないので、tsc は 7.0、ほかの道具は 6.0 に頼れます。npm install のあと、次のようになります（2026年10月3日・macOS・npm 10.5.0）。@typescript/typescript6 は 6.0.2 を入れますが、その中で動く TypeScript は 6.0.3 でした。

$ npx tsc --version
Version 7.0.2
$ npx tsc6 --version
Version 6.0.3
$ node -p "require('typescript').version"
6.0.3

公式の記事には、6.0 側だけを入れる書き方として、次のコマンドも載っていて、「こうすると tsc6 だけが残る」と書かれています。

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

一方、2026年10月3日に、npm 10.5.0（macOS）の空のフォルダでこのコマンドを実行すると、tsc6 のほかに、6.0.3 の tsc と tsserver も node_modules/.bin に入り、npx tsc --version は Version 6.0.3 と表示されました。公式の説明とは動きが違うので、この形で入れたときは、npx tsc --version で、どの版が動くかを確かめてください。

入れるときの注意: OS・CPU と Node.js

7.0.2 は、OS と CPU ごとの本体を、別のパッケージ（optionalDependencies）に分けて配っています。全部で 20 種類で、Windows は win32-x64 と win32-arm64、Mac は darwin-x64 と darwin-arm64、Linux は x64 と arm64 などです。Mac（arm64）で npm install -D typescript を実行すると、typescript と @typescript/typescript-darwin-arm64 の 2 つが入ります。tsc の入口は Node.js のスクリプトで、OS と CPU に合うパッケージの中の実行ファイルを起動します。

OS と CPU に合うパッケージが入っていないと、tsc は動かず、次のエラーを出します（Mac で npm install -D [email protected] --omit=optional として入れて再現）。

Error: Unable to resolve @typescript/typescript-darwin-arm64. Either your platform is unsupported, or you are missing the package on disk.

Node.js の版については、7.0.2 の package.json（engines）に >=16.20.0 とあります。6.0.3 は >=14.17 です。公式のブログには、Node.js の版についての説明は書かれていません（2026年10月時点）。

React・Next.js・Vite で TypeScript 7 は使える？

公式の記述があるのは、Next.js だけです（16.3 以降）。React の公式の TypeScript のページと、Vite の「Features」のページには、2026年10月3日時点で、TypeScript 7 についての記述がありません。

Next.js

Next.js は、16.3（2026年8月3日）から、next build の型チェックに TypeScript 7 を使えるようになりました。プロジェクトの typescript を 7 に上げるだけだと、Next.js の発表に書かれています。

Next.js の文書（TypeScript のページ）には、TypeScript 7 には JavaScript のコンパイラ API がまだ無いので、next build で 7 を使うにはプロジェクトに入れる、と書かれています。Next.js は既定でプロジェクトの tsc コマンドを使うので、ほかの設定は要りません。

npm install -D typescript@^7

Next.js の発表記事には、pnpm のコマンド（pnpm add -D typescript@^7）が書かれています。npm・yarn・pnpm の違いは、こちらの記事で説明しています。

この動きを決める設定は、experimental.useTypeScriptCli です（文書）。既定で有効ですが、文書には「現在は実験的な機能で、変わることがあり、本番には勧めない」と書かれています。false にして 7 を使うと、next build は止まります。

この方式のときの型チェックのエラーは、tsc の出力がそのまま出ます。Next.js 独自のコード付きのエラー表示（code frame）や、ルート・ページ・レイアウトなどについてのエラーの書き換えはしません。

Next.js には、エディタ用の TypeScript プラグインがあります。このプラグインが TypeScript 7 の言語サーバーで動くかどうかは、Next.js の文書には書かれていません（2026年10月時点）。

React

React の公式の TypeScript のページ（react.dev/learn/typescript）には、2026年10月3日時点で、TypeScript 7 についての記述がありません。エディタの機能としては、TypeScript の 7.0 の記事が、JSX（React で書く、HTML に似た書き方）のタグの連動編集と補完を足したと書いています（React の側の記述ではありません）。

Vite

Vite の文書は、Vite は .ts のファイルを JavaScript に変換するだけで、型チェックはしない、と書いています（該当のページ）。型チェックは、エディタとビルドの手順に任せる前提で、本番のビルドでは、Vite のビルドに加えて tsc --noEmit を流せます。Vite の文書にも、TypeScript 7 についての記述はありません（2026年10月3日時点）。

Vite のひな形を作る create-vite（9.2.1、2026年9月10日）の react-ts は、typescript を ~6.0.2 で入れます。ビルドのコマンドは tsc -b && vite build です。

型チェックだけの確認結果（公式の記述ではありません）

次は、その react-ts のひな形（2026年10月3日には React 19.3.0・@types/react 19.3.0・Vite 8.3.2 が入りました）で、typescript を 7.0.2 に替えて、npx tsc -b を実行した結果です。2026年10月3日、macOS・Node v21.7.1 での結果で、React や Vite の公式の記述ではありません。npm install の出力は省いています（Node v21.7.1 は Vite 8 系が求める Node の版の外なので、EBADENGINE の警告が出ました）。

$ npm install
$ npx tsc --version
Version 6.0.3
$ npx tsc -b
$ npm install -D [email protected]
$ npx tsc --version
Version 7.0.2
$ npx tsc -b

npx tsc -b は、6.0.3 でも 7.0.2 でも、何も表示せず、エラーなく終わります（終了コードは 0）。型の誤りをわざと入れると、7.0.2 はエラーを出します（src/App.tsx の最後に export const broken: number = "x"; を足した場合）。

src/App.tsx(124,14): error TS2322: Type 'string' is not assignable to type 'number'.

誤りを消すと、またエラーなく終わります。この確認は、型チェック（tsc -b）だけの結果です。vite build や、アプリを動かすところは確かめていません。React や Vite が TypeScript 7 に対応していると、公式が書いているわけではありません。

7 にまだ対応していないものは？（API・ESLint・Vue など）

上げる前に確かめたい道具を、公式の書き方に沿って並べます（2026年10月3日時点）。

使っているもの	7 について書かれていること
Next.js	16.3 から、next build の型チェックに 7 を使える
React	公式の TypeScript のページに、7 の記述なし
Vite	公式の Features のページに、7 の記述なし。型チェックは tsc などに任せる
typescript-eslint	対応する TypeScript は「4.8.4 以上 6.1.0 未満」。7 は対象外
Vue・MDX・Astro・Svelte	まだ 7 を活かせない見込み。当面は 6.0 のまま
Angular	コマンドの tsc は 7、エディタは 6.0 という組み合わせにできる

API が無い

7.0 には、API（プログラムからコンパイラを使う仕組み）がありません。7.1 で新しい（これまでと違う）API を出す見込みです。それまでは、API が要る道具（たとえば typescript-eslint）のために、6.0 と並べて使えるようにしてある、と公式は書いています（「6.0 を経由して 7 に上げる手順」の「手順 6」）。

7.0.2 の require('typescript') で取れるのは、版の情報だけです。createProgram は、6.0.3 では関数ですが、7.0.2 では undefined になります（macOS・Node v21.7.1）。

typescript-eslint

typescript-eslint（ESLint で TypeScript を扱う道具）の文書には、対応している TypeScript の範囲が「4.8.4 以上 6.1.0 未満」と書かれていて、7 は対象外です（依存する版の文書、2026年10月3日時点）。typescript-eslint 8.71.0（2026年9月28日）の peerDependencies も、"typescript": ">=4.8.4 <6.1.0" です。

typescript-eslint の側は、2026年7月8日の Issue での回答で、TypeScript 7 にはまだ API が無いので、いまは対応できない、と答えています。TypeScript 7 が API を出すまでは、できることがないとも書かれています。回答では、TypeScript 6 を使うように設定して、7.0 の記事にある「6.0 と並べる」方法を使うよう案内されています（「6.0 を経由して 7 に上げる手順」の「手順 6」）。

Vue・MDX・Astro・Svelte・Angular

公式は、Vue・MDX・Astro・Svelte などを使う流れは、まだ 7 を活かせない見込みだと書いています。Angular のテンプレートの中の型チェックも、7 を使わない見込みです。

理由は、7 がまだ安定した API を出していないためです。TypeScript を自分のコンパイラや言語サービスに組み込む道具（Volar など）は、いまは 6.0 にしか頼れません。公式は、これを一時的な問題と考えていて、解決を約束しています。

公式の勧めは、言語サーバーのプラグインが要らない場面で、7 を使うことです。Angular は、コマンドの tsc で 7（プロジェクト全体の誤りを速く見つける）、エディタは 6.0 という組み合わせにできます。Vue・MDX・Astro・Svelte などは、当面は 6.0 を使い続ける必要がある、と書かれています。言語サービスのプラグインなど、6.0 固有の機能がエディタで要る場合も、エディタは 6.0、コマンドのビルドは 7.0 という分け方ができます。

VS Code で TypeScript 7 を使うには？

エディタのエラー表示や補完を支える言語サーバーも、7 で作り直されました。新しい土台は LSP（Language Server Protocol）で、複数のスレッドで同時の要求に答えられます。どのエディタでも使えるはず、と公式は書いています。7 の言語サーバーは、VS Code の TypeScript 拡張が使っていた独自の TSServer の方式ではなく、標準の LSP を使います。そのため、VS Code の拡張に固有だった動きには、変わったものがあるかもしれない、と公式は書いています。

VS Code では、7 用の拡張機能を入れます。Marketplace での名前は「TypeScript 7」（ID は TypeScriptTeam.native-preview、発行は Microsoft）です。2026年10月3日時点の版は 1.0.1（2026年9月30日更新）で、TypeScript 7.0.2 を同梱しています。ベータや RC の記事では、同じ拡張機能を「TypeScript Native Preview」と呼んでいました。

有効にする方法は、公式の資料で言い方が 2 つあります。どちらも公式の説明です。この記事では、VS Code の画面は確かめていません。

• 7.0 の記事（2026年7月8日）: 拡張機能を入れると、自動で既定の動きになります。コマンドパレットの「Disable TypeScript 7 Language Server」と「Enable TypeScript 7 Language Server」で、いつでも切り替えられます
• Marketplace の説明（2026年10月3日時点）: コマンド「TypeScript: Enable TypeScript 7」を実行するか、設定に "js/ts.experimental.useTsgo": true を書いて有効にします

7.0 の記事は、「数週間のうちに、VS Code 本体にも TypeScript 7 の対応が入る」と書いていました。本体に入ったという告知は、確かめた公式の資料（VS Code 1.131〜1.141 の告知など）には見当たりません（2026年10月3日時点）。一方、VS Code 1.130（2026年7月22日）の告知には、VS Code 自身のリポジトリを TypeScript 7 の正式版でコンパイルし、TypeScript 7 の拡張機能も正式版に切り替えた、と書かれています。

Visual Studio は、最新版なら、ワークスペースに応じて自動で TypeScript 7 を有効にします。何も変える必要はない、と公式は書いています。

エディタの機能は、ベータのあとに足されました。自動 import・ホバー・インレイヒント・コードレンズ・定義元へ移動・JSX のタグの連動編集と補完などが入り、ベータで足りなかった意味に基づく色分け・「sort imports」・「remove unused imports」も入った、と公式は書いています。公式のデータでは、7.0 の新しい言語サーバーは、6.0 と比べて、失敗するコマンドを 80% 以上、サーバーが落ちる回数を 60% 以上減らしました。

よくある質問

TypeScript 7 はいつ出た？もう使える？

正式版は、公式ブログの日付で2026年7月8日（日本時間では7月9日）に出ていて、npm の版は 7.0.2 です。公式は「本番で使える」と書いています。ただし、typescript-eslint のように、7 にまだ対応していない道具もあります。次の版の 7.1 は、ベータが2026年10月6日、RC が11月10日、正式版が11月24日の予定です（2026年10月3日時点の公式の計画）。

typescript-eslint は TypeScript 7 で使える？

2026年10月3日時点では、対応していません。typescript-eslint の文書に書かれている対応範囲は「4.8.4 以上 6.1.0 未満」で、7 は含まれません。TypeScript 7 にはまだ API が無いためです。typescript-eslint の側は、TypeScript 6 を使うように設定して、6.0 と 7.0 を並べる方法を使うよう案内しています（「6.0 を経由して 7 に上げる手順」の「手順 6」）。

tsgo と tsc の違いは？

tsgo は、7.0 より前のプレビューやベータのときに、新しいコンパイラを動かすためのコマンドの名前でした。7.0 RC からは、コマンドの名前は tsc です。入れ方は、時期によって次のように違いました。

• プレビュー: @typescript/native-preview というパッケージで配られ、コマンドは tsgo
• ベータ: npm install -D @typescript/native-preview@beta、コマンドは tsgo
• RC: npm install -D typescript@rc、コマンドは tsc
• 正式版: npm install -D typescript、コマンドは tsc

なお、npm の beta の印は、2026年10月3日時点で 6.0.0-beta を指しているので、typescript@beta では 7 は入りません。

なぜ Go で作り直したの？Rust ではないの？

正確には、作り直し（書き直し）ではなく、移植です。公式の FAQ（Why Go?）は、いちばん大事なのは、意味でもコードの構造でも、新しいコードを元のコードとできるだけ同じに保つことだと答えています。慣用的な Go（Go らしい書き方）は、元の TypeScript のコードの書き方によく似ていて、移植がしやすかったそうです。

書き直しではなく移植を選んだ理由は、互換性です。別の FAQ には、新しい TypeScript が役に立つには、書き方や設定だけでなく、あらゆる点で今の TypeScript とそろっている必要がある、と書かれています。

公式は、一から書き直すなら多くの言語が合っていたが、この状況に固有の条件を合わせて見ると Go がいちばんよかった、と書いています。ほかの言語より優れているという言い方はしていません。Why Go? の FAQ の回答の本文には、Rust という名前は出てきません。

自分の TypeScript のコードが Go のコードに変わるの？

変わりません。公式の FAQ は、変わったのは TypeScript 自身を作っている言語で、TypeScript のファイルを Go やほかのネイティブのコードに変換する道具ではない、と答えています。

まとめ

• TypeScript 7 は、TypeScript のコンパイラを Go に移植した版です。正式版は2026年7月8日に出て、npm の版は 7.0.2 です（7.0.0 や 7.0.1 という正式版はありません）
• 公式の言い方は、フルビルドが「たいてい 8〜12 倍」速くなる、です。表には 7.7 倍の行もあります。測ったマシンの性能は、公式の記事に書かれていません
• 主な既定値の変更も、使えなくなった設定も、6.0 で入った変更です。公式は、先に 6.0 に上げることを勧めています。つまずきやすいのは types と rootDir です
• 手順は、6.0 を入れる、types と rootDir を書く、非推奨のエラーを直す、7.0 を入れる、の順です。typescript を import して使う道具があるときは、6.0 と 7.0 を並べます
• Next.js は 16.3 から、next build の型チェックに 7 を使えます。React と Vite には、公式の記述がありません。typescript-eslint は 7 に対応していなくて、Vue・MDX・Astro・Svelte は当面 6.0 のままです
• 7.1 は、2026年10月6日にベータが出る予定です（2026年10月3日時点の計画）。版が動く話なので、使う前に、公式の最新の発表も確かめてください

参考資料

• Announcing TypeScript 7.0（公式ブログ、2026年7月8日）
• Announcing TypeScript 6.0（公式ブログ）
• Progress on TypeScript 7 – December 2025（公式ブログ）
• TypeScript 7.1 Iteration Plan（GitHub の Issue）
• 6.0 Migration Guide（GitHub の Issue）
• microsoft/typescript-go（移植の作業場所。2026年10月3日時点で archived）
• Why Go?（typescript-go の FAQ）
• 移植を選んだ理由（typescript-go の FAQ）
• 自分のコードが Go になるか（typescript-go の FAQ）
• CHANGES.md（JavaScript ファイルの扱いの違いの一覧）
• ts5to6（baseUrl と rootDir を直す道具）
• Next.js 16.3 の発表
• Next.js の文書: TypeScript 7 を使う
• Next.js の文書: useTypeScriptCli
• Vite の文書: Features（TypeScript の扱い）
• React の文書: TypeScript を使う
• create-vite 9.2.1 の react-ts ひな形の package.json
• typescript-eslint の文書: 対応している TypeScript の版
• typescript-eslint の Issue #12518（TypeScript 7 への対応について）
• TypeScript 7 の VS Code 拡張機能（Marketplace）
• VS Code 1.130 の更新内容

※この記事は、公式の資料をもとに AI（Claude）で下書きし、2026年10月3日時点の公式の資料と照らして確かめてから公開しています。誤りに気づいたらお問い合わせからお知らせください。