「サイトが遅い」「WordPressのアップデートに追われる」「セキュリティ脆弱性の通知が怖い」——コーポレートサイトを抱える多くの企業が、こうした課題を慢性的に抱えています。グリームハブでは自社サイトの再構築にあたって Jamstack アーキテクチャとヘッドレスCMSを採用し、表示速度を約3倍に改善しながら運用コストを半減させることに成功しました。本記事ではその背景・設計判断・具体的な数値をもとに、実践的な知見を共有します。
なぜ WordPress をやめたのか
リニューアル前のサイトは WordPress で構築されていました。コンテンツ更新の自由度は高く、当初はプラグインエコシステムの豊かさが魅力でしたが、運用を続けるうちにいくつかの構造的な問題が表面化してきました。
表示速度の劣化。WordPress はリクエストのたびにPHP処理→DBクエリ→HTML生成というサイクルを繰り返します。プラグインが増えるにつれてこの処理が重くなり、LCP（Largest Contentful Paint）は常時 4.8 秒前後を記録していました。Google の基準では 2.5 秒以内が「Good」とされており、これは明らかにSEO・UXの両面で不利な状態です。
保守コストの増大。WordPress 本体・テーマ・プラグインのアップデートは頻繁に発生し、互換性確認・バックアップ・テスト環境での検証が毎月の定常業務になっていました。専任の開発者がいない状況では、このオーバーヘッドは無視できません。
セキュリティリスク。WordPress は世界のCMSシェアの約40%を占めるため、攻撃ターゲットになりやすい。マルウェア感染・ブルートフォース攻撃・プラグインの脆弱性——こうしたインシデントへの対応コストも潜在的なリスクとして存在していました。
Jamstack への移行を検討した理由は、これら3つの課題をアーキテクチャレベルで解消できると判断したからです。Jamstack の基本概念についてはこちらの記事で詳しく解説しているので、概念から理解したい方はそちらをご参照ください。
採用したスタック構成
移行後のスタック構成は以下のとおりです。
| レイヤー | 採用技術 | 選定理由 |
|---|---|---|
| フレームワーク | Astro | 島アーキテクチャによるゼロJS原則、ビルド速度 |
| ヘッドレスCMS | microCMS | 日本語UI・APIファースト設計・サポート品質 |
| ホスティング | Google Cloud Storage + CDN | 静的ファイル配信、グローバルエッジ |
| CI/CD | Cloud Build | コード変更→ビルド→デプロイの自動化 |
Astro を選んだ理由は「デフォルトでJavaScriptを配信しない」設計思想にあります。React や Vue では状態管理やインタラクティブなコンポーネントのために大量のJSバンドルが生成されますが、Astro は静的HTMLを出力し、インタラクティブ性が必要な箇所だけに「アイランド」として最小限のJSを渡します。これがLCP改善に直接的に効いています。
microCMS を選んだ理由は運用者視点の使いやすさです。国産のヘッドレスCMSであり、管理画面は日本語、サポートも日本語で受けられる。API設計が明快で、Astro との統合も公式チュートリアルが整備されています。2025年末時点で導入企業数は13,000社を超えており、エンタープライズ採用実績も豊富です。
Astro と microCMS の具体的な統合手順は別記事で実装ガイドを公開していますので、実装フェーズに入る際にあわせてご参照ください。
設計フェーズで決めた3つの原則
1. コンテンツとプレゼンテーションの完全分離
microCMS はコンテンツをAPIで提供するだけです。「どう見せるか」はすべてフロントエンド（Astro）が担います。この分離により、デザインリニューアルやフレームワーク変更が将来発生しても、コンテンツ資産（記事・画像・メタデータ）はそのまま引き継げます。WordPressではテーマにコンテンツが強く依存するため、デザイン変更のたびにコンテンツ移行リスクが発生していました。
2. ビルド時静的化の徹底
コンテンツが更新されるたびにビルドを走らせ、すべてのページを静的HTMLとして書き出します。ユーザーのリクエスト時にはCDNキャッシュから即時配信されるため、サーバーサイドの処理は一切発生しません。WordPress 時代と比べてTTFB（Time to First Byte）が劇的に改善されました。
3. 段階的移行によるリスク最小化
一気にすべてを移行するのではなく、「新規コンテンツは新スタックで、既存コンテンツは順次移行」という段階的アプローチを取りました。これにより移行作業中もサイトをダウンさせることなく、チームが新システムに慣れながら確認・修正できる期間を設けました。
数値で見る改善効果
移行から3ヶ月後に測定した主要指標の比較です。
| 指標 | 移行前（WordPress） | 移行後（Jamstack） | 改善率 |
|---|---|---|---|
| LCP（モバイル） | 4.8 秒 | 1.5 秒 | 約3.2倍高速化 |
| TTFB | 1.2 秒 | 0.08 秒 | 約15倍高速化 |
| PageSpeed Insights スコア | 48（モバイル） | 94（モバイル） | +46ポイント |
| 月額ホスティング費用 | 約15,000円 | 約3,000円 | 約80%削減 |
| 月次保守工数 | 約12時間 | 約2時間 | 約83%削減 |
| セキュリティインシデント対応 | 年3〜4件 | 0件 | — |
LCP が 4.8 秒から 1.5 秒になったことで、Google の Core Web Vitals 評価が「Poor」から「Good」に転換しました。これはSEO評価の直接的な改善につながり、オーガニック流入が移行後6ヶ月で約35%増加しました。
ホスティングコストの削減は、動的サーバー（VPS）から静的ファイル配信（Cloud Storage）への転換によるものです。静的ファイルのストレージ・転送コストは同規模のVPS維持費に比べて大幅に安価で、スパイクアクセス時もCDNがスケールするため追加費用の心配もありません。
運用フローの変化
Jamstack 移行後に最も変わったのは「コンテンツ更新のフロー」です。
移行前: 担当者が WordPress 管理画面にログイン → 投稿・編集 → プレビュー確認 → 公開（即時反映）
移行後: 担当者が microCMS 管理画面で編集 → 下書き保存 → プレビューURL で確認 → 公開ボタン → Webhook → Cloud Build → 静的ファイル生成 → CDN配信（2〜3分で反映）
公開まで2〜3分のビルド時間が発生するため、「今すぐ反映したい」というケースでは体感的な待ち時間が生じます。ただし、「意図しない公開ミス」も防げるという副次効果があります。ビルドのタイムラグを考慮した上でコンテンツカレンダーを運用するようになったことで、公開フローが整理されました。
技術担当者が不要な更新作業（WordPress プラグイン更新・セキュリティパッチ適用・バックアップ確認）から解放されたことで、その工数を機能開発・パフォーマンス改善・SEO施策に充てられるようになりました。
Jamstack 移行で注意すべき落とし穴
すべてのケースで Jamstack が最適解になるわけではありません。移行前に把握しておくべき注意点を整理します。
コンテンツ量が多い場合のビルド時間。ページ数が数千〜数万規模になるとビルドに時間がかかります。Astro の場合は増分ビルド（Incremental Build）の仕組みを活用するか、ヘッドレスCMS側のWebhookで変更のあったページのみ再ビルドする設計が必要です。
動的機能はサーバーレス関数で補完。ログイン・フォーム送信・検索など動的処理が必要な部分は、Vercel Functions・Cloud Functions などのサーバーレス関数で実装します。完全に静的にできる範囲を見極めて設計することが重要です。
CMS の API 制限に注意。ヘッドレスCMSの無料・低価格プランにはAPI呼び出し数の上限があります。ビルド時のコンテンツ取得 + プレビュー確認 + 本番確認で、予想より早く上限に達することがあります。microCMS であれば適切なプランを選定し、CDNキャッシュを有効活用することで呼び出しコストを抑えられます。
まとめ
Jamstack × microCMS への移行は、表示速度・セキュリティ・運用コストの3軸すべてで改善をもたらす、現時点でもっとも合理的なWebサイト構築アプローチの一つです。特に「WordPress の保守に疲れた」「サイト表示速度がSEOの足を引っ張っている」と感じているなら、移行を検討する価値は十分あります。
重要なのは、段階的な移行設計と、静的化できる範囲・できない範囲の見極めです。すべてを一気に置き換えようとせず、新スタックのメリットを最大化しながらリスクを最小化する設計判断が成否を分けます。
グリームハブでは、Jamstack を使ったコーポレートサイト・メディアサイトの構築・リニューアル支援を行っています。「自社サイトをリニューアルしたい」「WordPress から移行を検討している」という方はお気軽にご相談ください。
