Aioright Technologies
IT運用・コンサルティング

脱WordPress・脱レンタルサーバー　AWS S3+Astroで構築するセキュアなWebサイト

中小企業のコーポレートサイトを対象に、WordPressとレンタルサーバーの管理対象や課題を整理し、AWSとAstroによる静的サイトへ移行する利点、生成AIとの相性、向いているサイトを解説します。

公開日 著者 Aioright Technologies
紫と紺のグラデーション背景

会社案内、サービス紹介、採用情報、お知らせ。こうした情報を掲載する企業サイトに、WordPressの管理画面やデータベース、PHPを常時動かす仕組みは本当に必要でしょうか。

WordPressは、専門知識がなくてもブラウザから更新しやすく、豊富な機能を追加できる優れたCMSである一方で、利用する機能が少ない企業サイトでも、WordPress本体、プラグイン、テーマ、PHP、データベース、管理者アカウントなどを継続して管理する必要があります。

そこで検討すべきなのが、必要なページをあらかじめ作成し、完成したファイルだけを配信する静的サイトです。AWSのCloudFrontとS3、Webサイト制作ツールのAstroを組み合わせることで、不要な管理画面や実行環境を減らせます。

この記事では、非エンジニアの経営者やWeb担当者に向けて、WordPressから静的サイトへ移行する利点を、セキュリティ、管理対象の整理、生成AIとの相性から解説します。

目次

  1. WordPressは「本体だけ」を管理すればよいわけではない
  2. 2026年10月のPHP脆弱性
  3. レンタルサーバーの問題は管理範囲の広さ
  4. 静的サイトは「完成したページ」を配信する
  5. AWS+Astroによる企業サイトの構成例
  6. ファイルで管理するサイトは生成AIと相性がよい
  7. 静的サイトへの移行が向いている企業
  8. 移行前に確認すること
  9. まとめ：守る仕組みを減らすという選択肢
  10. Webサイトの見直しをご相談ください
  11. 参照資料

WordPressは「本体だけ」を管理すればよいわけではない

WordPressサイトは、複数の仕組みを組み合わせて動いています。WordPress本体を最新にしていても、セキュリティ、プラグイン、テーマ、PHP、サーバー設定などに問題があれば、個別の対応が必要です。

WordPress向けセキュリティ企業Patchstackの調査では、2025年にWordPressのエコシステムで11,334件の脆弱性が発見され、前年比42%増でした。内訳はプラグインが91%、テーマが9%で、WordPress本体は6件と報告されています。また、46%は脆弱性の公表時点で開発者による修正が提供されていませんでした。

管理対象WordPressサイトで必要になる主な作業
WordPress本体更新、動作確認、バックアップ
プラグイン・テーマ脆弱性情報の確認、更新、互換性確認、不要なものの削除
PHP・データベースバージョン管理、セキュリティ更新、障害対応
管理画面・アカウント認証、権限管理、不正ログインの監視
Webサーバー・レンタルサーバー設定確認、ログ確認、バックアップ、復旧手順の整備
FTPなどの更新手段認証情報とアクセス権限の管理

更新を外部事業者へ任せている場合でも、利用者側で更新状況や責任分界を把握する必要があります。重大な脆弱性が公表された際に、誰が影響を確認し、誰が更新や動作確認を行うのかを明確にしておくことが重要です。

2026年10月のPHP脆弱性

2026年10月21日、PHP公式（WordPressが動作するプログラム言語）は、認証なしの遠隔コード実行に繋がり得る2件の重大な脆弱性を公表し、修正版への更新を呼びかけました。

この脆弱性はWordPress固有のものではなく、すべてのWordPressサイトが同じ条件で侵害されるという意味でもありませんが、WordPressの管理画面で本体やプラグインを更新していても、その下で動くPHPの更新は別に必要になる場合があることを示す例です。

レンタルサーバーでは、PHPなどの基盤をサービス提供者が管理する場合もあります。ただし、対応時期、利用中のバージョン、利用者側で必要な操作は契約やプランによって異なります。「誰が、何を、いつ更新するのか」が分からない状態は、担当者の少ない企業にとって見過ごしやすい運用リスクと言えます。

レンタルサーバーの問題は管理範囲の広さ

