BtoB SaaSの比較メディアを、公開サイト・社内管理画面・掲載企業向け管理画面の多層構成で開発しています。公開サイト（既存の素PHP）は維持したままAPI経由で管理側と連携し、全面書き換えのリスクを回避しました。管理画面2系統はLaravel＋Inertia＋React＋TypeScriptで構築し、同一のMySQLを共有。旧APIサーバーは移行対象を明記して統合・廃止しています。LLMによる投稿モデレーション、レポート要約、資料の自動生成をサービス層に実装し、アクセス解析APIとも連携しました。
- レガシー公開サイトをAPI境界で共存
- 公開サイトを作り直さず、API境界で新しい管理側と共存させることで、集客に直結する部分を止めずにモダナイズしています。
- 移行対象エンドポイントの一覧化
- 旧APIサーバーのエンドポイントを移行対象として一覧化し、統合・廃止の進捗を追える形にしました。
- LLM機能をサービスクラスとして独立実装
- 投稿モデレーション・レポート要約・資料自動生成をサービスクラスとして独立させ、バッチからも画面からも同じ処理を呼び出せるようにしています。
- 社内用と掲載企業用の管理画面を分離
- 社内向けと掲載企業向けで管理画面を2系統に分け、同一のMySQLを共有しつつ画面と権限を別立てにしました。立場ごとに見せる範囲と操作できる範囲を、画面の作りから分けています。
- 管理画面2系統で構成を統一
- 2系統の管理画面をどちらもLaravel＋Inertia＋React＋TypeScriptで構築し、画面部品と実装の作法を揃えました。片方で作った仕組みをもう片方へ持ち込みやすく、保守する技術も1組に収まります。
この種のシステムで検討する論点（想定例）
以下は同種の案件で一般的に検討する内容の整理であり、上記事例の詳細を示すものではありません。
想定例: 公開サイトを止めずに裏側を刷新する順序
検索流入で成り立つメディアでは、公開サイトのURLや表示を変えること自体が集客のリスクになります。まず管理側（入稿、掲載企業の情報、問い合わせの処理）を新しい基盤に移し、公開サイトはAPI経由でデータを受け取るだけの形にしておくと、見た目を変えずに内部を刷新できます。公開サイトの書き換えは、管理側が安定し、移行の効果を測れる状態になってから、ページ種別ごとに段階的に進めるのが安全です。
想定例: 管理画面が複数ある場合の権限とデータ共有
社内向けと掲載企業向けのように利用者の立場が異なる管理画面を持つ場合、同じデータベースを共有しつつ、見せてよい範囲と操作できる範囲を厳密に分ける必要があります。テーブル単位ではなく「どの企業のどのデータか」で絞り込む権限設計を最初に決め、画面側だけでなくAPI側でも必ず検証する二重の守りにします。ログイン方法や通知先も立場ごとに異なるため、共通化する部分と分ける部分の境界を仕様として残しておくと、後の機能追加で迷いません。
関連するサービス
関連する業種
関連する開発ガイド
- 他社が作ったシステムの引き継ぎ・保守を依頼するときのチェックリスト前の開発会社が作ったシステムの保守を別の会社に引き継ぐときの手順を、資料・アカウント・ソースコード・環境の棚卸しから調査、リスク整理、保守範囲の合意、移行まで、確認項目の表とともに解説します。
- WordPressで作るか、自社開発するか — 判断基準Web サイトやシステムを WordPress で作るか、一から自社開発するか。要件の性質、更新頻度、拡張性、保守の観点から判断基準を整理し、比較表と組み合わせの選択肢も紹介します。
- Webシステム開発でよくある失敗10選と回避策Webシステム開発で中小企業が陥りやすい10の失敗を、要件・契約と費用・進め方・運用の4つの場面に分けて想定例とともに紹介し、発注側が事前にできる回避策を解説します。
他の開発事例
監修: Unlogical Systems合同会社（杉並区・西荻窪）公開