Jamstackはやりすぎ？Next.jsに疲れたWeb制作者へ贈る「PHP × microCMS」で作る超軽量・静的JSONキャッシュ型サイトのすすめ

Jamstack や Next.js を提案してみたものの、ビルド、デプロイ、ライブラリ更新で疲れていませんか。WordPress のテーマ自作はできる。include で部品も分けたい。ただ、Node のビルドとインフラの費用が、案件の規模に乗らない。静的 HTML だけに戻るのも気が重い、という層向けです。

結論です。ビルド環境も Vercel も不要で、Next.js と同等の爆速・安全が保証される、とは言いません。 できるのは、使い慣れたレンタルサーバー上で、microCMS のデータを静的な JSON として置き、PHP で描画する構成です。表示のたびに外部 API を叩かない。更新は Webhook か Cron で JSON を書き直す。規模と予算、指定サーバーに対して、Next.js が過剰になっていないかの選択肢です。最先端を否定しません。

この記事では、フリーランスのWebディレクター兼エンジニアとして、PHP × microCMS の静的 JSON キャッシュを整理します。パフォーマンス 100 点、月額を劇的に削減、といった確認できない成果は出しません。Xserver やさくらの個別プランの仕様は、契約時点の公式案内で確認してください。

モダンフロントエンドの理想と、制作現場のリアル

Next.js の SSG / ISR は、表示と更新の分離としてよく効きます。このサイトも Next.js と microCMS で動かしています。問題は技術そのものより、小〜中規模の制作費に、環境構築と継続保守の工数が乗るかです。

コストの不一致として、Vercel や AWS の料金表をここで引用しません。起きやすいのは、CI、プレビュー、依存関係の更新、Node のバージョン固定に使う時間が、コーディングの見積を食うことです。Hobby プランの制限や商用利用の条件も、案件ごとに公式を参照してください。

引き継ぎの壁もあります。package.json とビルドコマンドがブラックボックスになると、インハウスや別の制作会社が「見た目だけ直したい」で止まります。担当者退職後にビルドが通らなくなった、という個別事故は、ここでは創作しません。起きうるのは、再現手順がリポジトリに残っていないことです。

サーバーの縛りも現実です。クライアント指定が Xserver やさくらの共用レンタルであることが多い。Node の常駐や Next の SSR / ISR を、そのプランが公式に対象にしているかは契約次第です。FTP で PHP を置く前提の案件では、Jamstack 一式を持ち込む方が、運用の説明コストになります。

だからといって、WordPress に戻るか

戻す理由はあります。管理画面に慣れている。テーマとプラグインで画面が揃う。ただし見えないコストもあります。コアとプラグインの追従、PHP バージョン、ログイン画面への攻撃面、MySQL のバックアップと引っ越し。終わらないメンテ、は程度の問題です。件数と権限設計で負荷は変わります。

ここで出す結論は、「PHP に全部戻す」ではありません。画面の分割とサーバー上の実行は PHP。記事の編集画面はヘッドレス CMS。 表示の自由さと、DB を自前で抱えない楽さの、いいとこ取りです。microCMS 以外のヘッドレスでも同じ手法は取れます。ここでは、API を JSON で取れる前提で書きます。

提案：PHP × microCMS の静的 JSON キャッシュ

View は PHP。include / require でヘッダー、カード、パンくずを分ける。MVC と名付ける必要はありません。テンプレートと、JSON を読む薄い読み込み層があれば足ります。

Model に相当するのは、リクエストのたびに叩く API ではなく、サーバー上の JSON ファイルです。公開・更新時、または Cron で、一覧と詳細を書き出す。PHP はファイルを読んで HTML を出す。

[microCMS]
    |  Webhook または Cron
    v
[サーバー上の JSON を更新]
    |
    v
[PHP が JSON を読んで描画]
    |
    v
[ブラウザへ HTML]

超高速表示、は約束しません。表示経路から外部 API の待ち時間を外せる、が要点です。ディスクと PHP の実行時間は残ります。CDN や画像最適化は別件です。

制作現場で効きやすい点

サーバーを選ばない、は言いすぎです。PHP が動き、ファイルが書け、Cron か Webhook 受信ができること。いつものレンタルサーバーで、FTP で上げて動かす案件には合いやすい。Node のビルドマシンは要りません。

表示速度は、リクエスト時に microCMS を叩かない点で、静的 HTML に近い部類です。Next.js の SSG と同等、とはここでは言いません。

引き継ぎは、PHP と JSON のパスが分かれば、ビルドツールより説明が短いことが多い。他の PHP エンジニアやコーダーが、マークアップだけ直せる余地は残しやすい。権限とディレクトリ設計は、案件ごとに書いて渡してください。

API 制限の完全回避、もしません。閲覧のたびに GET しないので、公開ページのヒットでは消費しにくい。再生成の頻度、件数、下書きプレビュー用の都度取得は、microCMS のプラン上限 に乗ります。無料・下位プランでも気にせず、は誤りです。書き出しを間引く、が実務です。

実装するときの3つの注意

1. 更新の遅れ：Webhook と Cron の両方

Cron だけだと、公開から JSON 更新まで最大で間隔分遅れます。microCMS は Webhook を出せます。公開・更新で書き出しスクリプトを走らせる。受信 URL の認証、HTTPS、失敗時の再試行は必須です。共用レンタルで外部からの POST が弾かれる設定もあるので、事前に通す。Webhook が落ちたときの保険が Cron です。押した瞬間に必ず再生成、はネットワーク次第です。

2. 件数増：一覧 JSON と詳細 JSON を分ける

1ファイルに本文まで全部入れると、一覧ページの読み込みとメモリが膨らみます。一覧は id、title、日付、サムネ URL、抜粋。詳細は detail_{id}.json。分割は銀の弾丸ではありません。画像の枚数と本文長の方が効くこともあります。

3. API 失敗時は古い JSON を残す

書き出しが 5xx やタイムアウトで落ちたとき、空ファイルで上書きすると画面が壊れます。一時ファイルに書いて、検証してからリネームする。失敗したら既存を触らない。真っ白を避ける、が最低ラインです。古い情報が残るので、管理画面に「最終成功時刻」を出すと運用が楽です。

技術過剰で止まった構成 vs JSON キャッシュで回した構成

悪い例：小規模に Next.js 一式を載せ、再現手順が残らない

担当退職後に脆弱性とビルドエラーで修正不能、は個別の実名事故としては書きません。起きやすいのは、Node のバージョン、環境変数、デプロイ権限が、納品物に含まれていないことです。クライアント側で直せない、はスキル不足だけでなく、手順の不在です。Next.js が悪い、ではありません。規模と引き継ぎ先に対して過剰だった、です。

良い例：レンタルサーバー上で JSON を置き、PHP で出す

爆速かつ低コスト、100 点、保守が格段に楽、はここでは言いません。確認できるのは、表示時に外部 API を待たないこと、いつものサーバーに載せられること、テンプレートが PHP であること。計測と月額は、その案件の領収書と PageSpeed の保存結果で出してください。

現場で使えるアーキテクチャ選定チェックシート

表の「向く」は保証ではありません。要件のメモです。

まとめ：最先端より、予算・サーバー・引き継ぎ

技術選定の基準は、新しいことではありません。クライアントの予算、指定サーバー、誰が直すかです。Next.js が合う案件は残します。WordPress が合う案件もあります。PHP × 静的 JSON は、その間の、泥くさい現実解の一つです。最強、とも言いません。

既存サイトのヘッドレス移行や、レンタルサーバー前提の構成の相談は、相談・お問い合わせからどうぞ。