レンタルサーバーが一律に危険なわけではありません。適切に管理されたサービスを使い、WordPressやPHPを更新し、認証やバックアップを整備すれば、一定の安全性を担保できます。

一方、Web、メール、FTP、データベース、管理パネルなどを一つの契約で利用できる構成では、使っていない機能が残っているケースも少なくありません。機能や通信の口が存在するだけで脆弱性になるわけではありませんが、公開する仕組みが増えるほど、設定や認証、更新の管理対象も増えます。

確認する仕組み主な用途見直すポイント
WordPress管理画面記事・ページの編集外部公開の必要性、認証、利用者権限
FTP・ファイル管理機能Webサイトの更新現在も必要か、認証情報を適切に管理できているか
PHP・データベースWordPressの実行とデータ保存バージョン、更新責任、バックアップ
メール・Webメールメールの送受信Webサイトと同じ基盤で管理する必要があるか
サーバー管理パネル各種設定の変更多要素認証、アクセス制限、不要アカウント

企業サイトの用途が情報発信中心なら、管理し続けるよりも、公開に必要な仕組みそのものを減らす方が合理的な場合があります。

静的サイトは「完成したページ」を配信する

WordPressは、閲覧者がページを開くたびに、PHPやデータベースを使ってページを組み立てるのが一般的です。一方で、静的サイトでは、公開前にHTMLなどの完成したファイルを作成し、閲覧者にはそのファイルを配信します。

Astroは静的なWebページを作成できるツールです。作成したファイルをAmazon S3へ保管し、Amazon CloudFrontで配信することで、公開サイト上でWordPressやPHP、データベースを動作させない構成にできます。

【制作・更新】

[担当者・制作支援]
        |
        | ページや記事を更新
        v
[Astro]
        |
        | HTML・CSS・画像などを生成
        v
[Amazon S3（非公開）]


【閲覧・問い合わせ】

[閲覧者] <----> [Amazon CloudFront] <----> [Amazon S3（非公開）]
    |
    | 問い合わせを送信
    v
[HubSpotなどの外部フォームサービス]

閲覧者はCloudFrontを通じてS3内の公開用ファイルを閲覧します。問い合わせのように入力処理が必要な機能は、静的な配信部分から分離し、HubSpotなどの外部サービスへ接続します。

比較項目WordPress+一般的なホスティングAstro+CloudFront+S3の静的構成
ページ表示PHPやデータベースでページを生成事前に作成したファイルを配信
公開用の管理画面通常は存在する不要にできる
公開用PHP・データベース通常は必要情報発信部分では不要
プラグイン・テーマ更新継続して必要WordPress用の更新作業は不要
主な管理対象CMS、サーバー、拡張機能、アカウントAWS設定、更新権限、制作データ、外部サービス
問い合わせフォームWordPress内に持つことがあるHubSpotなどの外部サービスへ分離できる
セキュリティ上の考え方多層的に保護し続ける公開する仕組みを減らし、必要部分を分離する

CloudFrontは閲覧者に近い拠点からファイルを配信するCDNで、表示の安定化や高速化にも利用できます。S3はファイルの保管場所です。S3を直接公開せず、CloudFrontからの読み取りだけを許可する構成にすれば、公開経路を絞れます。

AWS+Astroによる企業サイトの構成例

情報発信を中心とする企業サイトでは、Astro、Markdown、S3、CloudFront、外部フォームサービスを次のように組み合わせることができます。

構成例の要素役割・考え方
企業サイトのページAstroで静的ファイルとして生成
ブログ記事Markdownで本文とタイトルなどを管理
共通デザインヘッダーや記事レイアウトを共通部品として管理
公開先S3にファイルを配置し、CloudFrontから配信
問い合わせHubSpotなどの外部フォームサービスとして配信部分から分離

この構成では、記事を追加するために公開中のWordPress管理画面へログインする必要がありません。共通部分と記事本文を分けて管理できるため、サイト全体の表記変更やページ追加もしやすくなります。

なお、この構成例がすべての企業にそのまま適合するわけではありません。更新担当者、公開頻度、承認方法、必要な機能に合わせて設計する必要があります。

ファイルで管理するサイトは生成AIと相性がよい

