複数のサービスサイトと管理画面を、Next.js App Routerのアプリ1つと管理画面アプリ1つに集約しました。Hostヘッダを見てproxyがドメインごとのルートセグメントへrewriteすることで、ブランド別のデザインを維持したまま単一デプロイで運用しています。デザイントークンは独立パッケージ化し、バックエンド（Laravel）のEnumはTypeScriptへ自動生成。管理画面はスキーマ駆動の汎用CRUDです。
- Hostベースrewriteによる複数ブランド配信
- Hostヘッダでドメインを判定し、proxyがブランドごとのルートセグメントへrewriteすることで、1アプリ1デプロイのまま複数ブランドを配信しています。
- スキーマ駆動の汎用管理画面
- バックエンドが公開するリソース定義スキーマを管理画面が読み取り、汎用のCRUD画面を動的に描画するため、リソース追加のたびに画面を作り込む必要がありません。
- Enumを型として自動生成
- バックエンドのEnumをTypeScriptの型として自動生成し、フロントとバック間での値の乖離を排除しています。
- デザイントークンの独立パッケージ化
- 色・余白などのデザイントークンを独立パッケージとして切り出し、ブランドごとの見た目をコードで管理しています。
- 複数系統を2アプリに集約
- 診断・メディア・コミュニティ・法人向け・アカウント管理・公式サイト・管理画面の複数系統を、Next.jsアプリ1つと管理画面アプリ1つに集約しました。系統ごとにアプリを立てず、共通基盤の重複を避けています。
この種のシステムで検討する論点（想定例）
以下は同種の案件で一般的に検討する内容の整理であり、上記事例の詳細を示すものではありません。
想定例: 複数サイトを1つにまとめる判断基準
ブランドやドメインが増えるたびに別のアプリを立てると、認証・共通部品・デプロイ手順がそれぞれに複製され、修正の漏れが起きやすくなります。共通する基盤（アカウント、決済、管理機能）が多く、見た目だけが違うのであれば、1つのアプリでドメインごとに振り分ける方が保守は楽になります。逆に、リリース頻度や担当チームが大きく異なるサイトを無理にまとめると、1つの変更が全ブランドの再デプロイを伴い、かえって身動きが取れなくなる点には注意が必要です。
想定例: 汎用管理画面と作り込み画面の使い分け
スキーマから自動生成する汎用CRUD画面は、マスタ管理のような単純な一覧・編集には非常に効率的です。一方、承認フローや複数テーブルにまたがる操作、業務の順序が決まっている画面は、汎用画面では使いにくくなります。「まず汎用画面で運用を始め、操作頻度が高く手順が固まった業務から作り込む」という順序にすると、初期の開発範囲を抑えながら、現場が本当に必要とする画面に投資できます。
関連するサービス
関連する業種
関連する開発ガイド
- CMSの選び方 — 3つの方式の比較WordPress・MediaWiki・Wix などのクラウド型CMSを用途別に比較し、会社サイト・社内wiki・小規模ページなど目的に合ったCMSの選び方と、導入前に確認したい点を整理します。
- WordPressで作るか、自社開発するか — 判断基準Web サイトやシステムを WordPress で作るか、一から自社開発するか。要件の性質、更新頻度、拡張性、保守の観点から判断基準を整理し、比較表と組み合わせの選択肢も紹介します。
- 独自ドメインとSSL証明書の基礎 — 取得から更新まで独自ドメインの取得、DNS設定、SSL/TLS証明書の発行、サーバー設定、更新管理までの手順を順に解説します。失効したときに何が起こるかと、更新を止めないための管理方法も紹介します。
他の開発事例
監修: Unlogical Systems合同会社（杉並区・西荻窪）公開