TypeScript 7 ベータ完全ガイド：tsgoのインストールから移行判断まで
くろこちゃん
- TypeScript 7とは何か——Goへの移植と「10倍」の根拠
- なぜGoが選ばれたか
- ベータの現在の状態
- ベンチマーク：数値で確認する実際の差分
- コードベース別ビルド時間比較
- 数値を読む際の前提
- tsgoのインストールと基本コマンド
- インストール
- バージョン確認とビルド
- tsconfig.jsonの生成
- 並列オプション
- Breaking Changes：tsconfig.jsonの変更点
- デフォルト値の変更
- 削除・エラーになるオプション
- エコシステム互換性の現状
- 対応状況の整理
- 「並列インストールが必要」の意味
- ハマりどころ集：先に把握しておくべき7つの落とし穴
- あなたのプロジェクトは今すぐ移行すべきか？
- 段階的移行の公式推奨手順
- FAQ
- まとめ：今すぐ着手すべき3つのアクション
- お気軽にご相談ください
- 参考情報
TypeScript 7.0（コードネーム：Project Corsa）は、2026年4月21日にMicrosoftがベータリリースした、Go言語で書き直されたTypeScriptコンパイラである。npmパッケージ名は@typescript/native-preview。型チェック速度はTypeScript 6.0比で約10倍、メモリ使用量は約3分の1に削減される。コマンドはtscからtsgoへ変わり、tsconfig.jsonのデフォルト値も複数変更されている。
この記事では、ベンチマーク数値の読み方、tsgoのインストールと基本コマンド、Breaking Changes対応、エコシステム互換性の現状、移行判断フローチャートを順に解説する。
TypeScript 7とは何か——Goへの移植と「10倍」の根拠
なぜGoが選ばれたか
TypeScript 7は、既存のJavaScript実装を捨て、Go言語でゼロから書き直したコンパイラである。TypeScript 6.0は「最後のJavaScriptベースリリース」として2026年3月にリリースされ、7.0でアーキテクチャが刷新された。
MicrosoftのコアデベロッパーRyan CavanaughがGoを選んだ理由として公式に説明しているのは以下の3点だ。
- TypeScriptのコードベース構造とGoの型システムの相性が良く、約1年でポートできた
- RustはTypeScriptコードを実質的にゼロから書き直す必要があり、数年のコストがかかる
- esbuildがGoで10〜100倍の高速化を実証済みという先行事例があった
最初の技術発表は2025年3月11日、Anders Hejlsbergによる「A 10x Faster TypeScript」である。Go版の内部コードネームは「Corsa」、JavaScript版の旧コードネームは「Strada」。
ベータの現在の状態
公式は「本番利用可能なレベル」と明言している。ただし、TypeScript Compiler APIを使うプログラマティックなインターフェイスはTypeScript 7.1以降まで未対応である。この点は後述のエコシステム互換性と移行判断で直接影響する。
ベンチマーク：数値で確認する実際の差分
以下の数値はMicrosoft DevBlog（2025年3月）が公開したデータである。自社環境での独立した第三者検証ではない点に留意すること。
コードベース別ビルド時間比較
| コードベース | 規模 | TypeScript 6.0 | tsgo | 改善倍率 |
|---|---|---|---|---|
| VS Code | 1.5M LOC | 77.8秒 | 7.5秒 | 10.4x |
| Playwright | 356K LOC | 11.1秒 | 1.1秒 | 10.1x |
| TypeORM | 270K LOC | 17.5秒 | 1.3秒 | 13.5x |
| date-fns | 104K LOC | 6.5秒 | 0.7秒 | 9.5x |
数値を読む際の前提
これらはMicrosoftの自社計測である。コードベースの規模・複雑さ・型アノテーション密度によって倍率は変動する。自プロジェクトで先に実測値を取ってから意思決定することが望ましい。
tsgoのインストールと基本コマンド
インストール
tsgoのインストールはnpmコマンド2行で完了する。@typescript/native-previewがtsgo本体、typescriptはtsconfig生成など一部機能のフォールバックとして引き続き必要になる。
npm install -D @typescript/native-preview@beta
npm install -D typescript正式リリース時にtypescriptパッケージへ統合される予定だ。
バージョン確認とビルド
# バージョン確認
npx tsgo -v
# ビルド（tsconfig.jsonを参照）
npx tsgo -p .
# 型チェックのみ（JS出力なし）
npx tsgo -p . --noEmit
# プロジェクト参照ビルド
npx tsgo -btsconfig.jsonの生成
tsgoはtsconfig.jsonの自動生成コマンドを持たない。既存のtscで生成する。
npx tsc --initnpx tsgo --initというコマンドは存在しない。初期設定でここに詰まるケースが多いため注意すること。
並列オプション
# 型チェック並列ワーカー数（デフォルト4推奨）
npx tsgo -p . --checkers 4
# プロジェクト参照ビルダー並列数
npx tsgo -b --builders 4
# シングルスレッド強制（デバッグ用途）
npx tsgo -p . --singleThreadedモノレポで--checkers 8以上にしても効果が逓減する傾向がある。デフォルトの4がスイートスポットとして推奨されている。
Breaking Changes：tsconfig.jsonの変更点
デフォルト値の変更
TypeScript 7.0はtsconfig.jsonの複数オプションのデフォルト値を変更した。明示的に設定していない場合、既存プロジェクトの動作が変わる。
| オプション | TypeScript 6.x のデフォルト | TypeScript 7.0 のデフォルト |
|---|---|---|
strict | false | true |
module | commonjs | esnext |
noUncheckedSideEffectImports | false | true |
types | ["*"]（全型定義を自動含む） | []（明示的指定が必要） |
特にstrict: trueとmodule: esnextのデフォルト化は既存コードへの影響が広い。typesのデフォルト変更により、@types/nodeなどを明示的にtsconfig.jsonへ追記しないと型解決されなくなる。
削除・エラーになるオプション
以下のオプションはTypeScript 7.0で廃止され、使用するとエラーになる。
| 廃止オプション | 移行先・代替 |
|---|---|
target: es5 | ES2015以上を指定する |
downlevelIteration | targetを上げれば不要 |
moduleResolution: node（node10含む） | bundlerまたはnode16/nodenextを使用 |
module: amd, umd, systemjs, none | esnextまたはcommonjsへ |
baseUrl | pathsのみを使用する |
esModuleInterop: false | 削除してtrueに統一 |
allowSyntheticDefaultImports: false | 削除してtrueに統一 |
TypeScript 7との互換性の水準として、Microsoftの進捗報告（2025年12月）では、約20,000のコンパイラテストケースのうちTypeScript 6.0でエラーを出すのは約6,000件で、そのうち74件を除いてTypeScript 7も同じエラーを再現すると報告されている。
残る74件はいずれも実装途中の機能か意図的な仕様変更に起因するもので、Microsoftは「今日からTypeScript 7で型チェックを行って問題ない」と明言している。
エコシステム互換性の現状
対応状況の整理
| 状態 | ツール |
|---|---|
| 対応済み | Vitest, Biome v2, esbuild, Prisma Client, babel-plugin-transform-typescript |
| 並列インストールが必要（注意） | ts-jest, ts-loader, tsup（--dtsフラグ時）, TypeDoc, Storybook |
| 現時点では動作不可 | typescript-eslint（言語サービス初期化失敗）, ts-morph（Strada API廃止） |
「並列インストールが必要」の意味
ts-jestやtsupはTypeScript Compiler APIに依存する部分があり、tsgoの完全なAPIが確定するTypeScript 7.1まで安定しない。現在はnode_modules内のtypescript（v6系）を参照させたまま動作させるのが正しい運用だ。ts-jestのtypescriptオプションを@typescript/native-previewへ向けることは現時点で禁止と考えること。
typescript-eslintはLanguage Service初期化段階で失敗する。これはTypeScript 7.1以降のプログラマティックAPI安定化待ちであり、現在解消する方法はない。
ハマりどころ集：先に把握しておくべき7つの落とし穴
- プログラマティックAPIが未安定：TypeScript Compiler APIを直接使うツール（typescript-eslint、カスタムトランスフォーマー、ts-patch）はTypeScript 7.1リリース待ちである。現時点で無理に対応しようとすれば、ツールチェーン全体が不安定になる。
--outFile（アウトファイル）が動作しない：単一出力ファイルへのバンドルオプションは現時点で機能しない。esbuildやtsupのバンドラー側でまとめること。tsconfig.json生成コマンドがない：npx tsgo --initは存在しない。npx tsc --initで生成してから使うこと。これを知らないと初期設定で詰まる。- ts-jestの設定ミス：ts-jestの
typescriptオプションを@typescript/native-previewに向けてはならない。node_modules/typescriptにv6を残し、そちらを参照させること。 - VSCodeの言語機能が未完成：Quick Fix（Ctrl+.）が動作しない、Find All Referencesのクロスファイル参照が不完全、ファイルリネーム時のimport自動更新が不安定という3点は現時点でのVSCode拡張の既知の問題だ。コーディング体験は7.1以降に改善する見込みである。
- モノレポのワーカー数は4が上限の目安：
--checkers 8以上に増やしても速度向上が逓減する。デフォルトの4を基準に実測してから調整すること。 typesのデフォルト変更による型解決の失敗：@types/nodeなど暗黙的に使っていた型定義が突然解決されなくなる。tsconfig.jsonのtypesフィールドに必要なものを明示的に列挙すること。
あなたのプロジェクトは今すぐ移行すべきか？
正直に言う。TypeScript 7ベータの10倍の高速化というのは、ビルド待ちの時間コストが高いプロジェクトにとって無視できない数値だ。しかし、現時点でのtsgoには対応待ちの空白地帯が確実に存在する。移行判断は「プロジェクトがその空白地帯に入るかどうか」の一点で決まる。
以下のフローで確認する。
ステップ1: TypeScript Compiler APIを直接使うツールを使っているか？
→ typescript-eslint / ts-morph / カスタムトランスフォーマー / ts-patch
→ YES → ts-morphのみに強依存している場合：移行を見送る（Strada API廃止により動作不可）
→ typescript-eslintのみ：TypeScript 7.1リリース（2026年後半以降と予測される）まで待つ
→ NO → ステップ2へ
ステップ2: プロジェクトのコードベースは40万行以上か？
→ YES → 今すぐtsgoをCIに並行追加して効果を実測する価値がある
→ NO → ステップ3へ
ステップ3: 現在のビルド・型チェック時間がCIのボトルネックになっているか？
→ YES → --noEmitでの型チェックのみ並行CIジョブとして追加する（非ブロッキング）
→ NO → 正式リリース（2026年6〜7月）まで待ってから一括移行を検討する段階的移行の公式推奨手順
Microsoftが推奨するTypeScript 7への移行ステップは以下の順序だ。
- TypeScript 6.0への移行を完了させる（非推奨オプションをすべて修正する）
- TypeScript 6.0と7.0ベータを共存インストールして並行検証する
npm install -D typescript@npm:@typescript/typescript6- CIに
tsgo --noEmitを非ブロッキングで追加し、エラーを観察する - エコシステムの各ツールの対応状況を確認してから完全移行する
FAQ
Q1. @typescript/native-previewとtypescriptは両方インストールが必要ですか？
両方インストールすることが推奨される。tsgoコマンドは@typescript/native-previewが提供するが、tsconfig.jsonの初期生成（tsc --init）や、ts-jestなどのCompiler API依存ツールはtypescript（v6系）を参照する必要があるためだ。正式リリース後はtypescriptパッケージに統合される。
Q2. TypeScript 7ベータを本番CIに使っても安全ですか？
型チェック（--noEmit）のみを非ブロッキングジョブとして使うなら問題ない。公式も「本番利用可能なレベル」と明言している。ただし、JSの出力ビルドにtsgoを使う場合は、--outFileが未対応な点と、エコシステムの互換性を事前に確認すること。
Q3. typescript-eslintはいつ使えるようになりますか？
TypeScript 7.1以降、プログラマティックAPIが安定化した時点で対応される見込みだ。正式リリース予定は2026年6〜7月頃であり、7.1はその後になると予測される。現時点での回避策はない。
Q4. strict: trueがデフォルト化された場合、既存コードへの影響を最小化する方法は？
tsconfig.jsonに明示的に"strict": falseを追加することで旧来の動作を維持できる。ただし、段階的にstrictを有効化することが長期的には正しい方向である。まずTypeScript 6.0環境でstrict: trueを適用してエラーを潰し、その後TypeScript 7.0に移行するのが公式推奨の手順だ。
Q5. tsgoはWindows環境でも動作しますか？
Go製のネイティブバイナリとして配布されるため、Windows・macOS・Linuxのいずれでも動作する。npmパッケージのインストール方法は各OSで同一だ。
まとめ：今すぐ着手すべき3つのアクション
TypeScript 7ベータの移行において、今日から実行できる確認事項を整理する。
- TypeScript 6.0への移行を先に完了させる——廃止オプションが残った状態では7.0への移行パスが詰まる。
moduleResolution: nodeやbaseUrlの除去を先に終わらせること。 - CIに
tsgo --noEmitを非ブロッキングで追加する——本番ビルドには手を加えず、型チェックの速度差を実測する。エラーが出れば7.0対応のための作業量が見積もれる。 - エコシステムの依存ツールを棚卸しする——typescript-eslint、ts-morph、カスタムトランスフォーマーの有無を確認し、それぞれのTypeScript 7互換性の対応状況と照合する。
——この3ステップが、TypeScript 7への移行を安全かつ最短で進める実務的な出発点だ。
お気軽にご相談ください
AIを使った業務効率化、社内ツール開発、既存プロダクトへのAI機能追加、受託開発全般——上流の企画段階から実装・運用まで、まとめてご相談いただけます。
「これってAIで解決できるの？」「どこから手をつければいい？」という入口のご相談大歓迎です。
具体的な仕様が固まる前の壁打ちフェーズからぜひお気軽にご相談ください。
参考情報
- Microsoft DevBlog「A 10x Faster TypeScript」（https://devblogs.microsoft.com/typescript/typescript-native-port/）
- TypeScript公式GitHubリポジトリ（https://github.com/microsoft/typescript）
- npm @typescript/native-preview（https://www.npmjs.com/package/@typescript/native-preview）