TypeScript 7.0 RC入門——Next.jsプロジェクトで型チェックを高速検証する

はじめに

Next.jsの業務アプリを育てていると、型チェックの待ち時間がじわじわ効いてきます。

2026年6月18日、Microsoftは TypeScript 7.0 RC を公開しました。公式ブログでは、Goで移植された新しいコンパイラ基盤により、TypeScript 6.0より高速に動作するケースが多いこと、RC版は typescript パッケージの rc タグから導入できることが説明されています。

本記事では、架空の在庫管理SaaS「StockLane」を題材に、Next.js + Firestore + GitHub ActionsのプロジェクトでTypeScript 7.0 RCを安全に検証する手順を紹介します。読み終えると、本番ブランチを壊さずに型チェック時間と互換性を測れるようになります。

何がニュースなのか

TypeScript 7.0 RCの大きなポイントは、構文や型システムを派手に変えることではありません。既存のTypeScript 6.0と同じ意味論を保ちながら、コンパイラと言語サービスの実装基盤をGoへ移したことです。

公式発表で確認できる実務上の要点は次の通りです。

つまり、Next.jsアプリでまず見るべきなのは「新機能を使う」ではなく、「既存コードが同じ結果で速く検査できるか」です。

ハンズオン1: ブランチでRCを試す

まず本番ブランチへ直接入れず、検証ブランチで試します。モリソンのプロジェクト方針に合わせ、コマンドはYarnで統一します。

git switch -c feature/typescript-7-rc
yarn add --dev typescript@rc
yarn tsc --noEmit
yarn build

yarn tsc --noEmit は型チェックだけを走らせます。Next.jsのnext buildも型チェックを含みますが、最初はtsc単体で失敗箇所を絞ったほうが調査しやすいです。

StockLaneのようなFirestoreを使うアプリでは、まず型境界の強い箇所を確認します。例えば、Firestoreの監査ログをアプリ内の型へ変換する関数です。

import type {
  DocumentData,
  QueryDocumentSnapshot,
  Timestamp,
} from "firebase-admin/firestore";

type AuditAction = "stock.create" | "stock.adjust" | "stock.archive";

type AuditLog = {
  id: string;
  action: AuditAction;
  actorId: string;
  itemId: string;
  createdAt: Date;
};

export function toAuditLog(
  snapshot: QueryDocumentSnapshot<DocumentData>,
): AuditLog {
  const data = snapshot.data();
  const createdAt = data.createdAt as Timestamp | undefined;

  if (!createdAt) {
    throw new Error(`auditLogs/${snapshot.id} is missing createdAt`);
  }

  return {
    id: snapshot.id,
    action: data.action as AuditAction,
    actorId: String(data.actorId),
    itemId: String(data.itemId),
    createdAt: createdAt.toDate(),
  };
}

ここで見るべきなのは、TypeScript 7.0 RCが新しいエラーを出すかどうかです。RCはTypeScript 6.0との互換性を重視しているため、正常な6.0設定で通るコードは同じように通ることが期待されます。一方で、古い非推奨オプションや曖昧な型境界が残っていると、7.0移行前の整理ポイントとして表面化します。

ハンズオン2: 計測用CIを分ける

RCをいきなり通常CIへ入れると、失敗時に開発全体が止まります。まずは手動実行できる比較用workflowに分けるのが現実的です。

name: TypeScript RC Check

on:
  workflow_dispatch:

permissions:
  contents: read

jobs:
  compare:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: "20"
          cache: "yarn"

      - run: yarn install --frozen-lockfile
      - name: Baseline typecheck
        run: time yarn tsc --noEmit

      - name: Install TypeScript 7.0 RC
        run: yarn add --dev typescript@rc

      - name: RC typecheck
        run: time yarn tsc --noEmit

      - name: RC build
        run: yarn build

このworkflowはworkflow_dispatchだけにして、必要なときだけ実行します。CI時間を毎PRで増やさず、TypeScript 7.0 RCの互換性と速度感を観察できます。

計測結果は次のような表でIssueに残しておくと、後で正式版へ移行するときの判断材料になります。

数値はプロジェクト規模やGitHub-hosted runnerの混雑で変動します。1回だけで判断せず、同じ条件で複数回測るのが安全です。

ハンズオン3: Next.jsとFirestoreの確認ポイント

TypeScript 7.0 RC検証では、アプリの全画面を手で触る前に、型依存が集中する箇所を順番に見ます。

例えば、Server Actionでは入力値をそのままFirestoreへ流し込まず、TypeScriptで扱う型を一度確定させます。

"use server";

type AdjustStockInput = {
  itemId: string;
  delta: number;
  actorId: string;
};

function parseAdjustStockInput(input: FormData): AdjustStockInput {
  const itemId = String(input.get("itemId") ?? "");
  const actorId = String(input.get("actorId") ?? "");
  const delta = Number(input.get("delta") ?? 0);

  if (!itemId || !actorId || !Number.isFinite(delta)) {
    throw new Error("Invalid stock adjustment input");
  }

  return { itemId, actorId, delta };
}

TypeScript 7.0 RCによって、このような型境界の設計が不要になるわけではありません。むしろ型チェックが速くなるほど、CIでこまめに検証し、Firestoreのスキーマ崩れを早く見つける運用が組みやすくなります。

導入時の注意点

RCは正式版ではありません。業務アプリでは、次のルールを置いてから試すのがおすすめです。

1. mainへ直接入れず、検証ブランチで試す
2. yarn buildだけでなくyarn tsc --noEmitも見る
3. typescript-eslintなど、TypeScriptのAPIを直接使うツールの互換性を確認する
4. Firestore本番データへ接続する検証とは分離する
5. 正式版リリース後に、RCで得た結果をもとに再確認する

特に重要なのは3つ目です。公式発表では、TypeScript 7.0の安定したプログラマブルAPIは少なくとも7.1以降になる予定とされています。コンパイラAPIへ深く依存するツールがある場合は、アプリ本体の型チェックが通っても、周辺ツールで詰まる可能性があります。

参考リンク

• Announcing TypeScript 7.0 RC
• Announcing TypeScript 7.0 Beta
• New runner images in public preview

まとめ

TypeScript 7.0 RCは、Next.jsアプリの開発体験とCI時間を改善する可能性が高いリリースです。ただし、RC段階でやるべきことは、無理に本番採用することではありません。

まずは検証ブランチと手動実行のGitHub Actionsで、yarn tsc --noEmitとyarn buildを比較します。Firestoreの型境界、Server Actions、周辺ツールの互換性を確認できれば、正式版が出たときに落ち着いて移行判断できます。