WordPressの編集画面はそのままに、配信だけ静的にする — Jamstack構成

弊社のコーポレートサイトは、リニューアル前から静的サイトとして配信していました。

リニューアルの話をするとき、たいてい「今のサイトに問題があった」という書き出しになります。今回はそうではありませんでした。

【リニューアル前】
  エンジニアがHTMLを編集
      │ コミット / プッシュ
      ▼
  CI（GitHub Actions）でデプロイ
      │
      ▼
  オブジェクトストレージ ──▶ CDN ──▶ 閲覧者

この構成、配信という観点では何の問題もありません。

• 表示は速い（CDNから静的ファイルを返すだけ）
• 落ちない（動的処理がないので、落ちる部分がない）
• 攻撃対象がない（PHPもDBも管理画面も、公開側に存在しない）
• 安い（ストレージとCDN転送だけ）

つまりインフラ的にはすでに理想に近い状態でした。これを壊してまでWordPressを入れる理由は、普通に考えればありません。

問題は技術ではなく、運用の属人化でした。

コンテンツを1文字直すにも、こういう流れになります。

1. 担当者が「ここを直したい」と依頼する
2. エンジニアがHTMLを開いて編集する
3. コミットしてプッシュする
4. CIが走ってデプロイされる

誤字ひとつの修正にエンジニアの手が必要です。お知らせを1本出すのも、実績を1件追加するのも、同じ手順を踏みます。

これが積み重なると、じわじわと効いてきます。

• エンジニアが空くまで更新が止まる（リードタイムが人の予定に依存する）
• 軽微な修正でも依頼が必要になるため、更新の優先度が下がりやすい
• HTMLの構造を理解している人に依存する＝運用が特定の担当者に紐づく
• 情報が古いままになり、サイトが「作った時点の状態」で止まる

一番まずいのは3つ目と4つ目です。サイトが更新されない理由が「面倒だから」になっている状態は、コンテンツを持つ意味そのものを削っていきます。

やりたかったことは、はっきりしていました。

配信の速さ・堅牢さ・安さは1ミリも手放さず、 「誰でも更新できる」だけを足す。

案Cの弱点は明確で、WordPressを動かす分のコストが増えることです。配信はもともと安いので、増分はまるごとCMSの費用になります。

ここは設計で対処しました。CMSを常時起動しないという方針です。

前述のとおり、閲覧者はCDN上の静的ファイルを見ています。CMSが止まっていても公開サイトは何の影響も受けません。だから、編集しない時間帯は止めておけます。

実際の運用では、CMSは平日の日中しか起動していません。夜間も土日もCMSは停止していますが、サイトは24時間365日配信されています。

結果として、CMSのコストは常時起動のおよそ1/5の稼働時間分に収まりました。配信部分は以前と同じ（コーポレートサイト規模なら実質ごくわずかな額）なので、全体の増分を最小限に抑えたまま、編集体験を手に入れた形になります。

さらにコンテナ実行基盤にはフルマネージドのサービスを選び、OSやミドルウェアの面倒を見ない構成にしました。小規模サイトの運用で地味に効くのは、この「管理しなくていいものを増やす」効果です。

ポイントは「止められる設計にしたから、止めてコストを下げられた」という順番です。 CMSが配信経路に入っていたら、止めるという選択肢自体がありません。

「WordPressを入れた」と聞くと、まず脆弱性の心配をされると思います。

今回の構成では、公開ドメインにWordPressが存在しません。

• 公開側で動的処理がゼロ → プラグインの脆弱性を突く攻撃が成立しない
• 公開ドメインに管理画面が無い → ログイン試行の的にならない
• 公開側にDBが無い → SQLインジェクションの対象がない

CMS本体は別ドメインに置き、アクセス制限をかけています。そして公開HTMLにCMSのURLが残らないよう、書き出し時にすべて置換しています。外から見て「このサイトはWordPressで作られている」と分かる手がかりが出ません。

