Blog

不正アクセスのニュースを見ると、「WordPressで作った自社サイトは大丈夫だろうか」と気になります。会社案内と問い合わせフォームだけのサイトなら、もっと単純な作りで十分ではないでしょうか。

結論からいうと、社内で記事を頻繁に更新しないサイトでは、静的ページを中心に作る方法は有力です。公開する仕組みを減らせるためです。ただし、WordPressを使わなければ安全、という話ではありません。何を公開し、誰が保守するのかを分けて比べてみましょう。

WordPressは、OSSだから危険なのか

OSS（オープンソースソフトウェア）は、ソースコードが公開されているソフトです。WordPressもその一つ。攻撃者もコードを入手でき、手元で動かしたり、修正前後の違いから弱点を調べたりできます。

一方、公開されたコードを確認して問題を見つけ、直せる利点もあります。WordPress公式のセキュリティ方針には、開発時のコードレビューや、報告された脆弱性を修正して配布する体制が説明されています。

つまり、公開されていることだけで「危険」とは決められません。独自開発や非公開のソフトにも設計・実装の不備は起こります。比較したいのは、使う機能、外部から操作できる入口、そして問題が見つかったときに直せる体制です。

サーバーを契約すれば、更新も任せられる？

WordPressでは、主に次の二つを分けて考えます。

• サーバー側：OS、Webサーバー、PHPなどの実行環境
• サイト側：WordPress本体、テーマ、プラグイン、独自に追加したプログラム

PHPは、WordPressなどのプログラムを動かす仕組みです。PHP公式にはバージョンごとのサポート期限があります。ただし、利用中のPHPを誰が更新するか、新しい版への切り替えと動作確認まで含むかは、サーバーの種類や契約によります。

サーバー会社がPHPの対策をしても、フォーム用プラグインの不備まで直るわけではありません。逆に、WordPressを更新しても、古いPHPの問題は別に残ります。

WordPress向けの管理サービスでも、自動更新の対象や例外、失敗時の対応範囲を確認しましょう。「自動」という名前だけでは判断できません。WordPress公式の自動更新案内も、設定や環境によって更新が利用できない、正常に動かない場合を説明しています。

静的ページにすると、何が減るのか

静的ページは、あらかじめ作ったHTMLなどを配信し、閲覧のたびにサーバーでページを組み立てない方式です。

一般的なWordPressは、アクセスに応じてPHPを動かし、データベースの内容を使ってページを生成します。これに対し、公開側からCMS（記事などを管理する仕組み）、PHPによるページ生成、データベースへの接続を実際に外せば、その経路を使った攻撃の対象は減らせます。

ここが「静的の方が安全にしやすい」と考える理由です。ページ数の少なさより、攻撃に使われ得る機能や接続経路を減らすことに意味があります。OWASPの攻撃面の解説でも、管理画面、フォーム、APIなどを確認対象に挙げています。

ただし、問い合わせフォームは別です。HTMLで入力欄を作っても、内容を受け取り、メール送信や保存をする仕組みが必要です。MDNのフォーム送信の解説も、フォームからサーバーへデータを送り、処理する流れを説明しています。

自作のPHP、API、外部フォームサービスのどれを使っても、受信処理の安全性、管理アカウント、個人情報の保存先は確認が必要です。ホスティングやファイル公開用の権限、外部から読み込むJavaScriptの管理も残ります。「フォーム付き静的サイト」は、すべてが静的な仕組みではないのです。

WordPressは編集用に残し、公開先だけを分ける方法も

既存のWordPressを、編集専用として別サーバーに置く方法もあります。担当者は今までの管理画面で記事や画像を更新し、読者には書き出した静的ページだけを見せる構成です。

流れは「編集用WordPress → 静的ファイルの出力 → 公開サーバーへの反映」。静的化ツールでHTMLや画像などを出力します。標準の「エクスポート」で出るXMLは移行用データで、そのまま公開できるHTMLではありません。

編集環境にはVPNや接続元の制限を設け、関係者だけがアクセスできるようにします。URLを知らせない、サブドメインを変える、といった対応だけでは隔離にはなりません。公開側からWordPress本体、PHPによるページ生成、データベース接続を外しても、編集側の本体・テーマ・プラグインの更新やバックアップは続けます。

フォーム、サイト内検索、会員機能などは、静的化後にどう動かすかを別に設計します。編集しただけでは公開ページは変わらないため、再出力して反映する担当とタイミング、反映後の表示・リンク・フォーム確認まで決めておきましょう。

同じサーバーに古いWordPressがあったら？

別サイトから被害が広がる可能性も、構成次第です。

一つの契約アカウントで複数サイトを管理し、侵入されたプログラムの権限で他のサイトのファイルも書き換えられるなら、被害が及び得ます。その権限で書ける静的HTMLも例外ではありません。

ただし、共有サーバーの別契約サイトが一つ侵害されたら、必ず全サイトが被害を受けるわけではありません。契約間の隔離やアクセス権によって異なります。WordPress公式のセキュリティ強化案内も、ホスティング環境やファイル権限を対策の一部として扱っています。

制作会社には「同じアカウント内に使っていない旧サイトはないか」「どの範囲まで書き換えられる権限か」を確認すると、具体的な話になります。

保守費用は、作るときだけで比べない

WordPressには、担当者が管理画面から文章や画像を更新しやすい利点があります。その便利さを日常的に使うなら、保守を続ける理由になります。一方、年に数回の修正をすべて制作会社に頼むなら、CMSを常時動かす必要があるか検討できます。

静的サイトにも内容修正の費用はかかり得ます。WordPressも、プラグインや独自改修が増えれば、更新時の確認対象が増えます。費用の見通しを立てるときは、「初期費用＋数年間の保守＋内容更新＋緊急対応」の合計で比べてみてください。

脆弱性が分かったら、次の定期更新日を待たない

月1回の更新を頼んでいても、緊急時まで月1回でよいわけではありません。脆弱性の情報や修正版の公開後、攻撃者が極めて短時間で悪用する可能性があります。IPAもPHPの注意喚起で、短時間での悪用に備え、修正版を速やかに適用できる準備を呼びかけています。公開前から悪用される場合もあるため、発表されるまでは安全とも限りません。

注意喚起を把握したら、自社への影響、重大性、悪用状況を確認し、必要な更新を急ぎます。すぐ適用できなければ公式の回避策やアクセス制限を検討します。保守契約では「月に何回」だけでなく、緊急時に誰が情報を受け、どれだけ早く判断・対応できるかまで確かめておきましょう。

更新が終わったら、表示が崩れていないか、フォームから送信できて通知メールも届くかを確かめます。普段の異常を誰が見つけ、バックアップから戻せることを誰が確認するのか。緊急時の連絡先も含めて、見積もりの段階で聞いておきたいところです。

まずは「自社で何を更新しているか」を確認する

会社情報、サービス紹介、問い合わせが中心で、内容修正も少ないなら、静的ページ中心の構成を候補に入れてよいでしょう。反対に、お知らせや事例を社内で継続して発信するなら、WordPressの編集機能を使う価値があります。

いまのサイトをすぐ作り直す必要はありません。直近1年に更新した内容と担当者、使っている機能、保守契約の範囲を書き出してみてください。「便利だから残す機能」と「使っていないのに守り続けている機能」が見えてきます。

構成を整理したい場合は、ウェブモのホームページ制作についてのご相談へ。必要な更新方法と現在の保守範囲を伝えていただくと、構成を検討しやすくなります。

情報確認日：2026年10月21日。