攻撃される場所がなくて、更新は AI に頼める。WordPress をやめたコーポレートサイトの作り方
2026 年 10 月の PHP 脆弱性を機に、自社サイトを WordPress から「完成したページを配るだけ」の構成へ作り替えました。管理画面もプラグインもデータベースもないサイトで、セキュリティの何が変わり、更新がどう楽になるのかを非エンジニア向けに説明します。
2026 年 10 月 21 日に PHP の重大な脆弱性が公表されてから、「うちのサイトは大丈夫なのか」というご相談が続いています。WordPress で作られたサイトの多くが影響を受ける可能性があり、ニュースを見て不安になった方も多いと思います。
実は私たちも、ちょうど同じ時期に自社サイトを WordPress から別の仕組みに作り替えたところでした。新しいサイトには、管理画面も、プラグインも、データベースもありません。今回の脆弱性も「対応不要」でした。そして更新は、AI に日本語で頼めば済むようになりました。
この記事では、エンジニアではない方に向けて、WordPress のサイトがどこを狙われるのか、私たちがどう作り替えたのか、それでセキュリティの何が変わるのかを書きます。向かない会社もあるので、そこも書きます。
WordPress のサイトは、どこを狙われるのか
WordPress のサイトは、誰かがページを開くたびに、サーバーの中でプログラム（PHP）が動いてページを組み立てています。注文が入るたびに厨房で調理するレストランのようなものです。厨房があるから何でも出せる反面、狙われるのも厨房です。
狙われる場所は主に 4 つあります。
- ログイン画面。WordPress のログイン画面の URL は世界中で同じなので、攻撃する側は探す必要すらありません。機械的にパスワードを試し続けるアクセスが、どのサイトにも毎日来ています。
- プラグイン。フォーム、SEO、目次、バックアップと、ひとつのサイトに十数個入っているのが普通です。作者はバラバラで、更新が止まったものも混ざっています。WordPress で見つかる脆弱性の大半は、本体ではなくプラグイン由来です。
- PHP そのもの。今回の件がこれです。PHP の更新はレンタルサーバーの設定画面で自分で切り替える必要があり、「切り替えると表示が崩れるかも」と思うと手が止まります。そうやって何年も古いままになっているサイトが、たくさんあります。
- データベース。記事だけでなく、会員情報や問い合わせ内容もここにたまっています。侵入されると、持ち出されるのはここです。
担当者が怠けているわけではありません。「更新すると壊れるかもしれない」「更新しないと攻撃されるかもしれない」の間で手が止まるのは、WordPress を持っている限り誰にでも起きます。
今回の構成は「完成したページを配るだけ」
新しいサイトは、あらかじめ全ページを完成品として作っておき、訪問者にはそれをそのまま渡します。厨房で調理するのではなく、調理済みの弁当を配るイメージです。この作り方を「静的サイト」と呼びます。
記事や会社概要はテキストファイルで書き、内容を変えるたびに、Astro という道具が全ページを完成品として作り直し、Cloudflare という世界中に拠点を持つ配信網に置きます。訪問者が見ているとき、サーバー側でプログラムは何も動いていません。
動くプログラムは、お問い合わせフォームの送信処理 1 本です。これも Cloudflare の中で動く小さなプログラムで、受け取った内容を確認してメールで転送するだけです。データベースは持っていません。
| 項目 | WordPress（以前の自社サイト） | 今回の構成 |
|---|---|---|
| ページを開くとき | サーバーで PHP が動いて組み立てる | 完成済みのページを渡すだけ |
| ログイン画面 | ある（URL は世界共通） | ない |
| プラグイン | 十数個 | ない |
| データベース | ある | ない |
| PHP の更新 | 自分で切り替える | 無関係（PHP を使っていない） |
| 動くプログラム | サイト全体 | フォーム送信の 1 本だけ |
| 置き場所 | レンタルサーバー 1 台 | Cloudflare の世界中の拠点 |
| 月額費用 | レンタルサーバー代 | 0 円（無料枠の範囲） |
セキュリティの何が変わったか
守るものが減った、これに尽きます。防御を強くしたのではなく、攻撃される場所をなくしました。
PHP の脆弱性が出ても、対応が要らない。 PHP を使っていないので、今回のようなニュースが出ても「うちは関係ない」と即答できます。PHP点検で調べると「何もしなくて OK」になります。
ログイン画面がないので、パスワードを試される場所がない。 サイトの更新は、GitHub というコードの保管庫にファイルを置くことで行います。入口は二段階認証付きで、サイトの URL からはたどり着けません。
プラグインがないので、「あのプラグインに脆弱性」というニュースを追わなくていい。 フォームもサイトマップも目次も、自分たちで書いた少量のコードで動いています。
データベースがないので、持ち出されるものがない。 お問い合わせの内容はメールで届き、サーバーには残りません。万が一侵入されても、そこにあるのは公開済みのページだけです。
改ざんされても、元に戻せる。 全ページの元データが履歴付きで保管されていて、配信し直せば数分で復旧します。WordPress の場合は「どこを書き換えられたか」の調査から始まり、バックアップにも改ざんが混ざっていることがあります。
攻撃の矢面に立つのが Cloudflare。 大量アクセスでサイトを落とす攻撃や不審なアクセスの遮断を、世界最大級の配信網が前段で引き受けます。フォームのスパムは、人間かどうかを判定する仕組み（Turnstile）で弾きます。
リスクがゼロになったわけではありません。GitHub や Cloudflare のアカウントを乗っ取られればサイトを書き換えられますし、フォームの処理にバグがあればそこが穴になります。ただ、守るべきものが「アカウント 2 つとフォーム処理 1 本」に絞られたのと、「サイト全体と十数個のプラグインと PHP とデータベース」を守り続けるのでは、難易度がまるで違います。
いちばん変わったのは、更新を AI に頼めるようになったこと
セキュリティのために作り替えたのですが、使ってみて一番大きかったのはここです。サイトの中身がすべてテキストファイルになったので、「お知らせを 1 件足して」「会社概要の住所を変えて」「このテーマで記事を書いて」と Claude や ChatGPT に日本語で頼めば、AI がファイルを書き換えます。管理画面でメニューを探す必要も、HTML を触る必要もありません。
AI が書いた変更は、そのまま本番に出るのではなく、まず確認用のページとして自動で公開されます。担当者はそれを見て OK を出すだけで、数十秒で本番に反映されます。間違えても前の状態に戻せます。
担当者がやるのは、頼むことと確認することの 2 つです。ログイン画面はなく、AI が触るのは文章ファイルだけです。
WordPress でも AI に文章を書かせることはできますが、管理画面に貼り付けて見た目を整えるのは人の仕事でした。テキストファイルは AI が最も得意とする形式なので、書くところから公開の手前までを任せられます。実際にこのサイトは Claude Code に指示して作り、この記事の下書きも Claude と一緒に書いています。
AI と GitHub をつなぐ最初の設定だけは技術者が行います。そこから先は、エンジニアでない方でも日本語で運用できます。
ついでに良くなったこと
狙いはセキュリティでしたが、ほかにも変わったことがあります。
- 表示が速い。訪問者に一番近い拠点から完成済みのページを渡すので、サーバーがページを組み立てる待ち時間がありません
- サーバー代が 0 円になった。コーポレートサイト程度のアクセスなら、Cloudflare もメール送信も無料枠で収まります
- 定期的な更新作業が消えた。WordPress 本体・プラグイン・PHP の更新を、もう気にしなくてよくなりました
- 誰がいつ何を変えたかが全部残る。間違えても前の状態に戻せます。公開前に確認用の URL も自動で発行されます
載せ替えると変わること、向かないサイト
変わることと、向かないサイトも書いておきます。
- 更新のやり方が変わる。記事はテキストファイルとして保管庫に置く形になりますが、上に書いたとおり AI に頼めるので、ファイルを直接触る必要はありません。WordPress と同じように管理画面で書きたいなら、編集画面だけを別サービスで持つか、Cloudflare の EmDash を使えば、技術者なしで更新できます（下の表）
- 「動く機能」は別に用意する。会員ページ、予約、EC、検索など、WordPress ならプラグインで済んでいたものは、ひとつずつ作るか外部サービスをつなぎます
- 移行に手間がかかる。過去の記事を持っていくには変換作業が要ります
もっとも、WordPress でプラグインが担っていた機能の多くには、サーバーで動くプログラムを持たずに実現できる代替手段があります。
| WordPress で頼っていたもの | 代わりになるもの |
|---|---|
| 記事の編集画面 | 編集画面だけを別サービスで持つ「ヘッドレス CMS」（microCMS など）。書いた記事を Astro が取りに行き、ページを作り直す |
| 管理画面ごと WordPress のように使いたい | Cloudflare が 2026 年 4 月に公開した CMS「EmDash」。WordPress の後継を狙ったもので、WordPress の記事をそのまま取り込める。プラグインは許可した操作しかできず、ログインはパスワードでなくパスキー。ただしまだ開発者向けのベータ版 |
| サイト内検索 | Pagefind。完成済みのページから検索用の索引を作り、訪問者のブラウザの中で検索する。サーバーは要らない |
| お問い合わせフォーム | Turnstile + 小さなプログラム（今回の構成そのもの） |
| 予約 | 予約サービスの画面を埋め込む（TimeRex、Google カレンダーの予約ページなど） |
| 決済・EC | Stripe の決済リンクや Shopify の購入ボタンを埋め込む。カード情報は自社のサイトを通らない |
| 会員限定ページ | Cloudflare Access。メールアドレスでログインした人だけに見せる。少人数なら無料枠で済む |
それでも、毎日更新する大きなメディアサイトや、商品数の多いネットショップ、会員機能が込み入ったサイトは、今の仕組みを安全に保つ方が現実的です。
自社サイトはどうすべきか。判断の目安
次の項目に 3 つ以上当てはまるなら、載せ替えを検討する価値があります。
- PHP点検で「管理者に連絡」または「管理者に確認」と出た
- WordPress・プラグイン・PHP を最後に更新したのがいつか答えられない
- 作った制作会社との契約が終わっていて、保守を誰も見ていない
- サイトの更新は年に数回で、内容はお知らせ程度
- お問い合わせフォーム以外に「動く機能」がない
- ログイン画面の URL を変えていない、二段階認証も入れていない
逆に、担当者が管理画面で週に何度も記事を書いているなら、今の WordPress を安全に保つ方が先です。PHP の更新、使っていないプラグインの削除、ログイン保護、バックアップの 4 点で、リスクの大半は下がります。
まずは、自社サイトを調べるところから
今回の脆弱性の対応が必要かどうかは、PHP点検に URL を入れるだけで分かります。「管理者に連絡」と出たら、サイトを保守している会社にその結果を伝えてください。
保守を頼める先がない、あるいはこの機会に「更新を気にしなくていいサイト」にしたい方は、お問い合わせからご相談ください。お手伝いできることは 2 つです。
- 今の WordPress を安全に保つ。PHP の更新、プラグインの棚卸し、ログイン保護、バックアップの整備
- この記事と同じ構成へ載せ替える。コーポレートサイトの規模なら、旧 URL の引き継ぎも含めて対応します
載せ替えるべきかどうかを迷っている段階でもご相談いただけます。現在のサイトを拝見したうえで、今の構成のままで十分と判断した場合は、その旨を正直にお伝えします。