TypeScript 6.0とは｜5から6への移行手順とts5to6・7.0との違い【6.0.3対応】

TypeScript 6.0は、JavaScriptで書かれたコンパイラとしては最後のメジャー版です。安定版の6.0.2が2026年3月23日に公開され、6.x系は2026年4月16日の6.0.3で止まっています（2026年10月時点）。npmのlatestはすでにGo製の7.0.2です。この記事では、5.9から6.0へ上げたときに何が壊れるかを、同じコードを5.9.3・6.0.3・7.0.2で型チェックした結果で示し、ts5to6を使った移行手順と、typescript-eslintやAngularのように7.0をまだ受け付けないツールがある構成で6.0をどう残すかを整理します。

まとめ

• 6.0は5.9と7.0をつなぐ移行用のリリースです。strict・types・rootDir・targetなどの既定値が変わり、baseUrlやtarget: es5などが非推奨エラーになります。
• src配下にソースを置いてoutDirを指定し、5.9で通っていたプロジェクトを6.0.3に上げると、最初はTS5011（rootDir）だけが出て、それを直すとTS2591（types）・TS7006（strict）・TS2882（CSSのimport）が続けて出ます。
• ts5to6はrootDirとbaseUrlの2つだけを書き換えるツールで、2つのフラグは同時に指定できません。typesとstrictは手で直します。
• 6.0でエラーなしに通るコードは、stableTypeOrderingを有効にしignoreDeprecationsを外した状態なら、7.0でもほぼ同じ結果になると公式が説明しています。
• typescript-eslint 8.71.2とAngular 22.2.3はpeerDependenciesで6.0までしか受け付けず、7.0.2と一緒に入れるとnpmがERESOLVEで止まります。Vue・Svelte・Astro・MDXの言語サーバーも6.0が必要です。7.0を使うなら、@typescript/typescript6のエイリアスで6.0を併置します。
• 6.xに公式のサポート期限は示されていません。

TypeScript 6.0のリリース履歴と位置づけ

6.0のベータからRC、安定版、そして7.0の安定版までの日付は、npmの公開記録で次のとおりです（日時はUTC）。

6.0には「6.0.0」「6.0.1」という安定版がありません。0と1はベータとRCに使われ、最初の安定版は6.0.2です。npm install -D typescript@6で入るのは6.0.3になります。npmに6.1は公開されておらず、nextタグで毎日公開されている次の版は7.1.0の開発版です（2026年10月18日時点で7.1.0-dev.20261018.1）。

公式の6.0発表は、6.0を「現在のJavaScriptのコードベースに基づく最後のリリース」とし、5.9と7.0の橋渡しと位置づけています。変更の大半は7.0に合わせるためのもので、コンパイラAPIは5.9と互換のままです。6.0の中身は、新機能よりも「7.0で消える設定を先にエラーにする」ことに重心があります。

5.9から6.0で変わる既定値と、上げた直後に出るエラー

6.0は、tsconfigに書いていない項目の既定値を一度に変えました。

5.9.3で通るプロジェクトを6.0.3にかけた結果

CSSの副作用import・型注釈のない引数・processの参照を含む小さなプロジェクトを、rootDirとtypesとstrictを書いていないtsconfigで型チェックしました（Node.js v26.5.0・macOS・@types/node 24.19.2・TypeScript 5.9.3／6.0.3／7.0.2）。

// tsconfig.json（移行前）
{
  "compilerOptions": {
    "outDir": "dist",
    "target": "es2020",
    "module": "commonjs",
    "esModuleInterop": true,
    "skipLibCheck": true
  },
  "include": ["src"]
}

// src/index.ts（同じ階層に styles.css を置く）
import "./styles.css";
export function greet(name) {
  return `Hello, ${name} (${process.env.USER})`;
}

5.9.3ではエラー0件でdist/index.jsが出力されます。6.0.3では次のように段階的にエラーが出ました。