Astroでは、記事、ページ、共通デザインを静的なファイルとして管理できます。生成AIは既存ファイルの構成を参照しながら、文章の下書き、ページ追加、表記の統一、デザイン変更案などを作成できます。

利用場面生成AIに任せられる補助作業人が確認すること
お知らせ・ブログ下書き、校正、見出しや概要文の作成事実、著作権、対外表現
サービスページ既存構成に沿ったページ案の作成サービス内容、価格、問い合わせ導線
表記の統一複数ページの用語やリンクの修正案変更範囲、意図しない書き換え
デザイン調整共通部品を使った変更案パソコン・スマートフォンでの見栄え
SEO・読みやすさタイトル、概要文、見出し、代替テキストの改善案正確性、検索意図、アクセシビリティ

変更箇所を差分として確認し、承認後に公開できる点も、生成AIを業務へ取り入れるうえで有効です。自然言語で「新しいサービスページの案を作って」「全ページの表記を統一して」と依頼し、担当者が内容と画面を確認してから公開する運用が考えられます。

WordPressでも生成AI連携や編集支援は可能ですが、ファイルと共通部品に整理されたサイトは、AIが変更対象を把握しやすく、複数ページをまたぐ修正との相性がよい傾向があります。

静的サイトへの移行が向いている企業

静的サイトは、情報発信を中心とする中小企業のサイトに適しています。一方、複雑な機能や頻繁な即時更新が必要な場合は、WordPressを適切に保護して継続する方が合理的なこともあります。

サイト・運用の特徴静的サイトとの相性理由
会社案内、サービス紹介、採用情報良い公開内容が中心で、動的機能が少ない
低〜中頻度のお知らせ・ブログ良いMarkdownや編集用サービスで運用できる
資料ダウンロード、問い合わせ条件付きで良いHubSpotなどの外部サービスへ分離する
多数の担当者が毎日更新要検討編集画面や承認フローを別途用意する
EC、予約、会員ページ単純な静的化には不向き専用サービスや動的なシステムが必要
複雑な検索やユーザー投稿単純な静的化には不向きAPIや別システムの設計が必要

「WordPressか静的サイトか」の二者択一にする必要もありません。情報発信するためのページだけを静的化し、問い合わせ、予約、会員機能などは専用サービスへ分離する方法があります。非エンジニアが頻繁に更新する場合は、編集画面を提供するヘッドレスCMSと静的サイトを組み合わせる選択肢もあります。

移行前に確認すること

WordPressからの移行では、見た目だけでなく、現在のURLや検索流入、問い合わせ、メール設定まで確認する必要があります。

  1. 現在のページ、画像、PDF、ブログ記事を洗い出す
  2. 問い合わせ、検索、予約、会員機能など、WordPressに依存する機能を確認する
  3. 現在のURLをできる限り維持し、変更する場合は転送を設定する
  4. 更新担当者、更新頻度、確認・承認の流れを決める
  5. 問い合わせフォームと個人情報の保存先を確認する
  6. Webサイトの切り替えで、会社のメール設定まで誤って変更しないようにする
  7. 新サイトの表示と問い合わせを確認してから、旧環境を停止する

移行を急いでレンタルサーバーを解約すると、メール、画像、転送設定、過去データなどを失う恐れがあります。旧環境の停止は、依存する機能がないことを確認した後に慎重に行います。

まとめ：守る対象を減らすという選択肢

セキュリティ対策は、現在ある仕組みを守り続けることだけではありません。企業サイトに不要な管理画面、PHP、データベース、更新経路を減らせば、外部から狙われる穴と日常の管理負担を小さくできます。

WordPressには、非エンジニアがブラウザからすぐに更新できる強みがあります。一方、会社案内やサービス紹介が中心で更新頻度が限られるサイトでは、AstroとAWSによる静的サイトが、セキュリティ、運用の単純化、生成AIを使った更新のしやすさを見直す選択肢になります。

Webサイトの見直しをご相談ください

現在のWebサイトが静的サイトへ移行できるか、WordPressを継続すべきか分からない場合は、目的、更新頻度、問い合わせ機能、検索流入、運用体制を確認し、適した構成を整理します。

参照資料

関連するサービス・ご相談

コンサルティングを見る セキュリティサービスを見る お問い合わせ