TypeScript 5.0の新機能まとめ：Decoratorsやconst型パラメータなど主要な変更点を解説

2026年4月30日

アップデート情報

TypeScriptは現在、Web開発における標準的な言語としての地位を確固たるものにしています。

その進化の過程において、バージョン5.0は単なるアップデートに留まらない、言語の基礎体力を大幅に向上させた記念碑的なリリースとなりました。

長年待ち望まれていたECMAScript標準のデコレータへの対応や、型推論をより厳密に制御する新機能など、開発者が直面していた課題を解決する強力なツールが導入されています。

本記事では、TypeScript 5.0で追加された主要な機能に焦点を当て、それらが実務にどのような変化をもたらしたのかを詳しく解説します。

目次 [ close ]

ECMAScript Decorators：待望の標準仕様への対応

TypeScript 5.0における最大のトピックは、ECMAScriptのStage 3プロポーザルに基づいた「デコレータ」の実装です。

これまでTypeScriptで提供されていたデコレータは、実験的な機能としての位置づけであり、tsconfig.jsonでexperimentalDecoratorsフラグを有効にする必要がありました。

従来のデコレータとの違い

従来のデコレータと5.0以降の標準デコレータでは、内部的な動作やメタデータの扱いが大きく異なります。

新しいデコレータは、クラスやそのメソッド、アクセサ、プロパティに対して、より型安全かつ予測可能な形で機能を追加できるように設計されています。

以下に、新しいデコレータを用いた簡単な実装例を示します。

TypeScript

// デコレータの定義：メソッドの実行時間を計測する
function loggedMethod(target: any, context: ClassMethodDecoratorContext) {
    const methodName = String(context.name);

    function replacementMethod(this: any, ...args: any[]) {
        console.log(`LOG: Entering ${methodName}.`);
        const result = target.call(this, ...args);
        console.log(`LOG: Exiting ${methodName}.`);
        return result;
    }

    return replacementMethod;
}

class Calculator {
    @loggedMethod
    add(a: number, b: number): number {
        return a + b;
    }
}

const calc = new Calculator();
calc.add(5, 10);

実行結果

LOG: Entering add.
LOG: Exiting add.

この新しいデコレータの最大の特徴は、contextオブジェクトを通じて型情報や名前などのメタデータにアクセスできる点です。

これにより、コンパイル時のチェックがより厳密になり、実行時のバグを未然に防ぐことが可能になります。

experimentalDecoratorsとの共存

TypeScript 5.0では、従来の実験的デコレータも引き続きサポートされています。

しかし、標準仕様への準拠という観点からは、新規プロジェクトでは標準デコレータの採用が推奨されます。

既存のライブラリ（例えば、InversifyJSやTypeORMなど）が従来の仕様に依存している場合は、無理に移行せず、互換性を維持することが重要です。

const 型パラメータ：リテラル型推論の簡素化

次に重要な機能が、「const 型パラメータ」の導入です。

これまで、関数の引数などで渡されたオブジェクトや配列をリテラル型として推論させるには、呼び出し側でas constを付与する必要がありました。

従来の方法とその課題

従来は、以下のように引数ごとにアサーションを行う必要がありました。

TypeScript

function getNames<T extends { names: readonly string[] }>(obj: T) {
    return obj.names;
}

// as const を忘れると string[] と推論されてしまう
const result = getNames({ names: ["Alice", "Bob"] } as const);

この方法では、APIの利用者が常に as const を記述しなければならず、書き忘れによる型の抽象化（ワイドニング）が頻発するという課題がありました。

const 型パラメータによる解決

TypeScript 5.0からは、型パラメータの宣言時にconstを付与できるようになりました。

これにより、関数側で「受け取った値を常にリテラルとして扱う」ことを強制できます。

TypeScript

// 型パラメータ T に const を付与
function getNamesConst<const T extends { names: readonly string[] }>(obj: T) {
    return obj.names;
}

// 呼び出し側で as const を書かなくてもリテラル型として推論される
const resultConst = getNamesConst({ names: ["Alice", "Bob"] });
// resultConst の型は ["Alice", "Bob"] というタプルリテラルになる

この機能により、ライブラリ作成者はユーザーに対して負担を強いることなく、より精密な型推論を提供できるようになりました。特に、定義済みの設定オブジェクトやスキーマ定義を扱う際に非常に強力な効果を発揮します。

複数の設定ファイルを継承する：extendsの配列指定

tsconfig.jsonの設定管理においても、大きな進歩がありました。

これまで、extendsフィールドには単一の文字列（ファイルパス）しか指定できませんでしたが、5.0からは「複数の設定ファイルを配列で指定」することが可能になりました。

設定の柔軟な組み合わせ

大規模なプロジェクトでは、ベースとなる共通設定、バックエンド用設定、フロントエンド用設定といった具合に、複数の設定を組み合わせたい場面が多くあります。

JSON

{
    "extends": ["./tsconfig.base.json", "./tsconfig.paths.json"],
    "compilerOptions": {
        "outDir": "./dist"
    }
}

このように記述することで、複数の設定ファイルから必要な項目を継承し、最後に記述された設定で競合を上書きすることができます。

これにより、設定ファイルの重複を減らし、メンテナンス性を飛躍的に向上させることが可能です。

