シリーズ①なぜWordPressではなく、静的サイトを採用したのか。得た速さ・安全・壊れにくさ

結論：速度・セキュリティ・運用安定の3点で、弊社の考えでは、静的サイトはWordPressに勝ったと考えます。

結論から言うと、私たちが運営するAI情報メディア「AIテックベース」は、WordPressではなく、静的サイト構成を採用した事で、
表示速度が速くなり、攻撃されるリスクが減り、サイトが壊れにくくなりました。
なぜなら、静的サイトには管理画面・プラグイン・データベース（DB）が存在しないからです。
これらはWordPressの便利さの源であると同時に、遅さ・脆弱性・故障の主な原因でもありました。
この記事では、非エンジニアの代表者が実際に構築して感じたメリットと、正直なデメリットをまとめます。

そもそも、どのような開発環境だったのか

もともとAIテックベースは、さくらのレンタルサーバー上でWordPressでの構築を検討していました。
しかし、次の構成へ置き換えました。

• 表示部分（フロント）：Astro（出力は静的HTML）
• 記事管理（CMS）：microCMS（日本製のヘッドレスCMS）
• 公開場所（ホスティング）：Cloudflare Pages
• 問い合わせフォーム：さくらインターネットのレンタルサーバー上のPHP（メール送信のみ。個人情報はどこにも保存しない）

ポイントは、記事を書く画面（microCMS）と、読者が見る画面（静的HTML）が分かれていることです。
WordPressのように「1つのシステムが全部を兼ねる」構成をやめました。

メリット1：速度 — 完成済みのHTMLをそのまま配るから速い

静的サイトは、WordPressより表示が速くなります。配信のしくみがシンプルだからです。
WordPressはアクセスのたびに、サーバーがPHPを動かし、DBに記事を問い合わせ、HTMLを組み立てて返します。この「毎回その場で作る」処理に時間がかかります。
一方の静的サイトは、あらかじめ完成したHTMLファイルをそのまま渡すだけです。
料理にたとえるなら、注文のたびに一から調理するのがWordPress、作り置きを温めてすぐ出すのが静的サイトです。
さらにCloudflare Pagesは世界各地のサーバーから配信するため、読者に近い場所から届き、待ち時間が短くなります。

メリット2：セキュリティ — 攻撃される入口がそもそも無い

静的サイトは、WordPressより安全です。攻撃される面（攻撃対象領域）が大きく減るからです。
WordPressが狙われやすいのは、次の3つの入口があるためです。

• 管理画面（ログインページ）：パスワードを総当たりで破ろうとする攻撃の的になる
• プラグイン：便利な反面、更新を怠ると脆弱性が放置されやすい
• データベース：不正なデータを送り込む攻撃（SQLインジェクション等）の対象になる

静的サイトには、この3つがいずれも存在しません。
入口が無ければ、そこを破られることもありません。
記事を編集するmicroCMSの管理画面は別のサービス上にあり、
公開中のサイト本体とは切り離されています。「侵入しようにも、そもそもドアが付いていない」状態に近いと言えます。

メリット3：運用安定 — DBが無いから壊れにくい

静的サイトは壊れにくく、運用が安定します。データベースに依存しないからです。
WordPressの不調の多くは、DBやプラグイン同士の相性に由来します。
プラグインを更新したら画面が真っ白になった、DBが壊れて記事が表示されなくなった、といったトラブルです。
静的サイトで公開されているのはただのHTMLファイルなので、こうした連鎖的な故障が起きにくいのです。

さらに私たちの構成では、microCMSで記事を公開すると、Webhook（更新を知らせる通知）が自動でCloudflareに伝わり、
サイトが作り直されて反映されます。「公開ボタンを押すだけ」で運用が回るようになりました。

WordPressと静的サイトの比較

WordPressにも、変わらない強みがある

ここまで静的サイトのメリットを述べてきましたが、
WordPressには、今も多くの現場で支持され続ける理由があります。
まず、テーマ・テンプレートの豊富さです。無料・有料を合わせると数万種類以上が存在し、
デザインの専門知識がなくても見栄えのあるサイトをすばやく立ち上げられます。

次に、プラグインによる拡張性です。SEO対策・フォーム・予約システム・EC機能など、必要な機能をプラグインで追加できます。
コードを書かずに実現できる幅の広さは、静的サイトには簡単には真似できません。

