ブランドごとに分かれて作られてきた複数系統のサイトと、それらに共通するアカウント管理や運営用の画面を、利用者向けのNext.jsアプリと管理画面アプリに集約した基盤です。リクエストのドメインを判定してブランドごとの画面へ内部的に振り分ける仕組みにより、ブランドごとに異なるデザインを保ちながら、デプロイは一つで済みます。色や余白などのデザイントークンは独立したパッケージとして管理し、サーバー側（Laravel）で定義した列挙型はTypeScriptの型として自動生成。管理画面はバックエンドが公開するスキーマを読み取って一覧・編集画面を動的に描画する汎用型です。
- ドメイン判定による単一デプロイ運用
- アクセスされたドメインに応じてブランド別の画面構成へ内部で振り分けます。ブランドごとにアプリを分ける方式は独立性が高い反面、共通機能の修正を系統の数だけ繰り返すことになり、その手間はブランドが増えるほど積み上がります。運用の負荷を一定に保つ側を選んだ判断です。
- スキーマから描画する汎用管理画面
- サーバー側のリソース定義を読み取って一覧や編集の画面を組み立てる方式にしました。管理画面は利用者の目に触れない一方、作り込むほど費用がかさむ領域です。まず汎用の仕組みで運用を始め、現場で使う回数が多いと分かった業務だけを専用画面として作る順序にしています。
- 型の自動生成で食い違いを排除
- サーバー側の列挙型からTypeScriptの型を自動生成し、フロントとサーバーの間で値の定義がずれることを仕組みで防いでいます。
- 見た目の差分をトークンで管理
- ブランドごとの色や余白をコードとして切り出したパッケージで管理し、デザインの変更をエンジニアとデザイナーが同じ基準で扱えるようにしました。
- アプリの数を利用者の種類で決める
- 系統ごとにアプリを分けず、利用者向けと運営者向けという閲覧者の違いだけで分割し、Turborepoとpnpmで依存を管理しています。分割の単位をブランドや機能に置くと、系統が増減するたびに構成を組み替えることになります。変わりにくい軸で切ることが、長く使う基盤の条件です。
この種のシステムで検討する論点（想定例）
以下は同種の案件で一般的に検討する内容の整理であり、上記事例の詳細を示すものではありません。
ブランドを増やす戦略と技術基盤の整合
複数のブランドやメディアを展開する事業では、新ブランドの立ち上げ速度が競争力に直結します。アカウント、決済、管理機能といった共通の土台が同じで、見た目と内容だけが違うのであれば、一つのアプリの中でドメイン別に画面を出し分ける基盤を先に作っておくと、新ブランドの追加はデザインとコンテンツの準備だけで済みます。一方で、更新の頻度や担当する組織が大きく異なるサービスまで同じ基盤に載せると、一つの変更が全体に波及するため、統合の範囲は組織構造と合わせて決める必要があります。
管理画面への投資を最小にして事業に集中する
管理画面は利用者の目に触れないため投資を惜しみがちですが、作り込むほど開発費がかさむ領域でもあります。データ定義から自動で画面を生成する汎用の仕組みで運用を始め、使う回数が多く手順の定まった業務だけを後から専用画面として作り込む順序を採ると、初期費用を抑えながら実際の現場で価値が確認できた画面へ投資を集中できます。承認の流れや複数のデータをまたぐ操作は汎用画面に向かないため、どこまでを汎用に任せるかの線引きを運用開始後に見直す前提で始めます。
使った技術・扱った領域
- Next.js
- React
- TypeScript
- Turborepo
- pnpm
- shadcn/ui
- Tailwind CSS
- Storybook
- Playwright
- Laravel
- MySQL
- ECS
関連するサービス
関連するインサイト
- シリーズB以降の構造の変え方単一プロダクトから複数ラインへ広げる段階で、何を共通の土台に移し、何を各ラインに残すか。早すぎる共通化が招く停滞と、共通化を始める判断のタイミング、組織との対応関係を整理します。
- クラウドインフラコストの圧縮 — 見直しの順番と落とし穴クラウドの利用料が事業の成長より速く増えているとき、どこから手を付けるべきか。可視化から監視の継続運用までの手順と、可用性や開発速度を損なう落とし穴を経営者向けに整理します。
- 少人数開発チームの体制設計 — 役割・採用・外部パートナーの使い分け小さなチームでプロダクトを作り続けるために必要な役割と兼務の考え方、採用と外部パートナーの使い分け、CI/CDや生成AIで人手を補う仕組みを、事業フェーズの変化とあわせて整理します。
他の開発事例
監修: フィリット・コンサルティング株式会社公開