企業向けSaaSを比較・紹介するメディアを、読者向けの公開サイト、運営会社の社内管理画面、掲載企業向けの管理画面という多層構成で開発しています。検索流入を支える公開サイトはフレームワークを使わない既存のPHPのまま残し、API経由で新しい管理側と連携させることで、全面的な書き換えに伴うリスクを避けました。二つの管理画面はLaravelとInertia、React、TypeScriptで構築し、同じMySQLを共有。役目を終えつつあった旧APIサーバーは、移行対象を一覧化した上で統合と廃止を進めています。投稿のモデレーション、レポートの要約、資料の自動生成といったLLMを使う処理はサービス層に独立して実装し、アクセス解析のAPIからデータを取り込む連携も行っています。
- 集客の源泉を守りながら刷新
- 検索流入に直結する公開サイトのURLや表示を変えず、裏側の管理機能から先に新基盤へ移すことで、メディア事業の売上を止めずに技術の更新を進めています。
- 廃止の対象を見える化
- 旧APIサーバーの各機能を移行対象として一覧化し、統合と廃止の進み具合を追える状態にしたことで、並行稼働の期間を計画的に短縮できます。
- LLM処理を再利用できる形で実装
- モデレーション、要約、資料生成をそれぞれ独立したサービスとして実装し、画面からもバッチからも同じ処理を呼べるようにして、運営業務の自動化範囲を広げやすくしました。
- 旧公開サイトはAPI経由で接続
- フレームワークを使わない既存PHPの公開サイトを書き換えず、新しい管理側とはAPIでつなぐ形にしました。表示側の改修を伴わずに、裏側のデータ管理だけを新基盤へ寄せられる構成です。
- 二つの管理画面で同一DBを共有
- 運営会社向けと掲載企業向けの管理画面をLaravelとInertia、Reactで作り、同じMySQLを参照する構成にしました。誰がどのデータを見られるかは画面とAPIの双方で判定しています。
- 解析データの取り込み経路
- アクセス解析のAPIからデータを取り込む連携を組み込み、掲載企業へ示すレポートの数値を管理側で扱えるようにしました。表示のたびに外部へ問い合わせない形にしています。
この種のシステムで検討する論点（想定例）
以下は同種の案件で一般的に検討する内容の整理であり、上記事例の詳細を示すものではありません。
メディア事業の収益構造と刷新の順序
比較メディアの収益は、検索からの流入と、そこから生まれる問い合わせや資料請求といったリードによって成り立ちます。公開サイトの変更は流入に影響するため最後に回し、リードの処理や掲載企業への提供価値に関わる管理側から刷新する順序を採ると、売上を守りながら運営の効率を上げられます。刷新の効果は、リード一件あたりの処理コストや掲載企業の継続率のような指標で測れるようにしておくと、次の投資判断がしやすくなります。
掲載企業向けの管理画面をプロダクトとして育てる
社内向けの管理画面と掲載企業向けの管理画面を持つ場合、後者はメディアの「顧客」が直接触れるプロダクトです。掲載内容の編集やリードの確認、レポートの閲覧といった機能を段階的に充実させ、掲載企業が自分たちで成果を確認できる状態にすると、掲載の継続と単価の向上につながります。一つのデータベースを共用しながらも、どの企業がどのデータを見られるかの権限を画面とAPIの両方で検証する設計が、この方向へ進むための前提になります。
関連するサービス
関連するインサイト
- レガシーコードのモダナイズ — 全面リプレイスか段階移行か古くなったシステムを作り直すべきか、少しずつ置き換えるべきか。全面リプレイスと段階移行の比較、ストラングラーパターン、データ移行、テストのないコードへの向き合い方を経営者向けに整理します。
- Webサービスのマネタイズモデル比較 — サブスク・従量・手数料・広告サブスクリプション、従量課金、手数料、広告、フリーミアムの5つのマネタイズモデルを、向くサービス・収益の安定性・運用負担・注意点で比較し、LTVとチャーンとの関係、組み合わせや切り替え時の注意点まで整理します。
- 広告運用の基本 — 計測設計とLTVから逆算する予算の考え方広告運用を始める前に整えるべき計測設計（コンバージョン定義・タグ・同意管理）と、LTVとCACの関係から予算上限を導く考え方、媒体とクリエイティブの検証、プロダクト改善との連動、見るべき指標の絞り方を解説します。
他の開発事例
監修: フィリット・コンサルティング株式会社公開