TypeScript 6.0 RCとNext.js16型エラー12例の直し方

TypeScript 6.0 RCとNext.js 16を同時に上げたら、いきなり型エラー祭りになって手が止まった。そんな人に向けた記事です。この記事では、実際に現場でよくハマる12パターンを「症状→原因→最短修正」でまとめます。読み終えるころには、どこから直せばビルドを戻せるか、判断の軸が作れるはずです。

僕は普段、福祉事業のIT全般を担当しつつ、AI×SaaSの開発にも入っています。Node.js + TypeScript + npm workspacesのモノレポを毎日触っているので、今回の移行で起きる「地味だけど痛い事故」を、できるだけ実務目線で言語化していきます。

TypeScript 6.0 RC × Next.js 16で型エラーが急増する理由

まず前提の日付をそろえます。TypeScript 6.0 RCの公式発表は2026年3月6日、Next.js 16の公式発表は2025年10月21日です。どちらも比較的新しい仕様変更なので、同時アップデートしやすいタイミングに入っています。ここで起きるのは、TypeScript側の既定値変更と、Next.js側の非同期API移行が同じタイミングで衝突することです。

• TypeScript側 — types 既定値が []、strict 既定値が true、rootDir の既定挙動変更などで、今まで見えていなかった問題が表面化します。
• Next.js側 — params / searchParams / cookies() / headers() が非同期前提になり、同期アクセスがそのままエラーになります。
• 運用側 — モノレポやCIで tsc --noEmit を強く回しているほど、エラー検知が一気に増えます。

イメージとしては、健康診断の解像度が突然4Kになった状態です。病気が増えたわけじゃなく、見えていなかったものが見えるようになっただけです。Next.js 16側はTurbopackでFast Refresh最大10x、本番ビルド2〜5xという改善も出ているので、移行メリットは大きいです。だからこそ、エラーを辞典化して順番に潰す進め方が効率的です。

エラー辞典12選（症状・原因・最短修正）

ここが実務で一番使うパートです。まず12例を一覧化します。詳細コードは次セクションで出しますが、先に「どの設定を触る話か」を見える化しておくと、チーム内の会話が速くなります。

大規模移行だと120以上のrouteファイル修正が必要だった事例もあります。なので、個人戦で頑張るより、エラーIDをチケット化して分担するのが現実的です。

tsconfig差分テンプレート（5.9→6.0 RC、Next 16対応）

ここでは、僕が実務で最初に当てる差分を置きます。ポイントは「新しい既定値に任せるところ」と「事故りやすいので明示するところ」を分けることです。特に types と rootDir は明示しておくと、チーム開発の再現性が上がります。

{
  "compilerOptions": {
    "target": "ES2025",
    "module": "ESNext",
    "moduleResolution": "bundler",
    "strict": true,
    "rootDir": "./src",
    "paths": {
      "@app/*": ["./src/app/*"],
      "@lib/*": ["./src/lib/*"]
    },
    "types": ["node", "jest"],
    "noEmit": true,
    "skipLibCheck": true
  },
  "include": [
    "next-env.d.ts",
    "src/**/*.ts",
    "src/**/*.tsx",
    ".next/types/**/*.ts"
  ]
}

補足すると、TS公式では types を適切に絞ることで、調査対象プロジェクトでビルド時間が20〜50%改善したとされています。つまり「型の厳密化で遅くなる」だけではなく、設定次第で速くなる余地もあります。あと、baseUrl は今後の扱いが変わる前提なので、エイリアスは paths のフル指定へ寄せるのが安全です。

既存コード量が多いなら、最初の1週間だけでも strict の運用方針をチームで明文化しておくとブレません。暗黙anyを一時許容するのか、今回で潰し切るのか。ここをそろえるだけで、レビューの渋滞はかなり減らせます。

自動移行の実務フロー（codemod / next typegen / CI）

移行作業は、手で頑張るより自動化の順番が大事です。僕はだいたい次の流れで進めます。モノレポでもこの順序なら、壊れた箇所の切り分けがしやすいです。

1. 専用ブランチを切る — アップグレード専用PRにして、機能開発と混ぜません。
2. codemodを先に当てる — npx @next/codemod@canary next-async-request-api .
3. @next-codemod-errorをゼロにする — 残件を検索して手修正します。
4. 型生成を更新 — next typegen を実行し、PageProps などを再生成します。
5. CIで型チェック固定 — tsc --noEmit を必須ジョブにします。
6. ルート単位で検証 — 動的ルート、metadata、sitemapを重点確認します。

export default async function Page(props: PageProps<'/blog/[slug]'>) {
  const { slug } = await props.params
  const query = await props.searchParams
  return <div>{slug} / {query.q}</div>
}

運用メモとして、外部導線ではなく、実測ログ・設定差分・再現手順を同じ場所に残してチーム内で確認できる形にしてください。

失敗しやすいポイント（typedRoutes、cacheComponents、3rd-party依存）

ここは「直したはずなのに再発する」ゾーンです。特に typedRoutes を有効化しているプロジェクトは、ルーティングの文字列ミスが即型エラーになります。たとえば /aboot のようなtypoは即落ちです。非リテラルは as Route で意図を示す必要があります。

つまり、ルーティング本体だけじゃなく周辺APIまで一括で非同期化するのが再発防止のコツです。さらに、searchParams依存のページは「静的90%・動的10%」のようにルート分離しておくと、静的生成のメリットを残しながら移行できます。

本番移行チェックリスト（段階リリースとロールバック基準）

最後に、本番で事故らないための運用面です。僕は「全部切り替え」より、段階リリースを推奨しています。理由はシンプルで、型エラーは直せても、トラフィック実環境でしか見えないボトルネックが残るからです。

• チェック1 — CIで tsc --noEmit を必須化し、main直pushを止める
• チェック2 — 動的ルートのE2Eを最低限追加（params/searchParams/cookies）
• チェック3 — metadata・sitemap・route handlerを別観点で確認
• チェック4 — まず10%トラフィックでcanary配信し、48時間監視
• チェック5 — エラー率、p95、ビルド時間の3指標で判定
• チェック6 — ロールバック条件をPRに明記しておく

目安として、エラー率が前週比で有意に悪化、またはp95レイテンシが20%以上伸びるなら、いったん戻す判断が現実的です。逆に、型エラーの検知件数が下がり、レビュー時間が短縮しているなら成功です。移行のゴールは「最新化」ではなく、開発速度と安全性を同時に上げることですよね。

移行を知らないまま1年過ごすと起きること

このテーマを後回しにすると、じわじわコストが増えます。たとえば新規参加メンバーが古い前提で実装し、後から全面修正になる。あるいは typedRoutes の型恩恵を受けられず、単純なリンクミスが本番で発覚する。仕様変更を知らないままだと、開発速度ではなく「手戻り速度」だけが上がる可能性があります。今のうちに土台を合わせておくと、1年後の差がかなり大きくなります。

この記事を書いている理由

僕自身、Node.js + TypeScript + npm workspacesのモノレポをMac mini M4 Proで24時間運用する中で、型の移行を雑に進めると後で何倍も返ってくる場面を何度も見てきました。2025年10月から継続改善している結婚式Web招待状サービスでも、90日以上のログイン継続を維持するために、機能追加より先に型品質を整える判断をしてきました。これは理想論ではなく、実際に運用して痛みを見たからこそ伝えたい話です。移行で詰まっている人の、最初の一歩になったらうれしいです。

次のアクション

記事が役立ったら、感想をXで教えてください。反応が多ければ、次回はJest/RTLでの params モック実装まで具体例を出していきます。