この記事は CyberAgent Developers Advent Calendar 2025 7日目の記事です。
1. はじめに
こんにちは。株式会社シロクで N organic など中心に展開する「シロクオンラインショップ」の開発・運用を行っている小野寺と申します。
今回は、シロクオンラインショップで進めている Next.js をベースにしたモダンフロントエンド導入計画について、
背景から技術選定、移行戦略、運用上の工夫、取り組みを通して感じたを紹介していこうと思います。
2. なぜモダンフロントエンド導入を行う決定をしたのか
シロクオンラインショップの開発チームは約10名ほどで、
フロント専任・バックエンド専任に分かれず、フルスタックに開発を行い、
メンバーが施策単位で幅広く実装を担当する体制を取っています。
この柔軟な体制はプロダクトの高速な改善に強く貢献しており、
月に数百リリースを可能とする高頻度リリースを続けてきました。
一方で、フロントエンドで長く運用されてきた
Rails の VIew に React + ViewComponent を配置して運用するモノリスの構成は徐々に複雑性が増し、
次のような課題が見えてきました。
-
Rails と React 双方にロジックが散らばり、整合性維持が難しい
-
ViewComponent や部分テンプレートによって責務が曖昧になる
-
React の型が Rails 側に伝わらず、思わぬ不具合につながる
-
AI 開発との相性が悪く、コード生成が破綻しやすい構成になってしまいがち
そうした中で、
お客様向け機能の刷新がスタートし、新しい技術を少しずつ導入しやすいタイミングが訪れた
こともあり、フロントエンドのアーキテクチャを見直し、フロントエンド/バックエンドを分離する意思決定をいたしました。
3. Next.js 導入の目的
今回の目的は、一言でいえば AI 開発が加速する中で開発者体験とコード品質、組織としての再現性を長期的に維持すること でした。
特に重要視していたのは次の4点です。
-
責務の明確化
→ Rails とフロントの境界を再整理し、コード理解コストを下げる -
再現性ある実装フロー
→ 誰が書いても同じ品質になる構造をつくる -
AI を前提とした開発体験の強化
→ 責務や構造が明確であればあるほど、AI の提案精度が上がる -
長期運用しやすいアーキテクチャ基盤の構築
→ 将来の技術選択の自由度を確保しながら進化させたい
こうした理由から、Next.js を中心とした新しいフロント基盤を設計することにしました。
4. 採用したアーキテクチャと技術選定の思想
Next.js は非常にパワフルなフレームワークである一方、
App Router・Server Components・データフェッチなど、
扱うべき概念が多岐にわたります。
そこでシロクショップのフロントエンドでは、Next.js に対して 無理をしない Next.js を運用する 方針を採用しました。
つまり、組織体制に合わせて最適化した使い方をする という意味です。
SSR/CSR をあまり意識しない構成にする
Next.js の複雑な概念をチーム全員が一度に理解するのは難しいため、
責務を明確にわけることで認知コストを抑えています。
-
app 配下
-
ルーティング（App Router）のみに責務を集中させる層
-
-
src 配下
-
React コンポーネントとしてシンプルに書ける層
- SSR/CSR の使い分けは任意
-
この分離によって、
「どこで SSR を意識すればよいか」「Next の概念をどこまで学ぶべきか」が
明確になり、実装の迷いを大幅に減らすことができました。
Feature-Sliced Design の採用
Feature-Sliced Design （以下 FSD と表記します）を採用した理由は明確で、
誰が触っても同じ構造で実装できるという環境を作るためです。
-
責務ごとに自然とコードが整理される
-
増築しても破綻しにくい
-
AI がコードを提案する際の構造的前提が揃う
という点で、FSD は今回のリプレイス方針と非常に相性がよいと判断しました。
また、社内の知見のある方々と議論しながら
長期運用を見据えた現実的な運用方法を固めました。
この場で改めて感謝を述べさせていただきます。
5. Next.js 導入に向けた移行戦略
今回は、一度に全面リプレイスする方針ではなく、段階移行を行う方針を採用しました。
背景として、
-
組織文化としてスピードが求められる仮説検証型開発であること
-
既存を壊さずに安全に移行していきたいこと
-
新技術の概念理解に一定のコストがあること
という事情がありました。
導入判断には PoC の開発完遂を K点 として採用
新機能の一部を Next.js + FSD で実際に作ってみて、開発スピード・品質・運用しやすさを確認しました。
結果として、
-
SSR/CSR の境界が明確で混乱がなかった
-
FSD によって実装のばらつきが減った
-
AI 開発との相性が高く、Rails × React + ViewComponent と比べ、5倍以上のスピードで作れた（※体感）
と、確かな成功体験を得ることができました。
また、シロク内の別ブランドである FAS でも Next.js を使用している実績があり、
社内知見を活用できたことも移行の大きな後押しとなりました。
最終的な切り替えはインフラ側で行う
Rails と Next.js はしばらく共存させ、十分に Next.js 側へ開発が完了した段階で
インフラ側でトラフィックを切り替える 方針を採用しました。
これによって安全でリスクの少ない移行を行うことが可能となります。
6. スムーズに移行するために工夫したポイント
今回のリプレイスをスムーズに進めるうえでいくつかの工夫を行いました。
- FSD によって責務を明確にし、迷わない構造をつくった
- SSR/CSR の境界を App Router と FSD で分けた
- 判断基準をドキュメント化し、概念の言語化を徹底した
特に、概念を言語化するために レビューをあえて属人化した のは効果的でした。
フロントエンド理解の深いメンバーがレビューを集中的に担当し、
レビューの中で Next.js の概念や FSD の意図を丁寧に説明し、
それをドキュメントとして整備していきました。
こうした作業が「Next.js の新たな学習コストの懸念を、チーム全体で解消していく」という役割を果たし、移行をスムーズにしました。
7. 今後の方針について
今後もリプレイスは継続していく予定なのですが、
無理なく新陳代謝が必要になった部分から確実に Next.js に寄せていく方針を採用 していきたいと考えております。
犠牲的アーキテクチャの思想に基づき、
技術を無理に永続させようとせず、
必要な部分を必要なときに更新していく柔軟な戦略を取って行く予定です。
開発において重要なことは、お客様に価値のあるリリースを行うこと です。
新機能は Next.js で作り、既存機能は刷新タイミングに合わせて自然に移行することで、組織としても無理のない移行戦術を取っていきたいと考えております。
8. 今回の取り組みを通して感じていること
今回のシロクオンラインショップ Next.js 導入での最も大きな学びは、
技術そのものもそうですが、プロジェクトへの向き合い方について学びを得られたことが大きい です。
徹底的にプロジェクトに入り込み、説明責任を果たし続けることで、チームは前に進む力を得られる と強く感じる経験でした。
Next.js や FSD という新しい概念を扱うとき、
単に技術を導入するだけではプロジェクトは動きません。
-
なぜその技術が必要なのか
-
どんな価値を生むのか
-
どんな判断基準で運用するのか
- スケジュールも含めて導入可能なのか
こうした点を 自分自身が誰よりも理解し、言語化し、説明し続ける姿勢 が
プロジェクトを推進するエネルギーになりました。
そして何より、
諦めず、真摯に向き合い続けることで、
Next.js 導入という挑戦が着実に前へ進んでいくことを実感しました。
この姿勢は今回の経験に限らず、
プロダクト開発を進めるうえで普遍的に重要な考え方だと感じています。