Blog

ホームページが普通に表示されていると、保守費用はもったいない、と感じるかもしれません。内容を変えないなら、なおさらです。

でも、放置して困るのは、自社だけとは限りません。侵入されたサーバーが、他人のIDやパスワードを盗む偽ページや、不正なプログラムの配布に使われることもあります。訪れた人に被害が及べば、会社への信頼にも関わります。

保守を外注しなければいけない、という話ではありません。社内で管理する場合も含めて、誰が情報を確認し、何かあったときに動くのか。そこを曖昧にしたまま、公開し続けないでほしいのです。

文章を変えなくても、サイトの裏側は古くなる

お知らせや写真を差し替えることと、サイトを動かすソフトを更新することは別です。

WordPressなら、基本機能を受け持つ本体、見た目を作るテーマ、機能を追加するプラグインがあり、それらをPHPというサーバー側の仕組みで動かしています。

自社で何も変えていなくても、そのどこかに脆弱性、つまり攻撃に使われる弱点が見つかることがあります。画面がきれいに表示されていても、修正が必要な状態かもしれません。

PHPだけの話でもありません。JavaScriptをサーバーなどで動かすNode.jsは、2026年10月21日付でセキュリティ更新を公開しました。Javaで作ったプログラムを動かす環境などを含むOracle Java SEにも、10月20日付で更新の発表がありました。

もちろん、どのサイトもこれらを全部使っているわけではありません。影響や対応の急ぎ具合も違います。制作・開発担当者には、「うちのサイトは何を使っていて、更新のお知らせを誰が見ていますか」と聞いてみましょう。

会社の名前を知らなくても、攻撃はやってくる

攻撃者が一社ずつ社名を調べ、相手を選んでいるとは限りません。

NICT（情報通信研究機構）の2025年の観測報告では、攻撃に関連する通信が前年より増え、弱点を探す動きが高い水準で続いているとされています。これは侵入された会社の数ではなく、調査目的も含む通信の観測です。不正プログラムに感染した機器などからの探索も確認されており、知名度が低いことを安心材料にはできません。

攻撃に使う道具を、一から作らなくてもよい場合もあります。警察庁によると、身代金を要求するランサムウェアでは、道具を開発・運営する側が実行者へ攻撃環境を提供する分業が広がっています。高度な専門知識がなくても攻撃できる仕組みが、多数確認されています。

自動化や分業は、最近急に始まったものではありません。ただ、重大な弱点が自動で悪用される場面では、対応を後回しにしている時間も問題になります。英国のNCSC（国家サイバーセキュリティセンター）も、こうした場合に備えて、普段の更新とは別にすぐ動ける仕組みを用意するよう勧めています。

自社サイトが、他人への攻撃に使われることもある

フィッシングは、実在するサービスに見せかけ、IDやパスワードなどを盗む行為です。JPCERT/CCは、第三者のサーバーを不正利用してフィッシングサイトが公開されることを説明しています。

例えば、自社のサイト内に偽のログイン画面を置かれたらどうでしょう。そこで盗まれるのは、自社の情報とは限りません。その画面を信じて入力した人の情報です。

マルウェア、つまり不正なプログラムの配布に使われるおそれもあります。警察庁は、改ざんされたサイトを見た人がウイルスに感染するおそれや、ウェブサーバーにマルウェアが置かれた相談例を紹介しています。自社には何の連絡も来ていないのに、別の誰かが被害を受けているかもしれません。

会社側も被害者です。それでも、訪れた人には「この会社のサイトは使って大丈夫なのか」という不安が残りかねません。ページを直せば、会社の信用まで簡単に戻るとは限らないのです。

だから、トップページが普段どおり表示されるだけで、問題なしと判断しないでください。見覚えのないページやファイル、不審なアクセスの記録まで確認しましょう。保守は、自分たちのサイトだけを守る話ではありません。

月1回の保守では、間に合わない日もある

定期的な更新やバックアップは欠かせません。ただ、問題が見つかる日は、保守の予定に合わせてくれません。

2026年10月のPHPの重大な脆弱性では、修正版が出る前から事前告知がありました。IPAも、短時間で攻撃される可能性を踏まえ、修正版を公開後すぐ適用できるよう準備を呼びかけています。その後、PHP開発元は修正版を公開し、直ちに更新するよう推奨しました。

こういうときに、次の定期保守まで待っているわけにはいきません。更新前に何をして、どこまで確認したら再開するのか。あらかじめ、次の順番で動けるようにしておきましょう。

1. 事前告知が出たら、自社サイトへの影響を調べる。
2. 必要なら詳細公表前から、危険な処理にアクセスが届かないよう制限する。
3. 修正版が出たら、適用し、実際に動いている環境へ反映されたことを確かめる。
4. サイトの主要な機能を確認してから、アクセス制限を解除する。

すべての脆弱性でサイトを止めるわけではありません。影響範囲や攻撃のしやすさ、停止による業務への影響を見て決めます。CERT-EUも今回、すぐ修正できない場合は、修正と確認が済むまで公開アプリケーションの隔離を検討するよう勧告しています。

気をつけたいのは、「メンテナンス中」と表示すれば十分とは限らないことです。今回のPHPでは、WordPressなどの処理が始まる前に攻撃が成立する構成も、開発元から示されました。WordPressのプラグインで画面を隠すだけではなく、PHPへアクセスが届く手前で制限できているか、管理担当者に確かめてもらいましょう。

更新後は、問い合わせや注文まで確かめる

更新ボタンを押せたら、それで終わり。そう簡単にはいかないこともあります。