$ npx tsc -p .    # 6.0.3・1回目
tsconfig.json(3,5): 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" を足した2回目
src/index.ts(1,8): error TS2882: Cannot find module or type declarations for side-effect import of './styles.css'.
src/index.ts(2,23): error TS7006: Parameter 'name' implicitly has an 'any' type.
src/index.ts(3,29): 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.

1回目はTS5011しか表示されず、設定のエラーがある間はソースの型エラーが出ませんでした。1件直したら終わりと考えず、エラー0件になるまで繰り返し実行します。rootDirを直さないまま出力すると、ファイルはdist/index.jsではなくdist/src/index.jsに書き出されました。7.0.2でもエラー番号と順序は同じです。

types既定値[]とTS2591の直し方

@types/nodeをインストールしていても、6.0では既定でグローバル型として自動読み込みされません。typesはこの自動読み込みを制御する設定で、importなどによる型定義の読み込みまで禁止するものではありません。"types": ["node"]を足すとTS2591は消えます。Jestを使うなら"jest"も並べます。公式リリースノートは、typesを適切に設定しただけでビルド時間が20〜50%短くなったプロジェクトが多いと書いています。["*"]で5.9の自動列挙の挙動に戻せますが、不要な型パッケージの読み込みを減らす効果は得られません。20〜50%という短縮幅は公式が調べたプロジェクトの結果で、すべての構成に当てはまる保証はありません。

strict既定trueで増えるTS7006への対処

strictを書いていなかったプロジェクトは、6.0でnoImplicitAnyなどが一斉に有効になります。先の例では、"strict": falseを明示すると6.0.3・7.0.2ともTS7006が消え、TS2882とTS2591は残りました。エラー件数が多いプロジェクトでは、いったんfalseを明示して6.0へ上げ、strictの対応は別のプルリクエストに分けるほうが差分を追いやすくなります。

CSSの副作用importで出るTS2882は、declare module "*.css";を書いた.d.tsを置くと消えます。TS2882とTS5011の詳しい扱いはtsconfigのbaseUrl非推奨（TS5101）の直し方の記事にまとめています。

6.0で非推奨になった設定・構文とエラー番号

6.0の非推奨は警告ではなくエラーとして出るため、CIの型チェックは失敗します。"ignoreDeprecations": "6.0"で6.0の間だけ抑止できますが、7.0ではこの指定があっても止まります。抑止の効く範囲はbaseUrl非推奨とignoreDeprecationsの記事で扱っています。

下の4行は設定ではなく書き方・呼び出し方の変更です。import data from "./d.json" assert { type: "json" }は6.0.3・7.0.2ともTS2880: Import assertions have been replaced by import attributes. Use 'with' instead of 'assert'.になりました。TS1540はignoreDeprecationsを付けても消えません。

見落としやすいのがTS5112です。5.9までは、tsconfig.jsonのあるディレクトリでtsc src/index.tsのようにファイルを指定すると、tsconfigが黙って無視されていました。6.0ではこれがエラーになり、tsconfigを無視したいときは--ignoreConfigを付けます。lint-stagedなどでファイルを渡してtscを呼んでいるスクリプトは、ここで止まります。

逆に、エラーが出ないまま挙動が変わるのがno-default-libディレクティブです。リリースノートは「6.0ではサポートしない」とし、代わりに--noLibか--libReplacementを使うよう案内しています。この1行を先頭に書いたファイルは、5.9.3では既定のlibを読まずにTS2318: Cannot find global type 'Array'.などを出しましたが、6.0.3と7.0.2ではエラー0件で、既定のlibが読み込まれました。独自のlibで標準の型を差し替えていたプロジェクトは、型チェックが通ったまま別の型定義で検査されることになるため、grep -r "no-default-lib"で残っていないかを確かめます。

TypeScript 5から6への移行手順

5.9から6.0.3へ上げる作業は、次の順に進めると差分が小さく保てます。最初にtsconfigを整え、最後に7.0との差を確認します。

手順1：5.9の既定値に依存するtsconfig項目の明示