また、WordPress.orgとWordPress.comの2つの選択肢があります。
自分でサーバーを用意して自由にカスタマイズしたいならWordPress.org（自己ホスト型）、
手軽にはじめたいならWordPress.com（ホスティング込み）と、運用スタイルに合わせて選べます。
さらに、セキュリティ面でよく槍玉に挙げられる管理画面（wp-admin）への不正アクセスも、対策は存在します。
プラグインを使えばログインURLを任意のパスに変更でき、総当たり攻撃のリスクを大幅に下げることが可能です。
プラグインを最新の状態に保ち、適切な設定をすれば、WordPressでも十分に安全な運用はできます。

制作会社が関わるコーポレートサイトや、複数人で記事を書くメディア、
ECや予約機能が必要なサービスサイトなど、WordPressが依然として最適解になる場面は多くあります。
そのうえで私たちは、更新頻度が高くコンテンツ中心のメディア運用という自社の事情から静的サイトを選びました。
なお、今回のサイト構築はバイブコーディングで行いました。
専門的な開発知識がなくても、AIに意図を伝えながら一緒に作り上げていくこの手法は、
静的サイト＋バイブコーディングの組み合わせとして、スピード・安全・安定という移行テーマとも一致していました。

さくらインターネットの良さ

皆様に知って頂きたいさくらインターネットの良さは、
外資独占だった国の「ガバメントクラウド」に国内企業で唯一選ばれ、
高い技術要件をクリアした信頼のインフラ企業です。
AI向けGPUの提供に加え、元祖学生起業家である田中社長はエンジェル投資家としても活躍されており
その投資家視点を活かし、インフラ無償提供など挑戦者を徹底支援する文化が根付いていると聞いた事があります。
円安リスクのない国産の安心感と、日本の未来を創る技術や人に投資し伴走してくれる熱量こそが最大の魅力です。

今回、私の構築環境では、この記事で触れたような構築にしましたが
メリットとデメリットを考慮して構築環境を選択する事が重要と考えます。

では、今回の構築の正直なデメリットは？初期構築には手間がかかります。
良いことばかりではありません。静的サイトは、最初の構築に手間がかかります。
WordPressのように「インストールすれば全部そろう」わけではなく、
表示・記事管理・公開・フォームをそれぞれ組み合わせて作る必要があるからです。

私たちも移行の途中で、いくつもの壁にぶつかりました。

• さくらインターネットのレンタルサーバー（スタンダード）ではFTPで運用していました（同サーバーはSSH/SFTPにも対応していますが、当時はFTP運用のままでした）。
• 自動デプロイを試したが失敗、さくら「国外IPアドレスフィルタ」だった。自動化ツールは海外のサーバーで動くため、海外からの管理アクセスが遮断されていた。

このフィルタは、サイトの閲覧（通常のHTTP）は止めず、FTPや管理画面といった「管理系の入口」だけを海外から遮断する安全機能です。
最終的にホスティングをCloudflare Pagesへ切り替えたことで、さくらへ海外からアクセスする必要がなくなり、このフィルタを有効に保ったまま自動運用ができるようになりました。
問い合わせフォームは通常のHTTPで動くため、フィルタを有効にしたままでも問題なく送信できます。

ここでの学びは、非エンジニアにとって特に重要でした。
「原因らしきものを片っ端から試す」のではなく、先に環境の仕様を確定し、エラーの意味を調べて原因を1つに特定してから直すこと。
推測でFTPのホスト名を決めて失敗した、という遠回りも経験しました。
初期の手間は確かにあります。しかし一度組み上げてしまえば、その後の速さ・安全・安定は日々の運用でずっと効いてきます。

このシリーズの他の記事もどうぞ

本記事は、AIテックベースがWordPressではなく静的サイト構成を選んだ経緯を記録したシリーズの一部です。関連トピックもあわせてお読みください。

• ヘッドレスCMS「microCMS」を選んだ理由
• Cloudflare Pagesでの無料ホスティングと自動デプロイ
• さくらの「国外IPアドレスフィルタ」でハマった話
• 個人情報を保存しない問い合わせフォームの作り方
• Webhookで「公開ボタンだけ」運用にする方法
• AI（Claude Code）と一緒に進めた制作の進め方
• 移行時のSEOで気をつけたこと

まとめ

• 速度：完成済みの静的HTMLをそのまま配信するため、WordPressより表示が速い。
• セキュリティ：管理画面・プラグイン・DBが無く、攻撃される面が大きく減る。
• 運用安定：DBに依存しないため壊れにくく、自動デプロイで運用が楽になる。
• デメリット：初期構築には手間がかかる。ただし一度作れば効果は長く続く。
• 非エンジニアの学び：推測で試さず、環境の仕様を確定し原因を1つに特定してから直す。