こんにちは！株式会社Yoiiでソフトウェアエンジニアをしてます、吉本 亮介（よしもと りょうすけ）です。普段は弊社の資金調達プラットフォームであるYoii FuelのReactとGolangの開発・設計に従事しており、またチームリーダーとしてプロジェクトの進捗管理などをしております。
今回は弊社のコーポレートLPを、ノーコードツールから自社ホスティングに移行した背景について説明させていただきます！どういった背景で移行を決意したのか、また移行において採用した技術スタックについて同じようなことを検討している方の参考になれば幸いです。
1. なぜノーコードLPから移行を決意したのか
さて、改めてですが弊社のコーポレートLPはノーコードツールで構築していました。弊社の創業初期において、非エンジニアがクイックにLPを作成し公開するというフェーズにおいては非常に助けられていました。
お陰様で弊社の事業も伸びており、またお客様の導入事例やお役立ち記事などのコンテンツも充実してきました。しかし、少しずつですがLPのコンテンツ・ページ数増加に伴い下記の課題感が生じました。
- コード・CMS出力(エクスポート)ができないためコンテンツが充実すればするほど過度な依存となる
- コーディングエージェントによるLP開発高速化・自動化の恩恵を受けたいが、ソースコードが隠蔽されているためそれができない
- Diffチェックの機能がなく、毎回のリリースで差分の全量が確認できないのが怖い
- どうしてもサーバーサイドやインフラが隠蔽されているため、SEOを見据えたパフォーマンス最適化などに限界がある
- 開発環境がない
これらの中でも移行の決め手になったのが「１」と「２」です。
LPのコンテンツが順調に増え、ツールに対する依存はどんどん増加する。この状況下において、エクスポート機能がないことはどうしてもリスクになります。予期せぬ理由でサービス終了となり、急にLPが見れなくなるといったことが100%起きないとも断言できず、どうしてもLPを長期で運用していく上ではリスクと言わざるを得ないです。
そして、ノーコードツールはソースコードがブラックボックスです。もちろん非エンジニアがLPを柔軟に作ることができる優位性があるものの、現在はLLMを活用したVibe codingによりコードを直接修正してLPの編集を行うことも十分に可能となっており、この優位性が弱まっていると考えています。
これらのことから、弊社ではLP関連のシステムを内製化することに決めました。
2. 技術選定とシステム全体像
アプリケーション： Next.js(SSG)
- 今回は、Next.js 15のSSGによって静的LPを生成する方針を取りました。今後LPの機能を拡張するにあたって、ISR・SSRなどのサーバーサイド側での処理を行いたいとなった際も、Next.jsだけで完結することができるなど長期的な運用が可能であると判断しました。
- なお、最後まで「Astro」と比較して迷いましたが、以下の理由で最終的にNext.jsを採用することに意思決定しました。
- Astroの採用を優先するほどのパフォーマンス要件がなかった（Next.jsのSSGも十分パフォーマンスで優れています）
- Next.jsは経験者が多く、外部委託・採用で困らない・ユーザーコミュニティが強固で情報が多い
- LP上でのミニアプリの公開や機能拡張においてNext.jsは守備範囲が広い
インフラ・ホスティング：CloudFront + S3
- CloudFront + S3で完全静的にホスティングしています。Vercelも候補でしたが、依存するPaaSを増やすことは社内での管理上の煩雑さを生むと判断して、CloudFront + S3の構成を取ることにしました。CMSのコンテンツ頻度なども多くて週に1回程度なので、Next.jsのSSGで出力された静的コンテンツをS3にSyncする構成にしています。
ヘッドレスCMS：Strapi(Self hosting)
- CMSはOSSから採用することを第一に検討し、以下の内容を要件として考えていました。
- コンテンツ変更をトリガーにWebhookを実行し、Github Actionsを走らせることができる
- Next.js側で型安全にAPIリクエストができる
- 開発者コミュニティがしっかりしており、拡張機能が充実している
- 最低限の権限付与のバリエーションがあり、安全にコンテンツ管理ができる。また、複雑な権限管理が必要となった場合もその実現方法がある
これらを満たすOSSとしてStrapiが相応しいと判断し、採用することにしました。
- クラウドサービス型であれば日本ではmicroCMSが有名だと思いますが、弊社は多国籍組織であるために日本語ドキュメント・サポートが充実していることがあまりメリットにならなかったことと、メンバー数・API数の増加に伴い課金が増えていく料金体系が長期的な運用において負担になることから採用を見送りました。もちろん、前提としてできる限りのベンダーロックインを避けたい、というのもあります。
- またStrapiについては開発者コミュニティが強固であり、プラグインが充実していることから様々な機能拡張を採用できるところが魅力的でした。あくまで1つの具体例ですが、公式プラグインでOpenAPIスキーマを生成することができ、それを利用してNext.js側で型安全にデータフェッチをすることが簡単に実現できます！(公式以外にも充実したプラグインが存在します)。
3. 移行前後の比較
パフォーマンス
以下の画像の通り、Performanceにおいて大きな改善を行うことができました(弊社LPのほとんどのユーザーがDesktopからのアクセスです)！
Before
After
ノーコードツールはページ描画のためのビルド方法を調整することは多くの場合できません。弊社が採用していたツールのケースですと、Vue3のCSRバンドルのJS実行と、それに伴うレンダリング処理がヘヴィであることがパフォーマンススコアの低下を生んでいたと思われます。
このことは実際にChrome DevToolsのパフォーマンスタブを見てみることでも分かります。移行前のRun microtasksというアクティビティを見てください。
Run microtasks
Promiseチェーンや async/await による処理に該当します。Vueの仮想DOM更新などはここに含まれるでしょう。CSRの特徴的な挙動であり、どうしてもこの処理が多くなります。
一方で、以下が移行後のパフォーマンス測定結果です。
いくつかの指標で改善が確認できますが、Run microtasksの改善は顕著ですね(313.6ms => 34.4ms)
これはSSGでの場合初期DOMはすでにサーバーサイドで完成済みで、Client Componentでのハイドレーション部分のみに処理対象が限定されるからだと考えます。
開発フローなど
課題点に挙げた開発フロー関連の課題点は全て解消されました。コード差分の確認ができ、開発環境で動作・見た目をリリース前に確認することもできるようになりました。
また、これは弊社の当時の運用体制に問題があったのですが、ノーコードツール上で似たようなコンポーネントが複数バラバラに定義されておりUIに一貫性がないことが問題だったのですが、こちらも今回の移行に伴い解消することができました。
4. 今後やりたいこと
まず VRT(Visual Regression Test) の導入による外観の変化を自動検出ができる運用にしたいと考えています。スケジュール最優先の運用だったため、ローンチ前には対応できていませんでした。移行に伴いコンポーネント駆動によるLP構築ができているため、1つのコンポーネント修正が多くのページに影響します。これらの差分を検知するため、自動可視化はLP運用を安全に進める上では非常に重要です。
また、SEO・LLMOによる強化も優先度を上げて行っていきたいところです。とにかくLP関連のスタックが内製化されたことによって今後様々な施策を打てるようになったことは間違いないので、弊社マーケティング担当と協力してより改善施策を打っていきたいと考えています。
5. 最後に
株式会社Yoiiではマルチスタックエンジニア・データエンジニアを募集しております！
弊社はいわゆるSaaSのプロダクト開発や今回紹介したようなLP関連のリニューアル施策・最適化だけに留まらず、財務データの査定を行う上での基盤となるデータパイプライン・DWHの最適化などの領域においても活躍のフィールドがあります。様々なことに挑戦でき、かつ多国籍なメンバーが活躍しているというユニークな組織だと思いますので、ぜひ興味がある方は爆速になった弊社HPに目を通していただければと思います！
Discussion