既定値に任せていたstrict・target・moduleを、5.9で動いていた値のまま明示します。targetをes5に頼っていた場合は明示してもTS5107になるため、es2015以上へ上げるか、ダウンレベル変換をBabelやSWCなどの外部ツールに任せます。この段階ではまだ5.9のままで構いません。従来の実効値を明示するだけなら挙動は変わりません。ただし、es5からes2015以上へのtarget変更や外部変換ツールの導入は別の変更なので、出力と実行環境への影響を確認します。

手順2：ts5to6によるrootDirとbaseUrlの移行

公式リリースノートが実験的なツールとして紹介している@andrewbranch/ts5to6（2026年10月時点で1.1.1。2025年10月7日の公開から更新はありません）は、rootDirを「5.9が推論していたはずの値」で書き足す機能と、baseUrlを消してpathsを書き直す機能の2つを持ちます。

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

2つのフラグを1回で渡すとCannot use --fixRootDir and --fixBaseUrl togetherで止まり、ファイルは書き換えられません。1つずつ実行します。先のプロジェクトに--fixRootDirをかけると"rootDir": "./src"が追加され、TS5011は消えました。types・strict・CSSのimportには触れないので、残りの3件は手で直します。--fixBaseUrlの判定の挙動はbaseUrlからpathsへの移行手順で解説しています。

手順3：typesの列挙と6.0.3の型チェックエラー解消

6.0.3をインストールし、typesに必要な型パッケージを並べます。先のプロジェクトは、次の設定に加えてdeclare module "*.css";だけを書いたsrc/css.d.tsを置いた状態で、6.0.3・7.0.2ともエラー0件になりました。tsconfigだけではTS2882が残ります。

{
  "compilerOptions": {
    "outDir": "dist",
    "rootDir": "./src",
    "types": ["node"],
    "strict": false,
    "target": "es2020",
    "module": "commonjs",
    "esModuleInterop": true,
    "skipLibCheck": true
  },
  "include": ["src"]
}

非推奨エラーがすぐに直せない場合だけ"ignoreDeprecations": "6.0"を足します。7.0では効かないので、外す期限を課題として残しておきます。

手順4：stableTypeOrderingによる7.0との型順序の比較

型チェッカーが内部で型に振る番号の付け方が6.0と7.0で違い、宣言ファイルに出るユニオン型の順序がずれることがあります。--stableTypeOrderingは6.0の並び順を7.0に揃えるフラグです。公式のサンプルを3つの版で出力しました。

// order.ts
const x = 500;
export function foo(condition: boolean) {
  return condition ? 100 : 500;
}

// 生成された order.d.ts（--declaration --target es2022 で出力）
// 5.9.3                          : foo(condition: boolean): 500 | 100;
// 6.0.3                          : foo(condition: boolean): 500 | 100;
// 6.0.3 --stableTypeOrdering     : foo(condition: boolean): 100 | 500;
// 7.0.2                          : foo(condition: boolean): 100 | 500;

並び順は読み込む型の順序にも左右され、6.0.3を既定のtarget（es2025）のまま動かすとフラグなしでも100 | 500になりました。比べるときは6.0と7.0に同じtsconfigを渡します。宣言ファイルをコミットしている、またはスナップショットで差分を比較しているプロジェクトは、このフラグを付けた6.0と7.0で出力を比べると、並び順だけのノイズを除けます。公式は型チェックが最大25%遅くなることがあるとし、「6.0と7.0の差を診断するためのもので、常用するものではない」と明記しています。CIには常時入れません。フラグを付けて型エラーが出た場合は、型引数や変数の型注釈を明示すると解消することが多いとされています。

TypeScript 6.0の新機能と5.9.3との型チェック結果の差

thisを使わないメソッド構文の型推論

ジェネリック関数に渡すオブジェクトで、メソッド構文の順序によって推論が失敗する問題が直りました。

declare function callIt<T>(obj: {
  produce: (x: number) => T;
  consume: (y: T) => void;
}): void;