例えば、古いテーマが新しいPHPの系列に対応していなければ、切り替えた後にエラーが出る場合があります。WordPress公式も、PHP更新前のバックアップや、テーマ・プラグインの互換性確認を案内しています。

トップページは見えていても、問い合わせの送信に失敗しているかもしれません。ログイン後の画面や購入手続きも、実際に操作しなければ分からないことがあります。

あらかじめ、このサイトで止まると困る機能を決めておきましょう。会社案内なら問い合わせと通知メール、通販なら商品選択から注文完了まで。更新する人だけでなく、普段の業務で使う人も同じ項目を確認できれば、見落としを減らせます。

エラーが出たからといって、脆弱性の残る古い環境へ戻して公開するだけでは対策になりません。公開制限を続けながら直すのか、一時的に別の案内を出すのか。不具合が出たときの対応も、先に相談しておきたいところです。

保守契約で聞きたいのは「月何回」だけではない

契約書に「月1回更新」と書いてあっても、緊急時にどこまで動いてもらえるかは、それだけでは分かりません。制作会社や管理担当者に、次の点を聞いてみてください。

確認すること	具体的に聞きたい内容
情報を受け取る人	脆弱性やサーバー会社のお知らせを誰が確認するか
急ぎのときの対応	定期作業日以外や営業時間外は、どこへ連絡するか
停止と再開の判断	誰の承認で止められるか。連絡がつかない場合はどうするか
更新後の確認	表示だけか、フォーム・ログイン・注文まで確認するか
費用と対象範囲	緊急作業、古いテーマの修正、復旧は月額内か別料金か

レンタルサーバーを借りているからといって、サイトの管理を全部任せられるとは限りません。PHPの修正版はサーバー会社が用意していても、使う版の切り替えやWordPress側の確認まで誰が行うかは、サービスや契約によって違います。

自動更新も、手間を減らす助けにはなります。ただ、WordPress公式にも、自動更新が動かない場合や、更新に失敗する場合の案内があります。失敗のお知らせが届いても誰も読んでいなければ、そこで止まってしまいます。

異常に気づけるか、復旧できるかも確かめる

更新やアクセス制限だけでなく、不審なログインやファイルの変更を誰が見つけるか。その後、誰に連絡して調査や復旧を進めるかも決めておきましょう。IPAも最近の不正アクセスを受け、ログやアカウントの異常を点検し、誰が調べられるか整理するよう呼びかけています。

バックアップも、「自動で取っています」で話を終えず、実際に戻せるか、誰が作業するかまで確認してみてください。警察庁も、被害に備えてバックアップと復旧手順を確認するよう勧めています。

侵入が疑われるなら、元のデータを戻すだけでは足りません。原因や影響範囲を調べ、同じところから再び入られないようにするところまで含めて対処します。

保守に手をかけられないなら、仕組みを減らす方法も

手間や費用を抑えたいなら、使っていない機能を整理するところから始めましょう。不要なプラグインや、使わなくなった旧サイトが残っていないでしょうか。

会社案内が中心なら、「静的サイト」も選べます。ページを記述したHTMLや画像を、そのまま配信する方法です。公開先からWordPressや不要なPHPの実行環境を外せば、その分の更新作業や、攻撃に使われる入口を減らせます。WordPressを残してHTMLだけ表示しても、そのWordPressの管理は残ります。

筆者は『VIVANT』が好きなので、ここでは阿部寛さんの公式サイトを例に挙げさせてください。プロフィールや出演情報を載せ、トップページには所属事務所へのメールリンクがあります。問い合わせる人が、メールソフトなどを開いて送る方法です。会社案内が中心なら、必要な情報と連絡先に絞り、サイト側に送信フォームを置かない。こういう割り切りもできます。

10月22日の注意喚起では、IPAも、経営層を含めて継続的な管理に必要な人員・予算・保守体制を検討するよう呼びかけています。体制を確保できない場合は、保守を受けられるサービスへの移行や、機能を減らすことも選択肢に挙げています。

もちろん、静的サイトにするためにデザインを古くする必要はありません。ただし、サイトのアドレスに使うドメイン、公開用アカウント、暗号化通信（HTTPS）、配信するサーバーやサービス、掲載情報の管理は残ります。

フォームを置くなら、外部サービスなど送信処理を受け持つ仕組みの管理も別に考えます。会員・注文・決済も、静的ページだけでは完結しません。編集用のWordPressだけ接続を制限して残す方法も含め、詳しい構成の比較はこちらの記事で説明しています。

まずは「うちのサイトを誰が見ているか」を確認しよう

保守会社を探す前に、社内のWeb担当者や制作会社へ、こう聞いてみてください。

「明日、うちのサイトに関係する重大な脆弱性が発表されたら、誰が何をしてくれますか？」

答えが出ないなら、サーバーやサイトを操作できる人、緊急時の連絡先、バックアップの有無と復元する人を確認しましょう。長く放置して状態が分からないサイトは、手当たり次第に更新する前に、中の仕組みと復旧手段から調べてもらった方が進めやすくなります。

「自社が困っていないから、放置してよい」では済みません。自社のサイトが、他の人の被害の入口になるおそれもあるからです。

ホームページを持つなら、作るときの費用だけでなく、使い続けるための手間と費用も考えておきましょう。社内で担うか、外部へ任せるかは選べます。でも、公開したサイトを誰も管理していない状態は、そのままにしないでください。

現在の管理状況が分からない場合は、サイトURLと分かる範囲の契約内容を添えて、ウェブモへ既存サイトの問題についてご相談ください。

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