あなたがたはやはり、静的サイトを使うべきだ

今は悪い時代なのです。

今日から、脱WordPress？

AIの性能が大きく向上してからというもの、人間が何十年にもわたって丁寧に丁寧に作り込んだ隙だらけのコードから、大量の脆弱性が見つかっています。PHPでRCE¹を可能にする2つの脆弱性²は PHP2Shell と呼ばれ、日本でも時の首相がX（旧Twitter）で異例の注意喚起を発表するに至りました³。PHP公式から修正版が提供される前に攻撃手法が出回ったこともあり、10月21日にはPHPで作られた多くのサービスが予防的な臨時メンテナンスに入りました。

さて、このPHPで作られた世界的に有名なコンテンツ管理システム（CMS）として WordPress がよく知られています。ある調査⁴によれば、CMSの中では6割のシェア、Web全体でも4割がWordPressで構築されているという驚異的な普及率です。WordPressを使って構築された多くのブログ、ECサイト、コーポレートサイトもこの脆弱性の影響を受けることになり、これらのサイトも臨時メンテナンスとアップデートを経てサービスを再開しました。

もともとPHPは様々な要因で「脆弱性が見つかりやすい処理系だ」というイメージが先行して語られがちであり、今回の脆弱性の発見はその偏見に拍車を掛けています。SNSではPHPを脱してGoやRustに乗り換えようとか、特にWordPressをEmDashに置き換えようという論調が強くなりました。EmDashというのは、Cloudflareが発表したWordPressの精神的後継を自称するCMSであり、AIネイティブ・モダンな認証・モダンなフロントエンド・サーバレスといったイカしたアーキテクチャと共に、プラグインのセキュリティ向上を大きな差として掲げています。

WordPressのプラグイン機構は、もともとプラグインが本体と同じ環境で制限なく動くという過剰な信頼に基づいた設計で実装されています。インストールした時点でプラグイン本体を完全に信頼したのと同じなのはもちろんですが、プラグイン間での動作の競合やデータ破損を防ぐには祈るしかありません。プラグイン自身に悪意がなくとも、外部から悪用できる不適切な実装があれば、広い権限で損害を起こしうる深刻な脆弱性のできあがりです。

ある調査⁵によれば、WordPressで見つかったセキュリティの問題は96%がプラグインが原因であるとされ、ここに限れば、PHPの処理系よりもプラグインの穴がそのまま本体の侵害に繋がるプラグイン機構自体が原因だといえます。

EmDashでは、こうしたプラグインを隔離した環境で実行し、マニフェストで事前に定義した処理と機能のみ実行できるよう設計されています。外から差し込むプラグインをCMS本体から隔離して、本体にアクセスできるチャネルも最小限に抑えるわけですね。スマホのOSがアプリに対して明示的に権限を与える仕組みと似ています。

じゃあ、EmDash推進派？

さて、ここまで聞くとなぜ全てのWordPressを今すぐEmDashに移行しないんだ、と思う人がいるかもしれません。CloudflareはWordPressから直接移行できるプラグインも提供しており、既にモダンでクールなCMSを使う準備はできているはずです。しかも、全部任せれば上手くいきそうなあのCloudflareで！

もちろん、WordPressをEmDashに移行 しない 理由はたくさんあります。

まず「WordPressから移行できる」というのは、これまでと同じ使い勝手で運営できるという意味ではありません。サイトの見た目をほぼ再現できたとしても、これまでのアーキテクチャとは全く異なるので、WordPressの管理画面やプラグインの知識や経験をそのまま活かすのは難しいでしょう。

また、技術的な強いこだわりがなければCloudflare上にデプロイされ、そのままロックインされます⁶。改めて別のCMSに移行するとなればまた一苦労です。月額制のレンタルサーバーなら毎月の費用も予測可能ですが、Cloudflareは従量課金制なので、アクセスの量によって安くなることも高くなることもあります。

それに、国内向けのレンタルサーバー屋さんに比べれば、サポートも充実しているとは言えません。無料プランや低額の有料プランでは個別のサポートはほぼなく、自力で調査するかコミュニティへの投稿で解決を目指すことになります。WordPressから移行してセキュリティを向上させるつもりだったのに、自力で頑張った末に不適切な設定変更で誰でも通す大穴を開けてしまう……という悲劇にも繋がりかねません。

移行コスト、学習コスト、予算計画の複雑さ、サポートの薄さ、そして特定サービスへのロックイン……技術的知識のある個人で運営しているサイトならまだしも、企業のサイトをいきなりEmDashに移行するには、費用と工数の用意だけでなく関係者のコンセンサスも必要でしょう。

これらをデメリットを十分に考慮しても、モダンなプラグイン機構で得られるメリットの方が上だと言えるのなら、EmDashに移行する価値があります。しかし、「PHPじゃないから安全だ」とか「モダンで速いらしい」なんて的外れな理由で明日の会議資料を準備しているなら、何ヶ月経っても移行の成果を実感できないかもしれません。

