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