静的サイトのセキュリティ上の利点は、そのまま維持されています。

• 管理画面にログインする
• 記事を書く／実績を登録する
• 「更新」を押す
• 数分後に公開サイトに反映される

エンジニアへの依頼も、コミットも、デプロイの待ちもありません。内部的には、保存をきっかけに関係するページだけを再生成しています。記事を1本更新したら、その記事ページ・一覧ページ・トップページなど、その記事が載っている場所をまとめて焼き直す作り方です。

構成そのものは前述のとおりシンプルですが、実運用に載せるには押さえておくべき論点がいくつかあります。同じ構成を検討される方の参考になるよう、要点を共有します。

向いている

• すでに静的サイトを運用していて、更新がエンジニア依存になっている
• WordPressを使いたいが、速度・堅牢性・セキュリティを落としたくない
• コーポレート／採用／サービス紹介サイト、オウンドメディア
• 更新頻度が「1日数回」程度まで

向いていない（工夫が要る）

• 会員機能やログインが必要
• 検索・絞り込みをサーバー側で行いたい
• 在庫や価格がリアルタイムに変わるEC
• 秒単位の即時反映が必須

なお「一部だけ動的にしたい」（お問い合わせフォーム、簡単な検索など）は、その機能だけを独立させることで両立できます。今回もお問い合わせはサーバーレスの小さなAPIに切り出しており、サイト本体は静的なままです。

全部を静的にする必要はありません。動的である必要がある部分だけを動的にする、というのが現実的な設計です。

• 静的配信の速さ・堅牢さ・安さと、CMSの編集の楽さは、どちらかを選ぶものではない
• 「運用を楽にするだけ」なら普通のWordPressで足りる。 楽さと可用性を同時に取りにいくなら、配信とCMSを分ける設計になる
• 鍵は「配信経路を変えないこと」。CMSは配信に入れず、HTMLを作る側に置く
• CMSを配信経路から外すと、止められる。止められるからコスト増を抑えられる
• 静的化は構成を選んだ時点では終わらない。運用に乗せるところまでが設計範囲

配信基盤（オブジェクトストレージ + CDN）自体は、以前から同じものを使っていました。変わったのは、そこに編集の仕組みを”配信を汚さずに”接続したという一点です。

Jamstackは「速いサイトを作る手法」として語られがちですが、実際の価値は運用と可用性を同じ構成の上で両立できることにあると考えています。

---

Bee2Bでは、JAMstack構成による高速・高可用なWebサイト構築に力を入れています。

この構成の最大の強みは可用性です。閲覧者に返しているのは事前に書き出されたHTMLファイルだけで、公開側にPHPもデータベースも存在しません。そのため——

• アクセスが急増しても落ちない — CDNが静的ファイルを配るだけなので、 瞬間的にトラフィックが跳ねても構成側がボトルネックになりません。 キャンペーンやメディア掲載など、読めない負荷に強い構成です
• 公開側に攻撃対象がない — 管理画面もログインフォームも公開ネットワーク上にありません
• CMSが停止してもサイトは動き続ける — 編集ができなくなるだけで、閲覧には影響しません
• アクセス増が費用に直結しない — 配信の主体はストレージとCDNです

こうしたご相談を承っています。

• 「サイト更新のたびにエンジニアの手が必要で、運用が止まりがち」
• 「WordPressを入れたいが、表示速度やセキュリティを落としたくない」
• 「アクセスが読めないので、落ちない構成にしておきたい」
• 「今の静的サイト構成は維持したまま、CMSだけ載せたい」
• 「リニューアルを機に、構成から費用対効果を見直したい」

このようなご相談を承っています。既存構成を拝見したうえで、費用対効果の観点から現実的な選択肢をご提案します。「そもそも作り直すべきか」からご相談いただいて構いません。

▶ お問い合わせはこちら

---