だって、EmDashはすごく安全なわけでも、すごく速いわけでもないのですから。

それなら、脱CMS？

あなたがWordPressを捨てたくなったときにまず検討しなければならないのは、「どのCMSに移行しようか」ではなく、「動的にコンテンツを生成するCMSが必要なのか」ということです。これに答えられない、あるいは意味が分からないなら、おそらくまだWordPressを使い続けたほうがよいでしょう。もちろん、これまで以上にセキュリティ維持に十分なコストを払う前提で、です。

動的にコンテンツを生成――というのは、ユーザーのリクエストに応じてデータベースを読み書きしたり、コンテンツを組み立ててレスポンスを返すやり方です。WordPressを含む多くのCMSや、ユーザーがコンテンツをアップロードするサービス、ユーザーごとに別のコンテンツを返すサービス、リアルタイムでコンテンツを提供するサービスは、ほとんどが動的にコンテンツを組み立てる 動的サイト です。つまり、以下のようなウェブサービスは動的サイトで提供するのに向いています。

• 不特定多数のユーザーが投稿したコンテンツをリアルタイムで別のユーザーが読むSNS
• 特定のユーザーや会員だけが読めるコンテンツを提供するニュースサイト
• 先着順で商品の在庫数を減らして注文処理を確定させる通販サイト

逆に言えば、こうした特徴に当てはまらないサービスは動的サイトで提供する必要がありません。ユーザーがコンテンツをアップロードしない、どのユーザーにも同じコンテンツを返す、リアルタイム性が求められないサービス。つまり、以下のようなサイトのほとんどは、不特定多数のユーザーに対してサーバーで複雑かつ動的な処理を実行する権利を渡さなくてよいのです。

• 数人が数週間に一度くらい公開の記事を投稿する小規模なブログ
• 最初に作ってからほとんど更新しない企業や店舗の紹介サイト
• 不定期にイベント告知や通販サイトへのリンクを記載するだけの同人サークルサイト

こうしたサイトは、事前に生成したHTML/CSS/JavaScriptをただ返すだけの 静的サイト として構築するのが向いています。静的サイトというのは、その言葉からイメージするような画面に動きのない退屈なサイトではありません。CSSでアニメーションを付けたり、JavaScriptで3Dモデルを動かしたり、ユーザーごとのカラーテーマを提供することもできます。あくまで、一定の反映の遅れを許容して同じコンテンツを返し続けるという点で、「動的」ではなく「静的」なのです。

注意すべきなのは、動的サイトと静的サイトは完全に異なる存在ではないということです。たとえば、静的サイトでの配信が向いているサイトでも、訪問者数をリアルタイムに表示するカウンター、ユーザー投稿を受け付けて交流するコメント欄、複雑なフィルタに対応した検索機能を提供する場合は、その部分にだけ動的な処理を取り入れることができます。

もちろん、サーバーでの動的な処理が増えれば増えるほど危険性は増しますし、導入しなくて済むなら避けるべきです。たとえば、コメント機能はユーザー入力を受け取ってページに出力する典型的な悪用の窓口なのであまりおすすめしません。SNSでの投稿で反響を確かめたり、お問い合わせページや感想フォームを用意するとよいでしょう。また、シンプルな検索機能で十分なら、Pagefindを導入すればブラウザ上で検索を行えます。

つまり、静的サイト？

ここでさらに気になるのは、あなたのサイトが静的サイトに向いている理由ではなく、静的サイトに切り替えるべきメリットでしょう。

静的サイトを使う最大のメリットは、決まったコンテンツを返すだけのシンプルなHTTPサーバーさえあれば配信できるということです。URLを受け取って合致するパスのコンテンツを返すだけ。データベースにアクセスしたり、ユーザーにコンテンツをアップロードさせたり、リクエストに応じてその場でコンテンツを作ったりしません。コンテンツの変化が予測しやすいので、CDNなどのキャッシュを活用した配信とも相性がよいです。つまり、すごく安全で、すごく速いです。

これは、動作にPHPを必要とするWordPressや、EmDashのような特定のプラットフォームを前提としたシステムと比べても大きなメリットです。シンプルなHTTPサーバーさえあれば済む静的サイトはどこからでも配信でき、ベンダーを選びません。これまで通りのレンタルサーバーやVPSはもちろん、GitHub Pages、Cloudflare Pages、Firebase Hosting、Amazon Cloudfront + S3、Netlify、あるいはOnion Serviceを選んでもよいでしょう。

こういう静的サイト安全論を見ると、「HTTPサーバーに脆弱性があったら安全ではないんですよねぇ」と反射的にnginxあたりの脆弱性を持ち出す人もいます。でも……ちょっと待って！　WordPressもPHPで処理をしてから、外部に向けたHTTPサーバーを用意して配信するのが一般的です。動的サイトが依存する複雑なウェブアプリケーションの層を使わないというだけで、やはり安全性は上がります。