列挙型（enum）の改善：ユニオン・エナム化

TypeScriptのenumは、古くから存在する機能ですが、いくつかの奇妙な挙動や型の不整合を抱えていました。

5.0ではこれらが整理され、すべての列挙型が「ユニオン列挙型」として扱われるようになりました。

改善された点

以前のバージョンでは、計算された値を持つ列挙型において、一部の型チェックが甘くなる傾向がありました。

5.0では、すべての列挙型メンバーが独自の型を持つようになり、より厳密な比較が可能になっています。

特徴	従来の仕様	バージョン5.0
数値メンバーの扱い	一部で曖昧な型推論	常にリテラル型として厳密に管理
計算された値	制限があった	より柔軟かつ型安全に処理

この変更により、列挙型を使用した際のエラー検出精度が向上し、予期せぬ数値の代入などを防ぐことができるようになっています。

verbatimModuleSyntax：モジュール出力の明確化

モジュールのインポートとエクスポートに関する挙動をより厳密に制御するための新しいフラグ、verbatimModuleSyntaxが導入されました。

なぜこの機能が必要なのか

これまでのTypeScriptでは、importsNotUsedAsValuesやpreserveValueImportsといった複数のフラグを組み合わせて、型のみのインポートをどのように出力コードに残すかを制御していました。

しかし、これらの挙動は複雑で、特にesbuildやSWCといった外部トランスパイラを併用する場合に問題が生じることがありました。

verbatimModuleSyntaxを有効にすると、以下のようなルールが適用されます。

import type で記述されたものは必ず削除される。
通常の import で記述されたものは、値として使われているかに関わらずそのまま残る。

TypeScript

import { someValue } from "./module"; // 値として扱われ、出力に残る
import type { SomeType } from "./module"; // 型として扱われ、必ず削除される

このフラグにより、「どのコードが最終的なJavaScriptに出力されるか」が構文から一目で判別できるようになります。これは、現代的な開発パイプラインにおいて非常に重要な予測可能性を提供します。

パフォーマンスの劇的な向上

機能面だけでなく、TypeScript 5.0はコンパイラ自体のパフォーマンス向上にも注力されました。

開発チームは、コードベースを名前空間（Namespaces）からモジュール（Modules）へと完全に移行し、ビルドツールの最適化を行いました。

改善の統計

マイクロベンチマークや実際のプロジェクトを用いたテストでは、以下のような顕著な改善が見られました。

パッケージサイズの削減：インストール時のディスク容量が約半分近くまで減少。
ビルド速度の向上：多くのプロジェクトで10%〜20%程度の高速化を達成。
メモリ使用量の最適化：複雑な型計算を伴うプロジェクトでのメモリ消費が抑制。

これらの改善は、開発者が毎日行う「コードの保存から反映」までのサイクルを短縮し、開発体験（DX）を直接的に向上させるものです。

2026年現在の視点で見ても、この時のアーキテクチャ刷新がその後の高速な進化を支える土台となったことは間違いありません。

新しい JSDoc サポート：@satisfies

TypeScript 4.9で導入された satisfies 演算子が、5.0からはJSDoc経由でも利用できるようになりました。

これにより、JavaScriptファイル（.js）を直接記述しながらTypeScriptの型安全性の恩恵を受けたい開発者にとって、強力な味方が加わりました。

JavaScript

/**
 * @typedef {Object} Color
 * @property {number} r
 * @property {number} g
 * @property {number} b
 */

/** @satisfies {Record<string, Color>} */
const palette = {
    red: { r: 255, g: 0, b: 0 },
    green: { r: 0, g: 255, b: 0 },
    // blue: { r: 0 } // エラー：g と b が不足している
};

satisfiesの利点は、オブジェクトの具体的な型情報を保持したまま、特定の構造を満たしているかをチェックできる点にあります。

JSDocでのサポートにより、TypeScriptへの完全移行が難しい既存のプロジェクトでも、段階的に型安全性を高めることが容易になりました。

export type * のサポート

以前のバージョンでは、export * from "module" は値と型の両方を再エクスポートしていましたが、型のみを対象とした export type * from "module" は記述できませんでした。

5.0からは、これが可能になっています。

TypeScript

// 別のモジュールから型だけをまとめて再エクスポート
export type * from "./models";

この構文により、APIの境界線において「型情報のみを提供している」ことを明示でき、不要なJavaScriptコードの生成を防ぐことができます。

まとめ

TypeScript 5.0は、「標準仕様への準拠」「型推論の表現力向上」「圧倒的なパフォーマンス改善」という3つの柱を中心とした、極めて完成度の高いアップデートでした。

特に、ECMAScript標準のデコレータへの対応は、長年コミュニティが待ち望んでいたものであり、今後のエコシステムの中心となる機能です。

また、const型パラメータや複数のtsconfig.json継承といった細かな改善も、日々の開発におけるストレスを軽減し、より堅牢なコードベースを構築するために寄与しています。

2026年の現在においても、これらの機能はTypeScript開発の基礎知識として定着しており、その重要性は変わりません。

まだ全ての機能を使いこなせていないと感じる方は、この機会に自身のプロジェクトへ取り入れ、より洗練された型安全な開発を追求してみてはいかがでしょうか。