脆弱性に強く、速いサイトのつくり方 — 脱WordPressという選択肢

こんにちは！システムデザインワークスの山岸です。

Web サイトを運用していて、こんな不安はありませんか。「WordPress の更新を溜めてしまっている」「使っていないプラグインが残ったまま」「管理画面のログイン URL に毎日アタックが来ている」。近ごろは WordPress の脆弱性に関する報告も目立つようになり、こうした不安を感じている方は少なくないはずです。本記事では、弊社が自社サイトで「脱 WordPress」に踏み切った理由と、代わりに採用している構成を、実際の仕組みとともにお話しします。

APIで動かすサイト運用（前後編）

1. 前編：脆弱性に強く、速いサイトのつくり方 — 脱WordPressという選択肢（本記事）

2. 後編：アクセス解析は「見に行かない」— GA・Search Console 週次レポートを AI がチャットに届ける

背景・課題:安全と速さを両立したい

WordPress は世界で最も使われている CMS で、用途によっては今も最適な選択肢です。ただ、広く使われているぶん攻撃者にも狙われやすいのも事実です。実際、2026 年 7 月には WordPress 本体（コア）に、プラグインを入れていなくても遠隔から悪用され得る深刻な脆弱性（wp2shell / CVE-2026-63030）が公表され、修正版が緊急でリリースされました。

ただ、ここで着目したいのは個別の脆弱性そのものよりも、その背景にある構造 です。WordPress の公開ページは、リクエストのたびにサーバー上でプログラムを実行し、データベースに問い合わせます。この「実行する場所」がある限り、本体かプラグインかを問わず、そこは攻撃の対象になり続けます。私たちが優先したかったのは、この攻撃面をそもそも小さくすること、そして表示速度も両立することでした。

取り組みの概要:ヘッドレスCMS × SSG × エッジ配信

弊社サイトは、記事を管理する ヘッドレスCMS（管理画面と公開ページが分離した CMS）と、ページを事前に静的な HTML として書き出す SSG（静的サイト生成）、そしてそれを世界中の拠点から届ける エッジ配信 の 3 つで成り立っています。具体的には Payload CMS と Next.js を、Cloudflare のエッジ上で動かしています。

従来の WordPress 構成と比べると、考え方の違いは次のとおりです。

※ WordPress の一般的な構成と、Next.js + Payload CMS による弊社サイトの構成を比較したものです。

実装・検証の要点

なぜ速く、なぜ堅牢なのか

ポイントは、訪問者に見せるページと、記事を編集する管理画面が完全に分離していることです。公開ページは「ただの静的 HTML」で、リクエストのたびにデータベースを読みに行くことも、プログラムを実行することもありません。だから速く、そして攻撃者から見て狙う先（実行環境）が表に出ていないため堅牢です。先ほどの wp2shell のような「リクエスト時のプログラム実行」を突く攻撃は、そもそも実行するコードが公開側に存在しないため成立しません。

管理画面を開かずに、生成AIの下書きから投稿まで自動化する

「静的」と聞くと更新が面倒そうに思えますが、実際は逆です。弊社の構成では、記事の投稿・更新・画像添付を、すべて API からプログラムで実行できます。だから「生成 AI に下書きを書かせ、そのまま API で投稿する」ところまで、人が管理画面にログインすることなく自動化できます。実はいまお読みのこの記事も、生成 AI が下書きし、API 経由で下書き投稿したものです。下書きの作成にかかった時間は 10 分ほど。しかもゼロから文章を作らせるのではなく、実際に変更したソースコードや設定ファイルをそのまま材料として渡しているため、スピードだけでなく 内容の正確さ・具体性といった記事の品質 も確保できています。

文章だけではありません。構成図やフロー図も Mermaid（テキストで図を描ける記法）で表現できるため、図の作成まで含めて生成 AI に任せられます。この記事に載せている図も、AI が Mermaid で書いたものです。

投稿そのものは、標準の API を叩くだけです。画像も同じ流れでアップロードし、記事に差し込めます。

1// 1) 画像を API でアップロードする（管理画面を開かない）
2const image = await createMedia({ alt: '記事のアイキャッチ画像', file: heroImageFile })
3
4// 2) 生成AIが書いた下書きを、そのまま記事として投稿する
5await createNews({
6  title: '脆弱性に強く、速いサイトのつくり方',
7  slug: 'why-we-left-wordpress-headless-ssg',
8  status: 'draft', // まず下書き。確認してから公開できる
9  heroImage: image.id,
10  content: aiGeneratedBody, // 生成AIが作った本文
11})
Copy

そして記事が更新されたときだけ、その 1 ページを裏側で作り直します（オンデマンド再生成）。普段は静的 HTML の速さを保ちつつ、更新は素早く反映される——という両取りの仕組みです。

1// 記事ページは「静的HTML」として事前生成しておく（＝リクエスト時に DB を叩かない）
2export const dynamic = 'force-static'
3export const revalidate = false
4
5// 記事が更新されたときだけ、その1ページを裏側で作り直す
6revalidatePath('/news/why-we-left-wordpress-headless-ssg')
Copy

この「API で動かす」という発想は、記事投稿だけでなく運用の自動化にも効きます。弊社では同じ考え方で、Google Analytics と Search Console の数値を毎週自動で集計し、AI による要因分析を添えてチャットへ投稿する仕組みも動かしています。人が毎週ダッシュボードを開く必要がなくなり、見るべき変化だけが手元に届きます。この仕組みは後編で詳しく紹介します。

結果:攻撃面が小さく、運用が軽くなった

構成を変えたことで、まず 公開ページから実行環境が消えました。プラグインや本体の脆弱性といった「実行される場所」を突く攻撃の心配から解放され、日々の更新追従に追われることもなくなりました。表示は世界中のエッジから静的 HTML を返すだけなので、アクセスが増えても安定しています。そして記事は API から自動で投入できるため、「書く・直す・出す」の運用そのものが軽くなりました。

まとめ

• 公開ページで実行環境が動いていること自体がリスク。本体かプラグインかを問わず、実行する場所がある限り攻撃対象になり続ける

• ヘッドレスCMS × SSG × エッジ配信なら、公開側に実行環境が出ないため攻撃面が小さく、静的 HTML の速さも得られる

• API 経由で下書き生成から投稿・画像添付まで自動化でき、運用が軽い

WordPress の脆弱性や保守の負担に悩んでいるなら、対症療法ではなく サイトの作り方そのもの を見直す価値があります。

ご相談お待ちしております。

栃木県でアプリ開発・システム開発の会社をお探しの方、Web サイトや業務システムを長く安心して任せられるパートナー企業を探している方へ。 今回ご紹介したような「脱 WordPress」のサイト刷新から、日々の業務を楽にする自動化、そして業務システム・アプリ開発まで、システムデザインワークスが一貫して対応します。

「こういうのできる?」の一言からで構いません。弊社は自社サイトで実際に試し、効果と落とし穴を把握したうえでご提案するスタイルです。お気軽にお問い合わせフォームよりご連絡ください。