TypeScript 7.0をDjangoサイトに導入して実測してみた: Goネイティブ化で型チェックは何倍速くなるのか

結論

2026年7月8日にリリースされたTypeScript 7.0を、当サイト (kurutann.com) の 実際のJavaScript資産で多角的に計測しました。結論から書くと、

• tsc によるCLI型チェックはTypeScript 7.0を標準採用する
• typescript-eslintのようにCompiler APIに依存するツールのためだけに、 TypeScript 6.0系を別名パッケージ(@typescript/typescript6)で併用する
• Node.jsは本番サーバーに常駐させず、Dockerのビルド工程だけで使う

重要なのは、これは「サイトの表示を速くする施策」ではなく「開発・型チェック・CI を 速くする施策」だという点です。この区別も含めて、実測データで整理します。

TypeScript 7.0とは: 単なるメジャーアップデートではなく世代交代

TypeScript 7.0 は、これまでJavaScript(自分自身)で書かれていたコンパイラと言語サービスを Go言語ベースのネイティブ実装へ移行したバージョンです。ただし「ゼロから 別物として書き直した」わけではありません。Microsoft公式は、既存コードベースの構造と ロジックをできるだけ忠実に保った移植(port)であり、TypeScript 6.0と結果の互換性を重視した と説明しています。既存のJS資産をallowJs/checkJsで検証する対象としても、 この「結果互換の移植」という性質は重要です。

時系列としては、2026年6月18日にRC(リリース候補)版が報じられ、2026年7月8日に正式版が 公開されました。本記事はRC情報ではなく正式版(7.0.2)で計測しています。

公式が公開している数値は以下の通りです。

• フルビルドが TypeScript 6.0 比で8〜12倍高速化 (VSCode: 125.7秒→10.6秒、Sentry: 139.8秒→15.7秒、Bluesky: 24.3秒→2.8秒)
• メモリ使用量が6〜26%削減
• エディタでファイルを開いてからエラー表示までが約17.5秒→1.3秒未満(13倍以上)
• 新Language Serverは、失敗したLanguage Serverコマンドを80%以上削減、 サーバークラッシュを60%以上削減(対TypeScript 6.0)
• strictが既定で有効化、module既定がesnextになる等、 既定値が多数変更

これらは他社の大規模モノレポでの数値です。「では自分たちのコードで測るとどうなるか」を 確認しました。

計測条件(公平性のための前提)

以下の数値は、当サイトの実際のJSファイル(StudyRoom、NoFake、AvatarRig、Portal、Kids、 MyRoom MMOタウンのインラインJSを抽出したもの)を対象に、[email protected]と [email protected](いずれもnpmの実配布バージョン)を実際にインストールして 計測したものです。

• 計測環境はNode.js 24.12.0・論理16コアの開発機。本番VPSは3 vCPUのため、 並列化系の数値は本番でそのまま再現するとは限りません
• メモリはプロセスのWorkingSet。TS7のtsc.jsはネイティブtsc実行 ファイルを子プロセスとして起動する薄いランチャーであることを確認したため、 子プロセス分も合算しています(合算しないと大幅な過小評価になります)
• 通常比較・strict比較は3回計測の中央値、並列度比較はノイズが大きいため7回計測の中央値、 watchモードは1サンプル
• strict比較は同一のtsc 7.0.2バイナリでフラグのみ切り替えており、 コンパイラ差と設定差を分離しています
• ブラウザでの実行速度・訪問者側メモリ・LCP等の表示指標は本計測の対象外です

実測1: 通常の型チェック速度(TS6.0.3 vs TS7.0.2)

6アプリ平均で約4.4倍の高速化、約38%のメモリ削減。公式の「8〜12倍」より控えめなのは、 当サイトの各アプリが1〜12ファイル規模で、プロセス起動コストの比率が相対的に大きいためと 考えています。ファイル数が多いアプリほど倍率が伸びる傾向も確認できました。 つまり今回の実測は公式値と矛盾せず、「現実的な中小規模コードでは公式値より控えめになる」 ことを確認できたという位置づけです。

実測2: 並列化オプション(--checkers / --singleThreaded)は当サイト規模では効かない

TypeScript 7.0は解析・型チェック・emitを並列化しており、型チェックワーカー数を調整する --checkers(公式デフォルトは4)、並列化を止める --singleThreaded、project references の並列ビルド数を調整する --buildersが追加されています。当サイトの6アプリで --checkers 1/2/3/4/8と--singleThreadedを7回ずつ計測しましたが、 明確でモノトニックな傾向は確認できませんでした。7回計測の中央値でも値が 上下しており、効果量より測定ノイズの方が大きい状態です。

