「ビルドに 4 分かかる」「VS Code の型チェックがいつまでも回らない」——大規模 TypeScript プロジェクトでよくある相談が、2026 年に大きな転換点を迎えています。マイクロソフトが TypeScript コンパイラ（tsc）を Go 言語にフルポートした「TypeScript 7.0」ベータ版を公開し、型チェック・ビルドが約 10 倍高速になったと発表しました。
長年「ビルドの遅さ」が大規模 TypeScript の宿命とされてきた中で、tsc-go は文字通り次元を変えるアップデートです。本記事では、既存の TypeScript 6 系プロジェクト（Node / フロントエンド / モノレポ）を 7.0 へ受託で移行する際の判断軸・段階的な進め方・落とし穴を整理します。
なぜ「Go 移植」が桁違いに効くのか
TypeScript コンパイラは長らく自身も TypeScript で書かれており、Node.js プロセスで動いていました。これには 3 つのボトルネックがあります。
| ボトルネック | 6 系までの状況 | 7.0（tsc-go）での変化 |
|---|---|---|
| シングルスレッド | コア 1 つしか使えない | Go の goroutine で並列化 |
| GC の停止時間 | V8 GC で頻繁に停止 | Go ランタイムで安定 |
| 起動コスト | Node 起動 + JIT ウォームアップ | ネイティブバイナリで即時起動 |
結果、フルビルドが従来比 約 10 倍、IDE のレスポンスは体感で「待ち時間ゼロ」に近い領域へ入ります。
受託案件で「移行を提案すべき」プロジェクト像
すべてのプロジェクトを移行する必要はありません。投資回収が見える代表的な像は以下です。
- モノレポで TS ファイル数が 5,000 を超える
- CI のビルド時間が 5 分以上で、エンジニアが待ちで詰まる
- VS Code の
tsserverが頻繁にハングする - Webpack / Vite ベースで
fork-ts-checkerを併用している - エディションが TypeScript 6.0 以上で型機能の互換性が高い
逆に、TypeScript 4.x 以前で長く塩漬けにされた小規模プロジェクトは、まず 6 系まで段階アップすることを優先します。
Cloudflare Code Mode MCP でエージェントのトークン消費を 7 割削る設計パターン 2026 のような最新スタックほど、ビルドの速さがそのまま開発スループットに直結します。
アーキテクチャ：tsc-go と既存ツールの関係
7.0 移行で多くのチームが混乱するのは、「既存ビルドツールとの関係」です。tsc-go は TypeScript の型チェックとトランスパイルだけ を担当します。バンドリング・テスト・Lint との関係は次の通りです。
| ツール | 7.0 での役割 |
|---|---|
tsc --noEmit | tsc-go に置き換え（型チェック専用） |
vite / esbuild / swc | そのまま（バンドル / トランスパイル担当） |
eslint | typescript-eslint が tsc-go の型情報 API に対応中 |
vitest / jest | swc / babel 経由で利用継続可 |
tsx / ts-node | tsx が tsc-go バックエンド対応版を準備中 |
つまり「バンドル」と「型チェック」が完全に分離する流れです。受託でアドバイスする際は、この境界を最初に握ることが重要です。
移行ステップ（5 フェーズ）
実案件で安全に進める標準フェーズです。
| フェーズ | 期間 | 目的 |
|---|---|---|
| 1. 互換性スキャン | 1〜2 週間 | tsc-go —diagnose で全パッケージを試走 |
| 2. CI で並行実行 | 2〜4 週間 | 既存 tsc と並走させて差分を観測 |
| 3. 型エラー修正 | 2〜6 週間 | 厳格化された型推論に追随 |
| 4. プライマリを切替 | 1〜2 週間 | tsc-go を正、6 系を fallback に |
| 5. 6 系撤去 + ツール再設定 | 2〜3 週間 | tsserver / lint / CI を 7.0 前提へ |
特にフェーズ 3 は要注意です。tsc-go では一部の型推論がより厳密になっており、これまで暗黙に通っていたコードが弾かれます。「型修正の予算」を最初に握るかどうかで、移行の体感工数が倍以上違います。
よく踏む 5 つの落とし穴
1. プラグインベースの transformer が動かない
ttypescript / ts-patch など、AST 変換プラグインを使っている場合、7.0 のプラグイン API はベータ段階です。一旦バンドラ側（swc plugin / esbuild plugin）に逃すのが現実的です。
2. monorepo の references 構成
大規模モノレポで使われる tsconfig の references は引き続き使えますが、ビルドキャッシュの場所が変わるため CI のキャッシュ戦略を見直す必要があります。
3. CI 環境のメモリ要件
並列度が上がる分、ピークメモリは 6 系より大きくなります。CI ランナーの上限を 4GB → 8GB へ引き上げる前提で予算を組みます。
4. tsserver プラグイン互換性
VS Code 拡張（Vue / Svelte / Astro / Tailwind 等）の一部は、tsc-go 系 tsserver への対応を進行中です。先行してフロントチームを 1 部門で試す段取りが安全です。
5. 型生成系 SDK のバージョン互換
prisma / drizzle / zod など、型生成系ライブラリのうち、AST に踏み込む実装は 7.0 と組み合わせるとエラーになるバージョンがあります。移行前に SDK を最新化 しておきます。
Drizzle ORM 移行ガイド 2026 — Prisma からの乗り換え判断基準と受託開発の実装パターン で書いた SDK 選定とセットで進めると合理的です。
受託案件のスコープ別パッケージ
弊社が提案している標準パッケージです。
| パッケージ | 期間 | 単価帯 | 提供物 |
|---|---|---|---|
| 7.0 互換性アセスメント | 2〜3 週間 | 80〜180 万円 | 互換性レポート + 移行ロードマップ |
| パイロット部門 PoC | 4〜6 週間 | 200〜450 万円 | 1 リポジトリで型修正 + CI 切替 |
| 全社モノレポ移行 | 3〜6 ヶ月 | 800〜2,500 万円 | 設計・移行・教育・運用支援 |
「アセスメントだけ先に発注」 という入口がもっとも通りやすく、結果次第で本格移行に進む流れがスムーズです。
まとめ — 「ビルドの遅さ」を経営課題として扱う時代
TypeScript 7.0 は、これまで「開発者の感覚的な不満」だったビルドの遅さを、定量的に解消できるところまで持ち込みました。10 倍速の意味は単純で、エンジニア 10 人のチームなら、待ち時間だけで毎月数百時間が浮きます。
弊社では、TypeScript 7.0 のアセスメント、モノレポ移行、tsserver / Lint / CI の再設定、SDK 整理までをワンストップで提供しています。「ビルドが遅くてリリースが回らない」「巨大モノレポを解きほぐしたい」というご相談は、お問い合わせフォーム からお声がけください。
