SJ blog
frontend
A

信頼度ランク

S 公式ソース確認済み
A 成功実績多数・失敗例少数
B 賛否両論
C 動作未確認・セキュリティリスク高
Z 個人所感

Remix 3がReactを捨てた——Preact Forkへの大転換と開発者の選択肢

Remix v3はReactを完全廃止しPreact Forkで再構築。移行パスはなく、React Router 7(安定)かRemix 3(実験的)という二択を迫られる。両者の違いと選択基準を整理する。

一言結論

Remix 3はReactを捨ててPreactフォークで再出発したが、既存ユーザーへの移行パスはなく、React Router 7(安定・React継続)かRemix 3(実験的・ウェブ標準志向)という二択になった。本番利用はRemix 3には時期尚早で、まず評価段階に留めるのが現実的だ。

何が起きたのか

2025年5月、Remix チームは公式ブログ「Wake up, Remix!」で衝撃的な発表をした。

Remix v3 は React を完全に廃止する。

これは単なるバージョンアップではない。Remix という名前を維持しながら、フレームワークの根幹部分を作り直すという大規模な方向転換だ。

Remix の軌跡:
  2020: Ryan Florence / Michael Jackson が Remix を創業
  2022: Shopify が Remix を買収
  2024: React Router v7 に Remix の機能がマージ
          → Remix v2 ユーザーは React Router 7 への移行を推奨
  2025年5月: 「Wake up, Remix!」 ─ React を完全廃止を宣言
  2026年現在: Remix 3 開発中(不安定版)

なぜ React を捨てるのか

Remix チームの主張は明快だ。React の「フレームワークとしての重さ」がウェブプリミティブとの乖離を生んでいるという。

Remix チームの問題認識:

  1. React は Web とは別のプリミティブ
     → Request/Response/FormData が React の抽象に隠れる
     → フレームワークが「Web の上で動く」のではなく
       「Web をラップしている」状態

  2. AI 時代の開発モデルとの不一致
     → LLM がコードを生成するとき、フレームワーク固有の
       DSL(useLoaderData 等)より Web 標準の方が扱いやすい
     → AI-First 設計には「汎用的なプリミティブ」が必要

  3. React のバンドルサイズと複雑さ
     → React 19 以降の Compiler / Server Components / Actions が
       複雑化。学習コストが増す一方

Remix 3 の技術的特徴

React ではなく Preact Fork

Remix 3 のコアスタック:
  ❌ React(廃止)
  ✅ Preact のフォーク(Shopify・Google が本番で使う実績ある VirtualDOM)

  なぜ Preact を「フォーク」するのか:
    → Remix 独自のコンポーネントモデルを実装するため
    → Preact のコアを取り込みつつ独自の this.update() 命令型モデルを採用
    → React とのエコシステム互換は意図的に切り捨てる

Web 標準へのフルコミット

// ❌ Remix v2(React ベース)スタイル
import { useLoaderData, Form } from '@remix-run/react'

export async function loader({ request }: LoaderArgs) {
  const data = await fetchData()
  return json(data)
}

export default function Page() {
  const data = useLoaderData<typeof loader>()
  return (
    <Form method="post">
      <input name="title" defaultValue={data.title} />
    </Form>
  )
}

// ✅ Remix 3(Web 標準ベース)スタイル(プレビュー段階)
// Request / Response / FormData をそのまま扱う
export async function loader(request: Request): Promise<Response> {
  const data = await fetchData()
  return new Response(JSON.stringify(data), {
    headers: { 'Content-Type': 'application/json' },
  })
}

AI-First 設計原則

Remix 3 は「LLM が生成しやすいコード構造」を明示的に設計原則に掲げている。

AI-First の意味:
  - フレームワーク固有の DSL を最小化する
  - Web 標準(Request/Response 等)に基づくため
    ChatGPT や Claude が訓練データから正確に推論できる
  - ソースコード・ドキュメント・ツールを
    LLM の入力として最適化する

二つの「Remix 系」フレームワーク

現在、開発者は事実上 2 つの別物 の中から選ぶ状況になっている。