これは当サイトの各アプリが数百ms未満で型チェックが終わる小規模プロジェクトであり、 並列化のメリットよりプロセス起動コストが支配的なためです。このオプションは数百ファイル 規模のビルドやproject references分割構成で真価を発揮するもので、当サイトの現在の 規模ではチューニング不要、既定値のまま運用という結論です。将来 StudyQuest/TRPG/SecOps/MyRoomをproject referencesで分割する場合は--buildersも 評価対象になりますが、--checkersと掛け算で並列数が増えるため、3 vCPUのVPSや CIではメモリ圧迫に注意が必要です。

実測3: watchモードは「再チェック速度」が明確に改善

TypeScript 7.0の--watchはParcel由来のファイルウォッチャーをGoに移植した実装に 刷新されています。tsc --watch単体で、ファイル保存から型エラー再表示までの 待ち時間を計測しました(各1サンプル)。

一貫してTS7が速く、単一ファイルのAvatarRigでは436ms→47msと特に大きく短縮されました。 一方、公式が言及する「アイドル時CPU使用量の削減」も測ってみたところ、変更なしで60秒間 放置した際のCPU消費はTS6・TS7とも0.02 CPU秒/分と実質ゼロ、常駐メモリは むしろTS7の方がやや多い(165.7MB vs 143.4MB)という結果でした。アイドルCPU削減は ポーリング監視が重くなる大規模プロジェクト向けの改善であり、当サイト規模では効果が 現れない、というのも正直に書いておきます。Django開発ではrunserver・Vite dev server・ tsc --watchを同時に動かすため、当サイトにとってのwatch改善の実益は 「再チェックの速さ」の方です。

実測4: strict既定値を有効化すると、既存コードから大量のエラーが出る

TypeScript 7.0はstrict: trueが既定です。同一のtsc 7.0.2バイナリで strictのみを切り替え、既存の無型注釈コードに対する検出エラー数の差分を 計測しました。

型安全化の価値を裏付ける数値である一方、いきなりstrict trueで移行するのは 非現実的だということも示しています。移行時はcheckJsを strict: falseから始め、型定義を積み増しながら段階的に個別のstrict系オプションを 有効化していく方針にしました。

実測5: JS/JSDoc解析の差分は、当サイトのコードでは軽微だった

TypeScript 7.0ではJavaScriptファイルの解析がTypeScriptファイルに近い挙動へ寄せられ、 Closure風JSDocや@enum、@class等の扱いが変わっています。既存JSを allowJs/checkJsで運用する場合はここが地雷になり得るため、同一コーパスに対する TS6/TS7のエラー数と内訳を比較しました。

• StudyRoom: 227件(TS6) → 222件(TS7)。内訳はプロパティ不存在(TS2339)が193→189件、 未定義名(TS2304)が19→16件など微減。一部は「候補の提案」系診断がTS2551→TS2552へ 再分類されただけでした
• MyRoom MMOタウン: 84件 → 82件。同傾向
• 残り4アプリ: 完全に同数

当サイトのJSにはClosure風JSDocや@enumを使った箇所がなかったため、 TS7のJS解析変更による新規エラーはゼロでした。逆に言えば、Closure由来の JSDoc記法が残っている古いコードベースでは、TS6で通っていたものがTS7で止まる可能性が あるので、移行前に同種の比較をしておくことをおすすめします。

CLI利用とCompiler API利用は分けて判断する

TypeScript 7.0のtypescriptパッケージを直接調べたところ、次のことがわかりました。

• require('typescript')の戻り値は{ default, version, versionMajorMinor } のみで、createProgram等の従来のCompiler APIは含まれていません。 AST操作等のAPIはtypescript/unstable/astのように明示的に"unstable"と 名付けられたパスの下にあるだけです
• エディタ向け言語サーバー(tsserver)バイナリも同梱されず、新しいLSPベースの言語サーバーは 別パッケージで提供されています
• typescript-eslint(調査時点の最新8.63.1、alpha版含む)の peerDependenciesは"typescript": ">=4.8.4 <6.1.0"で、 TypeScript 7系はサポート範囲外でした
• 6.0系を別名で併存させる@typescript/typescript6パッケージが公式に npm公開されており、side-by-side構成が組めます

この制約が最も強く効くのはVue/MDX/Astro/SvelteのようにTypeScriptをコンパイラAPIと して深く組み込むフレームワークで、公式もこれらは当面TypeScript 6.0依存が続き、 7.1で提供予定の新APIを待つ必要があると説明しています。一方、当サイトは Djangoテンプレート + 素のJS/TSエントリーという構成なので、CLI型チェック 用途としてのTypeScript 7.0をすぐ使い始められます。「SPAフレームワークではないから遅れて いる」のではなく、この場面ではテンプレート型構成の方が新コンパイラを先に採用しやすい、 という面白い逆転があります。

