サイトやWebアプリの刷新で3社から見積もりを取ると、技術構成の欄に別々の名前が並びます。ある会社は「Next.js」、別の会社は「Astro」、もう1社は「Remix」。どれも実績のあるフレームワークなので、発注側から見ると横並びで比べる材料がありません。結局「金額と担当者の印象」で決めることになります。
その判断が、今年少し難しくなりました。Remixが3系でReactを捨てたからです。フレームワークが人気を保ったまま土台ごと作り替えるという出来事は、発注する側に「今選ぶ技術は、改修を頼み続ける5年後も同じ形で残っているのか」という問いを持ち込みます。
Remix 3が捨てたもの
Remixは、Reactの上に構築されたフルスタックフレームワークとして評価を得ていました。3系のベータプレビューはその前提を外しています。Reactを使わず、仮想DOMも使わず、ビルド時の暗黙的な変換にも頼らない構成へ、ゼロから作り直されました（Remix 3 Beta Preview Ditches React for a Web-Standards Full-Stack Framework — InfoQ）。
代わりに置かれたのがWeb標準です。サーバー側の入出力はNode独自の req / res ではなく、Fetch APIの標準的な Request / Response を扱います。UI側はフォークされたPreactを使い、コンポーネントは EventTarget のようなWebプラットフォームの基本要素の上に乗ります。
実務的に効くのはこの帰結です。同じコードがNode 22でもDenoでもBunでもエッジランタイムでも動くという状態になります。Node固有のAPIに依存していないので、実行環境を変えるときの書き換えが要らない。ホスティング先を数年おきに見直す会社にとっては、これは費用に直結する性質です。
もうひとつは書き方の話です。Reactのフックのルール、依存配列、再レンダリングの理解——これらは学習コストとバグの温床を兼ねていました。3系では通常のJavaScriptの制御フローに戻ります。開発者の生産性の議論としては歓迎されている変更です。
「Reactで作ります」が答えにならなくなった理由
ここで発注側の話に移ります。Remix 3の技術的な良し悪しは、正直なところ多くの発注者にとって関心の対象ではありません。効いてくるのは別の側面です。
Reactは長らく「無難な選択」でした。人が採用しやすく、ライブラリが揃い、5年後も誰かが保守できる。この安心感を根拠に、技術選定の議論を省略できたわけです。ところが、Reactの上に作られた有力なフレームワークが、Reactから降りるという選択をした。この事実は、無難さの根拠そのものを少し揺らします。
誤解しないでほしいのは、Reactが終わるという話ではないことです。採用の裾野はまったく縮んでいません。変わったのは「Reactを選んでおけば技術選定を考えなくていい」という省略が効かなくなったことです。フレームワークの世代交代のときに、自社のサイトがどちら側に取り残されるのかを、発注の時点で確認しておく必要が出てきました。
技術スタックを発注者としてどう評価するかという論点は小規模案件の技術スタック評価で整理しています。あわせて読むと、今回の出来事が「例外的な事件」ではなく定期的に起きる種類のものだと分かるはずです。
既存のRemix 2案件は、どこへ行くのか
すでにRemixで作ったサイトやアプリを持っている会社には、具体的な影響があります。
Remix 2から3への移行は、素直な道ではありません。 バージョンアップというより、別のフレームワークへの移行に近い作業量になります。Remix側が示している現実的な選択肢は、React Router 7です。Reactを維持したまま互換性を保ち、Remixの価値だった機能を引き継ぐ位置づけになっています。
つまり、本番運用しているRemix 2のアプリを持つ会社が取れる道は2つです。React Router 7へ寄せてReactの世界に留まるか、Remix 3への実質的な作り直しを投資として判断するか。前者のほうが安く済みますが、Remix 3の恩恵は受けません。
判断の材料になるのは、そのアプリを今後どれだけいじるかです。年に数回の軽微な修正しか発生しないなら、React Router 7へ寄せて延命するほうが合理的です。逆に機能追加を継続的に予定しているなら、開発体験の差が積み上がるので作り直しの回収余地があります。フレームワークの新しさではなく、今後の改修頻度で決める問題として扱うのが確実です。
見積もりを見るときに聞く3つの質問
発注側がフレームワークの中身を評価する必要はありません。代わりに、提案してきた会社に次の3つを聞いてください。回答の具体性で、その提案が検討の産物か習慣の産物かが分かります。
ひとつ、「そのフレームワークのメジャーバージョンアップで、過去に破壊的変更はありましたか」。あったとして構いません。あったのに「特にありません」と答える会社は、追っていないということです。
ふたつ、「5年後に同じ構成で改修を頼めますか。頼めない場合、何が起きますか」。ここで移行パスの話が出てくるかどうかが分かれ目です。今回のRemixのように、公式が移行先を示すケースもあります。
みっつ、「その構成を選んだ理由は、この案件の要件のどれに紐づいていますか」。「社内で慣れているから」は立派な理由です。むしろ隠されるほうが困ります。要件と紐づかない技術名が並んでいる提案書は、あとから理由なく構成が変わることがあります。
引き継ぎと保守の観点はレガシー化したコーポレートサイトの引き継ぎでも扱いました。作った会社と別の会社が改修する場面では、フレームワークの選択がそのまま費用になって現れます。
大半のコーポレートサイトには、直接は関係ない
正直に書くと、この話が直接効く案件はそれほど多くありません。会社案内・サービス紹介・お知らせで構成される一般的なコーポレートサイトなら、そもそもフルスタックフレームワークを持ち出す必要がありません。静的サイト生成で足りる領域です。この判断軸はAstro 7でコーポレートサイトの土台を作るで書いた通りです。
Remix 3の話が効くのは、ログインがあり、データを書き込み、業務の一部がそのアプリで回っているような案件です。会員向けのポータル、予約や申込のシステム、社内向けの業務画面。この層を発注する予定があるなら、技術選定を「お任せします」で通さないほうがいいという話になります。
提案書の技術欄に、理由が書かれているか
次にサイトやWebアプリの見積もりを受け取ったら、技術構成の欄になぜそれを選んだかの理由が書かれているかを見てください。書かれていなければ聞く。それだけで、5年後に「この構成では改修できません」と言われる確率は下がります。
刷新の要件から技術構成まで含めて相談したい、既存サイトが今後どれくらい保守できる状態にあるか見てほしい——そうしたご相談は、グリームハブのHP制作・リニューアル相談で承っています。要件によって最適な構成は変わるため、個別にお見積りします。お問い合わせからご相談ください。
