【TypeScript】TypeScript 5.9のimport defer完全ガイド — モジュールの評価を遅延する新構文の書き方と使いどころ

結論

TypeScript 5.9で導入されたimport deferは、モジュールの「読み込み」と「評価（トップレベル実行）」を分離する新しい構文です。従来の静的importが読み込みと同時に即評価されるのに対し、import deferではプロパティに初めてアクセスされるまで評価を遅延できます。これにより、使われないかもしれない重いモジュールの初期化をアプリ起動後に追いやれるのがポイントですね。

// 読み込みは即時、評価は初回アクセス時まで遅延
import defer * as analytics from "./analytics.js";

// この時点ではanalyticsモジュールはまだ評価されていない
console.log("App started");

// 初めてプロパティにアクセスした瞬間に評価される
analytics.track("page_view");

ただし注意点もあります。import deferは名前空間インポート（import defer * as ns）のみサポート。名前付きimportやdefault importは使えません。またランタイム側の対応が必要で、現在はStage 3のECMAScript提案（2026年9月時点）ですが、TypeScript 5.9で先行して型チェックと構文サポートが追加された形です。

import deferの基本構文とルール

使える構文・使えない構文

import deferで覚えるべき一番の制約は「名前空間インポート限定」ということです。

// これだけが正しい
import defer * as feature from "./feature.js";

// 名前付きimportは不可
import defer { doSomething } from "./feature.js";

// default importも不可
import defer feature from "./feature.js";

// 名前空間なしも不可
import defer "./feature.js";

これはimport deferの動作原理から来ています。「プロパティアクセス時に評価をトリガーする」という仕様上、名前空間オブジェクト（ns.valueのようにアクセスする方式）じゃないと遅延評価の契機を取れないんですね。

TypeScriptのコンパイラ設定

import deferを使うにはmoduleオプションをesnextかpreserveに設定する必要があります。

{
  "compilerOptions": {
    "target": "esnext",
    "module": "esnext",
    "moduleResolution": "bundler",
    "strict": true
  }
}

TypeScriptはimport deferをトランスパイルしません（downlevelしない）。そのままランタイムやバンドラに任せる設計です。nodenextなど他のmodule設定ではコンパイルエラーになります。これは意図的で、import deferがまだ実験的な機能であり、対応しているランタイム環境でだけ使うことを前提としているからですね。

静的import vs 動的import vs import defer

ES Modulesにおける3種類のimportを比較してみましょう。

従来、重いモジュールを遅延読み込みしたい場合は動的import（import()）を使うのが定番でした。ただ動的importは非同期処理になるので、使う側もasync/awaitに巻き込まれるのが避けられません。

// 動的importの場合：非同期処理が必要
async function loadSettings() {
  const config = await import("./heavy-config.js");
  return config.default;
}

// import deferの場合：同期的に書ける
import defer * as config from "./heavy-config.js";

function loadSettings() {
  // ここで初めて評価される
  return config.default;
}

import deferの強みは「同期的に遅延評価できる」ことです。関数やコードの構造を変えずに、重い初期化処理だけ後回しにできます。

実践ユースケース

ユースケース1: 起動時間の改善

一番わかりやすい使い方は、アプリ起動時に不要なモジュールの評価を遅らせるケースです。

// heavy-analytics.ts
console.log("Analytics module evaluating...");

const start = Date.now();
while (Date.now() - start < 500) {
  /* CPUバウンドな処理 */
}

export function track(event: string) {
  console.log("Track: " + event);
}

export const APP_VERSION = "1.0.0";

// main.ts
import defer * as analytics from "./heavy-analytics.js";

console.log("App started");
// 起動時間に500msのオーバーヘッドなし

button.addEventListener("click", () => {
  analytics.track("button_click");
});

通常の静的importではアプリ起動時にheavy-analyticsが評価されて500msブロックしますが、import deferならユーザーがボタンをクリックするまで評価を遅らせられます。「もしかしたら使わないかもしれない」機能の初期化コストを、確実に必要な場面まで先送りできるのが強みですね。

ユースケース2: プラットフォーム固有のコード

ブラウザとNode.jsのように実行環境によって使うモジュールが異なる場合にも便利です。

// storage-web.ts
export function save(key: string, value: string) {
  localStorage.setItem(key, value);
}

// storage-node.ts
import { writeFileSync } from "node:fs";

export function save(key: string, value: string) {
  writeFileSync("./data/" + key + ".json", value);
}

// main.ts
import defer * as storage from "./storage-web.js";

export function savePreference(key: string, value: string) {
  storage.save(key, value);
}

従来は起動時に両方のモジュールが評価されたり、動的importで非同期処理を強いられたりしましたが、import deferなら評価を完全に初回使用時まで遅延できます。

ユースケース3: 巨大な設定ファイルやi18nリソース

// i18n-resources.ts
export const resources = {
  ja: { /* ... 大量データ */ },
  en: { /* ... */ },
};

import defer * as i18n from "./i18n-resources.js";

function getMessage(locale: string, key: string): string {
  return i18n.resources[locale]?.[key] ?? "MISSING";
}

ユーザーが言語設定を変更したタイミングで初めてリソースが評価されるため、初期表示が高速になります。

import deferの注意点と制限

top-level awaitとの非互換

import deferでインポートしたモジュール（およびその依存）がtop-level awaitを使っている場合、そのモジュールは積極的に評価されます。なぜなら、import deferによるプロパティアクセスは同期的でなければならず、非同期的な評価は先に完了しておく必要があるからです。

// async-module.ts
const response = await fetch("/config.json");
export const config = await response.json();

// main.ts
import defer * as cfg from "./async-module.js";
// top-level awaitを含むのでdeferしてもすぐに評価が開始される

現実的には、top-level awaitを含むモジュールはimport deferの恩恵を受けられないと考えておきましょう。

ランタイムサポートの状況

import deferはECMAScriptのStage 3提案であり、現時点（2026年9月）でネイティブサポートしているランタイムはまだありません。Chrome/V8チームが実装に興味を示している段階です。TypeScript 5.9での追加は「型チェックと構文の事前サポート」という位置づけですね。

とはいえ、構文が固まったStage 3からのドロップは稀で、多くの機能がそのままStage 4（正式仕様）に進んでいます。バンドラ（esbuildやwebpack）の対応も進むでしょうから、今のうちに構文と使い方を理解しておいて損はありません。

読み込みは即時行われる

import deferは評価だけを遅延します。ファイルの解決・取得・解析は通常の静的importと同じタイミングで行われます。つまり「ネットワーク負荷を減らしたい」という目的には使えません。ネットワーク経由の遅延ローディングには従来通り動的importを使う必要があります。

まとめ

import deferは静的importと動的importの「良いとこ取り」を狙った構文ですね。静的importのシンプルさ（同期処理）を保ちつつ、動的importのメリット（評価の遅延）を得られます。

まだランタイムの対応はこれからですが、TypeScript 5.9で既に型安全に書けるようになったのは大きな前進です。「重い初期化処理を持つモジュール」「プラットフォーム固有の実装」「巨大な設定データ」などを扱うプロジェクトでは、import deferが視野に入った設計を始めてみてもいいかもしれませんね。

【広告】お名前.comならドメイン取得が格安。

【広告】このサイトはConoHa WINGで運営しています。安定した高速サーバーで快適にブログを書けています。いつもありがとう！！