TypeScript 6.0は7.0への橋渡しリリースだった

非推奨オプション(target: es5、moduleResolution: node等)を 指定した際の挙動を比較すると、

• TS 6.0.3: error TS5107: ...is deprecated and will stop functioning in TypeScript 7.0. Specify compilerOption '"ignoreDeprecations": "6.0"' to silence this error. (エスケープハッチ付きの警告的エラー)
• TS 7.0.2: error TS5108: ...has been removed. Please remove it from your configuration.(エスケープハッチ無しの完全撤去)

TS6ではignoreDeprecations: "6.0"という抜け道がありますが、TS7にはありません。 古いtsconfigを持つプロジェクトは、TypeScript 7.0で速くなる前に、まずtsconfigの現代化で 止まります。DjangoサイトにTypeScriptを後付けする当サイトはtsconfig自体が新規なので、 この移行痛は発生しませんでした。

重要: 速くなるのは「開発体験」、サイト表示ではない

ここまでの計測はすべて、手元でコードを型チェック・ビルドする際のコンパイラの速度です。 TypeScriptは最終的に普通のJavaScriptへ変換されて配信されるため、

• サイト訪問者のページ表示速度(LCP/FCP)が速くなるわけではない
• 訪問者のブラウザのメモリ使用量が減るわけではない
• TypeScript化そのものによる3D/WebGL描画のパフォーマンス向上はない

改善するのは開発者側の体験(型チェック・watch・エディタ応答・CI)です。ユーザー体感速度を 改善するには、Viteによるbundle分割・遅延ロード・圧縮・キャッシュ設計が別途必要で、 それはTypeScriptではなくバンドラの仕事です。

DockerfileにはNode.jsのbuild stageが必要だった(本番runtimeには置かない)

本番のDockerfile(Python 3.14ベース)とデプロイパイプラインを確認したところ、Node.js/npmは 一切含まれていませんでした。ここで重要なのは、Node.jsを本番コンテナに常駐させる 必要はないという点です。既存のRustエンジンのマルチステージビルドと同じパターンで Node.jsのビルド専用ステージを追加し、Vite成果物(static/dist/)だけを最終イメージへ コピーすれば、最終イメージにNode.jsは含まれません。「本番にNode.jsランタイムを常駐させる 変更」ではなく「ビルド時にだけNode.jsを使う変更」です。

StudyQuest + three.js + TypeScript 7.0の今後

当サイトで型チェック高速化の恩恵が最も大きいのは、WebSocket・Canvas・three.js・API通信が 混ざって画面ごとのJavaScriptが肥大化している領域(StudyQuestの3Dスタディルーム、MyRoomの MMOタウン、NoFakeの3D会議室、AvatarRig)です。これらを順にVite + TypeScript 7.0管理下へ 移していきます。小ネタとしては、TS7でtemplate literal型のUnicode処理が自然になり (絵文字がサロゲートペアに分割されなくなった)、称号や絵文字つき演出名を型レベルで扱う StudyQuestのような用途では地味に嬉しい改善もあります。

まとめ

• TypeScript 7.0は「Goネイティブへの世代交代」であり、当サイトの実コードでも 型チェック約4.4倍・メモリ38%減・watch再チェック1.9〜9.3倍を実測できた
• --checkers等の並列化チューニングは当サイト規模では効果がノイズに埋もれる。 既定値(checkers=4)のままでよい
• strict既定値をそのまま適用すると既存コードから数百〜1,400件のエラーが出る。 段階的に有効化する
• JS/JSDoc解析差分は当サイトのコードでは軽微(新規エラーゼロ)だった
• CLIのtscは7.0採用、Compiler API依存ツール(typescript-eslint等)は @typescript/typescript6との併用で対応
• Node.jsはDockerのbuild-time dependencyとしてのみ導入し、本番runtimeには置かない
• そしてこれはサイト表示を速くする施策ではなく、開発・保守・CIを速くする施策である

「新しいから」「速いと報告されているから」ではなく、自分たちの実コードと本番環境で 何が起きるかを確認した上で採用範囲を決めた、という記録です。

出典と再現性について

最終確認日: 2026年7月22日。リリース日、Goネイティブ移植、公式ベンチマーク、 --checkers/--builders、TypeScript 6との併用は TypeScript公式発表を確認しました。 本文中のサイト内計測値は筆者の開発環境における実測であり、ハードウェア・対象コード・実行条件で変動します。