┌─────────────────┬──────────────────────┬────────────────────────┐
│                 │ React Router 7       │ Remix 3                │
├─────────────────┼──────────────────────┼────────────────────────┤
│ ベース          │ React 19+            │ Preact フォーク        │
│ 安定性          │ 安定(本番利用可)   │ 不安定(開発中)       │
│ 移行パス        │ Remix v2 から移行可  │ React Router 7 からなし│
│ エコシステム    │ React 全資産が使える │ ほぼゼロからスタート   │
│ Shopify 採用    │ 継続利用中           │ 未定                   │
│ 設計思想        │ 漸進的改善           │ 根本的再設計           │
│ AI-First 設計   │ なし                 │ 明示的に採用           │
│ Web プリミティブ│ React でラップ       │ そのまま使う           │
└─────────────────┴──────────────────────┴────────────────────────┘

既存 Remix ユーザーへの影響

移行パスが存在しない

これが最大の問題だ。

移行の現実:
  Remix v1/v2 → React Router 7:  移行パスあり(ガイド公開済み)
  React Router 7 → Remix 3:      移行パスなし

  理由: コンポーネントモデルが根本的に異なるため
  自動変換ツールも提供予定なし

Shopify がどうするか

Shopify は Remix の元オーナーであり、現在も React Router 7 ベースで Hydrogen(Shopify のストアフロントフレームワーク)を構築している。Remix 3 への移行は「Hydrogen の全面書き直し」を意味するため、現時点で Shopify は React Router 7 に留まっている。

コミュニティの反応

r/webdev・Hacker News での主な意見:

  賛成派:
    「React の複雑さに疲れた。Web 標準に戻るのは正しい」
    「AI コーディング時代に合ったアーキテクチャだ」
    「Remix 1.0 の精神に戻った感じがする」

  反対派:
    「React エコシステムの資産(ライブラリ・採用市場)を捨てるのはリスクが高い」
    「移行パスなしは既存ユーザーの切り捨てでは」
    「Preact フォーク = 小さいエコシステム。誰が使うのか」

  現実主義派:
    「React Router 7 に留まるのが今は最善策」
    「Remix 3 は2〜3年後に評価すれば十分」

開発者としての判断基準

今すぐ Remix 3 を選ぶべきか?

Remix 3 を試してよいケース:
  ✅ 個人プロジェクト・プロトタイプ
  ✅ Web 標準の深い理解を学びたい
  ✅ AI-First アーキテクチャの探求
  ✅ 小規模チームで実験的なアプローチが許容される環境

Remix 3 を選ぶべきでないケース:
  ❌ 本番プロダクション(パッケージが unstable タグ)
  ❌ 大規模チームで React エコシステムに依存している場合
  ❌ Shopify / Shopify Hydrogen ベースの開発
  ❌ 3rd パーティ React ライブラリ(UI コンポーネント等)に強依存

現実的な推奨

現時点(2026年4月)での判断:

  既存 Remix v2 ユーザー:
    → React Router 7 へ移行(公式推奨・安定)

  新規プロジェクト:
    → Next.js 15 / React Router 7 / TanStack Start を第一候補に
    → Remix 3 は実験的ウォッチリストに入れておく

  Remix 3 の本格評価タイミング:
    → stable リリースと公式移行ガイドが出てから
    → 主要 React ライブラリの対応状況が明確になってから

注意点・未確認情報

  • Remix 3 はブログ執筆時点で packages が unstable タグ。API が予告なく変わる可能性がある
  • 「Shopify が Remix 3 を採用するかどうか」は現時点で公式発表なし
  • Preact フォークの正式名称・ライセンス形態は最終決定前(2026年4月時点)
  • 「AI-First 設計が具体的に何を意味するか」はドキュメントが未整備の部分が多い

まとめ

Remix 3 はフレームワークの大胆な再想像だが、開発者が今すぐ本番で使う選択肢ではない。Remix チームは「React Router 7 は安定した Remix の後継であり、Remix 3 は新しい実験」と明確に述べている。React エコシステムから離れるコストと、Web 標準への接近によるメリットのトレードオフは、プロジェクトの規模・チームのリスク許容度・AI ツールへの依存度によって変わる。2026年現在の現実的な戦略は「React Router 7 に移行しつつ、Remix 3 の進化を注視する」だ。

参考リンク