Remixはもう"Reactフレームワーク"ではない - 生まれ変わったRemix 3の姿

はじめに

「Remixって、React Routerに統合されて終わったんじゃないの？」——そう思っている方は少なくないはずです。実際、Remix v2の機能はReact Router v7に吸収され、Remixという名前は一度表舞台から姿を消しました。

ところが2026年現在、Remixは**Reactに依存しない、全く新しいフルスタックフレームワーク「Remix 3」**としてベータ版が公開されています。GitHubのスター数は33,000を超え、「世界初の真のフルスタックJavaScriptフレームワーク」を掲げて、サーバー・ルーター・データレイヤー・UIコンポーネント・テストまでを一つのパッケージに統合するという、かなり大胆な再出発を果たしました。

この記事では、Remixがたどってきた経緯を整理しつつ、生まれ変わったRemix 3の設計思想と基本的な使い方を紹介します。

Remixとは

Remixは、React Routerの開発チーム（Ryan Florence氏とMichael Jackson氏）が開発しているフルスタックWebフレームワークです。かつてはReactをベースにしたSSRフレームワークとして人気を集めましたが、現在開発中のRemix 3ではReactへの依存をなくし、Web標準APIの上に構築された独自のフレームワークへと生まれ変わっています。

これまでの経緯を整理する

Remixの歴史は少し複雑なので、先に整理しておきます。

Remix v1〜v2: Reactベースのフルスタックフレームワークとして登場。loader/actionによるデータフローが高く評価されました
React Router v7への統合（2024年末）: Remix v2の機能はReact Router v7に統合され、既存ユーザーはReact Routerへの移行が推奨されました
Remix 3（現在ベータ版）: フレームワークとしてゼロから再設計。Reactから独立し、独自のコンポーネントモデルを採用しています

つまり、「ReactベースのRemixを使いたい」場合の答えは今やReact Router v7であり、Remix 3は全くの別物として捉えるのが正解です。

Remix 3の設計原則

Remix 3は、次の6つの原則を掲げて設計されています。

モデルファースト開発 - ドキュメントやAPIをLLMが理解しやすい形で設計し、AIエージェントとの協働を前提にしています
Web APIの上に構築 - RequestやResponseといったWeb標準APIをそのまま活用します
依存関係の最小化 - 外部パッケージへの依存を極力なくし、必要なものはフレームワーク自身が提供します
コンポーザビリティ - 小さな部品を組み合わせて構築できる設計です
ランタイム重視の設計 - ビルド時の魔法ではなく、実行時の挙動が予測しやすいコードを志向します
統合配布 - サーバー、ルーター、UIコンポーネントなどが一つのツールキットとして提供されます

特に面白いのがコンポーネントモデルです。Remix 3のコンポーネントはReactフックのようなランタイムセマンティクスを避け、通常のJavaScriptの制御フローで状態を扱えます。useStateやuseEffectの「ルール」に縛られない書き心地は、後ほどコード例で確認します。

インストール

Remix 3はベータ版のため、@nextタグを付けてインストールします。新規プロジェクトの作成はCLI一発です。

npx remix@next new my-remix-app
cd my-remix-app
npm i
npm run dev

開発サーバーはデフォルトで http://localhost:44100 で起動します（音楽好きのチームらしく、サンプリングレートの44.1kHzにちなんだポート番号です）。

既存プロジェクトに追加する場合は、パッケージとして直接インストールします。

npm install remix@next

基本的な使い方

ルート定義

Remix 3では、ルートを app/routes.ts にルートマップとして一元定義します。ファイルベースルーティングではなく、コードで明示的に宣言するスタイルです。

import { form, get, route } from "remix/routes";

export const routes = route({
  assets: get("/assets/*path"),
  home: "/",
  albums: {
    show: get("/albums/:albumId"),
    edit: form("/albums/:albumId/edit"),
  },
});