callIt({
  consume(y) { return y.toFixed(); },
  produce(x: number) { return x * 2; },
});
// 5.9.3（strict有効）: error TS18046: 'y' is of type 'unknown'.
// 6.0.3: エラーなし

メソッド構文の関数は暗黙のthisを持つため、5.9までは型引数の推論から後回しにされていました。6.0はthisを参照していない関数を後回しの対象から外します。アロー関数への書き換えや型注釈で回避していた箇所は、6.0では不要になります。

#/で始まるサブパスimport

package.jsonのimportsフィールドで、#root/のような名前を挟まずに#/だけを接頭辞にできるようになりました。moduleResolutionがnodenextかbundlerのときに使えます。

// package.json
{ "type": "module", "imports": { "#/*": "./dist/*" } }

// tsconfig.json
{ "compilerOptions": { "rootDir": "./src", "outDir": "dist", "module": "nodenext", "types": [] }, "include": ["src"] }

// src/index.ts
import { util } from "#/lib/util.js";
// 5.9.3: error TS2307: Cannot find module '#/lib/util.js' or its corresponding type declarations.
// 6.0.3: エラーなし（tsc後に node dist/index.js で実行できる）

pathsの@/*と違い、Node.js自身が解決する仕組みなので、コンパイル後のJavaScriptを別名の変換なしで実行できます。そのためimportsの参照先は出力先のdistに向けます。TypeScriptはrootDirとoutDirの対応からsrc側の.tsをたどって型を解決します。参照先を./src/*にすると、6.0.3の型チェックは通りますが、実行時にERR_MODULE_NOT_FOUNDになりました。ただしNode.jsが#/で始まる指定を受け付けるのは25.4.0以降と24.14.0以降で、22.xと20.xの変更履歴にはこの変更が載っていません。手元のNode.js v26.5.0では、同じ構成のJavaScriptがそのまま動きました。ESMとCommonJSの解決規則の違いはNative ESMとCommonJSの整理記事を参照してください。

es2025・Temporal・Mapのupsertに必要なlib指定

新しい標準APIの型は、入っているlibが違います。既定のtargetであるes2025に含まれるのはRegExp.escapeまでで、TemporalとMapのgetOrInsertはesnextを指定しないと見えません。

型があっても実行環境に実装が無ければ動きません。Node.js 26の公式ビルドではTemporalが既定で有効ですが、Temporalを無効にしてビルドされたNode.js v26.5.0（Homebrew版）では、型チェックが通ったコードが実行時にReferenceError: Temporal is not definedで落ちました。esnextのAPIを使うときは、動かす先のブラウザやNode.jsのバージョンで実装済みかを先に確認します。

dom.iterableのdomへの統合と5.9.3のTS2488

lib.dom.iterable.d.tsとlib.dom.asynciterable.d.tsの中身がlib.dom.d.tsに取り込まれ、"lib": ["es2020", "dom"]のようにdom.iterableを並べなくても、document.querySelectorAll()の結果をfor...ofで回せます。5.9.3では同じ設定でTS2488になりました。6.0.3のlib.dom.iterable.d.tsはライセンス表記と「互換性のために残している」という注記だけのファイルで、既存のlib指定に残っていても問題ありません。

bundlerとcommonjsの併用と5.9.3のTS5095

moduleResolution: bundlerをmodule: commonjsと組み合わせられるようになった変更は、非推奨になったnode10からの移行先として用意されたものです。5.9.3では同じ組み合わせがTS5095: Option 'bundler' can only be used when 'module' is set to 'preserve' or to 'es2015' or later.で止まり、6.0.3と7.0.2ではエラー0件でした。

6.0と7.0の違いと、6.0に留まる判断

7.0.2がlatestになった今、新規プロジェクトで7.0.2を選べるのは、使うツールがすべて7.0に対応しているか、下で説明する6.0との併用が成り立つ場合です。Vue・Svelte・Astro・MDXの言語ツールと、Angular・typescript-eslintの対応範囲を先に確かめます。

最終行は7.0の公式発表に載っている、VS Codeのコードベースでの比較値です。同じ発表ではSentryが139.8秒から15.7秒、Playwrightが12.8秒から1.47秒になっています。7.0の仕組みと移行はTypeScript 7の解説記事で扱っています。

7.0公開後も6.0を使い続ける構成

7.0はコンパイラAPIを公開していません。このため、TypeScriptを自前の言語サービスに組み込むVolarなどのツールは6.0にしか依存できず、公式発表は「Vue・MDX・Astro・Svelteなどを使うプロジェクトは当面6.0を使い続ける必要がある」と書いています。Angularについては、通常のTypeScriptコードを検査するtscには7.0、エディタには6.0を使う組み合わせを勧めています。Angularのテンプレート検査やng buildまで7.0へ切り替えられるという意味ではなく、Angularコンパイラには対応範囲内のTypeScriptを残します。VS Codeでは「Disable TypeScript 7 Language Server」コマンドで6.0の言語サーバーに戻せます。

typescript-eslint・Angular・ts-jestが受け付けるTypeScriptの版

7.0へ上げられるかは、typescriptをpeerDependenciesに持つツールの指定範囲で決まります。以下は、表に記載した各パッケージの版について、2026年10月18日に確認したTypeScriptのpeerDependenciesです。

Angular 22は6.0しか受け付けないため、Angular 22へ上げる作業は、そのまま5.9から6.0への移行になります。Angular 20のままでは6.0へ上げられません。Angular側の移行はAngular 21の変更点と移行手順の記事を参照してください。vue-tscは指定の上では7.0も入りますが、Vueの言語サーバーは先に書いたとおり6.0が前提です。

指定の外にある版を入れると、npmは依存関係の解決で止まります。npm 11.17.0で7.0.2とtypescript-eslintを一緒に入れた結果です。

$ npm i -D [email protected] [email protected] eslint@9
npm error code ERESOLVE
npm error ERESOLVE unable to resolve dependency tree
npm error Found: [email protected]
npm error Could not resolve dependency:
npm error peer typescript@">=4.8.4 <6.1.0" from [email protected]

--legacy-peer-depsで無理に入れると、インストールは通りますが、型情報を使うルールを有効にしたeslintがtypescript-eslint does not support TS 7.0.と表示して終了しました。メッセージは7.0の発表の併用手順と、7.1以降の対応を追うtypescript-eslintのissue #10940を案内しています。--legacy-peer-depsや--forceは解決策になりません。ESLintの設定全般はESLintの設定とflat configの記事にまとめています。

tsc6と7.0を併用するnpmエイリアス

typescript-eslintのようにtypescriptパッケージをimportするツールだけが6.0を必要とする場合は、互換パッケージ@typescript/typescript6（パッケージの版は6.0.2で、中身は依存先のtypescript@^6＝6.0.3。実行ファイル名はtsc6）をnpmのエイリアスで入れ、型チェックは7.0で回せます。7.0の公式発表に載っている設定です。

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

この構成をtypescript-eslint 8.71.2・eslint 9と一緒に入れると、npmはエラーなしで依存関係を解決しました。npx tsc -vはVersion 7.0.2、npx tsc6 -vはVersion 6.0.3を返し、require("typescript").versionは6.0.3です。型情報を使う@typescript-eslint/no-floating-promisesも、awaitしていないPromiseを検出しました。CIの型チェックはtsc（7.0）、lintは6.0のAPIという分担になります。

この構成でも7.0側は6.0の非推奨設定を受け付けません。7.0を併用する予定があるなら、ignoreDeprecationsに頼らずtsconfigを直しておきます。コンパイラAPIに依存する自作ツールがある場合は、TypeScript Compiler APIの記事で7.0での扱いを確認してください。依存ツールの対応待ちが多い業務システムで、TypeScriptの版上げを含めて作り直す場合は、フルスクラッチ開発として相談を受けています。

6.xのサポート期限の考え方

TypeScriptには、Node.jsのLTSのような版ごとのサポート期限の公表がありません。実態としては、6.xの修正は2026年4月16日の6.0.3以降出ておらず、GitHubのrelease-6.0ブランチの最後のコミットも2026年4月15日（6.0.3への版上げ）です。6.0.3にはATA（自動型取得）のパッケージ名の検査を強化する修正が含まれていました。

周辺の目安になるのは型定義の側です。DefinitelyTypedは、公開から2年未満のTypeScriptでしか@typesパッケージをテストしないと定めています。6.0.2の公開は2026年3月なので、2028年3月ごろには新しい@typesが6.0で検証されなくなる計算です。7.0の公式発表は、今後も3〜4か月ごとに機能追加の版を出す方針を示しています。

6.0は長く留まる版ではありません。Vue・Svelte・Astroなどの対応を待つ間だけ6.0を使い、7.0の言語サービスが使えるようになったら切り替える前提で計画します。

よくある質問

TypeScript 6.0はいつリリースされましたか？

最初の安定版である6.0.2が2026年3月23日にnpmで公開されました。ベータは2026年2月11日、RCは2026年3月6日です。6.0.0と6.0.1はベータとRCに使われたため、安定版は6.0.2から始まります。6.x系の最新は2026年4月16日公開の6.0.3で、2026年10月時点で後続の修正版は出ていません。npmのlatestはGo製の7.0.2に移っています。

TypeScript 5と6の違いは何ですか？

言語の書き方はほぼ同じで、違いは既定値と非推奨です。6.0ではstrictがtrue、typesが空配列、targetがes2025に変わり、baseUrlやtarget: es5がエラーになります。新機能はメソッド構文の型推論改善や#/のサブパスimportなどで、コンパイラAPIは5.9と互換です。

ts5to6で自動的に移行できますか？

一部だけです。@andrewbranch/ts5to6が自動で書き換えるのはrootDirの追加とbaseUrlの削除（pathsの書き直し）の2つで、--fixRootDirと--fixBaseUrlは同時に指定できません。typesの列挙、strictで増える型エラー、moduleResolution: nodeの移行、CSSのimportで出るTS2882は手作業です。projectのreferencesとextendsはたどって更新します。

TypeScript 6.0のサポート期限はいつまでですか？

公式が定めたサポート期限はありません。6.xの修正版は2026年4月16日の6.0.3が最後で、それ以降のリリースはありません。目安として、DefinitelyTypedは公開から2年未満のTypeScriptでしか型定義をテストしないため、6.0は2028年3月ごろにその範囲から外れます。Vue・Svelte・Astro・MDXなど7.0が使えない構成の中継ぎとして使い、7.0の言語サービスが対応した時点で切り替えます。

TypeScript 6を飛ばして5.9から7.0へ直接上げてもよいですか？

できますが、推奨されません。7.0は6.0の既定値を引き継ぎ、6.0で非推奨にした設定をすべてエラーにします。ignoreDeprecationsによる一時回避もできないため、5.9から直接上げると既定値の変更と削除済み設定の修正を一度に抱えます。公式も、6.0で非推奨の指摘を解消してから7.0へ進むよう勧めています。6.0.3でエラー0件にしてから7.0.2を試すと、原因の切り分けが容易です。

関連記事

• tsconfigのbaseUrl非推奨（TS5101）の直し方とignoreDeprecations・TypeScript 7.0の削除エラー
• TypeScript 7とは？Go製ネイティブコンパイラtsgoで最大10倍高速化｜RC公開と移行の要点【2026年最新】
• TypeScript Compiler APIとは｜AST解析と型情報取得の手順とTypeScript 7対応
• TypeScriptのモジュールとクラスの違い｜export/importの書き分けと7.0の変更点
• TypeScriptとは？型・型推論・型注釈の書き分けとJavaScriptとの違い【2026年版】