さらに、静的サイトとして配信する準備ができた動的サイトなら、静的サイトに変換するのも比較的簡単です。たとえば、WordPressならSimply Staticのようなプラグインで静的サイトに変換することができ、慣れた記事編集画面を使いつつ外側には静的サイトとして公開できます。

また、WordPress以外のCMSでも、動的サイトの出力をファイルに記録して配信すれば、原理的には全てを静的サイトに変換できるといえます。静的サイトに変換できる動的サイトは、このような特徴を備えています。

• 認証なしでアクセスできるURLが事前に決まっていて、リストにまとめることができる。
• どのURLにアクセスしても、全く同じページを返すか、無視できる差の変化しか生じない。
• 静的サイトの配信サーバーに対して、単純な取得以外のリクエストを行うフォームやスクリプトが存在しない。

こうしたサイトは、内側ではCMSの親しみやすい管理画面や記事編集画面を使いつつ、外側には安全な静的サイトとして公開することができます。わざわざEmDashに乗り換えて、今後役に立つか分からない学習コストや不必要なロックインを受け入れる必要はありません。

どうやる、静的サイトジェネレーター？

あるいは、もしあなたがWordPressを完全に捨てて静的サイトに乗り換える準備を終えているなら、 静的サイトジェネレーター （SSG）を使うのがよい選択肢です。動的サイトを静的サイトに変換する際の注意点を気にせず、配信しやすく整理された静的サイトを直接生成できます。

一般的な静的サイトジェネレーターの仕事は次の3つです。

• 人間などが書いたMarkdownなどの軽量なソースを読み取る
• それらをHTMLに変換して「テーマ」と呼ばれるテンプレートに埋め込む
• 生成したリソースを適切な階層にまとめて出力する

これらの仕事の中には、親しみやすい管理画面や記事編集画面の提供は含まれていません。こうした管理画面をサポートしている静的サイト用CMSを名乗るアプリはいくつかあるものの、Hugoを初めとした多くの静的サイトジェネレーターはファイルを直接編集し、コマンドでプレビューやデプロイを行う 玄人 向けのツールです。

もしWordPressを複数人で使っていたなら、記事を書く寄稿者と公開までできる編集者のようなユーザー権限の整備も必要でしょう。こうしたレビューや承認フローは、おそらくGitHubでのプルリクエストなどで実現することになりますし、簡単にプレビューを確認できる仕組みも自分たちで用意するのが前提です。

記事を書いて公開したいだけのユーザーがとにかく取っつきにくいのが、静的サイトジェネレーター最大のデメリットといえます。

こうした課題を解決する静的サイト用CMS、あるいはヘッドレスCMSと呼ばれるアプリには以下のようなものがあります。

• microCMS: 従来のCMSからフロントエンドを明確に切り離したヘッドレスCMSで、既存の静的サイトジェネレーターにソースを渡す仕組みで静的サイトを作ることができます。
• Sveltia CMS: 既存の静的サイトジェネレーターをリッチなエディターで編集できるように包んだウェブアプリで、スマホにも対応しています。
• Publii: 静的サイトジェネレーターを内蔵したデスクトップアプリで、記事やテンプレートの管理、ビルド、公開などの機能をアプリ自身が持っています。

これらのアプリを使うと、素の静的サイトジェネレーターに比べれば、少なくとも記事の編集はかなり手軽に行えるようになります。サイトのテーマやパーツのカスタマイズはWordPressほど自由で簡単にできるとは言えませんが、もともとそう頻繁にいじるものではありませんし、やりたいことをそのままAIに伝えればほぼ実現できる世界になっています。

静的サイトへの移行で執筆フローの整備が問題に挙がっているなら、こうしたアプリを使ってみる価値があるかもしれません。

えーと、結局どうする？

まとめると、これまでWordPressやその他のCMSを使ってきた動的サイトのうち、より安全でより速く提供できる静的サイトへの乗り換えに向いているサイトがこの世にはたくさんあります。そういうサイトを管理しているあなたは、次の選択肢を選べます。

• CMSの管理画面や記事編集画面はそのままに、静的サイトとして公開する仕組みを整える。
• 静的サイトジェネレーターに乗り換えて、新たなテーマ管理や執筆フローの運用を受け入れる。
• 移行についてはまだ何もせず、これまで以上にセキュリティに注視してアップデートを続ける。

いずれも、深い理由もなく流行りのEmDashに乗り換えるより合理的で、将来にわたって運用しやすい仕組みの構築に役立ちます。もっと掘り下げたいところがあれば、お手持ちのAIにこの記事を渡すとよいでしょう。

明日のWordPress移行会議が、将来にわたって実りあるものになることを祈っています。