get() や form() といったヘルパーでURLパターンとHTTPメソッドを明示的に紐付けます。ルートマップは入れ子にでき、TypeScriptの型推論が効くため、存在しないルートやパラメータをコンパイル時に検出できます。

コントローラーでリクエストを処理する

ルートに対するリクエスト処理はコントローラーが担当します。Railsなどのサーバーサイドフレームワークに近い考え方です。

import { createController } from "remix/router";
import { routes } from "../../routes.ts";

export default createController(routes.albums, {
  actions: {
    show(context) {
      return new Response(`Album: ${context.params.albumId}`);
    },
  },
});

注目してほしいのは、戻り値が素の Response オブジェクトである点です。フレームワーク独自の抽象ではなく、Web標準のAPIがそのまま顔を出します。

フォーム送信を扱う場合は、必要なアクションにだけミドルウェアを適用できます。

import { formData } from "remix/middleware/form-data";
import { createController } from "remix/router";
import { routes } from "../../routes.ts";

export default createController(routes.albums.edit, {
  actions: {
    action: {
      middleware: [formData()],
      handler(context) {
        let title = String(context.formData.get("title") ?? "");
        return new Response(`Updated ${title}`);
      },
    },
  },
});

context.formData.get() で受け取った値を検証してから使う、という流れが自然に書けるようになっています。

コンポーネントの2段階モデル

UIをレンダリングするには、アクション内で context.render() を呼び出します。

return context.render(<AlbumPage album={album} />);

そしてRemix 3のコンポーネントは、セットアップとレンダリングの2段階で構成されます。ここがReactとの最大の違いです。

import { clientEntry } from "remix/ui";
import type { Handle } from "remix/ui";

export const AlbumEditForm = clientEntry(
  import.meta.url,
  function AlbumEditForm(handle: Handle<{ album: Album }>) {
    // 外側: セットアップフェーズ（初期化時に1回だけ実行）
    let pending = false;

    // 内側: レンダリングフェーズ（更新のたびに実行）
    return () => <form>...</form>;
  },
);

外側の関数はコンポーネントの初期化時に1回だけ実行され、内側の関数が再レンダリングのたびに呼ばれます。つまり pending のような状態はただのローカル変数として宣言でき、useStateも依存配列も必要ありません。クロージャという素のJavaScriptの仕組みだけで状態が完結するのは、一度体験すると病みつきになる書き心地です。

clientEntry() でラップしたコンポーネントはブラウザでハイドレーションされ、インタラクティブに動作します。逆にラップしなければサーバーだけでレンダリングされる、という切り分けも明快です。

実践的なユースケース

AIエージェントと協働する開発

Remix 3の「モデルファースト開発」は、単なるキャッチコピーではありません。フレームワーク自体が**スキル（AIエージェント向けのAPIガイド）**を同梱しており、Claude CodeなどのコーディングエージェントがRemixのベストプラクティスに沿ったコードを生成しやすい構造になっています。「AIに書かせたら古いバージョンの作法で書かれた」という、あるあるな悩みへの一つの回答と言えます。

依存関係を増やしたくないプロジェクト

Remix 3は、ルーター・データテーブル・UIコンポーネントなどを remix/router、remix/data-table、remix/ui といったモジュールとして自前で提供します。npmの依存ツリーが肥大化しがちなフルスタック開発において、「フレームワーク一つ入れれば揃う」構成は、長期運用するプロジェクトのメンテナンスコストを大きく下げてくれます。

採用前に押さえておきたい注意点

一方で、現時点では以下の点に注意が必要です。

まだベータ版です。APIは今後変わる可能性があるため、プロダクション投入は慎重に判断してください
Reactのエコシステムは使えません。既存のReactコンポーネント資産を活かしたい場合はReact Router v7が現実的な選択肢です
情報がまだ少ないため、公式のGuides（guides.remix.run）とAPIリファレンス（api.remix.run）を一次情報として参照するのがおすすめです